Research

Reality has a funny way of intruding into the best laid plans. Some of you might have noticed I haven’t been writing that much for the past couple weeks and have been pretty much ignoring Twitter and the rest of the social media world. It seems my wife had a baby, and since this isn’t my personal blog anymore I was able to take some time off and focus on the family. Needless to say, my “paternity leave” didn’t last nearly as long as I planned, thanks to the work piling up. And it explains why this may be showing up in your inbox on Saturday, for those of you getting the email version. Which brings me to my next point, one we could use a little feedback on. If you look at the blog this week we hit about 20 posts… many of them in-depth research to support our various projects. I’m starting to wonder if we are overwhelming people a little? As the blogging community has declined we spend less time with informal commentary and inter-blog discussions, and more time just banging out research. As a ‘research’ company, it isn’t like we won’t publish the harder stuff, but I want to make sure we aren’t losing people in the process like that boring professor everyone really respects, but who has to slam a book on the desk at the end of class to let everyone know they can go. Finally, this week it was cool to ship out the iPad for the winning participant in the 2010 Data Security Survey. When I contacted him he asked, “Is this some phishing trick?”, but I managed to still get his mailing address and phone number after a few emails. Which is cool, because now I have a new bank account with better credit, and it looks like his is good enough for the mortgage application. (But seriously, he wanted one & didn’t have one, and it was really nice to send it to someone who appreciated it). On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences SIEM In The Spotlight with ArcSight Acquisition. HP to buy ArcSight for $1.5 billion. Favorite Securosis Posts Adrian Lane: NSO Quant: Monitor Metrics – Analyze. Definitely correlate. Ten minutes to Wapner. Mike Rothman: Monitoring up the Stack: Introduction. We’re starting another research project, pushing forward on our Monitor Everything philosophy. Keep an eye on this one – it’s going to be great. Rich: HP Sets its Arcsights on Security. Mike’s analysis of the HP/Arcsight deal, which tells you whether and why this matters. Other Securosis Posts The Securosis 2010 Data Security Survey Report Rates the Top 5 Data Security Controls. Incite 9/15/2010: Up, down, up, down, Repeat. FireStarter: Automating Secure Software Development. Understanding and Selecting an Enterprise Firewall Deployment Considerations. Management. Advanced Features, Part 1. Advanced Features, Part 2. To UTM or Not to UTM? DLP Selection Process Step 1. Defining the Content. Protection Requirements. Infrastructure Integration Requirements. Favorite Outside Posts Pepper: DRG SSH Username and Password Authentication Tag Clouds. Nice rendering of human nature (you can call it laziness or stupidity, as you prefer). Adrian Lane: Gift Card FAIL. Gift cards seemed designed to be scammed. Does the bank ever lose, or only merchants? Something to think about. Mike Rothman: Evil WiFi – Captive Portal Edition. Ax0n provides very detailed instructions on building your own Evil WiFi kit. For research purposes, of course… David Mortman: Security Planning – who watches the watchers?. It’s almost but not quite Banksy. Rich: Want to know if your app (especially Adobe Reader) is using unsafe functions? Errata has an app for that. Project Quant Posts NSO Quant: Monitor Metrics – Validate and Escalate. NSO Quant: Monitor Metrics – Analyze. NSO Quant: Monitor Metrics – Collect and Store. NSO Quant: Monitor Metrics – Define Policies. NSO Quant: Monitor Metrics – Enumerate and Scope. Research Reports and Presentations Security + Agile = FAIL Presentation. Data Encryption 101: A Pragmatic Approach to PCI. White Paper: Understanding and Selecting SIEM/Log Management. White Paper: Endpoint Security Fundamentals. Top News and Posts Flash Flaw Puts Android at Risk. Web Hacking Incident Database updated. HDCP Encryption Supposedly Hacked. It’s not like you can’t reverse engineer the set top box, but the details on this will be interesting. Another Adobe Flash zero day under attack. Old-school worm making the rounds. How nostalgic. Martin: What skillz should a geek kid learn? Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Troy, in response to Tokenization Will Become the Dominant Payment Transaction Architecture. Interesting discussion. As I read the article I was also interested in the ways in which a token could be used as a ‘proxy’ for the PAN in such a system – the necessity of having the actual card number for the initial purchase seems to assuage most of that concern. Another aspect of this method that I have not seen mentioned here: if the Tokens in fact conform to the format of true PANs, won’t a DLP scan for content recognition typically ‘discover’ the Tokens as potential PANs? How would the implementing organization reliably prove the distinction, or would they simply rest on the assumption that as a matter of design any data lying around that looks like a credit card number must be a Token? I’m not sure that would cut the mustard with a PCI auditor. Seems like this could be a bit of a sticky wicket still? Troy – in this case you would use database fingerprinting/exact data matching to only look for credit card numbers in your database, or to exclude the tokens. Great question! Share:

In our last post we detailed content protection requirements, so now it’s time to close out our discussion of technical requirements with infrastructure integration. To work properly, all DLP tools need some degree of integration with your existing infrastructure. The most common integration points are: Directory servers to determine users and build user, role, and business unit policies. At minimum, you need to know who to investigate when you receive an alert. DHCP servers so you can correlate IP addresses with users. You don’t need this if all you are looking at is email or endpoints, but for any other network monitoring it’s critical. SMTP gateway this can be as simple as adding your DLP tool as another hop in the MTA chain, but could also be more involved. Perimeter router/firewall for passive network monitoring you need someplace to position the DLP sensor – typically a SPAN or mirror port, as we discussed earlier. Web gateway will probably integrate with your DLP system if you want to on filtering web traffic with DLP policies. If you want to monitor SSL traffic (you do!), you’ll need to integrate with something capable of serving as a reverse proxy (man in the middle). Storage platforms to install client software to integrate with your storage repositories, rather than relying purely on remote network/file share scanning. Endpoint platforms must be compatible to accept the endpoint DLP agent. You may also want to use an existing software distribution tool to deploy the it. I don’t mean to make this sound overly complex – many DLP deployments only integrate with a few of these infrastructure components, or the functionality is included within the DLP product. Integration might be as simple as dropping a DLP server on a SPAN port, pointing it at your directory server, and adding it into the email MTA chain. But for developing requirements, it’s better to over-plan than miss a crucial piece that blocks expansion later. Finally, if you plan on deploying any database or document based policies, fill out the storage section of the table. Even if you don’t plan to scan your storage repositories, you’ll be using them to build partial document matching and database fingerprinting policies. Share:

Over the summer we initiated what turned out to be a pretty darn big data security survey. Our primary goal was to assess what data security controls people find most effective; and get a better understanding of how they are using the controls, what’s driving adoption, and a bit on what kinds of incidents they are experiencing. The response was overwhelming – we had over 1,100 people participate from across the IT spectrum. The responses were almost evenly split between security and regular IT folks, which helps reduce some of the response bias: I try to be self critical, and there were definitely some mistakes in how we designed the survey (although the design process was open to the public and available for review before we launched, so I do get to blame all you a bit too, for letting me screw up). But despite those flaws I think we still obtained some great data – especially on what controls people consider effective (and not), and how you are using them. Due to an error on my part we can’t release the full report here at Securosis for 30 days, but it is available from our sponsor, Imperva, who is also re-posting the survey so those of you who haven’t taken it yet can run through the questions and compare yourselves to the rest of the responses. We will also be releasing the full (anonymized) raw data so you can perform your own analysis. Everything is free under a Creative Commons license. I apologize for not being able to release the report immediately as usual – it was a mistake on my part and won’t happen again. Key Findings We received over 1,100 responses with a completion rate of over 70%, representing all major vertical markets and company sizes. On average, most data security controls are in at least some stage of deployment in 50% of responding organizations. Deployed controls tend to have been in use for 2 years or more. Most responding organizations still rely heavily on “traditional” security controls such as system hardening, email filtering, access management, and network segregation to protect data. When deployed, 40-50% of participants rate most data security controls as completely eliminating or significantly reducing security incident occurrence. The same controls rated slightly lower for reducing incident severity (when incidents occur), and still lower for reducing compliance costs. 88% of survey participants must meet at least 1 regulatory or contractual compliance requirement, with many needing to comply with multiple regulations. Despite this, “to improve security” is the most cited primary driver for deploying data security controls, followed by direct compliance requirements and audit deficiencies. 46% of participants reported about the same number of security incidents in the most recent 12 months compared to the previous 12, with 27% reporting fewer incidents, and only 12% reporting a relative increase. Organizations are most likely to deploy USB/portable media encryption and device control or data loss prevention in the next 12 months. Email filtering is the single most commonly used control, and the one cited as least effective. Our overall conclusion is that even accounting for potential response bias, data security has transitioned past early adopters and significantly penetrated the early mainstream of the security industry. Top Rated Controls (Perceived Effectiveness): The 5 top rated controls for reducing number of incidents are network data loss prevention, full drive encryption, web application firewalls, server/endpoint hardening, and endpoint data loss prevention. The 5 top rated controls for reducing incident severity are network data loss prevention, full drive encryption, endpoint data loss prevention, email filtering, and USB/portable media encryption and device control. (Web application firewalls nearly tied, and almost made the top 5). The 5 top rated controls for reducing compliance costs are network data loss prevention, endpoint data loss prevention, storage data loss prevention, full drive encryption, and USB and portable media encryption and device control. These were very closely followed by network segregation and access management. We’ll be logging more findings throughout the week, and please visit Imperva to get your own copy of the full analysis. Share:

