Who should ensure the security of software development? It is the engineering organization

In the war against cyber attackers, we may be putting the wrong type of soldier on the front line. Security teams have traditionally focused on protecting infrastructure – servers, endpoints, and other building blocks of corporate networks – instead of code, repositories, or building pipelines. But in the wake of software supply chain attacks like SolarWinds and Kaseya, it’s clear that “soldiers” or security teams are not trained to thwart the right threats. The culture of engineering, where speed and feature development are highly valued, does not currently lend itself to security.

The result: Software products are developed between two worlds – security and engineering – that have hardened their practices in recent decades since security teams have become essential in businesses. These two worlds don’t work well together and, in fact, don’t even like each other very much: Engineers think security professionals will slow down the lucrative work of product development, and security professionals think engineers are basically anarchists.

The truth is, every business is a software developer now – whether it’s a retailer, a bank, a transportation company, an insurer – they all operate like software companies. If attackers look to software as a promising venue for their exploits, then organizations must close this security gap. There are many ideas on the table, such as creating the position of Product Safety Officer, or the infamous DevSecOps idea that would find traditional security teams associated with modern application development. I think the best model, which can also disrupt business the most, is to put the responsibility on the engineers who actually create software solutions.

SEE ALSO: “The impact of poor machine identity management can be devastating”

The pandemic speeds up software security

The path to developing secure software products is not very clear. A new Venafi survey of infosec and professional developers found that there was no consensus on the functional team within organizations responsible for ensuring the security of the software supply chain. Almost half of respondents (48%) believe the responsibility lies with security teams, while 48% say DevOps teams are responsible. The lack of consensus on responsibility for software security creates gaps in code generation and management environments that make organizations and their customers vulnerable to attack.

The disconnect has been around for a long time, but the differences between security and engineering weren’t so pronounced before the pandemic. Certainly, the move to the cloud has changed perceptions of security, now that businesses no longer live behind firewalls. But the pandemic and remote working have hit businesses like an asteroid. We have lived through a decade of digital transformation in just a few months.

Security teams were ill-equipped for the explosion of software development in every company. Most of them are not engineers who know how to create software. Today every business is in the software industry, and the power and security of your software is your competitive advantage.

An idea: a Chief Product Security Officer

So what is the solution to secure software development? It’s a hot topic among security professionals. Chris Wysopal, CTO of Veracode, calls for the creation of a Chief Product Security Officer (CPSO).

“It would be a role that works with the development manager to ensure that security is built into the development process,” says Chris. “They need to have a background in software engineering and focus only on the products that companies deliver to customers or deploy in the cloud. The engineering team needs to perform the automated tests and correct the defects, but the CPSO can put in additional people and processes to augment what developers can do on their own.

Chris sees the CPSO as reporting to a member of a company’s management team, just like an CISO in most companies. If small businesses do not wish to add a CPSO, they should consider creating a product safety director position within the engineering organization.

I think Chris is on to something here: we can’t change the culture around development and security without getting buy-in from the top. The C suite should make it clear that the finger-pointing between security and engineering is not acceptable, and that both departments are responsible for the safety and security of software products.

SEE ALSO: “A proactive security analysis of the code is essential”

Fast and secure, without compromise

My answer to the safety problem begins with an analogy with Formula 1 racing. Sport needs extreme performance, but with a certainty of safety. Designers and racing engineers can’t compromise on any of these goals. Software development needs to be fast for competitive reasons, but we can no longer compromise on security. Achieving both goals must come from the culture of engineering: people who know how to make products. And it can’t be the speed and then we’ll try to secure it; it must be both fast and secure. Like our engineering teams at Venafi, security architects who know how to code must be involved in every software product.

If engineering is to build safety into products, as they should, safety teams don’t need to be as important as they are. We don’t need more firewalls; we need more people who know how to code but who have the brains to create more secure software.

As engineering creates a new function of safety, safety teams can go back to what they know best. They are the threat experts and can guide the business on governance and security compliance.

Regardless of the precise solution an organization chooses to ensure security, the responsibility will lie with the development organization. If we plan to keep software products safe for customers – and if we don’t want our businesses to end up in the headlines because of an undetected security flaw – engineering organizations need to become ‘soldiers’ better trained on the front line of cybersecurity.

Source link

Gordon K. Morehouse