PCI DSS Compliance and Security: Harmony or Discord?

September 02, 2010

The Payment Card Industry Data Security Standard (PCI DSS) provides data protection requirements for organizations that process card payments. These requirements evolve over time and have even become adopted by some US states, including Minnesota, Nevada, and Washington. While organizations that fully comply with PCI DSS are considered secure credit-card processors, compliance and security are not one in the same. An organization can be compliant and still experience a security breach – look no further than Heartland Payment Systems and RBS WorldPay. Both had achieved PCI DSS compliance at one point, only to suffer massive data breaches that cost tens of millions of dollars. So what good is compliance? What is the difference between compliance and security? And how can organizations effectively move beyond PCI DSS compliance to ensure the security of all their critical information?

Transcript:

Sam: Hello everyone, and welcome to this Lumension webcast titled, "PCI DSS Compliance and Security: Harmony or Discord." My name is Sam Erdheim [SP] and I'll be your moderator for today's event.
 
The Payment Card Industry Data Security Standard provides data protection requirements for organizations that process card payments. These requirements have evolved over time and have even become adopted by some U.S. states, including Minnesota, Nevada, and Washington. While organizations that fully comply with PCI DSS are considered secure credit card merchants, compliance and security are not one and the same. An organization can be compliant at one point and still experience a security breach. So what good is compliance? What's the difference between compliance and security? And how can organizations effectively move beyond PCI DSS compliance to ensure the security of all their critical information?
 
In today's webcast, we'll answer these questions and we'll examine the evolving threat and compliance landscape, how to use compliance as a catalyst for developing and implementing an effective security program, six critical elements to achieving effective and economical PCI DSS compliance, and how one organization is going beyond PCI DSS compliance and further enhancing its security of information.
 
We're lucky enough today to have a very distinguished panel with us to engage in this conversation. Michael Rasmussen, risk and compliance lecturer, writer, and advisor with Corporate Integrity. Michael is a leader in understanding risk and compliance standards, frameworks, regulations, and legislation, with more than 15 years of experience in the governance, risk, and compliance space. William Bell, Director of Information Systems with EC Suite, which is a global e-commerce solutions provider, located in Tempe, Arizona. William works to ensure that his company meets their service provider level one PCI compliance obligations, while protecting the sensitive consumer data his company collects. And Chris Merritt, Director of Solution Marketing with Lumension. Chris has worked for over a decade in the software industry, and at Lumension, he leads the market positioning and strategy for Lumension's endpoint and data protection solutions. He routinely delivers compliance and security related presentations, white papers, webcasts, and is a regular contributor to the Lumension blog. Welcome gentlemen, and thank you all for participating in today's discussion.
 
Before we get any further, I wanna open up a polling question for the audience. What is...let's see here, what is your driving motivator with regards to PCI DSS? Is it A, to ensure compliance to avoid penalties, reduce the burden and cost of PCI DSS audits, protect cardholder data, or gain competitive image, or insurance against legal claims?
 
While you take a look at that and make your votes, just one housekeeping point. At any point during this webcast, if you have questions, you can submit them to us via the questions tab at the top left panel of your screen. We'll try to answer as many of them as we can. Michael will first present some of his research findings. Then we'll open up for a discussion with Michael, William, and Chris to discuss PCI compliance and security, and the different perspectives they each can bring to this discussion.
 
So with that, please get your votes in, and we will take a look to see how everybody feels about this question. I'm going to, we'll give it, we'll leave it another 10 seconds and then I will close the poll...Okay, and it looks like 41% are really focused on protecting cardholder data, and 38%...oh, I guess we still have votes coming in, 40% with compliance to avoid penalties. So it looks like the avoiding penalties and protecting cardholder data are kind of the two major things. I'd like to open up one more polling question that actually brings up some interesting things. William, real quick, with regards to, you know, your experience, what's EC Suite's driving motivator? How does it stack up compared to what our audience is voting?
 
William: Well, you know, definitely protecting cardholder data, not so much from a legal requirement, but definitely from the, you know, threat against fines, and leverage, etc. from a merchant account's perspective. But also, and foremost, a PR issue, right, making sure that, you know, we protect our consumer's data, and, you know, we're not in the news, the person that lost everything, etc. So that's very important for us.
 
Sam: Okay, great. Thank you. One more poll question for the audience here. Actually, you know, we'll get back to that later. Let's move on to Michael's presentation. I'd like to get through that, and then we will go through one more poll. Michael, I will turn it over to you now. Thank you.
 
Michael: Sam, thank you. It is certainly a pleasure to be with everybody virtually for this next hour and talking about, you know, how to really approach PCI DSS compliance and security, whether we can attack all these two concepts as harmony, or are they really in discord with each other. But to really start the thought process moving forward, we're gonna talk about some of the evolving threat and compliance landscape.
 
Particularly, there's been a recent survey out from Verizon, and their 2010 data breach investigations report. And they basically were surveying how do breaches occur? And we find out that, well, Verizon specifically found out that 48% involved privilege misuse, so too much access being given, and people are abusing that, 40% resulted from hacking attempts, probably, most likely external hacking, 38% utilized some form of malware, 28% employed social engineering tactics, and you can see the growth in these in the parentheses off to your right, and 15% comprised physical attacks to get into the IT environment as well. So, you can also see that another piece of data that 85% was, you know, organized by criminal groups, and 15% by their agents.
 
