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.