REDUCING ORGANISATIONAL RISK THROUGH VIRTUAL PATCHING

Abstract

1. Introduction
Patching of software’s has been a concise way of keeping software’s reliable. In the past,
patching was focused on increasing functionality unlike today. (Risk Assessment – Cisco, n.d.;
Executive Office of The United States, 2005). Now that a large number of people know the
potential threat due to poor patching, most people are working on increasing security.
(Epstein, Grow & Tschang, 2008). With so much at stake, security implementation is being
done at a much quicker rate than before. (Chan, 2004). Over the past couple of years,
software exploitation has gravely been cut down. Almost up to 100% of the time, software
weakness is discovered through known weaknesses or configuration mistakes which can
easily be corrected. (Network Integration Services, 2010).
Majority of organisations strive to maintain high software security awareness and try to curb
a problem before it gets out of hand. Factors that can affect the action time to deal with the
patching include;
i. Appropriate expert; this is a person who can easily diagnose the problem
and fix it. Lack of an expert can heavily derail the whole response time.
ii. The application may be owned by someone else hence problems such as;
third party doesn’t have the resources to fix it or there are legal issues
involved e.g. SLA agreements.
iii. Fear that a new patch software my introduce problems e.g. financial ‘due to
break down’ to a system that seems to works well. This so called
improvement my introduce bugs, make the system unstable. So after
weighing the options, most organisations opt to remain with their working
system than to risk upgrading it and getting more problems.

Virtual Patching goes a long way in minimising the above factors.

2. Closing The Gap with Virtual Patching

2.1 A Virtual Patch Defined
Defined as “vulnerability mitigation in a separate layer, where you get to fix problems in
applications without having to touch the applications themselves” (Ristic,2010), or as “a
policy for an intermediary device (WAF) that is able to identify/block attempts to exploit
a specific Website vulnerability (Barnett, 2009). Shim iterated that virtual patching
eliminates weaknesses by controlling input and output from an application.

2.2 Architecture
Virtual patching success mostly depends on the architecture, in this case, Mod Security –
this is an Open Source Web Application Firewall (WAF) for custom Virtual Patches.

2.2.1 Embedded (decentralised)

 This involves embedding the Mod Security as an Apache Module to the sever
and the virtual patches to the particular applications.

2.2.2 Reverse Proxy (centralised)

This is done by configuring Mod Security running Apache on a reverse sever
proxy; this will be able to apply virtual patches and defend more applications on
more servers.
This model allows the administrator to perform his tasks across platforms with
much ease.

2.2.3 Architecture Advantages and Disadvantages

Mode Security as an Apache module reduces the labour due to its ease of
change that does not require network change. Another vital advantage also, is
that it requires no particular hardware, hence cost effective. The cons of this
architecture include the fact that it will utilise the hosting server and it will be
cumbersome for the administrator to deal with the increasing servers all with
different rules.
These cons can be dealt with by frequent updates and scripted deployment, but
this may only be a temporary solution due to increasing organisation size.

2.3 The Patch

2.3.1 The Vulnerable Web Application
Poor code handling can cause great vulnerability than can lead to great
consequences both financial and reputation wise due to loss of customer trust.
Security can be compromised by a simple procedure such as SQL injection.

2.3.2 The Injection Attack

This involves exploiting poor login validations by changing the original design
hence executing a newly created logic by termination the original. This process
will by-pass the security login.

2.3.3 The Virtual Patch Defence

When this weakness is found, a patch will be created to act upon the particular
weakness hence shutting down the gateway to the exploit for the SQL injection.

2.3.4 Mod Security Rule Engine

This operates according to already set rules.

2.3.5 Vulnerable Web Application – Brute Force Attacks

Brute force needs a lot of time because it involves trying all possible
combinations for a passkey. Virtual patching can be utilised here to prevent
brute for without changing any of the original code.

2.3.6 Virtual Patch – Brute Force Mitigation

 A login failure threshold is checked ‘up to and exceeding 25’ and the IP address
is temporarily blocked to stop repeated tries. This patch can be customised
depending on the needs.

2.3.7 Vulnerable Web Application – Session Attacks

When a developer does not adhere to the normal practise followed when setting
the value of a cookie, or simply there were lesser standards at the time of
creation, this exposes the application to XSS vulnerability. This makes it much
easier for a hacker to take advantage of this flaw. This flaw can easily be
corrected by a skilled programmer but other factors may play a role in ensuring
otherwise, so a properly crafted Virtual Patch can set the cookie to proper
development guidelines.

2.3.8 Virtual Patch – Session Attack Mitigation

3. ModSecurity & Virtual Patching Approaches

3.1 Patching Methodology
There are community rules in ModSec that are maintain by an elite group of Security
professionals. These rule are play a major role in making securing a web browser. They
can be set to automatically update or be deployed accordingly by the administrator; this
is all up to the organisation point of view in relation to risk.

3.2 Negative Security Model

Here rules can be configured to allow all traffic and to hunt and mitigate the attack; so in
negative security model, anything that does not meet the set standard in denied. This
makes this security model

3.3 Positive Security Model

4. Virtual Patching Benefits

4.1 Technical
4.2 Business
4.3 Getting It Right & Striking A Patch Balance

5. Virtual Patching Strategy – Areas To Focus On

5.1 Assess & Prioritise
5.2 Test And Tune Virtual Patches
5.3 Communicate

6. Conclusion

References