printer friendly version

Are you below the security poverty line?

Cisco held a media round-table discussion for the EMEA region in late 2022 in which Wendy Nather, head of advisory CISOs at Cisco, spoke about the state of cybersecurity, specifically focusing on the Security Poverty Line (SPL), defined as the line below which an organisation cannot protect itself effectively.

Setting the scene with news that is not really news to anyone anymore (some call it cyber fatigue) the company noted that there are endless headlines today about cyber breaches and the resulting fallout. Some of the primary causes are ransomware, as can be expected, as well as supply-chain attacks where a company is breached because its systems are linked or integrated in some way with systems from third parties within its supply chain.

Unsurprisingly, MFA fatigue is also playing a role in an increasing number of breaches. Multi-factor authentication (MFA) is touted as a way to secure access to systems by requiring an additional security measure, such as an SMS one-time PIN or other authentication factor (like Google Authenticator), or a request for access that is sent via a corporate app to gain access.

Wendy Nather.

While MFA does assist in reducing the number of breaches due to passwords being guessed or stolen, the constant requests to authenticate yourself over time result in ‘MFA fatigue’, which sees users trying to find a clever way to avoid it, or simply agreeing to any and all requests, as happened in 2022 to Uber and others who thought they were protected by MFA.

Other noteworthy mentions were the range of software libraries developers have access to these days. Simple examples of the dangers of this have been seen in Python and JavaScript libraries, to name just two. This highlights the need for a Software Bill of Materials (SBOM), which Wikipedia says, “declares the inventory of components used to build a software artifact such as a software application.” In other words, it is a formal record of the components of a software product, as well as their ‘supply chain relationship’.

Writing for CSO online, Josh Fruhlinger explains: “The days of monolithic, proprietary software codebases are long over. Modern applications are often built on top of extensive code reuse, often using open-source libraries. These applications are also increasingly broken into smaller, self-contained components of functionality known as containers, managed by container orchestration platforms like Kubernetes and running locally or in the cloud.

“Overall, these changes have been a boon for software development, and have certainly increased developer productivity and reduced costs. But in many ways they’ve been a nightmare for security. By relying heavily on third-party code whose inner workings they may not be fully familiar with, developers have created a supply chain of software components every bit as complex as the ones used by physical manufacturers. And because an application is only as secure as its least secure component, software built in this way has unique vulnerabilities that the industry is deep into grappling with.” ^[1]

Wearing your Zero Trust seatbelt

We wear seatbelts in vehicles as a precaution in case we or another driver makes a mistake, although most of the time there is no need for it. However, when it is needed the consequences of not wearing it can be severe. Just so, organisations should also wear a Zero Trust seatbelt to ensure their systems are secure from users’ mistakes (or malicious activity). Blaming the user is always a good option to protect the cyber teams’ jobs, but it doesn’t really do any good in the long run; at best, everyone will be on high alert for a week or month before ‘business as usual’ kicks in again.

What is required is a multi-layered defence that prevents one user failure from impacting the organisation as a whole. This is the simplified definition of Zero Trust: you trust a particular user to access and use specific data for a specific time, that’s it.

The best line from Nather at the event was: “Security should be as easy to use as a spoon.” Using a spoon is easy to learn and no matter where you go, you know how to use a spoon without “spoon awareness training.”

That said, security is always a problem for organisations, whether cyber or physical security. There is a plethora of decisions to make regarding what systems to use, understanding the cyber posture (or state) of the organisation, knowing what connects to what and whom, what apps are in use and which should be used, where your data is, and many more questions. Security means coming up with a solution that can deal with the answers to those questions (or change the company to make the answers simpler, such as tighter control of data) and not believing every silver bullet that latest sales promotion offers.

The reality is that even large enterprises have many security solutions in place (as few as 4 and as many as 31) and security budgets can often be off (ie, too low) by a factor of four – and there is still no guarantee you won’t be breached. On top of that you can throw in ‘small things’ such as company culture and the endless arguments of safety vs. security and privacy vs. security to complicate matters even more.

