7 Questions to Ask About Your DevSecOps Program

If you’ve implemented, or are implementing, a DevSecOps program, we’ve come up with several questions to consider below. By posing these questions, we hope to help spur new ideas and help identify areas for improvement. We’re also hosting a webinar on implementing DevSecOps next Wednesday (3/21/18).

Is My Application (or Microservice) Leaking Data?

While microservices have helped many organizations increase their development velocity and efficiency, they also make understanding data flows across an application more complex. As developers become more focused on the microservice they work on, their overall view becomes more siloed. Developers simply don’t understand how every microservices handles every type of data and, as a result, its becoming increasingly common for unencrypted critical data to be leaked to 3rd party databases and other services like code repositories, logging, analytics. (P.S. Check out our free data leakage assessment)

How is My Custom Code Vulnerable?

At ShiftLeft we see many customer environments and 100% have significant, previously unknown, vulnerabilities in the code that they write and maintain. The primary ways in which organizations attempt to find vulnerabilities in their code are static code analysis in dev, automated QA in testing and dynamic code analysis in production (e.g. pen-testing). Yet, what we see in the market is that, these techniques clearly aren’t sufficient. Every CISO must accept some level of risk, but the process of identifying vulnerabilities is so burdensome that many organizations don’t adequately understand their own security postures well enough to determine whether or not they are accepting appropriate risk levels.

Are My 3rd Party Libraries/Open Source Vulnerable?

For 3rd party libraries, there are a number of tools that map the versions leveraged in your application to Common Vulnerabilities & Exposures (CVEs). Context is also important with 3rd party libraries because how they are deployed and used can inadvertently create new vulnerabilities, for which there are no CVEs. In fact, misconfiguration is the most common form of real world vulnerability. The SF Muni breach is a good example, where they passed serialized data into a 3rd party component that wasn’t built to handle it securely.

How Quickly Can My Team Fix Weaknesses in Dev?

Identifying vulnerabilities and fixing them are entirely separate beasts. If you’re running static source code analysis, the handful of issues that it finds can be lost in a sea of false positives. These tools simply can’t understand what your code is supposed to do, so they flag many irrelevant issues that dramatically slow response times down. If leveraging dynamic analysis in production, which can also identify vulnerabilities, but is inherently manual/slow and has no way to trace vulnerabilities back to the lines of code in question, which also adds time to remediation. For 3rd party libraries, upgrading to a patched version isn’t always easy, so it’s important to also know whether or not you are using the library in a vulnerable manner. Unlike simple scans to map versions to CVEs, the context of how you are using the library takes time for your dev team to determine.

How Quickly Can My Team React to Threats in Production?

Historically, attempting to secure applications in runtime has been done with web application firewalls (WAF). However, very few organizations deploy their WAFs in “protect” mode to block attacks. The few that do, only block a very small subset of attacks. The reason is because false positives are so prominent that blocking kills far too much legitimate usage. Unfortunately, the solution has been to leverage WAF in alert mode, which passes the false positive problem on to the security team. Thus, security must waste an enormous amount of time filtering through false positives.

Am I Handing Data in a GDPR (& other Regulations) Compliant Manner?

The EU’s General Data Protection Regulation (GDPR), which goes into effect in May, is a significant expansion upon previous regulations in two important ways. First, unlike the Health Insurance Portability and Accountability Act (HIPAA) or the Payment Card Industry Data Security Standard (PCI DSS), which apply to specific industries (e.g. healthcare, banking & e-commerce), GDPR applies to any organization with EU resident data, regardless of where the business itself is located. And for organizations that build web/cloud software, that’s much more encompassing than previous industry focused regulations. Second, GDPR significantly expands the types of data that need to be protected. While PCI DSS has elevated the overall security of it’s industry, the vast majority of organizations that held credit card numbers already treated them as critical. Yet, GDPR’s definition of critical data includes new types of data that few would otherwise consider critical, such as:

Any information related to a [EU resident] or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer IP address.

Protecting names, social networking posts, IP addresses, etc. will be starting from scratch for many organizations.

Can I Answer All of These Questions for Every Release?

All of the questions above boil down to time. For example, what good is annual source code analysis if your organization releases weekly? The code changes with each release, so when any security process takes multiple release cycles, it increasingly becomes stale. With all the time in the world, everyone could thoroughly inspect and harden all aspects of an application’s security posture. However, with release velocity increasing, Security Teams have less and less time. Hence, DevOps is rapidly out-pacing AppSec in many organizations.

Concluding Thoughts

The only way to comprehensively deliver security for every version of every microservice is through automation. They key to precisely automating security is semantic graphing. That’s what we’ve built here at ShiftLeft: a security service that understands how your application is supposed to work as well as how it is actually being used. This is how we automate comprehensive security for every release and enable our customers to positively answer all of the above questions.

7 Questions to Ask About Your DevSecOps Program was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Andrew Fife. Read the original post at: https://blog.shiftleft.io/7-questions-to-ask-about-your-devsecops-program-e6cef650b8a7?source=rss----86a4f941c7da---4