Having our heads buried in application security most days, we find that if you are not careful, you can get very technical about application security and forget about the people, money, risk and business priorities side of security. Let me explain that for a moment. Like in everything in life, security is also not black and white, rather shades of grey – what may be perfectly adequate in one scenario may be a big no, no in another.
Let me give you an example us parents can relate to which explains my point - whilst it is perfectly acceptable to send your responsible teenager to the corner store to pick up milk when you run out, it is completely unacceptable to have your pre-schooler complete the same task. The task is to have a child go get milk from the corner store – same task, merely an age variable. If we think about this in the security sense, you can see where I am heading. To be black and white in application security decisions can lead to poor decision making, unnecessary complication and wasted resources.
In our practice, we have found over time that it’s important that developers when building or choosing security solutions, consider other aspects of security (besides the technical one) when picking the right one for their business and organisational situation. Our advice is that developers should appreciate and understand the wider context they are working within when making security decisions. In a nutshell, its important to be pragmatic when making these decisions.
Here are a few principles which guide our application security practice which we would like to share with you.
1. Don’t get stuck on hard and fast principles
Dogma – a principle or set of principles laid down by an authority as incontrovertibly true
Absolutism - the holding of absolute principles (in security)
Consider this – the argument regarding the common and widespread use of Java Web Tokens (JWT) and their potential to create a security gap. There is an argument built on not using JWTs in local storage and it goes something like this –
JWTs are the same thing as a username/password and if a hacker can get a copy of your JWT, they can make requests to the website on your behalf and you will never know so don’t ever store them in local storage.
The conclusion, clear message and absolute position here is never use JWT in local storage. Keep in mind these are widely used in development. The issue with this advice is that it does not allow developers to consider the nuance of the situation they are using it in. Here is a counter-argument to this –
Where you store a JWT is really not that important and storing it somewhere deemed “safe” does not in itself ensure it is secure. Perhaps as a developer, you should ask yourself what is the information you are placing in these JWT’s, how are you accessing these and in turn, what are they accessing?
Depending on your answer, you can then decide whether using JWT is the right way forward for your application – if the data being stored is not personable, identifiable data then maybe JWT is ok, if not, then go find an alternative.
That’s what we would be looking at when assessing your use of JWT’s when completing an assessment of your application – not dogmatic nor absolute, rather pragmatic. Don’t get so caught up in hard principles – they can be your friend, but not always.
2. Don’t believe anyone who tells you its watertight, foolproof secure
Believe us when we say there is no such thing as completely secure, rather we talk about secure as “so far as is reasonably practicable” relative to what is being protected.
In simple terms, based upon the value of the data being protected, the protections you build around this should be in proportion to the security placed around it. The best type of security creates hurdles for hackers which are higher than the value of the target to them, thereby making them unattractive targets.
When developing applications, it really puts you in good stead to consider the value of the data being collected and stored before creating appropriate security measures which reflect the value of the data being protected.
3. Know what you are up against and your exposures
When you know what you are up against, you are in a far better position to assess the risk to your assets and know what to do to protect these assets and reduce the risks. Interestingly, we know that hackers can range from kiddy scripters and automated threats all the way through to state-sponsored hackers but unless you are developing programs which are of significant financial value or sensitive government work, as a developer, your likelihood of attracting any hard-hitting hackers beyond your kiddy scripters or automated threats is pretty low. This knowledge should guide you in understanding the threats you face.
Beyond hacking resulting in a data breach, your application may be more vulnerable to a DDOS attack, if so, explore what this would mean to your organisation – will a DDOS attack result in taking your asset offline thereby creating significant embarrassment to your company and result in reputational damage?
4. Take a measured, proportionate approach
It may sound obvious, but you need to consider what you are up against – by knowing the risks, you can then consider what sort of security plan makes sense. When considering what is an appropriate level of security, the risks you face is important, but so is your budget and what it affords you. Questions you should be asking are
Your responses to these questions will decide what level of security is reasonable. If the value is low, keep it to basics, if it is high, you need to consider advanced security measures and if it is a mix, create a hybrid which accepts compromises in some areas and needs advanced measures in others.
In summary, it is clear that we cannot be absolute or dogmatic in our approach, rather pragmatism saves the day. When considering the risks you face, think about the value of the asset you are trying to protect – both to you and hackers before implementing a security policy which is proportionate to the risk, its value you and the resources you have at your disposal.
