Supply chain attacks like the FireEye and SolarWinds breaches demonstrate why the weak link in your security might lie with third-party software partners and suppliers.
This is not an attempt to exploit the misfortune of others during this breach, rather, to help Business, IT, & Security teams start the necessary conversation about the current understanding gaps between reactive cybersecurity, proactive risk management, and DevSecOps.
*Post updated 1/5/2021.
Cyber community coming to terms with a proactive reality
We agree with distinguished computer science research professor and CEO of Tag Cyber, Edward Amoroso's "How Do We Tell Cyber Security Truths That Might Hurt?" post,
and reference of Edgser Dijkstra's iconic essay, both scolding the community for choosing to ignore several obvious facts. And while Edward's truths may hurt, and no cyber vendor could have "stopped" the attack, we believe there are fundamental visibility and control mechanisms missing in most environments. Those of which could have empowered humans to mitigate the risks earlier to at least stop some of the spread.
Adding to the uncomfortable truths:
12 - Software engineering has so much autonomy it remains to be The Wild West. Much of the security architectures built for traditional IT still used today is a false sense of security against unchecked software and processes. Frankly, the tail is wagging the dog.
13 - Application Portfolio Change Risk Management – the more a company can tell about their applications, the supporting infrastructure, and their contextualized risk status of each, the better their security is, and the more comprehensive and real-time their risk operations, and the more mature they are.
14 - Buying the next shiny cyber tool does not replace the need to structurally and systematically change to empower people. People require the right insights at the right time, not only for IT Security, but for Leaders across DevOps and the Business as well.
15 - Ignoring the chance to wrangle your own internal complexity and technical debt, including all third-party and open source software, whether built internally or externally, is risking the entire system, adding to your funding and staffing challenges.
17 - You have poor and/or obsolete corporate governance practices for people, tools, and controls deployment/configuration in the realm of IT accountability that cannot keep up with the rate and speed of a constantly changing environment.
18 - The "trust, not verify" approach to security is just as pointless as the point-in-time assessments we keep using for compliance audits and cybersecurity questionnaires.
20 - Tackling these specific challenges requires a purpose-built, comprehensive platform approach, not more point solutions or general BI tools. This would require automatic and continuous inspection, monitoring, and data science automation within updates in the CI/CD process for signs of tampering, supply chain compromise, or malicious intent as part of their risk management architecture.
While some say there is little FireEye could have done, we believe this provides sufficient evidence for proactive approaches to reduce the size, complexity, scale, and scope of the software we are dependent on. This is a multifaceted problem, one that equally affects those that build/maintain software and those that consume it.
What if...
- Defining what "security-maturity" meant was updated. If software organizations had better DevSecOps practices and risk performance insight from code-to-cloud...could they have received notifications for tampering, malicious intent, or any unwanted additions that conflict with acceptable security policies? Could that have kicked off appropriate (and early) inspection to prevent a breach before it happened?
- Transparency with customers changed.
Perhaps all customers of software organizations could see how they, as vendors, were performing in managing their own risks—continuously. For example, taking the appropriate steps to investigate code or certificates after being publicly exposed...could their customers proactively isolate and/or disconnect the third-party software risk from their environments to avoid or prevent the sprawl of these threats?
- Product security could be simplified.
Complexity can be wrangled across every team microculture with instant visibility into contextual risks...could software business leaders understand where to spend dollars and allocate time?
If security remains stuck in this reactive state, where mainly checkbox compliance has ruled risk programs, it will be a missed opportunity to move into proactive risk management approaches.
Compliance-centric cybersecurity and DevSecOps
We have received questions if compliance mandates specifically call out this threat. While there are broad mandates to AppSec controls, code reviews, vulnerability scans, etc., supply chain compromise is tough to detect. Unfortunately, as we have seen with this attack, this is where lax security, silos, and 'point solutions' become problematic.
In the next post of this series, we lay out specific scenarios to monitor for from a proactive application and product portfolio risk governance perspective. To detect attacks like these, Gartner recommends ‘PatformOps.’ An agile, purpose-built solution to complete the promise of secure DevOps with continuous monitoring for the effectiveness of operationalized controls. From a risk management perspective, PlatformOps is preventative and incorporates concepts from several approaches and other automated capabilities.