Dan Ennis CEO

shutterstock_161075384

JPMorgan spent about $250 million on cybersecurity in 2014 and plans to double its spend next year, said Chief Executive Jamie Dimon in October 2014. Earlier in 2013, in a letter to the shareholders, Dimon said that more than 600 employees across the firm are dedicated to cybersecurity and that this number is likely to grow. The background is a coordinated hacker attack that was launched several weeks ago at the JPMorgan website as well as at least four additional banks, causing a serious data breach and compromising valuable user information.

With a quarter-billion cybersecurity budget and armies of cybersecurity experts, why did JP Morgan suffer a data breach? The reason, as reported in a related Bloomberg article, is a zero-day vulnerability:
“The use of a software flaw known as a “zero-day” in one bank’s website and the way the criminals navigated through elaborate layers of security indicates a degree of skill beyond an ordinary hacker. Zero-day refers to the fact that developers do not know that the vulnerability exists, making it easy for hackers to take remote command of a computer.”

As the practice goes, teams of security experts work on the endless task of patching and hardening the website, its content management systems (CMS) and other backend systems in order to secure them from known flaws, with new flaws reported daily. Securing the Web assets of large financial institutions requires hundreds of security professionals, which according to the best practice must create and enforce a security policy around each Web resource that is externally exposed. This a complex task, but a must to avoid cyber-attacks.

But what if instead of today’s practice of creating, maintaining and monitoring a policy for thousands of externally exposed resources: file downloads, POST requests, REST requests and more, security staff could focus on the few resources that actually require access to the backend systems? What if the vast majority of resources was served from an external zone; a Secure Front End of the DMZ that has no access to the backend at all?

Having the majority of the bank’s web resources deployed in an isolated zone will dramatically reduce the security exposure both to known attacks and to unknown, zero-day attacks. This will allow security teams to focus on the handful of critical transactions that must be served by the backend and protect the website more effectively. This approach saves valuable time, resources and, most importantly, allows security teams to focus on business-critical matters.

To implement this approach we typically advise our customers to use the following checklist:

  1. Create an additional security layer – a ‘presentation DMZ’ protecting the existing DMZ and aim for an implementation approach that does not require changes to the code or platform level.
  2. Restrict access to the original Web server to only allow specific, well known business transactions.
  3. Implement tight, structural whitelist-based validation on the input and output of these business transactions.
  4. Focus logging, monitoring and analysis on the few permitted business transactions.
  5. Implement automatic hardening for CMS and Web server.
  6. Deploy the website on any private or public cloud.

Attacks will then be redirected to the cloud allowing mitigating such attacks and only accepting legitimate transactions. You will be able to focus on your business rather than on trying to protect it.

The message I am trying to deliver is that focused security is effective security. Take the example of Fort Knox where security is laser-focused on the critical assets, keeping the gold safe.

This is the only approach that will prevent zero-day attacks and beyond.

 

blog-post-logo