No wonder the concept of ‘cyber fatigue’ is becoming part and parcel of everyday language. This brings us to the SPL.

The Security Poverty Line

Nather notes that the SPL is not referring to some form of moral failure on the part of organisations struggling with security, but the concept of ‘poverty’ rather describes the security dynamics of the organisation. As mentioned above, it is the line below which an organisation can no longer protect itself.

There are four primary factors that contribute to the SPL:

1. Money.

2. Expertise.

3. Capability.

4. Influence.

Money: Every company’s problem child, the question of money refers to whether the organisation is able to afford the appropriate tools and people to be able to protect itself effectively. The issue also raises some questions about the global nature of cybersecurity; for example, should some basic cybersecurity infrastructure or controls be provided as a subsidised service, as it is becoming rare that one breach only impacts one company? Additionally, what security should be ‘built-in’ and therefore available at no extra cost?

Even when using open-source software, which runs most of the world’s cloud servers, the actual software may be free to download and use, but enterprise-level applications need people to run them so it’s not really ‘free’. The cost and effort to maintain it (including security maintenance) are a factor to consider.

Expertise: We’ve all heard of or felt the pressure of trying to find good cybersecurity skills. Some forecasts say there will be a shortage of skilled people to fill around 3 million jobs by the end of next year or sooner. The problem is that even for companies that know what essential security they require, lack of skills may hamper the effective installation and use of it. Again, this also relates to the cost of solutions and skills; it’s not about awareness training, but the more in-depth knowledge required to make the systems function as required.

Nather suggests that cybersecurity products be designed to require less “arcane security expertise,” and the industry should be more supportive of all entry paths to the industry. Critically, she also recommends stopping “the market-driven concentration of expertise in those vendors who can outbid for talent.”

Capability: When it comes to the issue of capability, Nather recommends better technology refresh and integration practices, as well as moving non-core business functions to the cloud. She would also like to see more “vertical-specific security reference architectures,” not simply checklists.

Of course, company culture plays a significant role here, as in the hospitality industry for example – disrupting the guest experience (perhaps with MFA) would not be acceptable. Therefore, security must take these factors into account and create a balance between business and security. This relates to the above-mentioned arguments about safety vs. security and privacy vs. security. She notes that failing fast is good, and even necessary in certain industries, but not when you’re on a plane 10 km up in the air. Similarly, do you want to be the patient that dies on a gurney with your privacy intact?

Influence: Large customers with money get all the attention and their requests for new features or new legislation are fulfilled quickly; not so much the small guys, and this needs to change.

Probably the most difficult of the four factors, influence involves balancing those with more influence (the biggest/loudest) and the rest of the security and business community, while also addressing the “massive multi-stakeholder, cross-border, military/civil cybersecurity policy problem.”

As can be seen, many companies that think they have done the necessary to be cyber-ready will find themselves below the SPL, not from lack of effort but due to the complexity of the cybersecurity landscape. More frightening is that it is very likely that only the security team will know if the company is below the SPL unless they inform management – and who is going to take that risk?

Cybersecurity is something the industry as a whole needs to address, not simply from a profit motive but as a sustainability project, because those committing cybercrimes have no scruples in terms of who suffers the impact of their crimes. And it’s not simply an industry issue – governments need to get on board and work with the private sector (and vice versa) in setting up baseline capabilities and facilities that will allow those not able to afford the latest and greatest products and skilled people to at least have a chance of protecting themselves.

As a starting point for companies looking to raise their SPL rating, Cisco published its latest Security Outcomes Study ^[2], looking to “uncover the top 5 security practices and how to optimise them” – and a whole lot more. It’s well worth a read.

^[1] www.securitysa.com/*cso1, redirects to https://www.csoonline.com/article/3667309/what-is-an-sbom-software-bill-of-materials-explained.html

^[2] Cisco Security Outcomes Study, Vol. 2: www.securitysa.com/*cisco4, redirects to https://www.cisco.com/c/en/us/products/security/security-outcomes-study-vol-2.html

Share this article:

Further reading: