Implementing tokenization is much more about understanding how your organization interacts with payments than it is simply rolling out a device that will tokenize payment card data. Many tokenization solutions in the market today are a “silver bullet” and can remove your environment from PCI scope. Beware though, most solutions address only one piece of the tokenization puzzle. Whether it be token generation or storing the token/credit card association, make sure your solution provider has designed, or can develop, a solution to integrate with your payment channels.

Alex Pezold

Alex is the Director of Business Development at True. He is a Certified Information Systems Security Professional (CISSP) and holds Committee on National Security Systems (CNSS) certifications for Designated Approving Authority and Information Security System Professional. Alex has a Masters of Science in Computer Science, with an Information Security emphasis, and has participated in the Federal Service Cyber Corps Program sponsored by the National Science Foundation and Department of Defense.

Don’t be fooled. Implementing tokenization may not be as easy as they say. In fact, depending on your environment, implementing tokenization can be quite complex. For instance, if your company is a wholesaler and takes payments through multiple channels, implementing tokenization in all of those channels can be quite challenging. On the contrary, if you’re a smaller merchant with only one POS, tokenization is probably very easy, but may not be the best solution. Similar to implementing any technology, having the right resources to pre-assess your environment and determine how the technology will be implemented is a critical success factor.

Alex Pezold

Alex is the Director of Business Development at True. He is a Certified Information Systems Security Professional (CISSP) and holds Committee on National Security Systems (CNSS) certifications for Designated Approving Authority and Information Security System Professional. Alex has a Masters of Science in Computer Science, with an Information Security emphasis, and has participated in the Federal Service Cyber Corps Program sponsored by the National Science Foundation and Department of Defense.

How do you know if Tokenization is the right data security solution for your environment? Depending on how sensitive data flows throughout your environment, integrating a tokenization solution may not be the right solution. For instance, tokenizing a very small environment does not make sense if point-to-point encryption can provide the necessary means for data protection. Conversely, tokenization can drastically reduce, if not eliminate, a majority of your environment from PCI Scope.

Determining if tokenization is the right solution for your environment and then determining the right tokenization solution provider are both critical to achieving the correct data security strategy. Experts at True are available to evaluate your cardholder data environment and help you make this determination.

Alex Pezold

Alex is the Director of Business Development at True. He is a Certified Information Systems Security Professional (CISSP) and holds Committee on National Security Systems (CNSS) certifications for Designated Approving Authority and Information Security System Professional. Alex has a Masters of Science in Computer Science, with an Information Security emphasis, and has participated in the Federal Service Cyber Corps Program sponsored by the National Science Foundation and Department of Defense.

Right now two things keep me from getting a good night’s sleep:

The first – the anticipation of whether we’ll experience another earthquake in Oklahoma.
The second – the explosion of transmittal of electronic medical records (EMR) across the Internet.

There is some regulation governing how EMR must be protected, both at rest and while being transmitted. HIPAA arrived in 1996 and gave guidelines on how to protect the privacy and security of PHI (protected health information). HITECH appeared in 2009 and addressed those same concerns during the transmission of PHI, in addition to codifying the financial penalties for data breaches involving PHI. HITECH defined a breach as “generally, an impermissible use or disclosure under the Privacy Rule that compromises the security or privacy of the protected health information such that the use or disclosure poses a significant risk of financial, reputational, or other harm to the affected individual” (read the whole thing at HHS.gov).

But, here’s what scares me.  The payment card industry (PCI) has developed a set of standards, complete with required testing and auditing procedures, dealing with how to protect cardholder data. This was driven by private industry (the banks) since they have a vested interest in preventing breaches (because they are on the hook for fraudulent charges). The industry has refined those standards over the better part of a decade now. Even with those standards, millions of records are stolen each year.

Now I ask you this: if the PCI industry, through multiple iterations, hasn’t been able to completely fix this problem with required testing and auditing standards, what exactly are federal regulations for protecting EMR that are short on specifics and require no testing or auditing going to accomplish? I would posit that the answer is “not enough.” All we can be sure of is that the organizations which lose EMR data are going to incur significant financial penalties.

So, what free advice can TRUE offer to healthcare providers?  Look to ISO for information security best practices, and refer to PCI standards on protecting cardholder data. Just replace “cardholder data” with “PHI” for starters.  Also, keep this Gartner quote top of mind when preparing your 2012 security budget: “The cost of mitigating a data breach is likely to be greater than the cost of preventing the breach beforehand – perhaps by a 70-1 margin.”

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

