OpenSource

Using the OWASP Top 10 Properly

Matt Konda No Comments

I have gone to great lengths to strictly separate my OWASP activities from my Jemurai activities in an effort to honor the open and non-commercial aspects of OWASP to which I have committed so much volunteer time and energy.

Today I want to cross the streams for a very specific reason, not to promote Jemurai but to stop and think about how some of OWASP’s tools are used in the industry and hopefully prevent damage from misuse.

I want to address perspectives reflected in the following statements, which I’ve heard from a few folks:

I want a tool that is OWASP Compliant

And:

I need a tool to test for the OWASP Top 10

And:

I want an OWASP Report

Or alternatively:

Our tool tests for the OWASP Top 10

OWASP Is Generally Awesome

First of all, let’s ground ourselves.  OWASP provides terrific open resources for application security ranging from the Top 10 to ZAP to ASVS to OpenSAMM to Juice Shop to Cheat Sheets and many more.  The resources are invaluable to all sorts of folks and when used as intended are extremely valuable and awesome.

The Top 10 Is Not Intended To Be Automated

Let me be very clear:  there is no tool that can find the OWASP Top 10.  The following are items among the Top 10 that can rarely if ever be identified by tools.

  • #3:  Sensitive Data Exposure
    • Tools can only find some predefined categories of sensitive data exposure.  In my experience, a small subset.  One reason is that sensitive data is contextual to a company and system.  Another is that exposure can mean anything from internal employees seeing data to not encrypting data.
  • #5:  Broken Access Control
    • Tools can’t generally find this at all.  This is because authorization is custom to a business domain.  A tool can’t know which users are supposed to have access to which things to be able to check.
  • #6:  Security Misconfiguration
    • Tools can find certain known misconfigurations that are always wrong (eg. old SSL), but things like which subnets should talk to other subnets aren’t going to be identified by Burp or ZAP.  We find custom tools that can find them but they are just that custom.
  • #10:  Insufficient Logging & Monitoring
    • What does this even mean?  Our team has been delivering custom “security signal” for a while, but this isn’t binary that you have it or you don’t.  No company I have ever seen has comprehensive evidence.  There’s no tool you can plug in and immediately “get it”.

Even among the things that can be identified, there is no one tool that can find all of them.

Stepping back, its actually a good thing that the Top 10 isn’t easily identified by a tool.  That reflects the thought and human expert opinions that went into it.  It wasn’t just a bunch of canned stuff that got put together.

What The Top 10 is Great For

The Top 10 are a great resource to help frame a conversation among developers, to be the basis for training content, to be thought provoking for people actively thinking about the issues at hand.  More than 10 items is too much.  These approximate the best ideas we currently have.  Of course there is always room for improvement but the Top 10 are a great resource when used well.

Please just understand them as a guide and not a strict compliance standard or something a tool can identify.

References

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Commercial Software Using Open Source

Matt Konda No Comments

Here’s an interesting slightly different spin on the otherwise tired “Open Source” vs. “Closed Source” being more secure debate!

The topic is inspired by a conversation with a client that is using a whole slew of old open source libraries.  They know they need to update those libraries, but it is very difficult because they are using them as part of a distribution of a commercial product that they are paying for.  So, they buy XYZ product and pay good money for it.  XYZ product brings in all of these dependencies that are problematic.  The customer can’t update the libraries because it may break the commercial product and because the commercial product is large and not open source, they can’t see and edit the code to fix issues that arise.  Ultimately, it seems like that’s the vendor’s responsibility.  But that doesn’t mean they see it that way.

The obvious avenue for recourse is to tie payment to keep the libraries up to date.  That isn’t standard contract language … yet.

Another way to hedge in this situation is, of course, to avoid commercial platforms that don’t have a strong track record of updating their dependencies.  It would be interesting to see a scorecard or standardized assessment method to keep track of which vendors and which products do well keeping up with updates in their dependencies.  It seems like it might be relatively easy to ascertain …

In this case, we have an organization that went all in on a commercial platform and even has their own code built on top of it.  Now they wonder if they should have built from a lower level base so that they wouldn’t be locked into a platform that they really can’t update.  Interesting design decision, right!?

Glue 0.9.4 and Scout2

Matt Konda No Comments

Glue

We spend a fair amount of time building and using OWASP Glue to improve security automation at clients.  The idea is generally to make it easy to run tools from CI/CD (eg.  Jenkins) and collect results in JIRA.  In a way, Glue is like ThreadFix or other frameworks that collect results from different tools.  Recently, we thought it would be cool to extend some of what we were doing to AWS.  We have our own scripts we use to examine AWS via APIs but we realized that Scout2 was probably ahead of us and it would be a good place to start.

Scout2

The fine folks at NCCGroup wrote and open sourced a tool for inspecting AWS security called Scout2.  You can use it directly, and we recommend it, based on the description here:  https://github.com/nccgroup/Scout2.  It produces an HTML report like this:

For most programmers, running Scout2 is easy.  It just requires a little bit of python setup and an appropriate AWS profile.  So it wasn’t so much the barrier to entry that made us want to integrate it into Glue so much as the idea that we could take the results and integrate them into the workflow (JIRA) that we are using for other findings from other tools.  We thought that having an easy way to pull the results together and publish them based on Jenkins would be pretty useful.

What’s Coming with Glue

Glue has been a fun project that we’ve used opportunistically.  The next set of goals with Glue is to clean it up, improve tests and documentation and prepare for a legitimate 1.0 release.  At that point, we’ll probably also try to get Glue submitted for Lab status as an OWASP project.

Automate All The Things

Matt Konda No Comments

Today I gave a talk at a company’s internal security conference about automation.  The slides are on speakerdeck.  A video is on vimeo.

The point of the talk was threefold:

  1. Explain where automation works well and examples of where we use it with OWASP Glue
  2. Explain newish cool automation like cloud analysis and pre-audit preparation
  3. Talk about how really, automation can only get us so far because we need the interaction and communication to fix things

I’d be interested to hear feedback!

 

The 10 OWASP Commandments

Matt Konda No Comments

Here at Jemurai, we have at least a few Hamilton fans.  OK, I might be the biggest … but I’m definitely not alone.

At our quarterly meeting in early April, we were talking about our window of opportunity and “not throwing away our shot”, and somehow we started talking about “The Ten Duel Commandments” song and how cool it would be to do a version of it for the OWASP Top 10.

After no more than a few days later, one of our key contributors, Corregan Brown, had written lyrics.  A week later we had an audio version.  Now here’s a video to back it up.  All written and produced by Corregan.  I enjoy it because it is factual, educational, clever and fun.  Thanks, Corregan!

Of course, this is just an artistic rendition to draw attention to the great work OWASP and the Top 10 project team has done.

Ten OWASP Commandments from Jemurai on Vimeo.

Glue Update

Matt Konda No Comments

There have been several recent improvements with Glue.  Its been awesome to have more people committing to the project and adding in different ways.

One is related to ZAP integration, which is finally getting more of the attention it needs.  Another is related to reporting to JIRA.  Still another is a way to fail builds only on certain thresholds of errors.  We have also been working on integrations for Contrast and Burp.  We’ve added a more representative Jenkins Build Pipeline integration example.

We added support to search for entropy in passwords via TruffleHog.

What would you like to see in Glue?  Where do you think we need to be to get to a credible 1.0?

Glue 0.9.3

Matt Konda No Comments

Introduction

At Jemurai, we contribute extensively to OWASP Glue and use it on some of our projects where it makes sense to tie together automation around security.  We kept seeing the same types of integration challenges and found that it was useful to have a common starting point to solve them.  It is far from perfect and we would refer people to alternatives like ThreadFix and OWTF

What is Glue?

Glue is basically a Ruby gem (library) that knows how to run a variety of security tools, normalize the output to a set structure and then push the output to known useful places like Jira.  We package Glue in a docker image to try to make it easy to set up all the different important moving parts (eg. Java, Python, Ruby and tools).  You can get and run Glue from docker as easy as:

docker run owasp/glue:0.9.3

Or, for a more helpful example, we can run brakeman and get the output as follows:

docker run --rm owasp/glue:0.9.3 -t brakeman https://github.com/Jemurai/triage.git

Architecture

The idea behind Glue is to be able to process different types of files via Mounters.  Then to be able to analyze using different Tasks, filter with different Filters and report with different Reporters (CSV, Jira, Pivotal, etc.).  Ultimately, there are the concept of stages that can be easily extended.  The reason I’m writing the post today is because I wanted to add a Bandit task and it was so easy that all I had to do was add this one file:  https://github.com/OWASP/glue/blob/master/lib/glue/tasks/bandit.rb.

When I was done, you could run bandit from the Glue docker image and push results to Jira or anywhere else:

docker run --rm owasp/glue:0.9.3 -t bandit https://github.com/humphd/have-fun-with-machine-learning.git

The following diagram illustrates the stages of the pipeline of functions that Glue performs.

Check out Glue or reach out if you want to talk about some of the common challenges in security automation.