Security has become a major concern in the wake of all the recent high profile break-ins and the resulting outcry. With mega-corporations facing embarrassing attacks, it looks like no company is safe from cyber-attacks these days. In the old days, networks were targeted in the hope that some weakness (read vulnerability) would be found, which would help cyber criminals (as opposed to hackers, who don’t perform such malicious stuff!) get into a machine and steal data. However, now, Web and mobile applications are the prime targets.
Studies from Gartner show that 70 per cent of the threats are at the application layer. While other respected application security companies like White Hat and security groups like Web Application Security Consortium (WASC) estimate that the average number of vulnerabilities in a Web application is 12-13, US-based Ponemon Institute claims that around 73 per cent of organisations have been hacked through insecure Web applications (http://www.mykonossoftware.com/statistics.php).
Protecting Web applications is not only a security imperative, it is also good business sense unless you want to get sued by clients who discover that they are vulnerable because you have put an unprotected Web application on your network, which is accessible from the Internet!
ModSecurity can help you stay secure, with little or no cost (there will be some cost while calculating the total cost of ownership, which we will get to in the later part of this article).
What is ModSecurity?
It is a Web application firewall (more specifically, a Web application firewall module on Apache Web server), which sits between your application and the whole world out there, and will try to protect your application from being sabotaged or owned.
You can use ModSecurity on both the leading Web servers (Apache and IIS).
A typical interaction between an end user, whom we will call Vineet, and Modsecurity (to be called WAF or Web application firewall from now on) may go like this:
a) Vineet tries to access your application.
b) He hits the WAF first.
c) WAF will check the request to make sure that it is safe to go to the application.
d) If the WAF senses danger, it will take some action (email someone or drop the request); if the WAF deems it alright, it will allow the request to go to the application.
e) Vineet will either see the application interface (if the WAF thinks it is alright) or will see a warning page (if the WAF thinks that the request was a threat).
Why is ModSecurity useful?
Modern firewalls are very good at the network layers, but they do not understand the intricacies of application security. Consider the following scenario:
a) You, as a decision maker, have authorised an application to be made accessible over the Internet while hosting it in your network (reasons could be client pressure, staging an application, etc).
b) You have a firewall that filters all requests coming in from the Internet into your network.
c) You have to allow this application to connect to the Internet.
d) You host it on a shared server, along with 15 other applications, and configure your firewall so that it allows this Web application to be accessed through the Internet.
d) A cyber criminal accesses your application, finds out that it is vulnerable to many weaknesses, uses them to not only get data out of that application (e.g., database details, passwords, user IDs, etc) but also to gain access to the underlying machine. If it has been wrongly configured (hint: application server or Web server running on elevated privileges, etc), the cyber criminal ends up owning your server.
e) Your company gets sued because a client, upon responding to an incident that happened to its servers, realises that by NOT using a WAF, you have breached a due diligenceclause in the contract!
While not intending to spread FUD (fear, uncertainty and doubt), the point here is that securing different parts of your network is not only imperative, it is smart business as well.
ModSecurity provides a range of protection measures (ready-made rule sets like OWASP ModSecurity Core Rules, for example; documentation to help you write new rules, extensive logging, realtime analysis of the HTTP traffic, etc) that can help you secure your existing applications. These also ensure you comply with any standards, regulations and due diligence norms/laws (like the Indian IT Act, HIPAA, PCI-DSS, ISO 27001, any other contractual obligations with a customer, etc).
Where can it be used?
ModSecurity can be deployed to safeguard your Web applications that are accessible from the Internet AND are hosted in your network. You should do so if you are legally bound to secure them. (More so, if securing a clients network is part of a contractual requirement. The Indian IT Act does expect us to perform due diligenceand to meet the contractual requirements of a customer.) The WAF can be deployed as an external security layer without thoroughly disturbing your existing set-up (little tweaks might be needed if you already have an Apache installation running without a ModSecurity module).
One can deploy ModSecurity in either of two ways embedded or as a reverse proxy. In the embedded mode, it is run as an Apache module and is usually the path to follow if you already have a Web server installation in place and do not want to disturb the existing set-up. This deployment is also seamless to scale as the underlying infrastructure scales. However, be forewarned that it will share your existing system resources with Apache, so do plan for beefing up the server beforehand.
In the reverse proxy mode, ModSecurity is still embedded, but the Apache installation runs as a reverse proxy, which essentially means that it works as a router for Web applications. This deployment will be an additional layer (unlike the embedded mode) without hosting any application on it. This deployment is often preferred by security experts and offers the flexibility to use more server resources and thereby set complicated rules, if your infrastructure demands it. This could be appropriate in the case of a huge application environment which is open to the Internet along with load balancers, or when there are many applications with different requirements/rules, or when there is a complex infrastructure containing both. The reverse proxy mode also puts up a single point of failure, which needs to be thought of during deployment (load balancers for ModSecurity, anyone?).
Features of ModSecurity
Monitors HTTP traffic and log transactions (selectively and fully): ModSecurity gives you realtime access to live HTTP traffic which can be used for monitoring. You can choose to log all the HTTP requests/responses (which is not recommended as it will seriously impact the resources of the server) or selective logs. You can also choose the type of logging, depending on the attack (e.g., focus on logging all the information related to a transaction after it is found to be an attack and ignore extensive logging for other requests). You can also send partial log information (enough to trigger an alarm; you need to see ModSecurity audit log files to go through the entire transaction) through syslog to any existing SIEM (security incident and event management) application.
Virtual patching: This is the most exciting feature of ModSecurity. It configures ModSecurity (by adding/modifying existing rules) so that the attack-utilising vulnerability in an application can be thwarted before it reaches the insecure application, while it is being patched.
This is like fixing problems in an application without touching its code!
However, this activity (done by ModSecurity administrators/security specialists) should not be confused with actually patching an application (which is done by developers). This is at best a stop-gap measure and a long term solution is always to use secure software development life cycle processes.
Attack surface reduction: This term implies that we minimise the avenues for attack by accepting only some types of information and rejecting others. This is done by selectively accepting only some HTTP features (specific request methods, content types, etc) and rejecting others.
Deployment and management considerations
Before you issue the deployment orders for your troops, the following things need to be considered:
1. Do we need ModSecurity? For instance, do we even have any application that is accessible through the Internet?
2. Do we have existing manpower to deal with it, i.e., a Linux sysadmin, dev-ops, security operations centre team, etc? Or do we need to invest in all of these?
3. Infrastructure requirements for deployment need to be planned, usually through a formal change management process, so that any hiccups can be managed.
4. Process requirements need to be identified and addressed. The following questions need to be addressed: Who will own this software? Where will the logs go? Who will review the logs? What shall we do in case of a serious alert? Do we need to update our incident response procedures and probably our disaster recovery procedures?
With proper planning, ModSecurity can be a definite value add-on in the existing security system and for overall business due diligence (not to mention the peace of mind that comes with it). With a dynamic security and legal landscape, it is prudent to have a security system for Web applications as well.
