How to Maintain Security when Rolling out DevOps

Source – informationweek.com

DevOps may be up and running for your enterprise. Taking the time to integrate security will keep it that way.

While DevOps is relatively new to mainstream enterprises, DevSecOps is even newer. And arguably it is just as important. While DevOps is designed to move fast, that can open up vulnerabilities in security that are easily preventable with the right controls.

Development and security teams need to understand each other’s goals and requirements. Some might see security professionals as purveyors of “No,” the ones tapping the brakes as the DevOps team pushes forward. Security’s job is to best manage risk. To do so, the security team needs to be integrated into the DevOps process.

In many organizations, this is a whole new process that needs to be worked out, and different organizations require different structures. Working security professionals into the process can be done a couple different ways. One model makes the global security function a part of the program management ecosystem. The other integrates security as an essential member of the development organization. There are pros and cons to each, of course.

Whether your organization is rolling out DevOps or you’re already off and sprinting, here’s how to weave security into the process.

1) Security as part of the program management ecosystem: Pros

In this model, the program management function has a major role, ensuring that security is at the table, and trying to confirm that the requirements are documented and met. Security then performs evaluations and identifies what critical issues must be addressed. The advantage is that the security office can uniformly address the condition of a broad number of products that the company delivers.

2) Security as part of the program management ecosystem: Cons

The disadvantage is that the security issues are typically listed on a slide for review by executives and paid attention to by one focal person in the development organization. As a result, the slides that go to executives become a roadmap for “what we have to fix” more than a prescription for “what we need to ensure the product adheres to before it ships.”

If the security team is part of the development organization, they do need to maintain close contact with a global security office, but they have an opportunity to be much closer to the development of the product. That means they’re working closely with feature teams, and identifying stories that must be planned into the sprints. When there are assessments to be run, those can’t wait until the end. They need to be planned into the earliest sprint that makes sense, and the resultant set of issues then becomes technical backlog to prioritize into the next sprints. The objective is, of course, products that are secure for customers, that have known assessments that can hold up to customer audit, especially for (but not limited to) federal customers.

4) Security as a member of the dev organization: Cons

The downside is that the local security team needs to strongly connect to the global security office. Each security team that’s part of a development organization needs to rise to act as a single brain across all products; organizations can’t have any variance with respect to standards, tools, assessments, and adherence to mandates.

5) Where to include security

To enable a “continuous security” mindset, security should be covered by automated security-related test cases in the continuous integration/continuous deployment process over the following phases:

• Build phase: use code analysis
• Image creation and hardening: automate this phase as part of the delivery pipeline
• Infrastructure creation phase: test using tooling like rspec/serverspec
• Integration phase: complete sanity checks for internal/external end-points, and ensure any new workloads don’t break any security policies
•  Regular operations: use continuous monitoring and near-real-time automated enforcement

6) Securing dev and QE labs

Though they might be forgotten, the final dimension is development and quality engineering. Both have labs in which they ensure all functionality works, scales, performs, and so on. Those labs are outstanding targets for intrusion, and security has a strong role in the evaluation and remediation of the lab environment.

Just as bringing DevOps into the fold can introduce new vulnerabilities, new systems can introduce new blind spots. But improved communication and fewer workplace silos can help address issues faster. No matter which method works best for your organization, it’s essential to have security baked into the process. DevOps may be up and running for your enterprise. Taking the time to integrate security will keep it that way.