So some more specifically things that the survey from Verizon pulled out that I wanna draw to your attention before we get into the depths of this is that 85% of the attacks really weren't that difficult. They were rather easy to gain access to. This goes hand in hand with the figures we just looked at in the left there, where 48% involved privilege misuse. So if the access is already being given, too much access to individuals or roles, that can be a very easy compromise and attack. Web application vulnerabilities continue to be the attack vector of choice from the hacking side, and cyber criminals use stolen account logins in 38% of the successful data breaches, and if those stolen account logins have too much access, and aren't monitored correctly, we lead to the disasters that we have, that we are just going through.
 
But let's step back in time and look at a lesson from history. The Titanic, going back 100 years ago. What went wrong with the Titanic? Well, actually it wasn't one thing, it was a multitude of things. Captain E.J. Smith of the Titanic stated that, "Never in all history have we harnessed such formidable technology. Every scientific advancement known to men has been incorporated into its design. The operational controls are sound and foolproof."
 
Well, we know what happened with the disaster of the Titanic, and how unfortunate that was and the loss of life. But the things that went wrong, you couldn't just blame one thing. You had several things. You had overconfidence in the ship's design, you had a push to get her across the Atlantic quickly to show its speed and power, you had somebody that decided somewhere that we can set sail with the ship with a lack of the proper number of life preservers and lifeboats that don't adequately cover the passengers. You had somebody ignoring warnings of icebergs in the area, as well as somebody else not paying attention on watch for an iceberg that was coming before the ship, and you even have speculation that there's some poorly manufactured bolts and that when that ship hit, the Titanic that is, hit the side of the iceberg, it ripped open and caused a giant seam that would have water flooding in. You take away any one or two of those risk conditions, those vulnerabilities, those exposures, and we might not have had the same disaster that we now know as the Titanic.
 
The same thing happens in your organization today. It's not just one vulnerability, but it's a whole chain of different vulnerabilities and risk conditions. We just looked at that survey a few minutes ago, and referenced numbers in which, you know, 15% of them involve some type of physical attack, privileged access, hacking. You know, it's just not one exposure and vulnerability, it's a compound of several things that actually expose your organization. So just one issue and solving, putting out one fire doesn't necessarily mean you're secure. You have to think of the range of things that are impacting your business and look at risk holistically and all the different vulnerabilities and exposures, and how any specific perpetrator or miscreant can leverage the range of things that are available to them to compromise cardholder data in the case of PCI DSS, and steal that.
 
So some food for thought. The problem with a lot of risk and compliance in this IT space that we're working in is that we tend to focus on a lot of projects, that compliance is its own project, we complete it in time to come out and get our assessment on PCI or whatever else we're up against, and then we sort of close the door on the project, and might have some minor ongoing processes until things heat up again, and we have another annual assessment coming up. I see a lot of organizations focused on this point in time compliance, as well as point in time risk and vulnerability assessments, and that just doesn't work. That's a recipe for disaster.
 
Business is dynamic. It changes, minute by minute, second by second. New employees come into the organization, they change roles in the organization, they exit the organization. Think about that. We provision them with access. When we change roles, do they still have the right access? Do we revoke the access they don't need anymore? And when they exit the organization that we revoke their access. That's just not employees, technology changes. New systems are deployed. Others are patched and updated. Configurations are changed. Others are taken out of service. New network access is given to business partners, and information's thrown across different business relationships, and travels around the world.
 
Business is very dynamic, and if we're gonna manage compliance and security as point in time projects and assessments, well you might be compliant today at, you know, what is it, 10:14 central time where I'm at. Ten fifteen, we're out of compliance, because nobody is continuously monitoring things, nobody's managing on an ongoing basis. Something changed in the organization, an employee changed roles and they have too much access, because their old access wasn't revoked. There's not proper segregation of duties. An IT system was changed and some security settings were rolled back, or something hasn't been patched properly for a new vulnerability that was just out.
 
Compliance, with security, needs to be an ongoing and continuous process. If you're gonna manage compliance as a point in time project, well, compliance and security are gonna be in discord all the time. But if you're gonna manage them as a continuous process, that's where we get the harmony that we're gonna be talking about.
 
But think about it, if we're gonna manage risk, compliance, security, as their individual siloed projects, we're gonna have a PCI DSS project, and actually, a lot of organizations might have multiple PCI DSS projects, because they'll take each element of PCI DSS and spin off its own project. And they'll focus on the here and now, and not a continuous process. Well, all these different risk and compliance, these security issues, whether it's just...and we're talking about PCI DSS, but we can throw in mandatory disclosure laws, we can throw in HIPAA, and GLBA, and HITECH, and, you know, a variety of other things, as well as international regulations, the EU Data Protection Directive, Canada's Personal Information Protection Electronic Documents Act or Japan's Personal Information Protection Act and more.
 
And we're gonna manage of each of these as their little siloed little initiatives and solutions and processes. We lack visibility. There's no cohesive view across security and compliance across the IT systems, which ultimately means we have wasted and inefficient use of resources, because we have multiple ways of doing things. We've got multiple solutions to address very similar problems. I've seen organizations that have overlapping redundant controls because they've tackled each compliance area as its own separate project, instead of streamlining controls and find out how one control can meet a multitude of regulatory requirements.
 