Now that you’ve figured out what information you want to protect, it’s time to figure out how to protect it. In this step we’ll figure out your high-level monitoring and enforcement requirements. Determine Monitoring/Alerting Requirements Start by figuring out where you want to monitor your information: which network channels, storage platforms, and endpoint functions. Your high-level options are: Network Email Webmail HTTP/FTP HTTPS IM/Messaging Generic TCP/IP Storage File Shares Document Management Systems Databases Endpoint Local Storage Portable Storage Network Communications Cut/Paste Print/Fax Screenshots Application Control You might have some additional requirements, but these are the most common ones we encounter. Determine Enforcement Requirements As we’ve discussed in other posts, most DLP tools include various enforcement actions, which tend to vary by channel/platform. The most basic enforcement option is “Block” – the activity is stopped when a policy violation is detected. For example, an email will be filtered, a file not transferred to a USB drive, or an HTTP URL will fail. But most products also include other options, such as: Encrypt: Encrypt the file or email before allowing it to be sent/stored. Quarantine: Move the email or file into a quarantine queue for approval. Shadow: Allow a file to be moved to USB storage, but send a protected copy to the DLP server for later analysis. Justify: Warn the user that this action may violate policy, and require them to enter a business justification to store with the incident alert on the DLP server. Change rights: Add or change Digital Rights Management on the file. Change permissions: Alter the file permissions. Map Content Analysis Techniques to Monitoring/Protection Requirements DLP products vary in which policies they can enforce on which locations, channels, and platforms. Most often we see limitations on the types or size of policies that can be enforced on an endpoint, which change based as the endpoint moves off or onto the corporate network, because some require communication with the central DLP server. For the final step in this part of the process, list your content analysis requirements for each monitoring/protection requirement you just defined. These tables directly translate to the RFP requirements that are at the core of most DLP projects: what you want to protect, where you need to protect it, and how. Share:

In our last post we kicked off the DLP selection process by putting the team together. Once you have them in place, it’s time to figure out which information you want to protect. This is extremely important, as it defines which content analysis techniques you require, which is at the core of DLP functionality. This multistep process starts with figuring out your data priorities and ends with your content analysis requirements: Stack rank your data protection priorities The first step is to list our which major categories of data/content/information you want to protect. While it’s important to be specific enough for planning purposes, it’s okay to stay fairly high-level. Definitions such as “PCI data”, “engineering plans”, and “customer lists” are good. Overly general categories like “corporate sensitive data” and “classified material” are insufficient – too generic, and they cannot be mapped to specific data types. This list must be prioritized; one good way of developing the ranking is to pull the business unit representatives together and force them to sort and agree to the priorities, rather than having someone who isn’t directly responsible (such as IT or security) determine the ranking. Define the data type For each category of content listed in the first step, define the data type, so you can map it to your content analysis requirements: Structured or patterned data is content like credit card numbers, Social Security Numbers, and account numbers – that follows a defined pattern we can test against. Known text is unstructured content, typically found in documents, where we know the source and want to protect that specific information. Examples are engineering plans, source code, corporate financials, and customer lists. Images and binaries are non-text files such as music, video, photos, and compiled application code. Conceptual text is information that doesn’t come from an authoritative source like a document repository but may contain certain keywords, phrases, or language patterns. This is pretty broad but some examples are insider trading, job seeking, and sexual harassment. Match data types to required content analysis techniques Using the flowchart below, determine required content analysis techniques based on data types and other environmental factors, such as the existence of authoritative sources. This chart doesn’t account for every possibility but is a good starting point and should define the high-level requirements for a majority of situations. Determine additional requirements Depending on the content analysis technique there may be additional requirements, such as support for specific database platforms and document management systems. If you are considering database fingerprinting, also determine whether you can work against live data in a production system, or will rely on data extracts (database dumps to reduce performance overhead on the production system). Define rollout phases While we haven’t yet defined formal project phases, you should have an idea early on whether a data protection requirement is immediate or something you can roll out later in the project. One reason for including this is that many DLP projects are initiated based on some sort of breach or compliance deficiency relating to only a single data type. This could lead to selecting a product based only on that requirement, which might entail problematic limitations down the road as you expand your deployment to protect other kinds of content. Share:

As I mentioned previously, I’m working on an update to Understanding and Selecting a DLP Solution. While much of the paper still stands, one area I’m adding a bunch of content to is the selection process. I decided to buff it up with more details, and also put together a selection worksheet to help people figure out their requirements. This isn’t an RFP, but a checklist to help you figure out major requirements – which you will use to build your RFP – and manage the selection process. The first step, and this post, are fairly short and simple: Define the Selection Team Identify business units that need to be involved and create a selection committee. We tend to include two kinds of business units in the DLP selection process: content owners with sensitive data to protect, and content protectors with responsibility for enforcing controls over the data. Content owners include business units that hold and use the data. Content protectors tend to include departments like Human Resources, IT Security, Corporate Legal, Compliance, and Risk Management. Once you identify the major stakeholders you’ll want to bring them together for the next few steps. This list covers a superset of the people who tend to be involved with selection (BU stands for “Business Unit”). Depending on the size of your organization you may need more or less, and in most cases the primary selection work will be done by 2-3 IT and IT security staff, but we suggest you include this larger list in the initial requirements generation process. The members of this team will also help obtain sample data/content for content analysis testing, and provide feedback on user interfaces and workflow if they will eventually be users of the product. Share:

Back when I started Securosis my first white paper was Understanding and Selecting a DLP Solution. It has been downloaded many thousands of times (about 400 times a month for the first couple years), and I still see it showing up all the time when I talk with clients. (Some people call it the DLP Bible, but if I said that it would be really pretentious). Although the paper is still accurate, it’s time for an update. Over the next month I’ll be putting together the new revision of the paper and I want to make sure it reflects what you all need. My plans right now are to: Update the technology details. While there haven’t been any major shifts, we’ve definitely seen some useful new features and functions to consider when looking for a tool. Update the section on DLP as a Feature. The current paper focuses almost completely on full-suite solutions. While that’s still the option I usually recommend, I know some of you are only looking for coverage in a particular area. I plan to add a new section so you understand how the single channel or DLP features of other security tools work. Updated selection process. This is where I plan on putting most of myt effort… I’ll be creating a decision tree to help you prioritize your process. This section will also be released as a worksheet you can use during your selection process. It won’t name solutions, but will walk you through, and help you figure out your priorities and how those translate to technology decisions. Prettier pictures. But these are just my early ideas. If you have anything specific you want covered, feedback on the first version of the paper, or any other feedback on DLP, please let me know. You can drop it in the comments here or email me directly at rmogull@securosis.com. Also, although I’ll still follow our Totally Transparent Research process, it doesn’t make sense to post copy edits and tweaks as blog posts. I’ll post new sections and some major edits, but you’ll have to read the paper for the rest. Share:

This is one of those posts I’ve been thinking about writing for a while – ever since I saw one of those dumb-ass ADT commercials with the guy with the black knit cap breaking in through the front door while some ‘helpless’ woman was in the kitchen. I’m definitely no home-alarm security expert, but being a geek I really dug into the design and technology when I purchased systems for the two homes I’ve lived in here in Phoenix. We’re in a nice area, but home break-ins are a bit more common here than in Boulder. In one home I added an aftermarket system, and in the other we had it wired as the house was built. Here are some things to keep in mind: If you purchase an aftermarket system it will almost always be wireless, unless you want to rip your walls open. These systems can be attacked via timing and jamming, but most people don’t need to worry about that. With a wireless system you have a visible box on each door and window covered. An attacker can almost always see these, so make sure you don’t skip any. Standard door and window sensors are magnetic contact closure sensors. They only trigger if the magnet and the sensor are separated, which means they won’t detect the bad guy breaking the glass if the sensor doesn’t separate. You know, like they show in all those commercials (for the record I use ADT). The same is true for wired sensors, except they aren’t as visible. Unless you pay extra, all systems use your existing phone line with a special “capture” port that overrides other calls when the alarm needs it. For (possibly a lot) more you can get a dedicated cell phone line integrated into the alarm, so the call center still gets the alarm even if the phone lines are down. You probably want to make sure they aren’t on AT&T. Most of the cheap alarm deals only give you a certain number of contact closure sensors and one “pet immune” motion sensor (placed centrally to trigger when someone walks down your major connecting hallway). Pay more to get all your first floor doors and windows covered. Get used to the ugly white boxes on everything. Most alarm systems do not cover your exterior garage doors. The standard install protocol is to put a sensor on the door from your garage to the interior of the house. The only time we’ve been robbed is when we left our garage doors open, so since then we’ve always had them added to the system. They take a special contact closure sensor since the normal ones aren’t good with the standard rattling of a garage door and will trigger with the wind. Now every night when we set our alarm in “Stay” mode it won’t enable unless the doors are closed. None of the basic systems includes a glass break detector. Most of these are noise sensors tuned to the frequency of glass breaking, rather than shatter sensors attached to each window. I highly suggest these and recommend you put them near the windows most likely to be broken into (ones hard to see from the street). Mine has only gone off once, when I dropped something down the stairs. Understand which sensors are active in the two primary alarm modes – Stay and Away. Stay is the mode you use at night when you are sleeping (or if you are a helpless female in the kitchen in an ADT commercial). It usually arms the exterior sensors but not the motion sensor. Away is when you are out and turns on everything. I suggest having glass breaks active in Stay mode, but if you have a killer stereo/surround sound system that might not work out too well for you. There are also differences in arming times and disarming windows (the time from opening a door to entering your code). When your alarm triggers it starts a call to the call center, who will call you back and then call the police. I’ve had my alarm going for a good 30 seconds without the outbound call hitting the alarm center. It isn’t like TV, and the cops won’t be showing up right away. Most basic systems don’t cover the second story in a multilevel home. While few bad guys will use a ladder, know your home and if there are areas they can climb to easily using trees, gutters, etc. – such as windows over a low roof. Make sure you alarm these. Especially if you have daughters and want some control over their dating lives. Most systems come with key fob remotes, so you don’t have to mess with the panel when you are going in and out. If you’re one of those people who parks in your driveway and leaves your garage and alarm remotes in the car, please send me your address and a list of your valuables. Extra points if you’re a Foursquare user. Most alarms don’t come with a smoke detector, which is one of the most valuable components of the system. You regular detectors aren’t wired into an alarm sensor and are just to wake you up. Since we have pets, and mostly like them, we have a smoke detector in a central location as part of our alarm so the fire department will show up even if we aren’t around. We also have a residential sprinkler system, and as a former firefighter those things are FTW (no known deaths due to fire when one is installed and operational). My alarm guys looked at me funny when I designed the system since it included extras they normally skip (garage doors, glass break, second story coverage, smoke detector). But we have a system that didn’t cost much more than the usual cheap ones, and provides much better protection. It’s also more useful, especially with the garage sensors to help make sure we don’t leave the doors open.

