Startup

JASP Meta: November 2018 Edition

Matt Konda No Comments

Building JASP has been a really interesting experience for all of us at Jemurai (https://jasp.cloud).  This post captures some of what I think we’re seeing and learning right now.

We bootstrapped.  Lots of people think raising venture capital for an idea is the best way to build and grow.  We still bootstrapped.  That means we paid for all of the development of the tool by also working our tails off on client projects.  Some of those client projects were cloud security audits, and that’s where the whole idea came from.  Keeping close to clients needs has actually helped us.  Bootstrapping also means we’ve stayed very lean.  Which I hope means the team feels an organic sense of ownership and learning as we go.  We’re hungry.  Not scared.  But hungry.

As consultants and engineers, we are sure there is a lot of value in the JASP tool.  It makes it easy to find and fix AWS security issues.  It provides ongoing visibility and notifications when something isn’t right.  We have learned a lot from the awesome tools listed below in the references and you can run a lot of those by hand to get some of the results JASP gives.  But you have to figure out how to run those tools and digest the results.  We tried to build a tool around a lot of those same ideas that would take away a lot of the complexity of running the tool and exchange that for clearer information and resources for the user.  We believe there is a significant need for easier to use tools that don’t take a dev team or DevOps process and pull them out of the things they know.

I believe someone can get started in JASP in < 10 minutes and get the benefit of daily checking and alerting around AWS security items, for a price that is a small fraction of having someone do it by hand.  – MK

What I am personally learning is that having a tool with value isn’t enough.  I can show people the results, help them fix real security issues and while they are happy to have fixed them – they don’t necessarily feel a clear and present need to buy the tool.  It is still a “nice to have”.  Even most people who might want to try it for free can’t make the time.  People that do try it for free, rarely opt in to purchase unless they need the deeper support we can provide at the higher tiers.  It could be discouraging but I understand, there is so much noise and everyone is so busy, we need to make it easier and find the best ways to communicate about it.

Of course, one big goal was to be able to provide this value in a leveraged way, with a software platform.  We didn’t want to be constrained by what our team could do by hand.  (And of course, we wanted to be a SaaS business with a great hockey stick J curve)  So we’ve been trying to find ways to get the message out about our product.

As we’ve engaged with firms to help us with marketing and growing the idea beyond our technical ideation, we’ve learned more.  We digested their suggestions and it is clear that almost any framing of the tool comes off as a gross oversimplification.  Very common advice is to scare people or drive people to the tool with Compliance.  There’s a place for fear and compliance, but I told myself a long time ago I didn’t want to be one of those security firms.  I hate the idea of using people’s fear and ignorance to get them to buy my tool.  From the beginning, I have wanted to find developers and put tools in their hands that made their lives remarkably better.  I wanted to approach security as a constructive partner, helping people to do the right thing with a positive spin.  I believe by approaching the space this way, we can earn long term trust from partners.

But of course, like I said we also want to grow beyond what we can do directly with word of mouth.  So, following marketing advisors input, we have run ads on various platforms.  We have tried several messaging approaches.  All suggest that what we’re doing isn’t resonating for people in a major way yet.  We have done a couple of feature releases we think might help (better prioritization, user management, dashboards, reporting) but ultimately, we’re at that place where we’re not chasing users by adding more features – we’re trying to find the right messaging, framing, pricing, etc. to make the tool relevant and useful to people.

When I started my career, I hated having to build new features that sales people had already promised to customers.  Now, I’m laughing at my old self and thinking about how hard I would work for each new customer.  That’s not to say I am willing to lose my identity chasing them, but I definitely underestimated the complexity of building and running a software business – in particular the ability to engage with customers and have lots of great learning conversations.  I assumed that with a free tier in the tool we’d be having lots of those conversations.

There is a lot more to do here in terms of building a platform for automation.  The vision has always been to be able to do Azure, GCP and even integrate Glue for source code analysis.  We want to make these kinds of analysis really easy so that they just show up where developers need them.  We want to be an API first backbone for security automation that makes it possible to quickly apply new tools, rules, etc.  Yes, we can build some of these things into one off Jenkins jobs or run them as scripts, but there is a lot more value when the results are aggregated, stored over time, compared to industry standards, and get escalated with support to fix.

It will be very interesting to continue to learn what the industry has an appetite for.  The good news is that it’s all been fun along the way and its the journey not only the destination that matters.

References:

https://github.com/SecurityFTW/cs-suite

https://github.com/toniblyx/my-arsenal-of-aws-security-tools

https://github.com/nccgroup/Scout2

https://github.com/toniblyx/prowler

https://github.com/owasp/glue

JASP 1.0.3

Matt Konda No Comments

Today we’re publicly releasing version 1.0.3 of JASP, our cloud security automation tool:  https://jasp.jemurai.com.

We think of it as “we’ll watch your back in the cloud“.   We currently work in AWS and check for common security issues across EC2, S3, and RDS and many other services.  You can sign up on the website and get free checks right there.  To get monitoring or extended reporting, we are offering several tiers of paid subscription plans.

We’re working hard to price it such that it is consumable by a general audience and not just hyper secure environments with huge budgets.  Part of our mission is to democratize access to security tools.

JASP is the culmination of a ton of work on the part of our team.  I want to pause to congratulate them for the accomplishment of building a tool that can help a lot of companies build more secure environments.  We’ve been through a lot.  Thanks, Team!

It is just the beginning.  Our roadmap includes tackling other new environments like Azure, GCP and even considering going after AppSec Automation.  We see the platform as a center of accessible security automation.

If you can, take a moment to check it out and give us feedback.  Its for you!  Happy Friday!

Product Security in Github Issues

Matt Konda No Comments

As I’ve mentioned here in the past, we started working on a product in 2018 and we are getting really close to launching it more openly where people other than our initial (friendly) alpha customers can use it.   The reaction has been awesome and we’re encouraged.

As I looked at our project, I realized we needed to step back and really confirm we had our basics covered.  Now mind you, we’re all security oriented developers so I’m not saying these things weren’t done by our team – but I will say that even I, as a leader and someone who gets on a soapbox a lot about pushing left, had not explicitly emphasized or required these things as first class features yet.

So I thought I’d share a bit of detail about our thinking here.  We basically wanted to take the simplest possible approach to something that would work.  So I brainstormed a bit on some general items we always care about and added github issues for them.

Note that this not an exhaustive list.  We have more detailed requirements about authorization for example in each story.  We also have items to check for things like sql and code injection.  But I wanted to start simple for this discussion.

  • The Twitter password exposure notification and the emails I received as I dutifully reset my password inspired #36 here.  Basically, if we notify people properly we can let them help us identify issues if they happen.
  • Implementing two factor is pretty basic now and should be required for most if not all public apps.  We will think about social logins as well, but we’re not sure if that is relevant yet.
  • Knowing about both failed password attempts and successful attempts after a lot of failed attempts is interesting and will allow us to see brute forcing.
  • Setting security headers is easy and should be automatic.  Let’s make sure we do it.
  • Force SSL is self explanatory.
  • Verifying that we have secure and httpOnly set for session cookies is easy once we think of it.
  • We’re using Vue.js for the front end.  Let’s stop and make sure it is handling malicious script inputs the way we think and ensure that our API’s are encoding data as needed.
  • If we’re storing sensitive information, let’s talk through and document key management and algorithms as a team.
  • Let’s build a threat model that we can use on an ongoing basis for each different app component.  We’re thinking about threat dragon but I generally just use a mind mapping tool.  I think I’ll write a whole post about these.

Anyway, if you’re working on any kind of web application, most of these apply in one shape or form.  Reach out to me if you have questions.  Happy building!!!