“We’ve essentially created a massive sandbox for cyber criminals to play in”

JAXenter: Hi, thanks for taking the time to answer my questions. Let’s talk about OWASP and its 20th anniversary. First of all, can you tell us a little bit about the OWASP Foundation?

Tim Jarrett: The OWASP Foundation is a consortium of security professionals and developers who work together on projects to improve application security for all. Over its history, the group has contributed both significant process guidance and research, like the OWASP Top 10 Web Vulnerability list, and code, including both sample vulnerable applications like OWASP Juice Shop and Webgoat and security tools like OWASP Zed Attack Proxy and ModSecurity Rules.

JAXenter: What role has it played in the importance of security allies in the DevOps process? And what role will it play in the future?

Tim Jarrett: The OWASP Foundation has come a long way in helping shape cooperation between security and development since its early days. At the beginning, I think it’s fair to say that OWASP was representative of the broader security community in its concern over software quality and tendency to “blame the developer.” There was a pivotal moment at the 2011 OWASP Summit where a speaker famously said, “Developers don’t know s#!+ about security!” and an attendee, John Willander promptly responded, “Well, I got news. You don’t know s#!+ about development.”

I think a lot has changed since then, most of it with the rise of DevSecOps. I think that there is now a common understanding that Security’s job is not to gate deploying code to production, but to help development teams deliver code faster, safely. The increased focus at OWASP on security tooling and automation, as well as modernizing teaching tools like OWASP Juice Shop, demonstrates the community’s commitment to helping development deliver software safely.

SEE ALSO: “The average downtime due to a ransomware attack is 21 days”

JAXenter: According to the OWASP Top 10, 94% of apps were tested for some form of broken access control. It moved forward in the rankings up to fifth place. What is the cause for its change in ranking?

Tim Jarrett: There were a few changes in this year’s OWASP Top 10 process that help to explain the change in ranking. Past years have heavily leveraged statistical data contributed by the community, including by Veracode, who donated anonymized data summaries from our ongoing State of Software Security project. This year’s data showed that this category was more prevalent across applications than any other.

There were additional methodology changes that also contributed. Before this year, the OWASP Top 10 project team asked data contributors to contribute prevalence data for a pre-selected set of finding types (CWEs). This year they asked for prevalence data across all CWEs, and got a bigger picture of all the types of weaknesses that were out there. In addition to prevalence, the other factors in the priority are exploitability and technical impact. In both these categories, Broken Access Control ranks very high, since without effective access controls, the application is wide open to attackers.

JAXenter: Between the SolarWinds attack, the T-Mobile hack, and the surge of ransomware attacks, 2020 and 2021 have seen upticks in security breaches. Is there any particular reason for this increase and will it get worse before it gets better?

Tim Jarrett: One simple but true answer to the question of why there are more security breaches was given by noted criminal Willie Sutton, who when asked why he robbed banks answered, “Because that’s where the money is.” With more than 50 percent of people worldwide now online, software and digital applications are growing exponentially to meet demand. The pandemic has certainly added to this as nearly every type of business has had to transform operations to enable remote work and digital services. Add to that the speed with which organizations are developing software and pushing out code, often at the expense of security, and we’ve essentially created a massive sandbox for cyber criminals to play in.

Other considerations include the evolving ransomware model and the rise of cryptocurrency which makes ransomware payments difficult to trace; and therefore harder to recover.

Practically speaking, it is likely to get worse before it gets better, but with more organizations and individuals becoming aware of the threat, we do believe there will be a marked shift in this fight in the coming years.

JAXenter: What are your thoughts on the recent executive order from President Biden regarding a software bill of materials? Is this enough action?

Tim Jarrett: First off, we applaud the executive order and its intention to increase oversight, regulations and standards for vendors providing software to the federal government. By holding these vendors to a higher standard, the White House is taking a stand and prioritizing software security.

With regard to the software bill of materials (SBOM), it’s a worthy effort and I do think it can help to address some of the biggest challenges in software application security, which is the lack of transparency into development practices making it impossible to know how secure – or insecure – the software is. For example, open source code is ubiquitous in modern software development. Yet, according to our own State of Software Security (SoSS) report, more than 70 percent of open source libraries contain security flaws, and often developers aren’t even aware of them.
Recent incidents like the SolarWinds breach demonstrate the malicious libraries in software and the need for greater transparency in the software supply chain. Yet, our most recent SoSS open source report found 79 percent of the time, developers never update third-party libraries after including them in a codebase, despite the fact that open source libraries are constantly evolving.

This points to the critical need for greater security in the development process, and that is the other important area of focus. On the purpose of providing an SBOM, the executive order states, “the development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.” This language certainly suggests there will be stricter guidelines for secure software development including comprehensive scanning and testing of software code. Our research proves organizations that implement application testing during the development process are able to find and fix vulnerabilities before they make it into production.

The federal government will not be the last decision makers to require more security transparency from software vendors. We believe it’s just a matter of time before the private sector follows suit. Moving forward, I expect to see even more strict protocols in the future, meaning anyone developing software should understand the executive order in detail and be prepared to follow even more strict regulations down the road.

JAXenter: Adobe Flash, infamous for its security risks, is officially retired and Internet Explorer is on its way out. Are there any current frequently-used software that you think is just as precarious to security that we should be pivoting away from soon?

Tim Jarrett: This is like asking me to pick among my children!

The problem with Flash and IE has always been their widespread use by end users and the age of their code bases. These days, rather than calling out a particular piece of software, I’d highlight web applications with poor authentication management practices. Applications that protect sensitive data that rely only on username and password need to change. And don’t get me started about the ones whose “forgotten password” workflow emails me my old password in cleartext.

SEE ALSO: What Pitfalls To Avoid In Digital Product Development

JAXenter: Finally, what cybersecurity tools do you think are an absolute necessity? What’s in your toolkit?

Tim Jarrett: The cybersecurity tools I believe are an absolute necessity for developers are static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA). SAST is a type of testing that allows developers to scan code for potential vulnerabilities that can be carried out manually or automatically. Its biggest strength is its speed and simplicity. DAST finds exploitations by using test attacks. DAST scanners do not operate within applications and its biggest strength is delivering real time results without access to source code. SCA evaluates the open source libraries used by an application and points out which have critical vulnerabilities; it also maintains an inventory so when new vulnerabilities are discovered you can prioritize a response.

While not a tool per se, penetration testing is a proven method used to pinpoint vulnerabilities in critical apps. Pen testers are often security experts acting like an attacker, so they will use popular hacking tools and techniques to access applications’ key data. The most reputable pen tests come from people outside of your own organization. Employing these tools and methods can help organizations meet the transparency and security requirements of the SBOM and related regulations.