I recently had the pleasure of presenting a 2011 Data Breach Review presentation for the Central Indiana ISSA meeting and it reminded me of a blog post I wrote in 2010 called “The proof is in …We Suck at Information Security”.   I thought it would be a good idea to dust off the old blog post and update it with new data from the Verizon Business 2011 Data Breach report and the Ponemon 2011 Data Breach Cost report.  The interesting thing is nothing has really changed.  A few of the statistics moved a few percentage points up or down but overall the data supports a common theme; most organizations have not implemented a comprehensive information security program which addresses administrative, technical and physical security controls.

96% of breaches were avoidable through simple or intermediate controls*

This means that the breaches are a result of poor patching processes, incorrect configurations, human error or the lack of basic security controls like firewalls and virus software.  Simple security controls and information security “best practices” could have prevented 96% of the breaches that Verizon Business investigated. In my many years of performing security assessments, I have found that companies have no problem spending money on security products but they don’t invest the time and effort in developing information security policies, configuration standards and procedures to insure a secure network environment.

92% of attacks were not considered highly difficult*

This means that it does not take a professional “hacker” with special tools, programming or mad social engineering skills to breach these companies. The attacks used were simple attacks that should have been easily prevented with the proper security controls and administrative procedures. If these companies would have invested in the proper resources and implemented policies, configuration standards, procedures and basic controls, most of these breaches could have been prevented.

86% of breaches were discovered by a third party*

This means that almost no one is effectively monitoring and detecting malicious activities.  From my experience it is usually because of a lack of an effective log-monitoring program. Most of the companies that were breached could have detected the breach or possibly even prevented it if they had just been watching their log files or if they had implemented a log monitoring solution. Companies continue to invest in preventative controls such as firewalls, virus software, NAC and DLP but they don’t want to invest in detective controls such as audit log monitoring solutions.

89% of victims subject to PCI DSS had not achieved compliance*

This proves that the PCI DSS standard is working. I have sometimes been critical of the PCI DSS standard but the implementation of PCI DSS or any other security standard such as HIPAA, GLBA, or SOX will improve information security policies, configuration standards and procedures as well as system and control implementations. Implementing information security “best practices” will address all of the weakness listed above and result in a more secure environment.

63% of the breached companies implemented training and awareness programs after the breach and 54% of the breached companies implemented additional manual procedures and controls**

I believe this statistic supports my theory that the companies included in these surveys did not have comprehensive information security programs implemented at the time of the breach if the corrective action after the breach was administrative changes and additional training.  A proper information security program is about achieving a balance of administrative, technical and physical security controls.

Recommendations

Scary statistics, right? The good news here is all of these breaches could have been prevented. We simply need to implement information security “best practices” and if your company falls under any regulatory compliance areas insure that you implement not only the security controls required but also the policies, configuration standards and procedures. Please understand, building an information security program is not about purchasing the latest security appliance with cool blinking lights.  It is about having the proper resources, policies, configuration standards, procedures and controls to secure your IT environment.

The recommendations I presented during the 2011 Data Breach Review presentation included the following steps to build or improve your information security program:

Administrative Controls

• Improve your Information Security Program
• Update (or create) Policies & Procedures
• Update (or create) Configuration Standards
• Match Configuration Standards to Vulnerabilities
• Develop an Information Security Awareness Program
• Perform Security Awareness Training
• Perform Social Engineering Testing
• Develop a Vulnerability Management Program
• Identify Vulnerabilities
• React to Vulnerabilities
• Patch Vulnerabilities
• Perform Vulnerability Scanning

Detective Controls

• Implement SIEM solution to collect, analyze and alert on suspicious log activity
• Make sure IDS/IPS, AV and DLP logs are monitored
• Perform regularly scheduled Penetration Testing
• Include both Network & Application penetration testing

Preventative Controls

• Closely review firewall rules and implement egress filtering
• Consider implementing DLP or End-Point protection solutions
• Consider implementing Threat / Malware protection solution

To view the entire presentation click here

Sources:

* Verizon Business 2011 Data Breach Report

** Ponemon 2011 Data Breach Cost Report

