Posts Tagged ‘Compliance’

Compliance obligations need not stand in the way of better information security and risk management

I couldn’t help write this post when I noticed this press release based on an IDC Insights Survey of Oil & Gas Companies. I don’t have access to the full report so I am basing my comments solely on the contents of the press release.

I found the following two findings (copied from the press release) to be of interest :

• Security investments are not compliance driven. Only 10% of the respondents indicated that they are using regulatory compliance as a requirement to justify budgets.

• Tough regulatory compliance and threat sophistication are the biggest barriers. Almost 25% of respondents indicated regulatory environment as a barrier to ensuring security. In addition, 20% of respondents acknowledged the increasing threat landscape.

The good news here is that only 10% of the respondents used Regulatory Compliance needs to justify budgets. What that tells me (I hope it is the case) is that the remaining 90% make budgetary decisions based solely on the information security risks that their  businesses face and not on the risks of not complying with regulations or audits. I would commend them for it… and I don’t think any good auditor (regulatory or internal/external) would have a problem with it either if the organization was able to “demonstrate” that the risk of not complying with a particular regulatory requirement was very low. Agreed.. you still need to be able to “demonstrate” which isn’t easy if one hasn’t been diligent with risk assessments.

The not-so-good news to me is the 25% number (I realize it might be low enough for some people)..  that of folks indicating that regulatory compliance is a barrier to ensuring security. For those folks, I say “It really doesn’t need to be a barrier”, not if you have good   information risk management governance and processes. I don’t know a single regulation that would force you to implement specific controls no matter what. Even if you are faced with an all-or-nothing regulation like PCI DSS, you can resort to using compensating controls (see here and here for some coverage of PCI DSS Compensating controls) to comply with a specific mandatory requirement.  To repeat my argument in the previous paragraph, an auditor would be hard-pressed to fault you if you were able to clearly articulate that you went about the compliance program  methodically by performing a risk assessment and prioritizing (by risk level) the need for specific controls required by the regulation. If you did that, you would focus on ”ensuring security” and not ignoring it for the sake of compliance.

Do we have a wake-up call in the OIG HHS Report on HIPAA Security Rule Compliance & Enforcement?

If you didn’t notice already, the Office of Inspector General  (OIG) in the Department of Health and Human Services (HHS) published a  report on the oversight by the Center for Medicare and Medicaid Services (CMS) in the enforcement of the HIPAA Security Rule. The report is available to the public here.   As we know, CMS was responsible for enforcement of the HIPAA Security Rule until the HHS  Secretary transferred that responsibility over to the Office of Civil Rights (OCR) back in 2009.

To quote from the report, the OIG conducted audits at seven covered entities (hospitals) in California, Georgia, Illinois, Massachusetts, Missouri, New York, and Texas in addition to an audit of CMS oversight and enforcement actions.  These audits focused primarily on the hospitals’ implementation of the following:

• The wireless electronic communications network or security measures the security management staff implemented in its computerized information systems (technical safeguards);
• The physical access to electronic information systems and the facilities in which they are housed (physical safeguards); and,
• The policies and procedures developed and implemented for the security measures to protect the confidentiality, integrity, and availability of ePHI (administrative safeguards).

These audits were spread over three years (2008, 2009 and 2010) with the last couple of audits happening in March 2010. The report doesn’t mention  the criteria by which these hospitals were selected for audit except that these  hospitals were not selected because they had a breach of Protected Health Information(PHI) .

It wouldn’t necessarily be wise to extrapolate the findings in the report to the larger healthcare space in general without knowing how these hospitals were selected for audit. All one can say is that the findings would paint a worrisome picture if these hospitals were selected truly in a random manner.  For example, if one were to look at ”High Impact” causing  technical vulnerabilities, all 7 audited hospitals seem to have had vulnerabilities related to Access and Integrity Controls, 5 out of  7 had vulnerabilities related to Wireless and Audit Controls and  4 out 7 had vulnerabilities related to Authentication and Transmission Security Controls.

What might be particularly concerning is that the highest number of vulnerabilities were in the Access and Integrity Controls categories.  These are typically the vulnerabilities that are exploited most by hackers as evidenced (for instance) by the highlight in this quote from the 2011 Verizon Data Breach Investigation Report – “The top three threat action categories were Hacking, Malware, and Social. The most common types of hacking actions used were the use of stolen login credentials, exploiting backdoors, and man-in-the-middle attacks”.

