Government agencies are rethinking the ways they approach risk management, especially when it comes to protecting the software supply chain.
As with cybersecurity mitigations and controls, cyber risks are typically introduced via three categories: people, processes, and technologies. Risks associated with people and technologies are well known and manifest as phishing emails, social engineering, or software vulnerabilities and the introduction of malicious code onto a system. But what about risks introduced by poor or incomplete processes – for example, a patch that is not implemented quickly enough, unpatched/vulnerable third party and/or open source software components, or insecure software development practices? More hackers are exploiting these backdoors to infiltrate software delivery supply chains.
Let’s take a deeper look at process risks.
Process Risks Open the Door for Attacks That Target Loopholes in Software Development and Delivery
Until recently process security focused on two things: IT processes, such as vulnerability management or applying patches to minimize windows of exposure, and secure software development practices. But we’ve recently seen a rise in newer attacks that take advantage of vulnerabilities in the software development and delivery lifecycle and require vendors to rethink this strategy.
Now, vendors must extend their focus on the entire software development lifecycle, including the build process itself – one of the very last stages of application development after coding, QA and testing. To deliver an update, software vendors will typically build their code, perform QA and some security testing, run it through the build process, load it onto update sites, and then push it out to customers. Traditionally, vendors have not looked very closely at the risk posed by this last stage of the software development lifecycle. As such, bad actors have taken advantage of this process vulnerability and, for example, have inserted malicious code right before files are signed and delivered to customers.
These types of infiltrations and the risks they introduce are very complex and can come from any number of software vendors as well as from custom-developed software and code coming from contractors. According to Bloomberg Government, the U.S. government spent $597 billion on contractors in 2019. The sheer size of the contractor landscape makes process risk much harder to identify and mitigate.
Software Vendors Are Focusing on Lifecycle Process Security Improvements
There are many places up and down the stack where better security controls, automation, and compliance checks could be implemented to help secure the development lifecycle, yet there is no one technology that can do this effectively. Technology can enable better processes, but to mitigate against potential threats additional steps and controls need to be put in place.
When working with software vendors, ensure they are focusing on the following key areas to address lifecycle vulnerabilities:
- Building security controls into the software: Implementing security controls directly into the software is a foundational mitigation for securing applications against future threats. Input validation, output sanitation, development language specific secure coding practices and least privilege-based modularization are just a few of the examples of best practices for secure code development.
- Automating checkpoints throughout the software lifecycle: Look for vendors who are putting in automated checks throughout the process, not just at the beginning or the very end, to mitigate the impact of infrastructure attacks. For example, vendors should check files during the final build process against the audit trail from the build server to identify any differences.
- Securing the development cycle infrastructure: Each piece of the development cycle infrastructure is critical and must be protected. Secure boot and strong access control procedures with audit and verification for privileges can go a long way toward limiting threat opportunities.
- Controlling network access: At some point bad actors will gain access to even the most secure networks. The key is being able to segregate their activity and limit their ability to execute an attack. Network enclaves – separate networks that make it harder to jump between networks (e.g., from the human resources network to the one the developers use) – can limit exposure. Some organizations even employ an air gap style network in the very final stages of software delivery to ensure the finished product is physically separated from other networks.
- Protecting the build server: Build servers present exposure points that need to be locked down. Smart vendors strictly control access and privileges. They also keep a detailed audit trail of every entity that logs on or off the system as well as what they did on the server.
Implementing and integrating security development best practices and methodologies throughout the software development and deployment process (also known as SecDevOps) is now a necessary best practice.
These steps are essential to vetting potential vendors and securing Department of Defense and Department of Homeland Security supply chains, but they are just the beginning. Maintaining good security is an ongoing process. Agencies must continually evaluate vendors and make sure changes in ownership are investigated to ensure bad actors have not bought their way into the supply chain process.
They should also re-evaluate current suppliers by asking them to prove that they are taking software supply chain security seriously. Ask them to verify and provide evidence that they have good security processes in place. Only by continuously analyzing the entire supply chain can agencies hope to mitigate the impact of process attacks.
The views expressed here are the writer’s and are not necessarily endorsed by Homeland Security Today, which welcomes a broad range of viewpoints in support of securing our homeland. To submit a piece for consideration, email email@example.com. Our editorial guidelines can be found here.