Right in the middle of the holiday season, as much of the world was preparing to take some deserved time off to celebrate with their families and bid 2020 a less-than-fond farewell, some terrible news broke involving a number of government agencies and large enterprises. A common network management platform that is used widely across the public and private sectors had been victim to a supply chain attack, and the networks and data of a large number of users had been compromised.
The breach of SolarWinds’ Orion solution impacted a number of large government agencies — including the Department of the Treasury and Department of Homeland Security. And it raised large questions about the security practices of software and application vendors that work with and provide solutions to the government.
In the wake of this breach, there has been renewed and refocused calls for application development teams to embrace some of the new and emerging processes, practices, and technologies that have been proven to help identify and eliminate vulnerabilities in software. Included in these practices are DevSecOps and security as code.
What is security as code? And how is it different from DevSecOps? To find out, we recently sat down with Wias Issa, the CEO of Ubiq. During our discussion, we asked Wias for examples of security as code solutions in action and talked about how security as code and DevSecOps could help prevent new breaches like the SolarWinds incident in the future. Here’s what he had to say:
GovDevSecOpsHub (GDSOH): Before the evolution of DevSecOps, what was the relationship like between the software development team and the security team? Did they work together? Did they even really get along?
Wias Issa: It was generally a friction-filled relationship. You had two functions or organizations that were effectively operating in independent silos. Pre-DevSecOps, they were only really working together when there was an absolute need to achieve their respective missions.
In this environment, after an application was developed and hit production, the security team would initiate their vulnerability assessment practices, or they would rely on a third-party firm. If they found vulnerabilities, the security team would sometimes work with the development team to fix them, but they could also simply direct the development team to fix the problems before resubmitting the application to them for additional testing. I wouldn’t call it a warm handoff.
I can’t say that in most cases they got along because their priorities were different and their mindsets were different. One organization was focusing on building new products, features, and a fantastic customer experience for their users. The other team was mostly focused on reducing risk for the organization. There was definitely a missed opportunity to collaborate and work towards a shared goal of developing more secure applications.
GDSOH: How has this relationship changed as agencies and organizations have moved to a DevSecOps approach to app development?
Wias Issa: It’s gotten much better, but I wouldn’t say that all agencies have transitioned as quickly as others. For the organizations that have adopted the DevSecOps mindset and approach, relationships have certainly improved and you see it in the security integrity of the applications they’re building. And it started with shared goals and getting teams and individuals aligned on a shared objective — developing a secure application, product or service.
If you met an application developer on the street and asked them if they cared about the security of their products, you’ll be hard-pressed to find many that answer “no.” In my experience, there are very few developers that would claim they don’t care about the security of their product.
I think most developers do care about security, but prior to the evolution of DevSecOps, they weren’t empowered or enabled to leverage security controls effectively. They didn’t have the tools needed to really secure their applications. The companies making cybersecurity solutions didn’t build tools for developers. They built tools and solutions for security practitioners, which are deployed into production environments generally way after the application development processes has ended. That has since changed, significantly.
So, not only have the relationships gotten better but the teams are also more integrated. As a result, we’re seeing more secure code, more secure applications, and better results and outcomes for everyone.
GDSOH: In the past, how much of a role did app developers play in the security of their applications? Was it something that they were actively involved with and responsible for?
Wias Issa: Did they play a big role in security? No. Did people expect them to be responsible for it? In many cases, yes. At the end of the day, when an insecure application rolls out, who is blamed? The people who built it.
It was a rather unfair situation. Developers weren’t really playing a role in security, but they were responsible when there were issues.
GDSOH: We’re increasingly hearing the phrase, “security as code.” What does that mean? How prevalent is this in government agencies and the contractors that develop applications for the government?
Wias Issa: I don’t think it’s as prevalent as it should be, but my hope is that things are changing and more and more government agencies and contractors are adopting security as code solutions and practices.
What is security as code? It’s about taking security and building it not just into the DevSecOps process but into the applications themselves. The idea is taking security tooling, which has been traditionally a standalone product for security practitioners, and building it into the processes and the applications themselves. If you can do that, you ultimately make security a central part of the overall application development process.
There are a multitude of commercial cybersecurity tools that you can acquire and deploy into your infrastructure. In fact, on average, most large organizations use more than 47 distinct cybersecurity tools. This leads to tool proliferation across the enterprise, making security incredibly complex, costly, and less effective for leadership to implement and manage.
However, with the emergence of security as code solutions and practices, people are really questioning the need to acquire standalone security tools. Do I need to buy all these tools to protect my applications after development or can I integrate security tooling into the product itself, which enables me to build a secure application by design?
Let’s consider identity and access management. If I’m going to build an application, I’m going to need the ability for users to log in and authenticate. Traditionally, development teams had to build all of that on their own. But wouldn’t it be more efficient and effective to integrate a ready-made solution directly into the application?
People are realizing that the time and effort it takes to build something they have little experience with and expertise in is so great, that it makes more sense to turn to a security as code vendor that solves that problem for them.
This highlights the value and opportunity that security-as-code solutions present — taking a tool that was traditionally used after the fact and shifting it into the development process. Now, it’s being built directly into the applications, tools, and companies’ DevSecOps culture.
GDSOH: What kinds of security as code tools and solutions are out there for developers to help them make their applications more secure?
Wias Issa: It’s a growing ecosystem that encompasses a number of important security tools and solutions. I’ll give you a few examples.
One is offered by a company called Snyk and it allows a developer to perform application security testing to find vulnerabilities in their product as they’re developing it. This is in contrast to how it used to be done when an application developer would hand a complete or near-complete application to a specialized vulnerability assessment consulting organization, or someone within the security organization, for vulnerability testing. They would invariably find vulnerabilities and hand the application back to the developer to be fixed.
That is a very time-consuming and inefficient process because development has to stop during the security assessment, then restart when vulnerabilities are found and had to be fixed. So, a company like Snyk allows developers to do static and dynamic testing as they’re coding, enabling them to find and address the problems earlier. The later in the process a vulnerability is discovered, the more impact it will be to the overall development process and schedule. Applications like those from Snyk help the process run more smoothly and make it easier to find vulnerabilities earlier in the development process.
“Breaches like SolarWinds remind customers that it’s not just about what they’re doing from a security standpoint, it’s also about what their vendors are doing. If companies are going to deploy something into their environment, they need to make sure that the vendors they’re relying on are using strong security practices within the development process…” – Wias Issa
Another example is Auth0, which delivers identity and access management via an API. Auth0 allows developers to integrate identity directly into their application with almost no identity expertise required. So, designing an identity solution that would take most developers weeks or months to build can be done in a couple of hours. This rapidly accelerates the development process and greatly reduces time-to-market for that product or application.
Another example, Ubiq, simplifies data encryption for developers. Encryption is something that’s hard to get right and very easy to get wrong. In most cases, when you hand encryption or cryptographic methods to a developer, it’s like handing a bunch of knives to a child and telling them to go play. There’s potential to do some significant damage.
Ubiq solves that via APIs. We take something that would have taken weeks or months — and a lot of pain and mistakes — and eliminate all that complexity by delivering encryption and encryption key management to developers via APIs. This accelerates their overall product lifecycle and helps them build more secure applications from day one.
GDSOH: The recent SolarWinds breach that impacted the government was perpetrated through a software update. How could attacks like this be avoided in the future? Could “security as code” helped to mitigate or prevent this attack?
Wias Issa: I think that security as code and DevSecOps practices could definitely help mitigate the risk of another SolarWinds situation.
SolarWinds used some very poor developer security practices, which in their case, led to leaking FTP credentials through a public GibHub repository. These are very basic developer security missteps.
At the end of the day, you’ve got a bunch of developers building a product that’s meant to deliver a specific set of outcomes. Those outcomes aren’t tied to security, but it doesn’t really matter. Any environment that is making those basic mistakes is essentially leaving the door open for cyberattacks.
Breaches like SolarWinds remind customers that it’s not just about what they’re doing from a security standpoint, it’s also about what their vendors are doing. If companies are going to deploy something into their environment, they need to make sure that the vendors they’re relying on are using strong security practices within the development process, strong security practices within their infrastructure environments, and ultimately adopting and adhering to things like security as code and DevSecOps practices.
The whole premise of DevSecOps involves integrating security into the development process. And the whole premise around security as code involves getting the right tooling and technologies into the process and building security controls into the actual products and applications. SolarWinds, unfortunately, was a great example of how not to do things and why these trends in application development are gaining traction.
