Security By Design: Why Application Security Can’t Be Just An Afterthought

We expect the applications and software that we deploy in the workplace to be secure. But when it comes to application and product design, a reactive approach is often taken to security.

This means that many organizations are dealing with breaches after they’ve already taken place, as opposed to preventing them from happening in the first place—and more often than not, security is considered more of an afterthought than a vital step in the development process.

But with 77% of organizations having seen a rise in cyberattacks throughout 2021, and 80% of successful breaches being new or unknown zero-day attacks (often caused by the exploitation of undisclosed vulnerabilities) it’s clear that taking a reactive approach to security within software development just isn’t cutting it.

Instead, and to reduce the risk of catastrophic breaches, it’s vital for developers to take a proactive approach to security, by building in security processes when designing software applications.

To find out more about why we should be building in security by design and how we go about doing so, we spoke with Rohit Sethi, CEO at software security company Security Compass.

Sethi has been a driving force in the cybersecurity industry since 2004, having worked as a consultant at Deloitte before joining Security Compass in 2006 alongside founder Nish Bhalla.

Over the past sixteen years, Sethi has been a fundamental part of Security Compass—first running the consulting group, later managing SD Elements while it was being built, and becoming COO in 2016. As of 2020, Sethi serves as CEO.

Building In Security By Design

Building security into software applications by design is a challenging yet vital aspect of application and product design.

“The world is building software and products that have vulnerabilities, defects, and security issues in them,” Sethi says. “But the whole world is trying to address this by either finding the defect and fixing it after the fact, or by responding to the breaches.

“When we hear about really big breaches, they’re often down to a kind of security vulnerability in software that we’ve known about for a very long time. And it’s often one that we’ve known how to prevent for a very long time, too.”

For example, the vulnerability that came to light in 2021 concerning open-source logging library Log4j was described by some cybersecurity experts as the most serious they had seen in their career. But it was a vulnerability that could have been prevented. This vulnerability was even highlighted at Black hat USA 2016, five years before appearing in mainstream media.

“We’re going to continue to see that as long as we don’t try to solve the issue at its root cause—which is building security in by design.”

What Is Security By Design?

Secure by design is a concept that makes security an inherent part of the software design process, incorporating security practices and processes from the very beginning and throughout each development iteration as opposed to them being an afterthought.

“You can think about it using this analogy,” says Sethi. “You put up a building and then afterward find there’s a safety issue behind the walls. If you’d have caught the issue in the blueprints, it would be a completely different story. The same thing is true of software.

“When a developer writes software and finds out after that it has a security defect in it, then they have to go back and fix that software. It would have been pretty easy to prevent if it had been written in the right way in the first place but, now that it’s in the code, it can be really complex.”

So, secure by design is about preventing issues and building applications securely from the beginning. But this often isn’t as simple as it sounds.

A Perfect Storm

There are a plethora of challenges facing teams when it comes to implementing security into the design process. And we can break these challenges down into two key areas:

1.    Knowledge

“If you’re a civil engineer, you have to understand safety”, Sethi says. “You have to know that the bridge you’re building isn’t going to collapse.

“But what most people don’t realize is that if you go into software development, in most cases there’s no obligation to learn about security.”

And even for developers that do have an understanding of security, keeping up to date with and understanding all the potential security and compliance issues is often overwhelming. “It’s a full-time job. And not just for one person,” adds Sethi.

In fact, 49% of CISOs say that ensuring compliance alone can be the most stressful part of their role, with 57% agreeing that regulations will become more time-consuming and chaotic as time goes on.

“It’s people that don’t have a background in security but are building products, combined with the challenge and complexity in keeping up with new security vulnerabilities and regulatory compliance that gives you a perfect storm.”

2.    Time To Market

Even if developers do want to take the time to learn about security, they often face pressure to push that to one side because “spending the time learning about security is not directly contributing to building features and shipping them out to customers,” says Sethi.

In fact, security is often seen as an obstacle to businesses, slowing down their time to market, as opposed to a vital step in the development process.

“There is a big pressure for organizations to build software quickly and ship products quickly—and most of the best practices on how to make sure they’re secure are in direct conflict with that. We believe this is the root cause of most of the vulnerabilities and security issues, and the breaches we see in the news.”

In fact, a worrying 58% of organizations admit that they sometimes implement new technology with timescales that do not allow for a proper cybersecurity assessment, while 81% agree that the time-sensitive pressures of the COVID-19 pandemic in 2021 often forced them to bypass cybersecurity procedures altogether.

