DevSecOps as an Aspect of GRC

Originally published on DZone

An in-depth look at how DevSecOps can be a key aspect of supporting the needs of corporate governance, risk, and compliance (GRC).

DevSecOps as an Aspect of GRC [Part 1]

Throughout the DevSecOps as an aspect of GRC article, I’ll go in-depth on how DevOps can be a key aspect of supporting corporate GRC (governance, risk, compliance) needs. Before diving into implementation steps, it’s important to understand what DevSecOps and GRC are and why they’re more important than ever. In Part 1, I’ll look at why this approach is essential for scaling digital transformation while mitigating risks.

A Perfect Storm: Balancing Innovation With Governance, Risk and Compliance

As the COVID pandemic stretches into the back half of 2020 and beyond, businesses are faced with a barrage of new challenges:

• Supporting remote workforces.
• Addressing customer safety concerns.
• Removing supply chain bottlenecks.
• Ensuring data security.

Unfortunately, the challenges facing businesses today don’t stop here. Digital transformation has largely been fueled by disruption and competition. “Born-digital” companies are fast out-pacing most of the companies who have traditionally dominated the market. More than half of the S&P 500 is expected to be replaced in the next decade, and the average time companies remain on the S&P has fallen from over 30 years in the 1960s to around 12 years today.

Couple this disruption with the recent increases in compliance requirements — such as GDPR and CCPA— and it’s clear that the pressure to innovate has never been higher. But neither have the risks. While speed and agility are paramount, businesses must balance market pressure with security and legal standards.

As the market continues to accelerate transformation and data privacy demands grow, businesses must find a way to scale innovation and compliance simultaneously.

The GRC Framework

The term GRC was coined in 2002 in the wake of the WorldCom and Enron scandals and arose to address the need for efficient operations while abiding by laws and keeping the business secure. GRC frameworks are “structured approaches to aligning IT with business objectives, while effectively managing risk and meeting compliance requirements.”

GRC Frameworks are comprised of three components:

• Governance boils down to the ability to achieve your objectives however they’ve been defined by the organization.
• Risk Management is about addressing the uncertainties and potential adverse forces that may prevent you from achieving those objectives or activities.
• Compliance provides the guide rails to act with integrity and meet the different relevant regulations in that process.

GRC frameworks look different for different businesses, but at their core, each framework provides an enterprise with the structural strength and behavioral alignment across the organization to manage and overcome these competing pressures.

Applying the GRC Lens to DevOps and DevSecOps

DevOps originated within IT to meet similar performance and innovation goals. While security and compliance have always been a part of DevOps, DevSecOps arose to ensure security was explicitly emphasized. Seeing DevSecOps as part of a broader GRC framework makes clear how DevSecOps serves the needs of organizations to innovate faster, maintain complete visibility and control, and effectively manage risk.

GRC and DevSecOps use different tools, require different skills, follow different processes, and are emphasized by different teams. But their goals are aligned, and it’s important for both teams to appreciate this so they can collaborate effectively. DevOps specialists are often narrowly focused on process automation or improving handoffs within IT. It’s important for IT teams to appreciate their work in the broader context of serving the company’s GRC initiatives.

By contrast, GRC-focused consultants and leaders need to understand DevSecOps as a complementary approach that they should encourage, not inhibit. The IT industry evolves faster than most departments in the company, so compliance officers should defer to IT teams on the most efficient methods to meet requirements. Their main role should be to emphasize the goals and requirements of GRC, and to invite creative solutions from IT. Being overly prescriptive on how the IT team must operate will undermine the goal of governance, by layering bureaucracy on processes that could be streamlined.

Adopting a Holistic, Integrated Approach

While frameworks are often seen as processes and workflows, adopting them goes much deeper than documentation. To truly embrace digital transformation through the GRC lens, businesses must shift their mindsets: “In a forward-thinking organization, GRC is viewed as a well-coordinated and integrated collection of all of the capabilities necessary to support Principled Performance at every level of the organization. GRC doesn’t burden the business, it supports and improves it.”

OCEG Redbook uses a Capability Model to help ensure organizations take a comprehensive approach to GRC. But the most important thing to understand is that GRC should be viewed as something that can bolster a business, not burden it.

There’s a flawed view that compliance acts as a blocker to streamlining and achieving organizational efficiency. But in addition to meeting legal and ethical needs, compliance brings many short and long-term benefits, especially in terms of traceability.

To better appreciate GRC, let’s define and understand the interdependence of governance, risk and compliance.

While these concepts are interrelated and interdependent, they haven’t necessarily been executed together. Most organizations follow a more siloed model. Over the last two decades, companies have been trying to take a more collaborative and integrated approach to these three things in everything they do. Applying a GRC framework ensures that companies take an executive-level view of these concerns, so they can ensure they balance the time and resources required to address all of these needs. The goal is to design processes that are simultaneously efficient, compliant, and secure.

