This model was adequate in the past, but it is no longer good enough. Why? Malware volume stresses the system and all too common zero-day attacks have free and clear access to sitting duck systems.

Coping with the new threat landscape means embracing a new security model. First, we have to assume that an unknown file, URL, or IP address is malicious. That said, we can’t simply deny access; rather, we need to analyze the suspicious content in real-time and then make the appropriate access decision (i.e., allow access, deny access, quarantine, send content to a honeypot, etc.).

This new model depends upon a community of users and security devices/software acting as a neighborhood watch and sharing information with security vendors in real-time. Some people call this a “hybrid cloud” model to capitalize on the buzz around cloud computing.

Hybrid clouds are fine for now, but I foresee a future evolution to a peer-to-peer security model. With hybrid clouds, security devices/software still engage in a conversation with only one entity: the security vendor’s cloud infrastructure. In peer-to-peer security, security devices/software will engage in conversations with other security devices/software from multiple entities:  security vendors, ISACs, government sources, academic institutions, etc. These conversations will issue warnings, blacklist threats, analyze content, compare notes, exchange data, etc.

Several vendors–including Blue Coat, Cisco, and Trend Micro–already have hybrid cloud offerings that could serve as the foundation for my peer-to-peer model. A bit of vendor cooperation, government incentives, or user demand could lead to further developments in APIs, secure protocols, data standards, etc.

Cybercriminals constantly exploit our security weaknesses and lack of coordination. This has been a winning formula thus far to the tune of billions of dollars in identity theft and data breaches. To overcome these tactics, we need to use our technology assets more effectively. This is precisely what peer-to-peer security can do.

The Network Effect (or Metcalf’s Law) states that the value of a network is proportional to the number of connections. In my opinion, peer-to-peer security leverages the power of the Network Effect for the good guys.

Dell is doing the right thing by alerting potentially impacted customers, but questions remain:

1. How did the malware get there?
2. Were the motherboards assembled in a certain place or by a specific manufacturer?
3. What processes does Dell (and other server vendors) have in place to ensure that this doesn’t happen?

I could go on and on.

To me, the Dell incident demonstrates an important but relatively unknown concept called cyber supply chain assurance. Servers, software, and other IT equipment are made up of millions of lines of code, a potpourri of components, and hundreds or even thousands of specialized electronic gear. If any one of these elements is compromised, the whole enchilada could be a ticking time bomb. Malware on a server motherboard is just the beginning.

A bit of a tangent: back in 2004, the U.S. federal government issued a report stating that only 21% of semiconductor manufacturing remained in the United States while the bulk of capacity was migrating to China. This caused great concern in the Department of Defense as most our weapons systems, communications, and logistics all depend upon IT. This led to the creation of the Trusted Foundry program, a DOD/industry initiative to ensure microprocessor domestic microprocessor design and manufacturing capabilities.

I bring up this example to illustrate a point. DOD realized that it was dependent upon technology and thus vulnerable to a breach of the cyber supply chain. Outside of the defense community, however, cyber supply chain risk management is nearly invisible. While the Dell incident is minor and seems contained, it is a further warning about the risk we all face. Let’s hope it wakes up some security professionals outside of the Pentagon.

There are two primary knocks against CAG. First, many believe that it is completely redundant thanks to other security requirements and IT frameworks like ITIL and COBIT. Second, CAG is viewed as incomplete. The thought here is that stealthy or innovative security attacks could circumvent the 20 controls.

In my opinion, each of these criticisms is accurate. That said, I think these points are non-issues. Yes, CAG is redundant with other security and IT efforts, but most large organizations already face redundancy issues as they are forced to comply with HIPAA, SOX, PCI DSS, FISMA, etc. Sure, CAG has gaps–no one ever claimed it was exhaustive.

CAG ain’t perfect, but it does have several key strengths:

1. CAG has focus. I see organizations get overwhelmed by the scope of information security policies and controls all the time. CAG takes away this “boil the ocean” mentality and concentrates on the highest risks. This makes it easier to implement–and afford–than other security models.
2. CAG is based upon real-time data analysis. As the old saying goes, you can’t manage what you can’t measure. CAG takes this expression to heart as the 20 controls are anchored by data collection, measurement, and validation–in real time.

In the future, it is likely that the list of CAG controls will grow to accommodate new threats thus keeping CAG up to date. CAG may not be as comprehensive as other security models and it is certainly no panacea, but given its focus, it is a great way for overwhelmed CISOs to rationalize their security efforts and concentrate on high priority risks.

Bad news: Getting this far took far too long. While diplomats debated over wording and process, the state of cybersecurity severely degraded.

It seems that politicians and diplomats are long on protocol and thus missing the forest through the trees. Cybersecurity isn’t like physical border disputes or long-term efforts. Rather, threats morph and grow more dangerous every day. In the meantime, there are no international rules of engagement or agreements for cooperation — and no one nation can solve this problem alone.

What we need here is not long drawn out negotiations and formal agreements but a series of cooperative phases with measurable progress at each milestone.

The U.N. has a chance to really make a difference with cybersecurity. Let’s hope that diplomats realize that we are dealing with a real-time issue and respond with 21st century solutions rather than 19th century pomp and circumstance.

So what’s needed? The next generation of log management featuring:

1. Consolidation of logs and network flows. Some vendors collect both of these data sources but most don’t. Log and flow data together tells about individual network nodes and where they are connecting, helping me understand the origins and ramifications of an attack. Without this combination, I am filling in the blanks in one area or the other.
2. Location awareness. Yes, I want to know what happened but I also want to know where it happened. An IP address is a piece of random evidence while an IP address in the Ukraine may constitute a crime scene.
3. Deeper granular visibility. The system logs provide the big picture but researchers need to dig into particular sub-routines and processes to get a more accurate understanding of what happened. This requires the correlation of many types of data inputs and visual tools that make these relationships understandable.

Leading log management vendors like ArcSight, LogRhythm, Q1 Labs, and others realize that log management isn’t just about collecting and storing esoteric IT data, it is about providing organizations with the right data and tools to make this data actionable.

It’s time for users and other vendors to realize that the next generation of log management isn’t a visionary concept, it is an absolute requirement.

1. Has the state of cybersecurity improved over the last 12 months?
   55% of the audience responded “no”
   45% responded “yes”
2. Which of the following represents the biggest cybersecurity threat?
   40% responded “hostile foreign nations”
   39% responded “lack of federal security standards”
   21% responded “organized crime”
3. Who has the most impact on cybersecurity?
   38% responded “industry”
   26% responded “DHS/DOD”
   21% responded “the white house”
   15% responded “congress”

My take is as follows: Cybersecurity is worse than it was 12 years ago — there are more threats and the threats have become more sophisticated. The nation has been effectively treading water in that time frame so the gap continues to grow. President Obama’s focus on cybersecurity and his appointment of Howard Schmidt were positive moves but not enough.

I agree that hostile foreign nations represent the biggest potential threat but on a day-to-day basis, organized crime is picking our pockets. To some extent, this response concerns me because it casts security into a military category. It is also interesting that 39% said “lack of federal security standards.” These people were either looking myopically at the Federal space alone, or believe that the Feds haven’t stepped up with cybersecurity leadership. The former answer reflects insular Washington, the latter is absolutely true.

As for the final question, I couldn’t agree more. If 80% of the critical infrastructure is in the private sector as the President suggests, then industry must be a major part of the solution. This “public/private” partnership has also been lagging.

In total, these answers tell me that things are getting worse and we aren’t doing enough. Pretty scary stuff.

On the plus side, the feds have a lot of good work going. There is a lot of government brainpower focused on scoping problems, evaluating funding priorities, changing cultural barriers, and defining security solutions. Kudos are well deserved.

With all of this effort, however, it is time to discuss a fundamental problem between the public and private sector: communications. The feds have a language all of their own, one chock full of agency-specific acronyms and a military flavor. Information security is called “cybersecurity” and there are lots of references to missions, objectives, command-and-control, etc. The word “assurance” is used constantly: software assurance, information assurance, cyber supply chain assurance, and so on. This is just the tip of the federal language iceberg.

In his famous May 2009 cybersecurity speech, the President proclaimed that:

1. Cybersecurity would be a top priority in his administration.
2. 80% of the critical infrastructure is controlled by the private sector.
3. We needed a stronger public/private partnership.

For these things to happen, the federal government must realize that it needs to drop the inside-the-Beltway lingo and speak to the rest of us in common language. We don’t care which agency owns which initiative with acronym ABC. We don’t speak to each other about missions and battlefields and assurance. Many experienced IT and security professionals have no idea what NIST is or what it is doing. Like it, understand it or not, this is the truth.

The information security challenges we face are real and could be extremely damaging to the country, the economy, our way of life, and confidence in the government. We NEED the feds to step up, but we shouldn’t have to learn a new language or culture to make this happen. I already see the influence of this communications gap as most of the private sector has no clue about all the work going on in Washington–this is wasteful and a shame.

In his new book, Cyberwar, Richard Clarke does a great job of translating Washingtonese to common language. Good effort by Clarke, but the fact that he had to do this should be a red flag for all of us. If we can’t understand each other, we are doomed from the start.

To that end, Senator Joseph Lieberman (I, CT) is working with colleagues Susan Collins (R, ME) and Thomas Carper (D, DE) on a fairly comprehensive cyberseurity bill called the Protecting Cyberspace as a National Asset Act. The bill seeks to revamp the paper-centric FISMA Act of 2002, centralize cybersecurity management in DHS, and establish a more proactive public/private partnership for cybersecurity risk management.

The essence of the bill is certainly welcome. We need to address cybersecurity issues ASAP like President Obama promised he would do more than a year ago. Unfortunately, the Lieberman bill has a few significant flaws, in my opinion. One major problem is with the bill’s link to federal procurement. The Lieberman bill seeks to legislate security in federal IT spending by “creating a system that requires acquisition officers in the federal government to have the knowledge that they need about the vulnerabilities in products.” This in itself is a good idea but:

1. How do you do this? There is some talk in Washington about insisting that vendors pass some type of security certification that governs their development processes and cyber supply chain assurance model. Okay, but this certification doesn’t exist today and certification can be nothing more than a check box exercise like FISMA is. In the current state of the industry, this requirement is ludicrous.
2. Product vulnerabilities are one ingredient. The Lieberman bill’s focus on product vulnerabilities hearkens back to cybersecurity issues circa 2004 when it was fashionable to blame Microsoft for all security problems. Yes, these remain important but we need to think about system vulnerabilities (i.e., a superset of product vulnerabilities), comprehensive testing, and a lot more security training.

I don’t claim to be an expert on the Lieberman bill but it seems to me that we are falling into the old Washington scapegoat mentality of looking for a villain (i.e., the IT industry). Don’t get me wrong, lots of vendors should be called to task for unacceptable security practices but these provisions seem overly simple or impossible to enforce to me.

While the Feds figure out the next act in the cybersecurity play, it is really up to the IT industry to step up and establish its own security best practices and self-certification methodology. Strong examples already exist from vendors like EMC, HP, IBM, and Oracle. While some folks will certainly flame me for saying so, Microsoft’s SDL is also a model for the rest of the industry.

Legislators are caught between a rock and a hard place. They have to do something but these are uncharted and highly technical waters. This being the case, the IT industry has to do a better job of stepping in and demonstrating leadership. If this doesn’t happen, the U.S. IT industry will face difficult, costly, and confusing legislation that could impact financial results for years to come.

