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.

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.

Twitter Delicious Facebook Digg Stumbleupon Favorites More