Posts Tagged ‘Assessment’

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.

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.

Providers – Is HIPAA Security Risk Analysis in your plan over the next few months?

Security Risk Analysis is something that we recommend all organizations conduct periodically or before a  significant process or technology change. After all, threats, vulnerabilities and impact (three components of risk, see my other post here) often change or evolve over time which means that risk analysis results can soon become outdated.

In the context of Healthcare, Security Risk Analysis is also mandatory for two reasons.

The first reason is that it is required for compliance with HIPAA Security Rule which, by way of the HITECH Act, now applies to Business Associates in addition to Covered Entities.  It is a “Required” Implementation Specification in the “Security Management Process” standard under Administrative Safeguards of the HIPAA Security Rule, as highlighted in the table below.

The second (and more urgent) reason to conduct a Security Risk Analysis is that it is a core requirement for providers to achieve Meaningful Use certification of Electronic Health Records (EHRs) and thereby become eligible for Medicare/Medicaid incentives beginning April 2011 or risk Medicare reimbursement penalties beginning 2015 (see below).

Source: Center for Medicare & Medicaid Services (CMS)

So, it is important that providers plan on conducting a security risk analysis within the next few months unless you have conducted one recently. If you have already implemented an EHR system, you will need to ensure that the risk analysis included the EHR system and the related processes or practice workflows. If you plan to implement an EHR system in the next few months, we would recommend conducting risk analysis before the implementation so that any discovered risks can be identified and mitigated by proper design of the system and associated workflows or processes.  Any change to the system or processes after implementation is going to be hard, not to talk of the disruption to the practice and other costs.

The Final Guidance from OCR on Risk Analysis can be a useful reference in planning and conduct of risk analysis efforts.

Finally, I would like to go back to what I said right at the beginning. We recommend that organizations focus on managing all information risks, not just the risk of non-compliance with regulations such as HIPAA.  Therefore, it is critical that personnel performing the risks analysis are up-to-date on the current threat environment. Upon determination of the threats, one must be able to clearly identify the organization’s vulnerabilities to those threats and then the impact resulting from any exploits and various legal or compliance obligations including HIPAA.  Last but not the least, risk analysis must be conducted at appropriate intervals and certainly whenever there is a significant change in processes or technologies.

—————————————-

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.

Verizon 2010 Data Breach Investigations Report – Key takeaways for Security Assessors and Auditors

The Verizon 2010 Data Breach Investigations Report (DBIR) released last week has some interesting findings, just as it did last year. What makes it special this year is that Verizon partnered with the United States Secret Service in developing this report. I don’t intend to discuss all the statistics in this blog (will do so in another upcoming blog) but as you will see explained in the report, the Secret Service’s involvement has thrown new light into some of the findings.

My intention here is to highlight the significance of such a report to security and audit practitioners with the objective of improving the quality of their risk assessments or audits and more importantly, help make the right recommendations to management.  From my experience as a security practitioner and an occasional auditor, I can tell that we may not always be using all the available information to help improve the quality of our risk assessments or audits. And, I think reports such as the Verizon DBIR can provide some valuable help from that standpoint.

Let me explain what I mean… Deliverables for any risk assessment or audit typically include a list of findings and for each finding, we provide an explanation of the risk, the risk severity  (High, Medium, Low) and suitable recommendations for risk mitigation or remediation.  The management would then proceed to remediate various gaps in priority based on our risk rankings. Considering that risk is a product of likelihood and impact (I like the OWASP risk rating methodology, so will use it here), it is important that we get the impact and likelihood right.  Impact is largely a function of the organization’s characteristics including various technical and business factors seen in the methodology. On the other hand, likelihood is a function of threats and vulnerabilities.  I think the DBIR can be a useful reference in estimating the likelihood.

For example, the DBIR says that external agents were responsible for about 78% of the breaches whereas about 48% were caused by insiders. These numbers can be used to arrive at a better objective estimate  of the likelihood that these threat agents may cause any harm. Similarly, the DBIR also says that  48% of the breaches involved privilege misuse, 40% resulted from hacking  and 38% utilized malware. These numbers can be used for objective estimation of the likelihood that associated vulnerabilities could be exploited. The OWASP methodology has an illustration for such objective risk estimation.

These are but a couple of examples. The DBIR has a wealth of information that can be useful to auditors and security practitioners alike, both in improving the quality of their work as well as in being able to defend their risk rankings. We all realize that risk rankings almost always have a level of subjectivity in them but I think reports like the DBIR can be leveraged to make them as objective as possible. A very good example is the risk level one might normally assign to a case of unpatched vulnerability versus a configuration issue.  It may not be readily obvious that one might need to be assigned a higher risk level over another until you read the DBIR. The DBIR tells us that the likelihood of exploitation of an unpatched  vulnerability is far less as compared to a vulnerability caused by a configuration issue. If we didn’t leverage the DBIR (and assuming both issues had equal impacts), we might assign equal risk levels to both the findings or worse, we might assign the unpatched vulnerability a higher risk level.

Over the next couple of weeks, I plan to be blogging with a detailed commentary on some of the findings in the report including a special post on how the report can be leveraged to enhance the effectiveness of PCI DSS programs.

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 might be of assistance to you.