All this leads to unnecessary complexity. The organization has become very complex, and when business wants to change and IT has to react to it, well it's slow. We're no longer agile, because we're no longer flexible because the business has become so complex in how we manage compliance and security that we don't have one single cohesive view into it. And with that, we ultimately are counterproductive to what we're trying to accomplish. We have more vulnerability and exposure, because there's multiple projects and assessments going on instead of a streamlined approach to manage all this consistently and holistically across the organization.
 
So, PCI DSS, harmony or discord? Well, we all pretty much probably should know on this call already that the payment card industry standard really is aimed to protect payment cardholder information. So we're trying to secure the credit card numbers and associated security around those from compromise and attack.
 
Compliance and security though, as I've already illustrated, are not necessarily the same thing. An organization can be compliant and experience a security breach. Or they can also be non-compliant and maintain a secure infrastructure. The two do not go hand in hand, but however, they can work in harmony with each other. You can leverage your compliance initiatives for PCI DSS to maintain an ongoing process, with a single view into compliance, holistically, to provide a secure infrastructure. But if you're gonna manage security separate than compliance, we're gonna often have discord, and there's gonna be duplicated efforts and wasted spending. So the challenge for us is how do we achieve harmony? How do we make compliance and security work together hand in hand and get a situation where the organization's actually protected, as well as being compliant with the laws and regulations?
 
The value of compliance itself is it should be used as a catalyst for implementing effective security measures. The business doesn't just throw money at security. But compliance gives them the momentum and initiative to address security. So this is significant, because where a lot of businesses might not approach security, PCI DSS gives the IT security manager, security officer the cards they need to play to make sure that security is achieved in the enterprise. As we've already seen in the polls, people don't want fines, they don't want penalties, and the state of compliance is important for business operations because of that.
 
Another value of compliance is it requires an understanding of the principles behind the requirements, not just the adherence to minimum requirements. If we're gonna take a checkbox approach to compliance or even security, well, there's a lot of places where we might not have checkboxes properly defined. We need to take a principles-based approach. What are we trying to achieve? And understand that the requirements laid for us in PCI DSS and other areas really set, you know, our minimum benchmark. You know, that's just that basics we need to get done, but then it might not really address security holistically in our environment. What steps do we need to take beyond that to provide the adequate level of security? Security is more than just a list of checkboxes. We need to get to the principle behind it.
 
Compliance standards such as the payment card industry standard provide a foundation for achieving security, but does not adequately protect the organization itself. PCI DSS is aimed at payment card data. Well, we might house a lot of other types of data. Maybe you're a health care organization. And we're not just concerned about payment card data, we're concerned about personal health information, or protected health information. It's a point to consider, how can we leverage what we're doing for something like PCI DSS and use it for other areas of compliance as well.
 
...So, I've already painted a picture. We have a grim view of what I call Dante's Inferno, where we have unnecessary complexity, inflexibility, wasted resources, compliance and security we manage in little silos without a holistic approach, with greater vulnerability and exposure.
 
Well, let's start thinking differently. Let's understand what we're up against. The big picture of compliance, whether we're dealing with PCI DSS or other areas of compliance, is we have two levels of boundaries. We have our mandated boundary, which is our laws and regulations. This is things like HIPAA and GLBA and mandatory disclosure laws and other areas. But we also have voluntary boundaries, which include contractual requirements. Interesting enough, PCI compliance is not a mandated boundary. You're not required by law...well, you are now in three states, as Sam has already mentioned, so PCI DSS is sort of on this hybrid area, because it's both a mandated boundary in certain states as well as a voluntary boundary, because it's a contractual requirement.
 
But if you are operating in those states and you don't necessarily have to be PCI DSS compliant. It's a voluntary requirement, because you don't have to accept credit cards. But if you want to accept credit cards, and you wanna be able to accept Visa, Mastercard, American Express, well then you have to be PCI DSS compliant. It's your choice in the business. That's why we categorize it as a voluntary requirement, even though from a practical business perspective, it's really not voluntary, it's a necessity for doing business.
 
But other voluntary requirements include your risk culture, and different code of conduct and values of the organization. I was in one large insurance company recently, and they stated, "Yes, we are managed to protect personal financial information as a matter law, but it's really much more of a voluntary issue, because we go well above and beyond the law." And they pointed back to their mission statement in the 1800s, and stated, "This is what protecting personal information, financial information within our insurance company is all about." Because the mission statement stated "Being there for the customer and doing the right thing for the customer." So beyond laws and regulations, we voluntarily put the bar much higher than where it's required, because we're gonna do the right thing for the customer. It's their information, we're gonna protect it. So it's about managing both mandated boundaries and voluntary boundaries.
 
My apologies, I'm getting trigger happy with the slides. So we need to understand and come up with a process for managing compliance for PCI DSS and with that security around the payment card data. And the most solid approach for this in my mind is the GRC capability model from the Open Compliance and Ethics Group.
 
Now I know a lot of us are using ISO 27000, and I fully support that, and that gets down into the details, in the weeds, and that's extremely and critically important, but the GRC capability model took in 27000, and ISO 31000, and COSO ERM and internal control frameworks, and a variety of other frameworks out there, including the standard benchmark for compliance established by the United States Sensing Commission, Organizational Sensing Practices, and its seven elements, and came up with a common process model for managing governance, risk and compliance, what we know as GRC within the business.
 