Presentation by Jeff Foresman from Pondurance at the January 12, 2012 Central Indiana ISSA chapter meeting.

“Those who do not learn from history are doomed to repeat it” – George Santayana

Organizations have a responsibility to protect the data of their customers, employees or other stakeholders. Many organizations are also required to comply with industry requirements or government regulations to protect their confidential data, yet every year hundreds of organizations experience a data breach.

In this attached presentation we review some 2011 data breach statistics and resulting cost estimates, to understand common breach patterns and financial impacts among the affected organizations. We also review the causes of those breaches, and examine possible actions that could have prevented or mitigated the attack.

“A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.”– Wayne Gretzky

A special thanks to the guest panelists supporting the discussion:

• Dave Sims: WellPoint (Senior Information Security Advisor)
• Tad Stahl: State of Indiana (Chief Information Security Officer)
• Chris Blow: Brightpoint: (Manager, Global Information Security)

Their 34 page report includes survey results and commentary.  It sheds light on five hot topics:

• Key Threats and Mitigation Steps
• Regulatory Compliance Issues
• Technology and Staff Resources
• Cloud Computing Concerns
• Business Continuity Planning

The survey shows improving regulatory compliance efforts ranks as the No. 1 information security priority for the year ahead. And the No. 1 technology investment priority is audit logs.  Mobile security is also a high priority as well.

Download the report here.

One key finding:

- Only 74% of the 175 respondents have completed a HIPAA risk assessment

To help address this issue, Pondurance can facilitate and perform the following for our healthcare clients:

• Perform a HIPAA risk assessment using the Pondurance HIPAA/HITECH security assessment framework.
• Perform application interviews to understand the flow of Electronic Patient Health Information (ePHI).
• Perform interviews of information security, network and systems staff to understand the security controls protecting ePHI.
• Perform technical testing for critical applications to understand the security controls protecting ePHI.
• Perform technical testing of information security, network and systems to understand the security controls protecting ePHI.
• Perform management interviews in Information Technology, Information Security, Physical Security, HR, Disaster Recovery and Media Handling.
• Document findings in the Pondurance HIPAA/HITECH assessment report showing risk level, gaps in the HIPAA/HITECH security requirements and recommendations for remediation.
• Create an Executive Summary document and PowerPoint presentation summarizing the findings and recommendations.
• Provide our clients with general HIPAA/HITECH guidance and advice on their Meaningful Use application.

Furthermore, we can review PHI applications thoroughly from the perspective of source code and provide understanding of pertinent areas of the applications through threat modeling.

If you are in the 26% who haven’t yet done their HIPAA risk assessment, please contact us for a discussion on the topic.

Enterprise Security Vulnerability Management – Quick Wins and Gotchas

Implementing and executing an enterprise security vulnerability management program requires both time and/or money to be successful. This last part of the Enterprise Security Vulnerability Management series describes a couple of quick wins and some gotchas to look out for while dedicating your time or money.

It doesn’t have to be expensive

But, here is the caveat to that claim – the less you spend on your “enterprise” vulnerability management system, the less functionality in “management” features you get in the solution.  For a relatively cheap price, an enterprise can implement a vulnerability scanner such as Nessus with their Professional feed.  However, the reporting and data management features are really not “enterprise” solution capable.  This is where the tradeoff between money and resources really plays out – you pay less money, but it requires more work to create those reports and manage the data.

As an alternative to dedicating 25-50% of a full-time resource to operate your enterprise vulnerability management program, purchase vulnerability management as a service.  VM as a service should offer weekly threat and vulnerability analysis, monthly internal vulnerability scans, and quarterly external vulnerability scans.  The ongoing care and feeding of the vulnerability scanning solution is outsourced.  Some solutions only provide scan results in a dashboard, others spend time on site working with you to understand and remediate the identified vulnerabilities. Pick whatever works best in your situation.

Mine your own data

If you aren’t happy with the quality of the default reports in Nessus and you can’t afford the Tenable SecurityCenter data management, analysis, reporting and alerting tool, there might be some free tools that can help.  Again, it is the tradeoff between money and resources.  Three potential vulnerability data management tools are listed below.  The evaluation of these tools will be available in a future blog entry.

