Research

In this report we spotlight both the grim realities and real benefits of SIEM/Log Management platforms. The vendors are certainly not going to tell you about the bad stuff in their products – they just shout out the same fantastic advantages touted in the latest quadrant report. Trust us when we say there are many pissed-off SIEM users, but plenty of happy ones as well. We focused this paper on resetting expectations and making sure you know enough to focus on success, which will save you much heartburn later. This fairly comprehensive paper delves into the use cases for the technology, the technology itself, how to deploy it, and ultimately how to select it. We assembled this paper from the Understand and Selecting a SIEM/Log Management blog series from June and July 2010. Special thanks to Nitro Security for sponsoring the research. You can download the paper (PDF) directly or visit the landing page.   Share:

I joined Securosis back in January and took on coverage of network and endpoint security. My goal this year was to lay the foundation by doing fairly in-depth research projects on the key fundamental areas in each patch. I started with Endpoint Security Fundamentals (I’m doing some webcasts next month) and continued with the Network Security Operations Quant project (which I’m now working through) to focus on the processes to manage network security devices. But clearly selecting the anchor device in the perimeter – the firewall – demands a full and detailed analysis. So next week I’ll start a series on “Understanding and Selecting an Enterprise Firewall.” As always, we’ll use the Totally Transparent Research process, which means everything will be posted to the blog and only after taking a round of feedback will we package the content as a paper. In preparation for the series I’m (as always) looking for more data points on what’s changing on the perimeter, specifically for the enterprise firewall. Are you looking at updating/re-architecting your firewall implementation? Happy with the incumbent? Looking to add more capabilities, such as UTM-like functions? Do you give a crap about all this application visibility hype? How do you manage 15-200 devices? I only need 15-20 minutes and any help is much appreciated. If you have opinions send me email: mrothman (at) securosis (dot) com and we’ll schedule some time to talk. Share:

It’s funny how different folks have totally different perceptions of the same things. Obviously the idea of freedom for someone living under an oppressive regime is different than my definition. My good fortune to be born in a certain place to a certain family is not lost on me. But my wacky idea of freedom took on an interesting meaning this past weekend. The Boss was out of town with one of the kids. So I was responsible for the other two, and that meant on Saturday I started the day helping out our friends at their son’s birthday party. After much fun on the kickball field and making sure none of the little men drowned in the pool, I took the boy, XX1 (oldest girl), and two of his friends home for a few hours. When the interlopers were retrieved by their parents a couple hours later, I had to drop XX1 off at yet another birthday party. But this one involved a sleepover, so once I dropped her off I had one less thing to worry about. Back home with the boy, about an hour of catch (the kid has a pretty good gun), some hydration and a snack, and then time to send him off to his own sleepover. So by 6:30pm, I had shed my kids and felt freedom. So what to do? The Braves were out of town, I’m not a big Maroon 5 fan (they were in town), and no movies really interested me. So I decided to do something I very rarely do on a weekend: Be a slug. I got some Chinese food (veggie fried rice FTW) and settled down in front of the Giants NFL pre-season game and then a few stand-up comedy specials streamed via Netflix. About every 10 minutes I’d pause the TV for about 30 seconds and just enjoy. the. silence. No one asking me for a snack or to play a game or to watch TV or to just be annoying. No kids to pick up from this place or that. No to-do list to weigh over my head. No honey-do projects that had to be done. Just silence. And it was good. I know I should be kind of embarrassed that for me, freedom (at least in some sense) is about no one needing me to do anything. But it is. I’m happy 99% of the time to be doing what I like to do. But every so often it’s nice to just shut it down and not feel bad about it. Like everything else, that feeling passed. About 12 hours later, when I had to retrieve the kids and get back in the hamster wheel. But I did enjoy it, however fleeting it was. – Mike. Photo credits: “Freedom is a Toilet Tissue” originally uploaded by ruSSeLL hiGGs Recent Securosis Posts We Securosis folks are big fans of beer. Especially strong beer. You know, the kind you need to get in Canada. So we decided to import some help from up north in the form of new Contributing Analysts James Arlen and Dave Lewis. Yes, you know them. Yes, they are smart guys. And yes, we do have plans for world domination. Don’t say we didn’t warn you. Backtalk Doublespeak on Encryption Webcasts on Endpoint Security Fundamentals Data Encryption for PCI 101: Encryption Options Data Encryption for PCI 101: Introduction Friday Summary: August 20, 2010 Another Take on McAfee/Intel McAfee: A (Secure) Chip on Intel’s Block Acquisition Doesn’t Mean Commoditization Various NSO Quant posts: Manage IDS/IPS – Process Change Request Manage IDS/IPS – Test and Approve Manage IDS/IPS – Deploy Manage IDS/IPS – Audit/Validate Manage IDS/IPS – Monitor Issues/Tune Manage IDS/IPS Process Revisited Incite 4 U It was only a matter of time. This week Rich finally realized that he gets no extra credit for writing more in an Incite. Though he’s right, when you point to a well-written piece, layering more commentary on top kind of defeats the purpose. Blocking and tackling on the network – Hey, you. It’s your conscience here. Dressed stealthily as an Incite to get you to remember the fundamentals. You know, little things like a properly segmented network can really improve your security. John Sawyer consults some of our pals (like JJ) to remind us that there are a bunch of devices (including embedded OSes and printers), which are vulnerable and really shouldn’t be on the same segments as our sensitive stuff. I’m sure the Great Intel will solve everything by embedding ePO within every chip out there someday. But in the meantime perhaps revisiting your network architecture, while not as fun as deploying another set of flashing lights from soon-to-be-extinct companies will have a bigger impact on your security posture. – MR How do you say B.S. in Spanish? – The big news this week is how a malware infected computer lead to the crash of Spanair flight 5022 (or the English version). If true, this would mean that malware caused deaths and serious destruction of property. And sure, the loss of airliner control conjures up Daemon-like images of destruction. The problem is the article has no details other than malware being found. Somewhere. We’ll make the bold assumption it wasn’t in the baggage turnstile software, but beyond that we don’t know. Most likely it was in one of the ground maintenance systems, where it may have masked some maintenance issue(s). That may or may not have contributed to the crash, but it’s a great story. What really happened and the extent of the malware’s impact is in question. Occam’s Razor would indicate some maintenance worker installed an infected version of Tetris on a Windows 95 PC to stave off boredom. Seriously, until there are some hard facts on this, I have to call tonterias on this steaming pile of insinuation. – AL When in doubt, blame M&A – Given the backdrop of the security acquisitions last week (INTC/MFE and HP/Fortify) we once again get to suffer from

