What Happened to Vulnerability Management?

A recent spate of data breaches has highlighted the fact that, even in 2011, many organizations still have not managed to grasp the concepts of vulnerability management.  It is certainly the case that no organization, no matter what sort of controls are in place, can eliminate risk completely.  However, the apparent ease with which some of these attacks have been carried out makes one wonder what sort of vulnerability management practices, if any, these organizations had in place.  At the most basic, vulnerability management should be a cyclical process that involves the identification, analysis, reporting, and remediation of weaknesses in system configurations and software.  Before vulnerability identification can begin, though, it is necessary for an organization to have an understanding of what assets (i.e., systems and data) exist and where they live.  This, of course, is itself an ongoing process, as few IT environments are very static. Vulnerability identification is, believe it or not, often one of the easier steps in the vulnerability management process.  There are numerous options available to assist organizations in identifying weaknesses in their environments, including automated scanners, patch and configuration management utilities, and assessment service providers.  Regardless of the sources of this information, it should provide insight into vulnerabilities in system and software configuration, patch levels, and application code. Analysis of the identified vulnerabilities should include prioritization based on risk to the organization’s assets.  Information such as CVSS score can be helpful in this regard.  Also, categorization based on vulnerability type, infrastructure area, and business unit may also be beneficial, particularly in larger or decentralized organizations. Internal reporting of vulnerabilities sounds simple but, in larger IT groups, can actually be surprisingly complex.  A process needs to exist to ensure that vulnerability information is distributed to the proper individuals in a timely and organized fashion.  Ticketing systems can be a useful tool in this regard, particularly if your vulnerability assessment, analysis, or correlation tool can integrate directly with the system. Finally, identified vulnerabilities should be remediated.  In the ideal scenario, this simply means applying a patch or changing a configuration setting.  However, it is not uncommon for this to be a sticking point.  Whether due to patch incompatibility or a business need for particular features or configurations to exist, it is all too common for identified vulnerabilities to go unmitigated for long periods of time.  This is somewhat understandable and sometimes risks do need to be accepted but, often, the business impact of a vulnerability is not fully understood by the risk owners.  Ultimately, risk owners need to realize the implications on the entire environment if they choose to allow vulnerabilities to persist (see Scott Sutherland and Antti Rantasaari’s “When Databases Attack” presentation for some great examples). Ultimately, vulnerability management does have some complexities but it is an absolutely critical component of a comprehensive and effective information security program.  Security can never be a sure thing and threats will always exist.  However, in this day and age, there is really no excuse for organizations to lack a formal approach to identifying and treating vulnerabilities, particularly in their Internet-facing infrastructure.


Prioritization for Healthcare Executives

Many IT folks know that regardless of their respective fields the “unofficial” eighth and ninth layers of the OSI model are budget and politics.  Healthcare is no different, and some may argue that healthcare has more stringent competition within the “budget” layer.  With limited funds and many demands, organizations are faced with balancing all needs stemming from internal and external pressures.  As a result some sought after security products get delayed or outright shelved until the next fiscal year when it can compete again. Short of a divining rod or a scrying pool, it’s difficult to know what the top pressures or concerns may be.  Luckily groups like the Managed Care Executive Group (MCEG) publish their Top 10 issues collected from healthcare leaders across the country.  Not surprisingly many elements on the list discuss points of fiscal sustainability as it relates to funding from sources such as Medicare and Medicaid, and why wouldn’t it?  If an organization isn’t able to make money then the security posture won’t matter soon enough. From a security perspective some interesting elements are found within number 7 – Health Information Exchanges.  It briefly hits on security where, “HIE’s, in many cases, are being launched under time pressures by relatively inexperienced and under-resourced groups, exposing a lot of data to misuse and/or errors.”  At number seven in the list of ten we finally get to potential PHI breach concerns.  Even so, it doesn’t outright mention HIPAA, HITECH, nor the Health and Human Services (HHS) Office of Civil Rights (OCR). With the OCR increasing enforcement of HIPAA and HITECH regulations and recent fines and penalties this year totaling over $5 million ($4.3 and $1 respectively), this is a little surprising.  Many agree that the OCR is finding its footing in enforcement and their momentum is only going to increase.  I don’t know a lot of organizations that can pay such fines and the corresponding costs of immediate internal corrective actions (let alone the Public Relations costs) without too much concern. How does this help the resource-strapped healthcare organization?  The actions that precipitated these fines weren’t ground-breaking hacks.  They were procedural issues that could have been addressed early and are all part of an environment that secures and protects patient privacy; the goal of HIPAA/HITECH and other requirements found in PCI. Looking at the details of the OCR issues and knowing those top concerns may help reprioritize security.  Even those in a resource-strained company can benefit by using the recent OCR actions and by focusing initially on non-product based solutions that are no-to-low cost (such as policies and procedural changes, staff training, etc) and thus the foundational elements of a sound security posture.  Once those are solidified it makes it easier for those shelved security products to get dusted off and receive the green light.  Resources: Managed Care Executive Group – HHS Office of Civil Rights –


When Databases Attack: Secure360

Antti and I presented our revised version of “When Databases Attack” at the Secure360 conference in Minneapolis a few weeks ago. We included some new SQL script examples based on some feedback from the BSides Minneapolis crowd. Thanks everyone who provided feedback! Go BSides! Feel free to download it HERE if your interested. Hopefully it provides some examples that people can actually use in their environments. We are also working on a database worm that communicates with a bot controller that leverages a number of the trust relationships we cover in “When Databases Attack”. We have included a few screen shots of the front end in the new slide deck. We also submitted it as a presentation for DEF CON 19 so wish us luck!


Healthcare and Identity Theft Programs

With ambiguity over the definition of ‘creditor’ as it relates to the healthcare environment the American Medical Association (AMA) along with others cried “foul” and threw their challenge flag regarding the FTC’s Red Flag Rule. While the AMA is not against protecting patient’s privacy, details within the regulations caused some turmoil as to how this would disrupt physician practices. Delayed implementation and one lawsuit later saw the deadlines continued to get pushed back. Then in December 2010 Congress passed, and Obama signed into law, the “Red Flag Program Clarification Act of 2010.” Clarifying what creditor means, it essentially removed physicians from under the Red Flag Program. Even with this, it doesn’t mean healthcare can just ignore identify theft issues.  Even the AMA agrees. While they don’t think most physicians will fall under the redefined categories of ‘creditor’ it does provide some Red Flag Rule Guidance, sample policy, and FAQ  on their website (AMA membership required). Every organization can benefit from an identity theft prevention program and healthcare is no exception. In fact the majority of privacy breach violations are prosecuted under HIPAA anyways. With the loss of regulatory deadlines, the urgency to implement programs “formally known as Red Flag” seems to be faltering in some healthcare institutions. However the benefits of a successfully implemented identity theft program may limit losses and even gain consumer/patient confidence. With losses occurring due to bad debt and denial of payment false pretenses of identity theft (otherwise known as “I don’t want people to know it was me that was sent to the ED passed out”) a program can help successfully defend revenue recapture efforts. It also helps to curtail medical errors when individuals attempt to use another person’s medical records/insurance to obtain treatment or are merely drug seeking.  Anyway it’s sliced an identity theft program will aid any organization and many healthcare organizations are continuing forward with their programs regardless of where they are in their implementation. While the FTC continues to offer guidance HITRUST may interest healthcare organizations directly with its Common Security Framework (CSF) that has continued to gain momentum in offering a validation tool to not just Red Flag but also HIPAA and other requirements.  For those healthcare environments that have quantified the costs of resolving identity theft claims (both legitimate and not), they realize a little preventative medicine is worth it. I don’t need to remind those in healthcare that while that annual influenza shot may sting a little when you get it, it’s worth it in the long run.

Discover why security operations teams choose NetSPI.