Posts Tagged ‘risk management’

Choosing the Risk Framework with the Best Fit

Monday, February 20th, 2012

I was reviewing the changes to NIST SP 800-30 today, and have been discussing with several colleagues how one chooses the right risk framework given that there are so many known flaws or limitations with the ones commonly used today.  That got me thinking about what an organization who is just starting out needs to do day 1 to get their program off the ground and showing value.  Otherwise they are never going to get the opportunity to implement a mature or elaborate program.

The following are some initial thoughts on that initial selection process as part of building a program from scratch, but making the best use of what is out there knowing it isn’t even close to perfect:

  1. Matching the company culture / industry
  2. What exists already?
  3. Map to business’ strategic objectives
  4. Articulate the organization’s risk tolerance

When looking at the ‘frameworks’ that are commonly used in information security circles, you will find that they all came about to address slightly different problems, and therefore may be more suited to one environment or another.  For example, the OCTAVE framework’s emphasis on workshops, interviews, collaboration, and detailed worksheets might not be a good fit for a federal government agency, but it might be well suited for a software development company.

Beyond the frameworks themselves, it is essential to consider what risk processes and practices already exist within your organization.  You might look to the operations, legal, insurance, finance, business continuity, compliance, business strategy, or human resources teams to identify if they have a framework for risk assessment or management already.  If something does already exist, be sure to first determine if it can be expanded to meet your needs or how the information security risk frameworks would interoperate with models in other business units.

The next step before you select a framework is to look at the core objectives of your organization.  Make a list of your company’s annual strategic objectives, read the mission statement or vision statement, and look where the company is investing resources most heavily.  This is an important activity, because it can inform the style of framework that works best for you.  For example, if your organization is expanding into international markets you may want to consider the ISO framework because it will be more accepted than NIST outside the U.S.  Similarly, if your organization may have new regulation on the horizon, you would want to look at the frameworks that are recommended by that regulator to avoid unnecessary audit challenges later.

Finally, before you select any framework or even a risk model, you need to guide the executive team through the exercise of articulating the organization’s risk threshold.  Have them describe in words only, what level of risk they want escalated to them.  For example, if the organization’s mission includes a focus on being highly available to clients, then this might be their risk tolerance statement:

“At a minimum, any risk that is likely to result in service outage for all clients longer than the published recovery time objective should be escalated to the executive management team.”

Then you would want to select a framework that could articulate risks in a way that would allow you to compare each risk to this tolerance statement easily.  The framework would need to include the same risk factors that your organization is focused on.

If this topic interests you, you may want to check out my upcoming session at RSA Conference 2012 later this month: Taking Information Security Risk Management Beyond Smoke & Mirrors (GRC-107).  You can get a feeling for the content of the session by listening to this podcast I did last month: GRC-107 Sneak Peak.

Stop Asking for a Copy of My Pen Test Report

Saturday, December 31st, 2011

Clearly vendor due diligence reviews are an essential part of any risk management program, but the consistency and quality of the assessments being done today are really appalling.  Anyone who is working for a service provider today is probably getting inundated with requests ranging from a 50 item checklist of yes/no type questions all the way up to requests to review internal policies and procedure documents, or even an on site walk-through.  You might think that the variety of request types and levels of detail demonstrates that the customers are taking the time to rank each  provider based on the sensitivity of the service, and assess them accordingly, but sadly when you read through the due diligence requests it becomes obvious that most organizations have no clue how to assess their vendors.  Many have clearly just redistributed their own internal risk assessment questionnaires and don’t even bother to remove the internal acronyms and references.  Others clearly don’t know where to focus and try to audit every possible control one might implement in an environment.  This brings up a fundamental point, risk assessments and audits are not the same, but when you have people running a risk management program who don’t understand the distinction, you get a lot of activity with little actionable results.  The intention of a vendor risk review is to gauge whether that service provider presents an unacceptable risk to your organization, not to document every practice, procedure, and technology that may differ from your own environment or an industry framework like ISO.

Some of the worst offenders will waste your and their own time following up on questions about disclaimer banners on systems or why you only prevent the reuse of the last six passwords instead of the last twelve.  You can’t tell me that they are prioritizing based on risk!

Now a growing trend is to collect volumes of documentation like an auditor would, but this is problematic in many ways.  The first concern is whether it puts the service provider at risk to provide this data to all their clients.  In a shared service provider model in particular, am I really going to give you a copy of all my firewall rulesets?  If I do, then I think that should be the risk.  Same with the increasing demand for copies of penetration test reports.  These are some of the most sensitive documents an organization has, and we are supposed to just hand them over to every client just because there is an NDA in place?  Given that these reports are basically step by step instructions for how to compromise an application or environment, it really doesn’t seem responsible to be distributing them.  Instead of asking for the details on every single vulnerability found, you should be assessing the frequency and scope of the testing being performed, and ask for metrics on remediation of the highest risks.  There are plenty of ways to assess the quality of a security program without knowing the particulars of every vulnerability that has been found.  It comes back to a basic discussion about meaningful metrics.  You can certainly ask all your providers how many critical and high risk vulnerabilities have been found and not yet remediated, but that is pretty meaningless unless the answer is zero.  And even then that really doesn’t tell you much about your risk posture tomorrow, or next month.  If you want to assess a provider’s risk posture, ask for metrics on turnaround time between identifying a high or critical vulnerability and remediating it.  Or take it one step farther and ask them for their metrics around the time to implement some kind of mitigating control once a critical risk has been identified.  If these metrics aren’t good, or they have never gathered them, then you know something about the maturity of their program that is more than a point in time vulnerability discussion.

Of course in a dedicated provider model, this level of audit might be appropriate, but organizations need account for the differences in the service provider model and realize that they give up something for the cost savings of shared services.  Same with requesting copies of detailed network diagrams or the names of technologies being used.  You need to assess a vendor’s maturity and process, not every single control possible.

Another issue with the “give me everything” documentation requests is that is distracts the assessor from finding the real significant risks.  If a clients asks for a copy of every single security policy, standard, and procedure document, how can they possibly digest all that information without a team of analysts, and is it even worth it?

Organizations need to take a hard look at their practices for performing vendor risk reviews, and be honest about whether they are really focusing on risk or turning it into a blind checklist based audit.  Frankly, some of the due diligence requests I have seen from organizations recently make me start to question their own internal program’s effectiveness.