Archive for the ‘Risk Management’ Category

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.

Contemplating My Goals for Risk Management Education

Sunday, September 26th, 2010

As I am getting ready to teach the debut session of my new SANS MGT442 course this week, I have been thinking a lot about what my goal was for the course. It has been a long road to develop this course. I think that I first pitched the idea to SANS in June of 2009. Around that time I felt like risk management wasn’t getting nearly enough attention in the information security field, and so many professionals didn’t know the first thing about assessing risk. We had organizations running a qualys scan, and thinking that was a risk assessment, and security managers escalating every vulnerability to executive management like it was the end of the world. Now, over a year later, every security conference has tons of presentations with risk in the title at least, and risk as become almost as big of a buzz word as virtualization or cloud. I have even seen some great strides forward in the research and implementation of some really robust and advanced risk analysis models, but are we any better off than a year ago?

Every time I have to interview candidates for a open position, I am amazed how many have nothing more than the equivalent of a Devry training in information security. They have a bunch of tools in their toolbox, and they know the so-called “best practices” for applying them. The problem is that they have no idea how to really analyze a situation and consider solutions outside the normal model. It’s like taking your car to the dealership these days, if the computer doesn’t say anything is wrong with the car, the mechanics have no idea how to troubleshoot the strange noise coming from under the hood. Security practitioners still follow a simple methodology: find vulnerability, patch vulnerability. They also have a long list of things that aren’t ever allowed, but ask them for a creative way to mitigate the risk without just saying no, and they are lost.

As I really think about my goals for this new two day course on information security risk management, it has always been my number one goal to: educate the field about how to look at a problem, understand the real risks, and find a solution that meets the business needs, while keeping the risk level in an acceptable range.

Since I have recently joined the Society of Information Risk Analysts, I have been exposed to some really fantastic work that will surely move our field towards the level of maturity and precision that we desperately need. But I look at the gaps in knowledge and skills in the field, and I know that the audience for my class just isn’t going to be ready to digest that depth on the first pass. First we need to help the profession to understand and develop basic risk models that can move their security programs out of the “village elder” type approach to risk predictions. If we can provide a strong foundation for dissecting a risk and building a security program around risk management, then it should be trivial to substitute in more precise analysis models later when you’re ready. In my experience, the organization has a hard enough time absorbing the basic concepts of residual risk and compensating controls, if you also throw in advanced concepts like the differences between likelihood and frequency, you will lose them completely. I have seen so many security programs try to take on too much too fast, only to see it rejected by the corporate culture. I have found more success setting out your long-term goal, which may include a sophisticated quantitative risk model, but keeping this vision to yourself. You need to slowly lead the organization towards that end, but in small bite size chunks that they can digest. If you structure your risk program right, you will have all the foundational steps in place to keep raising the level of precision as the business finds the limitations in the simple models for themselves.

If by the end of this course, students come out understanding how to really break down a risk and understanding how to recommend solutions to address the real exposure and not just the symptoms, I will consider the class a success. If they also understand how to implement an information security program based on these principles, then I know that our profession will be better for it. If done right, the security risk management program will be so integrated into the core business processes that the lines will start to blur between functions like security, business continuity, vendor management, and operations to the point that security won’t feel like an island in the organization, it will just be embedded in every business decision.

Avoiding Formulaic Security

Sunday, February 21st, 2010

The problem with the information security these days is the emphasis on checklists and so-called “best practices” that may not be appropriate for all situations. For the sake of simplicity and consistency, the security field has evolved into a cookbook-type approach. Everyone gets the same recipe and is expected to execute on it in the same way, but we don’t live in a one-size-fits-all world. Instead of blanketly applying so-called “best practices” across the board, we should be using some risk analysis techniques to determine the best controls for our organization. The current training opportunities turn out security professionals who know which activities to perform and which patterns to follow, but can’t tell you why. The problem with this is that they have no idea what to do when the situation doesn’t fit their patterns, or even worse they apply the same checklists even if it doesn’t address the actual risks. Have you ever interviewed someone who is very technically savvy, and tried asking them why they do it a certain way? The scary thing is that most people can’t explain why. They have just always done it that way, or been told to do it that way, and never questioned it.

If you are transferring sensitive data over the network, then you need to encrypt it every time. But why are you encrypting it? What problem are you trying to solve? What risk are you trying to mitigate? Having checklists and baselines makes it easy for security novices to apply a minimal level of protection without having to understand the intricacies of information security, and also provides a basis for auditing. Just think about how many times you have gotten a recommendation from an auditor or third-party consultant, and it is clear that they don’t understand the real risks for your organization. I can’t tell you how many times I have seen recommendations that identify a “high” risk that should really be listed as low risk if you understand the business model of the organization.

We need to train our senior security professionals in the field to perform a real risk analysis and not just accept the established cookbooks for security. Even NIST seems to be moving in this direction with the latest draft of their SP800-37 guide for Certification and Accreditation which is now totally based on a risk management approach. This is clearly the future of the field. More dynamic and flexible approaches to security that bases recommendations on the particular risks of each scenario, not just a single pattern for the entire field. Just look at the Payment Card Industry, I don’t think that anyone would say that the PCI requirements have made retail companies more secure, just compliant.

As the threat landscape continues to shift, your old checklists and formulas for information security just aren’t going to cut it any more. If you want to stay ahead or just keep up, you need to understand the fundamental components of a solid information security program, and decide how to apply them given the particular risks to your organization. I think that “best practices” should be considered dirty words in the field. How can a single list of “best practices” possibly apply to my organization and yours in the same way?

New Risk Analysis Webcast with SANS

Wednesday, September 9th, 2009

Want to learn more about risk management?  Don’t know where to start developing your own risk model? On October 20th, I will be presenting a free webcast hosted by SANS and sponsored by Rapid7:

Changing the Way We Manage Vulnerabilities & Patching

If you are a resource administrator, then you probably spend too much time responding to new vulnerability reports and patching systems. For the security folks, you probably spend too much of your time tracking down the status on remediation and trying to qualify new vulnerability notifications. So how can we manage this better? This session will focus on how to take vendor and industry reports of new vulnerabilities in software/hardware, and analyze the risk to your own organization. With limited time and resources, you can’t patch everything on day 1, so how do you determine which alerts are actually critical for your environment?

The answer is to develop a risk model that takes into account the particulars of your environment. We will demonstrate how to develop your own risk criteria for severity and likelihood by analyzing some recent vulnerability notifications. By the end of this session, attendees will know how to analyze a new vulnerability report for the distinguishing characteristics that would make it a critical weakness for some, but a moderate concern for you. Armed with this knowledge, you can better focus your administrators’ efforts.

Register here:

https://www.sans.org/webcasts/changing-way-we-manage-vulnerabilities-and-patching-92834