I have to admit, I don’t really understand greedy desperation. Or desperate greed. For example, although I enjoy having a decent income, I don’t obsess about the big score. Someday I’d like a moderate score for a little extra financial security, but I’m not about to compromise my lifestyle or values to get it. As a business I know who my customers are and I make every effort to provide them with as much value as possible.

That’s why I don’t grok this whole GRC obsession (Governance, Risk, and Compliance) among certain sectors in the vendor community. It reeks of unnecessary desperation like the happily married drunk at the bar seething at all the fun of the singles partying around him. He’s got it good, but that’s not enough.

One of the first things I covered over at Gartner was risk management, and I even started the internal risk research community. This was before SOX, and once that hit a few of us started adding in compliance coverage. Early on I started covering the predecessors to today’s GRC tools, and was even quoted in Fortune magazine saying there was almost no market for this stuff (some were predicting it would be billions). That, needless to say, pissed off a few vendors. Most of which are out of business or on life support.

Gunnar Peterson seems to feel the same. He sees GRC as letting your company become audit-driven, rather than business-driven. He is, needless to say, not betting his career on GRC.

Now I’m about to rant on GRC, but please don’t mistake this as criticism of governance, risk management, or compliance. All are important, and tightly related, but they are tools to achieve our business goals, not goals in and of themselves.

GRC however is a beast unto itself. GRC is now code for “selling stuff to the C-level”. It has little to do with real governance, risk, and compliance; and everything to do with selling under-performing products at inflated prices. When a vendor says “GRC” they are saying, “here’s our product to finally get us into the Board Room and the CEO’s office”. The problem is, there isn’t a market for GRC. Let’s look at the potential buyers:

1. C-Level Executives (the CEO and CFO)
2. Auditors (internal)
3. Auditors (external)
4. Business unit managers (including the CSO/security).

Before going any further let’s just knock off external auditors, since they aren’t about to spend on anything except their own internal tools, which GRC doesn’t target.

Now let’s talk about what GRC tools do. There is no consistent definition, but current tools evolved from the SOX compliance reporting tools that appeared when Sarbanes-Oxley hit. These tools evolved from a few places, but primarily a mix of risk documentation and document management. They then sprinkled in controls libraries licensed from the Final Four accounting firms. I was never enamored by these tools, since they did little more than help you document processes. That’s fine if you charge reasonable prices, but many of these things were overinflated, detached from operational realities unless you dedicated staff to them, and often just repurposed products which failed at their primary goal. Most of the tools now are focused on providing executives with a “dashboard” of risk and compliance. They can document controls, sometimes take live feeds from other applications, “soft-test” controls (e.g., send an email to someone to confirm they are doing what the tool thinks) and generate reports. Much of what we call GRC should really be features of your ERP and accounting software.

In the security world, most of what we call GRC tools are dashboard and reporting tools that survey or plug into the rest of our security architecture. Conceptually, this is fine, except we see the tools drifting away from being functional for those with operational responsibilities, and focusing more on genercising content for the “business” audience and auditors. It’s an additional, very highly priced, reporting layer.

That’s why I think this category is not only dead, it was never born. There is no one in an enterprise that will use a GRC tool on a day to day basis. The executives want their reports at the end of the quarter, and probably don’t mind a dashboard to glance at, but they’ll never drill down into all the minutiae of controls that probably aren’t what’s really being used in the first place. It’s not what they’re paid for. Internal auditors might also use reports and status checks, but they can almost always get this information from other sources. A GRC tool provides almost no value at the business unit level, since it doesn’t help them get their day to day jobs done.

The pretty dashboards and reports might be worth a certain investment, but not the six-figure plus fees most of them run for. No one really needs a GRC tool, since the tools don’t really perform productive work.

We’re seeing an onslaught of security (and other) vendors jumping on GRC because they think it will get them access to the CEO/CFO and bigger deals. But the CEO and CFO don’t give a rat’s ass how we do security, the just need to know if they are secure enough. That’s what they hire the CSO for- and it’s the CSO’s job to provide the right reports. These vendors would be better served by making great products and building in good reporting and management features to make the jobs of the security team easier.

Focus on helping security teams do their jobs and getting the auditors off their backs, rather than selling to a new audience that doesn’t care. Stop trying to sell to an audience (the CEO) that doesn’t care about you, when you have plenty of prospects out there drooling over those rare, good, functional products. Plenty of products get a boost from compliance, but they aren’t dedicated to it.

Don’t believe me? Go look at what people are really buying. Go ask your own CEO if he wants the latest GRC tool and will pay for it. Ask him if he wants to talk to any more vendors. Ask the operational guys if it will help them get their jobs done.

GRC is a feature, not a product. It’s a reporting tool, not a new paradigm for doing business.

As for the “practice” of GRC? I wouldn’t bet my career on a buzzword created by a small group of vendors to sell more product and jump on the bandwagon of yet another buzzword (compliance).

Compliance is real. Risk management is real. Governance and security are real. GRC is an unrequited wet dream leaving a rash of vendor blueballs in its wake.

I was driving around listening to Car Talk on NPR this weekend, and it was an incredibly insightful lesson on risk tolerance and risk perception. I tend to do a lot of errands over the weekend around that time, so I usually catch 20-40 minutes of it every week as I’m in and out of stores. Pretty much every week you’ll hear things like:

Caller: My car’s making this grinding noise when I accelerate.

CT: How long has this been going on?

Caller: About a year or so.

CT: And why didn’t you take it in?

Caller: I’m worried it will be too expensive to fix.

Gee, that sounds familiar. Or these calls:

Caller: My engine feels like it’s running slow or something.

CT: Is the check engine light on?

Caller: Why yes, how did you know?

CT: And let me guess, it’s been on for three months?

Caller: Okay, who called and told you?

CT: No one [Click and Clack laugh]. So why didn’t you check the engine?

Caller: I’m scared it will be expensive.

Then there are these calls:

[long discussion figuring out the problem]

Caller: So I just need to take it in and get it fixed?

CT: Yep, that’s it.

Caller: Will it be expensive?

CT: Maybe, about [x dollars], but it will be a lot more expensive later if you don’t.

Caller: Oh, that’s a lot. Do you think I’ll be okay if I don’t get it fixed?

CT: As long as you don’t need a car, you’ll be fine.

Think about all those cavities you could have avoided by going to the dentist on a regular basis, or that big air conditioning repair you could have skipped if you just performed the annual maintenance on time. Then stop complaining that your users “just don’t get it,” or stop whining about the business ignoring you.

Thanks in large part to the Attrition.org data loss database, there’s recently been some great work on analyzing breaches. I’ve used it myself to produce some slick looking presentation graphs and call attention to the ever-growing data breach epidemic.

But there’s one problem. Not a little problem, but a big honking leviathan lurking in the deep with a malevolent gleam in its black eyes.

Breach notification statistics don’t tell us anything, at all, about fraud or the real state of data breaches.

The statistics we’re all using are culled from breach notifications- the public declarations made by organizations (or the press) after an incident occurs. All a notification says is that information was lost, stolen, or simply misplaced. Notifications are a tool to warn individuals that their information was exposed, and perhaps they should take some extra precautions to protect themselves. At least that’s what the regulations say, but the truth is they are mostly a tool to shame companies into following better security practices, while giving exposed customers an excuse to sue them.

But notifications don’t tell us a damn thing about how much fraud is out there, and which exposures result in losses.

(Okay- the one exception is that any notification results in losses for a business that goes through the process).

In other words, we don’t know which of the myriad of exposures we read about daily in the press result in damages to those whose records were lost. They are also self reported; and I know for a fact there are incidents where companies did not disclose because they didn’t think they’d get caught.

For example, based on the statistics nearly a third of all breach notifications are the result of lost laptops, computers, and portable media (around 85 million records, out of around 316 million total lost records). About 51 million of those records were the result of two incidents (the VA in the US, and HMRC in the UK). The resulting fraud?

Unknown. No idea. Zip. Nada. In all those cases, I don’t know of a single one where we can tie the fraud to the lost data.

In some cases we really can track back the fraud. TJX is a great example, and the losses may be in the many tens of millions of dollars. ChoicePoint is another example, with 800 cases of identity theft resulting from 163,000 violated records (a number that’s probably really around 500,000, but ChoicePoint limited the scope of their investigation).

What we need are fraud statistics, not self-reported breach notification statistics. We do the best with what we have, but according to the notification stats we should all be encrypting laptops before we secure our web applications, yet the few fraud statistics available support the contrary conclusion.

In other words, we do not have the metrics we need to make informed risk management decisions.

This also creates a self-fulfilling negative feedback loop. Notifications result in measurable losses to businesses, driving security spending to prevent incidents that cause notifications, which may not represent prioritized security/loss risks.

When you read these things, especially on the slides shoved down your throat by desperate vendors (it’s usually slide 2 or 3), ask yourself if each one is an exposure, or actual fraud.

Boy, RSA was sure a blur this year. No, not because of the alcohol, and not because the event was any more hectic than usual. My schedule, on the other hand, was more packed than ever. I barely walked the show floor and was only able to wave in passing to people I fully intended on sitting down with over a beer or coffee and having deep philosophical conversations with.

Since pretty much everyone in the world knows I spend most of my time on information-centric security, for which DLP is a core tool, it’s no surprise I took a ton of questions on it over the week. Many of these questions were inspired by analysis, including my own, that leaks over email/web really aren’t a big source of losses. People use that to try to devalue DLP, forgetting that network monitoring/prevention is just one piece of the pie. A small piece, in the overall scheme of things.

Let’s review our definition of DLP:

“Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis”.

Content Discovery, the ability to scan and monitor data at rest, is one of the most important features of any DLP solution; one with significant ability to reduce enterprise risk. While network DLP tells you how users are communicating sensitive information, content discovery tells you where sensitive information is stored within the enterprise, and often how it’s used. Content discovery is likely more effective at reducing enterprise risks than network monitoring, and is one reason I tend to recommend full-suite DLP solutions over single channel options.

Why?

Consider the value of knowing nearly every location where you store sensitive information, based on deep content analysis, and who has access to that data. Of being able to continuously monitor your environment and receive notification when sensitive content is moved to unapproved locations, or even if the access rights are changed on it. Of, in some cases, being able to proactively protect the content by quarantining, encrypting, or moving it when policy violations occur.

Content discovery, by providing deep insight as to the storage and use of your sensitive information, is a powerful risk reduction tool. One that often also reduces audit costs.

Before we jump into a technology description let’s highlight a few simple use cases that demonstrate this risk reduction:

1. Company A creates a policy to scan their storage infrastructure for unencrypted credit card numbers. They provide this report to their PCI auditor to reduce audit costs and prove they are not storing cardholder information against policy.
2. Company B is developing a new product. They create a policy to generate an alert if engineering plans appear anywhere except on protected servers.
3. Company C, a software development company, uses their discovery tool to ensure that source code only resides in their versioning/management repository. They scan developer systems to keep source code from being stored outside the approved development environment.
4. Company D, an insurance company, scans employee laptops to ensure employees don’t store medical records to work at home, and only access them through the company’s secure web portal.

In each case we’re not talking about preventing a malicious attack, although we are making it a bit harder for an attacker to find anything of value; we’re focused on reducing risk by reducing our exposure and gaining information on the use of content. Sometimes it’s for compliance, sometimes it’s to protect corporate intellectual property, and at other times it’s simply to monitor internal compliance with corporate policies.

In discussions with clients, content discovery is moving from a secondary priority to the main driver in many DLP deals (I hope to get a number out there in the next post).

As with most of our security tools, content discovery isn’t perfect. Monitoring isn’t always in real time, and it’s possible we could miss some storage locations, but even without perfection we can materially reduce enterprise risks.

Over the next few days we’ll talk a little more about the technology, then focus on best practices for deployment and ongoing management.

Technorati Tags: Content Discovery, Data Loss Prevention, Information Security, Information-centric security, Risk Management, Security

On Tuesday morning I’ll be giving a breakfast session at RSA sponsored by Vericept entitled Understanding and Preventing Data Breaches. This is the latest update to my keynote presentation where I dig into all things data breaches to make a best effort at determining what’s really going on out there. Since the system itself is essentially designed to hide the truth and shift risk like a token ring network, digging to the heart of the matter is no easy task.

On Friday Dark Reading published my latest column which is a companion piece to the presentation. It’s a summary of some of the conclusions I’ve come to based on this research. Like much of what I write I consider much of this to be obvious, but not the kinds of things we typically discuss. It’s far easier to count breaches and buy point solutions than to really discuss and solve the root cause. Here are a couple of excerpts, but you should really read the full article:

…

When I began my career in information security, I never imagined we would end up in a world where we have as much need for historians and investigative journalists as we do technical professionals. It’s a world where the good guys refuse to share either their successes or failures unless compelled by law. It’s a world where we have plenty of information on tools and technologies, but no context in which to make informed risk decisions on how to use them.

Call me idealistic, but there is clearly something wrong with a world where CISOs are regularly prevented by their legal departments from presenting their successful security programs at conferences.

…

1. Blame the system, not the victims, for identity fraud.
…
2. Blame the credit card companies, not the retailers, for credit card fraud.
…
3. Consumers suffer from identity fraud, retailers from credit card fraud.
…
4. We need fraud disclosure, not breach disclosure.
…
5. We need public root cause analysis.
…
6. Breach disclosures teach us the wrong lessons.

…

Based on the ongoing research I’ve seen, it’s clear that the system is broken in multiple ways. It’s not our failure as security professionals — it’s the failure of the systems we are dedicated to protecting.

While my presentation focuses on using what little information we have to make specific tactical recommendations, the truth is we’ll just be spinning our wheels until we start sharing the right information — our successes and failures — and work on fixing the system, not just patching the holes at the fringes.

Technorati Tags: Dark Reading, Data Breach, Governance, Information Security, Information-centric security, Security, Security Industry

There goes another one.

According to multiple sources, the Hannaford Brothers grocery chain suffered a major breach with 4.2 million credit cards exposed. Hannaford had published an FAQ for their customers. Odds are it will be months until we find out what really happened, but I’m going to speculate anyway, pick apart the press coverage and FAQ, and see if we can learn something from this now.

As usual, the information released is incomplete and contradictory.

PORTLAND, Maine (AP) - A security breach at an East Coast supermarket chain exposed 4.2 million credit and debit card numbers and led to 1,800 cases of fraud, the Hannaford Bros. grocery chain announced Monday.

Hannaford said credit and debit card numbers were stolen during the card authorization process and about 4.2 million unique account numbers were exposed.

The breach affected all of its 165 stores in the Northeast, 106 Sweetbay stores in Florida and a smaller number of independent groceries that sell Hannaford products.

This is interesting since there is a direct tie to fraud, as opposed to many other breaches. This often means the fraud was detected in the credit system and then traced back to the retailer, which seems to be what happened based on the FAQ. As a researcher it’s always helpful to be able to tie the breach to illegal activity. This does, of course, suck for the victims, but as long as it’s credit card fraud they are protected.

Since the information was stolen during the authorization process, and was distributed over many locations, it means a compromise of the central authorizations system or the credit card processor. It could be as simple as sniffing unencrypted communications, or a more complex compromise of a database or application. My money is 70% on sniffing, 30% on something in the database.

No personal data such as names, addresses or telephone numbers were divulged - just account numbers.

This can’t be true. Without names, the card numbers are unusable.

Hannaford became aware of the breach Feb. 27. Investigators later discovered that the data breach began on Dec. 7; it wasn’t contained until March 10, said Carol Eleazer, Hannaford’s vice president of marketing in Scarborough.

“We have taken aggressive steps to augment our network security capabilities,” Hannaford president and CEO Ronald C. Hodge said in a statement released Monday. “Hannaford doesn’t collect, know or keep any personally identifiable customer information from transactions.”

This reinforces the likelihood of a network breach and sniffing, assuming the statement is true. How was the network breached? Could be any one of hundreds of ways. Targeted phishing and compromise of the central network from a remote location are common. I can’t add anything more than pure speculation on this one.

The company urged its customers to monitor their credit and debit cards for unusual transactions and report any problems to authorities.

Actually, card issuers should reissue the cards and just eliminate the chance of greater fraud. This is irresponsible. Since this is just loss of credit cards, there is no need for identity theft protection.

Mark Walker, an attorney for the Maine Bankers Association, said his organization sent an advisory to member banks Friday after learning of the breach. Only a few had reported suspicious activity involving the credit and debit cards they had issued customers, Walker said.
“I had expected there would be more than we’ve heard of,” Walker said. “But it’s still too early for us to tell.”

Strange- I consider 1,800 to be a large number. It could be that the fraud was performed directly in the Hannaford system or something. Or this is an erroneous statement.

The FAQ gives us a little more information and narrows things down.

What happened?

Hannaford announced containment of a data intrusion into its computer network that resulted in the theft of customer credit and debit card numbers. This data was illegally accessed from Hannaford’s computer systems during the card verification transmission process in transactions. Further, Hannaford is cooperating with credit and debit card issuers to ensure those customers who may be affected by the theft are protected

Somewhat contradictory, with a mention of data security and network, but I don’t expect everyone to be as picky about those details as we are. I suspect the last sentence means fraud alerts are in place, and cards are probably being reissued to some extent.

When did you discover the intrusion?

Hannaford was first made aware of suspicious credit card activity on Feb. 27, and immediately initiated a comprehensive investigation with the assistance of leading computer security experts

Bingo. It was detected by the banks or credit card companies, then brought to Hannaford.

Is it safe to continue shopping in your stores?

We have continually devoted significant round-the-clock resources to ensure Hannaford has comprehensive data security systems in place. For example, our security measures meet industry compliance standards and many go above and beyond what is required by industry standards.

In other words, PCI is worthless.

In conclusion, it looks like some sort of a network breach (which could be anything from phishing/malware to compromise from a retail location to a full network hack). A sniffer was possibly installed, since it seems they don’t keep credit card information (again, assuming statements are true). The fraud was detected by the banks or credit card companies, then it took a little under two weeks to contain. Not great, and indicative of either a little sophistication on the attacker’s part, or a lack of sophistication on Hannaford’s part.

How to prevent this?

We won’t know until more information is out, but since they shouldn’t be PCI compliant if they transmitted credit card numbers in the clear, perhaps my guess of sniffing is off. I’m still laying odds on that, and if so, encryption is the answer.

Technorati Tags: Data Breach, Hannaford

Even in my drug-addled state last week it was hard to miss the cold boot encryption attack released by Ed Felten and the Princeton Center for Information Technology Policy. This is some seriously impressive work with major implications, but despite all the articles I’ve seen there has been little information on how to evaluate and mitigate your personal or organizational risk.

That’s where I come in.

I’m not going to assume you know a lot about file and media encryption, so we’ll start with en explanation of how, and why, the attack works. Then we’ll evaluate the risk and discuss mitigation strategies. I’ll close with some suggestions for vendors to close out this vulnerability. And yes, this works on a Mac with FileVault.

What is the cold boot attack and how does it work?

All encryption systems need access to a key to encrypt and decrypt data. It doesn’t matter what you’re encrypting- a hard drive, file, database, or whatever, you need a key. When encrypting and decrypting data, because of how computer systems are designed, the key always passes through memory at some point. For smaller content this is a transient process and the key is only in memory for a short time (assuming the software is designed properly), but when you need constant access to data the key is kept in memory. This is nearly ubiquitous for full-disk encryption or file encryption systems that leave files open for read/write operations. It’s not something we worried about, because when you turn a computer off the RAM (memory for the non geeks) loses power and anything stored is lost. Thus we would password protect our encrypted systems so that even if they wake up from sleep mode, an attacker would have to reboot the system unless they had the key, confident this process would erase the key from memory and keep the data secure.

