With continuous security, SecDevOps deconstructs CI/CD

Source – techtarget.com

DevOps has taken the IT world by storm over the last several years. It’s often credited as a way to reduce costs, speed deployments and improve corporate agility. Yet the application lifecycle management process is taking at least some of the blame in the fallout from recent high-profile security breaches.

In principle, at least, “DevOps teams that deploy software are responsible for maintaining security by design,” said Craig Lurey, CTO and co-founder of Keeper Security, a Chicago-based security software provider.

In practice, though, teams too often neglect security or paste it on at the last moment. Thus, the idea to build security in from the start — via a process known as SecDevOps — was born. It’s a concept that has gained momentum, though it is not without detractors.

There’s still uncertainty regarding exactly how to approach SecDevOps, DevSecOps or perhaps DevOpsSec. Each of the competing terms implies a somewhat different idea about how to accomplish the same goal. Summarizing the challenge, former McAfee CTO Jamie Tischart wrote, “Maybe what we need is SecDevSecOpsSec. Here, security is a continuous activity in itself that needs to be incorporated into all stages of the product lifecycle.”

To be sure, people have been talking for a long time about continuous security built into applications, but without ever arriving at a standard practice. That’s because turning that worthy goal into a reality is difficult, said Konstantin Rychkov, an analyst at IDC. Organizations that have in some way embedded IT application security in their product delivery systemsinclude well-known names, such as Adobe, Amazon, Etsy, General Electric, Google, Facebook, Fidelity, Intuit, Home Depot, Netflix and Nordstrom. Still, he said, examples of successful SecDevOps in practice are few in number.

“All of the DevOps teams I work with have some integration between cybersecurity and development,” said J. Wolfgang Goerlich, cybersecurity strategist at Creative Breakthroughs Inc., a Detroit-based IT security consultancy. Some organizations have embedded security architects in the DevOps teams. Others have security champions within DevOps who work directly with the cybersecurity team. “In both cases, the partnership is a means to introduce security concepts while maintaining DevOps velocity,” he said.

Goerlich said roughly one in four DevOps teams integrate and automate some level of security controls. “This integration is generally performing scans and checks against the static code, the application and the underlying environment composition,” he said.

But this level of automation often requires tuning and adjustments to ensure it keeps pace with DevOps. For example, he said, traditional code-level scans take several days. “That’s not effective when DevOps is changing the code on a daily or even hourly basis,” Goerlich said.

Effective SecDevOps teams secure without slowing, and they add continuous security without exceeding the team’s capacity to change, he said. “It’s paradoxically fast and slow, with security controls being added slowly while tuned to execute very quickly.”

Success comes from balancing protection for the DevOps product while protecting the DevOps productivity.

IT application security approaches

Rychkov sees two main approaches for handling IT application security: security by design and self-protecting applications.

Security by design is a matter of continuous code check-ups in development environments to minimize attack surfaces and eliminate protection gaps before production, Rychkov said. It is an approach that comes naturally to developers, but DevOps is a slightly more complicated case.

Rychkov proposes an analogy in which cement represents the DevOps process and concrete — cement mixed with extra ingredients — represents the SecDevOps process. “The moment wet cement gets dry, you’ll need to break it to add aggregates and make a concrete composite,” he said. That’s time-consuming and involves extra effort and money. Similarly, when an organization tries to morph DevOps into SecDevOps, the integration of the new security components will require you to first break up the settled DevOps processes.

“This is why IDC predicts that a DevOps transition into SecDevOps will take an organization twice as long as simply building SecDevOps,” Rychkov said.

Ultimately, he said, three areas need to align to achieve the SecDevOps state: culture, process and tools. The other valid approach is self-protecting applications or runtime application self-protection (RASP), a built-in security technology to detect and prevent attacks. “This is a cheat that DevOps [teams] can use when the will to collaborate is missing,” he said.

RASP is generally achieved by third-party code insertion, which will be responsible for application defense in the runtime. Available RASP products include Veracode from CA Technologies, Contrast from Contrast Security and Immunio. “Those can help to secure an app without massive DevOps process intervention,” he said.

According to Rychkov, the downside of this approach is threefold:

• It’s not sustainable in the long run. “If you think of the speed of attacks, reliance on the third-party add-ons is risky. In the end, you will be liable, not the [independent software vendor] you’ve leaned upon,” Rychkov said.
• Application performance decline can be significant. RASP will introduce extra processing to your app, and if you fail to use the right hooks — objects that can be applied as procedures in code to intercept processes — it will affect user experience.
• It leaves space for error. This point again refers to the integration or hooks used to attach a RASP solution to the app. If you fail to cover even one gap, you could be in trouble.

“In the end, the best place to begin is the beginning — when there is no solid DevOps structure,” Rychkov said.

Security is a priority — sometimes

Ben Rockwood, director of IT and operations at Chef Software, said high hopes for security’s place in DevOps have not been realized.

Most of the time, security practices rather than security people were built into the process. But reality is rarely kind to IT application security. You need it when you need it. The rest of the time, Rockwood said, it is nudged aside by pressing concerns to add features to an application or speed code delivery.

As a result, Rockwood said, SecDevOps isn’t working. “Most companies aren’t really investing in security, and they are trying to pepper it around. SecDevOps sounds like a movement; it gives them cover for their bad behavior,” he said.

Still, one way to make sure SecDevOps fulfills its promise is through testing, Rychkov said.

“When we speak of holistic testing, integrity assessment and the like, we should keep in mind one important thing: It takes time.”

In the SecDevOps environment, the red team, which is tasked with challenging everything, needs to realize that it can’t make everything perfect and completely secure within one spin of the continuous integration and continuous deployment spiral, Rychkov said. They need to accept prioritization by focusing on fixes to critical issues reasonably achievable in a given cycle and then building the plan for further cycles to handle the rest.

“This way of thinking can be beneficial for security specialists, even outside of SecDevOps boundaries,” he said.

One area where a SecDevOps approach can shine is compliance, Rychkov said. In particular, SecDevOps is an opportunity for worldwide enterprises that must comply with General Data Protection Regulation, a European Union mandate that will enforce the concept of “data protection by design and by default.”

To truly succeed at SecDevOps and continuous security, the mentality will need to change alongside the process, he said. “That’s a journey from absolutism to relativism — the most painful one for a security team,” Rychkov said.