Jim Doggett, US VP and CISO, Panaseer
In the good ‘ol days of CISO, things were straightforward and it was pretty easy to do what it took to be successful. I would prepare a budget for the upcoming year from a list of essential and value-added projects, which my security and risk team supported. Then we would sell the budget request through the normal approach: fear, uncertainty and doubt. Quite simply, if anyone questioned our request we would state that if we don’t do the project, we might get hacked and we would fear losing our jobs. With the budget in hand, we would set off and get a lot done over the course of the year. Then, at year end, we would produce a PowerPoint with all the great things we accomplished.
However, something then changed in my simple world. My Board of Directors and the C-suite began asking: “What is the ROI on each security investment,” and “How does each project reduce the risk to our organisation?” They then started asking for monthly updates on our progress to reduce those risks.
This was the beginning of how I, as a CISO and IT Risk Officer, began to think about security in a very different way. I was now being evaluated on how well I could reduce IT risk from security, measure that reduction and sustain it.
Before delving into how we might approach measuring and sustaining risk reduction, it might be useful to compare the past. If we go back, say 20 years, what were the key security risks/threats we were dealing with? I suspect most of us would have answered: patching, vulnerabilities, too much access and the like. In other words, doing the basics of security (i.e. enterprise cyber hygiene) well. And if we asked the same questions today, or looked at the root cause of most breaches today, many of us would answer the same way.
This was my first revelation: I cannot only focus on the newest black belt, advanced threat that was out there. I needed to focus on the basics of security to enable my team to have enough time to get to the latest threats. So this article is not about the latest advanced threat, it’s about the basics.
I knew that to become a modern CISO and understand the constant risks in my organisation, I would need to be able to track and monitor my state at any given time. There were at least three things I thought I needed to do in order to fulfil this: access to the right information at the right time, trust in the data I was using and automate as much of the process as possible.
Getting the right information
Getting to the right information was a big hurdle. For each security area I focused on, I had to consolidate all of the relevant data. That sounds easy but has proven to be much more difficult than anticipated. Bringing data together from disparate security and other tools and unifying/normalising that data is not easy and can be very time-consuming. I also needed to enhance the data with line of business details, geography, criticality to the company, etc.
If we are to make prudent decisions on what to fix and what not to, we must have the right information to prioritise the information. It’s not about fixing everything, but fixing the right things that most reduce risk for the dollar/pound.
It seems like every CISO I speak to says, ‘I have every security tool’. While this may be a slight exaggeration, the premise is sound. Most of us do have plenty of security and other data being collected through the plethora of tools we have. The problem relates to the fact that nothing joins all of the data from the tools into one place and one framework to enable us to understand what our risk posture is. Instead, I was forced to look at each security area and the assessment tools used in an isolated manner. I needed all of the data joined up so I could conjure up a true picture of risk.
Gaining trust in the data
I have found that everyone having trust in the data being used for security is a prerequisite to being able to have a fruitful discussion on the security issues. This is more obvious from the security team’s perspective, but even more important for those in the company outside of security who own the responsibility to fix or maintain the data. Its key to remember that most security, at any company, is done by people outside of security. It’s the infrastructure teams who patch systems, the developers who write secure/or insecure code, it’s people all over the company who authorise privileged access.
So the first few months of using this consolidated data was spent mostly arguing over the validity of the data and we had setbacks. On one occasion, a certain region of the world did not report on vulnerability data correctly and I reported improved results to the Board, only to have to retract this information in the next meeting.
Losing trust takes a long time to recover from. Measures must be taken to ensure that the data being used is of the highest quality so that the discussion can move on from the quality of data to the risks that need to be addressed.
So as I was pulling together this security data from many sources, I had to put in controls to help ensure that duplicate information was removed, gaps were identified (e.g., are your scanners scanning all the devices or only some portion) and we had clear definitions on what we were measuring (e.g., all devices or just servers).
Automation of the processes
A key contributing factor to why we have not solved the basics of security is that we have plenty of tools to automate the generation of data but few, if any, tools to automate the rest of the process – the collection and unification, the prioritisation, the driving of remediation and the ability to automatically track that status.
As I began the journey to address enterprise cyber hygiene permanently, I initially focused on doing it manually. I pulled people from other security work and had them focus on pulling the data for a particular security area, say; system vulnerabilities. They pulled data from nearly a dozen sources and then attempted to clean the data so it was complete and accurate. It proved difficult to do and required several revisits and too much time to get acceptable results. Then it had to be enriched with ownership data and put into reports for Board and executive reporting.
This manual approach proved to be impossible for me and my team to keep up with monthly. By the time we had one month completed, it was too late to start on the next. Thus, we had no choice but to automate.
As we began to develop process automation around security areas, we discovered several benefits: speed; as we had repeatable automated processes, fewer errors; as we build in logic to catch errors, and greater insights; as the computer saw many things we did not. Another benefit that we didn’t initially anticipate was the efficiency gains from less audit disruptions. As we allowed the second line of defence, audit and the SOX team to start using the tool, they quickly began using this data and stopped doing their own assessments/testing. That saved time not only for that team, but also for the IT teams that had to provide that information.
To summarise, I find it very interesting that the very thing I complained about most; not enough resources to address all these emerging security issues, was under my own control all along. By solving the enterprise cyber hygiene basics, I was able to do much more with the same, or fewer, resources. And I think that is, or will become, an expectation of all CISO’s in the future. We cannot opt-out of running our organisations as efficiently as possible when all the other parts of the company are being compelled to do so.
So, think about risk management embedded in security, automation of manually-intensive operations and bring all security data into one unified framework that is usable to make decisions and move forward. And if you do, you just might get what you need
