Thoughts on the latest NHS “WannaCry” exploit – could it happen again, could it be worse and what lessons can be learned?
NHS “WannaCry” exploit – It could happen again and it could be worse!
This week we have witnessed the wide spread hacking of computer systems, this has had widespread implications to us all as individuals, at the most fundamental level – our health.
This is a huge wake up call primarily because much of this could have been prevented. Luckily it really only impacted old Windows XP machines, so its target was limited.
What is the next big risk? We believe that the slow rate of adoption of Application Firewalls is putting many applications at serious risk.
The WAF (Web Application Firewall) has been around for a while, it’s job is to protect web sites and applications from specific attacks.
A web server is a strong target for an attack because they are typically accessible from both internal and public networks. They run on powerful server hardware and, unlike a user’s computer, they are always on! What a great place to launch a malware attack, such as the type recently seen with “WannaCry” and the NHS.
Although now a standard component for the Enterprise, user adoption for the SME and mid-market has been slow, in part because WAFs have been perceived to be complex and unnecessary at this level.
Standards such as PCIDSS, which specify that Application Firewalls are required for credit card payment systems, have accelerated adoption for financial institutions but this is just one area.
What does this mean for the rest of us? The simple fact is, hundreds and thousands of web applications are vulnerable to Layer7 web attacks.
Whilst most companies have a traditional firewall in place, blocking access to ports and applications for external connections, there are also applications designed to be accessed by the general public. A web site is the most simple example of this.
This means you can open the door and let everyone access your web server. How do you know that what they are requesting from your web server is valid? How do you know that they are honest? How do you know they are not just directly hacking your server and your only defense (the last line of defense) is the hope that your server is on the latest patch, and further more, that your application or website is written by a security trained developer.
You may say that you have your site secured, possibly by a user login. But where does this user login challenge come from? Unless you are using a Pre-Authentication server or SSO (like jetNEXUS) then your login challenge will come from the server you are trying to protect.
So yes, it is like letting people into your house but not letting them into the kitchen unless they give you the right password.
The job of the Web Application Firewall is to analyse what users are asking of the web server and also what the web server is responding to the user. This is checked against known attack types and either blocked or allowed to proceed (a list of the top 10 critical web application security risks can be found here https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).
This is very different to a normal Firewall and your current Firewall will most likely not offer this type of protection.
The good news is you may not have been attacked yet, as maybe you are a smaller application and not as interesting or newsworthy as a global bank or government organisation. Unfortunately, we have seen that many smaller applications and websites are now getting attacked. The reason is, like almost everything in IT, that cost and complexity is going down. What do I mean by this? It’s becoming easier, cheaper and more autonomous to hack vulnerable targets. Whereas previously, being a less “interesting” target meant that your application security faux pas may have gone unnoticed, this is no longer the case.
WAF’s, such as edgeNEXUS, are becoming increasingly simple to use and are very cost effective. You can even minimise data loss should you suffer a breach from another system or a zero day attack. This clearly has implications in relation to GDPR.
Don’t be the next victim of a preventable attack, use Pre-Authentication and put in place a Web Application Firewall.