Wake-up call or not, healthcare entities should perhaps take a cue from these findings and look to implement robust security and privacy  controls. A diligent effort should help protect organizations from the well publicized consequences of a potential data breach.

Next time you do a Risk Assessment or Analysis, make sure you have Risk Intelligence on board

I was prompted to write this quick post this morning when I read this article.

I think it is a good example of what some (actually many, in my experience) risk management programs may be lacking, which is a good quality of Risk Intelligence. In this particular case, I think the original article failed to emphasize that vulnerabilities by themselves may not mean much unless there is a good likelihood of them being exploited, resulting in real risk.  We discussed some details regarding the quality of risk assessments in a previous post.

A good understanding of information risks and their prioritization needs to be the first and arguably the most important step in any information risk management program. Yet, we often see risk assessment initiatives not being done right or at the right quality. We think it is critical that a risk analysis or assessment is headed by someone or performed by a team that has or does the following:

1. A very good understanding of your environment from people, process and technology perspectives
2. A very good and up-to-date intelligence on the current threats out there (both internal and external) and is able to objectively define those threats
3. Is able to clearly list and define the vulnerabilities in your environment. It will often require  process or technology specialists to do a good job of defining the vulnerabilities
4. Is able to make an unbiased and objective determination of the the likelihood that the vulnerabilities (from Step 3) can be exploited by one or more threats (from Step 2)
5. A very good understanding of the impact to the business if each vulnerability were to be exploited by one or more threats. Impact is largely a function of the organization’s characteristics including various business and technical factors, so it is important that you involve your relevant business and  technology Subject  Matter Experts.
6. Based on the likelihood (Step 4) and impacts (Step 5), estimate risks and then rank them by magnitude.

We just can’t stress the importance of steps 1-5 enough. We think it takes “Risk Intelligence” to do these steps well. Without good Risk Intelligence on your team, you may well be wasting precious time, money and resources on your risk assessments.  More importantly, you may not be protecting your business to the extent that you should, with the same budget and resources.

======================================

Important Disclaimer

The guidance and content we provide in our blogs including this one is based on our experience and understanding of best practices. Readers must always exercise due diligence and obtain professional advice before applying the guidance within their environments.

May we suggest some priority adjustments to your PCI DSS Compliance program?

It isn’t any news that achieving PCI DSS Compliance continues to be onerous for many merchants out there. PCI DSS is after all an all-or-nothing regulation meaning that not passing even one of over 200 requirements could prevent you from getting there. And then, if you do become compliant, there is really no assurance that you will have 100% security. This is something we have known all along to be true for any regulation and now we have one more statistic from the 2010 Verizon Data Breach Investigation Report to prove it …  21% of organizations facing payment card data breaches were compliant with PCI DSS at the time of the breach.

So, may be it is time to rethink our approach to PCI DSS compliance, in terms of how do we get there by way of addressing controls that carry higher breach risks before the others. That will at least help improve your  organization’s security posture against potential breaches even if you are nowhere close to meeting all PCI DSS requirements.   I think recent breach surveys or reports are a great source to identify such controls  with an objective of prioritizing the remediation initiatives in the right order. Such prioritization should help in achieving a better security posture sooner, as we’ll see below.

I am not the first one to suggest a prioritized approach to achieving PCI DSS compliance. In fact, PCI SSC already has guidance on this, though the guidance itself is somewhat dated having been issued back in February 2009. Since then,  the threat environment has probably evolved somewhat and exploitation of certain  vulnerabilities isn’t quite of the same order relative to others. Therefore, I suggest leveraging the data breach findings to make necessary prioritization adjustments.

Here are some findings from three recent reports on which I am basing my recommendations:

Here then is a summary of the key controls in the above table, relevant PCI DSS requirements and priorities from the PCI SSC Guidance.

Note: Numbers in brackets are the priority numbers from the PCI SSC guidance. Numbers in the guidance range from 1 through 6. A lower number indicates a higher priority.

As we can see from the table, there are several requirements which if addressed sooner, will actually improve an organization’s security posture against potential breaches, based on what we know from the recent breach studies.  I would recommend increasing the priority of the requirements in red to at least 3 if not 2. I do realize that organizations may not be able to afford to address too many requirements at a higher priority. If that is the case, you may want to review the current priority 2 and 3 requirements against the key controls in the table above and then decide to push some of them lower down the priority order as applicable.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we could be of assistance to you.

Proposed updates to HIPAA Security and Privacy Rules – What is new?

It was good to see the Office of Civil Rights (OCR) publish the long awaited proposed updates to HIPAA Security and Privacy Rules Thursday last week. Note that OCR is the division of the Department of Health and Human Services (HHS) responsible for enforcing both the HIPAA Security and Privacy Rules.

I want to emphasize that these are proposed updates, also called Notice of Proposed Rulemaking (NPRM) in Federal Government parlance. There is a 60 days period for the public to submit comments on the NPRM after it was published yesterday in the Federal Register. The comments are due by 09/13/2010.

The NPRM includes updates to the following HIPAA rules or areas:

1. Privacy Rule

2. Security Rule

3. Rules pertaining to Compliance and Investigations

4. Imposition of Civil Money Penalties, and

5. Procedures for Hearings (Enforcement Rule)

As noted in the NPRM, these updates are being made to “implement recent statutory amendments under the Health Information Technology for Economic and Clinical Health Act (HITECH) and to strengthen the privacy and security protection of health information, and to improve the workability and effectiveness of these HIPAA Rules”.

For those who don’t have much history on HIPAA, the current Privacy Rule was issued on December 28, 2000, and amended on August 14, 2002 while the Security Rule was issued on February 20, 2003. So, the proposed updates are long overdue in any case given that Information Security and Privacy risk landscapes have changed substantially since these rules were issued.

I’ll focus on updates to just the Security and Privacy Rules in this post. I’ll have two more posts over the next week or so, one with an in-depth coverage on what to expect from proposed updates to the Security Rule and the other one with a similar coverage of the Privacy Rule.

So, here are notable proposed updates:

1. Replace “individually identifiable health information” with “protected health information” to better reflect the scope of the Privacy and Security Rules.

2. Definition of “Business Associate”(BA) being expanded to include the following new constituents:

a. Patient Safety Organizations (PSO)

b. Health Information Organizations (HIO)

c. E-Prescribing Gateways

d. Other Persons that facilitate PHI data transmissions for Covered Entities or other BAs and require routine access to such PHI

e. Vendors of Personal Health Records (like Google Health and Microsoft Healthvault)

f. Subcontractors of a Covered Entity (CE) – i.e., those persons that perform functions for or provide services to a BA, other than in the capacity as a member of the business associate’s workforce.

3. As provided in section 13401 of the HITECH Act, the Security Rule’s administrative, physical, and technical safeguards requirements in §§ 164.308, 164.310, and 164.312, as well as its policies and procedures and documentation requirements in § 164.316, shall apply to BAs in the same manner as these requirements apply to CEs.

4. BAs shall be civilly and criminally liable for penalties for violations of the provisions in #3 above.

5. Requirements of BA contracts (or other arrangements) between CEs and BAs will now apply to contracts (or other arrangements) between BAs and their subcontractors. It is important to note here that the burden of obtaining assurances (through contracts) from subcontractors regarding safety of PHI falls on the BA rather than the CE.

6. A subcontractor will be required to notify any breaches of unsecured PHI to the BA who in turn would be required to notify the CE. The CE then notifies the affected individuals, HHS, and, if applicable, the media, of the breach, unless it has delegated such responsibilities to a BA.

7. BAs, like CEs, may not use or disclose PHI except as permitted or required by the Privacy Rule or their contracts with CEs or as required by law. If a CE and its BA have failed to enter into a BA contract or other arrangement, then the BA may use or disclose PHI only as necessary to perform its obligations for the CE.

8. Other proposed changes to the Privacy Rule include:

a. Certain material changes to the Notice of Privacy Practices (NPP) issued by a CE or by a BA, if delegated so by a CE through contract

b. A number of changes to the definition of “marketing” in the Privacy Rule at § 164.501

c. Provisions for individuals to request restriction of disclosure of certain PHI to a health plan under certain circumstances

d. New restrictions on sale of PHI by CEs and BAs

e. Strengthen the right of “access” more uniformly to cover all protected health information maintained in one or more designated record sets electronically, regardless of whether the designated record set is an electronic health record

