Bridging the Gap Between Policies and Execution in an Agile Environment

With the perpetual occurrence of high-profile attacks and data breaches caused by software vulnerabilities, a new trend known as secure by design (“shifting left”) has gradually shaped the software world.^{1, 2, 3} It is easier today to convince strategic governance teams that nonfunctional requirements such as security requirements, are equally as important as functional requirements. After-the-fact security activities such as patching and integrations have proven to be much more expensive and less effective than incorporating security requirements into the early stages of design.⁴

However, designing applications with security at the forefront raises new challenges. Organizations must comply with an array of regulations and standards based on factors such as their sector, location, whether they deal with personal data and more. The cost of noncompliance can be much higher than the cost of a proactive approach to integrating standards and regulatory requirements into design and development processes.^{5, 6}

At the same time, development life cycles are becoming shorter, and software releases are becoming more frequent. Traditional and linear software development processes (e.g., waterfall models) are being replaced by Agile processes. Moreover, with the advent of DevOps practices where traditionally separate business units now work closely together using Agile methods, the boundary between development and operations has become blurred. Practices such as continuous integration/continuous development have grown popular among software development teams. Exacerbating this complex environment is the push toward automation to minimize the latency of releasing new software features.

There is a dilemma that forms between these security by design and Agile software development and deployment phenomena: Security requirements are considered disruptive to Agile practices by the vast majority of the software community.⁷ Therefore, there needs to be a system of injecting actionable security requirements into the short development cycles of Agile processes. In addition to this, this system needs to bridge the gap between the policy space and the execution space. This gap is created when the requirements of policies, regulations and standards are too high level and abstract, which causes the process of extracting actionable tasks from them arduous, if not impossible. Systems that provide these translations are known in the security community as policy to execution (P2E) platforms.^{8, 9, 10} At the moment, only a handful of these platforms have been developed, but their numbers are growing rapidly.

Regulatory bodies continue to publish new security and privacy regulations and standards, such as the EU General Data Protection Regulation (GDPR) and the recently published Payment Card Industry Software Security Framework (PCI SSF), in an attempt to accommodate the ever-changing software landscape. The gap between policy and execution is widening because policies mandated by regulations and standards have become more abstract by requiring secure processes around the software development life cycle (SDLC), rather than providing straightforward, actionable tasks. This could be an attempt to render regulations and standards persistent in the face of a changing environment. Testing this hypothesis, however, requires a separate study and falls outside the scope of this work. Instead, the following is an approach for staying compliant with new and ever-changing regulations in an Agile SDLC environment with minimal business disruption or slowdown.

Research Methodologies for Consolidating Security Controls

Figure 1 provides a high-level overview of the approach used in the study presented herein. After a preliminary examination of sources and required information, an extensive literature review was conducted to gather information about existing workflows for addressing the governance of technologies in organizations.

Existing standards from external (e.g., compliance regulation) and internal (e.g., internal policies) sources and industry best practices were analyzed to gain insight about current controls in tactical governance. Subsequently, a set of interviews was conducted with subject matter experts (SMEs) to extract information about their experiences in completed projects. The interviews consisted largely of open-ended questions about existing processes. The results from SME interviews were then collected to verify consolidated controls from the aforementioned sources. In the next step, actionable controls were formulated from analyzing all collected resources.

Principles for Addressing Business and Security Needs

This study is based on three fundamental principles for success. One is that the proposed process can be repeated for existing and future standards without slowing down the production pipeline. The second is that the process should be minimally disruptive to developer workflows and easily integrated into their day-to-day activities. The third is that the process should be seamlessly adaptable to organizations of any maturity level and size without changing the structure of production to make the process functional. Taking these three principles into account allows for a unique solution in addressing the policy-to-execution gap.

Use Cases

In this study, PCI SSF is analyzed as a recently published compliance regulation.¹¹ In January 2019, the PCI Security Standards Council (PCI SSC) released two new PCI Software Security Standards as part of the new PCI SSF. These standards are the PCI SSC’s efforts to better address the integrity of payment transactions and the confidentiality of all sensitive data as new technologies and software development practices emerge.

The Secure Software Life Cycle (Secure SLC or SSLC) Requirements and Assessment Procedures is a standard in the PCI SSF that offers security assessment guidance for both the development and operations life cycles. Secure SLC compliance aligns with Agile and continuous deployment methodologies to develop software faster and without requiring an assessment from a qualified assessor for each release.¹²

Historically, many organizations that handle credit cards, such as payment software vendors and payment providers, have been subject to PCI Data Security Standard (PCI DSS) compliance. PCI DSS requirements revolve around a product’s technical security features and configurations for maintaining data integrity and confidentiality such as cardholder data encryption, strict access control and firewall configuration. However, PCI SSLC focuses on securing the software life cycle and building a secure software production and maintenance ecosystem regardless of the technology stack. This new need for compliance encourages strategic governance teams to recognize that, in addition to data security, application life cycle security is a business requirement. This business requirement mandates that product teams at the tactical governance level look for a new framework to build secure software life cycle capabilities. However, due to the widening gap between new requirements and traditional technical practices, it is not trivial to translate high-level strategic governance mandates and policies into step-by-step guidelines for building new practical processes for technical product teams. Moreover, adding a variety of emergent tools, frameworks and software development techniques to the endeavor renders it overwhelming.

In the first step of the proposed framework, PCI SSLC guidelines are analyzed and compared to existing best practices. This analysis helps identify gaps in the currently implemented controls. For example, section 4.1 of PCI SSLC requires a mature process for security testing that aims to determine the existence and emergence of vulnerabilities. While existing best practices aligned with traditional standards and business requirements advise utilizing static application security testing (SAST), they do not require a proper process for identifying the appropriate tool, the practical integration of those tools into the application development and deployment pipelines, or the proper management of vulnerabilities.

