Last week I wrote about the OWASP top 10, and the main steps that I think make up an application / development security programme. This can be found here; http://www.kevinfielder.co.uk/security/why-does-the-owasp-top-10-never-change/
Following from this I want to discuss the security of your applications is actually so much more than the secure development and assurance lifecycle along with developer training.
Doing all of the things I previously mentioned, tailored for your environment, will ensure you have as secure an application as is reasonable possible when compared to your threat landscape and risk tolerance. However the actual application / code is only part of the security story.
So what next? Does that mean your application is secure? Does it mean it is secure in all environments?
I am a strong believer in the principle of defence in depth. Even if you believe your application to be completely secure under any circumstances, I would always recommend having multiple layers of defence. Some of these layers will be independent security tolling, and some will be within the application itself e.g. security SDKs that can be incorporated invisibly into your application.
The below list will highlight a few of the areas you should consider in order to protect your applications and the data they hold about your business and it’s customers. The list focusses on technical security measures rather than processes, which are a completely different topic.
A ‘normal’ firewall is great for providing very fast and robust IP and port based filtering. However it has no understanding of what should be sent to the permitted IP addresses and ports.
An application firewall understands the traffic your application should receive. The most typical application firewall is the WAF (Web Application Firewall), Database firewalls also exist. Web application firewalls will automatically be able to protect your web applications from known attacks like SQL injection.
A further benefit is that specific rules can be created to protect against specific vulnerabilities that may be discovered by your code analysis tools or pen tests. This can aid speed to market by protecting your application while a fix is worked on.
The key thing here is that the WAF (or DB firewall etc.) will sit between the users of the system and the application, ‘proxying’ all the connections and alerting on or filtering out malicious traffic before it even gets to the application.
While this may seem outside of the application, and indeed the SIEM / log monitoring part is, logging the right information is critical. Unfortunately it is often overlooked.
Do all of your applications log enough information about enough events to provide real security value? This means a lot more than just things like logon / logoff. Any ‘security’ interesting activity such as administrative activity, user creation, permissions changes should be logged. Also consider user activity, so that there is a clear audit trail for whom undertook which actions.
Just as importantly is this in a format that can be ingested and analysed by your security log monitoring systems? Ideally if you have multiple applications your organisation develops you should have a standard logging format, this would be facilitated by creating / using a common logging API for all applications.
As a final thought on logging don’t forget that for the security team to be able to provide useful alerting from the logs, they need to understand what good and bad look like to your applications.
Server Application control
While perhaps not strictly ‘application’ security, a key protection that rarely seems to be implemented is strong application white listing and application controls. I mention these as I think they make a key part of the overall protection and I had omitted to cover them in detail previously. Servers should have a pretty static application lists so the overhead of running whitelisting controls should not be excessive once in place. The other benefit of these solutions is they also understand how many applications should work, so they can prevent even compromised commercial applications from misbehaving. This should be seen as a key protection for any high risk application servers in your environment, especially those hosting internet facing applications.
Mobile application and device protection / analysis
This is one of my current areas of interest. How do we protect mobile applications that will be installed on fundamentally untrusted devices? This can apply so normal Windows / Mac apps as well – see below.
So your application is ‘secure’.. Some questions to get you thinking about the environment a mobile application will run in;
- How secure is it if the mobile device is compromised and there is key logging software on the device, or man in the middle software that changes the users inputs before sending them to the server etc?
- How do your servers know if the application talking to them is your application or an exact copy of your application that has malware added?
- How does your application stay up to date to detect the latest rooting / jailbreak methods and malware?
- Does the behaviour within the application look like a human user, a bot, someone remote controlling it?
It is to enable us to answer these questions, and more, where mobile application security solutions come into play. I’ll not cover these in detail as there will be an upcoming post very shortly to cover this specific point in more detail. Suffice to say if you run mobile apps that handle any sensitive data or transactions etc. this an area you need to be all over. This also has multiple wider benefits highlighted further down this post.
Remote host security (if you supply an application to them)
This is a similar idea to the mobile security one. With the continuing malware epidemic across Windows, and the increasing prevalence of malware on Mac and Linux protecting your applications on remote machines should be investigated. Again, this is especially relevant if you supply an application that processes sensitive data of any sort.
On one hand you could argue that the security of the end point is your customers responsibility, and you would be correct. However given the challenges faced by most people, especially in the personal or SME markets is this a realistic stance to take?
Given the ease with which you can integrate a host protection SDK from one of the many vendors out there, I would certainly recommend looking into this option, especially if you charge your customers for the service.
Remote browser security
This is where we look at options for securing, or at least monitoring the remote browsers that connect to your web applications whether from mobile or more traditional desktop devices. This is the area where we have least control, as we are not installing anything on the remote device.
However all is not lost, we can insert various security measures into the page to look for potential browser issues, ID the browser and machine, and perform cool things like in field encryption.
As with the mobile security solution I would recommend that you investigate commercial options here as they will keep themselves up to date against evolving threats and also provide a wide range of added functionality like risk scoring, automated blocking etc.
Also as with the mobile security I’ll write about this in more detail, as in my experience this is overlooked by the vast majority of organisations.
This one shouldn’t need any introduction. In this case what I am referring to is the confirming to an appropriate level that a users is who they attest to be. There are however many pitfalls around authenticating users of a system. Obviously ensuring someone is who they say they are is key to securing your applications and their users.
The added benefits of supporting better authentication than passwords are much broader than just being more secure. You can offer a much better journey for your users, with reduced or no friction for many activities. You can also gain a lot of useful data as many authentication solutions collect extensive data around the user and device to enable risk based authentication.
Don’t forget, how you do authentication is also incredibly visible to your users and one of the first ways they interact with you every time you use the application. So this is a great opportunity to both provide a great impression and to highlight that you take security seriously right from the ‘front door’.
Authentication is another area I will be covering in more detail as it is critical we move away from passwords.
Consider the multiple wider benefits of remote security solutions and authentication;
- More secure customers = better security for you.
- Offering security = differentiation and potentially something you can charge for.
- Data Data Data – the more data you have about your customers and their behaviours, the more interesting analytics you can perform.
These benefits all apply to mobile application security solutions, remote host security, remote browser security and to some extent new authentication solutions. I briefly explored some of these in my earlier ‘Extending the Perimeter’ article, and will expand further on these in following posts.
Don’t forget that this is all in addition to all the ‘standard’ security stuff you must be doing anyway such as Firewalls, IDS/IPS, anti malware / host security, standard hardened builds, vulnerability scanning and patching etc.
If you have been following my last few posts, you should have a good idea of the basics required for general and application security, plus a few more advanced thoughts from this post. Once you have these security basics in place, you can then start looking at the even more interesting stuff! This includes network and application behavioural monitoring and big data analytics.
As always, do the ‘basics brilliantly’ before spending too much time on more advanced security. Malicious individuals and groups will tend to go for the low hanging fruit. Even if they are specifically targeting you, they will look for the easiest way in. No amount of advanced, behavioural monitoring will protect you if you’re hosting unpatched servers on the internet with single factor authentication and simple passwords!
More next week!