Can we prevent the unknown?

This article comes from the outcome of a discussion I had recently. The TLDR of the conversation was that the Security Architecture function of a company should try to protect against threats that the company cannot identify. I personally completely disagree with this (if you don’t and have an opinion, please get in contact and let me know)! The argument used was the classic entrepreneurial motto; you have your known knowns, your known unknowns and your unknown unknowns. Therefore you need to think about all three when making security decisions.

While there might be a case to think about all three, I don’t believe every company needs to care. I also don’t think responsibility for all three lies on security, let alone the Security Architecture function. If you are a static company that is comfortable in a well-established market segment and has no need to innovate a lot, your main threats are probably common across your industry. They do not require a new or modern approach. If it does, there are probably security specialists out there working to identify them for you.

However, if you are a more fast-paced company that’s rapidly growing/innovating and moving into new products/services/industries, you will care more about gaps in your knowledge. You might not have that unique domain experience, especially if there are few people out there with the expertise you need. This scenario, and maybe military organisations, are the only cases I can think of where worrying about the real unknown might matter.

If you are a company that does care about the “known knowns, known unknowns and unknown unknowns” I’ve written briefly below on what I think the appropriate actions are to handle each one. I believe that the terms are a bit fluffy. However, if this is the vocabulary people use within your company, this might help you with communicating security requirements to the rest of the business. If you disagree or have more to add to this discussion, please let me know!

Known knowns

Known Knowns are everything you have visibility of within your company, and you know that you have to do. Your big task here is first and foremost the security basics:

• Following any regulations/compliance tasks you care about.

• Making sure teams you engage with are secure.

• Tracking vulnerabilities/non-compliance

• Making decisions about how to remediate found vulnerabilities

These tasks are most Security Architect’s day jobs and enough for most security teams to focus on for their entire career.

Known unknowns

Known unknowns are the significant gaps in your security strategy that you have already identified. Examples might include:

• Teams where you realise you have no visibility of what they are doing and if they are following company security guidance.

• Gaps in your standards and currently implemented security practices. E.g. Do you have teams that use open source, but you don’t have any rules about how to use open-source code within the company? If so, this might be a gap in your security.

• Educational gaps within your security teams.

• Domain knowledge within the company. For example, do you have people with experience/knowledge to cover all areas you care about for security? An example might be a company that has lots of high-level security architects providing guidance but no one with experience on how to perform a secure code review.

All these are things that should probably end up on your road map to deal with slowly in the future. They’re easy to fix but take time/money. Once you have identified a gap and put effort into understanding it, the issues cease to be a gap in your knowledge, and the issue moves into the “known knowns” as detailed above. If it’s something too expensive/not important enough to investigate it can be fine to leave it, but you should at least document this decision and consider it as a known risk.

Unknown unknowns

Unknown Unknowns are the threats/vulnerabilities you don’t know about and don’t know you don’t know about it. Superfluous I know.

You are talking about gaps in your security you don’t know about that could affect the company. When discussing such gaps people often end up postulating about crazy possibilities that might be unlikely but could make your seniors paranoid. Usually, it’s entertaining to come up with all the crazy attack scenarios that could happen. However, they can be counter-productive if people take them seriously as you might focus on these issues over more pressing current issues.

When looking at how to prevent issues, you don’t even know about; the security team shouldn’t solve them alone. Proper risk management can solve such issues by defining a comfortable level of risk tolerance. Making sure your incident management and operational resilience is well prepared requires good engagement between all involved stakeholders. Operational resilience and recovery strategies are a much better solution for challenging to fix theoretical issues than trying to remediate every possibility.

One thing security architecture functions can do is make sure teams stay up to date with changes in the security field. That way, when there are new possible threats or technical vulnerabilities, your security teams are already prepared to deal with them. Some of the obvious choices to do this are investing in:

• External training and conferences

• Encouraging using work time to self educate and stay up to date

• External or internal threat intelligence

However, when it comes to business as usual activity, why should your security team focus on hypothetical existential threats when there are known issues you could focus on that will provide tangible and measurable results right now.

You might argue that operational resilience and incident response are security issues, this is definitely the case, and I’m not disputing this. What I am supporting is that they are not solely a security issue, incident response and operational resilience require input from across an entire organisation and sometimes won’t/shouldn’t need information from security at all. When it comes to assessing threats like this, it might be better to prioritise based on the worst possible impacts. If an attack was 100% unstoppable, what could that attack do? What would be the cost to the business? Are you in a position to remediate after the incident?

If you can make sure you have looked into what your operational resilience looks like possible unknown attacks become less scary, and if they ever did happen would have less of an impact. If resilience doesn’t work for you, the best option is to list all your significant impacts and wargame them. What happens, and what would your response be? I would expect it to be a blend of pre-emptive education for the teams that matter and lots of focus on incident response. It shouldn’t require additional security preventative measures.

After all this, I would say that you shouldn’t care about the unknown unless you already have an excellent grasp on what you do know. Most big compares are growing, merging into new markets, creating/replacing services so fast that the known issues you worry about are much more critical than hypothesising about what else could happen. You should prioritise your most significant threats and risks first.