It all starts with the culture and context. Well, the context for the business is, well, we have to be PCI DSS compliant, because we're accepting those credit cards. We also have other laws that bear upon that same type of information perhaps, like mandatory disclosure laws and other privacy laws. There's the culture of the organization itself, as I mentioned that insurance company that stated, "This is just the whole approach for protecting privacy and personal information within our organization. We set the bar high because it goes back to our mission statement in the 1800s of doing the right thing for the customer."
 
So culture and context surrounds everything. Organize and oversee means who's accountable, who's responsible? What are their roles and responsibilities for PCI DSS compliance? If we're gonna break out the 12 main areas of PCI DSS compliance, who's responsible and accountable for each area? And how do they manage that as an ongoing process? Assess and align is the risk assessment process, which is becoming more critical with the changes happening in the PCI DSS in the upcoming month. As the new updated standard is released, one of the changes is risk assessment, and addressing vulnerabilities on a risk-based approach.
 
Prevent and promote gets into the policies and procedures to communicate how information is gonna be protected. In this case, payment cardholder data. Detect and discern is the ongoing monitoring for vulnerabilities and exposure points. And respond and resolve is when there is an incident, we're monitoring for incidents on a ongoing basis, so that we can respond to the incident rapidly when it happens, and we're gonna have an investigations process, and when mandatory disclosure laws and other requirements kick in, we're gonna follow those. Monitor and measure is the metrics and monitoring ongoing. But inform and integrate's the heart of this all where we have some type of platform that centrally manages PCI DSS compliance on ongoing and continuous basis.
 
As we look at risk assessment processes, and that assess and align piece, my encouragement is to give a significant and close look to ISO 31000. ISO 31000 was established as a standard and based significantly on the Australia/New Zealand 4360 risk management standard. Where ISO 27000 gives guidance on that you should be doing a risk assessment, but doesn't give a lot of details, it now refers over to ISO 31000. ISO 31000 isn't specific to information security and IT risk, but it's something that's flexible and adaptable to a lot of areas of risk areas. And I have encouraged organizations to take a close look at using ISO 31000 as an IT risk assessment process, particularly as organizations facing PCI DSS compliance are gonna be challenged to develop a risk-based approach for vulnerabilities and exposures based on the new requirements coming out from my limited understanding of that.
 
So let's take a quick tour of the six critical elements to achieve economies in PCI DSS compliance and beyond. The six elements we're gonna look at is agility, consistency, efficiency, transparency, accountability, and security.
 
It starts with agility...It starts with agility. So agility is there to ensure continuous compliance. As I mentioned, business is dynamic. It changes minute by minute, second by second. You can be in compliance at 10:27 Central time now, and again, within two or three minutes be out of compliance because IT systems have changed, access has changed, employees have changed, business partners have changed.
 
You need to manage compliance on an ongoing and continuous basis. That means we need a foundation and architecture for managing PCI DSS that enables agility, because it's continuously monitoring the environment, which includes full ongoing discovery of the IT environment, its information technology assets, understanding where that cardholder data is stored, how it moves across the organization and who has access to it. The ability to automatically assess the network and devices that connect to the network for the state of vulnerability and exposures, automate the IT risk assessment to provide structure around the collecting of evidence for compliance controls, enforce policy for software updates, security patches, and standardized configurations, and provide flexibility to handle unique needs and requirements, because again, PCI DSS just establishes a baseline for us. Maybe there are certain areas of the business where we need to put in additional security controls because of additional risk. And as the new requirements in PCI DSS become more clear, we're seeing that there's gonna be much more of a risk-based approach to some of this. So these elements become all the more critical for organizations.
 
The second point to address in economies for PCI DSS compliance and security is consistency. You wanna streamline compliance workflows and process. If the different elements of PCI DSS compliance are gonna have their own separate processes and supporting technologies and workflows and tasks that individuals have to do around them, we have a mess. We don't have any type of centralized accountability and consistent framework to work within. And you multiply that by not just PCI DSS compliance, but other issues of security and risk and other compliance areas bearing down on the organization and its IT infrastructure, and we have a mess.
 
But if we can provide a consistent technology backbone and architecture and framework, where we can manage compliance and risk processes to IT and information consistently through workflows and task management, things become more consistent, and we have a consistent and a holistic view into the state of compliance, as well as security. This includes the ability to have a comprehensive inventory and management of IT systems that store, communicate, transmit, and interact cardholder data. We wanna consolidate the, have a consolidated console for visibility of the physical as well as the virtual environment and the controls around them, and the state of compliance.
 
We need IT asset management, where we have a clear inventory of our applications, databases, servers, networks, but also the physical environment of the data centers, as well as people and processes themselves, being able to understand how the different elements of the IT infrastructure and environment, as well as the people, bring together the processes that interact with cardholder data. That way we can understand and model the risk around the whole process, and achieve compliance and security together.
 
You wanna be able to continuously monitor compliance and IT risk postures and enforce mandatory baselines for systems. We want the ability to add, create, define, edit, import, export security configurations and checklists, so that they're up to date and current as technology changes, and be able to normalize common controls across standard regulatory requirements into a single control.
 
Again, if we have PCI DSS requirements, we also HIPAA or GLBA, or other laws and regulations. What's the common controls we can have? Can we approach this where we have a common control library, where we can map one control or one policy and be able to show how it meets multiple risk requirements?
 
The third element to look at is efficiency. Here we want to automate compliance and security processes, both of them, together. Efficiency is what the business wants. The business is tired of being hit with assessments week after week for different purposes. This week it might be some type of assessment around cardholder data for PCI DSS, line of business next week has some hit, would get hit by the week after that in operational risk, the week after that, a business continuity one. How do we streamline and automate the compliance and security processes to be more efficient, to manage them continuously in a very dynamic and changing business environment?
 
Well, some of the points we need to address, multiple management needs through a single compliance architecture and solution, maximize organizational IT flexibility with automated enforcement, saving both time and effort, so there's less manual checking and involvement. Implement standard configuration checklists with a repository of software vulnerabilities which provides context to properly maintain security and control of cardholder data, and automate risk profile analysis to save time over manual risk analysis practices.
 
The fourth element to look at today is transparency. Here we want to ensure visibility of IT risk across the organization. Transparency means that we want a full view, that we don't want just a system-by-system view, and have to go to different reports for each different system having, housing cardholder data, but we want to be able to holistically see metrics and monitoring of PCI DSS compliance, as well as the state of security of the organization across the business, and be able to drill down where you need to get more information, as well as see the aggregate level.
 
Here we want to provide harmonization of compliance controls across a range of mandates, understand holistic risk of cardholder data that flows across multiple information systems, multiple processes and departments, and even in [inaudible 00:30:23]] business relationships. How does information move across the organization? Not only how am I compliant with PCI DSS, but can I have some metrics and monitoring on how my business partners are compliant that interact with that same cardholder data. This include collecting device security and configuration information to provide consolidated visibility, and provide a global view of vulnerability status for all organizational assets at a glance. You wanna be able to document changes and demonstrate progress toward audit and compliance requirements, and ultimately be prepared for PCI DSS QSA audits.
 
And right there, the more information that you can provide and show people that you're managing this on an ongoing and continuous basis and you have a complete view into this, this transparent view, the easier your audits are gonna be. But, as I've found out time and time again with many organizations, if they don't have all this data together in one place for easy reporting and ability to give the auditors, it makes the auditors work more, and dig more, and they find more. Because an organization that doesn't have all this information together, it's just an indicator that hey, there's gonna be holes here. There's gonna be exposures, because they don't have all this information ready for me. And so it's just one area where you can help manage the process and get through audits much more efficiently if you have that transparent view and to be able to provide the information when it's asked for.
 
The fifth element to look at is accountability. Here we want to ensure that no stones are left unturned, and we want a complete view of PCI DSS compliance, again, we [inaudible 00:32:02]. We want to make sure all the different roles within PCI DSS compliance, as well as security, are being addressed, and there's individuals being held accountable for the status of them. And that when there is a vulnerability and exposure that crops up, that that person can be held accountable for remediating that vulnerability and managing the risk around that. And that there's proper risk owners to find for the organization and policy owners, and that there's accountability all levels of security in PCI DSS compliance.
 
We need to be able to achieve through this accountability a constant state of audit readiness, because again, we might be compliant at a point in time, but security particularly needs to be an ongoing continuous process. And with that, if we address compliance and security together as ongoing continuous process, so we're at that constant audit readiness, where we've achieved this harmony we're talking about. Workflow-based surveys need to be addressed to ensure accountability for procedural and physical controls, stakeholder surveys to determine the business impact of risk scenarios that compromise the confidentiality, integrity, and availability of cardholder data. We need a risk-based analysis of IT posture, and vulnerability and exposure to the IT world, and so forth.
 
We'll move on to number six now, the last one, security. And I bring this about because security itself is ultimately what we're trying to achieve. It's not just about compliance and crossing our T's and dotting our I's correctly, checking the checkboxes, but are we providing the right environment to the right level of security to mitigate risk to what the appropriate risk level is in the organization, what the risk culture of tolerance and appetite is?
 
So I wanna ensure continuous security policy enforcement, where you identify controls and enhance security cardholder data, while meeting the compliance requirements. How do you bring those two together and merge them? We need to assess threats, vulnerability and patch status and security configurations, installed software and hardware inventory, and manage that on an ongoing and continuous basis, because things change. New vulnerabilities and exposures are uncovered, and what was a state of acceptable risk is now unacceptable because of new vulnerabilities and exposure. We need to manage this on an ongoing basis. We need to remediate software and endpoints that store, transmit, and interact with cardholder data. And, that doesn't say eliminate them. We need to remediate risk in them by implementing proper endpoint security. Automate enforcement of malware protection and endpoint security, quickly respond to issues and visibilities when they arise. So we have an ongoing monitor for security incidents and events, and with that a investigation management process that is clearly defined, and continuous monitoring of the security policies and the environment.
 