Understanding the GRC framework provides an overarching context to understand how DevSecOps can help companies deliver applications efficiently, while reducing risk. In the following section, I’ll dig into each pillar of the GRC framework and how to use them to implement your DevSecOps methodology.

DevSecOps as an Aspect of GRC [Part 2—Governance]

In the first installment of the DevSecOps as an aspect of GRC, I provided an introduction to GRC (governance, risk, compliance) and how it helps businesses mitigate risks as they scale. In Parts 2-4, I’ll be exploring how DevSecOps helps teams implement GRC efficiently and safely.

This section — Part 2 — covers governance. We’ll define what governance is, why you need it, and how to apply it to your DevSecOps methodology.

What Is Governance?

Corporate governance is the ability for a company to achieve its goals. It implies the ability to carry out processes consistently and efficiently, to gain insight into whether that’s happening, and to change processes in response to changing goals. Governance exists to help businesses operate efficiently by:

• Aligning stakeholders and promoting collaboration.
• Preventing duplicative work.
• Ensuring security, legal, and business requirements are met in the course of daily work.

Why Do Your DevSecOps Teams Need Governance?

In Part 1 of this article, we discussed how the COVID-19 crisis has created a perfect storm of IT challenges. As companies strive to out-pace the competition and implement privacy regulations, they’re now also faced with supporting a remote workforce and rethinking business processes across the entire enterprise.

Simply, IT teams are responsible for more business initiatives and objectives than ever before — and they rely heavily on efficient release processes to deliver these at scale. The ability for IT teams to ensure environments remain consistent, and that applications can be built, tested, and delivered, is the challenge of IT governance. Such processes now need to happen faster than ever.

DevSecOps aims to address this need for speed while simultaneously reducing risk, so deployments are both frequent and safe.

Documenting and holding development, ops, and security teams accountable to common processes and objectives requires upfront alignment but creates efficiency in the long-term that leads to quantifiable business value:

“Companies with high-quality corporate governance do a better job of aligning executives’ interests with long-term shareholders’ interests, holding management accountable, and developing strategies for sustainable growth and profitability.” David Trainer, CEO of New Constructs and Forbes Contributor

As IT continues to play a larger role in corporate strategy, the need for governance within IT — particularly release management — will continue to grow.

Defining Your Governance Framework

As technology rapidly disrupts and evolves, IT needs to deliver the best experience for customers and the best tools for sales, service, and marketing teams. Development managers strive to fast-track transformation by deploying multiple times a day while meeting security and compliance standards, ultimately trying to strike a balance that helps you serve the business most effectively.

The goals for DevOps look a little different for every company. Some organizations may optimize for speed, while others may optimize for reliability and verification. For example, healthcare providers have additional compliance regulations, like HIPAA, that may skew their optimal journey toward the security and trust axis. Governance means applying the necessary controls to help continuously balance innovation velocity with security and trust for your applications.

Governing Your DevSecOps Process

For IT teams, successfully implementing governance goes beyond process definition. The tools they choose must enable their teams to operate within their defined standards. Essentially, teams who choose tools that were built with governance in mind are much more likely to increase both velocity and security.

At the same time that your team is doing work, it’s also important to monitor and optimize the way teams work. In addition to steps like automating deployments and tests, it’s important to gather metrics and gain insights into the development process.

• DevOps Analytics is important to track data such as the four key metrics of DevOps: lead time, deployment frequency, change fail rates, and time to recover. Other information, like the amount of work in progress, and what components were associated with bugs, can help teams pinpoint inefficiencies in deployment processes.

Tracking the Four Key DevOps Metrics

• Value Stream Mapping analyzes stages of development, allowing you to assess lead time, idle time, active development time, and more. These visualizations allow managers to quickly assess blockers and address process bottlenecks.
• Alerts and notifications bring exceptions and other events to your immediate attention. And exception reports help you proactively identify, detect, and prevent policy violations that could cause data leaks and exposure of confidential data.
• Environment and codebase monitoring allows teams to run regression tests, set up compliance rules, and run automated jobs to continuously monitor and scan environments and releases. Static code analysis can help detect security risks and falling code quality.

Single Source of Truth

Your DevOps tools should provide a single-source-of-truth (SSoT) for environments and changes made to them. Why is this so important?

Low code platforms like Salesforce make it tempting to make changes directly in Production or Testing environments. Without proper governance, changes made in Production or Test environments can easily be wiped out by the next deployment, leading to errors, rework, and associated costs and risks. Establishing version control as a SSoT allows you to ensure that important changes are made only in Development environments and propagated from there.