Risu (formerly known as NessusDB) from Jacob Hammack

• Risu is an open-source Ruby-based Nessus parser, that converts the generated reports into an ActiveRecord database, this allows for easy report generation and vulnerability verification.
• Risu requires a Ruby environment and a database such as MySQL or SQLite.  It can run on Windows and Linux.

MagicTree from Gremwell

• MagicTree is a closed-source Java penetration tester productivity tool. It is designed to allow easy and straightforward data consolidation, querying, external command execution and report generation. In case you wonder, “Tree” is because all the data is stored in a tree structure, and “Magic” is because it is designed to magically do the most cumbersome and boring part of penetration testing – data management and reporting.
• MagicTree is a Java client application that can run on Windows and Linux.

Dradis from Security Roots

• Dradis is an open source framework to enable effective information sharing, especially during security assessments.
• Dradis is a self-contained web application that provides a centralized repository of information to keep track of what has been done so far, and what is still ahead.  The Dradis server requires Ruby and SQLite and runs on Unix-like systems – installation guides for BackTrack, Ubuntu, FreeBSD and OSX are available.

Dig deeper

The quality of your enterprise vulnerability management program is highly dependent on the data it is based on.  The amount and quality of the data can be enhanced by two factors:

1)      Use more network and application vulnerability scanning tools.  This provides greater breadth in the vulnerabilities tested and can also provide corroboration in the findings.

You can always try security vulnerability testing tools on LiveCD distributions such as BackTrack, the Network Security Toolkit (NST), or the Security Tools Distribution (STD).  I recommend limiting your testing to systems in your designated test / development network prior to testing production systems.  The results from these tools could supplement or confirm the results from your regular vulnerability scanner.

2)      Don’t rely on network-only vulnerability scans.  Configure your vulnerability scanner with credentials.  Credentialed scans produce much better results regarding patching status and local host security configuration items that aren’t generally available from a network-only vulnerability scan.

However, even with credentialed scans, don’t believe you are scanning for “every” vulnerability out there.  Credentialed scanning allows the vulnerability scanner to log in to the target and determine application version information using meta-information from the Windows registry or other package management databases. This allows the scanners to be much more accurate and also provides much greater coverage than an unauthenticated scan. Using this local information, a credentialed scan can determine specific versions of libraries being used or versions of client software that have no listening services, among other granular security checks that can only be performed using credentials.  But even then, only approximately 25% of reported vulnerabilities make it into the signature database of vulnerability scanners.

3)     If time and resource skill-sets are on your side, leverage manual penetration testing to identify issues and vulnerabilities within your environment. Typically targeted towards your application stack, this can vary from source code analysis, application architecture reviews, threat modeling, business logic analysis, database schema and permission analysis, to automated database configuration reviews.

Don’t trust, verify

The “trust, but verify” signature phrase of Ronald Reagan doesn’t really apply to vulnerabilities scanners.  Inevitably, some reported vulnerabilities are false positives.  A false positive is when you think you have a specific vulnerability in your system or application but in fact you don’t.  You might consider running a second, more specialized security testing tool to test the vulnerability finding.  Tracking these down can be a hassle, but don’t blindly assume that because the vulnerability scanner identified a vulnerability, that it actually exists.

For instance many Linux-based operating systems leverage backporting which increases the number of false positives as many vulnerability scanners rely upon version numbers in requests. To “verify” that there are outstanding patches, you will need to get the output from the relevant system. On a RHEL based system (CentOS, Fedora, etc) the “yum list available ‘httpd*’” would provide output for any available Apache httpd patches that need to be installed. To list all of the currently installed patches on the same type of systems you can simply review the list of installed packages “rpm -qa|grep httpd” and manually compare them to the relevant Linux distribution errata.

As another example, the OS detection function of vulnerability scanners is not 100% accurate.  While you may be able to find some weird system types on your network, don’t assume that the OS detection function of vulnerability scanners is infallible, they might not be what they look like.   To help validate, look at all the headers retrieved in service detection plug-ins.  Try running NMAP or telneting to the open ports to see what is returned.  Verify.

