Foreword

The Cloud Security Alliance ("CSA") is global non-profit organization with the aim to facilitate and protect user information in the cloud and its ecosystem.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CSA shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the CSA list of patent declarations received (see www.cloudsecurityalliance.com/patents).

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

This document was prepared by the Cloud Security Alliance DevSecOps working group.

Introduction

Background

DevOps, the practice of applying developmental practices on infrastructure operations, has been shown to positively impact efficiencies of operation teams today, especially in the cloud environment.

Given its strengthening adoption, it is a logical next step in applying those practices to the arena of security management, as well as considering its impact on security itself.

Application to security

DevOps is now broadly practiced but it has been generally separated from security practices. There is currently no standardized term in industry that cater to this aspect.

To explain the intersection of security and DevOps, as well as the amalgamation of security, development and operations practices, a number of terms have been proposed by members of community, including "DevOpsSec", "DevSecOps", "SecDevOps".

These terms have been used mostly interchangeably, but the meanings they convey can be vastly different. The definitions of these terms can widely conflict with each other depending on the particular understanding of the reader.

Moreover, there is no industry recognized definition for security automation, which is a core concept to the application of DevOps practices to security operations, leading to confusion and misinterpretations.

It is therefore crucial to clarify and standardize such terms for a global and wider industry audience.

External pressure to organizations

Organizations today are faced with a number of security management issues, including:

spiralling compliance governance costs;
global shortage of cyber security professionals, which forces organizations to more efficiently utilize staff;
the notable disconnect between strategic security and operational security.

All of these factors force an organization to deliver more security "bang for the buck".

Purpose

This whitepaper aims to clarify and standardize an authoritative definition of the intersection between the three aspects of security, development and operations, and use it to generalize the principles of a novel security management approach we call "Agile Security".

Several approaches to Agile Security are suggested to resolve the availability gap of cyber security professionals.

Agile Security: the intersection of security, development and operations

1. Scope

This document:

provides rigorous definitions for the terms "DevOpsSec", "DevSecOps" and "SecDevOps";
describes the benefits of amalgamating security, development and operation practices for integrated management;
describes the "Agile Security" approach that represents a new paradigm in security management.

2. Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 27001, Information technology — Security techniques — Information security management systems — Requirements

CSA CCM 3.0.1, Cloud Security Alliance Cloud Controls Matrix, v3.0.1

3. Terms and definitions

No terms and definitions are listed in this document.

4. Essence of DevOps

4.1. General

While the term "DevOps" has been widely defined by its practices and toolsets, there are several conflicting definitions on what the term really represents.

Some of them are too narrow while some are too broad to be meaningful. For example, the Wikipedia article on DevOps claims it is "a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes", which is too vague, too broad as well as inaccurate.

"DevOps" practices today have minimal, if any, impact on software application development process itself. Its practices and related tools mainly service infrastructure automation, through concepts made apparent by Agile software development practices, such as continuous integration and delivery and programmatic (software-defined) infrastructure.

4.2. Definition

In this document, we clarify the following definition:

DevOps: The cross-application of software development and methodologies to infrastructure operations, chiefly for automating infrastructure management.

5. The (right) questions worth answering

Given the strong acclaim of DevOps practices, it is worth understanding how similar concepts affect security.

Here are the important questions we answer below:

What is the impact of DevOps practices on security?
How do we provide security through DevOps?
How does an organization implement security through automation?

6. DevOpsSec: Impact of DevOps practices on security

6.1. General

What is the impact of DevOps practices on security? Or more specifically, how do organizations ensure that DevOps does not compromise security? This has been called "DevOpsSec": "DevOps" security. DevOps practices bring strong impact on resulting infrastructure and operations. There are inherent security requirements in DevOps processes.

6.2. Definition

DevOpsSec ("DOS"): The embedding of information security principles to protect processes that utilize DevOps practices.

6.3. Implications

A software-defined infrastructure is highly beneficial (or a wet dream) for the experienced infrastructure engineer, where virtual instances, containers, and virtual network devices are spin up or down through fingertips on the keyboard.

Yet, as best put by Spiderman, power bring responsibility. It is equally true that the novice engineer armed with some development skill could have his fingertips spin things out of control. Very often, create security vulnerabilities due to lack of consideration of all aspects surrounding the infrastructure. E.g. lax firewall rulesets, default credentials or increased attack surface.

This happens more often than one thinks. As ironic it may be, software development and infrastructure administration are generally separate skill sets that doing one well does not necessary translate to the other. Anecdotes of novice developers attempting to use "DevOps" in running infrastructure causing moments of reflection abound.

In this document, we will describe the crucial security practices for protecting DevOps processes and preventing DevOps from being a threat.

7. DevSecOps: providing security through DevOps

7.1. General

How do we provide security through DevOps? Despite this question containing similar keywords with the previous one, it is an even more important question. Is it possible to apply DevOps concepts, where development practices can and have enhanced operations efficiency, onto security? Some have called this "DevSecOps" for "Security DevOps".

7.2. Definition

DevSecOps ("DSO"): The automation of information security processes through DevOps practices.

7.3. Implications

On a tactical level, DSO represents the "integration and automation of security controls through DevOps using automated toolchains". The CSO sets the policies following business requirements and risk management, which could be applied programmatically.

Examples of DSO practices:

Infrastructure
- Immutable infrastructures
QA
- Implementation of data masking of data used in development for testing
Containers
- Vulnerability scanning during building of container images
- Patch management of applications and libraries inside containers
- Hardening / secure configuration, self-healing
- PKI / Digital signatures
- Anti-virus scan during building of container images
- Certify container images
- Scan for embedded keys, hardcoded credentials, push for role based access technology
- Cryptographically sign and certify container images
Operating systems / VM images
- Vulnerability scanning during building of VM images
- Patch management of applications and libraries of the operating system
- Hardening / secure configuration, self-healing
- Anti-virus scan during building of VM images
- Cryptographically sign and certify VM images
Code / applications
- Static code analysis after code commits, builds or releases
- Scanning for embedded keys, hardcoded credentials, push for role based access
Release management
- Create new public/private keys for each release
- Only accept signed/certified container and OS images
- Revocation of older SSL certificates / private keys / PKI after each release

8. DevSec: Automating security practices

8.1. General

How do organizations implement security using automation? This is a generalized question from the previous one about security automation, no longer limited to DevOps. DevOps practices generally only helps with infrastructure automation. What should an organization do to fully utilize automation in achievement of security?

8.2. Definition

DevSec, security automation: The use of automation in place of manual processes for the achievement of information security management.

8.3. Implications

"Security as Code" is not equivalent to security automation because it does not require the "programmatic" ability.

EXAMPLE

A scripted application of the DOD Security Technical Implementation Guides (STIG) may still have to be run manually during the installation of a server.

Examples of security automation:

Business Continuity
- Automatic business continuity plan testing through Infrastructure as Code (IaC)
- Continuous backup and restore testing with data masking
SSL Certificates and Public Key Infrastructure
- Monitoring and auto renewal of SSL certificates
- Testing of expiry dates of SSL certificates
- Private and public key rotation
Identity and Access management
Infrastructure
- Vulnerability scanning of servers, VMs, containers, appliances during runtime
- Anti-virus scan during runtime

9. Agile Security: the new paradigm

Problem: CSO’s do not have sufficient number of security staff.

Agile Security is a new paradigm for information security management, that emphasizes embodiment of security across organizational roles, reactive to external and internal threats in an agile and dynamic way.

NOTE Agile Security compares to Agile Software Development, similar to how the traditional ISMS approach compares to the Waterfall mindset.

Agile Security is about dynamic information exchange within the organization. Like the immune system of the human body, information is immediately propagated to adjacent, potentially vulnerable functions given detection of a threat. A traditional ISMS approach will require that threat information to be reported back to the higher functions before any response can be made. With Agile Security, the business functions themselves are integrated security functions and can provide an immediate response to block potential impact. A centralized response is important, but should not prohibit an immediate tactical approach.

The ISMS approach is about adopting best practices. However, often best practices that work in larger organizations do not work with smaller ones, and create an unnecessary burden for the smaller organizations, which takes away precious time and effort from daily work and hence negatively affects their security stances.

Agile Security solves the security skill shortage paradox by promoting the idea of "hybrid-domain-security-experts".

Risks are delegated
Security responsibilities are delegated

A "commitment" of top leadership (as in ISMS) is not enough. Top leadership must understand the nature of security and is committed to integrating security into each and every aspect of the organization. Top leadership must fully understand the risks and threats the organization faces (its risk profile) with regards to security, and set clear bounds and requirements for personnel to adhere to.

Humans, it is often said, are the weakest link in security. Phishing, social engineering are all techniques to trick an unsuspecting individual to voluntarily compromise security of an organization. Without full participation (not just "awareness") of all involved people, security cannot be achieved.

10. Six pillars of Agile Security

10.1. Collectively responsible

Everyone is responsible towards the security stance of the organization. The CSO plays a leadership and shepherding role for information security within an organization, but each person has their own security responsibility, and they must be aware of their own contribution (and potential problems) towards the organization’s security stance. Edge users are not just "security-aware", but are the first line of defence.

10.2. Collaborate

Security can only be achieved through collaboration, not confrontation. A security aware and collaborative culture is necessary for the foot soldiers to report potential anomalies. The human factor is often the weakest link and remember that most security incidents are caused by simple human error.

10.3. Pragmatic

Security should provide value, not hindrance. For every security initiative or adopted security control, a cost-benefit should be considered to allow transparency on the value of security. Without this pragmatic approach, it is too easy for persons unaware of the benefits of security to dismiss security practices as mere overhead or unnecessary. This provides the necessary business case to convince stakeholders for security and therefore confidence to execute plans faithfully.

Traditional ISMS can create overhead, need to balance tailoring to an organization and adoption of best practices. Documentation requirements should be based on clearly thought out value brought to the organization, not a hard requirement.

10.4. Integrate

Security must be integrated in every aspect of business. Dedicated security personnel rarely have in-depth domain expertise as your business domain experts, and they are the wrong way of solving the problem no matter how many are hired. The truth is, no one else will know your domain, as well as its risks, as well as yourself. A team of dedicated security experts will most likely be oblivious of your domain-specific security issues. Domain knowledge and security knowledge must be fused and co-exist in every organizational process for effective security management.

10.5. Automate

Automated security practices are the core of optimizing process efficiency. Processes that can be automated should be automated, and those that can’t should be transformed. Automation also creates its own set of problems but automated approaches to those problems are often possible. There is a saying in software development: if you do the same thing thrice, it’s time to program it, and this applies squarely with Agile Security.

10.6. Measure

Performance that cannot be measured cannot be improved. Without measurements, there is no understandable evidence whether an information security management is effective. Agile Security is about achieving results, and even as vague as they might be, the results must be measurable for transparency and improvement.

11. Benefits of Agile Security

Resilient: Security no longer relies on a single function, e.g. a single security department. Integration of security practices throughout the organization. Requires deeper involvement of when compared to ISMS processes.
Holistic: Focused on business needs and responding to the actual risk context faced by the organization when compared to traditional information security management, from business goals to operational processes to humans, who often turn out to be the weakest link.
Dynamic: The protection of business goals is performed through integrating security with business processes, often down to the tactical levels. This allowing the organization to react faster and more effectively to threats and incidents.
Tailored: Prioritized approach to provision stronger protection to core or more vulnerable processes over those less exploitable. The traditional ISMS approach often applies the same set of controls across all processes, leading to inefficient resource allocation.
Human-centric: Security is integrated and internalized as an aspect of everyone’s work, and requires mind-share within every employee. It is not an external responsibility enforced or required by a separate, dedicated, security function.
Maturity of an Agile Security approach can lead to achievement of a formal ISMS given the need.

12. Conclusion

Agile Security provides a set of wide-implicating and easily understandable principles that affect an organization’s cybersecurity posture, especially suitable for today’s fast-paced and challenging cybersecurity landscape.

Appendix A
(normative)
Guidelines for implementing Agile Security

A.1. Approach A: Cross-train

Form an operational security function by selecting 1 or 2 persons that have an interest or background in security from each team and delegate security related tasks to those individuals. Make these persons a representative of the operational security teams.

The operational security teams know exactly what types of operating systems are used, applications are supported for the business, etc. In some organizations, this collaboration involves embedding IT operations specialists within software development teams, thus forming a cross-functional team. This effort may also be combined with a skills matrix.

A.2. Approach B: Delegate

Delegate risk management, maintenance of BCPs etc. to department heads. Freeing up resources of the dedicated security team so they can focus on the security process management and providing the framework(s). The department heads know exactly what they have in house, what risks there are.

DevOps is process neutral. Organizations can use Agile or Scrum. Have security engineers attend daily scrum meetings, make them part of the DevOps team.

Appendix B
(normative)
What Agile Security is not

TODO: Placeholder if we need it.

Bibliography

[1] ISO/IEC 27000:2018, Information technology — Security techniques — Information security management systems — Overview and vocabulary

[2] ISO/IEC 27002, Information technology — Security techniques — Code of practice for information security controls

[3] ISO 31000, Risk management — Guidelines