Although the new standard mandates the addition and governance of more processes and activities to an application’s life cycle, it does not provide a code of practice or set of guidelines for implementation. Therefore, tactical governance teams may choose any of the decisions from figure 2 to address this gap. Each of these decisions leads to detrimental consequences.

Next, SMEs such as a development manager, application security (AppSec) advisor and security verification engineer are interviewed. Each of them provides their experience and perspective of the secure SDLC in Agile environments. Having all information from both the compliance and execution sides, an extensive analysis is completed to improve existing practices and is organized into actionable processes. At one end of the spectrum, these processes are aligned with high-level compliance requirements and, on the other, they are compatible with production technology stacks. The outcome is imported to an existing P2E platform in the form of tasks that prescribe actionable steps to relevant roles for establishing and executing secure SDLC processes. The existing P2E platform, shown with an example in figure 3, facilitates mapping policy-level requirements to execution-level tasks. It also compiles a compliance report that lists actionable steps required to comply with particular sections.¹³

For example, PCI-SSLC section 4.2 requires establishing a mature process for identifying and fixing software vulnerabilities.¹⁴ The proposed approach is used to add a new execution-level task to the existing P2E platform. Figure 4 shows the content of this task.

As shown in figure 4, actionable steps are identified to establish and execute a process for finding vulnerabilities and fixing them using SAST tools. This new task, as well as others, can now be mapped to the sections of PCI SSLC that have been added to the P2E platform as a new compliance report. Figure 5 shows an excerpt of the compliance report.

Conclusion and Next Steps

This approach seeks to bridge the gap between complying with requirements outlined in a regulation and determining actionable tasks using a policy-to-execution platform. This systematic approach can be repeated in similar situations where requirements in regulations are too high level and do not provide sufficient guidance for implementation. Though this example used the newly published PCI SSF, a similar approach can be adopted with other compliance regulations. The utility of an existing policy-to-execution platform was leveraged to mitigate the perceived disruption of security requirements for Agile and DevOps environments. Next, best practices with respect to each requirement given in the PCI SSF were compiled from the experience of organizations of varying maturity levels. Then, SMEs were interviewed to evaluate and augment the collected best practices in the previous step. The entire process led to a set of actionable tasks that correspond to the original requirements of a compliance regulation, which can be adapted to an organization of a given maturity level.

An ongoing project designed to automate the process of listing required tasks to reduce as much manual work as possible is underway. A pattern for designing such a method has already been created and is also under development. In this method, the P2E platform used in this study collects necessary information from different sources such as code scanner results and its own activity logs to assign a task to the responsible role within the required time frame. Once the undertaking is complete, the process will be tested on a live project for a better evaluation of the approach.

Endnotes

¹ Lietz, S.; “← Shifting Security to the Left,” DevSecOps, 5 June 2016, http://www.devsecops.org/blog/2016/5/20/-security
² The Open Web Application Security Project (OWASP) Foundation, Security by Design Principles, http://www.owasp.org/index.php/Security_by_Design_Principles
³ Schneier, B.; “Patching Is Failing as a Security Paradigm,” Motherboard, 16 November 2018, http://motherboard.vice.com/en_us/article/439wbw/patching-is-failing-as-a-security-paradigm
⁴ Muresan, R.; “Costs of Non-Compliance Are Getting Higher,” Bitdefender, 2 April 2018, http://businessinsights.bitdefender.com/costs-of-non-compliance-getting-higher
⁵ Merkulov, P.; “The Staggering Costs of Non-Compliance,” SC Magazine, 1 May 2018, http://www.scmagazine.com/home/opinion/executive-insight/the-staggering-costs-of-non-compliance/
⁶ Johansson, D.; “Agile vs. Security: Resolving the Culture Clash,” Synopsys, 5 May 2016, http://www.synopsys.com/blogs/software-security/agile-vs-security/
⁷ National Institute of Standards and Technology, Special Publication (SP) 800-55 Rev. 1, Performance Measurement Guide for Information Security, USA, July 2008, http://csrc.nist.gov/publications/detail/sp/800-55/rev-1/final
⁸ Mohamed, S. I.; “DevOps Maturity Calculator DMOC—Value Oriented Approach,” International Journal of Engineering Research & Science, vol. 2, iss. 2, February 2016, http://www.academia.edu/32117015/DevOps_maturity_calculator_Value_oriented_approach
⁹ Johnson, M. E.; E. Goetz; “Embedding Information Security Into the Organization,” IEEE Security & Privacy, May/June 2007
¹⁰ Sultan, K.; A. En-Nouaary; A. Hamou-Lhadj; “Catalog of Metrics for Assessing Security Risks of Software Throughout the Software Development Life Cycle,” 2008 International Conference on Information Security and Assurance, Busan, South Korea, April 2008, http://ieeexplore.ieee.org/document/4511611/
¹¹ Gray, L. K.; “Just Published: New PCI Software Security Standards,” PCI Security Standards Council, 16 January 2019, http://blog.pcisecuritystandards.org/just-published-new-pci-software-security-standards
¹² Security Compass, “How You Can Comply With The New PCI Software Security Framework,” 17 January 2019, http://blog.securitycompass.com/how-you-can-comply-with-the-new-pci-software-security-framework-f1013d4df0b7
¹³ Miri, M.; F. H. Foomany; N. Mohammed; “Complying With GDPR: An Agile Case Study,” ISACA Journal, vol. 2, 2018, http://h04.v6pu.com/resources/isaca-journal/issues
¹⁴ Payment Card Industry Security Standards Council, “Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures,” January 2019, http://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf