At its simplest, out-of-scope means beyond jurisdiction; it means that whatever is being discussed no longer falls under the rules and requirements of PCI. One critical problem is that the brands and the PCI Council giveth and they can taketh away. In other words, if you’ve started sharing some, for example, tokenized data with marketing because a temporary out-of-scope ruling makes you comfortable doing so, you may find it almost impossible to undo should that ruling be reversed. Put more philosophically, you won’t likely be able to get the clear-text toothpaste back into the “they’re going to fine me from here to Shanghai, aren’t they?” tube.

The safest route is to somehow identify things that are declared temporarily out-of-scope from those that are permanently out-of-scope. But nothing would likely ever be declared temporary, so that’s rather useless advice. The only wise route is to simply assume that everything declared out-of-scope could later be declared back in-scope.

Standards change, and nothing changes faster than security standards. “We all thought WEP was cool until the data security standard changed,” said Walter Conway, a QSA with 403 Labs.

What’s just about as dangerous as being cavalier with data that may be only temporarily out-of-scope is reading too much into the vague comments coming from various card brands and the PCI Council. Statements have been made hinting that some technologies may be considered out-of-scope.

“If it’s potentially out of scope, I think you’re mad to consider it out-of-scope,” Conway said. “I think you’re juggling razor blades if you treat it as out-of-scope data for PCI purposes.”

Speaking of juggling razor blades, why would IT want to treat data differently if it’s out-of-scope? Just because PCI may not—for the moment—care about it doesn’t mean that various kinds of bad guys might not care quite a bit.

Let’s say you now share those PANs with someone in marketing. And they copy it onto a thumb drive or print it out and stick in a bag to take home.

If out-of-scope doesn’t mean it’s OK to shed security rules, what good is it? The only practical advantage is a cost savings on PCI assessments, to the extent that the newly out-of-scope data represents a material portion of the overall data you need protected.

Tokens are a common target for out-of-scope, but Conway argues that it could prove to be a reckless move. (Tokenization is fine, but assuming it’s out-of-scope could be reckless.) Why? Because anything that could be made unreadable can, in various ways, be made readable again. “Key management is only one way to make something that’s out-of-scope in-scope again. What if someone breaks into the secure vault and steals the key and then comes into your network?”

Another Conway scenario: “The IT staff just picked up a rumor that they’re being laid off and they call and say, ‘Give me these 100,000 tokens for testing.’ You have to ask yourself: My controls, how effective are they?”

Behind a lot of these concerns are real issues about whether the seemingly iron-clad protections that data-breach-victim retailers have had for years—most involving zero liability programs—is starting to fade, with federal judges pushing back.

Also muddying the waters are the claims of various security vendors that one approach—coincidentally, almost always theirs—will truly protect retailers, but all of the others won’t. The true decision-makers here—the card brands and the PCI Council—are waffling on these issues, fearful of weighing in on either side. That alone should tell retailers all they need to know about whether it’s safe to trust any out-of-scope declaration.

Out-of-scope declarations are a great concept, and if they happen and can be used to lower your assessment costs, that’s wonderful. But if you start treating data as out-of-scope, you may find that out-of-scope could drive you out-of-mind.

Evan Schuman is a guest blogger on the McAfee Security Insights blog. Evan is the founder and Editor-in-Chief of StorefrontBacktalk.com, a global site that tracks retail IT and E-Commerce issues for readers. He also writes the weekly Retail Realities column for CBSNews.com. More on Evan can be read on his author page.

Overworked IT executives suffering from staff cuts find checklist security quite comforting. The checklist mentality says that nothing should be done that isn’t mandated. And there are no external rules protecting data, beyond payment card, health-related information and some investment data. Is this wise?

This month, a frightening answer to that question came in the form of an E-mail exchange that a reader enjoyed. The reader—a security consultant—got a panicked call seeking a forensic expert. A large amount of important data had been stolen and they hadn’t been doing backups of that content. Even worse, they couldn’t even try and piece together what the intruders had stolen because of a logging problem. To quote the victim: “We can’t recover it, because it’s wasn’t backed up, and it wasn’t logging because it wasn’t on the part of the SAN where logging occurs.” Uh-oh.

