Research

Justifying an investment in tokenization is actually two separate steps – first justifying an investment to protect the data, and then choosing to use tokenization. Covering all the justifications for protecting data is beyond the scope of this series, but a few common drivers are typical: Compliance requirements Reducing compliance costs Threat protection Risk mitigation We’ve published a full model (and worksheet) on this problem in our paper The Business Justification for Data Security. Once you’ve decided to protect the data, the next step is to pick the best method. Tokenization is designed to solve a very narrow but pervasive and critical problem: protecting discreet data fields within applications, databases, storage, and across networks. The most common use for tokenization is to protect sensitive key identifiers, such as credit card numbers, Social Security Numbers, and account numbers. Less commonly, we also see tokenization used to protect full customer/employee/personal records. The difference between the two (which we’ll delve into more in our architectural discussion) is that in the first case the tokenization server only stores the token and the sensitive field, while in the second case it includes additional data, such as names and addresses. Reasons to select tokenization include: Reduction compliance scope and costs: Since tokenization completely replaces a sensitive value with a random value, systems that use the token instead of the real value are often exempt from audits/assessments that regulations require for the original sensitive data. For example, if you replace a credit card number in your application environment with tokens, the systems using the tokens may be excluded from your PCI assessment – reducing the assessment scope and cost. Reduction of application changes: Tokenization is often used to protect sensitive data within legacy application environments where we might previously have used encryption. Tokenization allows us to protect the sensitive value with an analogue using the exact same format, which can minimize application changes. For example, encrypting a Social Security Number involves not only managing the encryption, but changing everything from form field logic to database field format requirements. Many of these changes can be avoided with tokenization, so long as the token formats and sizes match the original data. Reduction of data exposure: A key advantage of tokenization is that it requires data consolidation. Sensitive values are only stored on the tokenization server(s), where they are encrypted and highly protected. This reduces exposure over traditional encryption deployments, where cryptographic access to sensitive data tends to show up in many locations. Masking by default: Since the token value is random, it also effectively functions as a data mask. You don’t need to worry about adding masking to applications, since the real value is never exposed (the exception being where even the token value could lead to misuse within your environment). Tokenization solutions do not offer as many formatting options to preserve value for reporting and analytics, but fully tokenized solutions provide greater security and less opportunity for data leakage or reverse engineering. For the most part, the primary reason organizations select tokenization over alternatives is cost reduction: reduced costs for application changes, followed by reduced audit/assessment scope. We also see organizations select tokenization when they need to update security for large enterprise applications – as long as you have to make a lot of changes, you might as well reduce potential data exposure and minimize the need for encryption at the same time. Understanding and Selecting a Tokenization Solution: Part 1, Introduction Share:

I spent some time on the road this week, and it was great to see some old friends, meet some new ones, come up to speed on some topics, and more than anything take some time to listen. With my head full of dancing fairies relative to what’s really going on out there, I was interested when I came across Jack Freund’s post on the RiskAnalysis blog called “Executives are not Stupid.” Jack leads off the discussion by mentioned that “You don’t fall into a job to run a company or a line of business.” Actually in my experience, continually validated by my primary research, many executives are in over their heads. The Peter Principle is not only alive and well, it gets in the way of the security professional’s charter on a daily basis. Come on, don’t make like you’ve never asked yourself what kind of pictures said executive has on the CEO to keep falling upward. You know you have, and you are probably right. Success in corporate life isn’t just restricted to the talented, that’s for sure. The lore has been known for years that to be good at security you have to think like a hacker. All that really means is that you have to understand the attacker’s motivations, get familiar with the tools they use, and use that knowledge to discover the path of least resistance (which tends to be the most significant attack vector). When we recommend that you systematically hack yourself, this is really to familiarize yourself with what the attacker sees. The same goes for dealing with senior management. A lot of folks just get grumpy when a decision doesn’t go their way. They grumble about how senior management “doesn’t get it,” but in reality it’s a failure on our part to anticipate the (often obvious) reaction of the senior team. Most executives are, frankly, predictable. They act in their own best interests, always. And that means if you want to get anything done, you have to convince the executive that going down the path your suggest is in their best interest. I know, this clearly involves political machinations and that is likely deplorable to many of you. It’s not my favorite thing to do, which is why I work with Rich and Adrian. But if you want the big title (or even a little title), part of that is playing the game. So you need to plan for success. That means before you pitch a senior exec on your pet project, you need to actively plan a strategy for lining up support. It’s not that hard, but it doesn’t happen by itself. You have to sit down and understand the playing field. Start by asking yourself two questions, but you need to answer as the executive(s) rather than as yourself. And no, the questions do not include which new BMW you want or which Four Seasons you will visit on holiday. How will this make my life better? You need to have a crisp understanding of why it’s in this executive’s best interest to support your project, and that usually gets down to two things: more money or making him/her look good. If you can position your project for either of these, you have a chance. What is the risk? There is no risk without reward, so you need to really consider the downside for the executive. Where can this go wrong? How would this alienate him/her with peers or higher ups? Basically you have to build a threat model from the executive’s perspective. And you then you need to be able to overcome those objections, or he/she will kill your project. Guaranteed. Building the threat model and overcoming the objections isn’t easy, which is why so many security folks don’t get what they want. Always remember, it’s not about protection or security. It’s about understanding the goals and success criteria for your organization and every executive that can say no. I know your senior executives aren’t necessarily adversaries, but since they can get in your way and derail your plans you need to map out a strategy to bring them to your side – or at least neutralize them. And keep in mind that you will not win every battle. Sometimes they’ll still say no, regardless of your strategy or efforts. Keep each setback in context of the entire war, and move on to the next battle. Or decide it was more fun to configure firewalls. That’s always an option. Photo credit: The Peter Principle: Why Things Go Wrong available on Amazon Share:

IBM continues to be aggressive with acquisitions, grabbing BigFix today for an undisclosed amount. Given BigFix’s aspirations (they were moving toward a public offering), I’m a bit surprised the economics weren’t disclosed, but it was likely a decent sized deal. IBM and BigFix have a fairly long history of working together, and strategically this deal makes a lot of sense – especially given that IBM’s Tivoli systems management offerings weren’t very competitive on the endpoint. Once we got past the “Smarter Planet” branding hogwash on the analyst conference call, the leverage of IBM/BigFix became apparent. First, BigFix always positioned itself as a platform, driven by content and their Fixlets: applications that plug into the platform. You have to figure the IBM Global Services folks are drooling a bit to finally control an endpoint management integration platform – and the billable hours to build thousands more Fixlets. BigFix as a stand-alone company wasn’t a long-term option. Small companies don’t get to play in the platform space, not over long periods of time anyway. But hats off to the BigFix folks – they focused on bringing specific use cases to market to show the power of their platform and knock down some big enterprise deployments. On the other hand, IBM is strictly a platform player, so the idea of Big Blue rolling out a comprehensive endpoint management offering is a no-brainer. If anything, this solves a big operational problem for IBM, given their 500,000+ employees around the world (they plan to eat their own dog food with an enterprise-wide deployment) and millions of endpoints managed through their outsourcing business. From that perspective, this is very much like the HP/Opsware deal a few years ago. Yes, the deal gets justified by the big opportunity to sell the software, but the internal operational leverage of the technology is a big sweetener (and likely a deal size multiplier). Additionally, IBM needed to make a move to bolster their security product capabilities, which are getting a bit long in the tooth. They’ve seen the former ISS erode to irrelevance; they moved the ISS products into the Tivoli group, but it’s too little too late. With BigFix they ger an opportunity to bring a far more strategic offering into the bag. Symantec has this capability through their Altiris acquisition and EMC/RSA bought ConfigureSoft a while back to get better endpoint management. You have to wonder if McAfee was a player in this deal, because they’ve got a big hole in their offering around endpoint management. Customer Impact If you are a BigFix customer, you likely have mixed feelings. Now you get to deal with IBM, which can be a nightmare. And if you have a very heterogenous environment, over time that is at risk. Of course, both IBM and BigFix will maintain their commitment to supporting a heterogeneous world, but you figure IBM platforms will get priority for new features and Fixlets. That’s the way of the world. IBM outsourcing customers should be tickled. If you can get an endpoint change request through the gauntlet of change orders, contract (re)negotiations, and the other roadblocks IBM puts in your way, they’ll actually have a slick way to make the change. This also adds a number of other cool service offerings (energy management, endpoint remediation, asset management, etc.) that may actually add value to your services relationship. Imagine that. Obviously you’ll see all the competition, both big (Symantec, RSA, HP) and little (LanDesk, Lumension, Shavlik) throw some FUD (fear, uncertainty, and doubt) balloons your way during the procurement process. Clearly there will be some impact to the product roadmap, and likely support, as the newly wealthy BigFixers move on and Tivoli starts putting their imprint on company operations. If anything, you should be able to use the FUD as more leverage to get additional pricing and T&C concessions when negotiating your purchase or renewal. Issues Like any other deal, most of the risk is in integration. Can IBM maintain the people and continue to drive the product to take advantage of the leverage they just paid for? I can say I was impressed with the three-phase integration plan IBM presented during the analyst call. The first phase is to get more exposure for BigFix within the customer base and good things should happen. After that, they integrate with the existing Tivoli stuff from a product and console standpoint. Given the existing relationship, the integration issues are somewhat manageable. That doesn’t mean they don’t exist or that IBM won’t screw it up – just ask ISS about that. But given the work already done to drive integration (you’ve got to figure the deal has been in the works for a while) and the existing partnership, they have done what they can to contain the risk. Bottom Line The only outstanding question is how much of a premium did BigFix cost? From almost every other standpoint the strategic rationale of this deal is strong and even the issues are not that big. This likely means other big Security/IT companies (think McAfee, BMC, Oracle, etc.) need to grab some real estate in the endpoint management space. So not only is this a good day for the folks at BigFix, but Shavlik, Lumension, and LanDesk (once their emancipation from Emerson goes through) are well positioned to be next. Share:

They say that no man is an island, and in the security space that’s very true. No system is, either – especially those tasked with some kind of security management. We get caught up in SIEM and Log Management platforms to suck in every piece of information they can to help with event correlation and analysis, but when it comes down to it security management is just one aspect of an enterprise’s management stack. SIEM/Log Management is only one discipline in the security management chain, and must feed some portion of its analysis to supporting systems. So clearly integration is key, both to getting value from SIEM/LM, and to making sure the rest of the organization is on board with buying and deploying the technology. For a number of enterprise IT management systems it is important to integrate with the SIEM/Log Management platform, ranging from importing data sources, to sending alerts, even up to participating in an IT organization’s workflow. We’ve broken the integrations up into inbound (receiving data from another tool) and outbound (sending data/alerts to another tool). Inbound integration Security management tools: We discussed this a bit when talking about data collection, regarding the importance of broadening the number of data sources for analysis and reporting. These systems include vulnerability management, configuration management, change detection, network behavioral analysis, file integrity monitoring, endpoint security consoles, etc. Typically integration with these systems is via custom connectors, and most SIEM/LM players have relationships with the big vendors in each space. Identity Management: Identity integration was discussed in the last post on advanced features and is another key system for providing data to the SIEM/LM platform. This can include user and group information (to streamline deployment and ongoing user management) from enterprise directory systems like Active Directory and LDAP, as well as provisioning and entitlement information to implement user activity monitoring. These integrations tend to be via custom connectors as well. Because these inbound integrations tend to require custom connectors to get proper breadth and fidelity of data, it’s a good idea to learn a bit about each vendor’s partner program. Vendors use these programs to gain access to the engineering teams behind their data sources; but more importantly devote the resources to developing rules, policies, and reports to take advantage of the additional data. Outbound integration IT GRC: Given that SIEM/Log Management gathers information useful to substantiate security controls for compliance purposes, clearly it would be helpful to be able to send that information to a broader IT GRC (Governance, Risk, and Compliance) platform that is presumably managing the compliance process at a higher level. So integration(s) with whatever IT GRC platform is in use within your organization (if any) is an important consideration for deciiding to acquire of SIEM/Log Management technology. Help Desk: The analysis performed within the SIEM/Log Management platform provides information about attacks in progress and usually requires some type of remediation action once an alert is validated. To streamline fixing these issues, it’s useful to be able to submit trouble tickets directly into the organization’s help desk system to close the loop. Some SIEM/Log Management platform have a built-in trouble ticket system, but we’ve found that capability is infrequently used, since all companies large enough to utilize SIEM/LM also have some kind of external help desk system. Look for the ability to not only send alerts (with sufficient detail to allow the operations team to quickly fix the issue), but also to receive information back when a ticket is closed, and to automatically close the alert within the SIEM platform. CMDB: Many enterprises have also embraced configuration management databases (CMDB) technology to track IT assets and ensure that configurations adhere to corporate policies. When trying to ensure changes are authorized, it’s helpful to be able to send indications of changes at the system and/or device level to the CMDB for confirmation. Again, paying attention to each vendor’s partner program and announced relationships can yield valuable information about the frequency of true enterprise deployment, as large customers demand their vendors work together – often forcing some kind of integration. It also pays to as vendor references about their integration offerings – because issuing a press release does not mean the integration is functional, complete, or useful. Share:

Earlier this week I was at the gym. I’d just finished a pretty tough workout and dropped down to the cafe area to grab one of those adult candy bars that tastes like cardboard and claims to give you muscles, longer life, and sexual prowess while climbing mountains. At least, that’s what I think they claim based on the pictures on the box. (And as a former mountain rescue professional, the technical logistics of the last claim aren’t worth the effort and potential injuries to sensitive bits). Anyway, there was this woman in front of me, and her ordering process went like this: Ask for item. Ask for about 5-6 different options on said menu item, essentially replacing all ingredients. Look surprised when a number following a dollar sign appears on the little screen facing her on the cash register. Reach down to gym bag. Remove purse. Reach into purse. Remove wallet. Begin scrounging through change. See salad in cooler out of corner of eye. Say, “Oh! I didn’t see that!” Walk to cooler, leaving all stuff in front of register, with transaction in the middle. Fail to see or care about line behind her. At this point, as she was rummaging through the pre-made salads, the guy behind the register looked at me, I looked at him, and we both subconsciously communicated our resignation as to the idiocy of the display in front of us. He moved over and unlocked the next register so I could buy my mountain-prowess-recovery bar, at which point the woman returned to the register and looked surprised that he was helping other (more decisive and prepared) customers. One of my biggest pet peeves is people who lack awareness of the world around them. Which is most people, and probably explains my limited social life. But they probably hate judgmental sanctimonious jerks like me, so it all works out. Just think about how many fewer security (and other) problems we’d have in the world if people would just swivel their damn heads and consider other people before making a turn? John Lennon should write a song about that or something. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike and Adrian on Open Network Podcast. Talking Open Source software vulnerabilities. Rich, Martin and Zach on the Network Security Podcast. Rich quoted on DLP in eWeek. Favorite Securosis Posts Adrian Lane: IBM gets a BigFix for Tivoli Endpoint Management. Congratulations to the BigFix team! Mike Rothman: IBM gets a BigFix. Normally I don’t toot my own horn, but this was a good deal of analysis. Fairly balanced and sufficiently snarky… David Mortman: Understanding and Selecting a Tokenization Solution: Introduction. Rich: Ditto. Other Securosis Posts Understanding and Selecting SIEM/LM: Integration. Know Your Adversary. Tokenization: the Business Justification. Understanding and Selecting SIEM/LM: Advanced Features. Incite 6/30/2010: Embrace Individuality. Understanding and Selecting SIEM/LM: Data Management. DB Quant: Manage Metrics, Part 3, Change Management. Favorite Outside Posts Adrian Lane: Full Disclosure: Our Turn Not only does this show just how easily this can happen – to anyone – but it underscores the difficulty for sites built from dozens of components from different vendors. The “weakest link in the chain” rule applies. David Mortman: Same for me – Full Disclosure, Our Turn. Rich: A great TED talk on self deception. I really love better understanding our own biases. Project Quant Posts DB Quant: Protect Metrics, Part 2, Patch Management. DB Quant: Manage Metrics, Part 1, Configuration Management. DB Quant: Protection Metrics, Part 4, Web Application Firewalls. 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 Rich and Adrian in Essentials Guide to Data Protection. Justices Uphold Sarbanes-Oxley Act. Laughably, some parties complained SOX is not being followed by foreign companies! Heck, US comapnies 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 spot together. Twitter mandated to establish information security program. Destimation Hotels breached. FBI fails to crack TrueCrypt. Top applications fail to leverage Windows security protections. This is a huge deal – if the apps don’t opt into anti-exploitation, they are essentially a dagger straight to the heart of the OS if an attacker finds a vuln. 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 Michael O’Keefe, in response to The Open Source Database Security Project. Adrian – thanks for the reply. Maybe risk assessment wasn’t the right word – I was thinking of some sort of market analysis to determine which open source databases to focus on. I was using selection criteria like “total number of installations” and “total size in bytes”, etc, but user groups is indeed a good criterion to use, since you are targeting an audience of actual ordinary users, not mega companies like facebook and twitter that should be managing the security themselves. Maybe these types of distributed databases (bigtable, Cassandra) should be the focus of separate project? A quick search of Securosis shows one mention of bigtable, so while I don’t want to expand the scope of the current project, these “storage systems” do offer some interesting security problems. For example here Peter Fleischer from Google discusses the difficulty in complying with the EU Data Protection Directive: http://peterfleischer.blogspot.com/2009/04/cloud-policy-consequences-for-privacy.html Share: