DevSecOps: Recreating Cybersecurity Culture

The relatively new practice of DevSecOps — bridging DevOps workflows with information security (infosec) operations — is defining new approaches and shared responsibilities as well as evolving cultural norms within formerly disparate security and technology teams. As companies offer customers digital experiences where products and services are increasingly powered by mobile, cloud, and data analytics capabilities, developers, in turn, are moving to development processes that meet the need for greater agility and scale. To keep pace, chief information security officers now need to work with developers much earlier in the production cycle.

It's an issue that requires both technology and culture change but is well worth the effort. At Cisco, our DevSecOps adoption and the subsequent security improvements exceeded our expectations. Within several weeks, the minimal viable version of the security automation tool we built was running in 72% of accounts that were hosting Cisco's cloud offerings; on average, 97% of those accounts received a health score of A or B in their daily report.

How did we get there? Here are four tips to guide your company on its DevSecOps journey.

Tip 1: Establish your DevSecOps foundation. Using clearly defined guiding principles to drive security throughout the development process helps establish mutual trust among the engineering, operations, and security teams. This is also the point at which expectations for mutual accountability and high security standards are defined. The Devsecops.org manifesto offers a great starting place. These guidelines can be readily modified to fit your company's unique requirements.

Tip 2: Prove it out first. Anyone with IT experience knows it's best to prove ideas manually before automating them. Consider running an Agile security hack-a-thon with participants from the information security and application teams to first configure the most important security requirements — what we at Cisco call the guardrails. Start by defining what your guardrails should be in the context of what platform you will use. Our first target environment was built on the Amazon Web Services (AWS) platform, so we defined 10 guardrails for our AWS accounts that fit Cisco-specific requirements. Do the same for your organization and its chosen platform. Then, conduct your hack-a-thon as you would for other Agile development efforts. Post-test readouts will help the entire team be knowledgeable and support users in true DevOps fashion.

Tip 3: Automate your guardrails. Provide an easy way for your teams to apply the guardrails — for example, at the time of new account provisioning. You can also develop simple scripting to retrofit existing accounts. This likely will require coordination among multiple teams — infosec, IT, supply chain, procurement, and possibly others. We implemented our security automation via our own tool that we call the Continuous Security Buddy (CSB), which is built on several AWS services.

Tip 4: Continuously validate. As new resources are onboarded or other changes occur, keep guardrails up to date with continuous security validation and real-time monitoring of security logs. Consider creating security "health reports" based on specific scoring or grading criteria to send to department-level "customers" on a regular basis. That will empower those customers to address any critical security findings in a timely manner. The cycle of teams continuously integrating and deploying code while getting ongoing security assurance is the holy grail of security!

The year-and-a-half long effort also taught us some meaningful lessons:

Cloud is more about doing than telling. Hack-a-thons enable cross-functional collaboration and deliver on critical security areas defined in the guardrails. They also provide great hands-on learning opportunities for everyone involved.

Timing matters. Coordinating your initial launch with other key organizational efforts can offer exponential returns on your effort. Try to integrate your efforts with other strategic initiatives, like signing a major cloud service agreement with a platform vendor or developing a new digital service offering for customers.

Start small and grow. Release minimal capabilities first, then iterate based on what you've learned and user feedback. Continuous visibility via those regular security health reports will enable teams to self-remediate issues and gain confidence in their offering's security posture. Scale over time as you learn more.

Guardrails vs. just pass/fail. The guardrail approach provides deep and clear guidelines for the range of compliance needed based on the situation at hand, allowing teams to manage their risks. For example, a Center for Internet Security benchmark score of 80% that is within the acceptable risk for an internal host is much more salient than just a hard pass/fail rating.

Cultivate partnerships. Establishing key operations partnerships with groups such as IT, infosec, procurement, and product operations creates a multiplying effect where the aligned efforts help everyone move faster and in the same direction.

Credibility built on trust. Be open and transparent regarding what you do with the access provided and be available for support if there are any issues. Consider setting up a central online site like a chat room to facilitate easy and fast interaction.

Skill sets matter. Realistically, infosec practitioners don't code. Complement their efforts with those of the skilled developers in your organization who do code, to ensure successfully delivery of your DevSecOps principles and guardrails. The collective skills and knowledge will cross-pollinate.

Take risks. DevSecOps is something new; it requires some risk-taking. Be patient but confident that it will pay off. Bringing teams together guided by a common goal is always a recipe for success.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Poll Results: Maybe Not Burned Out, But Definitely 'Well Done'."