“So, if you’re in an industry where you don’t have to do that, then it becomes a competitive risk to take the time to do security design reviews, when in fact your competitors are not.”

Automating Security Processes

With these challenges in mind, is there a way for organizations to ensure they’re following the right security processes and keeping up to date with the latest vulnerabilities without requiring additional resources or sacrificing time to market?

“We at Security Compass focus on the processes that people use to integrate security and compliance by design,” says Sethi. “And we help to automate as much of this as possible.”

There are several benefits to building in security by design via security process automation.

1. Freeing Up Developer Time

“Automating the process doesn’t mean you don’t need human experts at all,” Sethi says. “It just means that human beings don’t need to be involved with everything, to cover the 80% of well-known issues that we’ve known how to prevent for a decade.

“They can focus on the things that are specific to that piece of software that you need human intelligence and expertise to work on.”

2. Reducing Time To Market

“You’re taking something that previously took five days and shrinking it to minutes or hours. And that does two things,” Sethi says.

“One, it gets the software out faster. And two, you increase the appetite to do that work in the first place. It allows them to integrate security in and get the software out quickly.”

3. Managing Risk And Reducing Cost

By automating processes so that they’re faster and more manageable, organizations can more easily manage risk, making vulnerabilities less likely to go unnoticed.

And, in the event of a breach, security measures can end up costing ten to fifteen times more than if they were implemented from the beginning. “By integrating security you’re reducing risk and reducing cost. Because to fix a vulnerability at the early stages versus fixing it after the fact is just cheaper.”

4. Increasing Visibility 

“If you have an army of people going out and doing these manual processes, you can’t at a glance look at hundreds of thousands of applications in your portfolio and know whether or not they have met your minimum standard from a security perspective. You don’t have consistency.

“When you use a platform like this, you’re getting consistency and visibility in a way that just isn’t possible without technology.”

About SD Elements

Security Compass’ SD Elements helps organizations not only build in security by design, but also speed up the development process to provide a quicker time to market.

To achieve this, an organization must fill out a simple self-driven survey to provide details about their technology stack, business drivers, and the data that they store, Sethi says.

This survey is automatically connected to the Security Compass knowledge base, which is kept up to date by a team of researchers. “Their full-time jobs are to survey the world on emerging security vulnerabilities, new technologies, and changes to compliance.

“They determine underlying security issues, which software they apply to, actions development teams need to take to prevent those issues, and whether there’s any training we can provide developers to help them more securely build and deploy code.”

The system then defines a set of specific actions an organization needs to take to secure the way they build and deploy the software. These actions are integrated with ticketing or bug tracking systems like JIRA, so that developers can work on tickets that have descriptions of exactly the work they need to do and why.

This also enables organizations to keep track of when certain tasks are completed—adding in better traceability and showing that controls are implemented.

The system also integrates with penetration tools, ethical hacking tools, and tools that scan for vulnerabilities, and can show what those tools found and where security requirements were not met.

The solution then generates reports that determine whether the organization is compliant with a number of regulations and standards, taking away the strenuous manual processes that many security experts experience when ensuring compliance.

“It’s all done seamlessly behind the scenes, and we’re taking away the burden from having an army of security experts involved with every software development process and change,” Sethi adds.

Sethi’s Advice To Organizations

To finish, Sethi provides some final advice for software development organizations that are currently dealing with slow or unsecured processes during their design and build phases.

Some organizations might come under the “fast and risky” group, according to Sethi. “Fast and risky is the group that, instead of doing that five-day security process, does the find-and-fix approach. And they’re putting themselves at enormous risk because breaches are inevitable.

“Let’s say personally identifiable information is exposed in a breach and the organization can’t show they integrated security from the onset—they’re already not following industry best practice. That’s a risk that could result in not only fines but also reputational damage.

“Those organizations should really rethink whether or not it’s okay to maintain the status quo of not integrating security by design in some systematic way.”

On the other hand, other organizations might come under the group referred to as “slow and safe,” Sethi says. “This is the group that’s doing manual security processes that are adding ten or fifteen days to their development process—while maybe some of their competitors aren’t.

“What you have there is a different kind of risk: a competitive risk. They’re shipping software slower than the competition, which means the competition can innovate faster.

“So, those organizations should think about how they can speed up the extra burden they’re putting on teams that are developing things.”

---

Thanks to Rohit Sethi for participating in this interview. You can learn more about the Security Compass platform and how it works via the Security Compass website and their LinkedIn profile.