Tokenization: the Business Justification

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:

Read Post

Know Your Adversary

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:

Read Post

IBM gets a BigFix for Tivoli Endpoint Management

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:

Read Post

Understanding and Selecting SIEM/LM: Integration

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:

Read Post

Friday Summary: July 1, 2010

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: Share:

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.