In case you missed it, the PCI Security Standards Council (SSC) published the initial release of the much anticipated Point-to-Point Encryption Solution (P2PE) Requirements document last month.  Many of you are probably asking, “Why do I care?” – a good question in a day and age with so much information and noise.  If you’ll allow me, I’d like to answer two better questions!  But first, to answer, this document is significant because it is at the heart of the fiery topic of PCI scope.

Now, on to better question numero uno: “Can I use encryption to reduce PCI scope?”  The answer to that question has been – and still is – “no,” with one key exception.  In the PCI SSC’s FAQ entitled, “Is encrypted cardholder data considered cardholder data that must be protected in accordance with PCI DSS?” the SSC presents their reasoning for why encrypted cardholder data needs to be in scope.  The abbreviated version is that encryption only ensures confidentiality if you don’t have the keys.  If someone can gain access to the decryption keys, then they can get the cardholder data.  By keeping the encrypted data and the systems and segments on which it resides in scope, the organization is forced to implement and maintain all of the controls that protect access to those keys.

“So, what’s the exception?” you ask.  Great question!  In the FAQ, the Council states an organization may deem encrypted data out of scope “if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.”  In other words, you may treat encrypted cardholder data as out of scope if you use a managed solution from a service provider that encrypts the cardholder data before it touches your environment and the service provider maintains sole possession of the key to decrypt it.  The most basic example of this scenario is an encrypting card reader.

Prior to the release of the new requirements document, no real guidance for service providers and merchants existed on how to implement a compliant solution to this exception.  This document provides the needed guidance and makes some significant changes to the PCI program in the process, including the following:

• The development of a new P2PE Requirements Standard (the document referenced above)
• P2PE QSAs to validate the P2PE solutions
• P2PE PA QSAs to evaluate applications on PCI-approved POI devices for point-to-point encryption solutions
• A training and certifications process for P2PE QSAs and PA QSAs and their companies

The Council plans to roll out these new programs, training and certifications throughout the remainder of 2011 and 2012.

The P2PE solution requirements have the greatest impact on the service providers who have already rolled out P2PE solutions.  Merchants who are using or considering such solutions should also stay tuned.  Now that the requirements have been released, some providers may decide their P2PE solutions are not worth the annual audit compliance costs they must incur for merchant use.

Unless there are any more questions, I’ll close with that!

Dominic Schulte

Dominic Schulte currently serves as the Managing Director of Security Services & Consulting at TRUE, where he is responsible for the execution of a wide range of security and regulatory compliance services. Previously, Dominic worked with the National Security Agency (NSA) as a Global Network Exploitation and Vulnerability Analyst in the National Security Incident and Response Center (NSIRC). He holds CISSP, QSA and CNSS 4011-4015 certifications.

The point of my catchy title is not to remind you of the popular 80’s Tom Cruise movie (though most of you are probably already hearing the opening piano riff from Bob Seger’s Old Time Rock & Roll racing through your mind). My intent is to explain the ‘Risky Business’ of waiting too long to begin a governance, risk and compliance program.

Far too often I see companies wait …and wait …and wait because they don’t think they need an IT GRC program. I continuously hear statements like, “We’re not big enough,” “We’re not ready,” “We don’t have the budget,” or my personal favorite, “We really don’t have any risks to warrant such a program.” And that’s usually When it happens – a data breach (a laptop goes missing with sensitive data, a key financial system gets hacked, a disgruntled employee sabotages a legacy system) or any type of compliance deficiency. That’s When it’s too late to be proactive with GRC and ‘Risky Business’ sets in.

Why is waiting so risky? Well, now a company has to take reactive security measures and not only has to implement some type of IT security or GRC initiative, but also has to simultaneously manage the chaos and events from the fallout of the data breach. And, who knows how many thousands of dollars will be spent in remediation of the breach. Far too often these companies end up spending significantly more than they would have had they proactively implemented the GRC program months earlier, before they felt the pain of a data breach.

Does having a GRC program make you bullet proof from a data breach? No, but it does show your stakeholders that you take security seriously, and you had safeguards in place to prevent such an attack. And, having a sound GRC program puts you in a much better position for breach response.

This business of risky management vs. risk management is a sad but true trend in the IT GRC space. The solution: begin an IT GRC program before you feel the pain from the ‘Risky Business’ of waiting too long to say Now.

Tommy Thompson

