I often follow the discussions on the "ISO 27001 Security" Google Group. Not because I'm a huge ISO fanboy, but rather, because it's full of people who are just starting to dip their toes in the waters of InfoSec and are looking for advice on how to get started. Having started an Information Security Program from scratch in my previous role and built it into an 8-person team covering just about every facet of Information Security, it has put me in a unique position to be able to provide advice and guidance to them. Recently, there was a young man who posted into this group asking for "a checklist or template for conducting a gap analysis" because he believed that having such a tool would be helpful in identifying the gaps between their current and desired performance and enable them to develop strategies to bridge those gaps. While few people on the list threw out anything useful, I was able to point him toward the spot in our demo video where I highlight exactly how to do this in SimpleRisk and provide him with a link to the recording of my BSides Vancouver 2021 talk on Measuring Cybersecurity Maturity. This initiated a whole side conversation where he mentioned that he recently joined this organization (a university) where he is struggling. Apparently, he presented to his leadership on his ideas for what he will be working on, but they didn't like it. I'm not sure why this organization would hire a novice to build an Information Security Program for them, but he seemed like a nice guy and I wanted to try to be helpful so I asked him to share with me his idea and the feedback they gave him.
The PowerPoint he sent me showed that he had done some research. It had themes of reviewing policies and procedures, performing control gap assessment, and risk assessment and management. He had bullet points for vulnerability assessment, penetration testing, incident response, change management, configuration management, data classification, BCP/DR/BIA, IAM, security awareness training, phishing campaigns, and a host of other ideas. All of this done in 8 slides (including the title slide) with a four month plan of execution.
From an aesthetics standpoint, it was bad. While it was clear he put a lot of time into it, he clearly did not know his audience. Slides were cluttered with data that was completely irrelevant at this stage in his progress and I counted 16 bullet points on one slide with numbers and letters, but no indentation. Many of these details would have been fine on a project plan, but weren't really appropriate for this presentation. The background was just a stock white with no template. It was data overload in an underwhelming format. But that wasn't the worst part.
Once I dug into the meat of the presentation, he had the right idea, but it was completely backwards. His plan was essentially to review the organization's current cybersecurity policies and procedures, identify any gaps or areas for improvement and develop a plan to address those gaps. Seems pretty solid, and probably something I could have gotten behind on it's own, but in his timeline on the last slide, he basically ignored that plan and went straight to phishing his users and conducting a training campaign. Forget for a moment that I wrote a blog post a long time ago about Why You Shouldn't Phish Your Users. He went from ZERO to PHISHING before identifying what his risks were and creating a mitigation plan for them. This is a classic example of putting the cart before the horse. I'd be willing to bet that a sales guy from some phishing company convinced him it was his biggest gap and he just went with it. When you start pushing tools before process, you're clearly in the danger zone.
While I certainly appreciate the idea of starting with a framework and performing a control gap analysis, it too feels like a step in maturity that he wasn't yet ready to take. I guess you have to start somewhere, but if that somewhere is literally the ground floor, your gap analysis is just going to frustrate you by showing that you do little to nothing.
My suggestion was to first put a formal Risk Management program in place. The SimpleRisk Core is a great place to start here because it is a free tool that enforces the NIST 800-30 process for risk management. I provided him with some presentations that I gave when I was at NI to help sell the risk management program. I had a different presentation for Management and Individual Contributors. On the Management side, I highlighted how our new Risk Management program would drive visibility and accountability up the chain of management. How they would have insight into things that they currently aren't aware of. And if you don't know that it's an issue, how can you possibly plan for it? On the IC side, I highlighted how this was a tool for CYOA and cited an example of how one of our Unix Admin's told me "When I tell you all my risks, I feel like I'm at the Dr's office with my pants around my ankles". I told him that, currently, if the bad thing happen's, he's the one who deals with the fallout. However, with proper risk management, I could guarantee him that the right people in Management will not only see his risks, but have to make a decision on how to handle them.
Next, I suggested that he sit down with the different teams to learn how they do things today. It's fine to keep your NIST CSF, ISO 27001 or whatever framework of choice in mind when you do this, but it's not a formal gap assessment. The goal is to listen and learn. With a formal process in place for how to manage the organization's risks, you can begin to document what they are telling you and map those risks to your desired controls. With this step, you begin to visualize what the issues are in your environment and how to fix them.
From here, you should consider that there are a wide variety of sources of risk assessment in your organization. Every vulnerability assessment, penetration test, audit, etc that you do is highlighting risk as a result. You should be leveraging your new risk management process to prioritize your risk mitigation efforts based on a combination of severity and level of effort/cost.
Lastly, now that you finally know the teams and have a solid foundational understanding of your operating environments, you can begin to look at your control framework and performing a gap assessment against it. It's not even worth talking about certifications at this point because we still don't know what we don't know. At this stage, we should be looking at the current maturity levels of our controls against our desired state for each, rather than a binary "we do it" or "we don't" approach. The Control Gap Analysis report in SimpleRisk provides a nice visual for Management that highlights your areas of strength and weakness. Gaps should be documented as new risks in your risk registry and you can follow your existing risk mitigation process to close them. The size and number of gaps are going to be what determines our security project roadmap and how long it will take to accomplish our goals. This is the justification that we present to Management to ensure they are onboard with both our assessment and direction.
This is the process that I followed when I was at National Instruments. Through patience and perseverance, I was able to grow my team and expand our purview across IT, and eventually, much of the enterprise. Certainly there are other ways to go about it, but I feel like this builds a solid foundation for getting your Information Security Program off the ground, as well. Good luck!
