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, 18 January 2015

AVA - Now open source

This is a quick post to say that I have taken the plunge.

Warts and all AVA is now open source and ready for contributors.

If you have time to help with docs, direction, hosting and tenenting, coding, testing, UX or general monkeywork ... I need you.

Before you all go plough through it though I wanted to give a brief message and ask a favour.

AVA is really special to me and I am working really hard to make an amazing tool for protecting people. That said I am a security specialist not a software developer... I've never written something like this before....

My code is ugly and broken and probably an absolute mess. There is no testing and I know there are gaps in functionality. 

I sort of believed that AVA would vanish and nobody would be interested... I never knew it would go this way.

So here is my plea, please be kind. Open sourcing this rather than hiding is the hardest thing I have ever done. Admitting my failures and my codes state is terrifying.

So, please be kind. I need your help. I really do. But there is a vulnerability in doing this that I can't shake.

This will be an amazing tool. I just can't do it alone.

You can find the repo here:

P.S : Any sensitive bits commited are dead and not used in anything public - don't get all excitable now.

Thursday, 25 September 2014

Shellshock - Evolving the vulnerability disclosure response

For those of us in technical or security roles, today has been quite eventful.

I won't join the hundreds of other security bloggers writing about the details of the Shellshock vulnerability. There are many awesome information sources out there that will explain it in great detail.  Here are some particularly handy ones:

I even spoke to ITnews for business Australia about it. You can read the article here.

For me, today was interesting as it reinforced how the vulnerability disclosure world had changed in the last 12 months.

When Heartbleed emerged in April 2014, complete with logo and human readable website - suddenly the world was able to understand and talk about a security vulnerability. For the first time, non-security people were aware that there was a problem, that problem was serious and they knew it's name.

Today, when the vulnerability now known as Shellshock came into the public consciousness there were expectations. Clients and contacts wanted to know what it was called and where to find a simple understandable set of remediation options. The example set by Heartbleed had set the bar high and the security community scrambled to keep up.

As security professionals we talk about the value of patching and monitoring for security vulnerabilities a lot. Our clients know that part of growing a resilient and secure organisation is accepting that your technical stack is a complex entity that contains issues, not all of which have yet been found. We teach the importance of knowing what libraries, applications and components are in use, what versions are present and where to find new updates....

We teach this regularly but we do a really poor job of it.

You see there is a practical issue here. Knowing that you should do these things is not the same as being equipped with the skills, tools and support to do so.  Security vulnerability becomes something you know about but feel ill equipped to fix. Not ideal for anyone involved.

So what can we do to improve this?

Within the security community we have to watch the way we communicate when security vulnerabilities are disclosed. In addition to the technical information sources, we need to prioritize plain English trustworthy and accessible disclosures for non-security people. This information needs to link to trusted technical sources, contain information on what is known/assumed and provide guidance on remediation. If remediation or patches aren't yet available we have to help suggest interim solutions.

Most importantly however these disclosures need to be regularly updated and free from advertising and product placement. This is not the place to sell border devices or audit tools.

Within the greater technical community, I encourage you to come find a friendly security person (we exist, I promise) and explain your needs, your concerns and your situation. Help us to understand what you need to get you patching regularly and monitoring security information sources.

Show us how to help you.

Sunday, 14 September 2014

SafeStack and Microsoft TechEd 2014

It's been a busy couple of months!

Wondering where I have been and why you haven't seen much on here in terms of articles? 

Here is what you've missed:

1) I have launched my own company SafeStack ( specialising in Agile Information Security. This has been an amazing (but scary) experience so far. Look out for more from SafeStack and follow our year long #startupsecuritychallenge on twitter to get your organisation going on its road to security.

2) I presented at Microsoft TechEd 2014 and Codecamp Auckland. In fact over that 5 day period I gave 3 talks. You can see the slides to these (and maybe video when it becomes available) over on the presentations page. I was even lucky enough to get a little news coverage!

Don't worry. After a brief rest period, I will be back with  more articles and maybe a little downloadable treat.

Tuesday, 22 July 2014

Addition, Adaptation or Abandonment

At the core of introducing security to an environment is change. Change is an interesting and sometimes scary thing, especially if you are meddling is someone else's workflow or domain. 

So how do you handle this change when what you are proposing involves the developer’s workflows?

In short, you have to make very conscious decisions about what you add, what you adapt and what you abandon.


Bringing security practices into an existing development team is challenging. Agile development workflows are very structured and have very little slack space built in. The Sprint velocity may have been finely tuned over a number of iterations and adding new items to the Sprint is an exercise in balance, compromise and communication.

The most important consideration when adding to a lifecycle is the cost and frequency of the activity.  Costs need to be measured in both terms of activity completion and the additional costs levied as a result of delaying or providing less resource to other functions.

Additional activities need to be roughly scored before they are proposed to the team. This score may mean that the number of stories loaded into Sprints may need to be reduced to compensate. Trust me when I say that this will be a challenging conversation to have.

Copyright - Scott Adams (

Scoring needs to be carried out in conjunction between security specialists and development leaders. It needs to factor in the ramp up or education period for the new practice as well as whether the change will impact on story development. Blocks introduced to processes need to be found early and addressed.

Examples of activities that are likely to be added to workflows include outsourced security services such as penetration testing and security vulnerability management. These include processes for triage, prioritisation and scheduling remediation of vulnerabilities as they are identified. 

Often, these tasks do not naturally exist in standard development workflows or require integration with other groups, teams or individuals outside the development areas themselves.


The cost of adding items to workflows is quite clear. If something additional goes in, something has to give in return. Basic 'physics says no' rules apply here.

Is it better therefore to adapt existing rituals, artifacts or workflows to include security focus points?

Godzilla vs. The Coffee Shop

Imagine you went to the same coffee shop every day and ordered the same drink. Bob the coffee guy writes your name on your cup, puts it on the queue of other drinks being made and eventually a lovely hot caffeinated beverage appears on the end of the counter. Bob calls your name and off you go. Job Done!

What if the coffee shop was suffering from a case of sticky fingered clients? Drinks are going missing and Bob is getting into trouble. Something must be done.

Security to the rescue

A simple sounding adaptation to this process would be to change the final delivery stage. In our new process, the name is called and the customer must provide their receipt to collect their drink.

Do we now have a secure warm drink filled utopia? I don’t think so.

The customers are feeling inconvenienced and are proving to be quite bad at remembering to keep their receipt at hand. Bob is slowed down by the additional checks and hot drinks are queuing up on the exit counter and rapidly going cold. Furthermore, nobody feels empowered or trusted.

The process was adapted for security but in making a change like this was security chaos theory in action. One tiny butterfly-wing-beat of an action and Godzilla destroys a perfectly good coffee shop.

Objective focused adaptation

Simply put, if security start tweaking and adapting processes without fully analysing and understanding the situation then small security gains will come at a massive cost to the organisation.

If you need to adapt an existing process, work with the process owners to figure out how best to do that. Keep your adaptations focused on objectives not activities.  Nobody knows the current process and its constraints as well as the people living it every day. Don’t assume you know better than they do, communicate your needs and support them in helping you meet them.

Keep it simple when it comes to adaptation

Sometimes the simplest adaptations can have the greatest return.

For example, tagging or labeling all tickets that come through your work tracking system (i.e. JIRA or equivalent) with the word ‘security’ allows any developer or technical team member to quickly identify and flag security related stories. This simple label is the enabler for custom dashboards and work flows. It can be used to trigger additional code reviews or make anticipating security consultant support requirements easier.  Best of all, anyone can do it. No special skills or tools required.

When adaptations go bad

You've adapted a process. Your confidence is high. The only possible outcome is improvement right?

Making the change is the simple part, then it's up to you and the teams to monitor the process closely to see if it’s working. Continuous improvement (or learning from your mistakes) is a core of agile security as much as it is agile software development.

Simple things like choosing the wrong name for a process, ritual or artifact can cause confusion and inefficiency. Be prepared to react if your dream plan goes horribly wrong and react quickly.  Process change and adaptation takes time and is often done is increments. If you are changing a ritual or process that has been in place for months or even years – you will need to provide education and support to manage the transition.


So there was no good way to add to the workflow or adapt an existing process, is that the end of the story? Is the situation impossible?

Sometimes as security people the tools and processes that we are used to are just not made for your circumstances. They may be cumbersome or costly. Perhaps they need dedicated specialist resources or dedicated maintenance and monitoring.

So why don’t you abandon them altogether?

Focus on what really matters

Security is an evolving profession. 

The tools, techniques and methodologies we have are the product of years of work by organisations and individuals with a wide range of constraints and operating environments. While they are tried and true for a lot of circumstances, that may not always work for your organisation at this time.

Instead of focusing on your inability to integrate a certain activity or practice with your development lifecycle, focus on what those activities were trying to achieve and what risk they were protecting you from.  Once you have your objective in mind, invent something new.

Experiment, Assess, Adjust

Once you start focusing on what you what from your security practices in term of objectives - design processes and controls that suit your situation. Try them and then assess the situation. Did you meet your objectives? Did your risk level reduce? If you aren't where you want to be – adjust and try again.

Nobody knows your organisations security risk better than the people in it. Security specialists are here to support and empower all technical disciplines to build their own secure development environments and workflows. We want to make you better, faster, stronger and more secure - one change at a time.

Wednesday, 25 June 2014

Is my application secure?

The one question that security consultants and penetration testers are asked regardless of how big or mature their clients are.

Four simple words. 

In fact in the security world it is the most complex,  loaded  and generally misunderstood question we have.

A case of complexity by semantic ambiguity. 

In essence, there are multiple possible meanings for each word in the question. Each of these meanings would result in a different answer.

So let’s break it down

First Word: “is”

In literal terms, ‘is’ is the present tense singular participle of the verb ‘to be’. It literally means, at this moment, right now is this true.

Utterly irrelevant but lovely none the less.

Unfortunately, that’s not what organisations want to know. They want to know if they will still be secure next week or next month. They want to feel a sense of ongoing assurance. This assurance simply isn’t reflected in this question.

Ongoing assurance means continuous assessment, monitoring and evaluation. It means understanding your threat environment and how it changes over time and most importantly it means having enough visibility over these things to know if something changes or a threat is present.

‘Is’ speaks of certainty in a brief moment in time. We live in a constantly evolving threat landscape. ‘Is’ has no place here.

Second Word: “my”

Unless you are involved in writing super specific secret squirrel type applications (or you’ve never released anything), your application doesn’t operate in isolation.

The infrastructure you run on may be managed, owned or maintained by someone else. You may be on shared hosting or on a massive virtualised cloud host. You run on top of an operating stack of applications and services.

You probably didn’t write all of the code you use (and that's OK)

Your application is most likely a collection of libraries and dependencies – the majority of which you have no visibility into or control over.

Do you receive or send data as part of your application?

Perhaps you query web services or take feeds from information sources. Once again, while you control the receipt and processing of information and the components that make queries and send data – you are reliant on a third party.

So is it useful or sensible to isolate your application in this way?

Clearly, attempting to resolve the security issues of third parties is the road to madness, however the risks inherited by your application from the interconnected network of components, data stores and processes needs to be consciously managed.

Third Word: “application”

Whether you have an actual application, piece of software or service you provide there is simplicity in this question that does you a disservice.

When simply called an ‘application’ you imagine a single tangible unit. Clear definitions and scopes and the stuff of sales brochures and glossy advertisements.

In reality, there is inherent complexity in any piece of software we write. Every configuration option you implement and every fine-grain permission you include adds to this.

Imagine you sell your product to 3 customers. Do they each use it in exactly the same way, with exactly the same configuration? 

Is this difference significant? 

Is the attack surface and risk profile the same? Given the amount of configuration and customisation you allow – are they still the same application? If you didn’t know they were the same code base under the hood – would you believe they were related? Would an attacker?

If your application has just 7 customisable options to change the authentication or business logic flow... that's 5040 distinct permutations....each creating a different attack surface. Still think adding a new technical configuration option is a minor change?

Is it really the application itself that you are interested in or is it perhaps the information you store behind it? Are you protecting 100k lines of code or is this a neatly woven facade protecting a nest egg of a different type?

Is it even the information you store that you care about? What about your reputation or that of your company? Can you identify what scares you? What are your fears?

Forth Word: “secure”

That just leaves the most loaded word of all.

How do you define secure? Is secure to you the absence of vulnerability or the conscious understanding and management of your exposure?

Can you measure security? I’m not talking in the formal governance and maturity model sense. Can you, right now put a measure on the number, complexity and relevance of the vulnerabilities in your environment?

Is a high number of known vulnerabilities > a small number of unknowns?

Can you give a binary answer of whether you are under attack at this exact second?

Yes or No?

The clock is ticking. I can only accept your first answer.

Can you account for the thousands of variables that are moving within your organisation, operating environment and the online landscape at any moment in time? Can you simplify that down into a heat map or a tick box?

The secure label is an ambiguous, subjective over simplification.

So don’t ask if your application is secure:  chances are that isn’t what you really want to know.

Saturday, 21 June 2014

Not waving but drowning

There is a point in every transition into security conscious development where you look at your bug tracking system and despair.

It doesn't matter if you have fancy SaaS project management tools or a stack of crumpled aging post it notes to convey the message. The end result is the same. You have way more vulnerabilities than you expected and they just keep coming.

Whether you are talking about technical debt, performance scaling issues or security vulnerability backlog, the reactions, the stresses and the neurological processes all come to the same end point.

There is a primal urge at this point to run. Flee. Take your desk menagerie of trolls and assorted family oddments, pack your little bag and leave.

In fact, there is some deep psychology and neuroscience at play here.

So if you want the ‘buck up, you’ll get through it speech..’  move along, there’s nothing for you here.

Let’s talk science.

Specifically, let’s talk about bears.

OK so we’re not actually going to discuss bears (though that would be cool). Imagine if you will that you are stood alone in a forest and faced with a bear. Not the cuddly picnic basket stealing variety obviously. This is the 8ft tall,  eat your entrails for breakfast sort of bear and today you happen to look a lot like lunch. 

At this point, your body is physically and chemically primed for action. Non essential systems such as digestion are being slowed down and bodily systems used for physical activities such as fighting or running are getting super charged with a potent cocktail of adrenaline and other chemicals.

In a fraction of a second, your body (with your help) will decide whether you are going to go head to head with your furry aggressor or flee in the hope of living another day. 

This is primal stuff

While for the majority of us, fighting actual bears isn't in our day to day schedule, this primal fight/flight mechanism comes back to us when we face a wide range of stresses... including dealing with our security and technical debt.

There is a predictable curve when introducing security into an organization.

To begin with, the feeling (perception) of security will exist to some extent within your organization. You have a certain degree of confidence. You may have never experienced a security breach before. You may have caught minor issues before and resolved them. You know there is work to be done but you aren't aware of how much. 

Then the security programme starts. 

Systems and processes begin and security vulnerabilities begin to appear. Initially these are slow to come and easy to manage. You feel empowered and in control. Education and training begin and external testing is somewhere on the calendar.

Your developers are engaged and learning security practices. Your systems are running smoother and the number of vulnerabilities is climbing quickly. The initial glow however is fading and the prioritisation of issues for remediation is becoming complex. There is a balance to find between remediation and business. Important conversations are happening and compromises are being made. The number of fixed issues is slowing.

And this is where you find yourself. 

As the pace slows and the process negotiations commence, it can be difficult to feel like you are moving at all. You may watch the dashboards and issue trackers and feel helpless or angry to begin with... eventually the fear will come.

Confidence begins to dip.

Can we fix these issues?
Can we get the process right?
Can we find the balance between business and security?
Can I do this?

And fear... leads us back to bears.... fight or flight. 

In my experience, flight is the most tempting and is certainly the easiest option. Find a new job, find a new challenge. Walk away.

However, if you are in this position, if your bear is in front of you and you are scared.. I urge you to fight. It's a hard road and a long one. You will be wounded and exhausted before the end I have no doubt. Despite your sunny appearances at meetings - inside you will be convinced you are drowning. Endure.

Can I tell you a secret?

Everyone in a defensive application security role feels like this at some stage. For many they feel like this on a regular basis.

As an industry we need to accept that defense is hard and start talking about it. You are not alone in your struggle.

Introducing security is not the easy path but it's the right one. It's a path that needs strong people and leaders. It needs people communicating honestly and helping each other. It needs us to notice when those around us are not waving but drowning.

It needs people like you.

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.

Twitter Delicious Facebook Digg Stumbleupon Favorites More