DevSecOps: Fast development without sacrificing safety

DevOps has been a boon to companies looking to shorten the systems development cycle, pushing software developers and IT operations to work together and help their enterprises fulfil their business objectives.

But while DevOps has been embraced relatively quickly, the same cannot be said for adding security into the mix, even though many software devs and IT and security professionals agree that it would be welcome and the effects of this merger on app security are documented and clear.

From DevOps to DevSecOps

Granted, the process of adding Sec to DevOps is not easy and requires a commitment to cultural changes within the company: everybody needs to take responsibility for security, be on the same page about their duties and work together during the development and delivery processes.

It also requires the performance of application security analysis at every stage of the software delivery lifecycle, a considerable dose of automation, and the implementation of the right tools.

“The security department is often viewed within organizations as an innovation blocker because requirements and processes they add that slow down the pace of code releases. If security wants to work better with the DevOps teams, it’s on them to embrace approaches that improve security while also empowering innovation,” says Andrew Peterson, CEO at web app security company Signal Sciences.

Security teams must pursue three areas to bring the SecOps and DevOps tribes together:

• Building a bridge between security and engineering cultures
• Creating adequate feedback loops that empower the dev teams to achieve the desired delivery velocity
• Insist that everything—including infrastructure—is treated as code, or components, to be effectively managed and tested on an ongoing basis.

“The pursuit of these three areas is an ongoing effort, and the tools and processes that enable security teams to successfully reach these goals will be those that prove most effective,” he notes.

The cloud, applications, and visibility

The key tenets of DevOps—automation, continuous improvement, adopting microservice-based architecture—are all part of an organization’s competitiveness in the marketplace.

But moving fast within the context of the cloud—and developing and deploying applications and services across cloud or a hybrid of on-premise and cloud has practically become the norm—means more opportunities for attackers to get through.

“Cloud computing introduces challenges and broadens the threat landscape. Running distributed systems and applications within third-party providers like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform changes (or should change) how we think about security incidents and lateral movement,” Peterson says.

“Attackers are less likely to gain a foothold into your organization by pivoting across your systems through network segments, but instead will attack your cloud provider’s configuration and seek to open holes in that environment.”

Unfortunately, one key weakness that most network focused, enterprise security departments have is a lack of preparedness to deal with the changing cloud and app security landscape. In fact, as Peterson notes, industry experts have dubbed it a “black hole” due to the disconnect that they often feel with these new technology architectures.

“To deal with this, cloud providers like AWS provide a complete audit log called CloudTrail which logs all changes to every single configuration in your cloud architecture. Meanwhile, auditing monitors all system commands run on the hosts. Combining these two vectors of logging and auditing provides a clearer picture to changes happening throughout the environment,” he explains.

But still, that is not enough: development teams that want to truly integrate security into their operations and development cycles need tools that will provide extensive visibility into potential attacks at the web app layer, regardless of where apps, APIs and microservices function.

“Adopting tools that provide real-time visibility into potential threats and automated blocking will both empower and imbue DevOps with security that works within a CI/CD framework,” he notes, and says that one of the company’s primary goals is “to make security visible to teams across the technology group.”

“Code testing tools (DAST in particular) can generate lists of vulnerabilities but offer no information if attackers are or have ever targeted those parts of your application,” he shares. In contrast, Signal Sciences provides actionable, real-time visibility of attacker behavior, be that malicious requests, app manipulation or feature abuse through a central dashboard available to both security and dev teams.

“By providing developers visibility at the application layer into how their app is being attacked and providing insights via dashboards and alerts with common DevOps tools like Slack and PagerDuty, we not only make security visible, we make it part of a DevOps team’s continual processes with the feedback loops they need to stay in front of the adversary.”