So, I've gone through those six elements, and to go beyond securing cardholder data and enforce policies to protect all critical information, so that we bring harmony between both PCI DSS compliance and security. The more critical abilities we need to look at and to review is the ability to discovery and inventory and categorize your information systems and the supporting technology infrastructure, monitor the vulnerability and exposure and PCI DSS compliance together, that we're monitoring for security and particularly the PCI compliance requirements. Remediate and maintain compliance to PCI DSS, manage security configurations across all the endpoints in the enterprise, as that can often be the backdoor that's led to the compromise and vulnerabilities that we're trying to avoid. You wanna control removable device use and enforce data encryption, particularly if it's removable devices that are being used to transmit personal financial information, particularly with PCI DSS, the cardholder data. Streamline overlapping technical and procedural controls across our compliance obligations. We wanna maintain trusted application use. Enforce compliance. If you have evolving requirements, enable reporting. Those are those elements, and I wish I could have had a full day to go through them, because we could spend an entire day on that, and I've already gone over time, but I'd like to turn this back over to Sam to lead us in the panel Q and A.
 
Sam: Thank you, Michael. I'd like to open up another poll for our audience, and we're gonna ask, "Do your security measures go beyond PCI DSS requirements?" A, yes our security efforts go beyond PCI DSS requirements. B, no our security efforts are per PCI DSS requirements. C, no, we do not comply with PCI DSS, but we are looking into it. And D is sort of a tongue in cheek, what are PCI DSS requirements? Please answer those now.
 
We have had some questions come in asking about the presentation slides, making them available after the webcast. You will receive a follow up email from Lumension that will include a link to the archived webcast, a link to the slides, as well as a couple other relevant pieces of content for you to review. So please, we'll leave this poll open for a few more seconds, and we'll review the results here...Okay, I'm going to close the poll right now, and we will share the results. So looks like 50% of you said yes our efforts go beyond securing PCI DSS requirements. So, that's good. Twenty-seven percent, no, our security efforts are per the PCI DSS requirements, and then no, we do not comply with PCI, but we are looking into it.
 
So, this is actually a question, quick follow up question for those folks who answered B, no, our security efforts are per PCI DSS requirements. I would like to know, okay, why that is? Is it that there are too many, and I'm opening up one more poll here, too many other priorities? Or you feel PCI DSS requirements are sufficient for your needs? Is it a budget and resource issue? Or is it management resistance? If you could vote on that, I'd love to get the feedback on that. And while we're waiting for responses there, Michael, I know that a summary of PCI updates just came out, or were just announced a week or two ago. Can you give us a little info on what those summary changes are?
 
Michael: Yeah, there's more clarity coming on this, but there's specific elements they're changing to clarify the applicability of PCI DSS and cardholder data where they're like a three dot three and three dot four, they're clarifying that only applies to the PAN element, they're aligning language with the PTS secure reading and exchange of data module. There's scope of the assessments area, they wanna ensure all locations of cardholder data are included in the scope of PCI DSS assessments, and they state that the proposed change there is to clarify that all locations and [inaudible 00:39:29] the cardholder data should be identified and documented, to ensure accurate scoping of cardholder data environment. That's like when I was going through my presentation, I mentioned we need to understand the process and the physical environment and logical environment and how all these interrelate to each other.
 
It's providing further guidance on virtualization environments, further clarification to DMZ, clarify the ability of PCI DSS when it comes to issuers or issuer processors for credit cards. They're providing more clarity around key management processes, merging requirements to eliminate redundancy in some of the areas, like requirement 6.3.1, are being merged into 6.5 to eliminate redundancy for secure coding for internal, and web-facing applications, clarifying remote copy, move and storage, payment applications on hardware terminals they're addressing, payment applications to facilitate centralized logging, where there's a sub-requirement for payment applications to support centralized logging, and alignment with 10.5.3. And there's some other requirements are being merged, but more particularly, I think the most interesting one is the requirement on 6.2 to apply a risk-based approach for addressing vulnerabilities, and they write there the proposed change is to update the requirement to allow vulnerabilities to be ranked and prioritized according to risk to the environment. I think that's the most interesting piece there.
 
Sam: Okay. Thanks, Michael. Chris, is there anything in...that Michael walked through, you know, what some of the summary changes that are being announced, is there anything in there that you think should be in there that wasn't, or isn't?
 
Chris: Well, there's a lot of talk early on, beginning of this year. Proposal's been out for a couple of years now that we should be mandating end-to-end encryption. The good folks at Heartland, whose name lives in a bit if infamy, have started to institute that for their merchants. And there are a lot of other people talking that that may be a necessary step.
 
Another thing that I found interesting, there was a lot chatter about early on, but isn't included in here, is tokenization. A whole different topic, but something that there's been a lot of talk about, and how that might help alleviate a lot of the burden on merchants, so that they limit the scope of what they have to protect. So those are two things that I see that have been talked about that aren't in there. William, did you guys [inaudible 00:42:09] any of that?
 
William: Yeah, I was gonna talk to a couple points. I definitely agree with Michael that the risk-based approach is an interesting change, if you will. It's something that we've been using for a while, and in the grading of our vulnerabilities, using modified CV metrics, things like that. But, definitely the tokenization thing, I wanted to kinda speak towards that. Something that our business actually fought against pretty heavily.
 
The problem you have is that to tokenize, you have to have upstream support at the highest level, right? Either the network or the bank, particularly the bank, have to provide you with, you know, a token that you can rely on for forever. A significant part of our business is recurring billing, and if we wanted to change banks, and the bank had all of our credit cards, and all we had were tokens that applied to that bank only, right, that's an impossible move for us, right? So there's some issues with that. Yeah, makes things more secure, sure. It makes my job 10,000 time easier, right? However, it's completely, you know, our business could completely not operate that way. So, definitely, you know, some food for thought. I think that's something that will definitely almost never happen.
 
Chris: Yeah, and I think that points out kind of part of the discussion that we were having earlier that Michael was talking about, is the need to balance the business needs versus the security needs. And, so it's interesting to hear from you on where that really falls apart for you.
 
William: Right.
 
Chris: Great man, and...
 
Sam: Well, thanks guys. I'm...Oh, go ahead, sorry.
 
Chris: I was just gonna ask, end-to-end encryption, what's your feel for that? Was the reason it was left out, did y'all have a kind of input on that?
 
William: No, we already are practicing that, as well as our payment gateway system specifically. So we're an ISO as well as a payment services provider. So we have merchants that report to us, and basically funnel transactions through our payment gateway. We only allow, you know, fully, mutually authenticated SSL connections to those gateways. You know, we issue a certificate, they use it, etc., and then we apply some field-level encryption on our XML gateway as well, that we create as part of our API to code towards our systems.
 
So, definitely something that we're very, very, you know, ingrained with. It's stuff like, just to give you an example, a lot of business use things like load balancers, SSL termination at the edge, etc. They obviously present their, you know, certificate to the world, they, you know, pass all their vulnerability scans, but they don't re-encrypt on the other side of the load balancer, right? So they're speaking to their internal systems, you know, free and in the clear, and that's something that's a huge, huge hole that pretty much, I mean, it's I've...talking to the guys over at F5 the other day, and when I asked them about their, you know, their customer base and what they call virtual interface re-encryption, is so rarely used in all the configs they've seen, and you have to know that a large segment of F5 customers are financial processors. So it's, you know, it's simple things like that they could be doing just by, you know, making sure that their web servers internally were also offering up SSL, even if it's an internal certificate that they're...shoot, even if it's not a fully authenticated, fully verified certificate. Anything other than just throwing it across the wire unencrypted would be better, so.
 
Sam: Okay, I'd like to just quickly share the results from that last poll we did. It was, "Why don't your security efforts go beyond PCI DSS requirements?" And 40% put it as a budget and resource issue, 36% put it at too many other priorities. William, could you walk us through sort of how you developed...how you discuss PCI DSS compliance in your organization, and how you kind of use that in further developing and implementing your overall security program?
 
William: Well, you know, we're a perfect example. Six years ago, we didn't have a security program. You know, the CISSP program was just coming together over at VISA since the 2004 timeframe, 2003, late 2003. And, you know, we didn't have a security department. And then CardSystems happened. And CardSystems breach was very...impacted our business significantly, because they were our payment gateway. And everyone all of a sudden realized that, you know, in specifically the world of online payments, where we specialize, it's an easy...you know, there's pretty low barriers to entry, lot of competition, right? It's something where it's easy for merchants, or, you know, not...guess would be clients, if you will, that have a merchant account, serves, you know, third party payment individuals to jump ship and move somewhere else to another provider. So it was important to make sure that we are doing everything possible to protect our cardhold data, specifically, and we formed a security department based on the yearly onslaught, if you will. And we have a couple different brands that have a couple different merchant accounts, that are all level one.
 
So, you know, we have three PCI audits every year for different, you know, systems, different companies inside our organization, that we have to pass. And that's, you know, just outside of all the continuous compliance that Michael talked about, right, because it's very important to us. Outside of that, it still means, you know, two weeks per, you know. So, basically, six weeks of, you know, our security staff's entire life is just auditing around PCI compliance, and it's, you know, forced us to stay on top of it, because when our auditor comes in, they...the change in the auditor's perspective from 2004 to today, they have really heavily started focusing on this continuous compliance, and they're requiring you to show that you're doing things not just periodically, but continuously, to assess the profile of your, security profile of your environment, and make sure that you're actually and accurately protecting cardholder data.
 
Sam: Okay. And then, you know, and that poll from the audience showed that budget and resources and too many other priorities are kind of the things holding organizations back from going beyond, you know, the requirements outlined in PCI DSS. You know, what are things that your organization's has done? And how have you gotten around some of those issues? Or have you not had not those issues? I imagine most organizations these days have a budget constraint. You know, how do you work around some of those things?
 
William: Well, you know, we definitely have budget constraints, but, you know, one thing I think makes us a little bit different is that card payments are our entire life, right? So protecting the cardholder data is extreme, of extreme importance to our company. That is not the case for, you know, PetSmart, right? They operate retail stores. T.J. Maxx for example. You know, they operate retail stores, cash registers, POS. Taking money is a part of doing business, but it, you know, it's just about selling product, and selling different products and different services, and all of these things, and getting money for it is just a conduit, right? They're just taking money, and it's not a focus of their business.
 
And in fact, you know, when you look at the difference in the breaches of retail stores, right, or big-name companies versus your smaller, you know, back behind the scenes business-to-business stuff, you look at Heartland's breach and CardSystems breach, and its impact on their businesses, versus T.J. Maxx's breach, right, which they just kind of sloughed it off and said, "Man that hurt, but, you know, our customers love us, because we have awesome clothes," right? So that was their business line of thinking. We, you know, are constantly focused on the card payments that we take. It is our whole business. If we lose the trust of our consumer, we are out of business. So it's a different objective. Yes, I still have budget requirements, but, you know, it's definitely a lot of money and time and effort is put towards, you know, security in our organization. We have 350 employees, and 7 of them are dedicated information security professionals, so.
 
Sam: Okay, great. Are there things that you're doing to go beyond? You know, we've talked about the concept of going beyond compliance, and I want to get to the, a little more after this question on just a discussion of compliance versus security, but, you know, is your organization doing anything beyond...or what is your organization doing beyond PCI requirements, in terms of securing information? That you can share?
 
William: We're definitely, yeah sure. We're, you know, we're always trying to do things like I mentioned earlier, this risk-based approach to vulnerability management, right? We recognized, you know, three years ago that it was important that we figure out which vulnerabilities put us at the most chance of compromise, and address those, and put all our efforts towards fixing those vulnerabilities as quickly as possible.
 
So, we created, you know, a...they basically re-score system, based on the CBB system, that allowed us to apply our own protection mechanisms, the things that we're doing. Give you an example. Somebody comes out and says, "Hey there's a vulnerability in Apache. There's a buffer overflow in the way it handles the POST headers that come in," right? We look at that, we say, "All right, we have got a couple different things in play here." First off, you know, they're interacting with a load balancer, right, that's actually terminating that connection to begin with, right, and only bits of those headers are making it through to the system. And then we are running systems with PaX memory protection.
 
So if that buffer overflow was to occur, we have patches to our kernel that keep those overflows from resulting in, you know, remote code execution, right? And even if they were to get past that, we've got systems in place to do role-based access control for binaries on systems, right? And you take all those things, you apply it to that, you know, "Oh my gosh, end of the world" vulnerability, and it looks a little bit easier to manage, right? And we apply a, you know, remediation time based on that score, and our business loves that, because they know that we've taken, you know, all of the things into account to try to understand, you know, how much risk we have towards some specific vulnerability in our organization, and they're much more willing to go and patch those things that are still considered to be of the utmost criticality. And, you know, it's a different, before and after the implementation in that system, it's a completely different reaction than we used to get, which was, "Oh, again? Why are you doing this to us again?" Right? "We don't think that it's that important, etc, etc, etc." Now they know it is, they can see how we made those judgments, and they, you know, work appropriately to fix them.
 
Sam: Great, thank you. Chris, just a quick question for you on, you know, I posed this in some LinkedIn groups, around the question of compliance and security. I know we're running short on time. So, but, you know, it stirred up a lot of different responses. Do you have thoughts on, you know, what the, you know, quickly, what the difference is, and the purpose of each?
 
Chris: Well, yeah, that's a long topic, obviously, and I think, you know, there's a lot of discussion out there on that. I saw a quote the other day that I kind of liked, in a tongue and cheek sort of way, "Every time you think PCI OR security, God kills a kitten." The thing that we're trying to get across that Michael's been talking about, that William has just very excellently pointed out, is that, you know, PCI in and of itself is a baseline. It's a minimum set of requirements. It does not cover all of the areas that you need to worry about in a modern day IT system to mitigate the risks that you're facing. And in William's case, you know, as he says, his business revolves around being a trusted partner, and even folks who are in retail, I know personally that if I read about a store that has been breached, I'm less likely to do business there. And there's a famous report by the Ponemon Institute which showed that 40% of folks would follow that line of thinking also.
 
So, you know, it does impact everybody if there's a breach, and so you can't look PCI as just the good enough set of things to do. You really need to go beyond it. Which, you know, of course bring up the question, "Well, if you're not doing more, if you don't know what to do, how do you get kind of smart on it?" And I think there's a lot of really good information out there on the net. You know, the PC hour of SEC...SSC, sorry, has a lot of information, including a prioritized approach to meeting the requirement. And then recently, Visa's put out a document, in conjunction with the SANS Institute on how to approach security above and beyond PCI, to supplement that, and that's an excellent resource. The SANS folks do a really nice job in prioritizing protections that you ought to be putting in place. So those'd be the place I would start.
 
Sam: Thanks, Chris. That actually is a nice tie-in to some resources that Lumension has as well. Michael has written a paper on the six critical elements to achieving economical PCI DSS compliance, which you can get from Lumension website. We also have an EC Suite case study that William was kind enough to help provide us with the information to put that together, as well as other white papers, webcasts, so on and so forth, and software evaluations.
 
With that, I'd like to thank all of our speakers. Michael, thank you for your presentation. It was great information. William for your participation and insight, and Chris for your perspective as well. Thank you all for participating, thank you to our audience members for participating, and engaging with us on the polls.
 
If you have any other questions, please let us know. We will follow up via email. Emails will be coming to you within the next few days that have the information on the webcast, our archives, slides of the presentation, as well as some of the offers or content that I just went through. For more information on any of this, you can go to our website, of course, at www.lumension.com. You can check out our blog. Chris is a active blogger. Check out what Chris has to think on a lot of different topics. Michael, I believe, has also participated from time to time. It's blog.lumension.com. You can call us at 1-888-725-7828, or email us at [email protected] Again, thank you everybody for your attendance and participation. This now concludes our webcast.