Address the core problem early

If you want to make your job easier in minimizing the results from your enterprise vulnerability scan, work to eliminate the problems before they occur.  Here are four ideas:

1)      In your IT Standard Project Development Methodology or System Go-live Checklist, make sure there is a required vulnerability scan, with allowed remediation time prior to go-live approval.

2)      This is kind of like closing the barn door after all the horse have left, but make sure that there is an owner for each new system and application. Confirm that they know what their responsibilities are regarding on-going maintenance and patching.  Anytime you review a project implementation plan and do not see an operational process in the maintenance phase for patching, do not approve.

3)      Develop an active threat and vulnerability intelligence process identifying vulnerabilities and providing remediation steps that can be implemented prior to the vulnerability scanner pointing out the problems.  This requires a philosophical shift from reactive (don’t touch it unless it is broken) to proactive (preventative maintenance planning).

4)      Implementing well-defined Minimum Security Baselines (MSBs) as part of the system build procedure will eliminate some of the meticulous items like default accounts/passwords, incorrect SSL version, weak ciphers, and other easily fixed vulnerabilities. If you scour the Internet, there are many available publicly or you can leverage guidelines offered by NIST, CIS, NSA, or Tenable (Nessus .audit policies).

This ends our 3 part series on Enterprise Security Vulnerability Management.  If you are struggling with your current enterprise security vulnerability management program, or if you need to implement one, contact us at Pondurance for assistance.

[Part 2 of the Enterprise Security Vulnerability Management series.  Part 1 | Part 3]

Top 5 Reasons Why a Security Vulnerability Management Program is Bound to Fail

Implementing and executing an enterprise security vulnerability management program is hard.  Success is difficult to achieve and could be waylaid in any process of the program.  The top 5 reasons why a security vulnerability management program is bound to fail are described below.  Addressing these early will help ensure a more successful program.

1) Not having a complete, comprehensive enterprise inventory

If the asset inventory process to establish and manage IT assets is weak, the confidence that the vulnerability management program addresses all the IT assets in the enterprise will be low.  For example, when the list of networks is incomplete, the vulnerability scanner will not have full coverage.  This #FAIL will leave gaps in knowledge and potentially unaddressed security vulnerabilities with a direct network security impact.  For a large global enterprise, the full list of networks is sometimes difficult to completely define.  A network discovery tool like HP OpenView Network Node Manager, SolarWinds Network Engineer’s Toolkit or Lumeta IPsonar can provide a comprehensive list of networks within the enterprise. If you are good with FLOSS and have a do-it-yourself attitude, nmap or other free network discovery tools can be used. These tools can be found on the Backtrack Network Mapping menu as well.

When the list of operating systems installed in the enterprise is incomplete, the depth of the vulnerability scanner checks may be limited.  It is recommended to configure the vulnerability scanner to only check for vulnerabilities in the known installed operating systems to reduce false positives and decrease scan time.  However, when certain operating systems are eliminated from the configuration, but they actually exist, full coverage of potential vulnerability examination will not occur.  This situation is frequently encountered when IT management is decentralized and when networks are configured to allow anything to be plugged in.  It is very common to encounter non-standard “appliances” such as printers, environmental monitors, conference room scheduling displays, etc… that actually run an embedded operating system that are frequently vulnerable and rarely patched. One potential solution to these un-owned devices is to put them into a segmented network jail that has good network perimeter security to monitor those devices and protect the rest of the network.

On the application side, not documenting the comprehensive list of applications and versions will delay the patching and remediation process.  Instead of having a proactive threat and vulnerability intelligence process that matches published vulnerabilities with installed applications, there will be a reliance on the vulnerability scanner to catch vulnerabilities after the fact.  This can leave systems and applications vulnerable for a much longer time depending on how fast the vulnerability scanner incorporates those checks in the scanner combined with the frequency of running the scanner.

2) Not having well-defined system and applications owners