*Updated:** 8/25/2010 Storefront-Backtalk magazine had an interesting post on Too Much Encrypt = Cyberthief Gift. And when I say ‘interesting’, I mean the topics are interesting, but the author (Walter Conway) seems to have gotten most of the facts wrong in an attempt to hype the story. The basic scenario the author describes is correct: when you encrypt a very small range of numbers/values, it is possible to pre-compute (encrypt) all of those values, then match them against the encrypted values you see in the wild. The data may be encrypted, but you know the contents because the encrypted values match. The point the author is making is that if you encrypt the expiration date of a credit card, an attacker can easily guess the value. OK, but what’s the problem? The guys over at Voltage hit the basic point on the head: it does not compromise the system. The important point is that you cannot derive the key from this form of attack. Sure, you can you confirm the contents of the enciphered text. This is not really an attack on the encryption algorithm, nor the key, but poorly deployed cryptography. It’s one of the interesting aspects of encryption or hashing functions; if you make the smallest of changes to the input, you get a radically different output. If you add randomness (Updated: per Jay’s comments below, this was not clear; Initialization Vector or feedback modes for encryption) or even somewhat random “salting” (for hashing) we have an effective defense against rainbow tables, dictionary attacks, and pattern matching. In an ideal world we would do this. It’s possible some places don’t … in commodity hardware, for example. It did dawn on me that this sort of weakness lingers on in many Point of Sale terminals that sell on speed and price, not security. These (relatively) cheap appliances don’t usually implement the best security: they use the fastest rather than the strongest cryptography, they keep key lengths short, they don’t do a great job at gathering randomness, and generally skimp on the mechanical aspects of cryptography. They also are designed for speed, low cost, and generic deployments: salting or concatenation of PAN with the expiration date is not always an option, or significant adjustments to the outbound data stream would raise costs. But much of the article talks about data storage, or the back end, and not the POS system. The premise of “Encrypting all your data may actually make you more vulnerable to a data breach” is BS. It’s not an issue of encrypting too much, it’s in those rare cases where you encrypt in very small digestible fields. “Encrypting all cardholder data that not only causes additional work but may actually make you more vulnerable to a data breach” is total nonsense. If you encrypt all of the data, especially if you concatenate the data, the resulting ciphertext does not suffer from the described attack. Further, I don’t believe that “Most retailers and processors encrypt their entire cardholder database”, making them vulnerable. If they encrypt the entire database, they use transparent encryption, so the data blocks are encrypted as whole elements. The block contents are random so each has some degree of natural randomness going on because the database structure and pointers are present. And if they are using application layer or field level encryption, they usually salt alter the initialization vector. Or concatenate the entire record. And that’s not subject to a simple dictionary attack, and in no way produces a “Cyberthief Gift”. Share:

Starting in early September, I’ll be doing a series of webcasts digging into the Endpoint Security Fundamentals paper we published over the summer. Since there is a lot of ground to cover, we’ll be doing three separate webcasts, each focused on a different aspect. The webcasts will be very little talking-head stuff (you can read the paper for that). We’ll spend most of the time doing Q&A. So check out the paper, bring your questions, and have a good time. As with the paper, Lumension Security is sponsoring the webcasts. You can sign up for a specific webcast (or all 3) by clicking here. Here is the description: Endpoint Security Fundamentals In today’s mobile, always on business environment, information is moving further away from the corporate boundaries to the endpoints. Cyber criminals have more opportunities than ever to gain unauthorized access to valuable data. Endpoints now store the crown jewels; including financial records, medical records, trade secrets, customer lists, classified information, etc. Such valuable data fuels the on-demand business environment, but also creates a dilemma for security professionals to determine the best way to protect it. This three part webcast series on Endpoint Security Fundamentals examines how to build a real-world, defense-in-depth security program – one that is sustainable and does not impede business productivity. Experts who will lead the discussion are Mike Rothman, Analyst and President of Securosis, and Jeff Hughes, Director of Solution Marketing with Lumension. Part 1 – Finding and Fixing the Leaky Buckets September 8, 2010 11 AM ET (Register Here) Part 1 of this webcast series will discuss the first steps to understanding your IT risk and creating the necessary visibility to set up a healthy endpoint security program. We will examine: The fundamental steps you should take before implementing security enforcement solutions How to effectively prioritize your IT risks so that you are focusing on what matters most How to act on the information that you gather through your assessment and prioritization efforts How to get some “quick wins” and effectively communicate security challenges with your senior management Part 2 – Leveraging the Right Enforcement Controls September 22, 2010 11 AM ET (Register Here) Part 2 of this webcast series examines key enforcement controls including: How to automate the update and patch management process across applications and operating systems to ensure all software is current How to define and enforce standardized and secure endpoint configurations How to effectively layer your defense and the evolving role that application whitelisting plays How to implement USB device control and encryption technologies to protect data Part 3 – Building the Endpoint Security Program October 6, 2010 11 AM ET (Register Here) In this final webcast of our series, we take the steps and enforcement controls discussed from webcasts 1 and 2 and discuss how to meld them into a true program, including: How to manage expectations and define success How to effectively train your users about policies and how to ensure two-way communication to evolve policies as needed How to effectively respond to incidents when they occur to minimize potential damage How to document and report on your overall security and IT risk posture Hope to see you for all three events. Share:

It’s time that the security industry stopped trying to play paramilitary games and started trying to do a good job (aka “best practices”.) It would be a very pleasant change. Currently, the three major information security religions – ISACA, ISC2, and SANS – offer a total of roughly 75 different certifications. This laundry list of certifications leads to a set of fairly serious problems: Security professionals need fold-out business cards Organizations need an equivalency look-up table for resume filtering These problems are entertaining to describe this way, but also present a real problem – how can you objectively determine whether or not a given candidate has the skills necessary to do the job that they’re being asked to do? Recently, The Commission on Cybersecurity for the 44th Presidency released a fairly damning report entitled “A Human Capital Crisis in Cybersecurity: Technical Proficiency Matters” available as a PDF which essentially calls out the old-line security certification bodies for producing really good compliance rubber-stampers but not functional security practitioners. A real gap that needs to be managed – outside of the scope of the pre-existing commercial security certifications. Then things get interesting, this requirement was speedily turned into the ‘National Board of Information Security Examiners’ and if you just glance under the covers, you’ll discover something very interesting. Report authors: Franklin S. Reeder, Karen Evans, James Lewis NBISE Leadership: Franklin S. Reeder, Karen Evans, James Lewis It’s almost like they were ready to go with all of the answers to the problems they created… I guess they had some insight into what the report was going to say. If you look around a little bit, you’ll likely reach the same conclusion that I did: SANS is a little miffed at EC-Council being named in the most recent DoD 8570 directive and someone specifically wanted to carve out a little bit of a government-regulated monopoly on security certifications – a permanent revenue stream. I don’t think that this response is any more useful or valid than the position of the traditional security certifications. It’s yet another organization which exists for the service of it’s self – not it’s members and certainly not the ultimate end-users of it’s membership. If you are a member of ISACA, ISC2 or SANS, I would encourage you to ask yourself what they’ve done for you lately, what they’ve done to make the information security profession more respectable, and most importantly how many hours has it been since they suggested to you that you need to help them get more members. After all, making a scarce resource less scarce is the best way to increase quality and make sure your value stays high. Share:

In the introductory post of the Data Encryption for PCI series, there were a lot of good comments on the value of hashing functions. I wanted to thank the readers for participating and raising several good points. Yes, hashing is a good way to match a credit card number you currently have determine if it matches one you have already been provided – without huge amounts of overhead. You might even call it a token. For the purpose of this series, as we have already covered tokenization, I will remain focused on use cases where I need to keep the original credit card data. When it comes to secure data storage, encryption is the most effective tool at our disposal. It safeguards data at rest and improves our control over access. The PCI Data Security Standrad specifies you need to render the Primary Account Number (what the card associations call credit card numbers) unreadable anywhere it is stored. Yes, we can hash, or we can truncate, or we can tokenize, or employ other forms of non-reversible obfuscation. But we need to keep the original data, and occasionally access it, so the real question is how? There are at least a dozen different variations on file encryption, database encryption and encryption at the application layer. The following is a description of the available encryption methods at your disposal, and a discussion of the pros & cons of each. We’ll wrap the series by applying these methods to the common use cases and make recommendations, but for now we are just presenting options. What You Need to Know About Strong Ciphers In layman’s terms, a strong cipher is one you can’t break. That means if you try to reverse the encryption process by guessing the decryption key – even if you used every computer you could get your hands on to help guess – you would not guess correctly during your life time. Or many lifetimes. The sun may implode before you guess correctly, which is why we are not so picky when choosing one cipher over another. There are lots that are considered ‘strong’ by PCI standards organization, and they provide a list for you in the PCI DSS Glossary of Terms. Tripe-DES, AES, Blowfish, Twofish, ElGamal and RSA are all acceptable options. Secret key ciphers (e.g. AES) use a minimum key length of 128 bits, and public key algorithms (those then encrypt with a public key and decrypt with a private key) require a minimum of 1024 bit. All of the commercial encryption vendors offer these, at a minimum, plus longer key lengths as an option. You can choose longer keys if you wish, but in practical terms they don’t add much more security, and in rare cases they offer less. Yet another reason to not fuss over the cipher or key length too much. When you boil it down, the cipher and key length is far less important than the deployment model. How you use encryption in your environment is the dominant factor for security, cost and performance, and that’s what we’ll focus on for the remainder of this section. Encryption Deployment Options Merchant credit card processing systems can be as simple as a website site plug-in, or they may be a geographically disperse set data processing systems with hundreds of machines performing dozens of business functions. Regardless of size and complexity, these systems store credit card information in files or databases. It’s one or the other. And the data can be encrypted before it is stored (application layer), or when it is stored (file, database). Database Encryption: The most common storage repository for credit card numbers. All relational databases offer encryption, usually as an add-on package. Most databases offer both very granular encryption methods (e.g. only on a specific row or column) as well as an entire schema/database. The encryption functions can be invoked programmatically through a procedural interface, requiring changes to the database query that instruct the database to encrypt/decrypt. The database automatically alters the table structure to store the binary output of the cipher. More commonly we see databases configured for Transparent encryption – where encryption is applied automatically to data before it is stored. In this model all encryption and key management happens behind the scenes without the users knowledge. Because databases stores redundant copies of information in recovery and audit logs, full database encryption is a popular choice for PCI to keep PAN data from accidentally being revealed. File/Folder Encryption: Some applications, such as desktop productivity applications and some web applications, store credit card data within flat files. Encryption is applied transparently by the operating system as files or folders are written to disk. This type of encryption is offered as a 3rd party add-on, or comes embedded within the operating system. File/Folder encryption can be applied to database files and directories, so that the database contents are encrypted without any changes to the application or database. It’s up to the local administrator to properly apply encryption to the right file/folder otherwise PAN data may be exposed. Application Layer Encryption: Applications that process credit cards can encrypt data prior to storage. Be it file or relational database storage, the application encrypts data before it is saved, and decrypts before data is displayed. Supporting cryptographic libraries can be linked into the application, or provided by a 3rd party package. The programmer has great flexibility in how to apply encryption, and more importantly, can choose to decrypt on application context, not just user credentials. While all these operations are transparent to the application user, it’s not Transparent encryption because the application – and usually the supporting database – must be modified. Use of format-preserving encryption (FPE) variations of AES are available, which removes the need to alter database or file structure to store cipher-text, but does not perform as well as normal AES cipher. All of these options protect stored information in the event of lost or stolen media. All of these options need to use

Before I get into the Summary, I want to lead with some pretty big news: the Liquidmatrix team of Dave Lewis and James Arlen has joined Securosis as Contributing Analysts! By the time you read this Rich’s announcement should already be live, but what the heck – we are happy enough to coverage it here as well. Over and above what Rich mentioned, this means we will continue to expand our coverage areas. It also means that our research goes through a more rigorous shredding process before launch. Actually, it’s the egos that get peer shredding – the research just gets better. And on a personal note I am very happy about this as well, as a long-time reader of the Liquidmatrix blog, and having seen both Dave and James present at conferences over the years. They should bring great perspective and ‘Incite’ to the blog. Cheers, guys! I love talking to digital hardware designers for computers. Data is either a one or a zero and there is nothing in between. No ambiguity. It’s like a religion that, to most of them, bits are bits. Which is true until it’s not. What I mean is that there is a lot more information than simple ones and zeros. Where the bits come from, the accuracy of the bits, and when the bits arrive are just as important to their value. If you have ever had a timer chip go bad on a circuit, you understand that sequence and timing make a huge difference to the meaning of bits. If you have ever tried to collect entropy from circuits for a pseudo-random number generator, you saw noise and spurious data from the transistors. Weird little ‘behavioral’ patterns or distortions in circuits, or bad assumptions about data, provide clues for breaking supposedly secure systems, so while the hardware designers don’t always get this, hackers do. But security is not my real topic today – actually, it’s music. I was surprised to learn that audio engineers get this concept of digititis. In spades! I witnessed this recently with Digital to Analog Converters (DACs). I spend a lot of my free time playing music and fiddling with stereo equipment. I have been listening to computer based audio systems, and pleasantly surprised to learn that some of the new DACs reassemble digital audio files and actually make them sound like music. Not that hard, thin, sterile substitute. It turns out that jitter – incorrect timing skew down as low as the pico-second level – causes music to sound like, well, an Excel spreadsheet. Reassembling the bits with exactly the right timing restores much of the essence of music to digital reproduction. The human ear and brain make an amazing combination for detecting tiny amounts of jitter. Or changes in sound by substituting copper for silver cabling. Heck, we seem to be able to tell the difference between analog and digital rectifiers in stereo equipment power supplies. It’s very interesting how the resurgence of interest in of analog is refining our understanding of the digital realm, and in the process making music playback a whole lot better. The convenience of digital playback was never enough to convince me to invest in a serious digital HiFi front end, but it’s getting to the point that it sounds really good and beats most vinyl playback. I am looking at DAC options to stream from a Mac Mini as my primary music system. Finally, no news on Nugget Two, the sequel. Rich has been mum on details even to us, but we figure arrival should be about two weeks away. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Intel to acquire McAfee in $7.7 billion deal. Mike quoted as being baffled. Which is not a surprise… Adrian’s Dark Reading post on Database Threat Modeling And Strip Poker. Good interview with Mike Rothman on Infosec Resources Sending a Mac away. There are many things to expunge before you let a Mac (or any other computer) out of your personal possession. This list feels long but it’s short compared to taking a laptop to China… Favorite Securosis Posts Mike Rothman: Acquisition Doesn’t Mean Commoditization. David Mortman: Tokenization: Selection Criteria. Adrian Lane: Since I am a contrarian I can’t go with David Mortman’s Acquisition Doesn’t Mean Commoditization, so I’ll pick Rich’s Sour Grapes Incite snippet. Not a whole post, but dead on the money! Rich Mogull: Acquisition Doesn’t Mean Commoditization Gunnar Peterson: HP (Finally) Acquires Fortify Other Securosis Posts Liquidmatrix + Securosis: Dave Lewis and James Arlen Join Securosis as Contributing Analysts. Data Encryption for PCI 101: Introduction. Another Take on McAfee/Intel. McAfee: A (Secure) Chip on Intel’s Block. Acquisition Doesn’t Mean Commoditization. Incite 8/18/2010: Smokey and the Speed Gun. Tokenization: Selection Criteria. Favorite Outside Posts Mike Rothman: Career Advice Tuesday = “How Did You Find Your Mentor”. Hopefully Mike and Lee didn’t find a mentor on FriendFinder. But seriously, everyone needs mentors to help them get to the next level. David Mortman: Cloud Computing & Polycentric Risk Tolerances. Adrian Lane: Quality analysis by Andy Jaquith on Horseless Carriage Vendor Buys Buggy-Whips. Rich Mogull: Young will have to change names to escape ‘cyber past’ warns Google’s Eric Schmidt. Honest assessment and totally untrustworthy all at once. Gunnar Peterson: Not a post, but consider this: $4.125B. That’s the average price of acquiring a security company this week. Project Quant Posts NSO Quant: Manage IDS/IPS – Audit/Validate. NSO Quant: Manage IDS/IPS – Deploy. NSO Quant: Manage IDS/IPS – Test and Approve. NSO Quant: Manage IDS/IPS – Process Change Request. NSO Quant: Manage IDS/IPS – Signature Management. Research Reports and Presentations White Paper: Endpoint Security Fundamentals. Understanding and Selecting a Database Encryption or Tokenization Solution. Low Hanging Fruit: Quick Wins with Data Loss Prevention. Report: Database Assessment. Top News and Posts Something about some hardware company that bought some other security company. Supposedly big news. And some other hardware company buying another security company. Supposed to change the industry. Kinda cool feature for detecting

Ah, the best laid plans. I had my task list all planned out for today and was diving in when my pal Adrian pinged me in our internal chat room about Intel buying McAfee for $7.68 billion. Crap, evidently my alarm didn’t go off and I’m stuck in some Hunter S. Thompson surreal situation where security and chips and clean rooms and men in bunny suits are all around me. But apparently I’m not dreaming. As the press release says, “Inside Intel, the company has elevated the priority of security to be on par with its strategic focus areas in energy-efficient performance and Internet connectivity.” Listen, I’ll be the first to say I’m not that smart, certainly not smart enough to gamble $7.68 billion of my investors’ money on what looks like a square peg in a round hole. But let’s not jump to conclusions, OK? First things first: Dave DeWalt and his management team have created a tremendous amount of value for McAfee shareholders over the last five years. When DeWalt came in McAfee was reeling from a stock option scandal, poor execution, and a weak strategy. And now they’ve pulled off the biggest coup of them all, selling Intel a new pillar that it’s not clear they need for a 60% premium. That’s one expensive pillar. Let’s take a step back. McAfee was the largest stand-alone security play out there. They had pretty much all the pieces of the puzzle, had invested a significant amount in research, and seemed to have a defensible strategy moving forward. Sure, it seemed their business was leveling off and DeWalt had already picked the low hanging fruit. But why would they sell now, and why to Intel? Yeah, I’m scratching my head too. If we go back to the press release, Intel CEO Paul Otellini explains a bit, “In the past, energy-efficient performance and connectivity have defined computing requirements. Looking forward, security will join those as a third pillar of what people demand from all computing experiences.” So basically they believe that security is critical to any and every computing experience. You know, I actually believe that. We’ve been saying for a long time that security isn’t really a business, it’s something that has to be woven into the fabric of everything in IT and computing. Obviously Intel has the breadth and balance sheet to make that happen, starting from the chips and moving up. But does McAfee have the goods to get Intel there? That’s where I’m coming up short. AV is not something that really works any more. So how do you build that into a chip, and what does it get you? I know McAfee does a lot more than just AV, but when you think about silicon it’s got to be about detecting something bad and doing it quickly and pervasively. A lot of the future is in cloud-based security intelligence (things like reputation and the like), and I guess that would be a play with Intel’s Connectivity business if they build reputation checking into the chipsets. Maybe. I guess McAfee has also been working on embedded solutions (especially for mobile), but that stuff is a long way off. And at a 60% premium, a long way off is the wrong answer. For a go-to-market model and strategy there is very little synergy. Intel doesn’t sell much direct to consumers or businesses, so it’s not like they can just pump McAfee products into their existing channels and justify a 60% premium. That’s why I have a hard time with this deal. This is about stuff that will (maybe) happen in 7-10 years. You don’t make strategic decisions based purely on what Wall Street wants – you need to be able to sell the story to everyone – especially investors. I don’t get it. On the conference call they are flapping their lips about consumers and mobile devices and how Intel has done software deals before (yeah, Wind River is a household name for consumers and small business). Their most relevant software deal was LANDesk. Intel bought them with pomp and circumstances during their last round of diversification, and it was a train wreck. They had no path to market and struggled until they spun it out a while back. It’s not clear to me how this is different, especially when a lot of the stuff relative to security within silicon could have been done with partnerships and smaller tuck-in acquisitions. Mostly their position is that we need tightly integrated hardware and software, and that McAfee gives Intel the opportunity to sell security software every time they sell silicon. Yeah, the PC makers don’t have any options to sell security software now, do they? In our internal discussion, Rich raised a number of issues with cloud computing, where trusted boot and trusted hardware are critical to the integrity of the entire architecture. And he also wrote a companion post to expand on those thoughts. We get to the same place for different reasons. But I still think Intel could have made a less audacious move (actually a number of them) that entailed far less risk than buying McAfee. Tactically, what does this mean for the industry? Well, clearly HP and IBM are the losers here. We do believe security is intrinsic to big IT, so HP & IBM need broader security strategies and capabilities. McAfee was a logical play for either to drive a broad security platform through a global, huge, highly trusted distribution channel (that already sells to the same customers, unlike Intel’s). We’ve all been hearing rumors about McAfee getting acquired for a while, so I’m sure both IBM and HP took long hard looks at McAfee. But they probably couldn’t justify a 60% premium. McAfee customers are fine – for the time being. McAfee will run standalone for the foreseeable future, though you have to wonder about McAfee’s ability to be as acquisitive and nimble as they’ve been. But there is always a focus issue during integration, and there will be the inevitable brain drain.