Maintaining a SSoT for development processes allows Admins and Developers to capture changes in the same system, while also providing visibility for managers. This removes the risk of out-of-sync environments, reduces rework, and gives teams confidence in their work.

What Comes Next?

That’s a quick round-up of what governance means for DevSecOps and the governance capabilities you must consider and implement within your DevSecOps model.  In the next two parts of this article, I will focus on the remaining pillars of the GRC framework—Risk Management and Compliance.

DevSecOps as an Aspect of GRC [Part 3—Risk]

In the first two sections of this DevSecOps as an aspect of GRC article, we provided an introduction to GRC (governance, risk, compliance) and a deep dive into building governance into your DevOps processes. This section covers risk management, specifically security risk management. We’ll examine why security risk management is more important than ever and how it’s addressed through DevSecOps.

Why Is IT Security Vital for Companies Today?

IT security risks have never been higher, with persistent threats from hackers, organized crime, insiders, and even governments. Despite heavy investments in data security, even leading-edge enterprises like Capital One, Adobe, and Marriott have experienced large-scale security breaches. While we’re all familiar with the big security headlines, you might not be as familiar with the financial fallout that comes from a breach. According to McAfee and the Center for Strategic & International Studies, each year security breaches cost businesses more than $600 billion globally.

The average cost of a security breach has risen 12% in the last year, totaling $8.19B while the average share price of a company disclosing a security breach falls 7.27% and continues to underperform for 2 years. (Comparitech Study of NYSE)

The security stakes have never been higher. Security vulnerabilities can be introduced at different stages of the development process. A key goal of both GRC and DevSecOps is to identify, reduce, and prevent these risks.

The Rise of DevSecOps

In the 2019 State of Salesforce DevOps report, we surveyed IT leaders from more than 300 organizations to determine the biggest drivers for adopting DevOps practices. To our surprise, security was the second biggest reason companies turned to DevOps. DevOps is typically considered a methodology that reduces waste to maximize productivity. While DevOps can and should address security concerns, it’s not generally viewed as a security-first methodology. The term DevSecOps emerged to direct explicit attention to managing security and other risks.

The “Sec” focus is all about:

• Ensuring changes are scanned for security vulnerabilities.
• Ensuring that the development processes themselves are secure.
• Reducing the possibility of becoming non-compliant with security standards.

The GRC framework shows these security goals in a broader context.

GRC consultants view security issues as yet another type of risk, and include those issues in mitigation plans. Ellen Herr, Copado Sales Engineer and former GRC Consultant summarizes that approach:

“We would interview and gather information from the different departments and kind of piece the puzzle together to figure out how information or processes moved along. That way, we were able to identify any risks or gaps in advance to subsequently mitigate or fill those gaps.”

The ability to address uncertainty is integral to both DevSecOps and the GRC framework. The GRC framework is widely understood in executive circles, so IT leaders can couch the need for DevSecOps in this context.

Three Lines of Defense

As you design your DevSecOps governance framework, consider the Institute of Internal Auditors’ (IIA) Three Lines of Defense Model.

According to the IIA, the Three Lines of Defense Model “provides a straightforward approach to coordinating duties to cover gaps and avoid duplication of effort related to risk management initiatives.”

The model begins with the smallest circle — the first line of defense. These are the people who own the risk and are executing those mitigating controls. In DevSecOps, this group would consist of developers, engineers, QA, and release managers — the people building and deploying code.

The second line of defense is made up of managers who define and modify the risk and control processes that are executed by the first line of defense. This group is also charged with monitoring and improving processes; thus, they should have clear visibility into performance metrics across the whole development lifecycle.

The third and final line of defense has a broader line-of-sight into the policies and objectives of the business. This group is often cross-functional, sometimes referred to as a Center of Excellence, and exists to ensure governance across different business units are consistent with organizational and regulatory expectations. In addition to being cross-functional, this group also includes independent parties, such as internal or external auditors, who conduct unbiased reviews and assessment of governance structure and process.

Security Risk Management Within DevSecOps

Enterprises need to protect and safeguard their applications and systems at all times. DevSecOps is not a milestone or destination; rather, the shift to DevSecOps means augmenting the development process with systems that prevent known security threats, and allow swift action on newly discovered threats.

To create such systems, companies must use a combination of architectural design, specific security features, and operational policies across the development lifecycle. Here are some aspects of the practice that should be ensured:

• All development processes run through a common platform for shared visibility.
• Version control is used as the source of truth for all changes.
• Changes to work plans, and activities such as deployments are all logged.
• Environments can be monitored for changes and violations flagged.
• Changes can be passed through static analysis and security scans.

In the next and last section of the Implementing DevSecOps article, we’ll focus on the final pillar of the GRC framework — Compliance —and how it applies to DevSecOps.

DevSecOps as an Aspect of GRC [Part 4—Compliance]

