App Security- the great unspoken

There is no shortage of conversation around enterprise security. In light of some recent, high-profile hacking incidents, everyone’s talking about the importance of securing networks, data and devices in avoiding a worst case scenario of confidential customer or organisational information or IP being compromised. Interestingly, these conversations often neglect one vital component- the applications that operate on these systems and how their own vulnerabilities can bring down an organisations’ entire security strategy.

Despite the broad penetration of apps in our corporate and consumer lives, native app security is still very much an emerging concept. There isn’t a one-size-fits-all solution, and in an age of ‘agile’, developers (in-house and externally) are sometimes prioritising speed to market at the expense of secure technology.

So how do we navigate this? Think of application security as akin to building a house. Integrating a home’s core utilities (things like electricity and plumbing) is much easier during the construction phase, building from the ground up, rather than having to go through a full renovation to shift a bathroom to another side of the house. The same principles apply when developing apps. Security must be built into applications from the ground up, rather than a bolt-on or afterthought. When applied to agile methodology and innovation, it’s important that at each stage or iteration you ask- “How can I break this?” After all, the longer you go into iterative stages, the more difficult and costly it is to go back and fix something that was flawed from the start.

With this in mind, here are some key considerations and strategies for safe and secure enterprise app development and deployment.

1.Take time to evaluate the environment

Taking the time to define what application security looks like for you and your organisation is a natural first step. If your organisation is building industrial control systems for example, then you need to be spending a bit more time and effort on security than if you’re building basic web applications, such as a game, that won’t be storing customer, personally identifiable or confidential data.

Some questions to consider are: What data is the app storing? What type of data is passing through it? What’s the worst case scenario for vulnerability? In what types of situations could that occur? For example, if you were to experience an exploit and a hacker conducts a full memory dump or secures higher access privileges, how detrimental will that be? Similarly, if an employee leaves a mobile device in a taxi, does the network require a VPN password for access and is that password cached? Think ahead and put the right policy in place for your business. Questioning who is accessing an application and from which devices will directly inform the approach you take.

2.Lay the right foundations

When coding to secure an application, the key is to do so from the outset. While it may seem overly precautionary at the time, it’s proven that by ‘default denying’ everything throughout the design process, the application will be closed and locked down sufficiently. By assigning permissions as and when they’re needed, it will make it much easier to pinpoint the source of vulnerability if and when it occurs.

From a design perspective, while User Interface and User Experience are key considerations in the evolution of any application, they are also intrinsic to security. The goal should always be to remove the burden of responsibility from the end-user. Why? Because if they personally have to make a trade-off between security and convenience, they will more often than not default to convenience- a decision which is nearly always the wrong one for an organisation. In those scenarios where you are forced to compromise convenience for security, i.e. having users enter a VPN password each time they use an app, make sure they clearly understand the rationale behind that decision.

3.Plan for contingencies

You can have all the policies you want, but if you don’t have a plan within that policy or if no one understands it, (and you’re not educating your testers, developers or coders), you will put the organisation at risk. Planning for disaster is key and part of this means taking an assumption that someone is always watching your network, your infrastructure and what passes through it, internal or external.

Many would question why it’s worth investing in native app security when the more perhaps logical alternative may be to secure core infrastructure and shared platforms instead. The answer is, if you’re running apps on shared infrastructure, you have to assume these platforms aren’t secure and the possibility of data being leaked is very real. Take the Snowden revelations for example; what was considered internal data travelling across data centres was actually being watched and being collected.

While most organisations don’t encrypt internal communications, the Snowden leaks revealed that in order to be safe, it’s best to assume your infrastructure is open. Assume the user is on an untrusted network and design and deploy applications with that in mind. For developers working closely with an internal IT infrastructure team or cloud provider, understanding what their policies are, how often they update them, how often they validate them, and whether or not they use auditors, are all key facets to a layered defense approach to application security. Your app may be secure, but the information or platform it sits on may not be; therefore a multi-faceted strategy is needed.

Equally important is assessing what you know and don’t know about a vendor’s security history. What is their response time if they or a customer detects a vulnerability? What have they experienced before? They should have their own policy in place and have proof that it works.

A sound enterprise application security policy requires three key things - a clear point of contact for employees within the organisation, transparency in SLA of how quickly a vendor and IT department can respond, a clear mitigation strategy if the vendor is unable to respond quickly, and finally, open lines of communication - the vendor should be alerting you if a vulnerability is found, rather than the other way around. Putting these processes in place, in conjunction with a ground-up approach to app security design and deployment will mean we’re on our way to safe and secure app development. In this world, data leaks will be the exception, not the rule.

This article is brought to you the content directors for CSO Australia.

Upcoming IT Security Events

March 3rd, March 5th, March 9th 2015

Join CSO for the day@#csoperspectives and hear from @kimzetter @LeviathanSec

3 International Keynote speakers, 36 Key IT Security Industry Speaker, 21 Exhibitors, Security Analysts and many more.. Register today

Dont miss one of the biggest IT Security events in ANZ (registration is free, but seats are limited)