Security and Risk Management Strategies Blog

In the Eye of Malware’s Hurricane

Blogger: Dan Blum

In the eye of the hurricane, the helmsman rests; sun glitters through windswept clouds but the sea is deceptively calm as far as the eye can see. He shades his gaze from the glare and wonders from which point the storm will strike again…

Like the helmsman, security staff at a number of large companies we visited are wondering where the malware went. After years of battling spreading worms and viruses, the alarms are quiet, the infections relatively rare. What happened? Did firewalls, patch management and anti-virus tame the beast? Or has the nature of the beast changed?

A bit of both, we think. Countermeasures successfully block most self-propagating malware, especially (as we predicted) in large enterprise environments with locked down systems. And there are fewer propagating worms and viruses out there than there were in their heyday.

But malware isn’t going away, its just changing. McAfee told us the amount of samples they see has increased many fold over the last two years. According to the Internet Security Threat Report Volume XIII: April, 2008 Symantec saw 499,811 new malicious code threats in the second half of 2007, a 136% increase over the first half of the year. Symantec also measured over 61,000 active botnet machines per day, and Websense found thousands of legitimate websites infected with links to malicious sites.

There are a growing number of underground economy servers selling everything from financial information to increasingly sophisticated crimeware toolkits. Finjan predicts that in the future, the underground economy will mature to point where already-prevalent crimeware as a service (CaaS) style offerings will enable cybercriminals to tap straight into a data feed from victim machines belonging to an individual or organizational target of interest – no need to bother with much up front work. That’s a scary thought.

Its not just vendors hyping the stats to drum up business, we’ve heard many inklings of targeted malware from large enterprise customers (not that they like to talk about getting hit). Some of this showed up in my blog entry Financial Services Roundtable Promotes Information Sharing. I’ve also heard from an impeccable source that industrial espionage is rife in the aerospace and defense sector; DoD has told aerospace and defense companies the Chinese are eating their unclassified data lunch and hauled staff to Washington for meetings to consult on what new compliance requirements to put into future defense contracts. Information warfare isn’t science fiction anymore. We saw it in Serbia, we saw it in Iraq, and most recently there were denial of service attacks in Estonia.

When you’re in the eye of a hurricane, it’s hard to tell where the storm will hit next, but you know isn’t over. While financial services firms and defense/aerospace companies take the brunt of targeted attacks today, government is also under heavy attack and according to Symantec, yielded the lion’s share of identity data breaches in 2H 2007. ISPs get phished a lot, medical identity fraud is increasing, and any organization charged with safeguarding critical infrastructure is also under a cloud. No organization is immune to one of their employees randomly tripping across a malicious website and getting rooted, defrauded, and botted; possibly to its embarrassment, lawsuit, loss and potentially getting targeted for additional exploitation.

For organizations in some industries, the direct targeted attacks may not be a major concern, while the others I’ve identified that have a higher profile are more likely to attract the attention of disgruntled individuals or professional crackers looking for secrets or economic gain. Those organizations need to be wary and maintain high vigilance and counter-measures. Others can relax a bit more, but still need to run a tight ship and monitor the weather map, so to speak.

If you’re lucky enough to have calm skies, do as the wise mariner would: batten down the hatches, rest and feed the crew, then take out the charts. Make sure the basic stuff like anti-malware and patch management are working. Lock down the desktops, tighten up the security zones, track down and corral your critical data and then start thinking about additional architectural strategies to get ahead and stay ahead of the threat. We like inherent protections of the endpoint such as data execution protection (DEP), address space layout randomization (ASLR) and trusted platform modules (TPM) as well application whitelisting in addition to basic system hardening configuration measures. But that’s another post.

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.

Is PCI compliance creating a false sense of security?

Blogger: Randall Gamby

I was going to write a blog on small to medium businesses (SMBs) getting PCI compliant, but last week a breach changed all that.  Last Monday, Scarborough, Maine-based Hannaford Brothers Co., a regional Grocery Store chain the Northeast U.S. (and the store I shop at and pay using my debit card) had a breach that exposed up to 4.2 million credit and debit cardholders to potential fraud. 

The result of this breach so far has been about 1,800 instances of fraud as reported by company officials, all company information has been removed from their website (I’m assuming while they reevaluate their transaction strategy and architecture) except for a news brief from the CEO, http://www.hannaford.com/Contents/News_Events/News/News.shtml and the page containing their privacy statements, including their PCI compliance statement:

Hannaford Supermarkets has been certified as compliant with the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS is recognized as the accepted industry security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations protect customer credit and debit card account data.

So the question has to be asked, “Are we putting too much faith in PCI compliance to really reduce our risk of exposure?”  Apparently in the unfortunate case of Hannaford, whatever PCI compliance measures were taken to protect cardholder information weren’t enough to keep attackers from infiltrating the organization and stealing this valuable data.  Plus the question has to be asked, “What is a grocery store chain that mainly does Point-of-Sale (POS) transactions doing storing this information anyway?”  It’s not like cardholders have future payment options like they might have at Amazon.com--where their full credit card or debit card information is stored for checking out at a later date.  I guess believing that shopping at a PCI compliant merchant, over a merchant that isn’t PCI compliant, will reduce your chance of having your credit card data stolen isn’t always accurate.

Now I’m not saying PCI isn’t important, after all this breach may have never been found if PCI measures weren’t put in place, but enterprises have to look beyond the task of being compliance and take whatever additional steps may be needed to secure their data against breaches.   

In addition, on 22 January 2008, Visa released statistics on merchant compliance with PCI. Visa reported that as of the end of 2007, 77% of large merchants were PCI compliant (compared with 12% in March 2006) and that 62% of midsize merchants were compliant (compared with 15% at the end of 2006). These two merchant categories represent approximately two-thirds of Visa's transaction volume.  With other credit card issuers lagging, it seems that there’s still a lot of risk in using your credit/debit card out there in the big consumer marketplace.  So the warning of the week is to stay diligent in watching those credit and debit card statements and keep your guard up, whether the merchant has the PCI stamp of approval or not.  In the meantime, I’ll be getting a new debit card (my magnetic strip was wearing out anyway).

Trust, NAC, and the Art of Ceasing Operations

Blogger: Eric Maiwald

In the security world, we talk a lot about trust – the assured reliance on character, ability, or strength of someone or something (according to Webster). We place confidence in products, mechanisms, processes, companies, and people to act in a particular way. The trust that we have in something or someone directly affects how we view the risks associated with various activities.

Our trust may be based on any number of things – who the person is, their reputation, testing done on a product or mechanism, etc. In the network world, knowing who is coming on to the network seems to be an important consideration. The Security and Risk Management Strategies Service (SRMS) at Burton is working on a project to learn how the network fits into an overall enterprise security architecture. This project seeks to learn whether enterprises are currently using or planning to deploy an overlay style of architecture, and whether defenses are being shifted to the endpoints, application systems, information systems, and data centers. It will also challenge the messaging that vendors use to justify their NAC products and their strategy for building security intelligence into networks by tracking recent customer experience with NAC projects and gain an understanding of how network security architecture is evolving in enterprise customer networks. So far in our research, the idea of placing a control to limit the access of unknown people or clients to the network is appearing regularly. It appears that enterprises have a desire (and sometimes a need) to at least find out who is connecting to the network. Maybe that is the basis for identifying how far the enterprise will trust the individual or the client system and maybe that trust forms the basis for a perceived risk.

If there is a need to know who is coming on to my network, does that imply that NAC (network admission or access control) is important? (In a previous blog entry, I talked about the confusion in the NAC market and what NAC actually is) Well, at least identity seems to be important. Enterprises are using the identity of individuals and client systems to make decisions on entry to the network and access to resources once on the network. Other preliminary indications in our research show that the configuration and status of the client system are less important than whether the client system belongs to the enterprise or not and whether the individual is an employee or not. So maybe it is that some type of control over the network is important.

The failure of Lockdown Networks this past week is seen by some as an indication that NAC has failed. I think that goes too far. Our research indicates that some type of control over who enters or connects to the network is important to enterprises. However, trust has another part to play in the success of vendors who offer this type of control. Customers have to have confidence that the vendor can provide the product as advertised and that the vendor will do well enough to provide the necessary support for the product over the long haul. It seems that Lockdown did not inspire the necessary confidence in the market. Perhaps Lockdown offered a product that didn’t fit into what the enterprise customers were looking for or perhaps Lockdown’s financial future was sufficient secure for enterprise customers to take a change on a small vendor.

We will be finalizing our research and presenting the findings from our network architecture research at Catalyst North America in San Diego. Come join us there in June!

Financial Services Roundtable Promotes Information Sharing

Blogger: Dan Blum

Just as King Arthur’s knights gathered around their roundtable to try and divine the future intentions of invaders and other threats to the realm, financial services and other enterprise organizations have a critical need to share information about emerging cybercrime threats and attacks. So it was that one day this Fall in New York, I found myself at a private Wall Street roundtable meeting with leading thinkers from a number of large financial institutions (FIs).

Whereas the previous roundtable meeting I blogged about in the summer concerned general issues, the second meeting addressed predictive threat analysis. Attending were a number of Wall Street firms, National Cyber Forensics and Training Alliance’s (NCFTA), FBI and Burton Group.

The meeting started with a general introduction noting the evolution of the threat from script kiddies to organized crime to state sponsored industrial espionage or low grade information warfare activities. For example, the Russian Business Network (since gone underground, apparently) was a front for organized crime, a one stop shop allegedly tolerated by the Russian government as long it kept its attacks external. The speaker also noted that:

• China, France, Japan, Israel, Germany are similar in that they make no distinction between industrial espionage and national espionage. Some would argue the US is the same. Welcome to globalization!
• There has been good news and bad news for vulnerability management. iDefense says that OS vulnerabilities are generally down. On the other hand, there is now a thriving marketplace for vulnerabilities and the bad guys can find them.
• One thing hasn't changed - 85% of threats are still internal. One financial service had to surveil senior management after finding increased "rolodex activity" after executive departures. The company is working on ways to discourage or stop this behavior.
• Not all solutions are purely technical. With bad guys turning to pump and dump schemes against penny stocks, E*Trade lost $18M. But application developers at one bank were tapped to change the code on the web site so that customers have to call in low priced stocks trades, which are in any case a low revenue source for the company. This procedural solution was a decisive win against pump and dump schemes.

The NCFTA, a non-profit member-supported organization, described “Stock-Aid”, an information sharing service it provides for financial
services facing pump & dump attacks. Through NCFTA, the banks share feeds with the bad guys’ IP addresses and the names of stocks that are being attacked.

Could the industry do more than just block cyberattacks and perhaps shut down the botnets they’re coming from down? In the game of whack-a-mole NCFTA provides a hammer. And the FBI’s Botroast operation took down two large botnets. But new botnets keep emerging.

A more productive approach is to catch criminals by following the money: NCFTA noted that eGold gave over all their data, PayPal cooperates, and so do many other organizations that have been used for money laundering. Unfortunately criminals keep finding new places to hide in the money game; the latest ploy is to move money through online games like World of Warcraft.

The issue of information sharing is important to all industries, not just financial services. That’s why it’s so beneficial to participate in ISACA, BITS, I4 and other organizations. The warriors of information protection can either band together and share information like King Arthur’s knights, or risk falling into a dark age of cybercrime.

Policy-based Management Tools Unite!

Blogger: Randall Gamby

I’ve recently moved over to the SRMS Analyst team from Burton Group’s Consulting organization. Before moving over to the team I spent almost nine years in the field as a Burton Group Principal Consultant. Over these years I’ve worked one-on-one with many of our clients in both North America and Europe, and one of the topics that has always been an issue, and still is in many enterprises, is the process of implementing the enterprise’s policies in technology.

In the Identity Management (IdM) arena everything is moving to “roles-based” management controls. While roles-based controls are a subset of an enterprise’s policies and deal well with access rights for individuals and groups, in the security world “policies” are much more in-depth than just access. Not only do policies govern the actions of individuals, they also deal with data (whether in motion or at rest) and systems. But it seems that every security control system in the market is developing its own policy-based management interface. So the question is, “How many policy-based management interfaces do we need to configure?”

Historically, most enterprises have taken many years to create a relatively consolidated user identity repository (a vast majority of enterprises I’ve worked with use Microsoft’s Active Directory). However, as we move up the food chain to enforcement and compliance tools, products typically don’t--or can’t--read the LDAP user and group information. This forces the enterprise to go back to a siloed approach of creating and interpreting policies.

Think about it. I have a client that has firewalls being run by its Network Group, secure messaging run by a specialized IT group, host intrusion and prevention system (HIPS) being run by Security, and enterprise Active Directory deployment run by its directory team. Each product has policies about users, groups, and resources but barely recognizes the existence of the others; and each claims to have done policy “right.” Are they consistent? Maybe. Are they genuinely doing their best? Of course. Is there a risk to the organization that something has been overlooked? Very probably.

So what has to be done?

I think the first thing that needs to be done is for enterprises to review their policies. In the field many enterprise security managers (confidentially) have expressed a concern that the brave new world of security enforcement has invalidated, or provided scenarios that were never considered, in their original enterprise security policies. Next, I think vendors have to recognize that while policy-based management is a great ideal, it can’t be done in a vacuum. Managing policy enforcement for your set of tools that addresses only a part of an enterprise’s security front, without considering how you can share this with other sets of vendors’ tools working on other fronts, increases the chance of a hole in the defenses. Finally, I know you hear Burton Group say this all the time, but we need a standard to represent “policies” within a set of tools and a central repository--probably “virtual” if you ask the IdM people--that can store these values for the consumption and update of the tools. If a vendor can create a policy-based management interface that works across its suite of products (and some have), why can’t this framework be standardized for a similar group of tools, or even across all security enforcement technologies?

In the end, it will be the market that will determine whether policy-based management will be something that is a tool requirement or an enterprise requirement. If security managers aren’t educated on the “risk” in their current enforcement technologies; if vendors don’t hear from their clients that they’re tired of interpreting their new, and updated, policies for each of their policy-based enforcement technologies; and if standards can’t be created to make this all “consistent” within an enterprise, then efforts to go out and purchase expensive tools to manage their risk may be in vain.