Month: August 2023

Software Supply Chain Security Considerations

Over the past five years there has been increased scrutiny on the security of supply chains and in particular software supply chains. The Solar Winds attack in 2020 brought this issue to the foreground as yet another requirement for a well rounded security program and also has been codified into several security guidelines such as, the Biden Administration Executive Order in 2021 and CISA software supply chain best practices. As businesses shift their software development practices to DevOps and Cloud, CSOs need to make sure software security is one of the components that is measured, monitored and controlled as part of a well rounded security program.

How Did We Get Here?

The use of open source software has increased over the past two decades largely because it is cheaper and faster to use an existing piece of software rather than spend time developing it yourself. This allows software development teams quicker time to market because they don’t have to re-invent software to perform certain functions and can instead focus on developing intellectual property that creates distinct value for their company.

There is also allegedly an implicit advantage to using open source software. The idea being open sourced software has more eyes on it and therefore is less prone to having malicious functions built into it and less prone to security vulnerabilities within the software. This concept may work well for large open source software projects that have a large number of contributors, but the concept falls short for smaller projects that have fewer contributors and resources. However, until the Solar Winds hack in 2020 the general attitude that open source software is more secure was generally applied to all projects regardless of size and funding. As we have learned, this flawed reasoning does not hold up and has allowed for attackers to target companies through their software supply chain.

The challenge with open source software is it is supposed to be a community led project. This means people use the software, but are also supposed to contribute back to that project. However, as companies have embraced open source software the two way street is more biased towards taking and using the software than contributing back. If corporations contributed back in ways that were proportionate to their use of open source software, the maturity, security and quality of the open source software would be drastically improved.

What Are the Risks?

There are several inherent risks involved in using open source software and they are as follows:

Can You Really Trust The Source?

How do you know the software you are pulling down from the internet doesn’t have a backdoor built into it? How do you know it is free from vulnerabilities? Is this piece of software developed and supported by an experienced group of contributors or is it maintained by one person in their basement during their spare time?

The point is, it is fairly easy to masquerade as a legitimate and well supported open source software project. Yet, it is difficult to actually validate the true source of the software.

What Is The Cadence For Vulnerability Fixes And Software Updates?

The size and scope of the open source software project dictates how well it is supported. As we saw during Log4j some projects were able to push updates very quickly, but other smaller projects took time to resolve the full scope of the issue. Any company using open source software should consider how often a project is updated and set limits on the use of software that doesn’t have regular and timely updates.

May Actually Require An Increase In Resources

There are ways for companies to manage the risk of using open source software. Assuming you can trust the source you can always pull down the source code and compile the software yourself. You can even fork the build to include fixes or other improvements to suit your specific application. However, this takes resources. It may not take the full number of resources that would be be required if you wrote the software from scratch, but maintaining the builds, version control and the general Software Development Life Cycle will need to be properly resourced and supported.

Can Complicate External Stakeholder Management

Another issue with using open source software in your supply chain is external stakeholder management. The Biden EO in 2021 requires companies to provide a software bill of materials (SBOM) for software sold to the U.S. Government. This trend has also trickled down into 3rd party partner management between companies, where contractual terms are starting to ask for software bill of materials, vulnerability disclosure timelines and other security practices related to software.

One major issue with this is: it is possible for software to be listed as vulnerable even though there may be no way to exploit it. For example, a piece of software developed by a company may include an open source library that is vulnerable, but there is no way to actually exploit that vulnerability. This can cause an issue with external stakeholders, regulators, auditors, etc. when they see a vulnerability listed. These external stakeholders may request the vulnerability be resolved, which could draw resources away from other priorities that are higher risk.

Standardization Is Hard

Finally, standardizing and controlling the use of open source software as part of the SDLC is advantageous from a security perspective, but exceptionally difficult from a practicality perspective. Unwinding the use of high risk or unapproved open source software can take a long time depending on how critical the software is to the application. If developers have to recreate and maintain the software internally that takes development time away from new features or product updates. Similarly, getting teams to adopt standard practices such as only allowing software to be a certain number of revisions out of date, only allowing software from certain sources and preventing vulnerable software from being used all takes time, but will pay dividends in the long run. Especially, with external stakeholder management or creation of SBOMs.

Wrapping Up

Using open source software has distinct advantages such as efficiency and time to market, but carries real risks that can be used as an attack vector into a company or their customers. CSOs need to include software supply chain security as one of the pillars of their security programs to identify, monitor and manage the risk of using open source software. Most importantly, a well robust software security supply chain program should consider the most effective ways to manage risk, while balancing external stakeholder expectations and without inadvertently causing an increase in resources.

Can Risk Truly Be Measured?

As a CSO, everything you do needs to be evaluated in terms of risk to the business. When you build a security program, prioritize objectives or respond to incidents all of your decisions will take into consideration risk and how to effectively manage it. Which begs the question: Can Risk Truly Be Measured?

The Problem With Risk

