“Dev, Ops, and security need to work together to address risk”

Thanks for taking the time to answer our questions. First, let’s discuss the recent Toyota cyberattack. Could you tell us a little bit about that? What happened and what were the consequences?

Piyush Sharma: In February, a cyberattack disrupted one of Toyota’s plastic parts and electronic components suppliers, causing Toyota to suspend domestic factory operations (primarily in Japan) and lose approximately 13,000 cars in output. The cyberattack points to an increasing need to patch vulnerabilities throughout a manufactured product’s entire lifecycle. All too often, speed and features are prioritized over security in code, but this isn’t sustainable, which is where infrastructure-as-code (IaC) comes into play.

Could this have been prevented and if so, how could IaC have prevented this?

Piyush Sharma: Supply chain attacks, which are a type of cyberattack that targets a third-party vendor that offers software vital to the supply chain, have become very common over the years. Just consider the impact of the Solarwinds attack which is one of the largest to date. With these types of cyberattacks rapidly increasing year over year, security teams and vendors are focusing on them too.

So, yes, this could have been prevented by implementing security into the developer build process – continuous integration and continuous delivery (CI/CD) and DevOps Pipelines. These build processes depend on rapid commits and deployment and with security traditionally being implemented at the end of the process, it’s too late to detect and remediate an attack like the one Toyota suffered.

Organizations need to establish IaC as a common vocabulary between DevOps and security teams, improving collaboration and enabling DevOps teams to satisfy security requirements independently. They need developer-first security solutions that are compatible with their workflows and detect and resolve vulnerabilities introduced in their build pipelines before cloud applications are deployed.

What is infrastructure-as-code (IaC)? How is it used?

Piyush Sharma: Infrastructure-as-code is a way to provision infrastructure through code rather than manual processes. Leveraging IaC, teams can fix problems for any cloud environment directly within the code before it reaches runtime, and before attackers are able to exploit those issues as vulnerabilities.

Think of the process like building a house. There are three stages: laying the foundation and designing the house; relinquishing it to the homeowners; and getting the house up-and-running. Without IaC, vulnerabilities aren’t discovered until this third stage and by that time, an organization has already been exposed. But if we’re able to detect and mitigate issues while the code is still being written – during the foundational phase – the organization will be secure by design. This means that your infrastructure can be written and described in code, and this code can be executed to make changes to your infrastructure.

Before IaC existed, the only authoritative source for this information was the configuration of the runtime environment itself. If problems weren’t found or fixed before the provisioning stage, then the company would need to bear that cost or risk.

What are some of the benefits and advantages associated with IaC?

Piyush Sharma: IaC is changing the game when it comes to security, offering many benefits to security leaders like speed, consistency, accountability, scalability, reduced costs and more. First and foremost, devices are secure by design with IaC, so when teams assess the code used to create the environment, it removes the risks before they are ever even introduced and allows security to be scaled at the speed of code. If a single script creates all of the cloud resources, teams no longer need to modify the permissions of thousands of cloud resources one by one. By looking at the drift between the actual cloud resource and what was intended, teams can catch problems earlier too. Finally – and arguably most importantly – infosecurity teams can better communicate with ops by offering edits to their IaC scripts, making security an actor and enabler in the deployment of new resources.

Does implementing IaC come with any pain points or difficulties?

Piyush Sharma: Infrastructure as Code is a tremendous benefit to IT environments but does come with a few challenges. Iac puts developers in the driver’s seat in an ever-increasing software-driven economy. They’re not only writing the code that powers applications, but the infrastructure and automated processes as well. All it takes is a single bad code commit to create vulnerabilities that attackers can exploit.

Also, you may need to expand the dev team as IaC requires high levels of technical expertise. This puts stress on organizations as they need to invest in building their employees’ skill sets, along with any new hires.

Configuration drift is also going to be a challenge for many. IaC becomes an organization’s source of truth. The IaC template is how you deploy and monitor ALL of your infrastructure. So if security or operations are making changes in runtime, after infrastructure has been deployed, how do you document those changes? It’s nearly impossible to monitor all changes being made in runtime, so often those changes go undetected. Now, your cloud starts to drift away from the definition of the configuration that was defined in infrastructure as code. If an organization were to redeploy the infrastructure using IaC, any change that was made in runtime is going to be lost. Thus, any fixes you made are lost and the risk is there all over again.

How does IaC tie into DevOps?

Piyush Sharma: IaC is helping bridge the divide between developer and security teams, and in turn, is starting to shift the accountability within organizations as teams change the way they perceive security. We’re starting to see more shared responsibility among developer and security teams, and that means shared accountability. No longer should the burden rest solely on a CISO’s shoulders if a breach happens. Developers are the custodians of cloud infrastructure and should therefore be accountable for maintaining the security infrastructure of the cloud.

In a perfect world, a CISO would consult developers when buying a security product to ensure that the tool won’t slow them down, and then the two departments would collaborate on integrating the product into their pipeline and code.

Are companies pushing out rushed features too quickly instead of focusing on security? What can be done to mitigate this?

Piyush Sharma: Security and DevOps teams have not always worked together harmoniously, and a big part of that is because of the velocity at which developers work. DevOps teams care more about the speed of code deployment than security, and they don’t want bug remediation to slow down their work. But when you embed security in IaC, you detect early and therefore fix early, allowing security teams to better speak the language of developer teams.

What security tools should be in every developer’s toolkit?

Piyush Sharma: Organization’s embracing IaC will need to move beyond traditional runtime security tools that require expert users and address risks after they have been deployed, Dev, Ops, and security will need to work together to address risk across the entire lifecycle and supply chain, in development and runtime, and deliver fixes in code to ensure risks are remediated quickly with minimal burden on security experts, and without having to turn developers into security experts. This is the cornerstone of an organization’s DevSecOps journey.

The post “Dev, Ops, and security need to work together to address risk” appeared first on JAXenter.