I’m very happy to be heading back to the US in a couple of months, this time to keynote at OWASP’s AppSecUSA in San Fransisco.
I had a great time in Amsterdam only a couple of months ago keynoting at AppSecEU as well and the whole event was just a heap of fun. It was a really good mix of security pros and developers, each bringing their own strengths to the show and making for some really interesting talks at different levels.
As I did on my recent European tours, I’m making the most of the time I have stateside because frankly, everything is a long way from Australia! I’ll be at the OWASP event for some of the time during the week of September 21 and I’ll be in Monterey the week before talking at SECURITYintersection on Azure and other security bits. But I’m also making time to run some workshops. I’ve been holding these across Europe and Australia for various organisations that want to get their development teams up to speed with the dos and don’ts of modern web security constructs. Let me share what I’m doing.
What the workshops are about
I hold workshops over one or two days for audiences usually between 10 to 20 people and whilst I tailor them for the organisation, they all have a few things in common. The usual event I run is my “Hack Yourself First” workshop which is squarely aimed at web developers who want to build up skills around identifying risks from the attacker’s perspective. This means they get to come at web security from the outside – here’s a vulnerable application, now your objective is to break into it. We go through attacks ranging from XSS to SQL injection to common vulnerabilities in APIs and we spend a lot of time looking at the mechanics of how these attacks work. Each day gets broken down into eight sessions and each session has an introduction to the concepts, a hands on “hacker challenge” to exploit a system and then a group discussion about how everyone went. That last point in particular is invaluable; if people just want to be talked at then they can do that from the comfort of their own homes via my Pluralsight courses, but being present adds a dynamic to learning that you just can’t beat.
Who it’s for and how it works
One of the key things that makes this workshop so successful is that it’s technology agnostic. If you work with HTTP and angle brackets (or curly braces or anything else you’re pumping out over the web), then the workshop is equally relevant whether you’re a PHP guy or an ASP.NET gal or, well, whatever because it’s all about taking an external view of the app. It also focuses primarily on tools developers use every day so that means lots of time in the browser developer tools and also in Fiddler or Charles depending on the operating system and proxy debugger of choice. It’s all on their PCs too – even when I run this at events where there are labs with custom made machines available, I get people to bring their own gear to ensure they’re working in an environment familiar to them. It’s easy for security to get too academic and the more real-world these workshops can be, the better equipped people are to actually use the knowledge in a productive way.
It’s about spending money in the right places
I love this old axiom about the cost of fixing bugs (or insecure code) at various stages of the software lifecycle:
It gets used extensively to support approaches such as agile practices but the same is true of security. If we can understand more about the business requirement and refine the spec, “fixes” are cheap. A good app sec example is account enumeration; was there ever a discussion with the business owner at Ashley Madison about not allowing the presence of users to be discoverable via their email address? That’s a very business-centric question because it goes to the heart of the privacy model they were pushing. Asking the right security questions at the right time is critical.
Design is where we begin committing to security approaches that will get written to code. Are the people involved in this phase thinking about the relative speeds of different hashing algorithms? That’s a very costly one to change later on and it’s even more costly if customer passwords are easily cracked. Oh – and if you are committing to a modern hashing algorithm that runs much slower than the old ones, does that present a potential timing attack thus trumping the previous paragraph on not allowing account enumeration?
Coding is clearly where a lot of the security challenges lie. How is untrusted data going to be handled? How is the output encoding done? Which security headers will be implemented? How will secure connections be enforced? It’s not all just coding practices either, what about techniques to assess risks in code while software is being built? One of the big fears I’ve been hearing a lot lately is security folks being wary of development teams pushing for continuous delivery. But there are ways of building process and structure into this cycle that can actually give the security guys a lot more confidence than they had before when everything was proverbially “thrown over the fence” to them at the end of the project.
The testing phase of software development is an interesting one because this is often where security begins: “Oh, the security guys need to check this before it goes live”. Now this is a good thing… so long as they’re not tied up finding low-hanging vulnerabilities that shouldn’t be there in the first place! Plus those security people can get expensive and it’s in everyone’s best interest to make their job as easy as possible and ensure they do the things they’re really good it when it comes to reviewing software. In fact this is one of the key reasons I became so focused on security many years ago; I was consistently see flaws only being discovered way down the software development lifecycle after the developers had already handed it over.
Then of course, the release cycle – you’re now live – clearly this is not where you want to be seeing security flaws in software! Maybe you’ll find them before someone else does. Maybe…
Teaching developers how to hack themselves first moves the security effort back up the stack to where it’s cheap. You’ll see different phases represented in various charts and different factors of cost (sometimes as high as 150x in the release phase) but the premise is always the same: avoid creating flaws in the first place by training and supporting the developers and that’s the best possible way of investing in software quality.
Find out more
If you’re interested in getting involved with Hack Yourself Workshops during my US travels, drop me an email and I’ve love to have a chat. Regardless of workshops, there are a heap of people I want to catch up with in SF so if you’re over that way and want to say hi then please do get in touch.