The problem with risk is that it is subjective. Everyone views risk, and the behaviors that contribute to risk, differently. Trying to measure a subjective concept can lead to inconsistencies, fluctuations or even conscious and subconscious influencing of the outcome. Even worse, as you engage in behavior that involves risk, your risk tolerance will adapt over time to accept the risk as normal. For the security space, this is the equivalent of failing to implement a specific security control and yet avoiding a breach or incident. As a result the business may try to rationalize that you don’t need to implement the control because you haven’t suffered the consequences of a breach. How do you consistently and objectively measure risk for yourself, your team or your business if it is subjective?

Objectivity Leads to Consistency

Risk can be measured, but it requires you to apply an objective and consistent process to gain consensus and get consistent results. There are several methods for obtaining consistent results when dealing with a subjective concept. In Operations Research there is a process known as the Analytical Hierarchy Process (AHP), which attempts to achieve a mathematical decision for a subjective concept (like deciding which house to buy). Similarly, when attempting to decide between different subjective concepts you can use simple mechanisms like pairwise comparisons or a triangle distribution to express the decision mathematically.

Here are two examples:

Pairwise comparison: This comparison is useful for comparing two things to determine which one is more important. Example: Patching our publicly facing systems with critical vulnerabilities is ten times more important than patching our systems with critical vulnerabilities that are only internally accessible.

Triangle Distribution: This distribution is useful when attempting to distill a decision down to a value when you may only know two data points, such as the extremes. Or, if two people offer different opinions for the value of something you can use the triangle distribution to find a compromise in the middle. Example: Manager 1 – The impact of this event is a 2 out of 5 (5 being highest). Manager 2 – The impact of this event is a 4 out of 5. Using a triangle distribution we decide the impact of this event is a 3.

Either of these methods can be used to determine the likelihood and impact for a specific security control in an industry standard security framework like NIST or CIS.

There are other objective methods for assessing and assigning risk. I’ve discussed the CIS Risk Assessment Method (RAM) in detail in my blog post about Building A Strategic Plan. The advantage of this method is you can apply a consistent process to assign and measure risk for every single CIS control and sub-control. This allows you to measure how you well you are managing risk over the lifetime of your security program in a repeatable way.

When Things Go Wrong

Following an objective process to measure risk requires you to take the time to methodically apply the process to each decision or control you need to asses. This can be time consuming at first, but once the initial baseline is set it is easy to update and maintain. However, it is easy to mess this process up. Here are a few things I don’t recommend:

  1. Don’t make up your own security control framework – There are industry standard security frameworks for a reason. The standard frameworks are comprehensive and have clear criteria for how to apply and asses the effectiveness of a control. The worst “frameworks” I have seen are typically made up by someone in the security team that things they know better. These “frameworks” are subjective, inconsistent, contradictory, redundant or unclear about how to apply specific controls. On top of that these “frameworks” require someone to update them, maintain them and communicate them to the rest of the org. Why duplicate work when you don’t have to?
  2. Failing to apply a consistent process – Failing to apply a consistent process for measuring and assessing risk means you will fail to get a consistent and objective result. This means you will have an inaccurate measurement of risk or the risk will fluctuate with each measurement, which will render it useless. Also in this category is allowing different teams within your company to use different processes for assessing risk. This means you will not be able to consistently compare the risk of different security controls across the business, which can lead to gaps or overconfidence.
  3. Failing to validate the result – This may be obvious, but each of your measurements should be backed up by evidence. Don’t assume your inventory is correct. Don’t assume your IDS is working and don’t assuming your DDoS protection will work properly. Test these things, audit them and spot check them periodically. Risk doesn’t always have to move in one direction. Controls can regress, postures can change and threats are constantly evolving. Validate your results on a regular basis to make sure you are getting the most accurate picture possible.

So Can You Really Measure Risk?

I believe you can measure risk and develop an accurate risk profile for your company. Despite the subjective nature of risk, you can reach an objective result by using simply mathematical principles and by using an consistent objective process. When applying these methods to an industry standard control framework, you can obtain an objective result that will accurately measure your risk for a single decision, or an entire control framework. Once you have an accurate risk profile you can use the risk to make prioritized decisions to manage risk for your business.

Security Vendor Questionnaires: Too Much or Not Enough?

Over the past few years there has been an increasing trend for customers and partners to request security teams to fill out lengthy security questionnaires seeking specific details about the state of their security program. These requests often come as part of routine audits, regulatory requirements or contract negotiations. As someone who has both sent out questionnaires and been a recipient of questionnaires I’m wondering if the industry has gone too far down this trend or if it hasn’t gone far enough? Let me explain…

As a CSO, I want to discover and manage as much risk as possible. This includes conducting business with partners, customers and other companies. I want to understand my supply chain and limit my exposure to any of their security weaknesses that could be used to attack my company. However, I also want to limit the amount of information I disclose about my security program because once I disclose it, I no longer control that information and it could eventually make its way to an adversary if the company I disclosed it to has a breach.

How do we balance these differing requirements and are security questionnaires really the best mechanism for understanding your supply chain?

How Did We Get Here?

Let’s take a step back and consider how we collectively arrived at the need for security questionnaires. There have been several high profile breaches that have set us down this path. The first was the Target breach in 2013 where Target had their point of sale systems compromised as a result of a third party HVAC vendor. The magnitude of this breach along with the realization that Target was compromised via a third party placed a spotlight on supply chain security for the entire industry.

The second high profile breach was the Solar Winds attack in 2020. This attack infiltrated the software supply chain of Solar Winds and placed a backdoor in the product. Given that Solar Winds was used by a huge number of companies this effectively compromised the software supply chain of those companies as well. This attack increased the scrutiny on the supply chain with additional emphasis on software supply chain and even leading to some sectors (like the government) requiring disclosure of a Software Bill of Materials (SBOM).

Increased Regulatory Pressure

These notable attacks (among others) have lead to an increase in regulations that force companies to disclose details around security breaches, but also to invest appropriately in security programs. Despite these investments and disclosures, companies can still face steep fines and costly lawsuits for security breaches. New regulations such as the SEC Cyber Risk Management rules and recent White House Executive Orders on Improving Cybersecurity and establishing a National Cybersecurity Strategy have elevated awareness and focus on supply chain security to the national stage.

Cyber Insurance Isn’t Helping

As Cybersecurity insurance premiums become more and more expensive, companies will continue to look for ways to decrease the cost, while still maintaining coverage. One of the most effective ways to do this is to establish and document a mature security program that you review in detail with your insurer to explain your risks and how you are mitigating them with appropriate controls. Questionnaires are one part of a security program that can demonstrate how you are evaluating and managing supply chain risk and hopefully drive down your premiums (for now). The problem is this creates an incentive where it is everyone for themselves in an attempt to lower their own premiums.

Transparency Is Lacking

The biggest issue security questionnaires are attempting to address is lack of transparency into the details of the security programs. In general, large publicly traded companies (particular cloud companies) and security product companies tend to be more transparent about security because it is built into their brand as a selling point to attract customers. However, details about technologies, program structure, response times, etc. generally lack specificity (for good reason) and the security questionnaire is an attempt to uncover those details to understand what risks exist when entering into a relationship with another company.

You might argue that companies should simply be more transparent with details about their security program, but this is not the solution. Companies should cover high level details with some specificity to demonstrate they have a security program and how it is structured. However, giving specific details about processes, response times, technologies, etc. will reveal details that can be used by an adversary for an attack. Additionally, do we really know what is happening with all this data from security questionnaires? It may be protected under Non-Disclosure Agreements (NDAs) and confidentiality agreements, but that doesn’t prevent the data from being leaked via an unprotected S3 bucket. It is extremely difficult to change a security program quickly and so it may be in the best interest of the responding company to refuse to answer the questionnaire and instead have an undocumented conversation (depending on your level of paranoia).

Yet More Audit and Regulatory Pressure

On top of all these issues, there are still very real requirements to respond to audits, questions from regulators or to provide these responses to your customers and partners that operate in heavily regulated industries (finance, healthcare, government, etc.). Responding to the questionnaires still takes time and places a burden on your security team and still comes with the risk that the information could be involuntarily disclosed to an adversary.

What’s Really Going On Here?

Responding to regulatory and audit requirements aren’t new requirements for our industry and so answering security questionnaires has been the norm for quite some time. However, I think the use of the security questionnaire has been hijacked by the industry as a catch-all way to accomplish a few things with respect to security:

  1. Assert your security requirements over another company (may work for small companies if they can fund it, but generally doesn’t work for large companies with mature programs).
  2. Minimize risk of doing business with and potentially pass on liability to the recipient company. I.e. “We asked them if they did this thing, but we got breached because of them so they clearly didn’t do that thing so it is their fault.”
  3. Create negotiating points as part of contract negotiations for concessions.

The problem with these is they are attempting to impose a solution or liability on a program they don’t control. As a CSO I can’t agree to these things because being contractually obligated to a specific security solution or SLAs removes my decision making power for how to best manage that risk within my security program. Security programs change and are constantly adapting to stay ahead of threats and risks to the business. Being boxed into a solution contractually can actually create a risk, where there wouldn’t normally be one.

Fatigue Is Real

I genuinely struggle with this problem because security questionnaires have their uses, but are causing real fatigue across the industry. The questions fall into one of two categories: either they are largely the same across customers or they are completely bonkers and don’t justify a response. As both a sender and recipient of questionnaires I can definitely understand both sides of the issue. I want as much information about my supply chain customers, but want to minimize the specifics that I share outside of my control. I want lower cyber insurance premiums and I want to pass all my audits and regulatory inquiries. However, I think the industry has deviated from the original intent of the security questionnaire due to the real fear of being held liable for a failure in their security program, which includes their supply chain.