Running a vulnerability scanner and identifying vulnerabilities is relatively easy.  On the contrary, it is hard to get things patched or remediated if you can’t find the owner.  This #FAIL is really an indicator of the maturity of the IT organization.  Less mature IT organizations will not have a well-defined process for full lifecycle IT asset management.  A key component of IT asset management is definition of owners.  Mature IT organizations will have clear documentation on the business owner, application owner and system owner for each IT asset.  Once the owner is known, it is simple to direct the workflow for vulnerability management and create tickets for remediation.

In my experience, this situation of not knowing who the owner is can also happen in a frequent merger environment where IT staff is rapidly consolidated.  If you can’t find an owner for a system, then one course of action is to effectively perform a controlled disconnect of the system.  Of course, prior to disconnecting the system, you will want to exhaust all methods for determining the owner, including using network sniffing tools to identify network connections that might indicate its purpose or users. If users complain about a missing system or application, then it might be important enough to assign an owner amongst the existing IT staff and start testing the remediation recommendations.  If there are no complaints, then turning it off saves the company money and eliminates the threats posed by abandoned technology.  For third party applications, the easy choice for remediation if no application owner steps forward is to either patch or remove.

3) Ignoring vendor vulnerability announcements

Many times the approach of “if it ain’t broke, don’t fix it” is reasonable, but this really depends on knowing if it is broke.  This #FAIL turns the enterprise vulnerability management program into a reactive finger-pointing exercise rather than a proactive vulnerability identification, threat removal, risk reduction process benefiting the enterprise.  There are a few causes for this situation and most are intentional.  One cause is just looking where you want to see, maybe because you have an automated patch management system in place for that area.  I’ve had IT managers at global companies tell me the company only has Microsoft technology implemented.  While OS identification is not a precise science, it should be able to pick up all the “hidden” IT assets that too-narrowly-focused IT managers don’t want to see.  If you can’t trust your IT asset inventory, then the first few enterprise-wide vulnerability scans can set the technology baseline that can be used to define the systems and application vendors that should be monitored for vulnerability announcements.

Another cause for ignoring vendor vulnerability announcements is the practice of bundling everything together in a quarterly set of patches for dozens of applications in what is called the quarterly critical patch update.  This presents a massive jumble of patches that overwhelms the application team to the point that they choose to ignore the patch rather than spend the time to parse the full list of vulnerabilities, determine what is applicable to their current installation, create their remediation actions and start the testing process.

4) Ignoring vulnerability scanner results

Even more common than ignoring vulnerability announcements is ignoring vulnerability scanner reports.  This #FAIL has many potential causes, but they mostly revolve around lack of resources and no consequences.  When an IT organization has an ingrained culture of install and don’t touch it unless something breaks, it is hard to change that culture into a continuous management process with frequent periodic maintenance and patching.  Some of the excuses when presented with the list of vulnerabilities and missing patches are:

• But it’s too hard to fix all those items.
• I can’t take the system down.
• I don’t have the manpower to investigate and test all those changes.
• We’ve managed so far without patching.

In the past, unless the CIO took a personal interest in the maintenance and patching of IT assets (maybe as a result of not patching and having the entire network go down because of Code Red, Sasser or Blaster) usually there were no consequences to not remediating vulnerabilities.  Ensuring regulatory compliance with PCI DSS or HIPAA/HITECH today means having a plan to address vulnerabilities and the consequences for ignoring vulnerabilities can be severe.  This is an easy item for the PCI QSA to fail a company.

5) Not mining the data for interesting things

“There’s gold in them there hills.”  What this translates to is that there is great information buried in the scan results.  Of course, the standard reports can identify system and application vulnerabilities, but the more you dig into the data, the more gleaming nuggets you can find.  This #FAIL is organizations that don’t devote the effort into looking closely at the data.

What might be interesting in that mountain of data?  How about:

• What systems are running old versions of operating systems or applications?  Do you have Windows NT systems still running on the network?  Are there systems still running Adobe Reader version 4, 5, 6, 7 or 8? Why?
• What systems are identified to be outside the norm?  This will indicated devices, appliances, and non-approved systems attached to your network. Does the official IT asset inventory know about these?
• How many systems did not allow a credentialed scan?  Why?
• How closely does the application inventory identified by the vulnerability scanner match the official list?  Depending on your organizations policy and controls regarding end user capability to install software, you may find old or non-standard versions of third party software.

Stay tuned for SVM Part 3 which discusses some quick wins and some potential gotchas.

What is Security Vulnerability Management?

Security vulnerability management is the current evolutionary step of vulnerability assessment systems that began in the early 1990’s with the advent of the network security scanner S.A.T.A.N. (Security Administrator’s Tool for Analyzing Networks) followed by the 1^st commercial vulnerability scanner from ISS. While early tools mainly found vulnerabilities and produced lengthy reports, today’s best in class solutions deliver comprehensive discovery and support the entire security vulnerability management lifecycle.

A vulnerability can occur anywhere in the IT environment, and can be the result of many different root causes.  Security vulnerability management solutions gather comprehensive endpoint and network intelligence and apply advanced analytics to identify and prioritize the vulnerabilities that pose the most risk to critical systems. The result is actionable data that enables IT security teams to focus on the tasks that will most quickly and effectively reduce overall network risk with the fewest possible resources.

Security vulnerability management is a closed-loop workflow that generally includes identifying networked systems and associated applications, auditing (scanning) the systems and applications for vulnerabilities, and remediating the vulnerabilities.  Any IT infrastructure components may present existing or new security concerns and weaknesses – i.e. vulnerabilities.  It may be product/component faults or it may be inadequate configuration.  Malicious code or unauthorized individuals may exploit those vulnerabilities to cause damage, such as disclosure of credit card data.  Vulnerability management is the process of identifying those vulnerabilities and reacting appropriately to mitigate the risk.

What are the drivers for Vulnerability Management?

The main drivers for implementing a security vulnerability management program are avoidance of:

• Compromised data confidentiality, integrity, availability
• Compromised system availability
  • Directly caused by incident
  • Required during incident containment, root cause analysis, and remediation
• Productivity loss
  • Employee idle time due to system unavailability
  • Lost transactions
  • Costs to identify and repair incident cause
• Liability towards 3rd parties
  • Business partners, customers
  • 3rd parties suffering attacks originating from compromised IT components
• Compromised public image and brand reputation

Successful security vulnerability management programs can reduce or eliminate the consequences of incidents.

What are the potential consequences?

The potential consequences of a non-existent or inadequate security vulnerability management capability are:

• Continue to be vulnerable to new and existing security threats such as viruses, worms, trojan horses, and the latest buzzword – APT – advanced persistent threats
• Inability to accurately measure susceptibility to current and new threats
• System uptime and availability could be jeopardized
• Potential cost savings by the reduction or elimination of vulnerabilities will not be realized
• Integrity and privacy of data could be at stake
• Potential image loss and liability damages if restricted data (PCI, PII, PHI) is exposed and/or abused
• Difficulty in demonstrating regulatory compliance since it is a requirement of PCI DSS

What are the steps in the Security Vulnerability Management program?

Typically, when people hear Security Vulnerability Management, they think about vulnerability scanning tools such as Nessus or Qualys.  Vulnerability scanning is only one important process in the entire program.  The major processes in the program are:

1. Asset Identification – Successful asset management starts with understanding what you have.  This process provides complete visibility into the entire hardware and software asset inventory, including version information, which helps determine applicability of threats in the environment.  Defining the scope of the networks where assets are located is also a critical component.
2. Threat Intelligence – Monitoring both internal and external sources for threat information is critical to provide a complete view.  From the internal perspective, log management and SIEM solutions provide alerting on on-going intrusion attempts and malicious code attacks.  Externally, vendors and industry alerting resources must be monitored and matched against the full breadth of IT assets in the inventory to identify potential threats.
3. Risk Evaluation – A cross-functional team must evaluate the threat information including the vendor risk ranking combined with any existing workarounds and security solutions to determine the threat criticality, remediation responsibility, and associated deadline for remediation.
4. Remediation – The responsible system or application administration team must develop the remediation plan and follow the existing enterprise change management process.  The remediation steps typically are patching or shielding and compensating controls such as network segmentation and system configuration changes.
5. Vulnerability Scanning – The vulnerability scanning system must be properly configured to scan all networks under target as determined in the Asset Identification process.  In a proactive IT environment, vulnerability scanning can provide remediation confirmation.  In a reactive environment, it can provide a list of systems vulnerable that need to be remediated.  Another side benefit of vulnerability scanning is identification and version tracking of systems and applications to complement or validate the results available from the Asset Identification process.  Vulnerability scanning can also provide reports that allow management to evaluate the effectiveness of patching and the potential security risk posture when vulnerabilities occur.

