Avatar

DevSecOps is the discipline of managing security using a software engineering methodology, similar to how we use DevOps to manage infrastructure and operations. But is DevSecOps really necessary? What would happen if an organization adopted DevOps but continued to do security traditionally?

Spoiler alert: nothing good!

In this article, we’ll explore this question: What would happen if you didn’t do DevSecOps?

First, let’s set the backdrop by considering today’s systems and the traditional security approach.

Large-scale systems at DevOps speeds

Modern large-scale systems are much larger, more complicated, and handle more data than the systems of yesteryear. Yet we are using tools like microservices, cloud-based infrastructure, and DevOps, and these push the envelope of how quickly systems can be developed.

In the past, a limiting factor for speed of delivery was infrastructure provisioning. Not anymore. By using CI/CD pipelines and cloud APIs, engineering teams can re-provision infrastructure in the cloud several times a day.

But at this scale, the traditional security approach of manual checks, reviews, approvals, and detection just can’t keep up. Here’s why:

Monolith versus microservices: Monoliths are in the comfort zone for security engineers. In a monolithic application, there is simply less of everything: less code, less internal communication, and less diversity of technology in the development, testing, and deployment of such systems.

Open source: The rise and acceptance of open source in large organizations is a boon for developers that suddenly can take advantage of huge amounts of high-quality software rather than develop it themselves. However, open-source software introduces a whole new area for security to address, as critical parts of a system are now developed and updated outside the organization.

Scale: Modern systems are larger. More engineers produce more changes. In addition, there is more data to process, store, and protect.

Speed: Both the system itself and its dependencies evolve much faster, challenging the ability of the traditional security approach to ensure the system remains secure.

How will these challenges affect enterprises that continue to adopt a traditional security approach rather than embrace DevSecOps?

The effects of not doing DevSecOps

The negative impact of not doing DevSecOps is quite broad, affecting several key areas.

Effects on overall system security

When an enterprise doesn’t adopt DevSecOps practices, the first casualty is often the actual security of its systems. Developers deploy software directly to the cloud, circumventing rigid security mechanisms with intentional choke points around infrastructure and processes. This leads to insecure systems that ignore or misuse important cloud security measures.

Effects on productivity

The second casualty is productivity. With overall system security compromised—and perhaps the occurrence of a security incident or two—the security team reacts by bluntly restricting developers from accessing the cloud, removing their ability to self-service infrastructure. Deploying updates or features becomes a slog of red tape, approvals, and blockers.

Effects from software supply chain vulnerabilities

The software supply chain in modern systems is more complicated than ever. Multiple programming languages are used for building microservices, and each language or framework has its own external package management systems, with rapid updates of direct and indirect dependencies. Traditional security is simply unable to cope with the deluge of changes. It’s unable to ensure that every change is safe and free from vulnerabilities and compromises. Attackers invest more in finding weaknesses in open-source libraries because those libraries are used by so many organizations.

Effects on identity and authorization

Traditional security has a hard time managing identities and authorization across cloud providers, internal systems, and infrastructure that are provisioned and scaled automatically. Manually curating user access and controlling cross-microservice interactions is infeasible. Security misconfigurations will occur, granting developers too much access or, alternatively, locking them out of needed access.

Effects of data breaches

Traditional security measures are insufficient when data is spread across multiple data stores, owned by myriad microservices, and stored across both on-prem and cloud systems. It’s too easy to miss when some data has been stored or accessed insecurely.

In addition, transferring data between different system components provides ample opportunity for data breaches. This can be exacerbated by misconfigurations of audit mechanisms, making it difficult to detect data breaches or assess the scope of breaches after the fact.

Effects on regulatory compliance

When the system is a sprawling and dynamic web of microservices, open-source systems, and cloud-based services, regulatory compliance violations will likely occur. This can come from using some open-source library with the wrong license or storing personally identifiable information (PII) or protected health information (PHI) in a non-compliant way. Non-compliance can result in serious legal consequences, penalty fees, loss of licenses, and loss of contracts.

Effects on system uptime

Without DevSecOps practices in place, outages or system downtime resulting from security breaches are more likely and will take longer to remedy. For example, a system of multiple microservices may publicly expose endpoints unnecessarily—a misconfiguration that DevSecOps practices would detect. However, this exposure could potentially expose a large surface area for attack, raising the probability of DDoS attacks and significant system downtime.

Effects on reputation and customer trust

Security and data privacy are trending topics within the technology and business world today. GDPR is on the minds of our customers and partners. When large companies are compromised, it makes headlines. Security is a huge deal. Many of the above areas of impact could result in a full-scale compromise of a system, damaging a company’s reputation and eroding the trust of its customers.

When more traditional companies are compromised, the public eye begins to see them as antiquated, unable to adapt to the fast pace of modern business. When innovative companies have their systems breached, this leads to the impression that they’re playing fast and loose with their customer data.

Either way, a security breach can result in loss of business and market positioning.

Conclusion

The scale, diversity, and pace of development for modern enterprise systems continue to increase. This is due to several trends, including cloud-based infrastructure, microservices, and DevOps practices. In these environments, traditional security methods are insufficient. The security teams for these modern applications must adapt accordingly

When organizations pursue this type of development but don’t do DevSecOps, the potential for consequences cannot be overstated: insecure systems, reduced productivity, increased risk of data breaches or compliance violations or system downtime, and the potential for a damaged business reputation.

Security teams and DevOps teams in modern enterprises would do well to stay ahead of the curve by integrating DevSecOps practices into their flow.

 


We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel

 



Authors

Gigi Sayfan

Software Engineer

Guest Blogger