The world witnessed the chaos created by the Solar Winds attacks that was traced back to a hack on Solar Winds’ core IT management software.
Apart from Solar Winds, other major attacks included Kaseya, Codecov and Log4j. In each scenario, the attacker looked to compromise or exploit the vulnerability in distributed code leading to hundreds of victims.
A software supply chain attack happens when hackers manipulate the code in third party software components in order to compromise the ‘downstream’ applications.
According to a recent study by Venafi, 87% of CIOs believe software engineers and developers compromise on security policies and controls in order to get new products and services to market faster.
And 82% of CIOs state that their organizations are vulnerable to cyberattacks targeting software supply chains, and they need to bolster security of software development.
The study which reached out to 1,000 CIOs globally found that the shift to cloud native development, along with the increased speed in development brought about by the adoption of DevOps processes, has made the challenges connected with securing software supply chains infinitely more complex.
Other findings from Venafi research:
85% of CIOs have been specifically instructed by the board or CEO to improve the security of software build and distribution environments.
84% say the budget dedicated to the security of software development environments has increased over the past year.
61% of organization gave oversight and ownership rules to InfoSec Teams for software development and this resulted in lesser insights to approach the problem.
95% of InfoSec teams have authority over what security controls should be used to protect software supply chains. At the same time nearly a third of InfoSec teams cannot enforce the policies they recommend.
Here’s what CISOs say on securing supply chain:
Saurabh Gugnani, Head IT & Security, Peoples Strong Technology:
Organizations must be able to take multiple levels of risk mitigation procedures to protect the code, as well as the applications. Security in software supply chain should be created in a phased manner as below:
For Software environments testing, quality assurance, and user acceptance testing is a must. Live production data in development, testing and quality assurance should be avoided. Isolation from Internet and event logging is necessary. Source code version control, removal of administrative privileges and preference be given to using only company-owned systems.
Configuration Management will help capture actual changes to the software code, end-user documentation, operations documentation, developer tools and settings, program build tools and settings, disaster recovery planning documentation, and other details of the change.
A centralized code repository helps in managing changes and tracking when and where revisions to the code have been done.
This repository can also track versions of an application so that application can easily roll back to a previous version if a new version is not compatible.
Security of Code Repositories: Code repositories primarily act as a central storage point for developers to place their source code. Source code must be protected from both unauthorized access and unauthorized changes. Only authorized personnel should have administrative access to the source code repository software.
Intruders must be kept out of the OS itself. All check-ins should require approval of another person. Only authorized developers and any other personnel should have access to source code. Limited, controlled checkout: Developers should only be able to check out modules when specifically authorized.
Kevin E. Greene, Security Strategist, CyberRes Federal:
As attackers shift their techniques left to disrupt supply chains, organizations must codify threat intelligence into the software construction process to inform about potential threats and risks to software.
This will help improve the overall design and implementation of security controls to absorb software supply chain attacks and compromises to build and CI/CD environments which impact software deployment and delivery. In an ideal world, every piece of software borrowed and used in software construction would have a threat intel summary that identifies and informs about software risk.
This means that current state-of-the-art tool must do more than just tally Common Vulnerability Exposures (CVEs), because all software have vulnerabilities… tools must provide relevant context about the behaviour of software and model the overall hygiene of that software. This will help organizations make well-informed decisions about what software to use and avoid in software construction. Organizations must realize the more code and software they borrow and use, the more risk they take on — knowingly or unknowingly…
Sameer Anja, Cofounder, Arrka :
The crux is both security and software engineering are exclusive, and need to interface with each other. However, security or for that matter privacy by itself cannot lead the software engineering chain. To enable this interface, we need to peel off the various layers in software engineering and enable it so that the development time is not impacted.
Today, the world relies on software security testing (known usually as threat hunting/ red teaming/ VAPT exercises) to get to vulnerabilities. This creates an environment where security teams look at the various vulnerabilities and ask the development teams to fix them. Sometimes this impacts the development team and increases the time to fix vulnerabilities, since most of the time is lost in understanding the vulnerability and many times it gives rise to repeat vulnerabilities.
We need to create libraries which are secure by design and also enables privacy by design. Such libraries can also be created as APIs and parsers and all data coming in can be parsed through it can be rendered as safety and privacy-aware data.
Over this layer, the various facets of IAM, Logging, SIEM etc. should be enabled to create a more secure and stronger layer.
There is also a requirement of security-aware and privacy-aware software engineers and being a niche area, many software engineers who are going this route can possess appropriate skills to secure the software supply chain and make this secure.
In summary, building security and privacy enabling libraries, embedding these into code and testing plans is a good first step. Then enable IAM, Logging etc to build the perimeter blocks and also control access to code from internal plus external developers as well. Thirdly, start training developers in security; they will aid a lot and interface better with security teams to build a more secure software.
Lucius Lobo, CISO, Tech Mahindra:
Informed security has to be built into the development process using automation and tools. This will ensure that security elements are never missed.
The second most crucial piece is training of software engineers for a secure product. We must further ensure that the development environment is tamperproof and the code is resistant to tampering.
(Image Courtesy: www.portswigger.net)