Cybersecurity In-Depth: Feature articles on security strategy, latest trends, and people to know.
SQL injection and its ilk will stop being "a thing" only after organizations focus on security by construction.
August 29, 2023
In late 1998, when I was just beginning my career in technology, I read in the venerable Phrack magazine how poor input sanitization allowed rain.forest.puppy (the pseudonym used by Jeff Forristal) to pass SQL query strings directly to the back-end database of a Web application.
It's an unfortunate reality that a quarter of a century later, SQL injection — among the lowest hanging of security fruit — is still included in the Open Worldwide Application Security Project (OWASP) Top 10 list of security vulnerabilities. One of the worst attacks ever occurred back in 2008, when Heartland Payment Systems was breached and more than 130 million credit and debit card numbers were compromised. In 2023, the Cl0p ransomware group exploited previously unknown SQL injection vulnerabilities in MOVEit, Progress Software's file transfer program, and compromised hundreds of victims as part of a supply chain attack.
We do not have insight into Progress Software's software development life cycle or security practices to ascertain what happened. While a vulnerability assessment system or even a bug hunting program could have potentially identified SQL injection flaws in the code before it was exploited, focusing on producing code that is secure by construction is an even better way to address this class of vulnerability.
Methods include using stored procedures instead of directly passing SQL queries and incorporating software libraries to sanitize input. This ensures that the code produced is secure by construction and doesn't require teams to employ quality control or bug hunts afterward, both of which can be expensive and error-prone.
"Secure by construction" is really the key here, and that requires education — for both developers and security teams. We often talk about "shifting left," and the furthest left you can shift is to education (such as OpenSSF's Secure Software Development Fundamentals Courses). Had developers used stored procedures and consistent input sanitization across the code base, MOVEit could have structurally avoided this exploit. Security must be embedded within the software development life cycle (SDLC) as an integrated part of code quality, not just as a checkpoint or an SDLC gate before release.
Accurately identifying security defects early allows developers to address them systemically. In production, ensuring good operational practices, such as continuous repaving through infrastructure as code, least privilege execution, sandboxing, and domain isolation, can help ensure that threat groups do not gain persistent access to exploited services.
Most developers know what to do but weigh speed over security. Education, therefore, must include the value of secure coding practices and the exponential costs of ignoring those practices. However, this education will be effective only if developers feel supported in taking the time needed to code securely. If developers are being told to code securely but the organizational culture is implicitly or explicitly penalizing them for being "slow," they will most assuredly drop back to insecure ways.
Education doesn't just go one way. Security teams providing developers with vulnerability information with little context complicates matters. This information, often delivered as a report that must be remediated at a checkpoint late in the software development life cycle, impedes developer velocity as they sift valid findings from false positives. Educating security teams to be better software engineers can help reduce the toil of unactionable security reports and help software engineers produce better code.
The MOVEit vulnerability illustrates how critical it is for every organization to understand the software supply chain. Accurate asset inventories of software and infrastructure are prerequisites for companies to respond to cybersecurity events, before they become breaches; that's why the OpenSSF SBOM Everywhere SIG exists.
Of course, there are no silver bullets, and the complexity of the software supply chain almost guarantees that more incidents will occur in the future. Companies must have a well-practiced incident response plan in place that will help ensure that security and engineering teams are prepared to address issues through well-known runbooks and procedures, rather than panic and intuition.
Indeed, while our ability to respond to security issues has become a lot better over the years, the reports of panicked responses to MOVEit are evidence that we still have a long way to go. Engineering teams and security teams need to be more practiced in their response to security incidents. This means documenting runbooks and practicing them regularly through tabletop exercises. After an incident — whether real or practice — organizations should develop a "hot wash," or after-action report, to identify areas for improvement and ensure better execution during the next incident.
Finally, good security is a team sport, accomplished through multidisciplinary teams with diverse backgrounds and points of view. We cannot solve our issues through the homogenous thinking that caused them; diversity of thought is critical.
My hope is that if someone comes across this article in 2033, they will say, "Thank goodness companies got their security acts together," and not, "How is SQL injection still a problem today?"
Omkhar Arasaratnam
General Manager, Open Source Security Foundation (OpenSSF)
Omkhar Arasaratnam is the General Manager of the Open Source Security Foundation (OpenSSF). He is a veteran cybersecurity and technical risk management executive with more than 25 years of experience leading global organizations. Omkhar began his career as a strong supporter of open source software as a PPC64 maintainer for Gentoo and contributor to the Linux kernel, and that enthusiasm for OSS continues today. Before joining the OpenSSF, he led security and engineering organizations at financial and technology institutions, such as Google, JPMorgan Chase, Credit Suisse, Deutsche Bank, TD Bank Group, and IBM. As a seasoned technology leader, he has revolutionized the effectiveness of secure software engineering, compliance, and cybersecurity controls. He is also an accomplished author and has led contributions to many international standards. Omkhar is also a NYU Cyber Fellow Advisory Council member and a Senior Fellow with the NYU Center for Cybersecurity. (Mastodon: @[email protected]; Bluesky: @Omhkar.net)
You May Also Like
Hacking Your Digital Identity: How Cybercriminals Can and Will Get Around Your Authentication Methods
Modern Supply Chain Security: Integrated, Interconnected, and Context-Driven
How to Combat the Latest Cloud Security Threats
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and Phishing
SecOps & DevSecOps in the Cloud
Black Hat Asia – April 16-19 – Learn More
Black Hat Spring Trainings – March 12-15 – Learn More
Cybersecurity Outlook 2024 – A Dark Reading December 14 Event
Cyber Resiliency 2023: How to Keep IT Operations Running, No Matter What
Copyright © 2023 Informa PLC Informa UK Limited is a company registered in England and Wales with company number 1072954 whose registered office is 5 Howick Place, London, SW1P 1WG.