Our reader said that he figured the data couldn’t have been close to mission-critical, given the cavalier way it was protected. But the victim had an interesting rationale: “Well, it wasn’t part of PCI so we didn’t think to add it into the normal data we monitor” with several different high-end security packages. The kicker: Why was the victim so desperate to retrieve this non-PCI-controlled data? “It’s the flight maintenance records for our entire fleet of aircraft.”

While this executive’s company’s safety details were off somewhere in the wild blue yonder atop CyberThiefVille, his counterparts were calmly deciding that security procedures should be minimalized.

If a thief wants to engage in identity theft, there are plenty of nuggets of data far more valuable than payment card information. Worried about an inside job? Wouldn’t the payroll database be a more tempting target?

Retailers today are amassing more data about Americans than anyone other than U.S. government. If retailers ever get their mouse pads around all of the data they’re already collecting, the image is staggering. For loyalty card using consumers, the chains know what they’ve bought and when. Courtesy of E-Commerce tracking, they know what they thought about buying, but chose not do. If stores truly deploy item-level RFID tracking, that knowledge will be known in-store, too. How would you like your next potential employer to be able to read a transcript of every question you’ve ever asked a customer service or tech support person?

That’s all data that’s being collected today. Some retailers are considering some even more Orwellian possibilities for next year

This all comes down to the fact that businesses of all sorts—and especially retailers—are collecting a lot of data today that no outside force is requiring them to protect in any formalized way. That means that companies must decide—on their own—to spend money and dedicate personnel to protect systems that they don’t technically have to. These execs will either do the right thing or face data Armageddon. Excuse me while I go out and buy a generator and a 30-year-old supply of survival supplies.

Evan Schuman is a guest blogger on the McAfee Security Insights blog. Evan is the founder and Editor-in-Chief of StorefrontBacktalk.com, a global site that tracks retail IT and E-Commerce issues for readers. He also writes the weekly Retail Realities column for CBSNews.com. More on Evan can be read on his author page.

The exact text of the FAQ is:

“The Council is looking for equivalent controls that address malware and all types of threats referenced in Requirement 5, which are often found in traditional anti-virus solutions. If another type of solution (application whitelisting, for example) addresses the identical threats with a different methodology than a signature-based approach, it may still be acceptable to meet the requirement.”

Some application whitelisting vendors are applauding the council’s statement and calling this a big step in the right direction and believe that this is a big win for the industry.

This is a step in the right direction, but a lot needs to change in order to get people to believe that compliance is a path to security. The PCI DSS 1.2 standard mandates the use of antivirus, which at the time the standard was released was cutting edge technology. Nothing better was available for security at that time.

Now the PCI Standards Council plans to add a new technology–Application Whitelisting–that can offer security on top of, or in lieu of, antivirus. However, the discussion is still about technologies.

Security standards like PCI should talk more about security requirements rather than technologies. For example, they should be writing requirements like the following:

1. Mandate use of technologies that protect against known and unknown malware attacks. (antivirus, HIPS and application whitelisting)
2. Mandate regular cleaning up systems that are infected with malware (antivirus scans)
3. Deploy technology that provides solution against vulnerabilities that can lead to memory based attacks (HIPS and patching solutions)

As long as the council keeps writing PCI DSS standards based on technologies available in the market, they will always be behind the curve and compliance will not mean security. They should consider moving to security requirements based view and leave the technology choice to customer and vendors.

This issue cropped up recently thanks to an interesting report on a well-respected site tracking data breaches. The report in Data Loss DB was trying to make sense of the fact that the number of data breaches they’ve been covering has dropped rather steadily all year.

Let’s drill down into these numbers a bit. First, Data Loss DB bases its reports on tracking media around the country. So if the number of stories slows down, that might have nothing to do with the breaches slowing down. Publications are cutting back and data breaches were new and sexy last year, much less so now. If media outlets are getting bored with data breaches, that could cause a sharp drop in the number of data breach stories.

