Cyberattacks come in many different forms, which the industry describes using tactics, techniques and procedures (TTP) to differentiate each type of attack. But there is one common component in each cyberattack, software, in some form, performs a role in the attack. This article asserts that a party can prevent a cyberattack if the software used in the attack can be prevented from running. This requires the ability for a software consumer to identify software objects that are used in TTP’s that can cause harm and prevent these software objects from being installed and exploited in a digital ecosystem. That’s easy, right?
There is one big problem, software can be quite elusive and software vulnerabilities that are exploitable can be difficult to identify, i.e. zero-day attacks. Even items that do not appear to be “software” can contain some executable code, i.e. MS Word documents with VBA macros. Sometimes an artifact can be used to cause a piece of software that processes the artifact to fail in such a way as to cause harm, i.e. some PDF exploits are good examples of this. The many ways in which software can be used to carry out a cyber-attack make it hard to identify each possible threat that software can introduce. There is no silver bullet method to guarantee that all harmful software scenarios can be identified before it is used in a cyber-attack. But there are some measures a party can take to prevent some cyber-attacks from succeeding.
Just like there is no “one pill” that can prevent all human health problems from occurring there is no “one pill” to prevent all cyber-attacks from succeeding. Each problem must be addressed independently using proven methods in both the healthcare and cyber-attack scenarios. This article uses the analogy of a dangerous health concern, i.e., people with a peanut allergy, to correlate an equivalent scenario using cybersecurity risks from software.
People with a severe peanut allergy understand the real risks of dangerous health reactions that can result in death when peanuts are consumed. Great care is taken to examine each product for the presence of peanuts before purchasing or consuming a product, in order to avoid any dangerous reactions. Now, thanks to the adoption of “Software Bill of Materials” (SBOM) standards software consumers can exercise the same level of due diligence to prevent a cyber-attack, before procuring or installing a software product. Guidance on how to conduct software risk assessments is provided by the National Institute of Standards and Technology (NIST) in Special Publication 800-161, Appendix F, which identifies the following, high-level steps to identify software risk and prevent harmful software from being procured and installed by a software consumer.
Some SP 800-161 High-Level Activities to Consider:
- Include all applicable minimum software verification techniques into a supplier’s “requirements for functional properties, configuration, and implementation information, as well as any development methods, techniques, or practices which may be relevant”
- Ensure minimum software verification techniques and results are documented alongside a supplier’s “cyber-supply chain threats, vulnerabilities, and associated risks”
- Mandate supplier “developer configuration management activities” incorporates checking included software for known vulnerabilities and application of remediations and/or compensating controls to resolve or mitigate identified vulnerabilities.
- Enhance “threat modelling and vulnerability analysis” activities to include the minimum software verification techniques, where applicable
- Incorporate automated testing, built-in checks, and address included code (libraries, packages, services) verification techniques to proactively identify unsupported systems or system subcomponents
- Augment “tamper resistance and detection control” to include a supplier’s minimum software verification techniques
- Use automated scanning and check included software techniques to continuously monitor “configuration control for component service and repair” activities as well as “anti-counterfeit scanning”
- Verify Software, Firmware, and Information Integrity
- Ensure SBOMs conform to industry standards formats to enable automated ingestions and monitoring of versions. Acceptable standard formats currently include SPDX, Cyclone DX, and SWID
- Maintain readily accessible SBOM repositories
- Integrate vulnerability detection with SBOM repositories to enable automated alerting of any cybersecurity risk in the supply chain
- Develop risk monitoring and scoring components to dynamically monitor the impact of SBOMs’ vulnerability disclosures to the acquiring organization. Align with asset inventories for further risk exposure and criticality calculations
- Require vendors to describe and, at a minimum, self-attest to their commitment and capabilities for securing software throughout the SDLC
- Preference or mandate the use of suppliers that provide a software security label or data sheet which should include information about the software itself, the tools and technologies used to build the software, security tools and processes governing the software, and the people involved in building the software for all provided products
- Automatically verify hashes/signatures infrastructure for all vendor-supplied software installation and updates
- Integrate SBOMs, vulnerability databases, and reporting mechanisms to ensure departments and agencies rapidly receive notification of recently released vulnerabilities