Moving forward, Cisco’s endpoint security efforts will center upon AnyConnect, an agent-based offering that unfies endpoint connectivity, TrustSec, DLP, threat defenses, and policy management. As far as pure AV protection, Cisco will recommend partner with vendors like Sophos and Trend Micro.

What’s going on here? Is Cisco walking away from an entire product and market? No. In fact, ESG believes this decision demonstrated guts and vision. Cisco has never had any luck with Windows client software and that’s really what CSA is. Cisco may be saying adios to Windows but this move is right down Broadway as it aligns with Cisco’s strengths and market direction. Why? Because:

1. Windows PCs are no longer the point. We all have PCs, smart phones, Macs, etc., and this list will only grow over time. I want to secure my stuff, not my Windows PC. How can you amalgamate this task? Through the network, of course. This is exactly what Cisco wants to do.
2. Think cloud. Yes, the cloud will provide us all with infrastructure, applications, and services, but it can also be a big honking proxy service. As we virtualize our workloads, this has to happen. Cisco gets this and is already offering cloud-based security services via IronPort and Scansafe. This is the future, not CSA.
3. The definition of endpoint security has grown. When Cisco acquired Okena, endpoint security was really about malware protection. Now endpoint security extends to identity, access controls, usage policies, and data assurance. Again, most of these other functions can be managed via the network.

Cisco has a fair number of CSA customers so I’m sure some folks within the company wanted to continue to invest in the product. This would have been the easy “let’s not rock the boat” decision.

Yes, this would have been the easy path but it also would have been the wrong decision. Cisco can now focus on endpoint security from a position of network/cloud strength rather than its Windows PC weakness.

The market is already headed in this direction. Cisco is simply shedding some legacy baggage and positioning the company at the nexus of endpoint, network, and cloud security. This is the absolute right decision.

So how much does a data breach cost an organization? Good question, as there are a lot of moving parts. You have to notify the users via regular mail, pay penalties and legal fees, cover customers with credit protection, develop and execute a PR “crisis mode” initiative, etc.

Obviously, this can run into some real dough, but exactly how much are we talking? Based on many, many anecdotal conversations, ESG continues to estimate a cost of between $30 to $150 per record. Why the range? The majority of breaches are small and local, in the hundreds of lost records. When your local hospital is breached, the clean-up costs are a lot less than when it happens to Citigroup.

We’ve also seen a pattern of costs actually going down. Why? Unfortunately, data breaches are an all-too frequent event. Large organizations and outside experts have gained experience and are more efficient now than they were a few years ago.

In my opinion, a range of $30 to $150 is about as close as it gets, but some companies try to get a bit more precise. In doing some recent research, I came across a report from the Ponemon Institute which claimed that the cost of a breach was actually $204 in 2009, up from $202 in 2008 and $197 in 2007.

This data was gathered through in-depth interviews with 45 organizations that had experienced a data breach. A press release declared that the “cost rose to $204 per compromised record in 2009.”

Now I hear that this research project is pretty thorough, but I have a few problems with this data and hyperbole:

1. The Ponemon data is based on organizations that experienced data breaches where 5,000 to 101,000 records were compromised. The number of organizations that fit this profile is a fraction of the number of breaches where dozens or hundreds of records are compromised. As I indicated, the cost per record here tends to be much less, so we can’t really judge the real cost of a data breach without considering this much larger population.
2. With a sample size of 45, the margin of error is over 14% in the Ponemon study. This means that there is no statistical difference between $204 (2009), $202 (2008), and $197 (2007) (Note: Even the $182 in 2006 is in the same ballpark). To paraphrase former President George H. W. Bush, declaring that the “cost rose to $204 per compromised record in 2009,” amounts to voodoo research.

Data breaches are a big and, yes, a costly problem, but I contend that it is nearly impossible to measure the real true cost of a breach. Ponemon deserves credit for trying, but we need to be careful about generalizing or hyping the results of small restricted research efforts that focus on a subset of the population. After all, security professionals are paid to assess risk and recommend solutions, not offer Chicken Little scenarios with hat in hand.