And even if the media interest has not deflated, retailers (and banks and hospitals) are getting a lot better at keeping such information quiet, which would also reduce the number of stories. Lawyers are getting better at skirting disclosure laws, too. New federal efforts to tighten such laws will actually have the opposite effort, so this problem isn’t going to get better any time soon.

Layer atop that the fact that cyber thieves are pursuing large volumes of card numbers, which may result in more cards being taken but fewer individual breaches. Because Data Loss DB logs every breach as a single breach (whether 100 names were taken or 100 million names were taken), this will also cause a drop, albeit a meaningless one.

Speaking of cyber thief professionalism, a key reality-versus-perception issue is awareness. What if there were a lot more breaches but the victims—due to thieves covering their tracks better—were not aware of them? In many of the most recent breaches, a common theme is that retailers, despite millions of dollars worth of sophisticated security software and hardware, were almost universally unable to halt the attacks.

But much worse, their expensive security systems didn’t even alert them to the incidents as they happened and the systems rarely even flagged the incidents after they happened. Typically, it was a heads-up by Visa/MasterCard, processors or the U.S. Secret Service (”Sorry, ma’am, but it looks like you’re the common point of purchase with a huge number of bogus transactions we’re now seeing”) given to the retailer long after the bad guys have packed up their sniffers and moved on to another victim.

Therefore, because retailers can’t report breaches that they don’t yet know about, a drop in the number of reported breaches could truly mean very little.

All of those excuses aside, we can now get to the core issue. Are retailers better protected today? Have they learned their lesson and are they actually running more secure networks than before? The answer to that question, as narrowly phrased, is “Yes, absolutely.” But it’s more along the lines of “Retailers were two percent effective against data thieves before and today they’re nine percent effective.” They’re certainly more secure than they were, but they aren’t even close to being sufficiently secure.

There is some good news, though. Although the state of retail security is still quite shy of where it needs to be, two other players have made huge improvements: the card brands and federal law enforcement.

The fraud detection programs of Visa, in particular, have gotten impressively sophisticated. They are detecting likely fraud a lot more quickly and deactivating suspect cards almost immediately. That means that cyber thieves need to steal even larger number of cards to run a profitable business. How many cards that are stolen is a minor concern for the thieves compared with “How many will still be valid when I try and sell them on the black market tomorrow?”

At the same time, the feds are doing rather well at shutting down black market venues. Their extensive use of undercover agents (yeah, Gonzalez was an undercover agent. You had to bring that up?) has made even the most polished cyber thieves a little nervous about who to trust with stolen goods.

Bottom line: data breaches are still happening today, but we may see a drop a year or two down the road. But why the sharp drop in reported breaches in 2009? It’s like a well-done surprise party. Just because you don’t know about it doesn’t mean it’s not going to catch you offguard tomorrow.

Evan Schuman is a guest blogger on the McAfee Security Insights blog. Evan is the founder and Editor-in-Chief of StorefrontBacktalk.com, a global site that tracks retail IT and E-Commerce issues for readers. He also writes the weekly Retail Realities column for CBSNews.com. More on Evan can be read on his author page.

Before we delve into what you should do next—and the fact that you really need to get your teams together and figure it out now (think of it as Data Breach Disaster Recovery Plan)—let’s look at why this is such a difficult area. In the last couple of years, a veritable who’s who of major retailers have been breached, including TJX, Hannaford, 7-Eleven, Target, J.C. Penney, BJ’s Wholesale, Boston Market, Sports Authority, Dave & Buster’s, Office Max, Barnes & Noble, Forever 21 and DSW. And that’s merely a partial list of the ones we know about.

And in almost every one of those cases, the cyber thieves entered those networks, rummaged around, copies GBytes of payment data and related files, transferred that data to themselves and left—all without the retailers detecting any alarms. Invariably, it was the card brands—and sometimes the U.S. Secret Service—that detected the fraud days, weeks, months and sometimes years later and then circled back to give a heads up to the retailers involved.

That’s complicating factor Number One: You’re likely to learn of the breach long after it’s been halted by the thieves themselves. That tends to fuel the tendency to react slowly, as it doesn’t feel like an emergency. Trust me: It is.

Complicating factor Number Two: Data logs. As Wal-Mart learned a few years ago, those logs are the first things that professional cyber thieves will alter and manipulate once they break in. You simply can’t trust them if you know that cyber thieves have had hours of free reign within your network. That’s one of the reasons that real-time alerts (E-mail or otherwise)—stored in various locations far away from the enterprise servers (beyond the reach of the intruder)—are so attractive. Before the bad guy can cover his tracks, video of those tracks has already been sent to 40 different inboxes.

That said, today’s the day. You’ve just gotten the call from Visa that your systems are apparently the common point of purchase with a few million fraudulent transaction attempts. What are the first three things you need to do?

One: Identify The Nature Of The Breach
Although number two on this list is cutting off your networks from the intruder and others associated with the intruder, you can’t meaningfully do that until you at least reliably know the basics of the attack.

What if you choose to yank your system from the network—which is exactly what one breached Colorado liquor store did—and you later discover that the attacks were done physically on the card swipes and that network access limits wouldn’t stop them?

Or perhaps you choose to break off all external links, leaving intranet and VPN connections alive so operations can continue. And you later learn that it was an inside job done by two people in accounting and an IT programmer? Oops.

So as tempting as it is to make “cutting off the intruders” number one on this list, establishing the exact nature of the breach has to be Number One. (Actually, phoning a reporter for StorefrontBacktalk really should be Number One, so as to prevent this breach from impacting others. You’re a retail patriot, no?)

Two: Cutting Off The Bad Guys
You have learned of a major security hole. Even if you’re confident the perpetrators have been caught and made inactive, these thieves use discussions forums and share knowledge. You can wager generously that it’s known—at least in the cyber thief world—that you’ve been breached and how.

You’ve got to plug those holes before the next wave of silent attacks happen. Don’t forget that they are silent, leaving almost no easily discoverable tracks. They may be copying files as you sit in a meeting debating options.

But you actually have a sub-priority that should trump your key priority: Maintain operations and maintain them seamlessly. Whatever you do, it can’t meaningfully impact customers. You can’t simply stop accepting online coupons or processing CRM points if you used to.

There are an infinite number of ways of cutting off access to the bad guys, but they generally fall into two equally-viable categories: Go Back; and Move Forward.

The Go Back strategy suggests cutting off access as much as possible to cut your losses and halt damage. It has some severe drawbacks, both in terms of functionality and security (no encryption), but it’s also likely to avoid further breaches for a bit. After all, it’s hardly cost-effective to steal one card at a time by tapping phone lines.

The Move Forward approach is also known as the “Panicky IT Executive Throwing Money At The Problem.” To be fair, many of the “move forward” options will have to be seriously considered for Step Three, which is returning the network to the new normal. But it’s not an especially great idea at this stage because the immediacy required prevents the kind of due diligence this merits. Still, adding software to plug limited holes or to generally boost protection is something to consider at this phase.The Zero Liability programs from the major card brands do a wonderful job of limiting direct financial losses from your customers. But if, in an attempt to make your systems temporarily breach-proof, you start losing customer-facing functionality, you have the real potential of alienating—and losing—key customers. If that happens, candor—in the form of “Well, we’ve been breached and we think this Eastern European cyber thief gang has your credit card info”—is not likely to help you, unless you define “help” as stopping customers from walking away and instead getting them to run away.

Three: Activating The New Normal
Once you’ve figured out exactly what the attackers did—to your satisfaction at least—and prevented anyone from doing those particular techniques to you again, you need to return to the living and get your operation to move into the next security phase.

But given the RFPs that need to be created and circulated plus the competing bids and then the questions and trials and trail evaluations and then limited deployments, you could easily have to live a year or two with your “immediate” approach. Don’t rush the new normal as that will be your key safeguard for quite some time.

If the size of your chain means that you may have to live longer without the new normal, that would certainly suggest that the Move Forward approach in Number Two might be a good way to go for you.

Breaches are becoming a fact of life in retail IT today and there’s no way to prevent them. But with some prep right, you can at least make the post-breach nightmare a little less horrific.

Evan Schuman is a guest blogger on the McAfee Security Insights blog. Evan is the founder and Editor-in-Chief of StorefrontBacktalk.com, a global site that tracks retail IT and E-Commerce issues for readers. He also writes the weekly Retail Realities column for CBSNews.com. More on Evan can be read on his author page.

For example, I was talking the other day with a CIO for a Fortune 500 retail chain and he was talking about mobile commerce and mobile payment—two very different things—not merely as sales and marketing tools, but as a way to potentially save a ton of money on interchange fees paid to the various card brands.

Retailers have for years screamed about what they see as exorbitant and potentially monopolistic payment card charges. Through rose-colored POS screens, they hope that something as radically different as mobile commerce would give them the means to escape, or at least seriously reduce, those fees. This particular CIO saw this 3-5 years out, which is when he hoped that most cell phones would ship with embedded encrypted payment chips.

The out? Such devices could potentially access consumer bank accounts directly, not unlike a debit card, sidestepping the Visas of the world. It’s an compelling idea, but there are several reasons why it would likely never work for a major retail chain. First, the risk to a consumer is lightyears more intense when withdrawals are automatically taken from bank accounts.

Why? Let’s say a cyberthief is able to obtain enough details to make fraudulent credit charges. We can even make it a less sinister scenario and say that it was simply a human error or an innocuous software glitch that caused the wrong charges to go through. Either way, the most likely scenario is that the consumer will detect it when the bill either arrives in the mail or is reviewed online. A call is made to the bank and a temporary credit is issued. Most likely, the matter will be resolved before the consumer has to pay any money and the consumer inconvenience is relatively minimal.

Contrast that with the same thing happening to that consumer’s bank account. Dozens of checks may immediately bounce. Services are disconnected and perhaps even police are brought in (writing bad checks is illegal). That consumer may be unable to pay critical bills and not even be able to access cash from an ATM. Yes, it’s true the bank will eventually make good on the removed money, but that can take weeks and potentially months. With a payment card, a temporary credit makes such a delay quite tolerable. Not so with a debit transaction.

We then have the resulting domino effect and the retailer’s loss of something called a Zero Liability program. In the major data breaches of recent years, most prominently TJX and Hannaford, the retailers practically skated with no lasting damage. Consumers did not abandon the retailers at all. Not even a little, not even in the beginning. That meant that revenue (and therefore profits) were not impacted, which meant that Wall Street gave the retailers a pass.

A variety of class-action lawsuits ensued and, one by one, court ruling after court ruling, the retailers emerged relatively victorious. Why? Because without the consumers suffering serious financial pain, the civil lawsuits couldn’t go anywhere.

But had those retail breaches hit millions of bank accounts the way they hit millions of credit cards, the story would be radically different. Hurt consumers would have abandoned those chains immediately—as would tons of others. It’s not hard to extrapolate a devastating financial potential.

So do retailers really want to give up the zero liability protections so easily? And they’d be doing it all to get rid of interchange fees. What makes those chains so certain that telecom carriers and handset makers won’t be demanding just as onerous—if not more exorbitant—fees of their own? Are retailers really so willing to jettison Visa, MasterCard and American Express for the kind-hearted humanitarians at AT&T, Sprint and T-Mobile? Which is likely to be more black-hearted (it’s probably a draw, but that’s the point)?

There are other choices, too. Do you want consumers to have to type in their payment data with each transaction? Presumably no, so that raises the issue of storing it on the phone—creating potential disaster if the phone is stolen, even with password protection—storing it on the retailer’s servers (raising PCI and other liability concerns) or storing it on a third-party service’s servers, which would force the razor-thin retails margins to be cut yet further.

No matter how you look at it, as we move deeper into the mobile security world, the questions and difficult decisions will become more numerous. But we can take a dialpad of solace from the fact that retailers are at least starting to think about these issues.

Evan Schuman is a guest blogger on the McAfee Security Insights blog. Evan is the founder and Editor-in-Chief of StorefrontBacktalk.com, a global site that tracks retail IT and E-Commerce issues for readers. He also writes the weekly Retail Realities column for CBSNews.com. More on Evan can be read on his author page.

It’s about making a choice, often couched in an ROI phrasing. Security can never make any money, boost profit margins or do anything affirmatively good for senior management. It’s all risk avoidance and there’s nothing more quintessentially thankless than that. If you do your job perfectly and keep all corporate secure, someone in a board meeting will invariably ask, “Why are we spending so many millions of dollars on security? We haven’t had any kind of a breach in 20 years.”

IT executives involved in security projects today are facing some especially fascinating choices. Tokenization and so-called end-to-end encryption are good examples. Of, real end-to-end encryption—where a card is encrypted as soon as it’s created and it stays encrypted when sent to consumer and when brought to the retailer, only being unencrypted at the processor and potentially even at the card brand itself—isn’t being seriously proposed by anyone today, leaving us with a dozen proposals for variants of middle-to-middle encryption. When most vendors speak of end-to-end protection, it’s not the retailer’s end that is being protected.

That all said, some form of middle-to-middle encryption—coupled with some version of tokens, encrypted with a public key—is almost certainly to be adopted widely. So what’s the big decision? It’s a simple matter of where those data tokens should live. Under the rationale of limiting (and, in theory, eliminating) risk, some vendors are arguing that the tokens need to be stored out of the control of the retailer—presumably with a third-party—so that the merchant can honestly say that he’s neither holding the tokens nor even has control of them. No breach of that retailer’s chain could ever possibly get those tokens because they’re simply not there, the argument continues, adding that the tokens—unlike encrypted payment card data—are worthless to a cyberthief anyway.

Indeed, those merchants argue, the token is so worthless that it’s beyond the scope of PCI requirements. Hence, the retailer should have dramatically fewer PCI obligations. That’s one school of thought.

The other school of thought—the alternative token philosophy, if you will—is a more cynical one. It argues that if there’s ever a breach of that third-party’s servers and the original payment details are so accessed, the retailer will still be held liable, both by their customers, by the PCI and card trend authorities (or, as some retailers call them, the Payment Gestapo) and certainly by judges overseeing the invariable class-action lawsuits to follow.

That cynical argument is that if a consumer walks into, for example, a Home Depot and gives a Home Depot employee their credit card—or even swipes into themselves into a Home Depot owned card swipe device—that consumer can and should hold Home Depot responsible if that card data later gets accessed. From the lawyer’s perspective, Home Depot is the deep pocket. This is especially true because Home Depot hired that third-party security firm so it absolutely is responsible for its actions. Also, this argument says, the tokens may not be so worthless, after all. Those tokens can—by the third-party—be converted at whim back to the original card data, for chargeback and other purposes. That fact casts doubt, they say, on whether tokens would truly be considered out of PCI scope.

Furthermore, what if that third-party firm goes bankrupt, gets bought or otherwise shuts down? No, the cynical argument continues, if the data is given to that retailer, it must maintain the data on its own servers, managed by its people. If it’s going to eventually be held responsible, it might as well maintain control. Those vendors sell those retailers kits to create—and manage—their own tokens.

Both arguments have merit and both play to the fears of retailers. But it’s another reminder that, in security, making a strategic decision only forces yet more decisions. There’s always a question as to whether more security is necessarily stronger protection. But when retailers today have to also choose a security philosophy, well, that’s where things get interesting.

Evan Schuman is a guest blogger on the McAfee Security Insights blog. Evan is the founder and Editor-in-Chief of StorefrontBacktalk.com, a global site that tracks retail IT and E-Commerce issues for readers. He also writes the weekly Retail Realities column for CBSNews.com. More on Evan can be read on his author page.

Organizations Are Suffering from Audit Fatigue

Of the many compliance obstacles facing organizations, the sheer volume of audits is perhaps the most oppressive impediment to returning to “business as usual.” With more than 400 separate sets of requirements facing organizations internationally, global institutions can face more than 40 diverse mandates. Failure or non-compliance is not an option, as reputational damage and severe consequences levied by regulatory agencies can have severe financial consequences for businesses.
 In a McAfee-sponsored survey, one organization estimated that to prepare for their PCI audit, they spent 1,000 hours in one week to configure audit settings. Another organization spent more than 18,000 hours to prepare for external audits in one year. Even when faced with such overwhelming compliance demands, more than 51 percent of organizations surveyed still used spreadsheets to execute audits.

Three Steps to a Better Audit

Organizations that embrace IT as the path to solving compliance issues should follow three key steps to combat audit fatigue:

1. Establish a governance committee: By connecting executives with operational realities, a governance committee can help focus compliance spending where it will be utilized to its fullest.
2. Automate the IT audit process: By investing in risk evaluation and auditing technology, companies can automate the vast majority of once-manual and time-consuming tasks, better ensuring ongoing compliance and reserving IT energy and spending for strategic priorities.
3. Adopt a well-built framework: By adhering to a consistent framework throughout an organization, IT can consolidate the number of separate audits it must conduct.

SCAP Leads the Way in Next-Generation Audit Standards

The emergence of Security Content Automation Protocol (SCAP) signals a change in traditional risk and compliance architecture. Using SCAP-compliant products, companies can now eliminate the need for vendors to issue updates when new policy or regulatory mandates are decreed. By immediately integrating new changes in policy, SCAP improves vulnerability detection, asset management, risk monitoring and response, threat publishing, and more. As more technologies are produced to support the continuing evolution of audit demands and evolving infrastructures, the more automated the audit process will become.

To learn more about McAfee’s insights into the status of risk and compliance technologies, read the newest edition of the McAfee Security Journal.

McAfee’s Application Control, Change Control, Change Reconciliation, Integrity Monitor, and PCI Pro will be added to our current line-up of risk and compliance offerings and system security offerings. The integration of Solidcore with McAfee provides customers with the highest level of system integrity and security across their physical and virtual environments, and allows customers to quickly and easily meet compliance requirements, like PCI. This is especially true for our retail customers struggling with how to protect their Point of Sale (POS) systems.

In addition, Solidcore’s portfolio adds the “enforcement” arm to McAfee’s current suite of risk and compliance offerings. Dynamic application whitelisting, coupled with our own Artemis in the cloud technology, will enable McAfee to move even further ahead of our competitors in protecting customers. The end result will be improved IT compliance, security and availability.

I have been traveling around the world the last two months, and the reception to this technology has been overwhelming. One bank I met with was keenly interested in protecting their ATMs and could not have DAT files pushed to each ATM because they had a whopping 8K of bandwidth. Yes – you read that correctly – 8K! Our Solidcore technology was a perfect fit for this application as well as many others – especially in a fixed function and constrained environment.

In my opinion, the industry had one “hammer” in their proverbial tool belt called AV, and everything looked like a nail. Now, McAfee has multiple compelling solutions that offer an amazing array of protection and integrity monitoring capabilities integrated into ePO. I would encourage anyone looking at application whitelisting technologies to learn more about this exciting technology by visiting our Web site at http://www.mcafee.com/us/enterprise/products/risk_and_compliance/application_control.html.

This year’s theme at the Gartner Risk and Compliance Summit centered on directions and tools to help organizations maximize their Governance, Risk and Compliance programs. No doubt, a reflection of the current economic climate.

Especially interesting was that few vendors really had anything innovative or different to offer compared to last year. Some were niche vendors who solve one piece of the puzzle but are trying to expand their offerings while others were broader GRC vendors that had matured their offerings.

What was clearly apparent is that customers are more then ever bent on consolidating vendors. The idea that you could have one platform to manage both security and compliance and with separation of duties built in, has gained momentum. And, controls automation, while a well-worn topic is also something that customers are becoming much more serious about as part of reducing the cost of audits.

McAfee co-presented a session with Tyco International on leveraging a risk-based approach to sustain compliance efforts, which resonated very well with attendees. Taking a risk-based approach could have helped mitigate some of the most publicized recent data breaches. Through regular automated audits and vulnerability scans and applying countermeasures to reduce residual risk, organizations can focus on assets most at risk – we call this the 80-20 rule.

Tyco International talked about their efforts to streamline compliance and how they have adopted this risk-based approach. They eliminated multiple disparate tools through using one integrated solution and a highlight for many attendees, they expect to reduce the number of hours they spend on external audits from thousands to days.