OCR has also proposed that the compliance deadline for all new and updated requirements in the Security and Privacy rules will be 180 days after the final update which I believe can be expected in Q4 this year. OCR is also proposing an additional one-year transition period to modify certain BA agreements. The NPRM further qualifies the one-year transition period as “The additional transition period would be available to a covered entity or business associate if, prior to the publication date of the modified Rules, the covered entity or business associate had an existing contract or other written arrangement with a business associate or subcontractor, respectively, that complied with the prior provisions of the HIPAA Rules and such contract or arrangement was not renewed or modified between the effective date and the compliance date of the modifications to the Rules.”

Assuming that these timelines don’t change in the final rule, all CEs and BAs need to plan for full compliance with the final rules by Q2 of 2011 and for revision of existing BA agreements no later than Q2 of 2012. I want to emphasize here that the current BAs (as defined in section § 160.103  of 45 CFR 160) must already be in compliance with the current  Privacy Rule and certain provisions of the current Security Rule beginning February 18, 2010 as required by the HITECH Act. The new deadlines will apply only to the new BAs (see 2. a-f above)  and for all CEs and current BAs to comply with any new or updated requirements in the final rules.

So, what are the highlights in this NPRM? We have known all along (from the HITECH Act) that the BAs need to comply with the Privacy Rule and certain provisions of the Security Rule. The real highlight to me in this NPRM is the expansion of the definition of a BA. Pretty much everyone (including all subcontractors and others) that has the custody of PHI will now have to comply with both the Security and Privacy Rules. Another highlight to me is the expected compliance deadlines as discussed in the previous paragraph.

As I mentioned earlier in this post, I’ll provide an in-depth coverage of the updates to Security and Privacy Rules in two of my upcoming posts.

As always, we welcome your thoughts and comments. We would also obviously like to hear if you need any consulting support in order to prepare for the anticipated HIPAA changes.

Logging for Effective SIEM and PCI DSS Compliance …. UNIX, Network Devices and Databases

In one of my previous blogs, I covered the importance of logging the “right” events for an effective Log Management or Security Information and Event Management (SIEM) deployment … see here or here for a discussion on the two technologies. The blog also provided a suggested listing of the Windows or Active Directory events that you might want to log from a PCI DSS Compliance standpoint.

Clearly, no amount of investment in your Log Management or SIEM solution is going to do much good, unless you have been able to generate all the right logs to begin with … see a related discussion with the recognized PCI Expert and Author, Dr. Anton Chuvakin here.

I would like to extend my suggested list in the previous post to cover a few other systems here,  specifically UNIX/LINUX, Network Devices and Databases. Note that this list is only a starting point so you can work with the respective System Specialists or Administrators in your organization to generate these events.

UNIX/LINUX Logging for Effective SIEM and PCI DSS Compliance

Logging of Network Devices for Effective SIEM and PCI DSS Compliance

-

Database Logging for Effective SIEM and PCI DSS Compliance

PCI DSS – Quick and Dirty?

I recently received a tweet titled “PCI DSS Compliance – Quick and Dirty”. I think it is safe to say that such a title is bound to grab immediate attention of anyone that has been associated with PCI DSS in one form or another. I immediately clicked the link on the tweet which took me to this page.

Not sure what the tweet’s originator meant to convey…  Neither am I  sure there is anyone that knows or has a quick and dirty approach to PCI DSS Compliance. Not unless perhaps, yours is a highly mature Security and Data Protection program…. I mean really high, perhaps the 90th percentile or higher.   PCI DSS being perhaps the most prescriptive security standard out there, the reality is that most organizations will have a fair bit of work to do before they can claim compliance.

The link on the tweet points to the “Prioritized Approach for PCI DSS”. The document was put out by PCI SSC to assist merchants and Service Providers in undertaking a prioritized remediation effort when they may have gaps in a large number of control requirements.  As the document says, the prioritized approach was developed based on extensive feedback from assessments, breaches and investigations, among other things.

Quoting from the document itself… “It is not intended as a substitute, short cut or stop-gap approach to PCI DSS compliance”.

And then, there is this quote … “To achieve PCI DSS compliance, an organization must meet all PCI DSS requirements, regardless of the order in which they are satisfied or whether the organization seeking compliance follows the PCI DSS Prioritized Approach”.

That said, as a security practitioner, I really wish there will come a day when compliance with a standard like PCI DSS can be quick and dirty for most organizations.

