The DevOps Process Model: Security and privacy by design

Two main issues enable the proliferation of successful cyber-attacks: human error – many due to misconfigurations or developer’s rush to hit schedules – and budgetary constraints. All too often, these pressures lead to sloppy coding and reliance on third-party libraries. Tight timelines and budgets also contribute to a lack of ongoing investment in the latest software security processes, tools, design techniques, and education.

Although we may never solve the challenges around deadlines and budgets, there are four key areas that every software engineer and organization must invest in:

1. Ongoing education
2. Ongoing awareness and organizational processes
3. Code/design review processes
4. Security testing tools

Each of these contribute to a more robust security protocol and will lead to designing and building more secure software. Here are some ways to manage each of these steps.

Due to the enormity of the problem and the continually changing nature of security issues, there is only one way to keep track of it all when you’re creating new software: regular education on what’s happening and ways to mitigate risks when designing and building software. Seminars and workshops are run regularly by a variety of firms, with perhaps the most obvious one being Microsoft.

Over the years, Microsoft has amassed a collection of resources to help its developers, and the community at large, to write secure code. The company was an early adopter of integrating security into their SDLC, or the SDL, as they call it, and have gathered valuable information, best practices, and techniques that they make available for public consumption.

Other interesting sources of education that will expand your knowledge are offered from many university programs, including from MIT. The classes are offered regularly as ‘self-serve’ online tutorials.

An excellent resource for education and ongoing awareness of new security issues is the Open Web Application Security Project (OWASP). Founded in 2001, the OWASP Foundation is considered the go-to reference for secure application development principles and practices.

Application security principles are collections of desirable application properties, behaviors, designs and implementation practices that attempt to reduce the likelihood of threat realization and impact should that threat be realized. Security principles are language-independent, architecturally-neutral primitives that can be leveraged within most software development methodologies to design and construct applications.
– OWASP

OWASP’s has ten proven application security-by-design principles:

1. Minimize attack surface area
2. Establish secure defaults
3. Principle of Least Privilege
4. Principle of Defense in depth
5. Fail securely
6. Don’t trust services
7. Separation of duties
8. Avoid security by obscurity
9. Keep security simple
10. Fix security issues correctly

Prior versions of OWASP’s principles included the “don’t trust the infrastructure”. While no longer in the top 10, it is still correct insofar as security must be applied throughout. We firmly believe that any competent developer must always assume that there are weaknesses in both the infrastructure and the application. The best practice is for the infrastructure to assume that the application is vulnerable and try to protect it with tools such as intrusion protection and a web application firewall. Think of the infrastructure as your first line of defense, but at the same time your applications must assume that the infrastructure won’t be able to intercept all attacks and must be capable of fending off application-layer attacks by applying secure coding principles, testing, and DevSecOps (development, security, operations).

DevSecOps is crucial to preventing cyber-attacks since the overall process will make everyone in your organization accountable for security. Key aspects of a DevSecOps best practice include:

• Making security and compliance testing mandatory and seamless as part of the DevSecOps process. In this context, seamlessness means that developers can remain within their integration and/or deployment tool environment
• Scanning for known vulnerabilities and misconfigurations in all open-source and third-party components
• Focusing developers on the vulnerabilities with the highest severity risk
• Being aware of new types of tools and approaches to application security testing that will make your developers more effective
• Ensure that you have a full organizational commitment to security at all times; even momentary lapses can be risky

Another excellent feature of OWASP is their widely referenced list of Top 10 most critical security risks for web applications. This list is typically referenced by scanning tools to generate OWASP reports or assigning weight to discovered vulnerabilities. The following graphic compares the last two iterations of the top 10 list from 2013 and 2017 and can be used to understand some of the trends in web application risks.

The risks will always be shifting, and it’s hard to maintain an IT environment that continually adjusts for every new risk (except for CI/CD pipeline environments). However, coupling the experience of a trusted partner with OWASP’s more general recommendations should keep you relatively safe by following these ten proactive security controls:

1. Define Security Requirements
2. Leverage Security Frameworks and Libraries
3. Secure Database Access
4. Encode and Escape Data
5. Validate All Inputs
6. Implement Digital Identity
7. Enforce Access Controls
8. Protect Data Everywhere
9. Implement Security Logging and Monitoring
10. Handle All Errors and Exceptions

Whether your IT expertise lies in software design and development or elsewhere, everyone can agree that designing and building more secure software can be a daunting prospect. The number of potential vulnerabilities is vast. It is essential to understand not only how many new vulnerabilities there are, but also the total number of known/reported vulnerabilities, as many remain unresolved by the software vendors, or left unpatched by IT Support teams. We all know that zero-day vulnerabilities are difficult to detect or prevent, but there are plenty of attacks succeeding due to addressed vulnerabilities, with some discovered as far back as a decade ago.

Some of the leading causes for the increase in reported vulnerabilities is the popularity of bug bounty programs along with the proliferation of new individual researchers and research teams who entered the field. These grassroots and industry-wide efforts help uncover many vulnerabilities in widespread applications, but they do very little to test and identify vulnerabilities in custom applications as these are not the focus of security researchers. However, if we are to extrapolate on general industry findings, we can safely assume that custom applications are even more vulnerable.

We also trust that application developers are generally not intentionally embedding vulnerabilities or backdoors. Vulnerabilities are a result of a combination of factors, such as lack of secure development knowledge, lack of a leadership mandate, or project time or cost pressures. All too often, organizations emphasize agility, competitiveness, and functionality over security, and there is often a reliance on unvetted or out-of-date open source or third-party code libraries. Many of these issues can be mitigated by implementing the OWASP’s proven application security-by-design principles mentioned earlier.

Another great place to enhance your software development/security processes is to reference the Common Vulnerabilities and Exposures (CVE) Project, which houses one of the primary open vulnerability repositories. It records many, but not all, of the known vulnerabilities. Since its launch in 1999, it has tracked a growing list of vulnerabilities, and just in 2018, the number of newly reported vulnerabilities reached 16,555.

A more comprehensive subscription-based tracking database is VulnDB, which as of early 2019 had nearly 200,000 known vulnerabilities across 22,000+ vendors and over 2,000+ open source code libraries. More than 65,000 of the vulnerabilities in VulnDB are not recorded in the CVE database. Of all the vulnerabilities disclosed, the majority are due to insufficient or improper input validation. With many vulnerabilities falling under this umbrella, including cross-site scripting, SQL injection, shell command injection, and buffer overflows, it underlines that developers still struggle to validate untrusted input.

Interested in learning more about secure application development best practices? Here’s some resources we like:

• OWASP has an ongoing number of projects, including Developer Guide, Application Security Verification Standard, and Code Review Guide
• OWASP also offer an extensive collection of application security videos
• A reference of various types of application security attack
• The concept of privacy-by-design was coined, developed, and internationally promoted by Dr. Ann Cavoukian, the former Ontario Information and Privacy Commissioner. Her work is available as a PDF.

Application security needs to be validated throughout the lifespan of the product, not just during initial development. It should incorporate best practices for secure coding, manual source code reviews, extreme care when using third-party libraries, and automated tools for code vulnerability scanning. In addition to manual penetration testing, there are two complementary families of tools that can be used to scan an application for vulnerabilities before release to production:

• DAST: Dynamic Application Security Testing (aka black box testing), looks for application vulnerabilities at a run time. It obviously doesn’t rely on access to source code, and as a result, may not discover all application execution paths and therefore miss some of the code. Moreover, unlike SAST, DAST can identify types of vulnerabilities that are caused by server misconfigurations, integration or calls to external services, and authentication issues.
• SAST: Static Application Security Testing (aka white-box testing) can scan for vulnerabilities either in the source code or even in compiled binaries, which can be useful when customizing an off-the-shelf product or incorporating third-party library binaries without access to all or some of the source code. SAST is generally considered to be more comprehensive because, unlike DAST, it scans 100% of the code.

These requirements are even more critical in CI/CD pipeline environments.

Assessing the ‘security equation’ for your organization may seem overwhelming, but it is manageable if you approach it on a holistic, incremental, and on-going basis. The key is to give serious consideration to developing a DevSecOps process model. Doing nothing isn’t an option, as it may lead to more problems, such as increased code maintenance and support efforts, dissatisfied customers, loss of reputation and revenue, and possible regulatory or legal liabilities.

With a full-on adoption of a DevSecOps process model, you can not only reduce the probability of these pitfalls but enjoy sustained business growth without the fear of losing customers due to security breaches.

To learn more about how MNP can help you to develop a DevSecOps process model for your organization, contact us today.