Tommy Thompson is True's Director of Program Development Services, specializing in IT GRC and security program initiatives. Tommy has implemented successful IT GRC programs from start to finish, gaining valuable experience and lessons learned to develop a proven, proprietary True IT GRC Framework Methodology used to guide clients to IT GRC success. Tommy has presented at multiple IT conferences; served as a Director of the Product Enhancement Committee for a leading GRC Platform software solution; and has consulted multiple Fortune 100 and 500 companies.

Perhaps one of the biggest questions facing the leadership of businesses and organizations in today’s Governance, Risk, and Compliance space is “What do I do first when it comes to implementing an IT GRC Program?  Do I procure an IT GRC software solution (platform) first and then implement the program while building out and configuring the platform?  Or, do I first develop and implement an IT GRC program and then procure an IT GRC platform down the road?  And, if the latter is the case, how do I know when the right time is to begin that procurement?”

All very good questions, and like most things IT GRC related, there’s no “silver bullet” answer.  There are, however, lessons learned and best practices that can be followed to make the best possible decision for your particular company or organization.

One paramount lesson that is continuously learned the hard way by companies and organizations is realizing the procurement of an IT GRC platform in itself is not going to create a stable, effective IT GRC program.  Typically, what happens in this scenario is a company now owns a big software application that nobody knows how to use to manage the GRC program – not even the company that sold it to them.

Why does this happen?  Because IT GRC is not a software solution, but rather a program and process.  In order to successfully implement an IT GRC platform solution, you must first have a clearly defined IT GRC program in place.  And, once the program is in place, it will continue to evolve with changes in requirements and guidelines.  Therefore, the configuration requirements for the GRC platform should be continuously defined even after the IT GRC program is implemented.  While the program and platform can both come at the same time, or one before the other, the Program always defines the Platform, and therefore, I recommend organizations develop the program first.

Tommy Thompson

Tommy Thompson is True's Director of Program Development Services, specializing in IT GRC and security program initiatives. Tommy has implemented successful IT GRC programs from start to finish, gaining valuable experience and lessons learned to develop a proven, proprietary True IT GRC Framework Methodology used to guide clients to IT GRC success. Tommy has presented at multiple IT conferences; served as a Director of the Product Enhancement Committee for a leading GRC Platform software solution; and has consulted multiple Fortune 100 and 500 companies.

I was recently discussing IT GRC program implementation with the CIO of a growing, mid-sized software company when he presented the question, “But HOW do you do it?  I mean, how do you get employees to follow the rules in a GRC program?”  The following is the second part to my response to his question…

…After the matrix team is established, a series of environmental assessments and gap analyses relating to risk, controls, policy and procedures, etc. begins.  Process and control owners get involved in updating and/or creating necessary key control processes in the form of process maps, risk matrices, control and risk standardization and integration, test plan development, etc.  Around this time we also recommend that businesses begin working on procuring a system of record that is going to house it all.

Once the control environment begins to take shape, the Compliance and Awareness Training Phase – another critical element of the program – is developed.  This step is probably one of the most critical success factors of the entire implementation because it allows management to communicate the IT GRC vision, while allowing process and control owners to train and delegate that vision to their teams.

As a result of this training, the matrix organization understands compliance initiatives will be measured using a series of self-assessments, with results reported to Executive Management, the Board of Directors, Audit Committees, etc.  Conversations about controls and applications not operating effectively, test failures, significant deficiencies, etc. will create immediate incentive in the minds of the process owners to ensure their teams begin “following the new rules.”

Self-assessment testing should be followed by training and awareness sessions that report the results to the matrix organization.  Rewards and public recognition for successful testing creates incentive to keep doing it, which naturally stabilizes the control environment with sustainable operational effectiveness.  Public embarrassment (for lack of a better term) creates immediate incentive for remediation to occur in areas that are operating ineffectively, and the environment again begins to naturally stabilize.

Following this framework, we have seen clients go from hundreds of deficiencies and multiple ineffective applications to no deficiencies, no ineffective applications, and only a few exceptions noted (which is an acceptable risk because you can’t manage to perfection).

True doesn’t implement the IT GRC Program for you.  We enable you and your teams to be champions for the organization by transferring our knowledge base and expertise directly to you.

After a short pause this CIO responded, “Sweet!” He is now a client.

Tommy Thompson

Tommy Thompson is True's Director of Program Development Services, specializing in IT GRC and security program initiatives. Tommy has implemented successful IT GRC programs from start to finish, gaining valuable experience and lessons learned to develop a proven, proprietary True IT GRC Framework Methodology used to guide clients to IT GRC success. Tommy has presented at multiple IT conferences; served as a Director of the Product Enhancement Committee for a leading GRC Platform software solution; and has consulted multiple Fortune 100 and 500 companies.

Vulnerability scanning. Mention those two words, and your IT operations staff usually shudders. Conversely, your IT audit/security staff usually start doing a happy dance (I think those guys are sadists, like Steve Martin in Little Shop of Horrors.) Love it or hate it, vulnerability scanning is required by many compliance regimens. The PCI DSS states that you have to perform vulnerability scanning quarterly, and from both an external and internal perspective. If you follow the letter of the PCI law, that’s at least eight scans a year. I would like to posit that if you’re really doing PCI vulnerability scanning correctly, it’s more like a minimum of 12 scans each year, with 16 being the better number.

Where do I get that number, you ask? Well, it all depends on where you are scanning from…

External scanning is pretty straight-forward: you scan from a location external to your public IPs and see what vulnerabilities show up. There are vulnerability scanning services that can do this for you. The trick here is to white list the scan source IP(s) on any devices that may actively modify or deny traffic. Examples of these devices are intrusion prevention systems, some load balancers, denial-of-service prevention proxies, etc. PCI DSS 11.2 requires at least quarterly external scans, so that’s four scans each year.

Internal scanning is a bit more difficult. PCI DSS 11.2 requires at least quarterly internal scans as well, but you very likely have more than one internal network segment. If you have PCI data, I believe you have at least three segments: a DMZ, a CDE (cardholder data environment), and your internal business operations network. So when you scan the CDE, which segment should you scan from, the CDE, the DMZ, or the business network? The answer is: Yes.

If you scan from the CDE, you will see a lot of vulnerabilities that are exploitable only from the CDE network, since you (should) have firewalls in place that severely limit traffic inbound to the CDE. That’s four scans each year.

If you scan from the DMZ, you may see a lot fewer vulnerabilities, but you’re probably going to be missing some easy-to-fix stuff in the CDE that should be remediated just in case an attacker does manage to make it inside the CDE. Scanning from the DMZ is another four scans each year.

If you scan the CDE from the business network you will be seeing even fewer vulnerabilities (since you are going through a firewall at the DMZ< ->business network and CDE< ->DMZ boundaries). But let’s be honest: your users are your weakest link, and as they go about their merry way during the business day surfing the web (when they should be working), they will visit a few off-color sites (or even legitimate sites that have been hacked) that exploit their browsers, drop some malware on their computer, and give an attacker a foothold on the business network. Clearly you need to know what the threat landscape is on the CDE from the business network because USERS ARE STUPID. Four more scans each year.

That puts us at sixteen scans. Maybe you choose to short-change yourself and not scan from the local CDE network, which knocks four scans off the count, but if you’re already doing 12 scans, is performing four fewer scans really worth not having an accurate picture of the CDE’s threat landscape? I would say it’s not.

Brett Edgar

Brett is a Founder and the Director of Managed Security Services at TRUE. He has been working in the system and network forensics field since graduating from the University of Tulsa with a B.S. Computer Science in 2003. He speaks hexadecimal fluently and is TRUE's resident human Ethernet transceiver. He holds CISSP, CSSLP, and CNSS 4011-4015 certificates, loves MLB and NCAA Football, and when he gets tired of hexadecimal, he goes home to hang out with his wife and kid.

Twitter - More Posts

TRUE’s latest event brought together a select group of industry thought leaders to discuss various aspects of risk management theories and principles as well as the metrics involved in executive-level decision-making.

Attendees benefited through open and candid exchange with peers on how risk impacted the various organizations. Participants conveyed how risk is defined within their respective companies and discussed quantitative vs. qualitative risk assessments and the concept of company-defined acceptable risk.

Hosted at Tulsa’s Summit Club, the exclusive event began with a cocktail hour, followed with dinner and lively discussion.

TRUE intends for The Round Table to be an annual event that serves as a forum to enable the mindshare of highly respected information security executives from various industries in years to come.

Kayna Kelley

Kayna Kelley is True's Marketing Manager and Technical Writer with responsibilities of managing True's marketing and sales support efforts. Kayna received her undergraduate and MBA degrees from Oklahoma State University and has rich experience promoting B2B technology companies.