By Jeff Kabachinski, MS-T, BS-ETE, MCNE
Say you learn of a newly found vulnerability in an EHR system or patient monitoring system, or even in some homegrown business applications. This is bad news for all the usual security reasons. It can make patient data and patient billing information vulnerable to cyber criminals, and it can lead to HIPAA violations that can in turn result in fines of $1 million or more.
Depending on where the software fix or patch is coming from—a commercial vendor or an in-house IT department—it may take weeks or months for the official fix to be applied. During this period, the “window of exposure,” you are left vulnerable to exploits. Not only does the vulnerability need to be thoroughly examined, but also the new code that must be written must be just as thoroughly tested. Moreover, sometimes a software update can inadvertently cause new issues in some other part of the application code, adding to the need for exhaustive testing.
This is where virtual patching can come to the rescue. It is an interim workaround that can be applied much more quickly than a software patch, and without causing disruption to the day-to-day operation of the facility.
Definitions
Before we get into the details of virtual patching, let’s define two key terms: vulnerability and exploits. A vulnerability is a weak spot embedded in the code of software programs or applications that can be used in surreptitious ways to expose your sensitive data or system to exploitation and subsequent cyber crimes. Exploits are events where known software vulnerabilities are used to deliver malware or to find ways to hack into your network and system.
The term virtual patching, originally coined by vendors of intrusion prevention systems, refers to a security policy enforcement layer that prevents targeted exploitation attempts of a known vulnerability. A virtual patch is also known as a web application firewall (WAF). It can save the day as a quickly developed, short-term security policy. With virtual patching, traffic to vulnerable web applications is monitored. Attempted attacks are subsequently blocked, preventing the malicious traffic from reaching its target.
Window of Exposure
When you learn of a vulnerability, it’s unwise just to wait for the code fixes to come, hoping that the vulnerability won’t be exploited during the window of exposure. If the software involved is a commercial application, you most likely will have to wait for the vendor to make the repairs. Since vendors in the health care domain have rigid software update release timing and need to comply with all regulatory laws in terms of testing and retesting, they may not officially release patches for months.
In addition, as the new source code or update patch becomes available, the installation and implementation times can be further drawn out to allow for extensive regression testing (see sidebar).
Regression TestingRegression testing refers to a selective method for retesting of a software system that has been modified to remove bugs or vulnerabilities. It is used to ensure that no other function of the software system has been adversely affected due to the modification. It is also a quality control measure to make sure that the newly modified code still complies with previous requirements, and that unmodified code requirements have not been unduly affected. |
A recent Internet Security Threat Report from Symantec reported that the average time organizations take to patch their systems is 55 days. The Web Security Statistics Report from WhiteHat Security documented that their customers’ time-to-fix average to remediate SQL Injection vulnerabilities found in their web applications was 138 days. (See the sidebar for more findings from WhiteHat.)
Key findings of the WhiteHat Website Security Statistics Report
|
Fixing custom or homegrown code can also get expensive. The costs come primarily from source code reviews, vulnerability scanning, and penetration testing. There are also costs associated with the software patch development and implementation. Still more cost and time will be involved if the vulnerable software application is from an out-of-business vendor.
Virtual Patching Tools
The main types of tools used in virtual patch development are intermediary logical devices like a WAF, web-server plug-ins or bolt-on programs, and application layer filters like an enterprise security application programming interface (ESAPI) WAF. (An application programming interface, or API, tells different software or application components how they should interact with one another.)
The tool will need to use an HTTP and HTML parser to thoroughly analyze the incoming communication traffic by taking apart software code or an input stream and breaking it back down into its component parts. Typically, it will identify the software objects, methods, and their attributes to be used in its analysis. It looks for things like sequential source code instructions, interactive online commands, and mark-up tags, and then tries to establish the relationship among the components.
Virtual patches use complex logic, so simply looking for signatures, as in anti-virus detection methods, is not enough. A virtual patch needs to establish a set of rules. For example, it will inspect operators and logical expressions to make sure the content is correct in terms of typical field lengths and usual character groupings. If a field is too long—perhaps because it’s carrying a malware or hacking payload—it will prompt deeper inspection. There are many types of rules, as well as rules that call other rules. If the payload is in XML, for instance, another rule may be called to inspect it further.
These scan results are transformed into WAF policies, which become the virtual patch to protect against exploits of the known vulnerability. This approach to mitigation decreases the window of exposure, reduces security risk, and affords greater control and flexibility in developing or waiting for the permanent fix.
Methodology
In the preparation phase of creating a virtual patch, care must be taken to develop a thorough framework to deal with the known vulnerability or the expected web intrusion, ideally before an actual intrusion takes place. The preparation phase should include ensuring you’re on the vendor list to be notified of vulnerabilities and of new source code updates.
In responding to vulnerabilities, you should obtain preauthorization to create the virtual patch so that governance procedures and preapproval to install new software can be expedited. One good thing about quickly reacting to a vulnerability in this way is that since you’re not revising source code, there’s less regression testing needed, thereby further expediting the process.
There are two general requirements that virtual patches should observe. First, since you don’t want to block legitimate traffic, they must not produce false positives. Second, because you want to capture and restrict all attempts to evade detection, the patches should produce no false negatives, either.
Finally, to avoid slowing down the processes of the web server too much, consider other techniques like selectively increasing traffic logging based on IP addresses.
Conclusion
Virtual patching is an interim process that provides a rapid data protection scheme until time and resources are available to implement the software update patch. The two main steps to the virtual patching process are first, to identify the known vulnerabilities, and second, to create defenses to stop their exploitation. Virtual patching monitors traffic to vulnerable web applications for attempts to exploit the identified vulnerabilities. Attacks then are blocked to thwart the malicious traffic from reaching its target.
Virtual patching offers three key benefits. First, it improves security, quickly mitigating vulnerabilities without disrupting business. Second, it increases operational efficiency, allowing the time to plan and implement patches according to your schedule. And finally, it helps to maintain web server ROI values, so that you don’t need to restrict legitimate traffic or slow down subsequent business. 24×7
Jeff Kabachinski, MS-T, BS-ETE, MCNE, has more than 20 years of experience as an organizational development and training professional. He is the director of technical development for Aramark Healthcare Technologies in Charlotte, NC. For more information, contact [email protected].
Works Cited
Imperva. Protected! Mitigating Web Application and Database Vulnerabilities. June 1, 2011. Accessed June 25, 2013.
Newton H. Newton’s Telecom Dictionary: Telecommunications, Networking, Information Technologies, The Internet, Wired, Wireless, Satellites and Fiber. New York, NY: Flatiron Publishing; 2013.
OWASP. Virtual Patching Best Practices. April 19, 2013. Accessed June 25, 2013.
Symantec. Internet Security Threat Report 2013. Mountain View, CA: Symantec Corporation.
Whitehat Security. WhiteHat Website Security Statistics Report. June, 2013. Available at: Whitehat Security: https://www.whitehatsec.com/resource/stats.html. Accessed June 25, 2013.
