Tag Archive security

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

Incubator: Canary Data

Matt Konda No Comments

Incubator

At Jemurai, we have started incubating products.  We love security consulting and the engineering we do there, but there is something amazing about building a product.  In particular, I constantly crave the experience of pushing the limit and trying something new and a little different.  I’m even embracing marketing and failing fast.  So each month, we take an idea out of our product backlog of ideas and try pushing ourselves with it a bit.

Last month, we released a set of simple Security Policy Bundle for $249 that you can download here.  This month, we’re pushing the canary.

Canary in the Coal Mine

What is the canary in the coal mine all about anyway?  Well, miners used to take a canary with them into the mine so that if carbon monoxide levels rose enough to be dangerous, they would know.  The canary would die and they would hopefully get out before the CO caused problems for them too.

In short, the canary is an early warning signal.

How Does Canary Data Work?

The way we envision canary data working is that we provide known data that is bad.  Sounds silly, right?  Except that we track it and know who we gave it to, when and for which of their environments.  Then we search for the known bad (canary) data in increasingly sophisticated ways and when we find it, it is a strong indication that a client has had a breach (of any kind!) at a certain point in time, in a certain location, application, part of their network, cloud, etc.

By tracing which canary data shows up, we can help both notify clients early of potential issues but also pinpoint where and which parts of their operations may have issues.  Its an early warning signal.

Input?

As with any “incubator” project, we have a lot of fresh ideas about how it could work, but it will have to be tested in the wild – so we’re interested in input or anyone that would like to help us test it in the realz.  Contact me to talk further.