Archive for the ‘Information Risk Governance’ category

“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.

The Future of Corporate IT: Implications for Information Risk, Part 2

May 25, 2010

We wrote recently about the five trends impacting the future of corporate IT, and the implication of first three trends for CISOs – information over process, IT Embedded in Business Services, and externalized service delivery. In this post we want to continue with the implications for the CISOs for the other two trends postulated in that work.


The Future of Corporate IT: Implications for Information Risk, Part 1

May 18, 2010

Two weeks ago we shared with you findings from the broader IT practice research effort about five trends that will reshape corporate IT functions in the next five years. In the next few posts we want to discuss with you risk and security implications arising from those trends. Here we tackle the first of the three trends postulated by the > future of corporate IT.


The Future of Corporate IT: 5 Radical Shifts in IT Value, Ownership and Role

May 4, 2010

We here at IREC are part of the IT Practice of the Corporate Executive Board. The IT Practice has just released what is probably the most important research we have done in years: The Future of Corporate IT.

The Future of Corporate IT

Our research series on The Future of Corporate IT is based on interviews and surveys with IT and business leaders at over 200 organizations, and on our analysis of business, social, and technology trends. As a result, we find that there are five shifts underway that will radically change how technology is used to create value and how the IT function is structured and managed. These shifts will upend job descriptions across IT management and result in a massive translocation of IT do-ers.


Avoid the 2 common mistakes when formalizing information risk governance

April 9, 2010

Governance of information risks is usually pretty informal. The Information Risk function has to do most of the work identifying risks and trying to get others to “do the right thing”, whether that be to not click on links in random emails, to code applications securely, or to conduct thorough due diligence before business process outsourcing.

For obvious reasons, we would like this governance to be more formal. If everybody knew when risk decisions needed to be made, and who should make them, fewer things would slip through the cracks and the security function wouldn’t have to do so much of the work!

However, we believe that many organizations that try to formalize information risk governance go about it the wrong way. (more…)

Information Risk Metrics — Necessary But Not Sufficient

February 15, 2010

IREC members overwhelmingly report that improving the information risk metrics program is at or near the top of their agenda for 2010.  Almost to an individual, CISOs tell us that the ROI calculation for their metrics program isn’t nearly what it should be.  Years of ongoing investment—staff time to collect and report metrics, expensive technologies to aggregate data feeds, etc.—have led to just a marginal improvement in tangible outcomes.

Organizations use metrics in the service of three major outcomes: 1) Communicate persuasively with executives; 2) Improve internal efficiency; and 3) Track the risk landscape.  In each case, good metrics are a necessary but not sufficient mechanism for solving the problem, and leading organizations are working to find the correct balance between metrics and other decision tools. (more…)