Identity Theft Red Flags Rule – Is the 06/01/10 deadline looking good?

Frankly, I have lost count of how many times FTC has moved the deadline already (see my related post from 2009).  This time, however, I think the deadline is too close (about a week out at the the time of this blog post) that I think the rule is finally going to take effect.  Again, I may be proved wrong… let us wait and see!

Aside from the rule taking effect, enforcement of the rule is going to be interesting to watch! Just this past Thursday,  AMA and two other physician groups filed a suit contending that the rule shouldn’t apply to physicians.  The rule had already been contested by Lawyers and Accountants.

AMA’s suit comes after several back-and-forth discussions with FTC over the last year or so. It looks like AMA wasn’t obviously convinced that the rule should apply to physicians despite what I thought was this compelling argument by FTC.

AMA’s main contention has been that hospitals and physicians are already subject to HIPAA Security and Privacy Rules and therefore the Red Flags Rule shouldn’t apply to them. From my experience, however, I believe that most HIPAA Security/Privacy Programs may not be effective against Identity Theft tricksters of today. I would recommend that health care providers implement a risk-based, written Identity Theft Prevention Program to supplement the Administrative Requirements (§ 164.530) of the HIPAA Privacy Rule and Administrative Safeguards (§ 164.308) of the HIPAA Security Rule.

I think the below quote from FTC’s letter sums it up well:

“The Rule is designed to prevent identity theft primarily by ensuring that organizations are alert to signs that an identity thief is using someone else’s identifying information fraudulently to obtain products or services, including services such as medical care. Thus, the Red Flags Rule generally complements rather than duplicates the HIPAA data security requirements.”

New details released regarding Internal Security Assessor (ISA) program for PCI DSS

PCI SSC has just released new details regarding the training schedule for the ISA program. The program is obviously PCI SSC’s response to the often heard complaints from merchants and service providers about high costs involved with maintaining PCI DSS compliance.  Be sure to read the program validation requirements as well as the FAQs.

Key requirements to note are:

1. ISAs have to be on full –time employment with the sponsor companies. Specifically , ISAs will not retain the certification upon termination of employment and so can’t carry the certification to a new employer.
2. ISAs need to be recertified annually. The recertification process includes ISA Program training and passing the examination every year.
3. ISAs have to be part of a dedicated Internal Audit department.

Important to note is the scope/objective of the ISA program which reads as “to improve the organization’s understanding of the PCI DSS, facilitate the organization’s interactions with QSAs, enhance the quality, reliability, and consistency of the organization’s internal PCI DSS self-assessments, and support the consistent and proper application of PCI DSS measures and controls”.  It also says that the “ISA qualification does not entitle an ISA to perform special functions or conduct QSA Assessments".

Here is another interesting blog post on this topic.

Logging for PCI DSS Compliance

PCI DSS has had specific requirements for logging and review of those logs for sometime now. The logging requirements (under Requirement 10 ) have a primary objective of supporting forensics in the event of a breach of cardholder data. I believe it is fair to say that PCI DSS has played a large role in bringing into limelight the topic of Log Management, in effect creating an assured market for several vendors who are vying for a piece of the PCI business out there.

While most Log Management vendor solutions are featured enough and support quick deployments (normally a selling point one hears from most vendors), I believe it is important for PCI merchants and service providers to take that with a grain of salt. Granted that most vendor solutions have features for effective log parsing, normalization, reporting, alerting etc… As I am sure anyone that has worked on PCI DSS (or for that matter any Log Management or SIEM deployments) would attest, an effective deployment requires deliberate planning and ground work. And in my view, the most critical step for an effective Log Management solution (and most certainly those focused on PCI DSS Compliance) is the very first step, which is Log Generation (see NIST 800-92 Guide to Computer Security Log Management to learn more about Log Management processes). After all, you can get to managing and analyzing logs only if you generate them and more importantly from a PCI DSS standpoint, generate all the right logs!

To illustrate the point, below is a partial suggested list of events you might want to log on Windows and Active Directory. One really can’t overemphasize the need for various system administrators to work closely with the PCI readiness teams to make this happen. I have also included sample mappings to PCI DSS requirements, the likes of which you can use to demonstrate due diligence to your QSA.

Hope you find this information useful and I welcome your comments!