As someone who is responsible for operational security I think that one of the biggest challenge I have to deal with is how to keep the systems and applications up to date with no service interruptions.
It is not only a question of having good patching polices or procedures that dictate how you have to patch after a vulnerability is found in your platform. The time required to analyse the vulnerability, develop a fix, test the fix and deploy it into production can leave a system vulnerable to attack for a period of time which might not be acceptable to the business.
In an ideal world application security vulnerabilities will be fixed by the development team following your secure development processes. The ideal world very rarely exists and there are some situations when it is not possible to patch application vulnerabilities in an acceptable time period. If you think about a public web application being vulnerable to an XSS attack and it is also critical to the business it isn’t always possible to apply a code change in the middle of the day. Even if a code change is approved we need to analyse the vulnerability, design a solution, develop the fix the, test the fix in QA, security review the code, security test the code, upload the code to pre-production, test again and if everything is still working we deploy it into production. This process will take time even if you have a highly skilled team and well defined processes and procedures.
As a person responsible for operations security I would look at alternative, temporary solutions in a situation such as the one outlined above. An alternative approach might allow us to reduce the risk of the vulnerability being exploited whilst we are waiting for a fix to be developed and deployed. Intrusion Prevention Systems and Web Application Firewalls are some examples of technologies we could use to implement a temporary fix, a “virtual patch”.
In this post I’m going to show a video example of an application that has a stored XSS vulnerability in a guestbook form field and how we can mitigate the problem with mod security.
In the first part of the video you can see that the application is vulnerable to XSS and once the admin user is logged in it is possible to steal the session cookie.
In the second part of the video, mod security is added to the Apache server and the attack is stopped by the server. The logs show information about the attack and how it was blocked.
Even though this is a very simple example mod security is a very powerful tool and can implement very complex rules, like filtering the responses from the server to the client for example. As I said at the beginning of the post this virtual patching approach should only be implemented as a temporary solution and/or an additional operational security layer. You should always aim to address application security issues through strong secure development processes and approaches such as the principles of secure development.