Foundational Activities for Secure Software Development
Follies
The Broadway Tower in Worcestershire, England is a famous structure. It’s inspiring, beautiful, and at 62 feet high, like other similar buildings, it’s a folly. While it looks grand inside and out, it serves no purpose than to be a decoration.
It’s all too easy to buy a set of policies and procedures, change the company name and some other details, then present it as an application development and security program. Regrettably, there are too many companies whose appsec program has quickly become a folly.
How can we avoid this trap?
Some Considerations
Akamai’s State of the Internet Report demonstrates that the growth of the gaming industry creates “an expanded attack surface for threat actors to exploit by using everything from DDoS to SQL Injection (SQLi) attacks.”
It’s not an exaggeration that APIs – whether monolith or microservices – account for 80+% of internet traffic, or that this increase has presented a treasure trove of targets for criminals.
As we learned from the MailChimp breach, API keys are a target. Criminals aren’t always simply after the money – they are looking for ways to achieve Account Take over (ATO), and that includes initial entry, followed by accessing credentials or API keys.
According to the “Cloud and Web Security Challenges in 2022” report from the Cloud Security Alliance (CSA), 47% of businesses are concerned about sensitive data loss, and 43% of businesses have customer data protection as one of their 2022 primary cloud and web security objectives.
Businesses and customers have a vested interest in secure software.
Some Problems
According to the 2021 IBM Security X-Force Cloud Threat Landscape Report, “Public API policies represented a significant security gap. Two-thirds of the incidents analyzed involved improperly configured Application Programming Interface (APIs), based on analysis of X-Force Incident Response data of impacted clients.”
The pressure on getting things done faster is at an all-time high. Stress testing, consolidated and condensed development need, faster fixes, first-to-market – the increased and sometimes competing needs of the business units creates higher stress on developers and producers.
The State of Software Security report found that fewer than 5 percent of apps use multiple languages. This 75 percent decrease (since 2018) suggests a move to smaller, single-language applications or microservices. While this can ease vendor sprawl, it also creates vulnerabilities because of the need for threat actors to only compromise a few sources.
A lack of comprehensive, cohesive, and coherent technologies presents obstacles for technology interoperability and interdepartmental cooperation.
The lack of any form of written guidance creates enormous problems for software currency and development succession. The future of proper software development hinges on documentation. Ask auditors and they’ll say, “If it isn’t written, it doesn’t exist.”
Some Solutions
What actions need to be taken to secure software? There’s no one-list-to-rule-them-all, but here are foundational (not basic – basic makes it sound easy!) activities that everyone needs to have in place.
- Leadership
- When everyone is responsible, no one is. While not discounting other stakeholders, someone must be the final arbiter of software direction (and be in the lead for remediations).
- This person is also responsible for developing and maintaining confidence in the tools used to bring about all the requisite changes and advancements according to business goals, policies, and vision.
- SDLC
- The Software Development Life Cycle (SDLC, or SDL) is a foundational document that should be designed by those who know what goes into proper development, providing guidance and direction for the proper flow of software development, and including all the aspects of development (e.g., QA, Shift Left and clean code references, vulnerability assessments, testing and prod environments, regression testing, steps where security of some sort is involved).
- The SDLC won’t contain everything (e.g., API documentation), but references to corollary files need to be included.
- Inventory
- Monolith and/or microservices? Do you know where your APIs are? Is anything out-of-date? It can’t be protected if it’s unknown. This includes a Software Bill of Materials (SBOM).
- For a recent example of the need for updating libraries, see the crpytomining infiltration of over 200 PyPi and npm packages.
- Follow compliance and regulatory requirements
- Even if a company or its industry is not regulated, its software will most certainly operate in a state or country that is regulated (e.g., CPRA, TX-RAMP), and the software needs to be designed accordingly.
Remaining secure requires the Shift Left concept, extending – not simply moving – secure testing further to the left of the design phase.
About the Author: Ross Moore is the Cyber Security Support Analyst with Passageways. He was Co-lead on SOC 2 Type 1 implementation and Lead on SOC 2 Type 2 implementation, facilitated the company’s BCP/DR TTX, and is a HIPAA Security Officer. Over the course of his 20 year IT career, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2’s SSCP and CompTIA’s Security + certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
The post ” Foundational Activities for Secure Software Development” appeared first on TripWire