How DevSecOps should be defined

How DevSecOps should be defined

Written by: Mark Wireman, December 15, 2019

It’s 9:00 pm on a Friday night. You’re well into the unwinding period after a long week of auditors, budgets, and fire drills of one security challenge after another. Not major challenges just daily items of tweaking this, updating that, and changing this other thing. All is well from an operations perspective and the latest business developed applications have been deployed to production without a hitch. Just as you get ready to tune out the week one final time for the weekend, the work cell phone rings followed by an urgent text. What you thought was an efficient and effective software development process has turned into the dreaded incident – sensitive client data that has been stolen through a compromise in one of the recently updated internally developed business applications. How can this be given we are a DevSecOps shop, you ask, realizing you’re asking this question out loud.

The Rise of Agile and DevOps

Organizations today struggle with the balance of meeting customer demands for new products and services while making sure the Organization maintains well-disciplined and mature development processes. This challenge is the main attraction for the adoption of the Waterfall and related methodologies which continues to drive many of the larger organization’s development methodologies.

However, even the large Organizations are receiving more and more pressure to get enhanced capabilities, integration of new technology, and consumer-based features into the hands of the customers. This is, in large part, being driven by the generation of consumers who have grown accustomed to on-demand results at the click of a button with everything they need literally at the edge of their fingertips. As a recent study highlights (Howen, 2015) mobile technology is bringing the ease of shopping and the information age to the smart device landscape – be it smartphones, tablets, or similar devices. This also drives the need for Cloud Service technologies – Platform as a Service (Paas), Software as a Service (Saas), etc. – to be more adaptive to the growing needs, wants, and demands at a moment’s notice. The final equation and the end result is Organizations are being forced to equally respond in kind, pushing development processes to respond quickly to consumer requests, abandoning the old ways of Waterfall and learning the new way of Agile. Agile itself is not a new concept. In 1988, Barry Boehm, in his landmark paper entitled “A Spiral Model of Software Development and Enhancement”  (Boehm, 1988) launched the concept of Agile development.

How DevSecOps should be defined
Figure 1 Spiral Model of Software Development (http://users.encs.concordia.ca/~paquet/wiki/images/e/ea/Spiral_model.gif

Since 1986 through today, there are many adaptations of the Spiral Model, however, notice how one key component has been removed from the adaptations: Risk Analyses. This is evident by the adoption of the Agile Manifesto in 2001 by a group of 11 individuals who represented the various offsprings of the Spiral model. Figure 2a is what the 11 individuals agreed to and has now forever known as the Manifesto for Agile Software Development.

Figure 2a: Agile Manifesto (http://agilemanifesto.org/)

From the Manifesto there are 12 key Principles shown in Figure 2b that align with the adoption and implementation of the 4 key statements of the Manifesto. As noted the important concept of Risk Analyses has been removed from the Agile nomenclature.

Figure 2b: Agile Principles (http://agilemanifesto.org).

The Manifesto and the Principles have thus given rise to the Agile Methodologies – used to respond to Customer demands through incremental, iterative, and continuous work in a repetitive cycle. This allows for the continual enhancements and improvements to requirements, design, code, and integration. Figure 3 is a representation of a few of the Agile Methodologies in use. Figures 4a through 4e provide a detailed representation of specific Agile Methodologies.

Figure 3: Example of Agile Methodologies (http://www.nascenia.com/wp-content/uploads/2014/12/Agile-Methodology.jpg)
Figure 4a: SCRUM Agile Methodology (http://scrumreferencecard.com/scrumreferencecard-content/uploads/2013/03/scrum-iteration-detail.png)
Figure 4b: eXtreme Programming (XP) Agile Methodology (http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-48-03-metablogapi/4578.image_5F00_thumb_5F00_2176142B.png)
Figure 4c: Dynamic Systems Development Method (DSDM) Agile Methodology (http://assets.devx.com/articlefigs/17425.jpg)
Figure 4d: Feature Driven Development Methodology (http://www.step-10.com/SoftwareProcess/FeatureDrivenDevelopment/images/fdd.jpg)
Figure 4e: Test-Driven Development Methodology (http://www.radicalgeek.co.uk/Post/14/acceptance-test-driven-development-of-an-mvc-web-application-using-specflow-and-selenium-webdriver)

With the array of Agile methodologies and the demand to push functionality to the consumers quickly, the need for automation to meet the accelerated time-to-market is an essential ingredient to the success of Agile. In addition, the agile development manifesto calls for automation to support continuous integration. This shift has given rise to a vast number of new tools in an attempt to automate the Agile processes. Figure 5 is a representative chart of the types of tools and where the tools fit into the Agile flow – known as DevOps – bringing “Development” and “Operations” together and running in parallel. The one interesting note is the Security tools are very light in the tool space and only looks at the tools that examine network traffic vs. tools that can identify and remediate security flaws early, before code release. Further discussion of the security tools will be presented throughout the remainder of the posts.

Image result for periodic table of devops
Figure 5: Tools used in Agile Development processes (https://xebialabs.com/assets/files/infographics/periodic-table-of-devops.png)

Importance of Software Risk in DevSecOps

Today, organizations deal with the concept of managing software risk in DevSecOps by scanning the application (either static code analysis, dynamic analysis, or pen testing) and by implementing some basic controls (training, policy or two and a few guidelines). However, the concept of software risk should be and is considered a hard problem (Application Security, 2015) (Getting Started, 2015). Yet, organizations – at the advice of professionals – continue treating the hard problem as though it is solvable and manageable with a two-dimensional approach. Think of this as trying to push a 50-pound boulder up a hill with a straw!

Thus the goal of this blog – to bring to focus, the true nature and reality that, just like Information Security, the concept of DevSecOps is beyond a two-dimensional approach and must be treated with the respect it deserves as a hard problem. Only then will organizations and the industry as a whole begin to understand all of the challenges and provide provable and implementable solutions to address the growing threats facing the single, most important barrier between the outside world and the most critical asset within the organization – information.

It is interesting how an area within the Risk universe has taken shape that forces the division between Development and Security to come together has yet to be officially or formally defined as a common standard within the industry. Sure there are plenty of definitions, however, even the definitions tend to lead to asking more questions than providing a clear understanding of what this “Thing” of DevSecOps is.

The term Application Security is all around – from the major technology vendors to the media to academia. And now the concept of Software Risk, Software Risk Management, Software Security, Software Assurance, are also thrown into the mix to attempt to drive meaning and understanding to the challenge of securing applications. And even this begs another question: what applications are considered to fall within the realm of security? Hence the reason why it is important to define Application Security which will hopefully lead to an understanding of what to protect and how to effectively protect it.

When we hear the phrase Application Security, the meaning conjures different points of view. From a Developer’s perspective, the general point of view is the protection of applications using scanning techniques to identify vulnerabilities. From a pentester, the general point of view is manually attacking not only the application to identify vulnerabilities, but also attacking the underlying system and dependent components to identify vulnerabilities. The C-level general point of view is scanning an application as well as providing some level of remediation and training to identify and manage application risks. And then there is another rogue point of view that application security is an archaic term that, if anyone uses it does not know what the concept means.

So, before defining DevSecOps, let’s try to standardize the concept of application security as well as introduce other phrases and concepts that have sprung up in the past few years.

Application security is loosely defined as the measures or controls that are built into the Software or Systems Development Lifecycle (SDLC) to detect, deter, and respond to exceptions in the security policies and procedures of an application or the exploitation of vulnerabilities from flaws in the design, development, testing, and deployment of an application (Application Security, 2015).

However, according to (Getting Started, 2015), “Application security is simply everything involved in developing, maintaining, and purchasing applications that your organization can trust.” This is a very broad, general, and open definition that does not provide a good understanding of what application security is. And this definition is not alone. Compliance and Regulatory standards such as PCI DSS, DIACAP, NIST, and others mention application security and secure systems, yet there are no clear definitions of what Application Security is or what a Secure System is and how the two are connected – only that if a check is in the box next to the control item that may or may not “look” like this nebulous concept of Application Security then the Organization, by proxy, thus has Application Security or a Secure System. Yet the Organization does not know WHAT that is or WHAT it means.

So are you confused yet? You’re not alone and this is one of the fundamental issues in the Industry. This is, in the author’s opinion, continuing to drive a wedge between the IT Security departments responsible for managing risks, the Board room responsible for protecting shareholders and the C-Suite from risk exposure, and the Development organizations understanding how and what risks to manage from an application perspective. (Application Security, 2015) has one of the best definitions of application security yet it does fall short on what type of measures or controls to build in and account for.

What has been interesting over the past few years is the Department of Homeland Security’s Build Security In (U.S. Department of Homeland Security, n.d.) organization has used the term Software Security Assurance (SSA) instead of application security for reasons not quite known. SSA is a process that encompasses software security. SSA uses a set of activities or leading practices in accordance with a maturity model to determine the maturity level the organization desires to achieve based on the level of security that is consistent with the potential harm that could result from a loss or compromise of the application.

Yet another term Software Security and now thrown into the mix are maturity models (because this is a misnomer from an Industry perspective). Appendix A defines and discusses maturity models. However, when the term Software Security is thrown into the mix this is essentially the same as application security. Are you still with me? The below summarizes the concepts so far:

1. Application Security = Software Security

2. Application Security is a subset Of Software Security Assurance

3. Software Security Assurance implies a maturity of application security within an Organization

4. Compliance and Regulatory Controls implies adherence to a unique set of an application security domain

Therefore, the end result is the industry continues to experience pain in applications being compromised because as items 1-4 clearly highlight there are two key missing elements when talking about application security:

a) No standard definition

b) No standard methodology and list of controls

So the next question is why are the key elements missing? It is precisely this question that proves that application security is a Hard Problem, expanding beyond the two-dimension approach taken today to one that is fraught within multiple dimensions to solve. Not all is lost, however. There is a glimmer of light at the end of the tunnel that might be a way to lead the Industry toward a solution to the Hard Problem: Software Risk Management and the use of Software Risk Analytics to effectively and efficiently manage the application security dimensions organizations face.

When the concept of application security, software security, and the like are thrown around, the underlying goal is the identification and management of Risk. The Industry has been dealing with Risk for a very long time, yet when it comes to application security, the Industry is stumped at how to tackle the issue. This is due, in general, that Risk and the management thereof from a technology perspective has always been the responsibility of the Network Engineers in the IT Security department. These Network Engineers have not, in general, been exposed to the Software Developers within the software development organizations so there has always been a sharp divide between the Network Engineers and the Software Developers and the responsibility and accountability of Risk. However, this dynamic is changing and because the Engineers and the Developers don’t understand each other, the age-old problem of Risk identification and management is being viewed as a new paradigm within Organizations.

Now enter the concept of Software Risk Management. (CAST Software, 2015) sums up the definition of Software Risk beautifully – “Software Risk [are the processes, methodologies, and controls] (added by the Blog’s author) that encompasses the probability of occurrence for uncertain events and their potential for loss within an organization.” Bingo! With the tweaking to include the “are the processes…”, that is Risk Identification and Risk Management 101 principles at its core and is exactly what the industry is trying to accomplish with Application Security!

With the foundation finally poured and the concept of a new era and paradigm born, then you can now begin to understand in terms of Risk what the concept of Application Security is by focusing on and thinking in terms of Software Risk Management and the overall goal of the management of risks. And with this well-understood paradigm, then you can now begin the journey to drive toward a set of standards that can be modeled, adopted, and implemented to meet the demand and challenges within the application security universe within DevSecOps.

This blog will begin that journey by laying out the effective DevSecOps that can be modeled, adopted, and implemented to help every level within the organization identifying and managing risks of applications that move through the DevOps Processes – from Requirements and beyond. It is interesting to note that software risk is an important element of Spiral, however, the concept of software risk has been removed from the Agile Manifesto, Agile Principles, and the Agile Methodologies highlighted above. There is an argument that Agile itself provides implicit and built-in security because of the limited functional requirements being developed. However, this argument does not hold true when considering the continuous integration of the code and services throughout the application’s lifetime. As more and more functional requirements and dependent services are added at an increased pace, the business driver becomes the functional requirements and getting those functional requirements released at the end of the cycle – software risk isn’t even considered. One can argue that the main reason for this is the identification of software risk is a bolt-on activity that takes place at the end of the Agile cycle thereby slowing down the release and impacting time-to-market. This argument does have some merit, however, as will be explained throughout this book, software risk can, must, and should be an integral part throughout the Agile cycle – from Requirements through Release.

Agile Manifesto v2.0

To begin our journey into the remainder of the blog and DevSecOps, the Agile Manifesto will be our guide and has been updated to include the important requirement of measuring Software Risk as an inherent part of the Principles.

Our highest
priority is to satisfy the customer

through early and
continuous delivery

of valuable AND
SECURE
software.

Welcome changing
requirements, even late in

development. Agile
processes harness change for

the customer’s
competitive advantage and PROTECTION OF INFORMATION.

Deliver working software
frequently, from a

couple of weeks to
a couple of months, with a

preference to the
shorter timescale WITHOUT SACRIFICING SECURITY.

Business people, SECURITY,
and developers must work

together daily
throughout the project.

Build projects
around motivated individuals.

Give them the
environment and support they need,

and trust them to
get the job done.

The most efficient
and effective method of

conveying
information to and within a development and SECURITY

team is
face-to-face conversation.

Working and SECURE
software is the primary measure of progress.

Agile processes
promote sustainable development and SECURITY.

The sponsors,
developers, SECURITY, and users should be able

to maintain a
constant pace indefinitely.

Continuous
attention to technical excellence, SECURITY,

and good design
enhances agility.

Simplicity–the art
of maximizing the amount

of work not
done–is essential.

The best
architectures, requirements, and designs

emerge from
self-organizing teams.

At regular
intervals, the team reflects on how

to become more
effective and SECURITY AWARE, then tunes and adjusts

With the inclusion of security in the Agile Manifesto, and the concept of DevOps as a way and means to deliver automation into the Agile processes, we now have the important elements to bring DevOps and Security together into a concept known as DevSecOps.

DevSecOps Defined

Simply put, DevSecOps is the automation of Security into DevOps. It is, finally, bringing Security Operations into the Agile process. Too often, Security Operations is looked as a slow adopter to new processes, methodologies, and technologies because of the bolt-on nature that the Information Security department has been forced to adapt. IS has traditionally been viewed as a business necessity vs. a business enabler, with the stigma of always telling Organizations “No” to this technology, or that process, or change because of the unknown risks the “change” brings. What IS departments are essentially saying is not “No”, rather, IS departments want to better understand the changes and whether those changes will impact business operations; subject the Organization to regulatory or compliance issues; or require updating of existing policies and procedures. However, Agile methodologies and the DevOps technologies are pushing IS departments to reinvent themselves with the continuous innovation of meeting the Organization’s need for rapid change while balancing risk mitigation, management, and compliance to keep business operations flowing.

However, far too often conversations of DevSecOps tend toward a conversation about technologies – Cloud-native, Jenkins, Kubernetes, Infrastructure as Code, automated security scanning, etc. – instead of how DevSecOps can or cannot be used to drive innovation; support the business in appeasing customers; protecting the organization and customers from cybersecurity risks; and a new way of working that influences the people and culture that impact the organization overall through collaboration, transparency, and innovation.

At its very core, DevSecOps is much like Agile, Waterfall, Test Driven Development: It is a Systems Development Lifecycle methodology that consists of processes to move systems from build to run in a streamlined, efficient, and effective way. The misperception of DevSecOps equating to tooling is not surprising given that DevOps was born out of the need to accelerate time to build and run applications with a new set of features that customers are demanding or important updates that fix issues with the pressure being put on the development and operations teams to go from run to build faster.

Given that development and operations think in the world of technology, DevSecOps is often seen and talked about from a technology perspective, with automation as one of the key mechanisms used to address the growing pressures of “run to build” at increased velocities and removal of manual processes thereby decreasing slack in the systems development lifecycle.  This additionally explains, to a large extent, why organizations are still challenged with adopting DevSecOps throughout the Enterprise because DevSecOps is for all intent and purposes a methodology that requires a cultural mindset, an understanding of the processes, the current and required skillsets for the DevOps execution, and the regulatory, compliance, legal, and policy requirements that must be included as part of the journey. The technology installation and integration is arguably the easiest task within the DevSecOps methodology.

However, without an understanding of how the development culture will significantly change; how operations must now work directly in a team of developers; security cannot be a bolt-on function; testing is now collapsed into an integrated flow; infrastructure deployment must be fundamentally changed, and release management must be overhauled to allow and support multiple deployments a day, then the technology components will end up being used manually and in the continued siloed approach. This will result in more confusion, challenges, and ultimately lead to dissatisfied customers, frustrated business owners, and product owners that are overwhelmed with repeated requests to coordinate the activities among the different siloed teams.  

To reinforce the concept that DevSecOps is a methodology that requires a cultural mindset, a defined set of processes, and a clear set of guardrails that allows the development and operations team to function in without continued concerns or issues with security violations, Figure 1 offers a more realistic view and perspective of DevSecOps that highlight DevSecOps as a methodology which relies on four key concepts that drive seven primary attributes (Bass, Weber, & Zhu, 2015) that integrates the Governance, Process, People, Requirements, and Technologies as elements of each DevSecOps activities that comprise the DevSecOps methodology.

Figure 6 A DevSecOps methodology with key concepts, elements, attributes, and activities that promote collaboration, transparency, and innovation.

When looking at the software risk challenges from a higher view, the issues that arise from securing an application is really no different than the overall challenges and issues when trying to secure an Information Technology system. An application does consist of the primary IT system components: Access and Authorization; Data; Users; Procedures (Policies, Procedures, Guidelines, Requirements); and Components (Software and Hardware). Therefore, since the software can be considered as a self-contained Information System, then we can begin to tackle the problem of how to automate and integrate security and measurement of risk into the Agile methodology. To assist with the shaping of DevSecOps and automating security into the Agile processes, we are going to leverage the concept of the 20 CIS Critical Controls for Cyber Security Defense (SANS Institute, n.d.). The 20 elements of the controls are shown in Figure 7.

Figure 7: SANS 20 Critical Security Controls (http://www.federaltechnologyinsider.com/wp-content/uploads/2014/05/20-Critical-Controls.png)

Throughout this blog, we will apply the 20 critical controls to a successful DevSecOps program, bringing Security Operations, Risk Mitigation, and Risk Management in an automated and calculated way that will complement and enhance the overall Agile processes. This will close the gap that Organizations have been struggling with in providing a means and a way to allow Information Security a seat at the table in protecting the Organization and the Organization’s customers in the Agile world.

References

Application Security. (2015, October 4). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Application_security

Bass, L., Weber, I., & Zhu, L. (2015). DevOps: A software architect’s perspective Pearson Education. Retrieved from http://www.vlebooks.com/vleweb/product/openreader?id=none&isbn=9780134049878&uid=none

Boehm, B. W. (1988). A Spiral Model of Software Development and. Retrieved from Index of Tech Reports: http://csse.usc.edu/TECHRPTS/1988/usccse88-500/usccse88-500.pdf

CAST Software. (2015). What is Software Risk.
Retrieved from What is Software Risk & How to Prevent Software Risk.

Getting Started. (2015, July 2). Retrieved from OWASP: https://www.owasp.org/index.php/Getting_Started

Howen, A. (2015, November 20). Newsflash: Millennials are Demanding. Retrieved from Website Magazine: http://www.websitemagazine.com/content/blogs/posts/archive/2015/11/20/newsflash-millennials-are-demanding.aspx

U.S. Department of Homeland Security. (n.d.). Build Security In: Setting a Higher Standard for Software Assurance. Retrieved from Build Security In: https://buildsecurityin.us-cert.gov

SANS Institute. (n.d.). The CIS Critical Security Controls for Effective Cyber Defense Now. Retrieved from SANS Institute – CIS Security Controls: https://www.sans.org/critical-security-controls