Without the concept of a baseline, different teams within an organization are inevitably incentivized to work at odds with one another. Developers are under pressure to create and update applications quickly and efficiently in order to be first to market and beat the competition. At the same time, security is tasked with protecting the organization’s cloud resources from security incidents. This organizational misalignment plays out differently depending on the organization.
In smaller or less developed organizations creating applications, the Security team is often working from a big binder or Excel spreadsheet of required security controls. That Excel spreadsheet contains a list of rules that serves as loose guidance and may be applied in ambiguous ways, or not at all.
In more sophisticated organizations, this adversarial relationship between DevOps and Security is exacerbated when security engineers write remediation scripts that programmatically enforce security or policy controls, such as closing ports that shouldn’t be opened. It’s not uncommon for security teams to automate destructive changes, such as accidentally closing a port that is required by an application to work properly, resulting in system downtime.
Security Teams Viewed as “The Bad Guy”
This entire process is highly inefficient. In the agile development and deployment process, where teams are releasing frequent updates, rejecting their work late in the process because it violates security or policy controls wastes a lot of development time and delays innovation. Because the Security team is enforcing compliance controls only after significant development work has been completed, they will be inadvertently portrayed as “the bad guy” putting up roadblocks at the end of the development process.
Baselines Are the Answer
Only an approach like baselining provides the details and high fidelity to enable different teams to collaborate effectively. A baseline provides a complete picture of what is actually running in a cloud environment and defines every resource with all of its attributes. There is no ambiguity about whether a specific resource is compliant with enterprise security policy, such as requiring logging to be enabled or all network traffic to be based on HTTPS instead of HTTP, because every configuration attribute is spelled out. Every relevant compliance control can be run against the baseline to verify whether the control will pass or fail.