What the Princeton researchers demonstrated is that modern RAM doesn’t degrade immediately after power is removed. The contents of memory can persist from seconds to minutes, and that time extends when cold is applied to the memory. An easy way to do this is to just use a can of dust off spray.

That’s the first part of the attack- keeping the contents in memory after the system is shut down.

For the second part of the attack they use a special tool, which they haven’t made public, to recover memory contents from RAM. In the demo this tool is on a bootable USB drive, so merely rebooting the computer from this USB stick, ignoring the host operating system of the computer, allows them to scan memory and recover the encryption key. Additional work allowed them to recover a full key even if a few bits were lost as the memory degraded.

To execute the attack, the attacker opens the computer, sprays the memory with an upside-down can of dust off to cool it, then reboots off the USB device with their software for key recovery on it, thus recovering the keys and gaining access to the data.

If you use a boot password or something similar they perform the same attack, but remove the memory and place it into a different system for key recovery. Thanks to the cold spray you have more than enough time to pull this off.

Evaluating the Risk

There are no public tools for this attack but it’s only a matter of time. Your immediate risk is low, but don’t be surprised if tools appear reasonably soon. This is a serious vulnerability, with a probability of attack that only increases over time.

In other words, don’t panic, but keep your eyes open. Once a public tool appears it’s time to be more concerned.

The researchers outline how most current protection techniques only partially, if at all, mitigate this flaw. Since memory can be removed, BIOS locks and other restrictions are ineffective.

You are only at risk when your computer is powered on or in sleep mode and you lose physical control of it. Powering off your system begins the memory degradation process and you are safe within a few minutes.

Reducing Your Risk

The most effective method is to power off your system completely (not sleep or hibernate mode) when it’s at risk of physical loss. This is inconvenient, but I’m going to start powering off when I’m in higher risk areas (like airport security) and can’t maintain physical control of the system.

Which brings recommendation number 2- don’t let someone steal your computer. I personally maintain physical control over my system nearly all the time when it’s out of my home (and I have a pretty good security system there). At hotels is the greatest risk, and I do tend to power off when I’m out of the room. You sales guys should start getting into the habit of not using sleep mode when you leave your computer locked in a rental car. At least until the encryption and laptop vendors come up with alternative protections.

For those of you with very sensitive information, combine file and folder encryption for sensitive files with your whole disk encryption. A few vendors offer this (feel free to brag in the comments guys). Just close those sensitive files or images before entering sleep mode, and make sure they are password protected and not linked to your normal login credentials.

Also consider an encryption system that supports storing the keys on a smart card (not in memory). I don’t believe there are many practical options today, but expect to see them crop up thanks to this paper.

Finally, ask your vendor their plans to manage this risk. Today it’s not a big deal, but we don’t know if it will be 2 weeks, 2 months, or two years before public tools appear (and it’s safe to assume some governments have this by now — or more accurately, it would be unsafe and foolish to assume any government does note have this capability by now).

Thus, your overall risk is currently low but growing. You can reduce that risk through good habits and some additional software.

What Vendors Can Do

I don’t know to what degree this technique works on commercial encryption products, but vendors should evaluate the risk to their products and keep customers updated. Saying it isn’t a problem or the risk is low isn’t the right answer- you’ll lose customers that way. If you are working on a solution, let them know since the risk really is low for now.

I suspect we’ll see a couple of different approaches. Over time, this is something that will migrate into hardware- even just a small bit of RAM soldered to the board, probably integrated with some future, mythical, TPM. On the software side I have to believe there are ways we can reduce the risk- for example, flushing the active key from memory during sleep (while turning off hibernate, which writes memory to disk and is always bad anyway) and transitioning to a password protected temp key to access the primary key.

