This is the first in a series we will be posting this week on security markets. In the rest of this series we will look at individual markets, and discuss how these forces work to help with buying decisions.
Catching up with recent news, Check Point has joined the crowd and added application control as a new option on their gateway products. Sound like you’ve heard this one before? That’s because this function was pioneered by Palo Alto, then added by Fortinet and even Websense (on their content gateways). Yet again we see multiple direct and indirect competitors converge on the same set of features.
Feature parity can be problematic, because it significantly complicates a customer’s ability to differentiate between solutions. I take a ton of calls from users who ask, “should I buy X or Y” – and I’m considerate enough to mute the phone so they don’t hear me flipping my lucky coin.
During last week’s Securosis research meeting we had an interesting discussion on the relationship between feature parity, commoditization, and organization size. In nearly any market – both security and others – competitors tend to converge on a common feature set rather than run off in different innovative directions. Why? Because that’s what the customers think they need. The first mover with the innovative feature makes such a big deal of it that they manage to convince customers they need the feature (and that first product), so competitors in that market must add the feature to compete.
Sometimes this feature parity results in commoditization – where prices decline in lockstep with the reduced differentiation – but in other cases there’s only minimal impact on price. By which I mean the real price, which isn’t always what’s advertised. What we tend to find is that products targeting small and mid-sized organizations become commoditized (prices and differentiation drop); but those targeting large organizations use feature parity as a sales, upgrade, and customer retention tool.
- So why does this matter to the average security professional? Because it affects what products you use and how much you pay for them, and because understanding this phenomenon can make your life a heck of a lot easier.
Commoditization in the Mid-Market
First let’s define organization size – we define ‘mid’ as anything under about 5,000 employees and $1B in annual revenue. If you’re over $1B you’re large, but this is clearly a big bucket. Very large tends to be over 50K employees.
Mid-sized and smaller organizations tend to have more basic needs. This isn’t an insult, it’s just that the complexity of the environment is constrained by the size. I’ve worked with some seriously screwed up mid-sized organizations, but they still pale in comparison to the complexity of a 100K + employee multinational.
This (relative) lack for complexity in the mid-market means that when faced with deciding among a number of competing products – unless your situation is especially wacky – you pick the one that costs less, has the easiest management interface (reducing the time you need to spend in the product), or simply strikes your fancy. As a result the mid-market tends to focus on the lowest cost of ownership: base cost + maintenance/support contract + setup cost + time to use. A new feature only matters if it solves a new problem or reduces costs.
Settle down, mid-market folks! This isn’t an insult. We know you like to think you are different and special, but you probably aren’t.
Since mid-market customers have the same general needs and desire to save costs, vendors converge on the lowest common denominator feature set and shoot for volume. They may keep one-upping each other with prettier dashboards or new tweaks, but unless those result in filling a major need or reducing cost, they can’t really charge a lot more for them. Will you really pay more for a Coke than a Pepsi?
The result is commoditization.
Not that commoditization is bad – vendors make it up in volume and lower support costs. I advise a ton of my vendor clients to stop focusing on the F100 and realize the cash cow once they find the right mid-market product fit. Life’s a lot easier when you don’t have 18-month sales cycles, and don’t have to support each F100 client with its own sales team and 82 support engineers.
Feature Parity in the Large Enterprise Market
This doesn’t really play out the same when playing with the big dogs.
Vendors still tend to converge on the same feature sets, but it results in less overt downward price pressure. This is for a couple reasons:
- Larger organizations are more locked into products due to higher switching costs.
- In such complex environments, with complicated sales cycles involving multiple competitors, the odds are higher that one niche feature or function will be critical for success, making effective “feature equivalence” much tougher for competitors.
I tend to see switching costs and inertia as the biggest factor, since these products become highly customized in large environments and it’s hard to change existing workflows. Retraining is a bigger issue, and a number of staff specialize in how the vendor does things. These aren’t impossible to change, but make it much harder to embrace a new provider.
But vendors add the features for a reason. Actually, 3 reasons:
- Guard the henhouse: If a new feature is important enough, it might cause either a customer shift (loss), or more likely in the customer deploying a competitive product in parallel for a while – vendors, of course, are highly motivated to keep the competition away from their golden geese. Competitive deployments, either as evaluations or in small niche roles, substantially raise the risk of losing the customer – especially when the new sales guy offers a killer deal.
- Force upgrade: The new features won’t run on existing hardware/software, forcing the customers to upgrade to a new version. We have seen a number of infrastructure providers peg new features to the latest codebase or appliance, forcing the customer’s hand.
- Perceived added value: The sales guys can toss the new features in for free to save a renewal when the switching costs aren’t high enough to lock the customer in. The customer thinks they are getting additional value and that helps weigh against switching costs. Think of full disk encryption being integrated into endpoint security suites.
Smart customers use these factors to get new functions and features for free, assuming the new thing is useful enough to deploy. Even though costs don’t drop in the large enterprise market, feature improvements usually result in more bang for the buck – as long as the new capabilities don’t cause further lock-in.
Through the rest of this week we’ll start talking specifics, using examples from some of your favorite markets, to show you what does and doesn’t matter in some of the latest security tech…
Posted at Monday 9th August 2010 12:00 pm
(1) Comments •
By Mike Rothman
As we conclude the policy management aspects of the Manage Firewall process (which includes Policy Review and Define/Update Policies & Rules), it’s now time to document the policies and rules you are putting into place. This is a pretty straightforward process, so there isn’t much need to belabor the point.
Document Policies and Rules
Keep in mind the level of documentation you need for your environment will vary based upon culture, regulatory oversight, and (to be candid) ‘retentiveness’ of the security team. We are fans of just enough documentation. You need to be able to substantiate your controls (especially to the auditors) and ensure your successor (‘cause you are movin’ on up, Mr. Jefferson) knows how and why you did certain things. But there isn’t much point in spending all your time documenting rather than doing. Obviously you have to find the right balance, but clearly you want to automate as much of this process as you can.
We have identified 4 subprocesses in the documentation step:
- Approve Policy/Rule: The first step is to get approval for the policy and/or rule (refer to Define/Update for our definitions of policies and rules), whether it’s new or an update. We strongly recommend having this workflow defined before you put the operational process into effect, especially if there are operational handoffs required before actually making the change. You don’t want to step on a political landmine in the heat of trying to make an emergency change. Some organizations have a very formal process with committees, while others use a form within their help desk system to ensure very simple separation of duties and an audit trail – of the request, substantiation, approver, etc. Again, we don’t recommend you make this harder than it needs to be, but you do need some level of formality, if only to keep everything on the up and up.
- Document Policy Change: Once the change has been approved it’s time to write it down. We suggest using a fairly straightforward template, outlining the business need for the policy and its intended outcome. Remember, policies consist of high level, business oriented statements. The documentation should already be about ready from the approval process. This is a matter of making sure it gets filed correctly.
- Document Rule Change: This is equivalent to the Document Policy Change step, except here you are documenting the actual enforcement rules which include the specifics of ports, protocols, and/or applications, as well as time limits and ingress/egress variances. The actual change will be based on this document so it must be correct.
- Prepare Change Request: Finally we take the information within the documentation and package it up for the operations team. Depending on your relationship with ops, you may need to be very granular with the specific instructions. This isn’t always the case, but we make a habit of not leaving much to interpretation, because that leaves an opportunity for things to go haywire. Again we recommend some kind of standard template, and don’t forget to include some context for why the change is being made. You don’t need to go into a business case (as when preparing the policy or rule for approval), but if you include some justification, you have a decent shot of avoiding a request for more information from ops, and delay while you convince to make the change.
In some cases, including data breach lockdowns and imminent zero-day attacks, a change to the firewall ruleset must be made immediately. A process to circumvent the broader change process should be established and documented in advance, ensuring proper authorization for such rushed changes, and that there is a rollback capability in case of unintended consequences.
Posted at Monday 9th August 2010 7:00 am
(2) Comments •
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.
Posted at Friday 6th August 2010 9:49 pm
(0) Comments •
By Mike Rothman
As we keep digging into the policy management aspects of managing firewalls (following up on Manage Firewall: Review Policies), we need to define the policies and rules that drive the firewall. Obviously the world is a dynamic place with all sorts of new attacks continually emerging, so defining policies and rules is not a one-time thing. You need an ongoing process to update the policies as well.
So this step focuses on understanding what we need to protect and building a set of policies to do that. But before we dig in we should clarify what we mean by policies and rules, since many folks (including Securosis, at times) use the terms interchangeably. For this series we define the policy as the high-level business-oriented description of what you need to protect. For example, you may need to protect the credit card data to comply with PCI – that would be a policy. These are high-level and distinct from the actual implementation rules which would be installed on the firewall to implement the policies.
Rules are defined to implement the policy within the device. So you’d need to block (or allow) certain ports, protocols, users, networks and/or applications (each a separate rule) during certain time periods to implement the spirit of each policy. There will be overlap, because the “protect credit card data” policy would involve some of the same rules as a “protect private health information” policy. Ultimately you need to bring everything you do back to a business driver, and this is one of the techniques for doing that.
Define/Update Policies and Rules
Given the amount of critical data you have to protect, building an initial set of policies can seem daunting. We recommend organizations take a use case-based approach to building the initial set of policies. This means you identify the critical applications, users, and/or data that needs to be protected and the circumstances for allowing or blocking access (location, time, etc.). This initial discovery process will help when you need to prioritize enforcing rules vs. inconveniencing users, since you always need to strike a balance between them. Given those use cases, you can define the policies, then model the potential threats to those applications/users/data. Your rules address the attack vectors identified through the threat model. Finally you need to stage/test the rules before deploying to make sure everything works.
More specifically, we’ve identified five subprocesses involved in defining and updating these policies/rules:
Identify Critical Applications/Users/Data: In this step, we need to discover what we need to protect. The good news is we already should have at least some of this information, most likely through the defining monitoring policies subprocess. While this may seem rudimentary, it’s important not to assume you know what is important and what needs to be protected. This involves not only doing technical discovery to see what’s out there, but also asking key business users what applications/users/data are most important to them. We need to take every opportunity we can to get in front of users in order to a) listen to their needs, and b) evangelize the security program. For more detailed information on discovery, check out Database Security Quant on Database Discovery.
Define/Update Policies: Once the key things to protect are identified we define the base policies. As described above, the policies are the high level business-oriented statements of what needs to be protected. With the policies, just worry about the what, not how. It’s important to prioritize policies as well, since that helps with inevitable decisions on which policies go into effect, and when specific changes happen. This step is roughly the same whether policies are being identified for the first time or updated.
Model Threats: Similar to the way we built correlation rules for monitoring, we need to break down each policy into a set of attacks, suspect behavior, and/or exploits which could be used to violate the policy. You need to put yourself in the shoes of the hacker and think like them. Clearly there are an infinite number of attacks that can be used to compromise data, so fortunately the point isn’t to be exhaustive – it’s to identify the most likely threat vectors for each policy.
Define/Update Rules: Once the threats are modeled it’s time go one level down, and define how you’d handle that attack on the firewall, including specifics about the ports, protocols and/or applications that would be involved in each attack. You also need to think about when these rules should be in effect (24/7, during business hours, or on a special schedule) and whether there is an end date for the rules (for example, when a joint development project ends, you close the port for the shared Subversion server). Keep in mind both ingress and egress filtering policies, as many attacks can be blocked when trying to exfiltrate data. This identifies the base set of rules to implement a policy. Once you’ve been through each policy, you need to get rid of duplicates and see where the leverage is. Given the number of policies and possible rules, some organizations use a firewall policy manager such as FireMon, Tufin, AlgoSec, Red Seal, or Skybox to help define the rules – and more importantly to make sure the rules don’t conflict with each other.
Test Rule Set: The old adage about measure twice, cut once definitely applies here. Before implementing any rules, we strongly recommend testing both the attack vectors and the potential ripple effect to avoid breaking other rules during implementation. You’ll need to identify a set of tests for the rules being defined/updated and perform those tests. Given that testing on a production box isn’t the best idea, it’s wise to have a firewall testbed to implement new and updated policies. If any of the rules fail, you need to go back to the define/update rules step and make the fixes. Obviously this define/update/test process is cyclical until the tests pass.
Default Deny and Application Awareness
We know defining all these policies can be daunting. But there are ways to make it a bit easier, and the first is to adopt a default deny perimeter security posture. That means unless you specifically authorize certain traffic to go through the firewall, the traffic gets blocked. Each of the rules is about configuring the port, protocol, and/or application to enable an application or user to do their job.
Obviously there is only so much granularity you can apply at the firewall level, which is driving interest in application-aware firewalls which can block certain applications for certain users. You have to allow port 80 in (to the DMZ at a minimum) and out, so the more granular you can get within a specific port based on application or business use, the better.
Keep in mind all of the commercial (and even some open source) firewalls ship with a set of default policies (and associated rules) that can be easily customized to your environment. We recommend you work through the process and then compare your requirements against your available out-of-the-box policies because you want to implement the rules that apply to your environment, not the vendor’s generic set.
Next we’ll quickly discuss documenting policy changes before digging into the change management subprocesses.
Posted at Friday 6th August 2010 3:42 pm
(2) Comments •
By Adrian Lane
I started running when I was 10. I started because my mom was talking a college PE class, so I used to tag along and no one seemed to care. We ran laps three nights a week. I loved doing it and by twelve I was lapping the field in the 20 minutes allotted. I lived 6 miles from my junior high and high school so I used to run home. I could have walked, ridden a bike, or taken rides from friends who offered, but I chose to run. I was on the track team and I ran cross country – the latter had us running 10 miles a day before I ran home. And until I discovered weight lifting, and added some 45 lbs of upper body weight, I was pretty fast.
I used to run 6 days week, every week. Run one evening, next day mid-afternoon, then morning; and repeat the cycle, taking the 7th day off. That way I ran with less than 24 hours rest four days days, but it still felt like I got two days off. And I would play all sorts of mental games with myself to keep getting better, and to keep it interesting. Coming off a hill I would see how long I could hold the faster speed on the flat. Running uphill backwards. Going two miles doing that cross-over side step they teach you in martial arts. When I hit a plateau I would take a day and run wind sprints up the steepest local hill I could find. The sandy one. As fast as I could run up, then trot back down, repeating until my legs were too rubbery to feel. Or maybe run speed intervals, trying to get myself in and out of oxygen deprivation several times during the workout. If I was really dragging I would allow myself to go slower, but run with very heavy ‘cross-training’ shoes. That was the worst. I have no idea why, I just wanted to run, and I wanted to push myself.
I used to train with guys who were way faster that me, which was another great way to motivate. We would put obscene amounts of weight on the leg press machine and see how many reps we could do, knee cartilage be damned, to get stronger. We used to jump picnic tables, lengthwise, just to gain explosion. One friend like to heckle campus security and mall cops just to get them to chase us because it was fun, but also because being pursued by a guy with a club is highly motivating. But I must admit I did it mainly because there are few things quite as funny as the “oomph-ugghh” sound rent-a-guards make when they hit the fence you just casually hopped over. For many years after college, while I never really trained to run races or compete at any level, I continued to push myself as much as I could. I liked the way I felt after a run, and I liked the fact that I can eat whatever I want … as long as I get a good run in.
Over the last couple years, due to a combination of age and the freakish Arizona summers, all that stopped. Now the battle is just getting out of the house: I play mental games just to get myself out the door to run in 112 degrees. I have one speed, which I affectionately call “granny gear”. I call it that because I go exactly the same speed up hill as I do on the flat: slow. Guys rolling baby strollers pass me. And in some form of karmic revenge I can just picture myself as the mall cop, getting toasted and slamming into chain link fence because I lack the explosion and leg strength to hop much more than the curb. But I still love it as it clears my head and I still feel great afterwards … gasping for air and blotchy red skin notwithstanding. Or at least that is what I am telling myself as I am lacing up my shoes, drinking a whole bunch of water, and looking at the thermometer that reads 112. Sigh Time to go …
On to the Summary:
Webcasts, Podcasts, Outside Writing, and Conferences
Favorite Securosis Posts
Other Securosis Posts
Favorite Outside Posts
Project Quant Posts
Research Reports and Presentations
Top News and Posts
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 Mark Bower of Voltage, in response to and older FireStarter: An Encrypted Value Is Not a Token!
Regarding your statement: “Key here is to remember, PCI DSS is allowing systems that substitute credit card data with tokens to be removed from the audit based upon the premise that PAN data is not available”
I’d be interested if you could point to the specific part of PCI DSS today that states that Tokens remove systems from the validation requirements. There’s a lot of work going on in this area but nowhere does this get stated in PCI DSS to be clear.
Thus, merely claiming one is “using Tokenization” may or may not reduce scope and may or may not increase security: it has to be done right: only a QSA can make that decision when looking at the specifics of an implementation.
A lot of claims are made about Tokenization security, and many are not based on science. I would also point out that getting Tokenization right is a lot more involved than merely substituting data and managing a Data Vault. Many of the types of attacks on cryptosystems still apply in slightly different forms to Tokenization systems especially if such systems do not pay very good attention to the token generation process, exactly what you tokenize in the first place, and most importantly how you manage credentials and access to BOTH the tokenizing system and detokenizing system and any images of it that are distributed.
The suggestion that Tokenization is “simple” is also a somewhat misleading statement: if you have to manage, sync, distribute and contain a growing database of tokens, keys and other sensitive materials (credentials), monitor it etc, then this starts to become a significant surface to risk manage – especially the entry and exit points and their data paths. Also, how do you manage a re-tokenize event if your token systems somehow have been compromised so the tokens themselves can now be manipulated, injected and abused? Assuring that the tokenizing engine has not been tampered with or the sources of entropy used to generated tokens are within specification are all considerations. One cannot underestimate the ingenuity of todays sophisticated attackers.
An open access tokenizer for example may permit a successful table based attack on a poorly implemented system given knowledge of cardholder data patterns. A badly design hashing token approach which does not pay attention to security may lead to simple compromise without even attacking the token database. VISA’s guidance is refreshing to see more rigor being necessary. Perhaps these types of attacks are what VISA indicated in their statement:
“Where properly implemented, tokenization may help simplify a merchant’s payment card environment,” said Eduardo Perez, Head of Global Payment System Security, Visa Inc. “However, we know from working with the industry and from forensics investigations, that there are some common implementation pitfalls that have contributed to data compromises. For example, entities have failed to monitor for malfunctions, anomalies and suspicious activity, allowing an intruder to manipulate the tokenization system undetected. As more merchants look at tokenization solutions, these best practices will provide guidance on how to implement those solutions effectively and highlight areas for particular vigilance,”
Posted at Friday 6th August 2010 6:26 am
(0) Comments •
By Mike Rothman
We now embark on the next leg of the Network Security Operations Quant research project by tackling the subprocesses involved in managing firewalls. We updated the Manage Firewall high level process map to better reflect what we’ve learned through our research, so let’s dig in.
We’ve broken up the processes into “Policy Management” and “Change Management” buckets. The next three posts will deal with policy management – which starts with reviewing your policies.
Although it should happen periodically, far too many folks rarely or never go through their firewall policies to clean up and account for ongoing business changes. Yes, this creates security issues. Yes, this also creates management issues, and obsolete and irrelevant rules can place unnecessary burden on the firewalls. So at a minimum there should be a periodic review – perhaps twice a year – to evaluate the rules and policies, and make sure everything is up to date.
We see two other catalysts for policy review:
- Service Request: This is when someone in the organization needs a change to the firewall, typically driven by a new application or trading partner that needs access to something or other. You know – when someone calls and asks you to just open port XXXX because it would be easier than writing the application correctly.
- External Advisory: At times, when a new attack vector is identified, one of the ways to defend against it would be to make a change on the firewalls. This involves monitoring the leading advisory services and then using that information to determine whether a policy review is necessary.
Once you’ve decided to review the policies, we’ve identified five subprocesses:
- Review Policies: The first step is to document the latest version of the polices; then you’ll research the requested changes. This gets back to the catalysts mentioned above. If it’s a periodic review you don’t need a lot of prep work. If it’s based on a request you need to understand the nature of the request and why it’s important. If the review is driven by a clear and present danger, you need to understand the nuances of the attack vector to understand how you can make changes to defend against the attack.
- Propose Policy Changes: Once you understand why you are making the changes, you’ll be able to make a recommendation regarding the required policy changes. These should be documented to the greatest degree possible, both to facilitate evaluation and authorization and to maintain an audit trail of why specific changes were made.
- Determine Relevance/Priority: Now that you have a set of proposed changes it’s time to determine its initial priority. This varies based on the importance of particular assets behind the firewall, and the catalyst for the change. You’ll also want a criteria for an emergency update, which bypasses most of the change management processes in the event of a high priority situation.
- Determine Dependencies: Given the complexity and interconnectedness of our technology environment, even a fairly simple change can create ripples that result in unintended consequences. So analyze the dependencies before making changes. If you lock down protocol A or application B, what business processes/users will be impacted? Some organizations manage by complaint by waiting until users scream about something broken after a change. That is one way to do it, but most at least give the users a “heads up” when they decide to break something.
- Evaluate Workarounds/Alternatives: A firewall change may not be the only option for defending against an attack or providing support for a new application. For due diligence you should include time to evaluate workarounds and alternatives. In this step, determine any potential workarounds and/or alternatives, and evaluate the dependencies and effectiveness of the other options, in order objectively choose the best option.
In terms of our standard disclaimer for Project Quant, we build these Manage Firewall subprocesses for organizations that need to manage a set of firewalls. We don’t make any assumptions about company size or whether a tool set will be used. Obviously the process varies based on your particular circumstances, as you will perform some steps and kip others. We think it’s important to give you a feel for everything that is required in managing these devices so you can compare apples to apples between managing your own, versus buying a product(s), or using a service.
As always, we appreciate any feedback you have on these subprocesses.
Next we’ll Define/Update Policies and Rules, where we roll up our sleeves and both maintain the policy base and take that to the next level and figure out the rules required to implement the policies.
Posted at Thursday 5th August 2010 6:32 pm
(3) Comments •
By Adrian Lane
We have now discussed most of the relevant bits of technology for token server construction and deployment. Armed with that knowledge we can tackle the most important part of the tokenization discussion: use cases. Which model is right for your particular environment? What factors should be considered in the decision? The following three or four uses cases cover most of the customer situations we get calls asking for advice on. As PCI compliance is the overwhelming driver for tokenization at this time, our first two use cases will focus on different options for PCI-driven deployments.
Mid-sized Retail Merchant
Our first use case profiles a mid-sized retailer that needs to address PCI compliance requirements. The firm accepts credit cards but sells exclusively on the web, so they do not have to support point of sale terminals. Their focus is meeting PCI compliance requirements, but how best to achieve the goal at reasonable cost is the question. As in many cases, most of the back office systems were designed before credit card storage was regulated, and use the CC# as part of the customer and order identification process. That means that order entry, billing, accounts receivable, customer care, and BI systems all store this number, in addition to web site credit authorization and payment settlement systems.
Credit card information is scattered across many systems, so access control and tight authentication are not enough to address the problem. There are simply too many access points to restrict with any certainty of success, and there are far too many ways for attackers to compromise one or more systems. Further, some back office systems are accessible by partners for sales promotions and order fulfillment. The security efforts will need to embrace almost every back office system, and affect almost every employee. Most of the back office transaction systems have no particular need for credit card numbers – they were simply designed to store and pass the number as a reference value. The handful of systems that employ encryption are transparent, meaning they automatically return decrypted information, and only protect data when stored on disk or tape. Access controls and media encryption are not sufficient controls to protect the data or meet PCI compliance in this scenario.
While the principal project goal is PCI compliance; as with any business strong secondary goals of minimizing total costs, integration challenges, and day to day management requirements. Because the obligation is to protect card holder data and limit the availability of credit cards in clear text, the merchant does have a couple choices: encryption and tokenization. They could implement encryption in each of the application platforms, or they could use a central token server to substitute tokens for PAN data at the time of purchase.
Our recommendation for our theoretical merchant is in-house tokenization. An in-house token server will work with existing applications and provide tokens in lieu of credit card numbers. This will remove PAN data from the servers entirely with minimal changes to those few platforms that actually use credit cards: accepting them from customers, authorizing charges, clearing, and settlement – everything else will be fine with a non-sensitive token that matches the format of a real credit card number. We recommend a standalone server over one embedded within the applications, as the merchant will need to share tokens across multiple applications. This makes it easier to segment users and services authorized to generate tokens from those that can actually need real unencrypted credit card numbers.
Diagram 1 lays out the architecture. Here’s the structure:
- A customer makes a purchase request. If this is a new customer, they send their credit card information over an SSL connection (which should go without saying). For future purchases, only the transaction request need be submitted.
- The application server processes the request. If the credit card is new, it uses the tokenization server’s API to send the value and request a new token.
- The tokenization server creates the token and stores it with the encrypted credit card number.
- The tokenization server returns the token, which is stored in the application database with the rest of the customer information.
- The token is then used throughout the merchant’s environment, instead of the real credit card number.
- To complete a payment transaction, the application server sends a request to the transaction server.
- The transaction server sends the token to the tokenization server, which returns the credit card number.
- The transaction information – including the real credit card number – is sent to the payment processor to complete the transaction.
While encryption could protect credit card data without tokenization, and be implemented in such a way as to minimize changes to UI and database storage to supporting applications, it would require modification of every system that handles credit cards. And a pure encryption solution would require support of key management services to protect encryption keys. The deciding factor against encryption here is the cost of retrofitting system with application layer encryption – especially because several rely on third-party code. The required application changes, changes to operations management and disaster recovery, and broader key management services required would be far more costly and time-consuming. Recoding applications would become the single largest expenditure, outweighing the investment in encryption or token services.
Sure, the goal is compliance and data security, but ultimately any merchant’s buying decision is heavily affected by cost: for acquisition, maintenance, and management. And for any merchant handling credit cards, as the business grows so does the cost of compliance. Likely the ‘best’ choice will be the one that costs the least money, today and in the long term. In terms of relative security, encryption and tokenization are roughly equivalent. There is no significant cost difference between the two, either for acquisition or operation. But there is a significant difference in the costs of implementation and auditing for compliance.
Next up we’ll look at another customer profile for PCI.
Posted at Thursday 5th August 2010 12:14 pm
(0) Comments •
By Mike Rothman
Note: Based on our ongoing research into the process maps, we decided we needed to update both the Manage Firewall and IDS/IPS process maps. As we built the subprocesses and gathered feedback, it was clear we didn’t make a clear enough distinction between main processes and subprocesses. So we are taking another crack at this process map. As always, your feedback is appreciated.
After posting the Monitor Process Map to define the high-level process for monitoring firewalls, IDS/IPS and servers, we now look at the management processes for these devices. In this post we tackle firewalls.
Remember, the Quant process depends on you to keep us honest. Our primary research and experience in the trenches gives us a good idea, but you pick up additional nuances fighting the battles every day. So if something seems a bit funky, let us know in the comments.
Keep the philosophy of Quant in mind: the high level process framework is intended to cover all the tasks. That doesn’t mean you need to do everything – this should be a fairly exhaustive list, and overkill for most organizations. Individual organizations should pick and choose the appropriate steps for their requirements.
When contrasting the monitor process with management, the first thing that jumps out is that policies drive the use of the device(s), but when you need to make a change the heavy process orientation kicks in. Why? Because making a mistake or unauthorized change can have severe ramifications, such as exposing critical data to the entire Internet. Right, that’s bad. So there are a lot of checks and balances in the change management process to ensure all changes are authorized and tested, and won’t create mayhem through a ripple effect.
In this phase we define what ports, protocols, and (increasingly) applications are allowed to traverse the firewall. Depending on the nature of what is protected and the sophistication of the firewall the policies may also include source and destination addresses, application behavior, and user entitlements.
A firewall rule base can resemble a junk closet – there is lots of stuff in there, but no one can quite remember what everything does. So it is best practice to periodically review firewall policy and prune rules that are obsolete, duplicative, overly exposed, or otherwise not needed. Possible catalysts for policy review include service requests (new application support, etc.), external advisories (to block a certain attack vector or work around a missing patch, etc.), and policy updates resulting from the operational management of the device (change management process described below).
Define/Update Policies & Rules
This involves defining the depth and breadth of the firewall policies – including which ports, protocols, and applications are allowed to traverse the firewall. Time-limited policies may also be deployed to support short-term access for specific applications or user communities. Additionally, policies vary depending on primary use case, which may include perimeter deployment or network segmentation, etc. Logging, alerting, and reporting policies are also defined in this step.
It’s important here to consider the hierarchy of policies that will be implemented on the devices. The chart at right shows a sample hierarchy including organizational policies at the highest level, which may then be supplemented (or even supplanted) by business unit or geographic policies. Those feed the specific policies and/or rules implemented in each location, which then filter down to the specific device. Policy inheritance can be leveraged to dramatically simplify the rule set, but it’s easy to introduce unintended consequences in the process. This is why constant testing of firewall rules is critical to maintaining a strong perimeter security posture.
Initial deployment of the firewall policies should include a QA process to ensure no rule impairs the ability of critical applications to communicate, either internally or externally.
Document Policy Changes
As the planning stage is an ongoing process, documentation is important for operational and compliance purposes. This documentation lists and details whatever changes have been made to the policies.
This phase deals with rule additions, changes, and deletions.
Evaluate Change Request
Based on the activities in the policy management phase, some type of policy/rule change will be requested for implementation. This step involves ensuring the requestor is authorized to request the change, as well assessing the relative priority of the change to slot it into an appropriate change window.
Changes are prioritized based on the nature of the policy update and risk of the catalyst driving the change – which might be an attack, a new 0-day, a changed application, or any of various other things. Then a deployment schedule is built from this prioritization, scheduled maintenance windows, and other factors. This usually involves the participation of multiple stakeholders – ranging from application, network, and system owners to business unit representatives if any downtime or change to application use models is anticipated.
Test and Approve
This step requires you to develop test criteria, perform any required testing, analyze the results, and approve the rule change for release once it meets your requirements. Testing should include monitoring the operation and performance impact of the change on the device. Changes may be implemented in “log-only” mode to understand their impact before committing to production deployment.
With an understanding of the impact of the change(s), the request are either approved or denied. Obviously approval may require a number of stakeholders approving the change. The approval workflow must be understood and agreed upon to avoid serious operational issues.
Prepare the target device(s) for deployment, deliver the change, and install. Verify that changes were properly deployed, including successful installation and operation. This might include use of vulnerability assessment tools or application test scripts to ensure production systems are not disrupted.
The process of making a change requires confirmation from both the operations team (during the Deploy step), and also from another entity (internal or external, but outside ops) as an audit. This is basic separation of duties.
Basically this involves validating the change to ensure the policies were properly updated, as well as to match the change to a specific change request. This closes the loop and ensures there is a trail for every change made.
In some cases, including data breach lockdowns and imminent zero-day attacks, a change to the firewall ruleset must be made immediately. A process to circumvent the broader change process should be established and documented in advance, ensuring proper authorization for such rushed changes, and that there is a roll-back capability in case of unintended consequences.
Health Monitoring and Maintenance
This phase involves ensuring the firewalls are operational and secure by monitoring the devices availability and performance. When necessary this will include upgrading the hardware. Additionally, software patches (for either functionality or security) are implemented in this phase. We’ve broken out this step due to its operational nature. This doesn’t relate to security or compliance directly, but can be a significant cost component of managing these devices and thus will be modeled separately.
For the purposes of this Quant project, we are considering the monitoring and management processes separate, although many organizations (especially the service providers that provide managed services) consider device management a superset of device monitoring.
So our firewall management process flow does not include any steps for incident investigation, response, validation, or management. Please refer to the monitoring process flow for those activities.
We are looking forward to your comments and feedback. Fire away.
Posted at Wednesday 4th August 2010 7:48 pm
(1) Comments •
By Mike Rothman
As I mentioned in the Mailbox Vigil, we don’t put much stock in snail mail anymore. Though we did get a handful of letters from XX1 (oldest daughter) from sleepaway camp, aside from that it’s bills and catalogs. That said, every so often you do get entertained by the mail. A case in point happened when we got back from our summer pilgrimage to the Northern regions this weekend (which is why there was no Incite last week).
On arriving home (after a brutal 15 hour car ride, ugh!) we were greeted by a huge box of mail delivered by our trusty postal worker. Given that the Boss was occupied doing about 100 loads of laundry and I had to jump back into work, we let XX1 express her newfound maturity and sort our mail.
It was pretty funny. She called out every single piece and got genuinely excited by some of the catalogs. She got a thank you note from a friend, a letter from another, and even a few of her own letters to us from camp (which didn’t arrive before we left on holiday). XX2 (her twin) got a thank you note also. But nothing for the boy. I could tell he was moping a bit and I hoped something would come his way.
Finally he heard the magic words: “Sam got a letter.” Reminded me of Blue’s Clues. It was from someone with an address at the local mall. Hmmm. But he dutifully cracked it open and had me read it to him. It was from someone at LensCrafters reminding him that it’s been a year since he’s gotten his glasses and he’s due for a check-up.
He was on the edge of his seat as I read about how many adults have big problems with their eyes and how important it is to get an annual check-up. Guess they didn’t realize the Boy is not yet 7 and also that he sees his Opthamologist every 6 weeks. But that didn’t matter – he got a letter.
So he’s carrying this letter around all day, like he just got a toy from Santa Claus or the Hanukkah fairy. He made me read it to him about 4 times. Now he thinks the sales person at LensCrafters is his pal. Hopefully he won’t want to invite her to his birthday party.
Normally I would have just thrown out the direct mail piece, but I’m glad we let XX1 sort the mail. The Boy provided me with an afternoon of laughter and that was certainly worth whatever it cost to send us the piece.
Photo credits: “surprise in the mailbox” originally uploaded by sean dreilinger
Recent Securosis Posts
- The Cancer within Evidence Based Research Methodologies
- Friday Summary: July 23, 2010
- Death, Irrelevance, and a Pig Roast
- What Do We Learn at Black Hat/DefCon?
- Tokenization Series:
- Various NSO Quant Posts:
Incite 4 U
We’re AV products. Who would try to hack us? – More great stuff from Krebs. This time he subjected himself to installing (and reinstalling) AV products in his VM to see which of them actually use Windows anti-exploitations technologies (like DEP and ASLR). The answer? Not many, though it’s good to see Microsoft eating their own dog food. I like the responses from the AV vendors, starting with F-Secure’s “we’ve been working on performance,” which means they are prioritizing not killing your machine over security – go figure. And Panda shows they have ostriches in Spain as well, as they use their own techniques to protect their software. OK, sure. This is indicative of the issues facing secure software. If the security guys can’t even do it right, we don’t have much hope for everyone else. Sad. – MR
Mid-market basics – She does not blog very often, but when she does, Jennifer Jabbusch gets it right. We here at Securosis are all about simplifying security for end users, and I thought JJ’s recent post on Four Must-Have SMB Security Tools did just that. With all the security pontification about new technologies to supplant firewalls, and how ineffective AV is at detecting bad code, there are a couple tools that are fundamental to data security. As bored as we are talking about them, AV, firewalls, and access controls are the three basics that everyone needs. While I would personally throw in encrypted backups as a must have, those are the core components. But for many SMB firms, these technologies are the starting point. They are not looking at extrusion prevention, behavioral monitoring, or event correlation – just trying to make sure the front door is locked, both physically and electronically. It’s amazing to think, but I run into companies all the time where an 8-year-old copy of Norton AV and a password on the ‘server’ are the security program. I hope to see more basic posts like this that appeal to the mainstream – and SMB is the mainstream – on Dark Reading and other blogs as well. – AL
Jailbreak with a side of shiv – Are you one of those folks who wants to jailbreak your iPhone to install some free apps on it? Even though it removes some of the most important security controls on the device? Well, have I got a deal for you! Just visit jailbreakme.com and the magical web application will jailbreak your phone right from the browser. Of course any jailbreak is the exploitation of a security vulnerability. And in this case it’s a remotely exploitable browser vulnerability, but don’t worry – I’m sure no bad guys will use it now that it’s public. Who would want to remotely hack the most popular cell phone on the planet? – RM
A pig by a different name – SourceFire recently unveiled Razorback, their latest open source framework. Yeah, that’s some kind of hog or something, so evidently they are committed to this pig naming convention. It’s targeting the after-attack time, when it’s about pinpointing root cause and profiling behavior to catch attackers. I think they should have called it Bacon, since this helps after the pig is dead. Maybe that’s why I don’t do marketing anymore. Razorback is designed to coordinate the information coming from a heterogenous set of threat management tools. This is actually a great idea. I’ve long said that if vendors can’t be big (as in Cisco or Oracle big), they need to act big. Realizing enterprises will have more stuff than SourceFire, pulling in that data, and doing something with it, makes a lot of sense. The base framework is open source, but don’t be surprised to see a commercial version in the near term. Someone has to pay Marty, after all. – MR
Disclosure Debate, Round 37 – Right before Black Hat Google updated its vulnerability disclosure policy (for when its researchers find new vulns). They are giving vendors a 60-day window to patch any “critical” vulnerability before disclosing (not that they have the best history for timely response). Now TippingPoint, probably the biggest purchaser of independently discovered vulnerabilities, is moving to a 6-month window. Whichever side you take on the disclosure debate, assuming these companies follow through with their statements, the debate itself may not be advancing but the practical implications certainly are. Many vendors sit on vulnerabilities for extended periods – sometimes years. Of the 3 (minor) vulnerabilities I have ever disclosed, 2 weren’t patched for over a year. While I’m against disclosing anything without giving a vendor the chance to patch, and patch timetables need to account for the complexities of maintaining major software, and it’s unacceptable for vendors to sit on these things – leaving customers at risk while hoping for the best. I wonder how many “exemptions” we’ll see to these policies. – RM
The future of reputation: malware fingerprinting – Since I was in the email security business, I’ve been fascinated with reputation. You know, how intent can be analyzed based on IP address and other tells from inbound messages/packets. The technology is entrenched within email and web filtering and we are seeing it increasingly integrated into perimeter gateways as well. Yeah, it’s another of those nebulous cloud services. When I read the coverage of Greg Hoglund’s Black Hat talk on fingerprinting malware code, I instantly thought of how cool it would be to integrate these fingerprints into the reputation system. So if you saw an executable fly by, you could know it came from the Mariposa guys and block it. Yeah, that’s a way off, but since we can’t get ahead of the threat, at least we can try to block stuff with questionable heritage. – MR
Papers, please – I don’t understand why Bejtlich has such a problem with Project Vigilant. The Phoenix Examiner thinks it’s legit, and that should be enough. Just because he has not heard of them doesn’t mean they’re not. It means they are too sooper sekrit to go around publicizing themselves. Guess Richard forgot about Security by Obscurity. Plus, there is documented proof of organizations with hundreds of members on the front lines every day, but I bet Mr. Bejtlich – if that even is his real name – doesn’t know them either. Project Vigilant has like 500 people; that’s a lot, right? Look around at your next ISSA or ISACA chapter meeting and tell me if you have that many people. You can’t fake that sort of thing. Bejtlich says “If they have been active for 14 years, why does no one I’ve asked know who these guys are?” Ignorance is no excuse for undermining Project Vigilant. Who’s to say Chet Uber is not the real deal? And with a name like ‘Uber’, he doesn’t even need a handle. You know, like “The Chief” or “Fearless Leader”. Plus Uber has a cool logo with a winged-V thingy … way cooler that that mixed-message Taijitu symbol. Who’s Bejtlich to question Uber when he’s out there, giving it 110%, fighting terror. It’s not like there is a vetting process to fight terror. Even if there was, that’s for losers. Chuck Norris would not have a vetting process. He’s already killed all the members of the vetting committee. Fightin’ terror! Jugiter Viglio, baby! – AL
Is the cost of a breach more than the cost to protect against it? – More survey nonsense from Ponemon. Evidently breach recovery costs are somewhere between $1 million and $53 million with a median of $3.8 million. And my morning coffee costs somewhere between 10 cents and a zillion dollars, with a median price of $2.25. But the numbers don’t matter, it’s the fact that a breach will cost you money. We all know that. The real question is whether the cost to clean up an uncertain event (the breach happening to you) is more than the cost to protect against it. Given the anecdotal evidence that revenue visibility for security vendors is poor for the rest of the year, I’m expecting a lot more organizations to roll the dice with clean-up. And it’s not clear they are wrong, says the Devil’s Advocate. – MR
Posted at Wednesday 4th August 2010 7:00 am
(0) Comments •
By Mike Rothman
Actually I learned nothing because I wasn’t there. Total calendar fail on my part, as a family vacation was scheduled during Black Hat week. You know how it goes. The Boss says, “how is the week of July 26 for our week at the beach?” BH is usually in early August, so I didn’t think twice.
But much as I missed seeing my peeps and tweeps at Black Hat, a week of R&R wasn’t all bad. Though I was sort of following the Tweeter and did see the coverage and bloggage of the major sessions. So what did we learn this year?
- SSL is bad: Our friend RSnake and Josh Sokol showed that SSL ain’t all that. Too bad 99% of the laypeople out there see the lock and figure all is good. Actually, 10% of laypeople know what the lock means. The other 89% wonder how the Estonians made off with their life savings.
- SCADA systems are porous: OK, I’m being kind. SCADA is a steaming pile of security FAIL. But we already knew that. Thanks to a Red Tiger, we now know there are close to 40,000 vulnerabilities in SCADA systems, so we have a number. At least these systems aren’t running anything important, right?
- Auto-complete is not your friend: As a Mac guy I never really relied on auto-complete, since I can use TextExpander. But lots of folks do and Big J got big press when he showed it’s bad in Safari and also then proved IE is exposed as well.
- Facebook spiders: Yes, an enterprising fellow named Ron Bowes realized that most folks have set their Facebook privacy settings, ah, incorrectly. So he was able to download about 100 million names, phone numbers, and email addresses with a Ruby script. Then he had the nerve to put it up on BitTorrent. Information wants to be free, after all. (This wasn’t a session at BH, but cool nonetheless.)
- ATM jackpot: Barnaby Jack showed once again that he can hit the jackpot at will since war dialing still workss (yay WarGames!), and you can get pretty much anything on the Internet (like a key to open many ATM devices). Anyhow, great demo and I’m sure organized crime is very interested in those attack vectors.
- I can haz your cell tower: Chis Paget showed how he could spoof a cell tower for $1,500. And we thought the WiFi Evil Twin was bad. This is cool stuff.
I could probably go on for a week, since all the smart kids go to Vegas in the summer to show how smart they are. And to be clear, they are smart. But do you, Mr. or Ms. Security Practitioner, care about these attacks and this research? The answer is yes. And no.
First of all, you can see the future at Black Hat. Most of the research is not weaponized and a good portion of it isn’t really feasible to weaponize. An increasing amount is attack-ready, but for the most part you get to see what will be important at some point in the future. Maybe. For that reason, at least paying attention to the research is important.
But tactically what happens in Vegas is unlikely have any impact on day-to-day operations any time soon. Note that I used the word ‘tactical’, because most of us spend our days fighting fires and get precious few minutes a day – if any – to think strategically about what we need to do tomorrow. Forget about thinking about how to protect against attacks discussed at Black Hat. That’s probably somewhere around 17,502 on the To-Do list.
Of course, if your ethical compass is a bit misdirected or your revenues need to be laundered through 5 banks in 3 countries before the funds hit your account, then the future is now and Black Hat is your business plan for the next few years. But that’s another story for another day.
Posted at Tuesday 3rd August 2010 8:44 pm
(3) Comments •
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…
Posted at Tuesday 27th July 2010 12:38 am
(1) Comments •
Posted at Monday 26th July 2010 5:16 pm
(1) Comments •
By Adrian Lane
We have covered the internals of token servers and talked about architecture and integration of token services. Now we need to look at some of the different deployment models and how they match up to different types of businesses. Protecting medical records in multi-company environments is a very different challenge than processing credit cards for thousands of merchants.
Central Token Server
The most common deployment model we see today is a single token server that sits between application servers and the back end transaction servers. The token server issues one or more tokens for each instance of sensitive information that it recieves. For most applications it becomes a reference library, storing sensitive information within a repository and providing an index back to the real data as needed. The token service is placed in line with existing transaction systems, adding a new substitution step between business applications and back-end data processing.
As mentioned in previous posts, this model is excellent for security as it consolidates all the credit card data into a single highly secure server; additionally, it is very simple to deploy as all services reside in a single location. And limiting the number of locations where sensitive data is stored and accessed both improves security and reduces auditing, as there are fewer systems to review.
A central token server works well for small businesses with consolidated operations, but does not scale well for larger distributed organizations. Nor does it provide the reliability and uptime demanded by always-on Internet businesses. For example:
- Latency: The creation of a new token, lookup of existing customers, and data integrity checks are computationally complex. Most vendors have worked hard to alleviate this problem, but some still have latency issues that make them inappropriate for financial/point of sale usage.
- Failover: If the central token server breaks down, or is unavailable because of a network outage, all processing of sensitive data (such as orders) stops. Back-end processes that require tokens halt.
- Geography: Remote offices, especially those in remote geographic locations, suffer from network latency, routing issues, and Internet outages. Remote token lookups are slow, and both business applications and back-end processes suffer disproportionately in the event of disaster or prolonged network outages.
To overcome issues in performance, failover, and network communications, several other deployment variations are available from tokenization vendors.
Distributed Token Servers
With distributed token servers, the token databases are copies and shared among multiple sites. Each has a copy of the tokens and encrypted data. In this model, each site is a peer of the others, with full functionality.
This model solves some of the performance issues with network latency for token lookup, as well as failover concerns. Since each token server is a mirror, if any single token server goes down, the others can share its load. Token generation overhead is mitigated, as multiple servers assist in token generation and distribution of requests balances the load. Distributed servers are costly but appropriate for financial transaction processing.
While this model offers the best option for uptime and performance, synchronization between servers requires careful consideration. Multiple copies means synchronization issues, and carefully timed updates of data between locations, along with key management so encrypted credit card numbers can be accessed. Finally, with multiple databases all serving tokens, you increase the number of repositories that must be secured, maintained, and audited increases substantially.
Partitioned Token Servers
In a partitioned deployment, a single token server is designated as ‘active’, and one or more additional token servers are ‘passive’ backups. In this model if the active server crashes or is unavailable a passive server becomes active until the primary connection can be re-established. The partitioned model improves on the central model by replicating the (single, primary) server configuration. These replicas are normally at the same location as the primary, but they may also be distributed to other locations. This differs from the distributed model in that only one server is active at a time, and they are not all peers of one another.
Conceptually partitioned servers support a hybrid model where each server is active and used by a particular subset of endpoints and transaction servers, as well as as a backup for other token servers. In this case each token server is assigned a primary responsibility, but can take on secondary roles if another token server goes down. While the option exists, we are unaware of any customers using it today.
The partitioned model solves failover issues: if a token server fails, the passive server takes over. Synchronization is easier with this model as the passive server need only mirror the active server, and bi-directional synchronization is not required. Token servers leverage the mirroring capabilities built into the relational database engines, as part of their back ends, to provide this capability.
Next we will move on to use cases.
Posted at Monday 26th July 2010 3:08 pm
(0) Comments •
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.
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.
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.
Finally, as with any major application, the token server includes various management functions. But due to security needs, these tend to have additional requirements:
- User management, including authentication, access, and authorization – for user, application, and database connections. Additionally, most tokenization solutions include extensive separation of duties controls to limit administrative access to the protected data.
- Backup and recovery for the stored data, system configuration and, if encryption is managed on the token server, encryption keys. The protected data is always kept encrypted for backup operations.
- Logging and reporting – especially logging of system changes, administrative access, and encryption key operations (such as key rotation). These reports are often required to meet compliance needs, especially for PCI.
In our next post we’ll go into more detail on token server deployment models, which will provide more context for all of this.
Posted at Friday 23rd July 2010 4:22 pm
(0) Comments •
By Mike Rothman
There is nothing like a good old-fashioned mud-slinging battle. As long as you aren’t the one covered in mud, that is. I read about the Death of Snort and started laughing. The first thing they teach you in marketing school is when no one knows who you are, go up to the biggest guy in the room and kick them in the nuts. You’ll get your ass kicked, but at least everyone will know who you are.
That’s exactly what the folks at OISF (who drive the Suricata project) did, and they got Ellen Messmer of NetworkWorld to bite on it. Then she got Marty Roesch to fuel the fire and the end result is much more airtime than Suricata deserves. Not that it isn’t interesting technology, but to say it’s going to displace Snort any time soon is crap. To go out with a story about Snort being dead is disingenuous. But given the need to drive page views, the folks at NWW were more than willing to provide airtime. Suricata uses Snort signatures (for the most part) to drive its rule base. They’d better hope it’s not dead.
But it brings up a larger issue of when a technology really is dead. In reality, there are few examples of products really dying. If you ended up with some ConSentry gear, then you know the pain of product death. But most products are around around ad infinitum, even if they aren’t evolved. So those products aren’t really dead, they just become irrelevant. Take Cisco MARS as an example. Cisco isn’t killing it, it’s just not being used as a multi-purpose SIEM, which is how it was positioned for years. Irrelevant in the SIEM discussion, yes. Dead, no.
Ultimately, competition is good. Suricata will likely push the Snort team to advance their technology faster than in the absence of an alternative. But it’s a bit early to load Snort onto the barbie – even if it is the other white meat. Yet, it usually gets back to the reality that you can’t believe everything you read. Actually you probably shouldn’t believe much that you read. Except our stuff, of course.
Photo credit: “Roasted pig (large)” originally uploaded by vnoel
Posted at Friday 23rd July 2010 2:00 pm
(0) Comments •