Regulation and threat aware DevSecOps culture is where DevOps was 5–10 years ago. Auditors, controls, regulations and compliance are not the topics that most autonomous, empowered, cloud-native, continuous-delivery practicing, run-what-you-build teams know much about or want to welcome.

Despite the collective progress we made during the last 5–10 years to break the walls between software development, release management, and operations, there is still a wide chasm between contemporary DevOps culture, security, and compliance to controls.

Any enterprise that collects money, processes and stores customer and payment data, and partners with other enterprises is required to comply to certain controls. These controls set some expectations on what the architecture and DevOps practices must conform to. Depending on the areas of the business and geographies served, these controls may come from IT General Controls provided by Institute of Internal Auditors, laws like Sarbanes-Oxley Act (SOX) to govern accurate financial reporting, EU regulations like GDPR for data protection of all individuals, PCI DSS for information security of payment card data, etc.

More important, some of these laws and regulations require certain executive level roles to attest that the enterprise conforms to those controls, failure of which may have material consequences. Most of these controls are also subject to internal and external audits for compliance. Auditors look for demonstration of evidence at a statistically relevant level.

However, when internal or external auditors approach dev teams, they may get a frowning “we know the right thing to do, why are we talking about this now” response. As far as dev teams are concerned, security teams, with their big-brother approaches, are blockers for getting things done quickly; and audits and compliance are drills that they have to grudgingly deal with periodically.

Folks that are responsible for security and controls consequently end up resorting to strong-arm techniques to get conformance. The result is cultural divides between each of these groups representing different interests. Controls frustrate dev/ops teams, and exasperate controllers and auditors. The outcomes are friction and potentially ineffectiveness of controls.

There are several reasons for this continued divide.

• Most of us on the tech side have a cursory understanding of regulations, compliance, and the audit procedures. Similarly, most regulators and auditors don’t always keep up with the changing technology and engineering practices.
• Each of these groups operate with different sets of skills and experiences. Lack of familiarity between these teams leads to differences in expectations or mistrust.
• Due to the general purpose and yet binding nature, regulatory language often looks ambiguous to tech teams, leading to subjective interpretations. For instance, PCI requires “file integrity monitoring or change detection systems check for changes to critical files, and notify when such changes are noted”. The interpretation depends on whether an application is stateful or stateless, how code and configuration are packaged and distributed, and how the data is managed. This ambiguity leads to tech teams not fully understanding and realizing what they need to do. Rules may sometimes appear arbitrary.
• Cloud further frustrates controllers and auditors. Though there are a number of building blocks on the cloud to build secure and compliant applications, those are not sufficient to ensure governance and show proof of compliance. You’ve to string together processes and automation for governance. Just the loss of access keys alone have exposed many organizations to data theft in recent years. While periodic rotation of access keys is a necessary practice to reduce the risk, it is up to each enterprise to invent processes and automation to implement such practices. There is a lot more that cloud providers can and must do than providing lower level buidling blocks and the System and Organization Control (SOC) reports. There is a vaccum of higher level cloud services that simplify the cost of governance.
• Though most tech teams understand that security is of paramount importance, they may lack sufficient understanding of rules and regulations that govern different types of environments (like production, PCI vs non-PCI, PII vs non-PII, analytics vs non-analytics etc.) and the rules that security teams impose on interactions between these environments. Again, such lack of familiarity leads to mistrust and perimeter friction.
• Traditionally, security teams operate under a shroud of secrecy with a “we will tell you what to do, but not why” culture. This is partly driven by the desire to keep ongoing threats confidential. Lack of such awareness further fuels mistrust and friction.
• Contrary to the blame-free DevOps culture tech teams tend to practice, certain regulations require certain roles to take the blame. In order to ensure that audits are impartial, audit teams enjoy a certain amount of autonomy with clear separation of duties. Separation of duties may end up strengthening the wall between tech teams and auditors.

Unfortunately, solutions are non-trivial and may take time. While technology in the form of automation and tools for compliance and verification is necessary, these cultural devides won’t disintegrate until and unless controls and security become part of an organization’s DevOps culture.

This won’t happen without short and frequent feedback loops between people and processes dealing with tech, security and compliance. Teaching and joint-learning should accompany these feedback loops to align mental models and vocabulary of each of these teams.