Monthly ArchiveJanuary 2018

Top 5.5 AppSec Predictions Sure To Go Wrong

Matt Konda No Comments

In keeping with an all too popular industry practice of producing year end Top 10 lists, at Jemurai we developed a Top 5.5 Application Security Trends for 2018.  It is obviously meant to be a little bit fun, given the “Top 5.5” title but we tried to capture what we think are significant important things to keep in mind.

#1.  Continued Framework Level Vulnerabilities

  • Expect to see additional massive breaches related to framework level vulnerabilities that were slow to be identified and patched (old and new).
  • Recommendations:
    • Actively stay up to date on libraries
    • Use a mechanism to detect in CI/CD that your libraries are aging
    • Commit to maintenance

#2.  Innovation Applying Artificial Intelligence and Machine Learning to Security

  • Expect to see more threat intelligence, smarter intrusion detection, better malware detection, improved identity – all through these technologies.
  • Recommendations:
    • If you are very mature and have money, look to these tools.
    • If you are not very mature or don’t have money, work on the basics first.
    • If you are a security company, figure out where these fit for your tools.

#3.  Changes to Static Analysis Market

  • Companies will adopt smaller, purpose built static code analysis tools
  • Companies will start developing their own tooling to perform checks in a DevOps fashion, especially for their growing cloud environments.
  • Commercial tools will continue to have high false positive rates, be too slow to include in developer workflows and will work well with only a few programming languages.
  • Recommendations:
    • Think twice before adopting a new static tool.
    • Look at the API and make sure it is usable (REST / JSON).
    • Leverage open tools to get the basics done and prove a process.
    • Teach your developers and ops (DevOps folks) ways to think about security.

#4.  Security Engineering

  • Companies will start to see the value in security libraries for things like:
    • Audit information
    • Application security signal
    • Encryption
    • Honey Data
    • Customize cloud auditing and assurance
  • Recommendations:
    • Look for places where security impacts architecture and consider building reusable component to handle it properly.

#5.  Software for Risk and Security Program Management

  • Just like companies use systems for procurement, recruiting, HR, finance and business flows, companies will start using software to help them manage their risk and security programs.
  • Recommendations:
    • Keep an eye out for these.  Try to identify your best practices and assess if the tools can help keep programs moving.

#5.5  Some Things That Should Not Be Forgotten Will Be Lost

  • Tools are never a panacea but we will increasingly focus on tools.
  • Awesome instructor led hands on training is expensive and hard to find but worth it.  Computer based training is widely hated by developers, but it will grow much faster.
  • Authorization is hard and tools don’t find gaps.  No advances will be made.
  • It doesn’t matter what you find, it matters what you fix.  We’ll continue to see a focus on finding problems instead of fixing them.
  • People will reuse passwords.  This will undermine all sorts of other controls but we won’t see substantial change.

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.

Jemurai Newsletter

Privacy Policy

Recent Comments