Security and Risk Management Strategies Blog

I Want to Know Who You Are!

Blogger: Eric Maiwald

We are in the final stages of analyzing the results of our research into network security architecture and one of the things that jumped out of the research was a huge desire and need to know who and what is connecting to the enterprise networks. The need to identify users and machines is a major driver for network admission and access control. For the most part, the decision was binary – I know you or I don’t; I recognize the machine as one of ours or I don’t. This decision applied equally across wired, wireless, and remote access networks.

User and machine identity is used to determine access to resources but more importantly, it also determines how you are allowed to access the resources. For example, if the user is recognized but the machine is not, the user might be redirected to a terminal server environment (if access is granted at all).

But there is more to it than simply knowing who is connecting to the network. There is a desire to hold users accountable for their actions. One of the interviewees put it very clearly, “I don’t just want to know which IP address or machine performed this bad thing, I want to know which user did this.” Based on the research results, we can take things a step further and say that holding the users accountable for their actions once on the network is becoming as important as preventative controls. It seems that this change comes from cultural issues that show security (and more generally IT as a whole) cannot be an impediment to business.

Along the same lines we found most organizations are thinking of NAC as using user and machine identity to control access. While there was some discussion about health checking the end point, this appears to be more of a future wish list item. We found problems with health checking at the time of admission to the network, but the real issue was what to do if you found a non-compliant end point. If security and IT cannot be an impediment to business, then a non-compliant end point may not be sufficient reason to deny the user access to the network (assuming that the end point belongs to the enterprise of course). This is especially true if the remediation of the non-compliant issue is not quick, easy, or invisible to the user.

We have more analysis to perform on our data. The results of the research will be presented in June at Catalyst North America in San Diego. Look for more blog entries and content based on this research in the future.

Operationalizing Security

Blogger: Trent Henry

Although friends and family would say otherwise, and tend to berate my penchant for sesquipedalianism (look that one up), I prefer to avoid a word as long as "operationalization."

However, we received an important question from a client lately: "What are the top security tasks that can be operationalized?" Put another way: "What tasks can be offloaded to network-, desktop-, or other operations groups?"

We've observed a trend over the last several years of enterprises moving certain day-to-day "security" functions to operational teams. This frees the security group to focus on more strategic matters, such as policies and architecture. It's a good management practice and creates natural separation among those who carry out tasks, those who provide oversight, and those who design controls. But what's the low-hanging fruit?

Foremost, here are some "operationalization litmus tests" for whether or not something might be handed to secops, netops, or desktop ops:

• Is it a repetitive task that is clearly spelled out in a process or procedure?
• Would operational execution of the tasks cause any violation of segregation of duties?
• Are there specific regulatory or contractual mandates stipulating who must do a piece of work?
• How high is the business risk in the area under consideration? The higher the risk, the more security oversight is warranted

Looking at common security tasks, here are some "best bets" for those to operationalize:

• 1st level help desk, including password reset and other credential handling
• Standard user account management
• Desktop patching
• Running standard vulnerability management infrastructure
• Firewall rule changes, if part of proper change control program with external oversight
• (possibly) Some degree of project management
• Security awareness and training execution (which might be handled by HR)
• Routine assessments (business unit, vendors, or others) that have been standardized (and "standardized" is an extremely important caveat, because such assessments might be compensating controls. For example, they might provide the monitoring of an outsource vendor's security program.)

On the flip side, here are "best bets" to retain in a Security architecture/strategy/program management team:

• Incident response (although ops might need to lend a hand)
• Future security architecture
• Policy
• Risk management and compliance monitoring
• Security awareness and training development
• Assessment program development and roll-up (create certification and accreditation [C&A] criteria, and aggregate organizational results)
• Interface with internal/external audit and higher-level risk management functions

Whether to shift/contain costs or keep security teams focused on more strategic functions, operationalization can be a legitimate, wise approach.

What are your experiences?

RSA Conference: Innovation becoming mainstream?

Blogger: Randall Gamby

Last week I attended the RSA Conference in San Francisco, CA.  While there was the usual flurry of security product announcements, there was a subtler undercurrent running through the show.  I heard the keynote speakers saying things like: “…security revolves around the three points of people, policy and technology”, “…you can’t secure what you don’t manage”, “…the future of security services is information-centric security”, “…end-to-end trust frameworks are needed”, etc.  Considering that RSA has led with technology in the past - after all it has one of the largest security expos in the country - this was quite a different outlook. 

In many ways this was a good conference for Burton Group.  The conference was, in a sense, validation of what Burton Group has been talking about since SRMS became a component of Burton Group’s portfolio of research areas.  Breakout sessions touting some of our tenets of security services being more than just firewalls and hardened platforms were starting to draw a significant number of attendees, however, the technology-oriented sessions still had the largest turnouts.  It was great to attend sessions where speakers were talking about how they’re developing security policies to address new threats and regulations; a talk on how a company’s security organization is structured to address business managers’ requirements through bi-directional communications through security liaisons; and a presentation on how roles are key to maintaining secure access. Quite interesting.

In addition, I attended a half-day off-site conference with Jericho Forum.  This Open Group sponsored forum has recognized that IT-dependent businesses have issues with traditional security mechanisms no longer meeting the business’ need for conducting dealings across open, extended enterprise environments. They have proposed a different model, de-perimeterization. Again echoing with the RSA conference’s themes of information-centric security and end-to-end trust (and Burton Group’s points of view).  Actually I was quite surprised that the Jericho Forum and RSA didn’t have closer ties, as they’re both preaching the same messages to the same crowds.

Finally, through manning our booth at the conference and talking to various attendees I found that security metrics – one of our 2008 “Security Vital Signs” – is a hot topic.  Both business managers and security personnel have recognized that security services are vital to the enterprise and have intrinsic value, but with the ever-decreasing security budget find themselves having to constantly justify their expenditures to get a piece of the budget pie.  To many I spoke to, being able to quantify the value, and cost, of security is getting harder and harder.  One of the metrics breakout sessions at RSA had people going around the block to attend, but the people I talked to afterwards said it didn’t go far enough and didn’t address their needs.  In all fairness to the speakers, metrics are a personal thing within an organization.  Like any sets of numbers, they have to be applicable to an enterprise’s current and future activities, they have to be quantifiable, and they have to address real issues the individual organization is dealing with.  No one set of metrics will fit everyone’s needs.

So my outtake from the 2008 RSA Conference was, "Security services have been hampering innovation with thoughts around denial but today's security services have to be about enablement of innovation using new processes, new procedures and new technologies."  Yep, quite a different RSA show.

How much is enough in an endpoint protection suite?

Blogger: Dan Blum

I was reviewing a product profile for a small anti-malware vendor with our analyst team, and received the following question:

“In the analysis of the product, you only mention its lack of host intrusion prevention software (HIPS) as a gap, but not its lack of a vulnerability management product. What components need to be part of core endpoint security functionality?”

At this point I’m evaluating endpoint anti-malware suites as follows: While customers may not deploy all these features, the vendor should be able to offer anti-virus, anti-spyware, web threat protection, mailbox/mail scan, system firewall, NIPS, HIPS, NAC, and application control on the endpoint – all with unified administrator-minimizing management, broad platform support, easy migration from previous releases, good end user experience, modularity, affordable pricing and good industry test results.

Symantec and McAfee, as the market leaders, provide benchmarks against which other vendors in the anti-malware space can be compared. The Big Two are broadening “endpoint protection” to include data leakage protection (DLP) and host encryption in their product lines. But it will take some time for McAfee and even longer for Symantec to move the acquired products into the single agent/single console architecture they both tout for their endpoint anti-malware components. Both also have host-based vulnerability management (scanning, remediation, patching), but only McAfee has integrated vulnerability management with its ePO manager software. Both vendors will price vulnerability management, DLP, and encryption separately from anti-malware for the indefinite future.

The real benchmark is: What do the customers want? In my experience large enterprise customers are generally on a vendor diet, trying to get from tens of security vendors to lower numbers, but not to one.

I don’t see great urgency on customers’ part to subsume endpoint anti-malware into a larger endpoint protection suite. However, the vendor diet (consolidation) might lead some to choose the larger suite vendor over the niche vendor if the large vendor is equal or close to equal in price, performance, and functionality.

Smaller vendors such as Trend Micro, Kaspersky, Sophos or Panda Software that are chasing Symantec and McAfee market share in the anti-malware races, might have a fairly complete anti-malware suite but lack any or all of DLP, host encryption, and vulnerability management. But because Symantec and McAfee haven’t yet integrated anti-malware with all their other endpoint security functions (let alone merged the pricing), I don’t consider the lack of offerings beyond anti-malware a weakness for the smaller vendors. But it is something to keep an eye on, as the security suites have a way of expanding.

What Does It Mean to be a "Virtualization Security" Solution?

Blogger: Pete Lindstrom

It happens with every new technology and/or security fad (think wireless, handhelds, NAC, DLP) – people want to make their solution buzzworthy and so work hard to explain why they are in this “product category” that isn’t really a product category and have some unique characteristics that differentiate them from the crowd of others making the same claims at the same time (try being an analyst amidst these frenzied marketing messages ;-)). The latest buzzworthy term is virtualization security.

The first thing to recognize when evaluating your security vendors’ support for virtualization is that virtualization is designed to be transparent. That means that virtual machines (VMs) running traditional host operating systems are intended to look and feel just like physical OSes and therefore any security solution running on the host will almost certainly run on a corresponding VM (please let me know if you find an agent that doesn’t). You get this automatically. (Congratulations! ;-)).

From a network perspective VM transparency also applies, though network-based solutions must be able to run on OSes that have been ported to the virtual environment. Ironically, the network security solutions that were developed using proprietary hardware and software (typically to meet performance needs) are going to be much more difficult to port to a VM. Software-based solutions that operate on network traffic and security appliances that sit on Linux or FreeBSD, for example, should port over nicely as well.

The only reason any of this matters is to assess the speed for which you need a security solution and the availability of solutions that support that need. There is nothing wrong with having a solution that is virtualization-agnostic, but it is useful to know how unique the solution actually is if it is a differentiator in your evaluation process. In addition, in the near-term security solutions should be able to leverage the characteristics of virtualization for beneficial features such as patching a VM that is not in service or isolating a host agent from the host it is monitoring. That is essentially the VMsafe story.

As vendors pick up and elaborate on their virtualization messages, it may be helpful to have a set of questions to ask them in support of your evaluation. Here are some basic ones (Note: most of these are VMware-oriented since almost all security solutions are starting with VMware integration):

1. What virtualization platforms do you support? If they say “all of them” that is your first indicator that this is a strategy and not a solution.
2. Is your solution running on physical memory (i.e. at the hypervisor level) or is it using virtual memory (in its own VM)?
3. Did you have to rewrite code to integrate into the virtual environment? If so, what components required this? (This is a higher-level question that consumes a lot of the following questions).
4. Does your solution leverage the VMsafe API? On other platforms, does it have access to CPU, memory, network, and file system operations of the physical host?
5. Can your solution track VMs that leverage VMotion across physical hosts?
6. How does your solution identify a VM (e.g. by MAC or IP address, by VM ID, etc.)?
7. Can your solution integrate with Virtual Center or other management platform to take actions specific to VMs?
8. Are you managing configurations (patch/vuln mgt), encrypting communications, “inline” network security (NIPS or firewall), or providing some other security capability?

It is worth noting that there are other security solutions that leverage “virtualization” that sometimes mean something different – for example, many network security vendors are providing virtualization on their network devices to provide for more separation options. Also, there are companies like Phoenix Technologies’ HyperCore or Neocleus that will add virtualization capabilities that leverage hardware virtualization from Intel and AMD.