My original plan for this week’s summary was to geek out a bit and talk about my home automation setup. Including the time I recently discovered that even household electrical is powerful enough to arc weld your wire strippers if you aren’t too careful. Then I read some stuff. Some really bad stuff. First up was an article in USA Today that I won’t even dignify with a link. It was on the iTunes account phishing that’s been going on, and it was pretty poorly written. Here’s a hint – if you are reading an article about a security issue and all the quotes are from a particular category of vendor, and the conclusion is to buy products made by those vendors, it’s okay to be a little skeptical. This is the second time in the past couple weeks I’ve read something by that author that suffered from the same problem. Vendor folk make fine sources – I have plenty of friends and contacts in different security companies who help me out when I need it, but the job of a journalist is to filter and balance. At least it used to be. Next up are the multitude of stories on the US Department of Defense getting infected in 2008 via USB drives. Notice I didn’t say “attacked”, because despite all the stories surfacing today it seems that this may not have been a deliberate act by a foreign power. The malware involved was pretty standard stuff – there is no need to attribute it to espionage. Now look, I don’t have any insider knowledge and maybe it was one of those cute Russian spies we deported, but this isn’t the first time we’ve seen government related stories coming from sources that might – just might – be seeking increased budget or authority. I’m really tired of a lazy press that single-sources stories and fails to actually research the issues. I know the pressure is nasty in today’s newsrooms, but there has to be a line someplace. I write for a living myself, and have some close friends in the trade press I respect a heck of a lot, so I know it’s possible to hit deadlines without sacrificing quality. But then you don’t get to put “Apple” in the title of every article to increase your page count. On another note it seems my wife is supposed to have a baby today… or sometime in the next week or two. Some of you may have noticed my posting rate is down and I’ll be in paternity leave mode. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich and Chris Hoff at RSA 2009. Video of their presentation on disruptive innovation and cloud computing. Rich quoted in Bloomberg on the Intel/McAfee deal. And also over at Forbes. Favorite Securosis Posts David Mortman: Backtalk Doublespeak on Encryption. Adrian Lane: Understanding and Selecting SIEM/Log Management. … of course. Granted it’s long, but if you are selecting a SIEM platform, this is a great primer to start the process. Mike Rothman: Data Encryption for PCI 101: Encryption Options. Really like this series because too many folks think encryption is the answer. This series tells you the question. Other Securosis Posts Starting the Understanding and Selecting an Enterprise Firewall Project. Incite 8/25/2010: Let Freedom Ring. Webcasts on Endpoint Security Fundamentals. Favorite Outside Posts David Mortman: Hoff’s 5 Rules Of Cloud Security…. Adrian Lane: Hoff’s 5 Rules Of Cloud Security…. I read this after I saw Rich’s link in this week’s Incite … and Chris has nailed it. How many of us have actually tried to set up a secure environment within Amazon Web Services? Great post. Mike Rothman: Why the USP for Every Technical Product Sounds the Same. If you think it’s hard to tell one product from another, it’s not you. This is why. And it’s sad, but really really true. Rich: Find Evil and Solve Crime. The Mandiant folks are some of the few that really fight the APT, and one of their folks is starting a series giving some insight into their process. Project Quant Posts NSO Quant: Manage IDS/IPS Process Revisited. NSO Quant: Manage IDS/IPS – Monitor Issues/Tune. Research Reports and Presentations White Paper: Understanding and Selecting SIEM/Log Management. White Paper: Endpoint Security Fundamentals. Understanding and Selecting a Database Encryption or Tokenization Solution. Top News and Posts Adobe Patches via Brian Krebs. Apple Mac OS X Security Patch. Visa Makes AppSec Recommendations. We’ll have more to say about this when we get a chance to finish reading the recommendations. Verizon Clears Credit Card Cloud Test. Yippee. Credit Cards in the cloud. And our profession needed a new place to hack credit cards to create a boost of excitement (just kidding, guys). Hey, watch where you stick that thing. You don’t know where it’s been! Researcher Arrested for Disclosure. This case is interesting for a couple different reasons. DEFCON Survey Results. Toolkit for DLL hijacking. Critical Updates for Windows, Flash Player. Apple Jailbreak Vuln. Wireshark review. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Jay, in response to Backtalk Doublespeak on Encryption. I don’t want to give this article too much attention, too much FUD, too few facts, but I thought this was worth a quote: “…the bad guys do not attack encrypted data directly…” which is followed up with: “When you encrypt a small field with a limited number of possible values, like the expiry date, you risk giving a determined (and sophisticated) attacker a potential route to compromising your entire cardholder database.” … by attacking the encrypted data directly? The other point I had was that there are 1 of 2 ways to create the same output given the same input (in “strong” symmetric ciphers), use ECB mode or re-use the same initialization vector (IV) over and over. I think most financial places lean towards the former because managing/transferring the

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: