Updates to PCI-DSS Compliance for E-Commerce and Cloud Computing Security

Updates to PCI-DSS Compliance for E-Commerce and Cloud Computing Security

February 26, 2013 2:00 pm

(Save to cal)


Online Tech and guest Adam Goslin discuss the new PCI cloud computing guidelines recently released to clarify the roles and responsibilities of cloud service providers and merchants.

Title: Updates to PCI-DSS Compliance for E-Commerce and Cloud Computing Security
When: Tuesday, February 26, 2013 from 2-3 PM ET
Description: Last month, the PCI council released new guidelines to help e-commerce companies, other merchants and those leveraging PCI cloud computing understand how to apply the rules to meet PCI DSS compliance. Adam Goslin, COO of High Bit Security, highlights the key takeaways and answers questions about working with cloud service providers and protecting cardholder data in cloud and e-commerce environments.




View slides (PDF).

Adam: Well, thank you very much April for having me. It’s always a pleasure to talk security. As you well know, that is my specialty, love and passion, so I appreciate the opportunity to talk to the folks about the updates that came from the PCI council. Without further ado, let’s go ahead and get started. PCI council released a couple of different updates recently, first off was an e-commerce guidance and then they also released some cloud guidance. Now the e-commerce guidance, I’ve got a couple of different things up on the screen just so that people can find the documents and look at them. This is intended to be more of an overview of those. Both the ways that folks can search for the different documents, via Google, as well as going on and looking up the actual URLs themselves, are on the screen.

Just as a general note, the presentation itself will be posted by Online Tech following the presentation, the webinar today, so you’ll be able to see these and be able to get these links, so you don't need to madly scribble them down. That said, for the PCI e-commerce guidance, it basically was released because there are a lot of questions that have been coming up from folks that are in the e-commerce space. There are a number of different methods and ways that e-commerce providers can go ahead and establish their systems. Quite frankly, the feedback that was provided in both of these documents are items that we’re fielding on a regular basis, talking to customers about it, so it was nice to see the additional guidance that’s been provided.

For the e-commerce guidelines, it’s talking about different implementation styles. The intent of both of these documents is to supersede the version 2.0 of the PCI data security standard but to provide some additional clarity. Because certainly, there were some interpreted questions that were coming up as a result of the new technologies in conjunction with the compliance requirements. They’ve also released a document on cloud guidance, giving explanation of different cloud implementation options, guidance for responsibilities as to where those lie, etc. We’ll be covering topics on both of these recently released documents from the PCI council today. Images and content that are contained in here are a subset of the documents that are provided online.

Adam: Let’s talk about the e-commerce arena. What's new with that? Mostly it was clarification and there was some additional explanation provided. However, this is the however of the document, as we took a look through the documents provided, a couple of points of note if you will, no option will completely remove a merchant's PCI-DSS responsibilities and there's a big paragraph in there and you guys can read that while I'm talking. The bottom line is, they just wanted to get very, very clear about the fact that no matter what, it is the merchant's responsibility to the PCI-DSS compliance. That includes every aspect of PCI compliance, it covers both how they implement the solution and all of their various requirements of PCI compliance that fall to the e-commerce merchants themselves.

The other important note that they had in the guidance document is that there is no one-size-fits-all method to just get PCI compliance. One of the things that I find, our staff are addressing if you will, on a regular basis, is the question from folks out there. They're trying to navigate PCI compliance saying, "Hey, we found this provider that says that we can go ahead and put our stuff there and we'll be PCI compliant." Well, the bottom line is, it's not quite that easy and so they called that out in the document. One of the things that heightened security being in a space where we’re regularly interfacing with folks surrounding PCI compliance, but also just general security consulting to organizations.

One of the pieces that wasn’t really clearly called out that I was pleased to see is the fact that they put in, the fact they’re looking for organizations to undergo penetration testing. One of the documents that we put together was a review, a summary of the prior year’s penetration testing engagements. For those who may not be aware of what is penetration testing, it's an engagement where trained security professionals are going in and doing a thorough, should be manual validation or test of the security of the system. It's pointed that both application layer, the host configuration layer, looking for vulnerabilities that may be in those applications. One of the interesting points of our 2012 review was that when we looked at all of our penetration testing engagement, the vast majority of those organizations were having their systems scanned by an approved scan vendor.

However, in over 95% of the cases, there were serious vulnerabilities that were still found within these applications. Penetration testing is extremely important for those that are interested in maintaining a high level of security. We talked about various e-commerce implementation styles. That's said, we're going to go do a little bit of a regroup on PCI and then expect getting into some of the meat of the e-commerce and cloud guidance documentation. The first step that I always recommend to anybody that's approaching PCI, coming back for their annual recertification, whatever it may be, is to put together effectively a data flow. Mapping all of the card holder data flow, that's covering electronic, covering any connections with partners or vendors that they may have.

This is typically where we'll find some different findings as we're going through and validating that data flow, is that organizations that are receiving credit card transactions over the phone, through the mail, fax machines, in-person transactions, card-present transactions, the star elements, they aren't specifically covered in the guidance document for e-commerce but that's something as an organization approaching PCI, you got to be aware where your information is etc. The strongest recommendation is, quite literally, to build through and validate it as if you have never been a part of the organization before. Ask the questions that you think may be straightforward that you already know the answer to. Just ask them, validate them.

You'd be surprised how many times I've been going through that exercise of validating the data flow. That finding someone's taking phone orders or something along those lines. They've got a spreadsheet that they'll keep on their desktop that they've got password protected, they use for repeat orders etc. Don't make any assumptions when you go through that process. That said, when we start talking about some of the cloud guidance that was provided, the document has a fair amount of depth to it and covers a couple of different service models, software as a service, platform as a service and infrastructure as a service. These three different delivery models wherein a software as a service, platform the clients will go ahead and use the provided applications and run them via a cloud infrastructure.

Adam: Now, for platform as a service, that's where clients can drive and deploy their applications into a cloud based infrastructure and use various language and libraries, etc., to go ahead and stand up their solution. In infrastructure as a service, that's really where the provider is providing the processing storage networks, etc., kind of as a base line entry point. Platform as a service and infrastructure as a service are primarily similar in accordance with the document. Software as a service really is a much different offering wherein many of the responsibilities will fall to the cloud service provider.

Regarding the responsibility sharing and how it's defined in the guidance documentation, for infrastructure as a service, you got the client responsible for things like an encryption antivirus and cloud service provider taking on responsibility for the physical environment. Then, with the remainder of the requirements for PCI compliance, following that both of those products, i.e. the client and the cloud provider. Platform as a service is where the cloud provider will take the physical environment and the remainder is a shared responsibility. For software as a service, both of the parties will be responsible for securing the systems, restricting the right to know and assigning unique IDs to each individual that's on the platform with the remainder falling to the cloud service provider.

Now, one of the important points when you're looking at a cloud based solution for your PCI compliance is really going back to the previous slide that we were talking about, knowing where your data sits, goes, resides, etc. You have to know where your information is being sent and how. Then, how is that impacted by the cloud service provider in the solution that they're providing to you. By an instance by instance basis, you need to evaluate that cloud service provider's offering. Ultimately, the merchant is responsible for their PCI compliance. Now, one way for those merchants to mitigate some of those responsibilities is to have written agreements with their cloud service providers and making sure that there is clear definition of responsibility. As far as what it is that the client's going to be responsible for, as well as what the cloud service provider is going to be responsible for.

Probably, most importantly, is that there are number of misnomers out there that the realm of cloud, as it relates to the payment industry, is one that has been evolving over the past number of years. There are a wide variety of players out in the cloud provider space and it's important that you validate the PCI compliance of that cloud provider. Ask them, have them show you what they do, make sure that you got everything clearly documented in terms of agreements, etc. The merchant ultimately bears that responsibility for making sure that their solution is PCI compliant regardless of which cloud option that they select.

April: Hey Adam. I have a question for you.

Adam: Yes.

April: If it was you and you were trying to validate if a cloud provider met PCI compliance, what specifically would you ask them for and expect to review? I know one of the challenges might be that, for clients who are remote and far away from their potential hosting provider, it might be pretty tough for them to actually fly in and inspect the physical facility. Although that does happen at some level, but what would you ask for that would give you a feeling like the cloud provider had really done their due diligence?

Adam: What the client should be looking for is documentation or a document approved of the compliance of that particular provider. As an example, for any organization that's providing cloud services in the PCI's base, likely they've gone through what you call a level one PCI compliance audit. Now, level one PCI compliance audit, whether you're level one or you're level four, everybody needs to meet all of the requirements for PCI. That said, level one instance, that is where the compliance has been validated by a qualified security assessor or QSA. In that case, what is important is to understand the details of the engagement that the level one audit covered. What was the context for the level one audit? What things were included? What things were not included? Then that's where when you start getting written agreements between the client and the cloud provider. You can start to map those aspects of their PCI compliance from their audit and map those back to your overall PCI compliance stance and basically leverage that platform.

Certainly if you're remote, depending on information that's been supplied from one of the qualified security assessors, that should be good enough proof for the client to be able to know and understand. Again, it's the merchant’s responsibility to provide the interpretation, know and understand the requirements of PCI and to make sure that they're compliant with them. The documentation from an audit and the context of that audit is really invaluable to that process.

April: Great. Thanks Adam.

Adam: No problem.

Adam: Let's move on and let's talk about the e-commerce space. Some of the third party players that fall into an e-commerce style environment, it really comes down to the payment gateway or the processor, the web hosting provider, i.e. where is this thing hosted, as well as any general infrastructure hosting providers that may be in play. Keep in mind, that’s the decision for you. What's best is dependent again on multiple factors. It depends on the nature of how the client is transacting payment card data. It depends on what aspects or elements of that solution are hosted where and the compliance of any of those third-party hosted components. Making sure that you validate and that they've got compliance for those aspects that those parties bring to the table.

That said, the typical three tier model for an e-commerce style environment involves the presentation layer, processing layer as well as the data-storage layer. On the diagram, you can see the public internet connecting in via router and firewall with IDS/IPS to a series of web servers and having those segmented from what we call the back-end or the processing server in the processing layer, i.e. the application servers and those segregated from the previous servers. That's your typical three tier model where you've got fun and basically processing in the middle with data storage on the back-end. Now that said, the typical components in an e-commerce style engagement are shopping cart software.

One of the important points about shopping cart software is if you're leveraging someone else's software. There is another compliance requirement that is specific to payment applications appropriately named payment application data security standard. Now, the payment application data security standard is something that a payment parts software provider would have to go through PA-DSS compliance and validate that shopping cart software meets all the requirements of PA-DSS, which ultimately, PA-DSS is primarily a subset of PCI-DSS. The same things that PCI council is looking for from a merchant that develops their own software are the same types of things that a shopping cart software provider would provide.

Just make sure when you're looking at shopping cart software, perform the validation and the double check that software you're about to leverage in your e-commerce platform has in fact passed PA-DSS compliance. There's also some other typical components, the secure socket layer and transport layer security, SSL/TLS, i.e. moving the data from one point to another in an encrypted secure fashion. Then, network components and then supporting infrastructure are other typical components on an e-commerce style engagement. Now, there are a number of different ways that e-commerce systems can be set up. The first of which that we'll talk about is merchant-managed or proprietary, it's where the merchants writing the code themselves and they're doing a direct integration to a payment processor.

Now that said, you got the consumers web browser with an e-customer data and order details, etc., as well as the card holder data that’s being entered into the browser. Having all those passing over to the merchant’s environment where the merchant will take the cardholder data, make some form of API call over to the gateway or processor for doing the payment processing side of things. In this environment, because of the fact that all of the information is going directly into the merchant environment, ultimately, from the merchant’s perspective that puts the greatest level of bonus for PCI compliance on the merchant themselves.

When we talk about the next style of interaction, that's where the merchant is leveraging some form of a commercial shopping cart or payment application, payment processing is directed through commercially available software that passed PA-DSS compliance but again is loaded onto that merchant’s environment. You can see the customer detail and data passing over to the merchant, whereas the cardholder data passes direct to an API call and then passed over to the gateway or the processor. In that way, it provides a measure of distinction between the merchant's environment and the fact that they're leveraging this third party. However, that data is still passing through the merchant environment and opens that merchant up to a number of additional environments under PCI compliance.

Adam: We'll start getting into some of the alternative solutions which really fall into a category in the guidance document called the shared-management. There are a number of different ways to do it so we'll talk through the various e-commerce style implementations. First off is a third-party embedded API or application programming interface that does a direct post. Well effectively, that means the customer’s data in the web browser is being passed over to the merchant environment with the cardholder data going directly from the web browser over to this third party service provider through their API.

The service provider will then go ahead and make the connection with the gateway or processor and then pass back some type of a transaction code, i.e. token, whatever it may be, to basically indicate that the payment has been accepted. In that way, the cardholder data effectively goes direct to the service processor, it doesn't enter the merchant environment.

That said, we'll go on to the next style of shared management and that's really a third-party with inline frames or otherwise known as iFrames. Effectively, on the consumer's web browser all the customer data goes to the merchant environment.

However, the cardholder data that is presented on the screen, in what can either be clearly called out on the web code as a separate frame page, most often that page is being served through a provider that will allow you to customize the look and feel, so it looks as if it's all part of the same web browser. However, the cardholder data really is making a direct connection through that iFrame over to the service provider then passes onto the gateway or processor. Now, the next style is where you've got a third-party hosted payment page. Everybody's seen these who make purchases online where you effectively go in, gather up all of your order details, etc., and then control is passed from that page to a third party page where the payment details are then gathered there.

It's a different implementation style, if you will, for how you do it once the payment's been processed then control's passed back over to the consumer's web browser back to the merchant's system. In other words, so that they can see the details of the order that's been placed, confirmation that payment's been processed, etc. Where again, that's segregating the actual cardholder data from the merchant systems over to the service provider. Now, one of the common questions that we'll see, especially when you're talking about these shared-management style solutions is where customers will say, "I’ve got all of my data. The card data isn't even entering my environment, so I don't really need to be subject to PCI compliance." and the answer is of course, yes.

On all of these platforms, there are a couple of different aspects PCI compliance have come into play. Not the least of which is, if there's processing in other manage and mechanisms, we're talking about earlier phone, mail, fax, etc. Those could all be things that merchant is responsible for, but even in the days where we don't take phone payments, we don't take mail payments, we don't take fax payments, the only thing we allow is the browser, even in that case, the merchant's still responsible for providing instructions to the internal staff about how to handle it. What happens if you got a support call that comes in where someone's trying to talk to your customer support representative about an order, wanting to go ahead and expose their card information?

Having internal policies and procedures or how those things are to be handled, those would fall under the realm of PCI compliance as well as the system itself. If you think about it this way, it's the merchant's system or the merchant's website that is ultimately passing either controlling which sub-frame comes up on that web application. It's also that merchant’s systems that are passing control from their website or their web application to the third party payment processor. In both cases, the security of that, of a website that they host is extremely important. There's still aspects of PCI compliance that fall into play and that's something that we end up answering questions on a fair amount, if you will.

Adam: Let's go to talking about some of the security considerations. We talked about it a second ago, with the security of the web page is something that the merchant is responsible for under all of the shared model environments. The guidance document goes one step further saying that the merchant needs to monitor for unauthorized changes and respond quickly if there's some type of problem. Being in the security testing space as an example, an example that we kind of relate to this particular instance is that we had a, I believe it's a law firm, contacting us indicating that their careers page on their web application was attempting to sell Rolexes, etc.

A hacker basically had compromised the website, managed to change out the application content and redirect away from their true careers page and direct them to a Rolex site. Well, in a similar fashion, if a merchant’s system were breached, then the hacker could basically redirect the iFrame to an iFrame page that looks completely identical to page that is presently being served and should be served. However, they’re going to bad hack your site. Meanwhile, your customers are busy entering all the credit card information and data into this alternative site. That's what they're talking about in the guidance document when they're talking about monitoring unauthorized changes.

As an example, monitoring logs would be one method for doing that. Another would be employing file integrity monitoring. In other words, if the files were changed on that web server then there's some mechanism for notifying you that that change has taken place. Not only should you have the monitoring in place, but also have a mechanism for being able to react to, which needs to be in place as well. The merchants are also encouraged to practice secure development. Training your internal staff, the ones that are responsible for making web application code changes and updating the system, making sure that they understand how to do secure development

Certainly, what I try do for customers as a whole is to let them know that just because your developer has gone to a secure code training class doesn't mean that they're going to catch everything all the time. There are a wide variety of aspects to security that come into play and certainly it is an overtime style assessment. Realistically, the council has also gone so far as to recommend merchant's do thorough penetration testing against their web applications. They realized that sending somebody to a training course isn't going to make them a security guru. Performing scanning isn't going to catch everything. The performance of penetration testing with security engineers is really important to an overall security stance. In terms of outsourcing your e-commerce implementation as it relates to a self assessment questionnaire A, the self assessment questionnaires are used for a number of different purposes. SAQ A is the one that merchants have the capability to fill out that denotes the least number of line items if you will, regarding PCI compliance. There are some notes on this guidance document, again, they're stating that even if you do a wholesale outsourcing it doesn't absolve the merchant PCI requirements and goes further to say that they may be eligible to complete the SAQ A but are looking for the merchants to validate that with their acquirer to confirm that that's truly the case.

Some of the challenges that we talked about earlier where you've got a card present, with fax, mail, phone, those are aspects that would likely not allow you to fill out a self assessment questionnaire A. Another note in the document that was interesting is that their clarification that PCI is treating local machines that connect to third party gateways via the internet, they're going to treat those as a virtual terminal. There is a self assessment questionnaire that specifically covers virtual terminals. That would be the direction that those style organizations would need to undertake in terms of filling out their self assessment questionnaires.

Adam: Now, some of the aspects of common security vulnerabilities surrounding insecure coding, these are things that would show up on your e-commerce web application. The primary ones that they call out are injection flaws, cross-site scripting, cross-site request forgery, buffer overflow, weak authentication and/or session credentials. Looking at this list that the PCI council put together and from our own experience performing penetration testing a wide number and variety of web applications, I would agree with, in fact, all of these are potential issues.

The biggest one, from the security vulnerability perspective that is, I’ll call it typically missed, which wasn't listed on this list is more of the logical coding fault. In other words, it's not a direct fault that one would find through any tool or utility that you point at the web application and get back your report because those applications are really looking for pattern matching. Maybe a developer made an assumption around what is an authenticated user, where you got the capability through manipulating parameters that are passed, bypassing authentication or accessing aspects of the system that you shouldn’t be able to access. Those are the types of things that will typically come up when looking at a particular web application.

There's a whole section in the guidance document about security misconfigurations. Majority of these would be picked up through scanning utilities and ASV scans. The misconfigurations when you start talking about the host level, etc., those are things that are typically picked up in the ASV scan. Some of the security myths that I just wanted to take the opportunity to dispel is really part of my charge in life around trying to get business owners, people that are responsible for poor sensitive information and data to understand is just because you have a network administrator and a developer on staff doesn't necessarily mean that they know how to do that securely.

I guess, the one piece of perspective I'll bring to the table is that my background came before I got into the wholesale and the security space. I was working up the ranks of IT management. Ultimately, I was vice president of IT and infrastructure for an e-commerce supply chain management company. I had a team of network administrators and developers there. During that engagement is when the boss came by and dropped off this three-inch deck of paper. I'm saying we need to be compliant with this and the three letters on the top were PCI.

I can tell you from firsthand experience being a leader in the IT arena of both infrastructure and development that there were a ton of things that that team learned through that process that weren’t really top of mind when they walked into the endeavor. The other security myth is that, I hear it commonly, that I pass my ASV scan so I'm secure. Going back to the High Bit Security 2012 review of the penetration testing engagements that have been performed, the vast majority of those were performing some form of vulnerabilities scanning and yet over 95% had serious vulnerabilities in their web applications. Just keep that in mind when you're assessing the security of your organization and how to keep it that way.

Adam: Moving on to some of the recommendations in the e-commerce space, these are good and applicable to any organization that's dealing with PCI compliance. That is, first off, knowing the location of all of your cardholder data. Probably the next one, and darn near as important, is if you don't need it, don't store it. There are a number of organizations that have been out of air for some time that have systems that have been developed forever to comply ten years ago, whatever it may be. Realistically, undertaking the changes that need to be made to your system, so that you aren't exposed to cardholder data, ultimately, will save a lot in terms of the overall cause for getting through PCI compliance.

Evaluating the risk with your selected e-commerce technology, as well as any outsourcing that you need to do with third parties, and making sure you're doing scanning and penetration testing, of course. Best practices for payment applications, that really falls to more of a coding arena. Security training for all staff, that's not just the developers, not just the network administrators. Yes, they're important and in fact they should have a higher level of training. For all staff, your front liners, people that are manning the phones, doing the support for your systems, those folks need to have security training performed as well.

The other recommendations, monitoring security alerts, put an additional firewall between your application and database servers. Servers that are performing support style pass from the business perspective, get a firewall between those. It was interesting, they had in the other recommendation section, the fact that you should never reflect full card numbers back to the interface or send on the receipts. That's actually one of the things I'm going to go back to the council and recommend that they make a change to because it's already required for PCI compliance in order to do that, so that should be a recommendation.

Best practices for consumer awareness, they also covered some things in there, not using public computers for doing e-commerce, don't use public Wi-Fi, watch out for shoulder surfing, making sure that your local machine is patched and my personal favorite, strong passwords and using a password keeper. You hear about these companies that are getting breached and having their password hashes posted publicly. Well, where it becomes a serious problem is when you are using, let's call it less than five total passwords for your personal use. So your password to your Gmail account happens to be the same password that you use for your banking account, happens to be the same working password that you use for your twitter account.

If you get in the habit of using a password keeper, one free one is named KeePass and it's called KeePass X for the Mac platform. That's something where you can go ahead and leverage to get the password for every system. That way when a system that you leverage has been hacked and someone pulls the password hashes, now you don't need to worry about how can they get in and take over your twitter account and your bank account, etc. Overall, why is all of this discussion around PCI compliance, around cloud security and development of security applications important?

Well, bottom line is, today there are international hacking rings that will literally go out, their sole goal in life is to go out hack people. There's card theft rings, there's websites on the internet where people can transact back and forth different credit cards and things on those lines. There's a recent news report that the Chinese government has a whole high-rise building that's dedicated to performing hacking. Primarily, the nature of that particular facility appears to be theft of intellectual property. Those are all reasons from the news side of it, but from a security perspective, the security of the card data, yes, absolutely, we want to make sure the credit cards are secure.

There's a lot more information out there, there's information of medical space, there's intellectual property, there's companies that have spent millions, billions of dollars on intellectual property that they need to protect. Just keep in mind that just because an organization goes through and passes PCI compliance does not necessarily mean that their company is secure. It means that the environment that is designated for transacting card information is secure, however, that may not and probably won't extend to the overall corporate security stance. Just keep that in mind as you're looking at the general security of your organization.

The fundamentals that exist within PCI compliance, those are aspects that are good. It is a good overall framework for security for any organization. Certainly, extending those beyond your cardholder environment would be strongly recommended. That said, April thank you for letting me navigate through all of the content. Looks like we've got about fifteen minutes or so left. Are there any specific questions that came up through this process?

April: Adam, first, thanks so much for that overview. That was really helpful to understand what those guidelines and recommendations were all about. A couple of questions here, the first one is, can you clarify what is the primary difference between vulnerability scanning and penetration testing?

Adam: Sure. Absolutely. Vulnerability scanning, for PCI compliance, every organization's required to perform quarterly scanning from what's called an approved scan vendor. Effectively, these scanning vendors have certified their scanning utility with the PCI council, they passed the requirements to be an approved scan vendor. Effectively, each of these utilities is a vulnerability scanner, what that is, the closest approximation I can make to the audience at large is that a vulnerability scanner will look for patterns within the system and will look for patterns that match the vulnerabilities that are configured within that scanning framework. Look at it similar to your antivirus or your malware scanner that exists on your local PC.

It's a similar type of notion where effectively your local virus scanner is evaluating the files, evaluating the operating system of your local machine, looking for patterns that match the pattern that have been identified with viruses, malware, trojans, etc. It's the same type of thing for a vulnerability scanner, they'll go through, they'll look at those configuration layers, they'll go in and look at the various infrastructure that's been contained in that system and look for pattern matching and spit back results. There are a couple of challenges with vulnerability scans, one is that they are prone to what's called false positives, so in other words they will believe that it’s found a vulnerability that doesn't really exist.

An example test recommended a vulnerability scanner can come up with a result that says that there is a misconfigured whatever Linksys router that exists within the environment, and whereas there is no Linksys router, so that's an example. All that it looks at is a subset of the overall security stance and because it's a machine, it's not stepping outside of the lines or boundaries of the ways it's been coded. For a penetration test, it's an engagement that's performed by a security engineer that's got experience with performing security testing on a multitude of systems. They usually ... Most of the really good penetration testers have literally years and years of experience doing security assessments.

A vulnerability scanner is one of five, eight, twelve different tools that they would bring to bear on a normal engagement. Realistically, they are looking at and doing manual validation of the results that are coming back from their plethora of tools. Probably most importantly, especially when it comes to web application layer, the security engineer is putting hands, eyes, ears on the web application itself. They are doing manual testing which wouldn’t be performed by an automated tool. They're validating all of the results. They are pulling specific examples from that client’s system to facilitate the ease of correcting the security problems that are found in the security engagement.

Where a security engineer comes up with a web or coding fault, typically, what will happen to a penetration testing engagement is the security engineer will actually pull the client's web code as it stands today and show them the correct example of what it should look like. Typically, the greatest benefit to a vulnerability scan versus the penetration test is felt after it's done. Because when you get a vulnerability scan you basically take in their report, now you got to dive through whatever results came out of it to figure out whether or not one, these are real issues and then two, how do I address them given the standard response that comes back from the machine.

For a penetration test, quite literally depending on the nature of the results of the engagement, customers should be able to take that report and effect quick and swift changes to close up security holes because they've been provided with every tool that they need to be able to correct these issues quickly. For web app, we're talking about the web application code sample as an example, the development team will typically go in, take a look at that issue, "Oh yeah, I understand what I need to do" take up the code form the penetration testing report, drop that into the code base, go back, do the testing and they can promote the code. It allows for very quick and efficient closing of security holes and gaps that exist within that environment.

The two are quite different. Did that give you enough explanation April?

April: Yeah. That was great Adam. I know we have several questions here. We'll let you get to as many as we can here in the next ten minutes, any additional ones we can follow up with directly. Adam, I'll let you kind of go through which ones to address there.

Adam: All right. This might be a silly question, but I'm trying to find the questions April.

April: Actually, I can just read them if you want Adam.

Adam: Yeah. Go for it.

April: Okay. Do you have insight into what is the merchant's responsibility when a hacker appears to be authenticating payment cards with ten cent charges? Is this a PCI recording responsibility?

Adam: The requirements from a PCI compliance perspective, to follow the letter of law from the PCI compliance perspective, there is no designation for the gravity of the breach in conjunction with your notification responsibilities. Certainly, whether it's hackers doing ten cent charges or if it’s hackers performing multi-million dollar charges, thousands of dollar charges, the responsibility would remain with that merchant to perform notification of the breach according to the rules and regulations of PCI compliance.

April: Okay. What is the biggest ... Do you have one industry, if you had to choose, that fails to meet PCI compliance most often or do you find that it's just kind of either across the board or no real rhyme or reason to ... or any trends there?

Adam: Well, as far as industry and meeting PCI compliance ... it's not necessarily that one group or another struggles to navigate PCI compliance more than another. I guess I would look at it more in the context of the path to PCI compliance for an organization that has not gone there that is transacting card data. There are two fundamental challenges when it comes to PCI compliance. The first is getting there, understanding what your options are and I cannot underscore enough the importance for organizations as they approach PCI compliance to leverage some folks that have some knowledge in that space.

Give them some direction, even if it's just some high level directional consulting early in the game to get them headed in the right direction. It's hugely important because the decisions that you make in those early phases of approaching PCI compliance really denote what are you in for, how much of PCI compliance you now hold as your responsibility versus how much of PCI compliance can you share with others. It really depends on the needs of the business, the available options, and risk mitigation strategies on behalf of that merchant, etc. There's a lot, a ton of factors that go into it but certainly, year one PCI compliance, i.e. getting there for the first time, that's its own challenge.

What I've seen out of organizations that tends to be the next challenge is getting through their following annual certification. Getting there for PCI compliance involves standing up and putting in place a lot of solutions, infrastructure, roles, responsibilities, documentation, software, doing code changes to your applications, etc. There's a lot of things that are involved in just getting there. Through that process you define roles and responsibilities for internal staff and vendors, etc. The typical ... Once you come back around for the first year, there's usually some more challenges that are involved in getting through that first year of compliance and realizing that maybe something wasn't done that was supposed to be there, etc.

Typically, once organizations get past that year one of compliance, years two and three, etc., going forward become significantly easier. First time compliance and your first annual shot are usually the two biggest hurdles that organizations will face.

April: That makes sense. Well, I think we have time for one more question here and for anyone who we are not able to respond to, just rest assured that we'll make sure Adam connects with you directly to answer your question. Adam, another question relates to file integrity monitoring and the use of things like firewalls or maybe web application firewalls are left to detect when something in this area is maybe occurring. Can you just clarify that PCI compliance ... Are you able to use the technology and the automated alert technologies alone or does it require a real human to review those results on a regular basis?

Adam: Well, there are a couple of aspects to that, the first premise of any file integrity monitoring ... If you will, file integrity monitoring your firewall, your web application firewall, your antivirus, your web application itself, one of the requirements for PCI compliance is that all of those logs go to central logging and that they are reviewed. Now, there are a number of different methodologies for that review process but the first and most important premise is that all of the logs that are supposed to be generated are actually making it to the central logging repository, that's the first challenge if you will. The next challenge that exists is in going through the logs that are pushed to central logging.

As far as we used to do it, yes, someone can go through the raw logs. They have the option to go through the raw logs and do so manually. However, keep in mind that generally speaking, for any organization that has any fair amount of traffic, you could be talking about five million lines plus daily. That said, the typical implementation for the log monitoring side of things of the central logging is to use some form of a log parsing utility. Here's where really the devil comes into the details when it comes to leveraging a system like that, they're very powerful tools for doing the log interpretation, however, those tools are equally powerful at ignoring things that the merchant should be exposed to.

It takes someone with a fairly high level of skill as well as a fairly high level of just general security knowledge as well as familiarity with all of the various devices that are pushing logs to be able to configure that parser appropriately, so that you're not ignoring things that really should be setting off security warning bells, etc. The way that that typically works is the logs get parsed. Also, there's another word used to map spaces called parameterized. For instance, let's say you had logs where it had a big timestamp and then a certain chunk of text and you've determined that particular log entry is benign.

When you parameterize a log, how that parameterized line would show up even though there’s fifty thousand lines that look identical, it would parameterize out the big timestamp on that line and you'd basically end up with one entry, just showing the date time parameter and the line of text that was the log. You can denote that particular line as something that is benign. You can note that line as something that needs inspection whenever it pops up. You can go ahead and fire off red flare warnings that happen. The art is in the designation of how those parameters are set in the log monitoring routine and then no matter what, someone needs to review the results of those elements that need to be reviewed, that still has to happen on a daily basis for PCI compliance.

In other words, the subset of elements that come out of the log monitoring solution there noted as must review if happens or our brand new patterns that show up in the log monitoring. Those are things that need to be reviewed on a daily basis by someone that’s kind of got the capabilities to do so.

April: Thanks Adam. I think that's an important clarification. Well, thank you so much for sharing your perspective. I apologize that we are at the end of our time limit and I know there are more questions. Adam we will pass those questions on to you to answer directly or we can even post some answers to questions that you see appropriate along with the slides. We will be posting the slides and the recording of the webinar. We'll email everyone a link to that when it's available and thank you so much everyone for joining us.

Adam, thanks again. I really appreciated your insights and I'm sure we will be getting more updates from you soon.

Adam: Thank you very much April for having me here. I appreciate it.

April: Thanks everyone. Have a great day.

Adam GoslinAdam Goslin, COO, High Bit Security, LLC

Adam has an IT career that spans more than 15 years, going on to found High Bit Security, a national security services provider, providing penetration testing solutions to clients who need to protect sensitive data in industries such as Healthcare, Credit Card, Financial, or companies that otherwise store Intellectual Property or Personally Identifiable Information. High Bit Security also provides security consulting services to our clients to assist them with their compliance objectives across PCI-DSS, PA-DSS, or simply wish to perform a security best practices audit of their organization. www.HighBitSecurity.com

Get started now. Exceptional service awaits.