Hardware tokens/smart cards are another great option, assuming we can control active access to the key and you remember to unplug it. There are a lot of really smart engineers out there who will probably come up with fixes, at least for third party encryption tools, before this attack becomes widespread.

Conclusion

This is an impressive and serious attack we all need to take extremely seriously. You are at risk if you lose physical control of an encrypted system that is either powered on or in sleep or hibernate mode.

Turning off your system when it’s at greatest risk of loss or theft is a very effective mitigation, but it will be difficult to train average users to stop using sleep mode due to the convenience.

Using file encryption for sensitive content in combination with whole disk may also reduce the risk when done properly.

Talk to your vendor, and make sure they are REALLY not susceptible or have a roadmap to eliminate this method of attack. If they offer the protection, understand and implement the necessary configuration profile, which may not be the default.

Vendors: talk to your customers and get working on the problem if you are vulnerable. Recognize that hardware solutions are always longer term and you should really see if there is a way to offer protection within the software.

Me? I’m not too worried, but I have extremely good habits around the physical control of my laptop, and will now shut down more under certain circumstances. Since I have a fast Mac, rebooting isn’t all that bad anyway…

Technorati Tags: Cold Boot, Encryption, Key Management, Laptop Encryption, Vulnerability

1. Internet Explorer/ActiveX
2. QuickTime
3. Adobe Acrobat Reader

Each of these applications has plugin architectures and inadequate security models. Actually, IE 7 + Vista is a good model, but it will take 3 years for it to hit wide enough deployment.

Technorati Tags: Adobe Acrobat, Apple, Internet Explorer, Microsoft, Adobe, QuickTIme

Update: Thanks to Windexh8er (who provides good information despite being far more inflammatory than he needs to, what’s up with that?) Iran is up and the traffic report is wrong.

Another cable is down in the Middle East, and Iran is now offline. News stories indicate the cables are relatively new, and odds of simultaneous component failure are low.

This can’t be seismic activity or we’d see other reports from scientists (kind of hard to hide earthquakes and volcanos these days).

The odds are inching towards deliberate tampering, but I’m not going to go all crazy with conspiracy theories yet. There could still be other explanations. And no, I don’t think this is the CIA with black submarines. If we have that capability, which I’m sure we do, we wouldn’t blow it by screwing with cables during Super Bowl weekend just to annoy people. It’s too strategically important a capability to tip our hand without a compelling, immediate cause.

Technorati Tags: Cyberattack

It’s no surprise that I’m a big fan of Microsoft’s Trustworthy Computing Initiative- something I was skeptical of when it was first announced. MS proved me wrong, and years later we’ve seen a very positive impact. Vulnerabilities are down, response times are up, and products ship in more secure configurations. Yes, they still screw up every now and then, but it’s overall been a huge improvement. Just because I don’t like to use Vista doesn’t mean I don’t appreciate all the security work that went into it, and let’s not forget all the benefits across the rest of the product line. Go count SQL Server 2005 vulnerabilities if you want any proof. You’ll only need one hand, and you’ll have 4 fingers left over (5, if you really look where the vuln came from).

If MS buys Yahoo! and implements TCI, the impact could be enormous. Google isn’t doing a very good job of managing security issues, and if these things hit a certain point they could affect user behavior.

Realistically it will take 3-5 years for the full implications of TCI to affect any product line, but we’ll see incremental improvements fairly quickly. Yahoo!’s security track record isn’t all that bad to start with, and I much prefer their privacy policy over Google’s.

Should Microsoft! use security for competitive advantage (and it work), we can expect Google to respond fairly quickly. They aren’t stupid, and if security affects business they will get on the ball immediately.

None of this, of course, will come to pass if market forces don’t place a priority on security. It doesn’t even need to be a top priority, just somewhere moderately high on the list. There could also be peripheral benefits to a major Web 2.0 company building the tools, techniques, and education for secure coding.

My guess? Nothing earth shattering, but if the deal goes through there will be a net security benefit substantial enough that we’ll all be referring back to it in our blog posts in 5 years.

Technorati Tags: Application security, Microsoft, Yahoo!