Overrated? On TPRM, SBOM, Solarwinds, and Supply Chain Security

We've all run to the same side of the boat on supply chain security when it comes to cyber. Rather than chasing the Sisyphean (and antithetical to modern product-development philosophy) task of ensuring our suppliers deliver perfectly secure software, we should be expected to architect and deploy our dependencies with the assumption they will be compromised at some point, minimizing the amount of impact that could have and ensuring we could detect such an issue timely.

To expound on it, I'll say the reaction to the Solarwinds incident has been unfortunate - and largely driven by the people with the largest microphones selling a solution. Organizations who deployed Solarwinds in a prudent architecture were able to sleep at night when news of that breach broke. The same is true of the Log4j vulnerabilities, Struts, and countless other fire drills over the past 25 years. The amount of effort it takes to deploy solutions in a safe architecture, while not trivial, pales in comparison to the amount of resource we collectively devote to assailing vendors with increasingly arduous - but always ineffective - questionnaires, algorithmic predictions, and contractual acrobatics. In short, the reaction to the Solarwinds breach was "I KNEW we should have given them a longer questionnaire, required an SBOM, and increased their limits of liability" instead of "I can't believe we installed Solarwinds in our production datacenter with unfettered internet access and lateral access to our Active Directory domain". Solving the latter problem will protect an organization from hundreds of vulnerabilities and has worked for 25 years; the former will accomplish nothing. The problem is that nobody is selling the latter. Actual security practitioners are encouraged to stay out of the spotlight and keep their learnings quiet, while commercial solutions have the opposite incentive.

One of several ironic bits about how this has played out is that companies have been examined and questioned on adherence to strong architectural principles for years. Many of us have diligenced, acquired, and partnered with many companies who claimed to enforce default-deny and zero-trust principles and - if questioned specifically - would claim that production datacenter equipment does not receive unlimited Internet access by default. Yet the same enterprise ecosystems almost universally require all-hands panicked weekend efforts while suffering active breaches every time those principles are called into question by another 0-day vulnerability. Someone isn't telling the truth - or perhaps properly understanding the question - when asked about their architectural strategy.

Have a production support engineer grab a console session on a server running a vendor package. Run a dig or nslookup on yandex.ru. If it returns a legitimate IP address, you have a game-stopping issue that can be solved in a few weeks with a few key engineers. Deploying the fix universally is worth 10x in TPRM efforts - but will anyone do it? Take it a step further: If running a curl or wget capture of the yandex.ru home page is successful, you are wide open to command & control, data exfiltration, and so much more. Switch to default deny, kill recursive DNS lookups, and go back to bed. Nothing to buy.

Or, I suppose, you can send the vendors longer questionnaires, have the CEOs sign unbacked promises about security, and hit the refresh button on LinkedIn all day waiting for the next 0-day to be announced.