From time to time I give talks on a range of information security and privacy issues, you can find my slides and what not here


A handy collection of my publications and whitepapers.

Tools, Scripts and Projects

Head over to GitHub to check out what I am currently working on.

Sunday, 25 May 2014

Your mountain awaits

Whether it came to you as a sudden epiphany or a growing acceptance, deciding to integrate security into your application and development culture is no minor decision.

Sure, there are people who make this choice and treat it as it’s no more complex than deciding whether to wear red socks or blue socks today. (this rarely ends well)

For everyone else, this is a significant milestone and dependent on where you on in the evolution of your product.

If you are at the start of your project, involved in a start-up or otherwise near the beginning of your applications life you have you very few technical or process constraints in place. Your technical debt collection is still more of a molehill than a mountain and you don’t have a complex hierarchy of people involved. Great!

Sadly however, unless the angel investors have shined their lights on you, you are probably fiscally challenged and unlikely to have any existing collateral, systems or tools to work with. Couple this with trading off your limited resource between innovation and development (that thing that means you can pay your bills and put food on the table) and security (more likely to cost you money than make you money) – justifications can be hard to come by.

However if you are like most organisations, far from those Greenfield days, the task of retrofitting and integrating security with your existing systems, processes and code bases can be a little on the daunting side of things for a whole range of different reasons.

You probably have a budget and a range of people and resources available (with the right business cases of course) and you may even have some tools and processes in place. However your technical debt is definitely in the mountain phase (caution, avalanches possible – proceed with care) and you have a codebase of hundreds of thousands of lines of code (representing thousands of hours of work) – that has never been touched by security.

So regardless of who you are and what your circumstances are – the first question on your journey is going to be  the same.

Where do I start?

There are two possible answers to this question.

The quickest, simplest and mostly likely to drive you to rage is ‘anywhere you want to!”

Yeah, I told you that one was going to irritate you.

The longer, more comprehensive answer is that to begins with a metaphor

Stop trying to climb the mountain in one day if walking to the end of your garden will take a week.

In short, despite feeling overwhelmed by the enormity of the task ahead of you – there is one simple truth that should allow you to start taking steps forwards.

The is no such thing as perfectly secure unless you are willing to stop doing business.

When you are taking those first steps, remember that the aim isn't for the perfect secure application after x number of days/weeks/months. There is no magic certificate that will appear when you have squashed 50 bugs or implement 3 standards. You will never achieve 100% secure and that’s OK.  Don’t aim for a lofty far away target now, make your aim more realistic.

End everyday with an application that is more secure than it was yesterday

In essence what I am describing is continuous improvement and setting realistic goals. 

Security isn’t something that is ever done or complete so don’t treat it like it can be. Security is a combination of looking at every aspect of your application and organisation every day and asking ‘how can I make this better’.

So ... where do I start?

Like I said, ‘Anywhere you want to’ but if it were me I would start with what I am working on already, the current change or feature, every line of code you write today, every quirk/bug you solve this week.

The time will come very soon to evaluate how big and complex the mountain ahead of you is,but for now, let’s start by taking one step.

Tuesday, 20 May 2014

The wolf at the door

Image: Copyright: Radiohead

Inside the security community, the web application security conversation has been active for well over a decade. The ideas and techniques for identifying and exploiting vulnerabilities in web applications are well established. Active communities of vulnerability researchers work tirelessly (or at least determinedly) to identify vulnerabilities in vast quantities of modern applications. There is a massive hacker community internationally and an ever increasing number of conferences at which new ideas, tools and techniques are discussed and developed.  

Security is a world of niches and specialists. Dark adventures down deep rabbit holes.

The world of the developer is a very different place. 

In the development world, security is part of a much broader, more complex picture. The technology landscape is vast and rapidly evolving. It has a laundry list of challenges – from scale and stability to an ever increasing demand for new innovative features and calls for reduced costs.

From tiny applications spawned from random ideas over coffee to global enterprise applications dealing with scale and availability requirements that was unimaginable a decade before. The number of applications under active development and possible technology stack permutations are innumerable. 

As security people we tend to forget about this other world. We test systems and make recommendations to address security vulnerability without any real context to support us. We demand changes and absolute control in an environment that is increasingly agile, infinitely varied and constantly changing. 

We talk loudly and passionately about application security – to a room full of people who already know about it while the development community is doing the same thing next door. 

Security professionals are not magicians, desperately hiding behind cheap tricks and praying nobody looks behind the curtain. We are deep technical professionals and specialists. Our methods are not the secret sauce, applying our knowledge to make things more secure is.
Whether you are a maker or a breaker, security or development – the time to work together is long overdue. 

  • No longer should the application security and software development operate independently of each other.
  • No longer should developers feel unsupported in their efforts to improve application security.
  •  No longer should application security be treated as less important than or incompatible with innovation, agility or flexibility.

This is my journey.

Moving from offensive application security to application defence is like moving to a foreign country. There are fragments that are eerily familiar but you will get on a lot better if you learn the language, try to integrate with the culture and ultimately leave your assumptions behind.

Conversely, welcoming an offensive security person into your software development team may feel like inviting the wolf to your door, threatening your ability to innovate, develop and deliver in an agile way.

Feel like the challenge is too big? Feel like it’s just too much work? Think it’s not your problem?

Harden up.

Our organisations and applications are at risk. We have work to do.

Twitter Delicious Facebook Digg Stumbleupon Favorites More