In the first 3 sections this article, we’ve introduced the GRC Framework and its ties to DevSecOps, Governance and DevSecOps, and Risk and DevSecOps. We’re rounding out the series with a look at compliance, the final aspect in aligning your DevSecOps strategy to broader GRC goals.

Compliance and Trust in Modern Business

Compliance today is carried out in the midst of a crisis of trust across geographies and organizations. The  2018 Edelman Trust Barometer  revealed that people generally lack trust in business, government, NGOs, and media.

Salesforce’s Chairman and CEO Marc Benioff often emphasizes that trust is the critical currency for any company or institution and that CEOs must become activists for their stakeholders to build trust. Trust is built through complying with legal, ethical, security, and procedural guidelines across the enterprise, and it needs to be embedded within everything that an enterprise does, including their processes for developing and deploying innovation. While compliance can often be seen as red-tape, it’s more than a system of regulatory requirements; it’s the basis for building trust both internally and externally.

The compliance and regulatory landscape is getting significantly more complicated. For example, if you’re a small business in California, you’re understandably subject to local California laws and US laws. But with the Internet instantly connecting businesses to users across the world, it’s also possible you’re now subject to international laws. For example, if you serve European customers, you need to comply with GDPR regulations.

As compliance gets more complex and harder to enforce, it’s also getting more expensive. Equifax paid a whopping fine of $700 million due to a breach of most of their customer records. British Airways had a massive fine for GDPR compliance violations, again, for exposing personal data on their customers. Beyond fines, these businesses also face disciplinary action, bad press, loss of customer trust, and even imprisonment of corporate officers in extreme cases.

So it’s more important than ever that businesses implement solutions with the proper process and controls, creating an auditable structure that allows businesses to assess and manage risk.

Shifting Compliance Left

Compliance within enterprises is often approached as an afterthought and sometimes mistakenly perceived as an impediment to innovation. Since DevOps is tied heavily to organizational innovation, compliance isn’t a word you’ll hear most development teams bring up frequently. But as DevOps increasingly becomes the method to reliably deliver innovation across critical enterprise applications, it’s increasingly important to manage compliance as part of the product development process.

Ellen Herr, a Sales Engineer at Copado and former GRC consultant, has a forward-looking approach to compliance and DevOps:

“I think one of the typical notions that needs to be corrected is that auditors or compliance can’t understand DevOps or aspects of it, and so trying to educate them and bring them along in this journey is a waste of time. This assumption is just flawed. Because the reality is that compliance groups and auditors are very open and willing to learn. They want to learn. I mean, it’s in the job description that they learn these new systems and these new processes and these new risks and controls. So it’s important to shift that mindset and to be able to bring them along in the process from day one, and invite them to participate. They can really help you assess your current state and help identify and address issues or potential problems before they become real issues. But you do need to bring them along in the journey with you, right from the beginning.”

The takeaway message is about collaboration and communication; it’s not an inorganic process like most assume, it’s a human process. These are humans trying to help the company succeed. Similarly DevOps is a process that makes the day-to-day life of the developers — the humans in the delivery process — much easier. When we look beyond the misconceptions of compliance, we can easily see how DevSecOps teams and compliance can align and benefit from working together.

Implementing Compliance Within DevSecOps

Almost every enterprise needs to invest in integrating compliance monitoring and management into their development process. Creating rules for your organization’s delivery process will take time, but it is an investment that saves your organization from punitive fines and delays that ultimately derail innovation.

Where possible, it’s beneficial to use automated tools to embed compliance policies and best practices into the development lifecycle. Ideally, such tools provide a single command center that helps you monitor and manage the environments you manage and the changes you release. Tracking the justification for each change is a common aspect of complying with enterprise rules and regulatory requirements.

Automated rules engines can enable you to create rules for environments and changes, define their severity, and specify what action to perform when a finding occurs. These rules can block violations, trigger an alert, or simply log a warning. As long as such systems are predictable and secure, they can prove both faster and more reliable than manual inspection.

The fundamental responsibility of C-suite executives is to ensure corporate performance while averting risks. In that process, the company must act with integrity at every level. Governance, risk management, and compliance (GRC) addresses that three-fold challenge. The IT organization is increasingly central to all three activities — and to broader business success. DevSecOps is a technical and cultural methodology that helps IT teams meet business GRC standards as effectively as possible.

The power of DevSecOps is that not only does it serve the needs of the organization, it empowers and engages individual contributors, challenging them to meet high-level goals in the most effective way. The practices in this space are still evolving, but the underlying principles are clear: deliver value as efficiently as possible, monitor systems and processes, and solicit feedback from users and workers to learn and improve continually. Security and compliance officers can bring the greatest benefit when involved from the beginning in crafting a workflow that is efficient, secure and compliant, serving the needs of the business without burdening it.