Archive for September 2010

Assessing Risk Is Hard to Do

September 28, 2010

The IREC research team is in the middle of an effort to understand our members’ risk assessment processes and identify information and practices that will be helpful in improving those processes. Thanks to all the members who have participated thus far. Here is an update on the research, with some early suggestions on where Security organizations might find some room for improvement.

  • Harder Than it Looks. Risk assessment would seem like a basic element of running the Security function. However, few members are satisfied with their processes. Indeed, from our perspective in talking to members, there is a wide gap-not just incremental improvement-between standard practice and that of the most progressive members.
  • Disparate Practices. As with so much in security, there is no such thing as a common approach to risk assessments across the organizations we have spoken with. For some security activities this makes sense, as you must tailor your approach to the detailed realities of your organization. So far we have not found much of a reason why this should be the case for risk assessments: most Security organizations are trying to accomplish pretty much the same things with their risk assessments. Instead this seems to be an area ripe for “best practice” maturity improvements.
  • Two Broad Categories of Activity. While most security organizations have several different activities they refer to as “risk assessments”, these seem to fall into two broad categories: 1) Specific, targeted assessments (e.g. assessing the risk of a specific application or a new business project), and 2) High-level reviews of the top risks facing the organization. In principle, it might seem to make sense to determine your high-level view of risk by aggregating the targeted assessments. In practice very few members do this, and from what we can tell this is probably appropriate due to the many well known challenges of risk quantification.

Most Security effort on “risk assessment” is devoted to the targeted assessments described above. The reality of these assessments is that they rarely assess risk, but rather are a look at vulnerabilities and the controls that should be present to address those vulnerabilities. Clearly it is not practical to perform a full threat model and impact analysis for every individual risk assessment, but there are several steps that members can take to better leverage these efforts:

Fewer resources are spent on assessing high-level risk areas. Members interested in this should look into our Controls Maturity Benchmarking Service. Two quick looks at what IREC members view as the top information risk areas for 2010 and 2011 are here and here. We also profiled several alternative approaches to identifying high-level and new risks a couple of years ago.

Let us know what you would like to know about risk assessment.

“The cloud”, just another word for outsourcing IT?

September 21, 2010

The question came up at a recent Annual Executive Retreat of how to conduct a risk assessment of a cloud vendor. One CISO in attendance suggested that “the cloud” is just a trendy term for outsourced computing, and that the risk assessment process is the same as it always has been. Other CISOs like to recall the term time-sharing to point out that everything old is new again.

However much this is part of a cyclical pattern, there are new aspects to the cloud that present new challenges to Security organizations:

  1. Governance. Purchasing decisions are much harder to detect. A credit card and they’re up and running. Members tell us much of this seems to be happening in the Sales and Marketing functions, and cite this as the number one risk of the cloud (see figure below). These are so easy to set up that those who initiate the relationship may not so much think they are going around IT, they are just doing what people do naturally these days-getting stuff done on the web. This creates new problems for Security:
    • How can you detect these transactions?
    • Is it possible to create a policy that defines what is OK and what is not, or do all projects need to go through a security review?
    • If you did create a policy, what are the carrots, sticks, and awareness needed to make it work?
  2. Requiring controls. With larger SaaS and IaaS vendors, there is little transparency into their controls, and the vendor will not change their security as a condition of your contract: the key to their cost efficiency is standardization and low transaction costs. Also, the vendors will rarely sign up for indemnification for when something goes wrong. IREC members are used to having the size to get their way with third parties, but the big cloud vendors aren’t that eager for each new small cloud contract. The balance of power has shifted.
  3. Regulations. Unlike outsourced computing in the past, in many cases with the current SaaS offerings you do not know the geographic location of the data/servers. This can be a regulatory problem, for example:
  4. Vendor selection. There are a lot of apparently small SaaS and IaaS vendors out there, but many are just resellers of services from big providers like Amazon. What accountability and visibility have you sold to the intermediary for a lower cost?

The economics and agility provided by these services are unstoppable, so CISOs must create ways to manage the associated risks. First, CISOs need to understand the business side’s desire to use SaaS offerings and then use an understanding of the organization’s risk tolerance to decide what Security’s posture will be. Specific solutions we have heard about include:

  • Offsetting desire for IaaS by building internal, private clouds, often using existing unused capacity.
  • Creating clear definitions of data or processes that cannot be transferred to a third party without a security review. Ideally the restrictions are minimal, including only regulated data or crown jewels rather than all somewhat sensitive data, which can result in driving activity underground.
  • Providing a list of approved vendors and a “getting started” guide to direct business users to safer cloud services. These guides should encourage submission of new vendors to ensure the lists continue to address user needs and keep Security aware of new cloud players.

What steps have you taken to address the specific risks of the cloud? Let us know.

Does the World Need Another Information Security Maturity Model?

September 14, 2010

One of the big information security analyst firms recently introduced a new, proprietary information security maturity model (ISMM). Existing ISSMs include ISO 27001/27002, NIST SP 800-53, sections of CobiT 4.1, NERC, and so on. ISMMs serve mainly to provide a comprehensive list of security controls and guidance on how to implement those controls, in order to help security functions avoid blindspots and organize their risk-reduction activities. A good ISMM will also describe a maturity scale for each of the controls-what does basic implementation look like, vs. best-in-class implementation.

Considering only this basic use of an ISMM, another one might seem to provide a welcome alternative point of view. However, previous Council research (see for example this and this) has shown that which ISMM you choose does not matter nearly as much as how you implement the ISMM. Furthermore, there are numerous additional uses of ISMMs that are not served with a new, proprietary ISMM:

  1. Provide a standard language for security organizations to communicate.
  2. Serve as a platform for the development of standardized security processes.
  3. Allow for detailed benchmarking between organizations.

In 2010, 77% of large security organizations are using ISO 27001/27002 (this will be covered in today’s webinar on budget and organizational trends). ISO has become a near universal language for security organizations, except for those required to use NIST. This is why when the Council created our Controls Maturity Benchmarking Service, we avoided the temptation to try to improve on the existing ISMMs, and instead created a tool to help CISOs measure their controls maturity against the ISO and NIST standards. This has contributed to the popularity and usefulness of the Controls Maturity Benchmarking Service, which now allows organizations to obtain a detailed benchmark their security controls against those of almost one third of the Fortune 500.