A few moments ago Mike posted his take on the McAfee/Intel acquisition, and for the most part I agree with him. “For the most part” is my nice way of saying I think Mike nailed the surface but missed some of the depths. Despite what they try to teach you in business school (not that I went to one), acquisitions, even among Very Big Companies, don’t always make sense. Often they are as much about emotion and groupthink as logic. Looking at Intel and McAfee I can see a way this deal makes sense, but I see some obstacles to making this work, and suspect they will materially reduce the value Intel can realize from this acquisition. Intel wants to acquire McAfee for three primary reasons: The name: Yes, they could have bought some dinky startup or even a mid-sized firm for a fraction of what they paid for McAfee, but no one would know who they were. Within the security world there are a handful or two of household names; but when you span government, business, and consumers the only names are the guys that sell the most cardboard boxes at Costco and Wal-Mart: Synamtec and McAfee. If they want to market themselves as having a secure platform to the widest audience possible, only those two names bring instant recognition and trust. It doesn’t even matter what the product does. Trust me, RSA wouldn’t have gotten nearly the valuation they did in the EMC deal if it weren’t for the brand name and its penetration among enterprise buyers. And keep in mind that the US federal government basically only runs McAfee and Symantec on endpoints… which is, I suspect, another important factor. If you want to break into the soda game and have the cash, you buy Coke or Pepsi – not Shasta. Virtualization and cloud computing: There are some very significant long term issues with assuring the security of the hardware/software interface in cloud computing. Q: How can you secure and monitor a hypervisor with other software running on the same hardware? A: You can’t. How do you know your VM is even booting within a trusted environment? Intel has been working on these problems for years and announced partnerships years ago with McAfee, Symantec, and other security vendors. Now Intel can sell their chips and boards with a McAfee logo on them – but customers were always going to get the tools, so it’s not clear the deal really provides value here. Mobile computing: Meaning mobile phones, not laptops. There are billions more of these devices in the world than general purpose computers, and opportunities to embed more security into the platforms. Now here’s why I don’t think Intel will ever see the full value they hope for: Symantec, EMC/RSA, and other security vendors will fight this tooth and nail. They need assurances that they will have the same access to platforms from the biggest chipmaker on the planet. A lot of tech lawyers are about to get new BMWs. Maybe even a Tesla or two in eco-conscious states. If they have to keep the platform open to competitors (and they will), then bundling is limited and will be closely monitored by the competition and governments – this isn’t only a U.S. issue. On the mobile side, as Andrew Jaquith explained so well, Apple/RIM/Microsoft control the platform and the security, not chipmakers. McAfee will still be the third party on those platforms, selling software, but consumers won’t be looking for the little logo on the phone if they either think it’s secure, it comes with a yellow logo, or they know they can install whatever they want later. There’s one final angle I’m not as sure about – systems management. Maybe Intel really does want to get into the software game and increase revenue. Certainly McAfee E-Policy Orchestrator is capable of growing past security and into general management. The “green PC” language in their release and call hints in that direction, but I’m just not sure how much of a factor it is. The major value in this deal is that Intel just branded themselves a security company across all market segments – consumer, government, and corporate. But in terms of increasing sales or grabbing full control over platform security (which would enable them to charge a premium), I don’t think this will work out. The good news is that while I don’t think Intell will see the returns they want, I also don’t think this will hurt customers. Much of the integration was in process already (as it is with other McAfee competitors), and McAfee will probably otherwise run independently. Unlike a small vendor, they are big enough and differentiated enough from the rest of Intel to survive. Probably. Share: