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!
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!!!