All too often, information security is regarded as risk management, rather than as actual data and network security. In order to show risk is being properly managed, security teams are often regarded as gatekeepers who slow the pace of software development due to what is perceived as their authoritative behavior. While no malice is intended, this negative perception of information security promotes an adversarial relationship between security teams and other groups involved with software development and delivery.
It doesn't have to be that way. Just as DevOps practices have helped development and operations teams work together more collaboratively and efficiently — and made their companies into stronger competitors — many companies are now looking to these same practices to turn InfoSec into a partner in the faster and safer release of software — not a hindrance.
The lack of collaboration between InfoSec and system operators (SysOps) hurts both teams. When the relationship is adversarial, meetings between the groups end in shouting matches or require external people to act as go-betweens. In reaction to InfoSec's traditional authoritative behavior, SysOps finds ways to subvert the rules, or doesn't consider their effects on a given system, rather than working with InfoSec to make security policy work well for a given environment. SysOps either figures out how to have implementation-specific security tests pass even when they shouldn't, or implements security policies by rote, resulting in systems that are simply unusable.
If you're recognizing the kind of pattern here that makes teams turn to DevOps for help, you're right. Just as active collaboration between Dev and SysOps is necessary for the smooth delivery of code, so is active and ongoing collaboration between InfoSec, SysOps and Dev. When these teams collaborate well, it's much more likely you'll end up with code that runs properly in production and is in line with the organization's security policies.
To help InfoSec, SysOps, and Dev work together more collaboratively and efficiently, high-performing companies are embracing policy driven development (PDD), a configuration management process based on the principle that policies are the shared responsibilities of everyone involved in IT. PDD defines a process of policy definition, testing, implementation and monitoring. When done properly, policies will be clearly understood by anyone, compliance can be proven at any time, and teams will collaborate through expertise rather than authority.
When defining a policy, it's critical to focus on the goal of the policy, not how it will be implemented. Policies are for humans, not computers. Therefore, policies should be written in easily understood prose. A policy defined as, “PAM should be configured to disable the nullok module” is a horrible policy. It focuses on the technical implementation, rather than the policy's intent. A better policy would be, “Authentication with blank passwords should not be possible.” This policy makes clear the constraints everyone in IT must work within, without telling them how their work must be done.
Once a policy is clearly defined, policy tests can be written. Policy tests should test the policy's intent, not its implementation. To continue with our blank password example, a proper test will not simply search for “nullok” in the PAM configurations. That's grossly insufficient. Instead, the policy should be covered by multiple tests. One test should look at every local user account and ensure none have a blank password. Another should create a user (local and directory if applicable) with a blank password, and attempt to authenticate as that user. The point is, test the actions the policy hopes to prevent, rather than testing the system's configuration.
Policy monitoring and implementation
Effective policy tests are powerful tools, continuously monitoring infrastructure for compliance and verifying that any changes to the configuration management system are correctly enforcing policy. Whenever a policy test fails, the necessary infrastructure changes can be made to the configuration management system. The tests are run in staging to prove the configuration management changes correctly remediate the mis-configuration, in addition to ensuring a regression isn't introduced in the future.
Policy driven development requires active collaboration between teams, including peer review of each other's work. You can see a simple breakdown of team tasks in the chart below. If you're familiar with DevOps principles, these cross-review relationships will come as no surprise.
Policy driven development has many benefits
When done properly, policy driven development can shift an adversarial culture to one of alignment and collaboration by allowing teams to focus on their expertise rather than depending on their authority. Open source tools make it easy to define effective policy tests and react quickly when a mis-configuration is introduced. The traceable history of intent and verification will make audits quicker and less costly. Perhaps most important — especially in light of the recent string of high-profile data breaches — companies can rely on security being a consideration throughout the software and infrastructure development and delivery process. Though it takes practice, time and goodwill to execute policy driven development well — just like DevOps — the benefits are tremendous.