Following the Solarwinds supply chain attack, the Monetary Authority of Singapore (MAS) revised its Technology Risk Management (TRM) Guidelines, which required all financial institutions to assess the suppliers of their technology vendors. The guidelines apply to banks, payment services, brokerage and insurance firms.
The attack has raised a sobering flag on the security of software development, deployment, and use, particularly in the era of DevOps and cloud-native applications in enterprises. MAS acknowledged that financial institutions are increasingly reliant on third-party service providers as they adopt new technologies and greater stringency was necessary to manage risk and security controls. The revised TRM guidelines were expanded to cover risks through the use of open application programming interface (API).
There is a need for fintech companies to shore up their defences and prioritise security, especially in an environment where software is developed faster, released more often, and uses tools that have been beyond the radar of the security team.
Beyond compliance, financial institutions need to protect themselves by practicing good cyber hygiene, strengthening risk management strategies with third-party vendors, and implementing DevSecOps.
The following three approaches are great places for DevOps teams of all sizes to start.
1. Maintain visibility at all times
DevOps teams should maintain dependency visibility to ensure everybody developing software understands its dependencies, especially any dependent elements not within a given team’s immediate control. Before moving forward with software reliant on dependencies, teams should understand its portability, the frequency it receives updates, and its compatibility with other platforms. But most importantly, teams need an understanding of a dependency’s specific security posture, otherwise they risk releasing software with exploitable vulnerabilities.
2. Assign a build monitor
A key method of guarding against supply chain attacks is securing build processes. To start, teams should assign a build monitor. This way, as teams undergo the build, one member will be monitoring the build process with a keen eye for any anomalies, unauthorised code changes, and other signs of suspicious activity. Other ways to ensure a secure build as the process progresses include:
- Leveraging CI/CD pipelines to integrate automatic SAST and DAST tests into the development process
- Having developers complete vulnerability and dependency scanning
- Implementing new AI/ML tools to support scanning, monitoring, and reviews
3. Don’t be hush-hush about secrets management
Teams working with usernames and passwords, API tokens, SSH keys, encryption keys, and other sensitive authentication information within applications should invest in secrets management solutions.
With cloud-native development models on the rise in the industry, it can be difficult to account for secrets spread across multiple infrastructures, and this may leave DevOps teams vulnerable to security blind spots. The implications of a security breach is staggering – Ponemon Institute’s Cost of a Data Breach Report 2020 found that the global average total cost of a data breach for an organisation is about US$3.86M dollars.
Third-party code is here to stay
The updated guidelines mandate more comprehensive risk management processes by assessing the risks their vendors present based on the software dependency the vendor provides. This way, risk management program tiers are predicated by necessity to the software’s security.
A tiered approach not only sifts through risk assessments requests for overwhelmed security teams, but also establishes priority for any vendors that need more attention beyond standard risk assessments. Once a vendor tier is established, financial institutions can make better decisions on the use of a third party based on their ability to meet more stringent security requirements.
Enterprises should also begin to ingest more data from their vendors as a means to increase inter-operational transparency and accountability. Vendors and enterprises working together should be more transparent with their information to ensure that sensitive data, such as secrets or personal identifiable information, is not stored somewhere unprotected and unaccounted for.
Put the ‘sec’ in ‘DevSecOps’
As financial institutions continue to move to the cloud, it’s becoming increasingly apparent they should be integrating DevSecOps into their cloud infrastructure, especially in the wake of some recent, newsworthy breaches. One of the biggest barriers to effective software supply chain security is go-to-market speed. Business growth requires fast releases and scanning and code tests can slow down development.
While initial implementation of DevSecOps programs may create challenges for security teams prioritizing security and IT teams focused on moving the release out, industry research suggests DevSecOps integration and fast releases are a growing reality. GitLab’s annual industry survey, the 2021 DevSecOps Report, found that even though 84% of developers said they’re releasing code faster than ever before, 70% of security professionals report their teams have moved security considerations earlier into the development lifecycle.
This is not only a good indicator of industry security improvement, but good news for teams prioritising software supply chain security. By prioritising security during development, teams can catch and address the vulnerabilities exploited in supply chain attacks so you won’t end up responsible for the next breaking-news breach.
Get proactive
Software supply chain security has long been treated with reactive measures. While the scope of the SolarWinds hack may make supply chain security appear like a Herculean task for any security team, an intuitive risk-based approach makes it manageable.
Adopting proactive security measures, such as creating secure builds, practicing more comprehensive vendor risk management, and implementing DevSecOps will lead to a more effective and secure enterprise.