What are the key criteria to measure the maturity of the Security Vulnerability Management program?

Some key measurement criteria for determining the maturity of the SVM program are:

• Does the organization have a comprehensive IT asset inventory in place for networks, systems, and applications?  Are there owners defined?
• Does the organization have internal network segmentation implemented?  Do they have a mature DMZ and business partner connectivity perimeter security architecture in place?
• Does the organization have well-defined security configuration guidelines and installation checklists implemented?
• Does the organization have an enterprise patching solution in place?
• Does the organization have separate development or testing systems and a formalized process to install and test patches integrated with their change management process?
• Does the organization have individuals identified across most IT departments who have been assigned the responsibility to participate in the Security Vulnerability Management program?

Stay tuned for SVM Part 2 which discusses the top 5 reasons why a security vulnerability management program fails.

The civil and criminal monetary sanctions that may be imposed by OCR for violations of HIPAA by either a covered entity or its business associate were also dramatically increased by the HITECH Act. Currently, there are four penalty tiers ranging from $100 to $50,000 for each violation, with $25,000 to $1,500,000 for similar violations in the same year. Penalties also vary depending on the degree of culpability of the covered entity or business associate, with the most severe penalties reserved for violations arising from “willful neglect.”

OCR has previously imposed sanctions under settlement agreements with cooperative covered entities for violations of HIPAA. These cases (i.e., Providence Health, CVS, etc…) were usually a relatively small fine coupled with a Corrected Action Plan detailing improvements in the trouble areas.

In the first civil money penalty ever handed out by OCR, Cignet Health of Maryland was ordered to pay $4.35 million for HIPAA violations arising from the covered entity’s failure to provide 41 patients with access to their protected health information (such access is required according to procedures and timeframes outlined in the HIPAA privacy regulations) as well as the covered entity’s failure to cooperate with OCR’s investigation. Indeed, by failing to cooperate more fully with OCR’s investigation of the patients’ complaints (itself a violation of HIPAA that is subject to sanction), Cignet Health acted with the kind of “willful neglect” that in the view of OCR made it necessary to impose the most stringent monetary penalties. It should be noted that $3 million of the $4.35 million sanction was attributed to Cignet Health’s failure to cooperate.

In another sanction, OCR has entered into a settlement agreement with Mass General. The settlement agreement provides for the payment of $1 million to resolve multiple disclosure violations that occurred when a Mass General employee lost paper medical records containing the PHI of 192 patients on the subway. (Note, paper records not electronic. It’s easy to overlook protections of paper-based PHI.)
It is also interesting to observe that cooperation with OCR pays off – Mass General’s fine was much less ($$millions) compared to Cignet’s when comparing number of patient records. My prediction is a future sanction against a business associate to reinforce the new HITECH direct business associate compliance enforcement capability.

These early cases remind me of the initial FTC actions in the mid-2000′s for data privacy issues (ChoicePoint, Guess?, Eli Lilly, etc…) which generally had fines and a consent decree such as requiring that the companies implement comprehensive information security programs and obtain audits by independent third-party security professionals every other year for 20 years. I guess that is one way to get executive management support and funding for your security program…

Another interesting phenomenon is the self-funding nature of compliance enforcement organizations. The more they fine, the more auditing and compliance resources are available to perform audits. Typically, Congress passes these laws with unfunded mandates for enforcement. I believe the same type of funding model for the compliance enforcement function occurs at the FDA and the FTC.

If nothing else, these cases are a reminder that stricter enforcement of HIPAA is not just a threat, and that it is imperative to cooperate fully with OCR in the event of any investigation of an alleged violation of HIPAA.