Cybersecurity Needs to Mitigate Complexity – Source: securityboulevard.com

Bruce Schneier’s quote, “Complexity is the enemy of security,” is one of my favorite sayings. It sums up one of our biggest challenges: We can’t defend what we don’t understand. You may have heard this saying as, ‘Complexity is the enemy of operations,’ or ‘Complexity is the enemy of reliability.’ While those may be true as well, overall, complexity is a rapidly growing problem facing the security industry. With that in mind, how do we change this from just a catchy saying to become a key part of our security program?

‘Complex’ means “consisting of many different and connected parts.” When I became a CISO, I didn’t realize how much time would be consumed with vendor management. A great insight from Panaseer’s 2022 Security Leaders Peer Report showed that, for a company with 500 employees, the number of cybersecurity tools increased from a baseline of 64 to 76 cybersecurity tools (a 19% increase). This doesn’t surprise me; at the last RSA Conference, there were 599 speakers and 605 vendors. But having a large number of security capabilities can lead to a few issues. You have one engineer trying to maintain and optimize multiple systems, so none of them are up to date. Next, you have one analyst trying to respond to feeds from multiple systems and, in some cases, multiple dashboards. This leads to missed alerts that could have prevented an incident from becoming a major crisis. Then you have the amount of time you spend with your vendor management team and the vendors themselves (they each want to have quarterly meetings–with 76 vendors, that would be about two months’ worth of meetings a year).

The Expanding Attack Surface

Having a great presence on the internet has a name: Attack surface. The attack surface is compounded by remote workers, customer access capabilities, growth of apps and APIs, the move to hybrid cloud infrastructure, BYOD and SaaS, which leaves us with multiple environments to protect. This means many of our current tools may not even work across all our environments.  Additionally, some environments may need bespoke tools. Finally, it means we need skills that our current team often doesn’t have (i.e., reviewing code versus setting up an antivirus server). The tendency is to solve each issue in isolation which leads to mission and tool bloat, which is a major factor in the complexity we face.

Don’t forget that the enemy gets a vote. We are working on a highly contested internet. I remember when the Magecart attacks prompted me to ask if the JavaScript environment was monitored and protected under the current security program. Even if it was not, and I decided to accept the risk, I then found out PCI was making it a part of the new 4.0 standard, so I would have to protect it to be compliant. So, here is a case where I discovered additional complexity in infrastructure that had critical data but was not part of my core risk program. Another example is DNS, which may not be part of the security team’s DDoS protection strategy. Or the move to infrastructure-as-code (think DevOps) and adding IoT devices to the network where I may not have the right skills on the InfoSec team. These are technical examples–don’t forget management/organizational complexity or convoluted regulatory/compliance requirements that drive solution bloat. While we are aware of the complexity issue, I don’t think we track it or try to quantify it.

I could go on, but I think these examples demonstrate the need to map out your infrastructure and critical data locations.  Additionally, many companies are now on a journey to develop a software bill of materials (SBOM) so they not only know what their infrastructure is but also can quickly understand risks from open source code or third-party software. Once you have the technical scope and gap assessment done, then you need to review the people and process complexity issues.

While I have run into a few folks who love drama and complexity, most of us don’t gravitate toward it. But large systems are often, by their nature, complex. We typically try to talk about them as simple models because we just can’t get into the details. This leads us to believe we understand them when we don’t–don’t fall into this trap.

It is also important to understand where we have complexity–for a retailer, the backend systems can be complex, but the customer interface has to be easy to use and extremely responsive. That said, I don’t believe we think enough about the opportunity costs of some of the backend systems we add. If we had a ‘Keep it simple, stupid’ (KISS) culture, we could minimize entropy into these environments.

One example of implementing KISS is in deciding how to invest. Some companies follow a model of, “We only build what is unique to our business or defines our competitive edge.” I have been in companies that had a culture of developing everything internally and other companies that only wanted to use off-the-shelf technology. While both are valid, if InfoSec followed the business model of ‘only develop what provides the company with its unique discriminator,’ then there could be a number of security controls that should be outsourced (i.e., leverage managed services).

Addressing Complexity

What can we do about it? First, I want to talk about the concept of cyber-first principles (In the interests of full disclosure, I helped publish a book on this topic, so I’ll admit my bias up front). I believe we need to start with a clear mission statement that helps us drive toward simplicity. Our recommended solution is “Reduce the probability of material impact due to a cybersecurity event over the next three years.” You can modify the period of performance based on your own business model. Then, from there, build out operational areas like zero-trust, intrusion kill chain prevention, resilience, risk forecasting and automation. Finally, add tactical aspects like DevSecOps and compliance (see figure below). By starting with a framework of what you want to do, you can reduce the number of tools to those needed to protect your company’s core functions.

The next step in reducing complexity is to scale back the tool count, increase automation and reduce technical debt. Where we have tools with overlapping functionality, we should accept some degradation in individual tool capabilities by eliminating one of them to gain the benefit of stronger monitoring/management of the remaining tool.  Next, we want to optimize our current tools to ensure they are both functional and integrated. Then, we want to look forward by asking if we can solve the issue by expanding on current capabilities or vendors. If not, the evaluation criteria should include ‘playing well with others.’ Finally, don’t just apply this to security tools but look at staffing and process documentation to see where we can reduce waste, reduce complication and duplication.

Mitigating complexity or moving to a culture of KISS is a journey, but I think it is important. We need to stop doing the same things over and over and refocus on what will provide the long-term benefits we need so we can go home at a reasonable hour on Friday. I will end with another quote from Michael Jordan: “Talent wins games, but teamwork and intelligence win championships.”