With more and more development teams today using open source and third-party components to build their applications, the biggest area of concern for security teams has become the API. Vulnerabilities are likely to appear here because the update of those interfaces has been delayed.
In a recent survey, research firm Forrester asked security decision makers at which stage of the application lifecycle they plan to adopt the following technologies. Static Application Security Testing (SAST) was 34%, Software Composition Analysis (SCA) was 37%, Dynamic Application Security Testing (DAST) was 50%, and Interactive Application Security Testing (IAST) was 40%. Janet Worthington, a senior analyst at Forrester who advises security and risk professionals, said the number of people planning to adopt SAST is low because it is already well known and people have already implemented the practices and tools.
One driver of that acceptance was the wake-up call created by the log4j vulnerability, where, she said, open-source developers understand direct dependencies but may not consider dependencies of dependencies.
Open source and SCA
According to Forrester research, 53% of external attack breaches are attributed to the application and application layer. Worthington explained that while organizations are implementing SAST, DAST and SCA, they are not implementing it for all of their applications. “When we look at different tools like SAST and SCA, for example, we see that more and more people are actually doing software composition analysis on their consumer-facing applications,” she said. “And SAST is coming too, but almost 75% of respondents we asked use SCA on all their external applications, and that, if you can believe it, is much higher than web application firewalls and WAFs are actually there to protect all your web-facing applications users. Less than 40% of respondents will say they cover all their applications.”
Worthington went on to say that more organizations are seeing the need to analyze the composition of software because of these breaches, but added that the problem with security testing today is that some of the older tools make it difficult to integrate early in the development lifecycle. This is the time when developers write their code, commit code to the CI/CD pipeline, and to merge requests. “The reason we’re seeing more and more SCA and SAST tools is because developers get instant feedback, hey, there’s something wrong with the code you just checked in. It’s still going to be in the context of what they’re thinking before they move on to the next sprint. And it’s the best place to kind of give them that feedback.”
RELATED CONTENT: Guide to Security Testing Tools
The best tools, she said, not only do that, but provide very good guidelines for remediation. “What I mean by that is they provide code examples, to say, ‘Hey, somebody found something similar to what you’re trying to do. Do you want to fix it this way?’”
Rob Cuddy, executive director of customer experience at HCL Software, said the company is seeing an uptick in remediation. Engineers, he said, say, “‘I can find things really well, but I don’t know how to fix it.’ So help me with that.’ I think auto restoration is going to be something that will continue to grow.”
Securing the API
When asked what respondents planned to use during the development phase, Worthington said, 50% said they planned to implement DAST in development. “Five years ago you wouldn’t have seen that, and what this really brings attention to is API security,” Worthington said. “[That is] something that everyone is trying to figure out in terms of the APIs they have, the inventory, what APIs are managed and what APIs are provisioned in production.”
And now, she added, people are putting more emphasis on trying to understand what APIs have and what vulnerabilities might exist in them, during the pre-release or pre-production phase. DAST in development signals an API security approach, she said, because “as you develop, you develop the API first before you develop your web application.” Forrester, she said, sees this as an indication that companies are embracing DevSecOps and want to test those APIs early in the development cycle.
API security also plays a role in software supply chain security, with IAST playing an increasing role and also encompassing parts of SCA, according to Colin Bell, AppScan CTO at HCL Software. “Supply chain is more of a process than necessarily any product feature,” Bell said. “The products are invested in it. So SAST, DAST and IAST are entering the software supply chain, but we’re working together on that, and maybe even looking for partners to help.”
Forrester’s Worthington explained that DAST is essentially black-box testing, meaning it doesn’t have any insight into the application. “Usually you have to have a version of your web application running, and it’s sending HTTP requests to try to simulate an attacker,” she said. “Now we’re seeing more testing tools aimed at developers who don’t actually need to access the web application, they can hit the APIs. And that’s where you’re going to secure things now – at the API level.”
The way it works, she said, is that you use your own functional tests that you use for quality assurance, like smoke tests and automated functional tests. And what IAST does is it looks at everything the application does and tries to find out if there are any vulnerable code paths.
Introducing artificial intelligence to security
Cuddy and Bell said they are seeing more organizations incorporating artificial intelligence and machine learning into their offerings, particularly in the areas of cloud security, governance and risk management.
Historically, organizations have operated with a level of what is acceptable risk and what is not, and have understood their threshold. However, cyber security has changed this dramatically, for example when a zero-day event occurs, but organizations were previously unable to assess that risk.
“The best example we’ve had recently of this is what happened with the log4j scenario, where suddenly, something that people have been using for a decade, which was completely benign, we found a use case that suddenly means we can get remote code execution and take ,” Cuddy said. “So how do you assess that kind of risk? If you base your risk primarily on an insurance threshold or a cost metric, you could be in a bit of trouble, because things that are below that threshold today, and that you think are not a problem, could suddenly turn into a problem a year later. “
That’s where machine learning and artificial intelligence come into play, he said, with the ability to run thousands – if not millions – of scenarios to see if something within an app can be used in a certain way. And Cuddy pointed out that because most organizations use AI to prevent attacks, there are unethical people who use AI to find vulnerabilities to exploit.
He predicted that in five or 10 years, you’ll be asking artificial intelligence to generate an application based on the data input and queries it receives. And AI will write code, but it will be the most efficient machine-to-machine code that humans may not even understand, he noted.
This will change the need for developers. But we return to the question of how far this will happen. “Then,” Bell said, “it becomes much more important to take care of it, and testing becomes more important now. We will probably move more towards traditional finished product testing and black box testing, as opposed to code testing, because what’s the point of testing code when we can’t read the code? It becomes a very different approach.”
Governance, risk and compliance
Cuddy said HCL sees the merging of governance, risk and compliance roles, which in many organizations are three different disciplines. There is also a desire to work together and connect seamlessly. “We see that reflected in the regulations themselves,” he said.
“Things like NYDFS [New York Department of Financial Services] regulation is one of my favorite examples of this,” he continued. “Years ago, they would say things like you have to have a robust application security program, and we’d all be scratching our heads trying to figure out what robust meant. Now, when you go and look, you have a very detailed list of all the different aspects that you now have to comply with. And it is revised every year. And you have to have people dedicated to that responsibility. So we’re seeing the regulations now catching up and the specifics moving the conversation forward.”
The cost of cyber security
The cost of cybersecurity attacks continues to rise as organizations fail to implement the safeguards needed to defend against ransomware attacks. Cuddy discussed the cost of implementing security versus the cost of paying the ransom.
“A year ago it was probably a lot more hey, you know, look at the level, pay the ransom, it’s easier,” he said. But even if the organizations pay the ransom, Cuddy said “there’s no guarantee that if we pay the ransom, we’ll get a key that actually works, that will decrypt everything.”
But cyber insurance companies are paying out huge sums and are now requiring organizations to do their own due diligence and raising the bar on what you need to do to stay insured. “They got smart and realized ‘Hey, we’re paying a lot in this ransomware stuff. So you’d better do some due diligence.’ And what’s happening now is they’re raising the bar on what’s going to happen for you to stay insured.”
“MGM could tell you their horror stories about how they were out of order and had literally everything — every vending machine, every ATM, every cash register,” Cuddy said. And again, there’s no guarantee you’ll be fine if you pay the ransom. “Actually,” he added, “I’d say the same group will probably attack you again. Because now they will just go somewhere else and buy something else. So I think the cost of doing nothing is worse than the cost of implementing good security practices and good measures to deal with it.”
When applications are used in unexpected ways
Software testers repeatedly say that it is impossible to test the ways in which people might use an application that is not intended. How can you defend yourself against something you didn’t even think about?
Rob Cuddy, executive director of user experience at HCL Software, talks about how he learned about the log4j vulnerability.
“Honestly, I found out through Minecraft that my son was playing Minecraft that day. And I immediately ran into his room, and I said, ‘Hey, do you see any bizarre things going through the chat here that look like weird textures that don’t make any sense?’ Well, who would expect that?”
Cuddy also shared a story from earlier in his career about misuse and how it was dealt with and how organizations are fighting back against it.
“There’s always going to be that edge case that your average developer hasn’t thought about,” he began. “Earlier in my career, doing finite element modeling, I was using a three-dimensional tool and I was playing with it one day, and you could do a join of two planes together with shaping. And I was looking for a radius around it. Well, I didn’t know any better. So I started using just typical numbers, right? 0, 180, 90, whatever. One of them, I believe it was 90 degrees, caused the software to crash, the window completely disappeared, everything died.
“So I filed a complaint about that, thinking our software shouldn’t do that. A few days later, I get a much older gentleman running into my office saying, ‘Did you submit this? What’s wrong with you? As if this is a mathematical impossibility. There is no such thing as a 90 degree radius of curvature.’ But my argument to him was that he should not crash. Long story short, I spoke to its manager and basically yes, the software shouldn’t crash, we need to fix it. So that older guy never thought that a young, inexperienced, fresh out of college would come along and abuse the software in a way that is mathematically impossible. So he was never responsible for it. So there was nothing to fix. But one day, it happened, didn’t it. That’s what happens in security, someone is going to attack in a way that we have no idea about, and it’s going to happen. And can we answer at that moment?”