SBN

DevOps Principles and Compliance: What to Know

Modern GRC and security teams play an increasingly important role in the growth of their companies. But these professionals are having trouble keeping up with the maintenance of multiple compliance standards and frameworks (e.g., SOC 2 Type 2, HIPAA, PCI, ISO 27001, etc.). The typical approach to security compliance work today is quite tedious and manual, which has a negative impact on compliance professionals’ quality of life and is not responsive to business needs. 

Company executives want to innovate quickly, deliver great products to customers, and gain market share. They also want to protect their corporate reputation by getting ahead of issues that can lead to a crisis. Corporate executives are looking to their compliance team to help identify and remove the threats that put key company objectives at risk. Yet, many compliance teams today are focused on keeping their company in compliance with the security and data privacy standards against which they’re audited.  

We’re not trying to minimize the existing work compliance teams do by any means. Keeping up with security and data privacy regulations and standards is essential work, and it’s a significant challenge that demands new solutions. But the real problem with taking an audit-centric approach to compliance is that it doesn’t adequately address the risks to which a company is subject. 

After living through a pandemic, all of us have recognized how quickly the risks our businesses face can change. Besides the COVID-19 pandemic, the pace of adoption of new cloud services, corporate restructures, lay-offs, mergers and acquisitions, and changes in vendor relationships can also introduce new risks to a company. The emerging risks a company faces aren’t covered by regulatory requirements, as regulations are almost always created only after we’ve lived through real-world disasters. In other words, a company can be compliant with a “rigorous” security standard and still miss the issues that can hurt their business (and customers). 

Infosec compliance teams today have an opportunity to proactively identify the real issues that put their company’s goals at risk and partner with business stakeholders to solve these crucial issues. If they focus on that — instead of just on regulatory compliance — they would have a “seat at the table.” Company executives and boards would see the great value that their compliance team provides to the organization.  

How can an infosec compliance team evolve its approach to accomplish THAT and stay on top of regulatory compliance? We believe that security compliance pros can benefit by learning about DevOps principles and processes. By understanding and applying DevOps concepts to their work, compliance professionals can become more productive, strategic, and happier.

Two vector characters use chess pieces to symbolize the strategy of devops principles

What is DevOps?

DevOps is a set of principles, processes, culture, and mindset used to shorten the software development lifecycle, using fast feedback loops to deliver features, bug fixes, and updates more frequently. RackSpace Technology provides a simple, concise definition below: 

DevOps integrates developers and operations teams to improve collaboration and productivity by automating infrastructure, automating workflows, and continuously measuring application performance. 

DevOps Principles and Practices 

The key principles and practices of DevOps are as follows: 

  1. Customer focus: DevOps principles were adopted to help organizations give their customers what they want: high-quality software and new features that are delivered quickly, in tightly managed increments (e.g., sprints). 
  1. Create with the end in mind: DevOps values being very intentional, developing and releasing software in sprint cycles are typically 2-4 weeks long. By shortening the release cycle, the risk of scope creep is minimized. By releasing code more quickly, value to customers is delivered more quickly. By breaking part deliverables into smaller increments, teams get work done incrementally faster. 
  1. End-to-end responsibility: In DevOps, you are not merely asking engineers to release code to system admins to deploy. Business teams collaborate with engineering teams during the development lifecycle. Business teams gather customer requirements and make specific feature requests to the development teams according to customer needs. 
  1. Cross-functional autonomous teams: Teams are not siloed but rather collaborate and share responsibility for the ultimate success of the software. 
  1. Shift left (or continuous testing and deployment): The term “shift left” refers to a shift in behavior: a DevOps-oriented team focuses on quality, works on problem prevention instead of detection, and does testing earlier than ever. The goal is to increase quality, shorten long test cycles and reduce the possibility of unpleasant surprises at the end of the development cycle (or even worse, in production). Shift left requires the practice of continuous testing and continuous deployment. These teams also continuously evaluate and prioritize the most impactful deliverables for their customers. 
  1. Automate everything you can: In DevOps, teams deploy a variety of tools to automate workflows across the entire DevOps chain. Tasks and processes that get automated include:  
  • Building and testing code continuously 
  • Tracking all changes to application code and all configuration management code 
  • Deploying applications across hundreds or thousands of servers
  • Monitoring performance of environment and application 
  • Making sense of how the entire application is performing and identifying bottlenecks 

Translating DevOps Principles To Compliance: High-Level Overview  

Many of the DevOps principles have broad applicability to compliance. Here at Hyperproof, we’ve translated DevOps principles for compliance work and created a set of principles we call “ComOps” (combining the terms “compliance” and “operations”). 

We’ve defined ComOps as an agile-inspired discipline that integrates assurance/compliance teams with business stakeholders to improve collaboration and productivity by automating workflows and continuously measuring and enhancing compliance performance

ComOps shares many of the same principles from DevOps, including: 

  1. Shared responsibility: Having business unit teams and compliance teams share responsibility for security, risk management, and compliance will lead to better outcomes than putting the burden of compliance solely on the compliance team.   
  1. Working in sprints: Attempting to get all compliance work done (and all evidence collected) right before a scheduled audit is incredibly stressful for compliance professionals and risky for an organization as a whole. Doing compliance work in a continuous, iterative way will help everyone keep stress levels down and reduce the organization’s risk level as a whole. 
  1. Automating routine, repetitive work: Compliance professionals traditionally spend a lot of time on repetitive admin tasks, such as: reminding people to submit evidence, going back and forth with control operators to clarify what evidence they need to submit, asking control owners the same set of questions from audit to audit, filing away documents, etc. Just as dev teams used multiple tools to automate much of the development pipeline, compliance professionals can automate manual tasks through compliance software tools. 
  1. Continuous data collection and improvement: The state of a compliance program must be constantly maintained. Why? Because new risks emerge all the time and changes in an organizational environment (e.g., changes to a company’s tech stack, alterations in how authentication and access control are implemented) need to be accurately reflected (and tested) in control language. Compliance professionals need to modify and remove controls as required. Collecting evidence on an ongoing basis will contribute to the next audit’s success and validate the effective operation of your controls. 

When compliance teams apply DevOps principles to their work (or deploy the ComOps methodology), they can keep up with new regulatory standards more easily, get their compliance work done more efficiently, and, most importantly, ensure that the work they do is truly work that helps their companies mitigate the risks that matter. From a corporate perspective, companies that deploy this approach are better positioned to avoid risk events, minimize losses from incidents when they do occur, and pursue new opportunities.

Two vector characters sitting around different objects

Analogs Between DevOps and ComOps Principles

1. Establish shared responsibility for security and compliance  

In some organizations, business process owners/stakeholders still view compliance as something that happens off to the side. This thinking is misguided because everyone in an organization has a role to play in maintaining security and compliance. 

Business process owners from HR, Finance, Engineering, and IT operate IT systems and processes that can affect data security, integrity, and privacy. These business stakeholders and operators purchase new technology to improve their own productivity and to deliver better customer experiences. When new technology is purchased, or a new business process is created, new risks to information may be introduced. It’s vital for the infosec compliance team to understand their business, why these business processes exist, what tools are used in these business processes, and why things are done a certain way — so they can understand the security and compliance implications. 

Compliance and business stakeholders (and product engineers) should work together to ensure that IT systems are configured and used in ways that advance business objectives and adhere to internal security and regulatory standards. It’s essential that the compliance team knows when business processes and technology changes happen. The compliance team should document the “proper” processes so that what’s happening can be reviewed against the established standard. They should make this data available to the business process owners. The business process owner is accountable for ensuring that the right processes or procedures are followed as they are operating their systems through the course of normal business.  

This shared responsibility model can be enforced if a company documents all its controls (i.e., business processes designed to mitigate a risk/ensure compliance with a regulatory requirement) and stores evidence of activities around those controls in a single repository. Compliance teams should be able to see when a control process deviates from what’s deemed acceptable and have a conversation with the business stakeholder to address the issue.  

2. Work iteratively and make improvements continuously 

One of the key principles of DevOps is that developers write software in small chunks that are integrated, tested, and monitored in small blocks, usually in hours, instead of the traditional way of writing large chunks of software over weeks or months. Writing smaller portions of code allows developers to improve deployment frequency and improve the time to deploy new code. It also allows them to adopt an iterative process to monitor, measure, and improve the new code every day, ultimately improving a company’s ability to respond to market needs and gain a competitive advantage. 

When you implement this same process in your security compliance function, instead of writing code, you develop controls tailored to your business processes and designed to mitigate specific risks and ensure adherence to regulatory requirements. If you can iteratively develop and improve your controls, you can minimize risks as they’re identified and maintain continuous compliance. 

Maintaining a discipline of iterative improvements is essential when we’re operating in such a risk-volatile environment. Think about how often your company enters into new markets, launches a new product, buys new software, and brings on new partners. It’s easy to see how these events can introduce new risks into the business or amplify existing ones. A ComOps oriented compliance team recognizes that internal controls need to evolve to keep up with the business as business processes and technology change. This team reviews controls on an ongoing basis and uses analytics to help them identify where to focus their efforts. 

3. Automate routine and repetitive work with tooling 

Just as a DevOps-oriented team tries to automate everything you can, a ComOps oriented infosec compliance team will seek to maximize the benefits of automation. 

With a system of record for risks, compliance requirements, and evidence of compliance activities in place, compliance teams can collect proof of control activities once and use them for multiple audits. They can automatically extract evidence from source systems to confirm that specific processes are done properly (e.g., configuration settings are accurate) and stop making demands of their colleagues.  

Although not all types of evidence can be collected automatically, automating the collection of evidence whenever possible is critical. This allows the infosec compliance team to test that evidence and detect when certain processes and system settings deviate from the baseline. More frequent testing and automated testing helps teams get ahead of issues that can cause bigger problems, such as a data breach.  

4. Continuously collect data to monitor how well risks are managed 

DevOps teams use a source control system that helps manage, track, and document all the changes to both the application code and the configuration management code (e.g., GitHub). They also adopt a discipline of application performance monitoring and optimization in almost real-time. This allows the developers to understand the performance impact of their changes. These actions help DevOp-oriented organizations achieve the ultimate goal of a production environment that gives customers a great experience. 

To make an analogy, developers care about how their code impacts application performance because application performance has a major impact on customer satisfaction. Similarly, infosec compliance teams should care about how existing controls are performing because controls’ performance directly impacts how well risks that matter to company executives are mitigated. 

A ComOps-oriented team is disciplined about tracking the risks that can throw their business off-course and seek to understand how well they’re currently mitigating those risks. To measure how well risks are managed (similar to application performance in DevOps), they use a compliance system of record to link their controls to their risks — so they understand the amount of residual risk that remains. 

They use tools to give them a real-time view of controls’ effectiveness. Rather than waiting to review dozens of controls at once right before an audit, they test and review controls on an iterative basis (a process that is ideally automated) and use automated reporting to monitor and gauge the effectiveness of their controls in real-time. By making incremental improvements on controls, the team can ward off the emerging risks and respond more quickly to changes within their business.

Four vector characters celebrate their successful devops compliance principles

What are the benefits of taking a Compliance Operations oriented approach? 

First, this approach will help compliance teams become more productive and happier. By automating routine tasks, a compliance team no longer has to complete regular administrative work.  

Additionally, security compliance teams can expect to gain credibility with internal stakeholders and corporate executives. By deploying ComOps principles, compliance teams increase the scope of their role — from focusing on regulatory compliance to leading the charge on strategic risk management. They help their organizations avoid losses due to operational disruptions, security incidents, lawsuits, and other crises. 

Armed with better data and tools that provide stakeholders with transparency into how they operate, compliance teams can communicate what they’re doing for the business more easily and effectively. Business stakeholders will see their value and be more supportive of putting more significant resources into risk management.

Meanwhile, company executives will be happier because this approach can ultimately save them money. By implementing this approach, an organization can efficiently stay in compliance with regulatory requirements and get through audits with fewer person-hours. They’ll be able to avoid hefty fines due to non-compliance and costs due to remediation efforts and investigations. 

Further, because the company is disciplined about thinking about risk landmines and avoiding them, executives can pursue new opportunities with greater confidence that they can succeed.

The post DevOps Principles and Compliance: What to Know appeared first on Hyperproof.

*** This is a Security Bloggers Network syndicated blog from Hyperproof authored by Jingcong Zhao. Read the original post at: https://hyperproof.io/resource/devops/