Research

I just posted an article on iOS (iPhone/iPad) security that I’ve been thinking about for a while over at TidBITS. Here are excerpts from the beginning and ending: One of the most controversial debates in the security world has long been the role of market share. Are Macs safer because there are fewer users, making them less attractive to serious cyber-criminals? Although Mac market share continues to increase slowly, the answer remains elusive. But it’s more likely that we’ll see the answer in our pockets, not on our desktops. The iPhone is arguably the most popular phone series on the face of the planet. Include the other iOS devices – the iPad and iPod touch – and Apple becomes one of the most powerful mobile device manufacturers, with over 100 million devices sold so far. Since there are vastly more mobile phones in the world than computers, and since that disparity continues to grow, the iOS devices become far more significant in the big security picture than Macs. … Security Wins, For Now – In the overall equation of security risks versus advantages, Apple’s iOS devices are in a strong position. The fundamental security of the platform is well designed, even if there is room for improvement. The skill level required to create significant exploits for the platform is much higher than that needed to attack the Mac, even though there is more motivation for the bad guys. Although there have been some calls to open up the platform to additional security software like antivirus tools (mostly from antivirus vendors), I’d rather see Apple continue to tighten down the screws and rely more on a closed system, faster patching rate, and more sandboxing. Their greatest opportunities for improvement lie with increased awareness, faster response (processes), and greater realization of the potential implications of security exposures. And even if Apple doesn’t get the message now, they certainly will the first time there is a widespread attack. Share:

In our last use case we presented an architecture for securely managing credit card numbers in-house. But in response to a mix of breaches and PCI requirements, some payment processors now offer tokenization as a service. Merchants can subscribe in order to avoid any need to store credit cards in their environment – instead the payment processor provides them with tokens as part of the transaction process. It’s an interesting approach, which can almost completely remove the PAN (Primary Account Number) from your environment. The trade-off is that this closely ties you to your processor, and requires you to use only their approved (and usually provided) hardware and software. You reduce risk by removing credit card data entirely from your organization, at a cost in flexibility and (probably) higher switching costs. Many major processors have built end-to-end solutions using tokenization, encryption, or a combination the two. For our example we will focus on tokenization within a fairly standard Point of Sale (PoS) terminal architecture, such as we see in many retail environments. First a little bit on the merchant architecture, which includes three components: Point of Sale terminals for swiping credit cards. A processing application for managing transactions. A database for storing transaction information. Traditionally, a customer swipes a credit card at the PoS terminal, which then communicates with an on-premise server, that then connects either to a central processing server (for payment authorization or batch clearing) in the merchant’s environment, or directly to the payment processor. Transaction information, including the PAN, is stored on the on-premise and/or central server. PCI-compliant configurations encrypt the PAN data in the local and central databases, as well as all communications. When tokenization is implement by the payment processor, the process changes to: Retail customer swipes the credit card at the PoS. The PoS encrypts the PAN with the public key of the payment processor’s tokenization server. The transaction information (including the PAN, other magnetic stripe data, the transaction amount, and the merchant ID) are transmitted to the payment processor (encrypted). The payment processor’s tokenization server decrypts the PAN and generates a token. If this PAN is already in the token database, they can either reuse the existing token (multi-use), or generate a new token specific to this transaction (single-use). Multi-use tokens may be shared amongst different vendors. The token, PAN data, and possibly merchant ID are stored in the tokenization database. The PAN is used by the payment processor’s transaction systems for authorization and charge submission to the issuing bank. The token is returned to the merchant’s local and/or central payment systems, as is the transaction approval/denial, which hands it off to the PoS terminal. The merchant stores the token with the transaction information in their systems/databases. For the subscribing merchant, future requests for settlement and reconciliation to the payment processor reference the token. The key here is that the PAN is encrypted at the point of collection, and in a properly-implemented system is never again in the merchant’s environment. The merchant never again has the PAN – they simply use the token in any case where the PAN would have been used previously, such as processing refunds.This is a fairly new approach and different providers use different options, but the fundamental architecture is fairly consistent.In our next example we’ll move beyond credit cards and show how to use tokenization to protect other private data within your environment. Share:

This hit Slashdot today, and I expect the mainstream press to pick it up fairly soon. Chris Paget will be intercepting cell phone communications at Defcon during a live demonstration. I suspect this may be the single most spectacular presentation during all of this year’s Defcon and Black Hat. Yes, people will be cracking SCADA and jackpotting ATMs, but nothing strikes closer to the heart than showing major insecurities with the single most influential piece of technology in society. Globally I think cell phones are even more important than television. Chris is taking some major precautions to stay out of jail. He’s working hand in hand with the Electronic Frontier Foundation on the legal side, and there will be plenty of warnings on-site and no information from any calls recorded or stored. I suspect he’s setting up a microcell under his control and intercepting communications in a man in the middle attack, but we’ll have to wait until his demo to get all the details. For years the mobile phone companies have said this kind of interception is impractical or impossible. I guess we’ll all find out this weekend… Share:

Our last post covered the core functions of the tokenization server. Today we’ll finish our discussion of token servers by covering the externals: the primary architectural models, how other applications communicate with the server(s), and supporting systems management functions. Architecture There are three basic ways to build a token server: Stand-alone token server with a supporting back-end database. Embedded/integrated within another software application. Fully implemented within a database. Most of the commercial tokenization solutions are stand-alone software applications that connect to a dedicated database for storage, with at least one vendor bundling their offering into an appliance. All the cryptographic processes are handled within the application (outside the database), and the database provides storage and supporting security functions. Token servers use standard Database Management Systems, such as Oracle and SQL Server, but locked down very tightly for security. These may be on the same physical (or virtual) system, on separate systems, or integrated into a load-balanced cluster. In this model (stand-alone server with DB back-end) the token server manages all the database tasks and communications with outside applications. Direct connections to the underlying database are restricted, and cryptographic operations occur within the tokenization server rather than the database. In an embedded configuration the tokenization software is embedded into the application and supporting database. Rather than introducing a token proxy into the workflow of credit card processing, existing application functions are modified to implement tokens. To users of the system there is very little difference in behavior between embedded token services and a stand-alone token server, but on the back end there are two significant differences. First, this deployment model usually involves some code changes to the host application to support storage and use of the tokens. Second, each token is only useful for one instance of the application. Token server code, key management, and storage of the sensitive data and tokens all occur within the application. The tightly coupled nature of this model makes it very efficient for small organizations, but does not support sharing tokens across multiple systems, and large distributed organizations may find performance inadequate. Finally, it’s technically possible to manage tokenization completely within the database without the need for external software. This option relies on stored procedures, native encryption, and carefully designed database security and access controls. Used this way, tokenization is very similar to most data masking technologies. The database automatically parses incoming queries to identify and encrypt sensitive data. The stored procedure creates a random token – usually from a sequence generator within the database – and returns the token as the result of the user query. Finally all the data is stored in a database row. Separate stored procedures are used to access encrypted data. This model was common before the advent of commercial third party tokenization tools, but has fallen into disuse due to its lack for advanced security features and failure to leverage external cryptographic libraries & key management services. There are a few more architectural considerations: External key management and cryptographic operations are typically an option with any of these architectural models. This allows you to use more-secure hardware security modules if desired. Large deployments may require synchronization of multiple token servers in different, physically dispersed data centers. This support must be a feature of the token server, and is not available in all products. We will discuss this more when we get to usage and deployment models. Even when using a stand-alone token server, you may also deploy software plug-ins to integrate and manage additional databases that connect to the token server. This doesn’t convert the database into a token server, as we described in our second option above, but supports communications for distributed systems that need access to either the token or the protected data. Integration Since tokenization must be integrated with a variety of databases and applications, there are three ways to communicate with the token server: Application API calls: Applications make direct calls to the tokenization server procedural interface. While at least one tokenization server requires applications to explicitly access the tokenization functions, this is now a rarity. Because of the complexity of the cryptographic processes and the need for precise use of the tokenization server; vendors now supply software agents, modules, or libraries to support the integration of token services. These reside on the same platform as the calling application. Rather than recoding applications to use the API directly, these supporting modules accept existing communication methods and data formats. This reduces code changes to existing applications, and provides better security – especially for application developers who are not security experts. These modules then format the data for the tokenization API calls and establish secure communications with the tokenization server. This is generally the most secure option, as the code includes any required local cryptographic functions – such as encrypting a new piece of data with the token server’s public key. Proxy Agents: Software agents that intercept database calls (for example, by replacing an ODBC or JDBC component). In this model the process or application that sends sensitive information may be entirely unaware of the token process. It sends data as it normally does, and the proxy agent intercepts the request. The agent replaces sensitive data with a token and then forwards the altered data stream. These reside on the token server or its supporting application server. This model minimizes application changes, as you only need to replace the application/database connection and the new software automatically manages tokenization. But it does create potential bottlenecks and failover issues, as it runs in-line with existing transaction processing systems. Standard database queries: The tokenization server intercepts and interprets the requests. This is potentially the least secure option, especially for ingesting content to be tokenized. While it sounds complex, there are really only two functions to implement: Send new data to be tokenized and retrieve the token. When authorized, exchange the token for the protected data. The server itself should handle pretty much everything else. Systems Management Finally, as with any

