Monthly ArchiveJanuary 2018

Turns Out Policy in Markdown in Github Works!

Matt Konda No Comments

I’ve seen policies from lots of companies big and small.  Generally, I’m a techie engineer so I don’t love policy.  I’ve also seen a fair number of companies that clearly don’t follow their policy.  I’ve also seen companies that get certifications like SOC2 and ISO that are meaningless because they systematically lie and their auditors (not us, we don’t do auditing) never check lots of basic things we see.  Sometimes the security teams at the companies aren’t lying, they just don’t even know the truth about their own company.  I get it, there’s all kinds of reasons we can’t always have nice things.

In response to that, we spent a few years at Jemurai trying to write minimal policies that people could understand and follow.  I even published a blog post last summer about it and we tried selling a minimal policy bundle off of our website.  It seemed like a good idea at the time.  I think the philosophy was generally sound in a pure sense.

The problem is, people use policy as a defense against auditors and without more explicit direction, you can’t say you have controls around a variety of things.  You don’t even know you need to know the answer to questions about data loss protection or mobile devices in your network.  Inevitably, sooner or later someone is going to run up against a SIG Lite or a more exhaustive partner checklist or some trigger that forces them to articulate a more complicated policy.

To update our position on this, while staying arms length from auditing and full on policy work in the future, we developed policies in Markdown and published them to our private Github repo.  They look nice and everybody can immediately see what the policies are and who changed them when.  We can also track approvals using pull requests.  For smaller tech companies this makes for a simple more digestible way to get, use and publish policy.  It keeps it in a relevant and accessible place.  We can share it with their security point of contact by letting them fork our policy in Github.  They can subscribe to updates and merge our new best practices in as they evolve.  So far, this seems to be a good direction.

 

Your Vulnerability Spreadsheet Says More Than You Think

Matt Konda No Comments

More often than I’d care to say, I work on projects where a client has a vulnerability spreadsheet to rule them all.  They’re using the spreadsheet to track all of the open items that were found across all of their projects with different tools and pentests.

One initial interesting point is that these companies don’t particularly seem to consider this data to be extremely sensitive.  The spreadsheets get mailed around with different tabs for different apps or organizations to teams across the company.  Good thing we just told all of our IT and development resources where the known problems are …

Going a little deeper, I can often tell a lot about a company based on what I see in the spreadsheet.  Maybe a simple Apache web server patch hasn’t been applied in 9 months.  Maybe some teams respond and others don’t.  Maybe it’s hard to find owners or they keep shifting.

Experienced security folks can often map vulnerabilities in a report back to the tools that find them.  You know the X-Frame-Options item came from ZAP or Burp.  The listable directory too.  Content types, password fields that don’t have autocompletion turned off, JS from foreign sites, etc.  You know the drill.

Something that I also find very interesting is what is NOT in the report.  If there aren’t ANY authorization related findings or other items that I wouldn’t expect a tool to find, I can often be quite confident that either the application testing was very time-limited or the testing methodology did not include human-driven testing.  This should be a red flag.

Unless you are trying to pay for only an automated test, look for a vulnerability you know a tool can’t find but ANY tester should.  Maybe even consider adding something you can use as a canary to test the tester.  There are lots of examples but an easy one is a user from one access role or organization being able to access data or a function from another access role or organization – basically an authorization failure.  Tools can’t find these.  If you don’t have any, it might be because your testers are only using tools.