DevSecOps: Striking a balance between security and agility

The US company, founded in 2001, started out protecting software in “hostile environments”, such as protecting missile guidance software being stolen from missiles that had failed to detonate.

The anti-tamper defence part of the business was sold to Microsemi in 2010, with Arxan focusing on commercial applications such as application attack prevention and self-protection tools for IoT, mobile and other applications.

Carter, who has been at Arxan for three years, says it was poor (or a lack of) DevSecOps that lead to criminals skimming the card payment details of some 380,000 British Airways customers in 2018.

Magecart, a notorious collection of hacking groups, is believed to be responsible. The group injected malicious code into the BA website that blended in, remaining undetected as it exfiltrated valuable card details.

“The data was all stolen out of the end users’ browser: their credit card information, their personal information, all those things were stolen directly from the user running it, with stuff running in the browser,” explains Carter, who has previously worked for McAfee and has been in the industry for some 20 years.

“And DevSecOps spans things like integrity of the web application running in the browser. Those are things that could have protected those companies from that attack.”

To understand integrity of the web application running in the browser, and how Magecart injected its code, Carter compares applications to a quiche (obviously):

“The application is the quiche. And in a browser, we have the pie pan and we have eggs and vegetables and milk and cheese, and all of these other things that are put into it at the time that they're baked.

“So, where a mobile application is baked before you send it out, the browser assembles all of these things before they run. Your web browser at home is assembling and baking that quiche before you're able to eat it.

“And not knowing what is being put into that quiche creates that vulnerability. So for some companies that have been hit, the JavaScript of Magecart is injected, it's put into the browser.

“It didn't exist in the infrastructure, it didn't go through the testing, they didn't just miss it.

It was put in after the fact, before that application was rendered in the browser. So being able to create integrity around that and know exactly what should be in that application, before we go out to run is a security technique that allows you to prevent it, or at least identify, that something new has been put in before it was baked.”

In short, once you’ve mixed all the ingredients – including the malicious code – together, they can’t be easily separated and are harder to detect.

For British Airways, the fallout has been severe, from reputational damage to a record-breaking £183m fine from the UK’s ICO.

So, what tools can companies integrate into their DevSecOps approach to prevent a Magecart style attack?

Traditionally, companies have turned to industries like mobile threat “where you have companies that have built out software development kits that you could include in your application in order to identify things,” says Carter.

However, he says this comes with problems.

First, developers need to learn how to use security software development kits. This can distract them from “building real business logic”, slowing down the software development process.

“And ultimately, those SDKs [software development kits] are no different than the DRM [digital rights management] and licensing systems of the past that we've dealt with, where they have well-defined boundaries.”

The familiarity with these parameters, says Carter, makes it easier for an attacker to infiltrate an application and start reconnaissance operations.

He explains that tools such as source code obfuscators (for hiding code) have their value for “applications that don't really do anything, or don't have mission critical data, or aren’t really part of your core business”.

“It's like the training wheels that people would put on their bicycle before they go and ride the Tour de France,” he says. “The source code educators help at least introduce companies to what it means to protect an application.”

Carter says that companies like Arxan can offer more advanced application security tools that can be integrated into a DevSecOps development lifecycle and “into your CI-CD (continuous integration & deployment) process”.

“So, after the developers are done, after the application is built, then protection is applied, then testing is performed. And then you have that deployment process.”

As with any cybersecurity market, it’s not a lonely place: WhiteCryption, Guardsquare and Veracode are among some of the other companies offering such application security for DevSecOps.

So, how does DevSecOps fit into the day of a developer?

“I put myself in the life of a software developer: I wake up, I go into the office, I have a list of things and business logic that I need to write. I write that work, I check my work in and I go home. When I check my work and go home, the next person in that cycle picks up and that's the DevOps person. They run the build, they make sure that the software is assembled correctly, and there's no errors in the build process.”

During this build process, the developer applies security and protection, using a “number of different frameworks” to automate security testing and general business tests.

“The next morning, that developer would come in, and they would have a list of things that they need to fix and a list of new stuff to build. So it's not really the end. It's a continuous circle.”

Carter says that “historically it’s been a challenge” to get companies to embrace DevSecOps. Businesses can be hesitant to implement solutions that might prove costly.

The direct cost of implementing DevSecOps tools can range from tens of thousands to hundreds of thousands of dollars. But it is the “overall business cost” that Carter says is met with the most resistance.

“The overall business cost is really scary, when you have to move very fast to stay ahead of your competition,” he explains. “You have to provide experience, you have to build trust, you have to build that relationship with the customer to stay competitive.”

Carter adds that there is also less awareness in the market around DevSecOps compared to areas such as application testing and static tests.

But DevSecOps isn’t always necessary, says Carter. Simply spending tens of thousands on products and tools is obviously a waste if they are not used properly.

“I recommend sort of starting at the end, which is looking at that application as it's deployed. Can it be instrumented to identify threats? Is it protected and hardened against attacks? And is there integrity around that application to ensure that if there is tampering, if there are problems with that application, I can identify it?”

Technology is full of trade-offs, whether its sacrificing privacy for a better user experience or a phone with more features but less battery.

But for businesses choosing not to embrace DevSecOps in favour of getting to market sooner, they are making a big gamble, warns Carter – one where the odds are worse than flipping a coin.

“I think ultimately, what businesses will realise is that it’s a two-headed coin. Because if they're able to go to market quickly, if they choose not to adopt DevSecOps, they may be out the market very quickly and that the crosshairs will be drawn on them – it's just a matter of time. The volume of attacks is only increasing. It's just a matter of time before they lose.”