Alex Hutton has a wonderful must-read post on the Verizon security blog on Evidence Based Risk Management. Alex and I (along with others including Andrew Jaquith at Forrester, as well as Adam Shostack and Jeff Jones at Microsoft) are major proponents of improving security research and metrics to better inform the decisions we make on a day to day basis. Not just generic background data, but the kinds of numbers that can help answer questions like “Which security controls are most effective under XYZ circumstances?” You might think we already have a lot of that information, but once you dig in the scarcity of good data is shocking. For example we have theoretical models on password cracking – but absolutely no validated real-world data on how password lengths, strengths, and forced rotation correlate with the success of actual attacks. There’s a ton of anecdotal information and reports of password cracking times – especially within the penetration testing community – but I have yet to see a single large data set correlating password practices against actual exploits. I call this concept outcomes based security, which I now realize is just one aspect/subset of what Alex defines as Evidence Based Risk Management. We often compare the practice of security with the practice of medicine. Practitioners of both fields attempt to limit negative outcomes within complex systems where external agents are effectively impossible to completely control or predict. When you get down to it, doctors are biological risk managers. Both fields are also challenged by having to make critical decisions with often incomplete information. Finally, while science is technically the basis of both fields, the pace and scope of scientific information is often insufficient to completely inform decisions. My career in medicine started in 1990 when I first became certified as an EMT, and continued as I moved on to working as a full time paramedic. Because of this background, some of my early IT jobs also involved work in the medical field (including one involving Alex’s boss about 10 years ago). Early on I was introduced to the concepts of Evidence Based Medicine that Alex details in his post. The basic concept is that we should collect vast amounts of data on patients, treatments, and outcomes – and use that to feed large epidemiological studies to better inform physicians. We could, for example, see under which circumstances medication X resulted in outcome Y on a wide enough scale to account for variables such as patient age, gender, medical history, other illnesses, other medications, etc. You would probably be shocked at how little the practice of medicine is informed by hard data. For example if you ever meet a doctor who promotes holistic medicine, acupuncture, or chiropractic, they are making decisions based on anecdotes rather than scientific evidence – all those treatments have been discredited, with some minor exceptions for limited application of chiropractic… probably not what you used it for. Alex proposes an evidence-based approach – similar to the one medicine is in the midst of slowly adopting – for security. Thanks to the Verizon Data Breach Investigations Report, Trustwave’s data breach report, and little pockets of other similar information, we are slowly gaining more fundamental data to inform our security decisions. But EBRM faces the same near-crippling challenge as Evidence Based Medicine. In health care the biggest obstacle to EBM is the physicians themselves. Many rebel against the use of the electronic medical records systems needed to collect the data – sometimes for legitimate reasons like crappy software, and at other times due to a simple desire to retain direct control over information. The reason we have HIPAA isn’t to protect your health care data from a breach, but because the government had to step in and legislate that doctors must release and share your healthcare information – which they often considered their own intellectual property. Not only do many physicians oppose sharing information – at least using the required tools – but they oppose any restrictions on their personal practice of medicine. Some of this is a legitimate concern – such as insurance companies restricting treatments to save money – but in other cases they just don’t want anyone telling them what to do – even optional guidance. Medical professionals are just as subject to cognitive bias as the rest of us, and as a low-level medical provider myself I know that algorithms and checklists alone are never sufficient in managing patients – a lot of judgment is involved. But it is extremely difficult to balance personal experience and practices with evidence, especially when said evidence seems counterintuitive or conflicts with existing beliefs. We face these exact same challenges in security: Organizations and individual practitioners often oppose the collection and dissemination of the raw data (even anonymized) needed to learn from experience and advance based practices. Individual practitioners, regulatory and standards bodies, and business constituents need to be willing to adjust or override their personal beliefs in the face of hard evidence, and support evolution in security practices based on hard evidence rather than personal experience. Right now I consider the lack of data our biggest challenge, which is why we try to participate as much as possible in metrics projects, including our own. It’s also why I have an extremely strong bias towards outcome-based metrics rather than general risk/threat metrics. I’m much more interested in which controls work best under which circumstances, and how to make the implementation of said controls as effective and efficient as possible. We are at the very beginning of EBRM. Despite all our research on security tools, technologies, vulnerabilities, exploits, and processes, the practice of security cannot progress beyond the equivalent of witch doctors until we collectively unite behind information collection, sharing, and analysis as the primary sources informing our security decisions. Seriously, wouldn’t you really like to know when 90-day password rotation actually reduces risk vs. merely annoying users and wasting time? Share:

We’ve been writing a lot on tokenization as we build the content for our next white paper, and in Adrian’s response to the PCI Council’s guidance on tokenization. I want to address something that’s really been ticking me off… In our latest post in the series we described the details of token generation. One of the options, which we had to include since it’s built into many of the products, is encryption of the original value – then using the encrypted value as the token. Here’s the thing: If you encrypt the value, it’s encryption, not tokenization! Encryption obfuscates, but a token removes, the original data. Conceptually the major advantages of tokenization are: The token cannot be reversed back to the original value. The token maintains the same structure and data type as the original value. While format preserving encryption can retain the structure and data type, it’s still reversible back to the original if you have the key and algorithm. Yes, you can add per-organization salt, but this is still encryption. I can see some cases where using a hash might make sense, but only if it’s a format preserving hash. I worry that marketing is deliberately muddling the terms. Opinions? Otherwise, I declare here and now that if you are using an encrypted value and calling it a ‘token’, that is not tokenization. Share:

I’ve been living full time in Phoenix, Arizona for about 5 years now, and about 2 years part time before that. This was after spending my entire adult life in Boulder Colorado thanks to parole at the age of 18 from New Jersey. Despite still preferring the Broncos over the Cardinals, I think I’ve mostly adjusted to the change. But damn, sometimes I wonder about this place. First there’s the heat. It’s usually pretty tolerable up to about 100-105 Fahrenheit, thanks to the low humidity. When the humidity starts to creep up in the summer it leads directly to the monsoon rains which cool things down. Usually. Right now we’re hitting humidity as high as 30% with temps breaking 110F. The high this week is expected to hit 116F. We’re talking it’s so hot that the health department issued a warning that kids could get second degree burns from the pavement. The heat also seems to be frying brains a bit. First up is our politicians, who don’t seem to realize that when you claim to be the number 2 kidnapping capital in the world (totally untrue), people might not come and visit no matter how many tourism ads you fund. Then there’s my neighbor. I’m not sure exactly which neighbor, but the one that lets their dog out in the morning while the coyotes are out. I was running today when I saw the dog outside, completely unmonitored, during prime snack time. Coyotes might actually play with bigger dogs, but the little ones are pretty much yappy snausages with legs. Finally, back on crime, we find the most awesome local news crime story in history. The good news? An armed home invader was shot. The bad news? By the 3 better-armed invaders already in the home holding the family hostage. It’s like the DefCon CTF. With guns. I think it’s kind of cool I live in a state where I don’t need a gun, because if someone breaks into my home the odds are I’ll either be holed up in a trunk while my family finds ransom money, or the early bird bad guys will defend their turf and property (me and what was previously my property). On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in an article on Websense’s release of downloadable DLP. Rich and Adrian in Essentials Guide to Data Protection. Rich mentioned in Bill Brenner’s article on security terminology. Favorite Securosis Posts Adrian Lane: Tokenization Architecture: The Basics. Mike Rothman: Preliminary Results from the Data Security Survey. We still suck at sharing information, but Rich’s survey is a good start. Can’t wait to see the more detailed analysis. David Mortman: Home Business Payment Security. Rich: Color-blind Swans and Incident Response. Other Securosis Posts Simple Ideas to Start Improving the Economics of Cybersecurity. Incite 7/14/2010: Mello Yello. Top 3 Steps to Simplify DLP without Compromise. Taking the High Road. Favorite Outside Posts Adrian Lane: Core Data and Enterprise iPhone Applications. Interesting comments on iPhone/iPad data security. Mike Rothman: The exception IS the rule. Shrdlu nails it here. Read this, but only if you want to have a fighting chance at being a security professional. If you just want to whinge about how crappy life is, don’t read this. David Mortman: Network Forensics Vendors: Get in the Cloud!. Chris Pepper: Firefox security test add-on was backdoored. User/Password capture snuck into a fraudulent Mozilla plugin, which was publicly posted and downloaded – and apparently bundled in a pen-testing kit! Chris Pepper: The exception IS the rule. Shrdlu: “This IS normal, you idiot.” Project Quant Posts NSO Quant: Define Policies Sub-Process. NSO Quant: Enumerate and Scope Sub-Processes. DB Quant: Protect Metrics, Part 2, Patch 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. Top News and Posts Oracle to release 59 critical patches in security update. Is it just me, or do they have more security patches than bug fixes nowdays? Connecticut AG reaches agreement with Health Net over data breach. Visa Tokenization Recommendations (PDF). I’ll have more to say about this in a follow-up post tomorrow. Justices Uphold Sarbanes-Oxley Act. Laughably, some parties complained SOX is not being followed by foreign companies? Heck, U.S. companies don’t follow SOX! Off balance sheet assets? Synthetic CDO’s? Please, stop pretending. Alleged Russian agents used high-tech tricks. Review of how the alleged Russian spies allegedly moved data. Interesting mix of old techniques and new technologies. But as any information can be digitized, the risk of being caught is far less, and prosecution much more difficult if spy and spy-handler are never in the same place. Microsoft opens center to report identity theft data repositories. A great idea. Talk on Chinese cyber armies pulled from Black Hat. Due to pressure on the presenter from the Taiwanese government. Large number of attacks using the Windows 0day dropped by a Google employee. Microsoft issues final security patches for Windows XP SP2 and Windows 2K. 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 Jesse Krembs, in response to Simple Ideas to Start Improving the Economics of Cybersecurity. Having incident response costs borne by the the business unit that is breached/responsible seems like a great idea. Tying it to performance bonuses seems like an idea worth exploring as well. Maybe a little $$$ motivation for stopping people in the hall who don’t have there badge for example. It makes me think that security groups inside a company should act in a consultant/regulator roll. Enforce a minimum rule set, that each department must live up to. Sell added security to departments as needed/affordable. Figuring out how to tie the money to security performance without rolling a giant FUD ball is key and difficult. Share:

Today Howard Schmidt meets with Secretary of Commerce Gary Locke and Department of Homeland Security Secretary Janet Napolitano to discuss ideas for changing the economics of cybersecurity. Howard knows his stuff, and recognizes that this isn’t a technology problem, nor something that can be improved with some new security standard or checklist. Crime is a function of economics, and electronic crime is no exception. I spend a lot of time thinking about these issues, and here are a few simple suggestions to get us started: Eliminate the use of Social Security Numbers as the primary identifier for our credit history and to financial accounts. Phase the change in over time. When the banks all scream, ask them how they do it in Europe and other regions. Enforce a shared-costs model for credit card brands. Right now, banks and merchants carry nearly all the financial costs associated with credit card fraud. Although PCI is helping, it doesn’t address the fundamental weaknesses of the current magnetic stripe based system. Having the card brands share in losses will increase their motivation to increase the pace of innovation for card security. Require banks to extend the window of protection for fraudulent transactions on consumer and business bank accounts. Rather than forcing some series of fraud detection or verification requirements, making them extend the window where consumers and businesses aren’t liable for losses will motivate them to make the structural changes themselves. For example, by requiring transaction confirmation for ACH transfers over a certain amount. Within the government, require agencies to pay for incident response costs associated with cybercrime at the business unit level, instead of allowing it to be a shared cost borne by IT and security. This will motivate individual units to better prioritize security, since the money will come out of their own budgets instead of being funded by IT, which doesn’t have operational control of business decisions. Just a few quick ideas to get us started. All of them are focused on changing the economics, leaving the technical and process details to work themselves out. There are two big gaps that aren’t addressed here: Critical infrastructure/SCADA: I think this is an area where we will need to require prescriptive controls (air gaps & virtual air gaps) in regulation, with penalties. Since that isn’t a pure economic incentive, I didn’t include it above. Corporate intellectual property: There isn’t much the government can do here, although companies can adopt the practice of having business units pay for incident response costs (no, I don’t think I’ll live to see that day). Any other ideas? Share:

Fundamentally, tokenization is fairly simple. You are merely substituting a marker of limited value for something of greater value. The token isn’t completely valueless – it is important within its application environment – but that value is limited to the environment, or even a subset of that environment. Think of a subway token or a gift card. You use cash to purchase the token or card, which then has value in the subway system or a retail outlet. That token has a one to one relationship with the cash used to purchase it (usually), but it’s only usable on that subway or in that retail outlet. It still has value, we’ve just restricted where it has value. Tokenization in applications and databases does the same thing. We take a generally useful piece of data, like a credit card or Social Security Number, and convert it to a local token that’s useless outside the application environment designed to accept it. Someone might be able to use the token within your environment if they completely exploit your application, but they can’t then use that token anywhere else. In practical terms, this not only significantly reduces risks, but also (potentially) the scope of any compliance requirements around the sensitive data. Here’s how it works in the most basic architecture: Your application collects or generates a piece of sensitive data. The data is immediately sent to the tokenization server – it is not stored locally. The tokenization server generates the random (or semi-random) token. The sensitive value and the token are stored in a highly-secured and restricted database (usually encrypted). The tokenization server returns the token to your application. The application stores the token, rather than the original value. The token is used for most transactions with the application. When the sensitive value is needed, an authorized application or user can request it. The value is never stored in any local databases, and in most cases access is highly restricted. This dramatically limits potential exposure. For this to work, you need to ensure a few things: That there is no way to reproduce the original data without the tokenization server. This is different than encryption, where you can use a key and the encryption algorithm to recover the value from anywhere. All communications are encrypted. The application never stores the sensitive value, only the token. Ideally your application never even touches the original value – as we will discuss later, there are architectures and deployment options to split responsibilities; for example, having a non-user-accessible transaction system with access to the sensitive data separate from the customer facing side. You can have one system collect the data and send it to the tokenization server, another handle day to day customer interactions, and a third for handling transactions where the real value is needed. The tokenization server and database are highly secure. Modern implementations are far more complex and effective than a locked down database with both values stored in a table. In our next posts we will expand on this model to show the architectural options, and dig into the technology itself. We’ll show you how tokens are generated, applications connected, and data stored securely; and how to make this work in complex distributed application environments. But in the end it all comes down to the basics – take something of wide value and replacing it with a token with restricted value. Understanding and Selecting a Tokenization Solution: Part 1, Introduction Part 2, Business Justification Share:

We’ve seen an absolutely tremendous response to the data security survey we launched last month. As I write this we are up to 1,154 responses, with over 70% of respondents completing the entire survey. Aside from the people who took the survey, we also received some great help building the survey in the first place (especially from the Security Metrics community). I’m really loving this entire open research thing. We’re going to close the survey soon, and the analysis will probably take me a couple weeks (especially since my statistics skills are pretty rudimentary). But since we have so much good data, rather than waiting until I can complete the full analysis I thought it would be nice to get some preliminary results out there. First, the caveats. Here’s what I mean by preliminary: These are raw results right out of SurveyMonkey. I have not performed any deeper analysis on them, such as validating responses, statistical analysis, normalization, etc. Later analysis will certainly change the results, and don’t take these as anything more than an early peek. Got it? I know this data is dirty, but it’s still interesting enough that I feel comfortable putting it out there. And now to some of the results: Demographics We had a pretty even spread of organization sizes: Organization size Less than 100 101-1000 1001-10000 10001-50000 More than 50000 Response Count Number of employees/users 20.3% (232) 23.0% (263) 26.4% (302) 17.2% (197) 13.2% (151) 1,145 Number of managed desktops 25.8% (287) 26.9% (299) 16.4% (183) 10.2% (114) 1,113 36% of respondents have 1-5 IT staff dedicated to data security, while 30% don’t have anyone assigned to the job (this is about what I expected, based on my client interactions). The top verticals represented were retail and commercial financial services, government, and technology. 54% of respondents identified themselves as being security management or professionals, with 44% identifying themselves as general IT management or practitioners. 53% of respondents need to comply with PCI, 48% with HIPAA/HITECH, and 38% with breach notification laws (seems low to me). Overall it is a pretty broad spread of responses, and I’m looking forward to digging in and slicing some of these answers by vertical and organization size. Incidents Before digging in, first a major design flaw in the survey. I didn’t allow people to select “none” as an option for the number of incidents. Thus “none” and “don’t know” are combined together, based on the comments people left on the questions. Considering how many people reviewed this before we opened it, this shows how easy it is to miss something obvious. On average, across major and minor breaches and accidental disclosures, only 20-30% of respondents were aware of breaches. External breaches were only slightly higher than internal breaches, with accidental disclosures at the top of the list. The numbers are so close that they will likely be within the margin of error after I clean them. This is true for major and minor breaches. Accidental disclosures were more likely to be reported for regulated data and PII than IP loss. 54% of respondents reported they had “About the same” number of breaches year over year, but 14% reported “A few less” and 18% “Many less”! I can’t wait to cross-tabulate that with specific security controls. Security Control Effectiveness This is the meat of the survey. We asked about effectiveness for reducing number of breaches, severity of breaches, and costs of compliance. The most commonly deployed tools (of the ones we surveyed) are email filtering, access management, network segregation, and server/endpoint hardening. Of the data-security-specific technologies, web application firewalls, database activity monitoring, full drive encryption, backup tape encryption, and database encryption are most commonly deployed. The most common write-in security control was user awareness. The top 5 security controls for reducing the number of data breaches were DLP, Enterprise DRM, email filtering, a content discovery process, and entitlement management. I combined the three DLP options (network, endpoint, and storage) since all made the cut, although storage was at the bottom of the list by a large margin. EDRM rated highly, but was the least used technology. For reducing compliance costs, the top 5 rated security controls were Enterprise DRM, DLP, entitlement management, data masking, and a content discovery process. What’s really interesting is that when we asked people to stack rank their top 3 most effective overall data security controls, the results don’t match our per-control questions. The list then becomes: Access Management Server/endpoint hardening Email filtering My initial analysis is that in the first questions we focused on a set of data security controls that aren’t necessarily widely used and compared between them. In the top-3 question, participants were allowed to select any control on the list, and the mere act of limiting themselves to the ones they deployed skewed the results. Can’t wait to do the filtering on this one. We also asked people to rank their single least effective data security control. The top (well, bottom) 3 were: Email filtering USB/portable media encryption or device control Content discovery process Again, these correlate with what is most commonly being used, so no surprise. That’s why these are preliminary results – there is a lot of filtering/correlation I need to do. Security Control Deployment Aside from the most commonly deployed controls we mentioned above, we also asked why people deployed different tools/processes. Answers ranged from compliance, to breach response, to improving security, and reducing costs. No control was primarily deployed to reduce costs. The closest was email filtering, at 8.5% of responses. The top 5 controls most often reported as being implemented due to a direct compliance requirement were server/endpoint hardening, access management, full drive encryption, network segregation, and backup tape encryption. The top 5 controls most often reported as implemented due to an audit deficiency are access management, database activity monitoring, data masking, full drive encryption, and server/endpoint hardening. The top 5 controls implemented for cost savings were reported as email filtering, server/endpoint hardening, access management, DLP, and