Security and Risk Management Strategies Blog

Measuring security performance

Blogger: Ramon Krikken

Security metrics is an ongoing hot topic (and pain point) for many of our customers and the industry in general. Of course everyone would very much like to find the one elusive key risk indicator (KRI) that near perfectly predicts the future … but predicting the future as usual turns out to be difficult at best. So we are turning our eyes to security performance measurement (i.e. looking at the past) in an upcoming overview and related talk at our annual Catalyst conference.

There are certainly plenty of security metrics out there, even in the performance area. But something to the likes of “number of incidents” or “percentage of systems with up-to-date patches” is at most something to compare with others – if even that – and it certainly does not make an actionable metric. What we need are goals to track towards and ways to understand how lack of performance leads up to incidents and other bad things.  I of course don’t want to give away one of the punch lines, but let’s just say a large part of it has something to do with establishing correct frames of reference.

And there are of course other documents and presentations related to this topic. Hot off the press is an Executive Advisory Program overview “Communicating Clearly About Risk” by Bob Blakley (subscription only), we have a half-day topic devoted to “Proving the Business Value of IT” which will feature plenty of metrics, Jack Santos touches on the bad side of metrics in the “What Will Your Boss Say? The Reality of Security” presentation, and in one way to circle back to risk management Fred Cohen will present “Risk Management: There are no Black Swans.”

So stay tuned for the upcoming document, and join us for the conference July 27 – 31 in sunny San Diego. You can find the schedule at https://burtongroup.wingateweb.com/us09/scheduler/weekAtGlance.do

Risks Around Hosted Email

Blogger: Eric Maiwald

Email is information on the move! It is different than information at rest.

In talking to analysts in Burton Group’s Collaboration Strategies Service about one of their talks at Catalyst, I heard a very disturbing idea. We were discussing hosted email and one of the analysts, Bill Pray, mentioned that enterprises that were moving toward using hosted email (email in the cloud) were keeping “sensitive” departments (HR, finance, etc.) on internal email systems. The reasoning was that these departments dealt with sensitive information and therefore should not be included on a hosted system.

But wait! This assumption may sound right on the face of it but it does not hold on further analysis. Back in (ancient) history, information was stored in filing cabinets. Cabinets in HR and finance were locked to prevent unauthorized people from seeing the information. As we moved to a more computerized environment, sensitive departments were given their own file servers so all of the sensitive information was stored together and the number of people authorized to access the files was limited. This worked as the information was at rest.

Email is information on the move and violates this base assumption. You can segregate the email from HR, Legal, Finance, and other sensitive departments to protect it, but as soon as someone sends email out of the protected environment, all bets are off! Most email is likely to be between team members but not all. Just think about HR. Employees may send sensitive emails to HR people and vice versa. The sensitive information exists in the email system – not just within the HR email system. The same is true for any of the other departments as well.

Don’t just assume that the paradigm used for information at rest works for information in motion. You have to treat them differently!

Of course, the bottom line for very sensitive information is: Do not send it over email in the first place. If you absolutely, positively, have to send very sensitive information over email, use some type of encryption mechanism along with a strong authentication mechanism to protect it.

Cloud Computing: Who is in Control?

As with real cirrus, stratus, and cumulus clouds IT’s cloud computing services come in various types and often combine with each other to make strange formations. An exposed hiker in the open might ask: "Is that but a fair weather cumulus cloud, or an ominous storm cloud?”

In the world of IT security, we call that risk assessment.

When it comes to putting your IT resources and – perhaps – even slightly sensitive data such as personal names, addresses, and phone numbers into the cloud one might start with these three questions:

• Who is in control?
• Do they provide assurances?
• Can we trust them?

In traditional IT environments, organizations generally share control over the network with service providers, but for the most part control their applications, servers, and storage infrastructure. In an internal cloud environment, the architecture changes, but not the complexion of control. As shown in the figure, however, the control architecture changes profoundly for public cloud offerings such as Amazon EC2, Google Apps, or Salesforce.

As we move from left to right in the diagram and put more and more control in the hands of the service providers, the outlook shifts from fair weather green to ominous red.

Assuming we trust our IT department to give the necessary assurances and do their jobs well, the “dedicated IT” stack is green but for its use of the Internet, which is yellow.

With server hosting providers or “colo” data center facilities we still retain substantial control, perhaps relying on the service provider only for rack space, power, and cooling. In these simple arrangements, the service hosting providers will typically provide assurances, or service level agreements (SLAs). They may help us build trust by offering site tours, audits, and track records. We may feel we can fully understand their operations and residual risks. We may feel comfortable sharing control of the server, storage, and network functions with hosting providers. Yellow is mellow.

In the world of cloud computing, everything changes. As we move from

• Infrastructure-as-a-Service (IaaS) with its line of demarcation in the server where the silicon stops, to
• Platform-as-a-Service (PaaS) where you cross the line after your code and applications are integrated with outside components, to
• Software-as-a-Service (SaaS) where you abandon all control when you hand over your data

I paint the functions these services control an alarming red. To see why, we must ask: Do they provide assurances?

No. The major public cloud computing providers generally offer no SLAs at all. They accept little or no liability even for the security measures their own advertising claims to provide.

Can we trust them? The short answer is no. Their actual security measures are obscure, vulnerabilities undisclosed, and audits unimpressive.

But each situation is unique and everything relative in risk management. With a water tight raincoat as counter-measure, the hiker need fear no rain. Lightning may be the only residual risk, and that may be acceptable. There is much more to be said about the risks of cloud computing and how one might ride this red tiger with a yellow whip; controlling enough of the data, applications, or virtual machines to accept some residual risks. Another option might be to consider internal clouds or private (community) cloud arrangements that give customers more say.

We’ll say all this at Catalyst North America and more. In our “Flying into the Cloud: Executive Perspectives on Externalized IT” track, we’ll cover practical perspectives on leveraging public clouds. We’ll cover internal or hybrid cloud strategies that maximize our control as we reap the benefits of the industry’s “big switch” to cloud’s elastic, on-demand architectures. And in “Cloud Now: Usage, Practices, and Rewards” I’ll go much more in-depth with “Security Strategies for Cloud Computing.”

A View from the Other Side

Blogger: Eric Maiwald

In security, we must understand how we are perceived by the business. What we think is critical may not matter at all to the business overall. We will not learn what matters to the business if we only focus on security vulnerabilities and the latest technology. We need to get out and learn how the business functions and how security impacts it. A recent experience brought this home to me.

I was in the Midwest visiting friends and I had the pleasure of being introduced to a man named Neil. Neil works in the maintenance division of a large agricultural services company. When he found out that I worked in IT security, he launched into a story about two IT people he knew. The first IT guy he really liked. This guy came into the division where Neil worked and helped them get their computers up and running. Neil explained how the computers helped him do his job and how this IT guy really paid attention to how the shop was run. Neil lamented the fact that this “good” IT guy took a job with another company and left.

Neil then launched into a story (you could almost call it a tirade except that Neil didn’t raise his voice) about the second IT guy (let’s call this the “bad” IT guy). The bad IT guy showed up and started changing things. He introduced a new system to track parts in inventory and then found ways to cut costs by reducing the inventory. Neil went into a long discussion about the parts inventory. It seems that his shop has to maintain a lot of equipment – much of it quite old – and they kept a lot of older parts on hand for the simple reason that some of the parts were hard to find. In addition, the mechanics would often only use components of a part if that was all that was really needed and they would keep the remaining components for use at some later time. Neil freely admitted that they were pack rats to some extent but he explained that they hoarded some of the parts because it allowed them to fix equipment quickly and get it back into operation without waiting for a part to arrive.

It is still unclear to me what position the bad IT guy held within Neil’s company (and it really doesn’t matter for this story – Neil perceived him as an IT guy) but he was able to change the parts inventory practice and get rid of a lot of the older parts. This was touted as a cost saving measure and was done without consulting with the people who did the work. Without the parts readily available, the time to repair older equipment increased. Equipment waited for parts to arrive (or in some cases to even be found!) and the overall availability of the equipment suffered.

So why am I relating this story? Neil’s perception of IT is formed by the IT people he interacts with. On the one hand, the good IT guy paid attention to Neil and his coworkers. He provided support for their work and helped them improve the shop practices. The bad IT guy didn’t learn how and why certain business practices existed in the shop. He only saw the potential cost savings without understanding how changing the practices might increase other costs and reduce the availability of equipment.

Who do you want to be? Who do you think your business perceives you to be? We need to be more like the good IT guy in the story. We need to learn how the business functions, what is important to the business, and how security impacts the business.