Though Cybersecurity Awareness Month is dedicated to raising awareness of cyber risks for non-tech people, it should also be directed at security professionals. So I thought it was a good time to share some pitfalls I encountered in my career as a CISO.
Here are three events that happened to me in my early days and the lessons I drew from them.
When I started working at one of my previous positions, I asked the IT Manager if the WAF was tested and working correctly. He confidently assured me that all was in order and that configurations were up-to-date. A few weeks later, during a routine check, it appeared that the WAF, though well configured, had been left in audit mode, and never turned back to enforce mode.
In other words, it was actually doing nothing.
Similarly, when I asked another DevOps team managing the cloud server environment if the latest Windows patches had been applied, he answered with confidence that we had no Windows servers, only Linux ones, and serverless services, and we are using a hypervisor-based protection system, so everything was in order. Two weeks later, in follow-up conversations, it appeared that, though most of our workloads were hosted on Linux servers, they were one or two Windows ones in the mix.
To make matters even worse, though protection systems were indeed active when I talked to IT the first time, it was in trial mode and not in audit mode. In the meantime, the trial period had expired. In short, not only did we have ‘one or two’ – upon verification, it was almost a year of unpatched Windows servers, and we had been woefully unprotected for the whole year since the expiration of the threat detection service trial period.
Another time, as the company I worked at added a code analysis system to highlight possible vulnerabilities during the SDL implementation phase, I asked and was assured that the CVE list had been updated and mistakenly assumed all was in order. So, the code analysis system was integrated and presumed to block potentially harmful lines of code. And it would have, except for one tiny detail. The system was running in audit mode and was somehow only scheduled to switch to blocking mode a couple of months later.
So, what did I learn from those early mistakes?
Building trust with your team is paramount
One of the biggest obstacles to obtaining a complete picture of the actual state of the system is to inspire your team members with the confidence that uncovering flaws is earning them credit and not threatening their credibility. Though security is more essential than bruised egos or respecting comfort zone boundaries, in real life, people tend to privilege their ego’s integrity and be reluctant to go the extra mile.
As long as team members lack the confidence that their CISO will congratulate them for disclosing security flaws, they are less inclined to invest the time needed to check all the nitty-gritty details, or might even tend to not disclose potentially problematic information for fear of adverse reaction.
Without a full picture, maintaining information and data security, let alone planning for technology improvements, is unworkable.
So, the most crucial role of a CISO is to build trust with all the people involved and build a team spirit to streamline accurate information flow.
When using any system, ask three fundamental questions:
- Do we have the system?
Even though it sounds ridiculous to ask if we are actually using it, checking that the license has been purchased and how long its validity extends makes the difference between believing a system is running and it actually running. Keeping track of licenses nearing expiration date and supervising new technology trials (including the trial period end date) is crucial to be 100% certain that all listed systems are indeed running. - Are we running the system?
Even if a subscription is active and months away from its expiration or renewal date, it does not mean that the system is actually running. Training your team to always verify that systems are active before assuming they are is key to avoiding the “stupid” mistake of trusting the effectiveness of a system that is actually off. - Are we running the system as intended?
There are two main pitfalls when using third-party systems:
• Keeping the default vendor configuration – This old trope remains true every day, so I just thought I would add it here. It always pays to ensure systems are correctly configured and never trust the vendor’s default configuration.
• Missing out the obvious – On the opposite side of lazily keeping vendors’ configurations as is lies the potential consequence of hyper-focusing on the detail and missing out on the obvious When configuring a system to work optimally, it is easy to get lost in fine-tuning privilege access, checking at all ingress and egress points, and other nitty-gritty details. After triple checking that all the details are correct, it is easy to miss out on the elephant in the room, such as a time gap between the time the code analysis system presumably started running and the time the two-week scheduling delay to switch from audit to blocking mode as I experienced once.
All the above might appear self-explanatory, but the art of avoiding these pitfalls lies in learning the delicate dance between creating team members’ trust and continuously auditing that their job is done correctly without denting that trust.
This dance can only be learned on the job, and its steps also need to be “configured” according to each team member’s personality and constantly adjusted to meet both their mood of the day and the job’s requirements.
Want to engage cybersecurity stakeholders, business executives, and your team based on factual and timely data? Gain the visibility you need to make the best decisions: