07
Aug
19

The PCI Dream Team Is Back

On Thursday, August 15, at 1PM ET/5PM UTC the PCI Dream Team will be back online to answer your toughest PCI questions.  Sign up at https://www.brighttalk.com/webcast/288/361775 to attend.

If you would like to submit questions before the session or will be unable to attend the live event, send them to pcidreamteam AT gmail DOT com.

As always, we look forward to your questions and attendence.

Advertisements
23
Jul
19

Requirement 1.2.3 And Not Applicable

I had a question posed here a week ago that resulting in a discussion regarding whether or not PCI DSS requirement 1.2.3 can be marked as ‘Not Applicable’ or NA.  What prompted this discussion is a post from long ago where I discussed certain requirements that cannot be marked as NA.

The discussion revolved around this statement from page 4 of the PCI Report On Compliance (ROC) Reporting Template in a discussion about the difference between Not Applicable and Not Tested.

“Using the example of wireless and an organization that does not use wireless technology in any capacity, an assessor could select “N/A” for Requirements 1.2.3, 2.1.1, and 4.1.1, after the assessor confirms that there are no wireless technologies used in their CDE or that connect to their CDE via assessor testing. Once this has been confirmed, the organization may select “N/A” for those specific requirements, and the accompanying reporting must reflect the testing performed to confirm the not applicable status.”

I can tell you right now that the Council’s Assessor Quality Management (AQM) team has called out the fact that when they say “does not use wireless technology in any capacity” they mean absolutely NONE, NADA, ZIP.  I cannot tell you the number of discussions I and others have had in AQM reviews where they mark you down for missing this nuance.  At the end of the day, their rule is that the minute a QSA sees wireless whether it is corporate wireless, guest wireless, whatever, that means that 1.2.3 must NOT be marked NA.

In discussions with a variety of QSAs, we all remarked that we regularly see sections 3.7 and 3.8 mention wireless networks as well as it is documented in the network diagrams in section 4.1.  Yet, when you got down to 1.2.3 the QSA would mark it NA because the wireless did not connect to the CDE.  In today’s ultra-connected world, it is extremely rare (as in almost never) that wireless is NOT present and operated by any organization.  Even data centers have wireless installed in their facilities.

Even if that wireless is not in the CDE, the QSA is required to validate that the wireless has no direct access to the CDE.  That is exactly why 1.2.3.b specifically asks:

“Verify that the firewalls deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.”

The QSA must reply either ‘Yes’ or ‘No’ to 1.2.3.b.  There is no NA option here.

If the answer to 1.2.3.b is ‘No’ (which is usually the case), the QSA is required to:

Describe how firewall and/or router configurations verified that firewalls deny all traffic from any wireless environment into the cardholder environment.”

The bottom line is – if there is ANY mention of wireless networking anywhere other than the requirements in 11.1, then 1.2.3 must NOT be marked as NA.

Hopefully we are all clear on how to address wireless networks now.

21
May
19

An Inadvertent Service Provider

A discussion came up on the last PCI Dream Team session regarding situations at universities that have bookstores and cafeterias operated by third parties on their networks and those vendors processing payment card transactions.  QSAs encounter this situation not only at universities and colleges, but also with hospitals, health clinics and large corporations.

The Situation

As organizations focus on customer and employee perks, QSAs encounter third parties operating business outlets within a variety of organizations.  These businesses include coffee shops, convenience stores, dry cleaners, bookstores, restaurants, cafeterias, parking ramps, travel agencies, pharmacies, health clubs and a whole host of other businesses.  Of course, all of these third parties accept payment cards for their services and need a way to process those cards.  Organizations offering these perks have existing wired and wireless infrastructure that get leveraged to connect these third parties to the internet and their payment processors.  Thus, bringing that network and everything attached to that network into scope for PCI compliance.

As a result, this situation creates a PCI compliance problem because the organization is now a service provider as well as a merchant.  The organization thought by outsourcing these businesses it was reducing PCI scope not increasing scope.  But scope increases because since they are now considered a service provider, they must provide each of these third parties with a Service Provider Attestation Of Compliance (AOC) for that network connectivity.

But it can and does get worse.  I have encountered situations where the outsourcing organization provides help desk, firewalls and other support services for these third parties, further complicating their PCI compliance responsibilities.

What Do You Do? Option 1 – Get Out Of Scope

There are some ways to get out of scope, but these can be complex and/or expensive.

The first way to get out of scope is to force all of your third parties to get their own network connectivity from their own internet service provider (ISP).  The problem with this is that an ISP will likely have to run wire into your facilities to make those connections.  That can be disruptive as well as expensive and complicated due to locations within existing buildings.  And what if each business wants their own ISP because of a contract relationship?  That will mean multiple ISPs tearing up your facilities.  Not necessarily the best situation.

The most extreme solution to get out of scope is for the outsourcing organization to implement carrier equipment and become a “carrier” to these third parties.  I have had a few clients go down this road, but it is not cheap and can also be more trouble than it is worth.  However, for a university or large hospital/clinic complex with lots of third parties, this solution can actually be a cheaper route to implement and operate.

But the beauty of these solutions is that your organization is totally out of scope so there are no service provider PCI assessment requirements.

What Do You Do? Option 2 – Reduce Scope

There are also a couple of ways to reduce scope.  But reducing scope requires at a minimum the creation of a Service Provider SAQ D and AOC.

The quickest and easiest way to reduce scope is that the outsourcing organization can implement end-to-end encryption between the third party’s connection and the internet.  However, this adds the requirements in section 4 to the assessment as well as keeps the endpoints in scope for PCI compliance.

Another option to reduce scope is to require these third parties to implement encryption from their operation to anyone outside of the outsourcing organization.  While this seems simple, it usually never is simple.  Never mind the fact that if that encryption is ever stopped (most times without your knowledge), the outsourcing organization’s network is back in scope.  Typically, when this gets brought up as a solution, a lot of the third parties balk or say they do not know how to encrypt their connections.  Never mind the fact of the complexity of proving that the outsourcing organization does not have encryption keys and that every third party connection is encrypted becomes problematic.  It ends up more trouble than it is worth.

The only good news about reduced scope is that you only need to fill out a Service Provider SAQ D and AOC because you have no idea the transaction volumes being processed by any of these third parties.  That said though, it is additional paperwork that needs to be filled out annually and given to all your third parties.

Heaven help you though if you offer firewall, help desk and other support services in addition to connectivity.  Those just complicate your compliance and reporting efforts.  All I can say is, if you can stop offering those services, stop.  If you cannot stop those services, then be prepared to document and report on the PCI compliance of each of those services.  That can be done in a single assessment, but the AOC must cover each of those services provided individually in a separate section 2g.

Never mind the fact that if some of those services offered give your organization insight into the number of transactions processed by your third parties such as you provide payment processing under one or more of your merchant identifiers, you may end up having to conduct a Service Provider Report On Compliance (ROC) because the transaction volume exceeds one of the card brands’ annual service provider transaction volumes.

There you have it on third parties and their payments on your network.

22
Apr
19

More On The NIST Password Standard

Apparently, I touched a nerve with my post on the National Institute of Standards and Technology (NIST) password standards discussed in Special Publication (SP) 800-63B.  As a result, I thought I would walk you through my logic by using a compensating control worksheet (CCW) approach since this is what you will have to do for your PCI assessment if you chose to rely on the NIST guidance.

[SPOILER ALERT: It is possible, but I doubt it is worth all the effort.]

First, let us review all of what a CCW needs to comply with the Council’s requirements.  From Appendix B of the Report On Compliance (ROC) Reporting Template.

“Compensating controls must satisfy the following criteria:

  1. Meet the intent and rigor of the original PCI DSS requirement.

  2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Guidance Column for the intent of each PCI DSS requirement.)

  3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)

  4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.”

QSAs can get stuck on the third point because the Council also seems to focus on that point in their Assessor Quality Management (AQM) reviews because QSAs miss that point so often.  However, the other three are also very important to apply to the compensating controls being discussed.

Now let us focus on is section 4 of the CCW where the organization being assessed is required to describe the controls they have in place that go “above and beyond” the requirement being compensating which in this case is requirement 8.2.4 which requires password changes every 90 days or less.  I pick that requirement because that is the one most often cited by clients as why they want to use the NIST standard.  Most want to go to a 12-month password change interval.  These controls are going to come from pages 13 through 15 of the SP800-63B.

  • All passwords are required to be [value greater than eight] characters or greater in length.
  • When passwords are modified, they are assessed against [name of credential verification source/service], [name of dictionary word list used], repetitive or sequential characters and context specific words are checked and rejected if found.
  • Authentication is only conducted using [encrypted authentication protocol(s)].
  • Passwords are hashed and salted for storage using [hash algorithm and appropriate salting technique].
  • [Name of password vault solution] is used to securely store and generate strong passwords that meet the aforementioned criteria.
  • A password strength meter is provided to assess the password against these aforementioned criteria to indicate to the user when they have met all of the criteria.

To comply with the NIST guidelines for passwords an organization needs to implement all of these controls.

So how do they match up with the four criteria for a CCW?

Above and Beyond

This is the easiest one to tackle because almost all of the controls are above and beyond.  What?  Almost?

There are a couple of controls that do not meet the above and beyond test.

The first is the easiest to discuss and that is “Authentication is only conducted using [encrypted authentication protocol(s)].”.  That control does not pass above and beyond because it is required by requirement 8.2.1 under transmission must use strong cryptography.  As such, that control cannot be relied upon in the CCW and must be removed.

The second one is the “Passwords are hashed and salted for storage using [hash algorithm and appropriate salting technique]” control.  This discussion gets sticky because requirement 8.2.1 states that storage of credentials must also use strong cryptography which is not very specific.  I would argue that any sort of reasonable response here would be required by requirement 8.2.1 and therefore this requirement would also be ineligible to be used.

Only the password length is specified by the PCI DSS and as long as a value greater than eight is picked, that meets above and beyond.  However, we need to discuss this value further under intent and rigor.

All of the remaining controls are not specified in the PCI DSS, so those are all considered above and beyond.

Intent and Rigor

For intent and rigor, we need to look to the guidance provided for requirement 8.2.4.

“Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.”

Remember, we are looking at a 12 month password change interval, so we need to consider intent and rigor under that concept that we need controls that will allow a password to remain unchanged for 12 months.

So let us look at the length attribute again.  Nine characters in today’s world without any complexity requirements can result in passwords able to be cracked in minutes.  Ten characters can be done in hours.  Only when we get to 12 characters and above do we get a value of at least 12 months or greater to crack.  As such, I would argue that you need 12 character long passwords or greater to pass the rigor requirement for justifying a 12 month change interval.

Passwords are assessed against a dictionary word list, context specific words and repetitive/sequential characters.  The key to this part of the second bullet is the extent of the dictionary word list.  The dictionary needs to be sufficiently large to provide the control that NIST desires.  The QSA is going to need to know how large the dictionary is, what is used as a reference to ensure that the dictionary has the appropriate words in its list and how often is the dictionary updated.  That would likely mean that these controls would need to be separated from the credential breach service control so that those aforementioned additional controls can be documented in the CCW. This would all have to be backed up by a proper risk assessment that documents that the review and updatee intervals of the dicutionary are appropriate and mitigate the risks.

Passwords being assessed to some credentialed breach source/service introduces an interesting twist to ensuring the security of a password.  But it also introduces an interesting discussion into the intent of requirement 8.2.4 which is to ensure the security of credentials.  NIST is only requiring that credentials be tested at the point they are changed.  But what happens if sometime during the 12 month interval that those credentials are compromised?  The intent of requiring a 90 day change interval was to reduce the risk of credentials becoming compromised for an extended length of time by changing one of those credentials at least every 90 days.

But NIST does not require monitoring of the credentials other than when they change.  Without constant monitoring of the credentials from a compromise service, how do you know when they need to be changed which is the intent of the change interval?

The PCI DSS does provide a bit of guidance on how the Council would likely approach this issue.  For reference I point you to requirement 3.6.5 which discusses this in regard to encryption keys that are suspected to have been compromised.  The reason I believe this is relevant here is that the PCI DSS does not require specific change intervals for encryption keys.  I would argue that the PCI DSS would view passwords changing at long intervals as requiring the same sort of control.  If the credentials are ever suspected of being compromised, then they should be changed.

Which brings up an interesting dilemma.  How do you monitor something that you have hashed and cannot recover?  Do we really want to have encrypted passwords in our authentication systems so that we can monitor them for compromise?  I seriously doubt that would be a good practice.

So with that said, we would need some sort of monitoring and alerting capability to warn if credentials do appear to be compromised such as monitoring for excessive logons, logons when the user is out of the office, logons from systems outside of the user’s area or building or other characteristics that would provide some sort of indication of credential compromise.  These controls would have to be added to the monitoring of the credential breach source to show that the credentials are changed when suspected of being compromised.

Similar Level of Defense and Be Commensurate

At this point, I think we have covered these two requirements for a CCW with our discussions about above and beyond and intent and rigor.

Where Are We With The CCW Controls?

Based on our discussion, here is what I think section 4 of the CCW would now have to look like.

  • All passwords are required to be [value of 12+] characters or greater in length.
  • When passwords are modified, they are assessed against [name of credential verification source/service]
  • Passwords are monitored for excessive logons, excessive failed logon attempts, logons when the user is out of the office and logons that occur from systems outside of the user’s area or building to provide an indication of credential compromise.
  • When passwords are modified, [name of dictionary word list/source used], repetitive or sequential characters and context specific words are checked, and the password is rejected if any of these characteristics are found. The dictionary is updated every [month/quarter/six months] and reviewed [semi-annually/annually] to ensure the dictionary contains an appropriate list of words.
  • [Name of password vault solution] is used to securely store and generate strong passwords that meet the aforementioned criteria.
  • A password strength meter is provided to assess the password against these aforementioned criteria to indicate to the user when they have met all of the criteria.

After looking at these controls, I would venture to say it is simpler and easier to meet the PCI DSS requirements than to implement these controls and make them work consistently and effectively.  Because remember, this is just section 4 of the CCW.  For section 5, you have to produce evidence that all of these controls are in place and working as designed.  Never mind section 6 where you explain how you maintain all of these controls.

So for those of you bent on using NIST, there you have it but I doubt it is worth the effort you think it is.  And this does not address the CCWs you will also need to write for 8.2.3 because you no longer enforce complexity and 8.2.5 because you no longer track the last four passwords used.  But those could be another post.  Yeah, I do not think so.  Not worth the effort because those CCWs will revolve around the controls in this one.

As I said in my original post, it might be better to wait for the Council to issue their guidance in v4 of the PCI DSS.

UPDATE: The PCI Council has created an FAQ to address this situation. https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-organizations-use-alternative-password-management-methods-to-meet-PCI-DSS-Requirement-8

02
Apr
19

The PCI Dream Team Rides Again

On Tuesday, April 23, 2019 at 1PM ET (1700 UTC) the PCI Dream Team will ride again and tackle The Cloud as well as any other tough PCI questions you have.  If you are interested, you can register using this link. (http://bit.ly/2OLhsYh).

We look forward to talking to everyone then.  If you have questions you would like the Dream Team to consider, please submit them to pcidreamteam AT gmail DOT com.

11
Mar
19

The New NIST Password Guidance

In June 2017, the US National Institute of Standards and Technology (NIST) issued new guidance on authentication in the form of four Special Publications (SP).

  • SP 800-63 is an overview of digital identity and the other three publications in the series.
  • SP 800-63A discusses digital enrollment and identity proofing.
  • SP 800-63B discusses authentication and lifecycle management.
  • SP 800-63C discusses federation and assertions.

This post is about SP 800-63B which covers the new password guidance from NIST.  In the vernacular of NIST, a password/passphrase is referred to as ‘Memorized Secret Authenticator’.  Here are the key attributes offered by this new NIST guidance:

  • A Memorized Secret Authenticator must be at least a minimum of eight characters in length and should allow for at least 64 characters.
  • All printable ASCII characters should be allowed for comprising a Memorized Secret Authenticator.
  • A replacement Memorized Secret Authenticator used to reset a forgotten/corrupted/compromised Memorized Secret Authenticator must be at least six characters long.
  • A Memorized Secret Authenticator can be forced to comply with blacklisted words/phrases to avoid guessing or brute force attacks.
  • No hints are allowed to be provided to unauthenticated users.
  • When changing a Memorized Secret Authenticator, the provider should ensure that the new Memorized Secret Authenticator is not known to be compromised, a known word or expected value such as ‘12345678password’ or similar.
  • The Memorized Secret Authenticator can be displayed if it cannot be readily observed by others.
  • Verifiers should not impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
  • Verifiers should not require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers shall force a change if there is evidence of compromise of the authenticator.

A lot of clients are pushing hard to use these new NIST rules in place of the PCI DSS requirements.  As a reminder, the PCI DSS requires the following when it comes to passwords.

  • 8.2.3 Passwords/passphrases must meet the following: require a minimum length of at least seven characters, contain both numeric and alphabetic characters. Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above.
  • 8.2.4 Change user passwords/passphrases at least once every 90 days.
  • 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used.
  • 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.

So where are we in regard to NIST versus PCI DSS?

On length, we are good.  Both documents have a minimum of 8 characters.

Complexity is a sticking point as the PCI DSS imposes complexity rules on the composition of passwords, NIST states that the authentication system should not impose such composition rules.

NIST is more restrictive on the checking of password/passphrase changes to include ensuring that they have not been used somewhere else that was compromised.  In addition, it also requires that if believed to be compromised, the authentication system should force a change.

However, it is when we get to changing passwords/passphrases on a specific interval that we run into trouble.  NIST advises that arbitrary changing of passwords/passphrases are not required whereas the PCI DSS states that passwords/passphrases should be changed every 90 days.  NIST counts on the fact that they require to monitor that credentials have not been compromised to support their not requiring an arbitrary change of passwords.

The first thing that comes to peoples’ mind is the guidance to requirement 8.2.3 which states:

“Strong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non-existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.

This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.)

Note: Testing Procedure 8.2.3.b is an additional procedure that only applies if the entity being assessed is a service provider.”

What people focus on is the last sentence before that note that states:

“For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.)”

They then refer the QSA to that statement and say that gives them license to apply that guidance to requirement 8.2.4 and the other password related requirements.  Unfortunately, that guidance only applies to 8.2.3 as it clearly references “password strength” and nothing about change interval or anything else related to password attributes.

Another key point is that the guidance for 8.2.4 makes no reference to SP 800-63.  The Council will tell you that if SP 800-63 applied to 8.2.4, they would have included the same sort of reference in the guidance for 8.2.4 as they did in 8.2.3.  Without that reference, a QSA should not be using the new NIST guidance to replace the requirements specified in 8.2.4.

So, with that path ruled out, the second thing that comes to peoples’ mind is, we will write a compensating control for following the NIST guidance.

There is only one thing wrong with the compensating control approach and that is that a compensating control must go “above and beyond” the PCI DSS requirement.  Above and beyond 90 days would be a value less than 90, not more than 90.  The test is very specific that the change interval must be no more than 90 days.  As a result, there is no compensating control that will get you above and beyond the intent of a 90-day change interval.

That is not to say that you and your QSA cannot write such a compensating control.  The question then becomes if you can get your acquiring bank to sign off on such a compensating control?  There are a number of banks that are not so diligent with their reviews of PCI ROC filings and such a compensating control would sail under the radar. But that is no guarantee.

However, such a compensating control puts your QSAC at risk of remediation if the PCI ROC is selected as part of the Council’s Assessor Quality Management (AQM) review.  Such a compensating control would not be viewed favorably by the Council because it flagrantly violates the rules of a compensating control.  Remediation, while not a death nell to a QSAC, does adversely impact sales of PCI assessments and services and makes current clients uncomfortable, so going into remediation is avoided by QSACs like the plague.

The bottom line is that until the Council makes a change to the PCI DSS (i.e., v4), you are stuck with its password/passphrase requirements regardless of what other standards setting bodies state.

UPDATE – June 28, 2019

This is from the PCI SSC June 2019 Assessor Newsletter.

PCI DSS v3.2.1 to NIST Cybersecurity Framework Mapping
In July, the PCI Security Standards Council (PCI SSC) will be releasing new resources that show how the PCI Data Security Standard (PCI DSS) maps to the NIST Cybersecurity Framework. PCI DSS and the NIST Cybersecurity Framework share the common goal of securing data. The Mapping of PCI DSS to the NIST Cybersecurity Framework will provide a resource for stakeholders to use in understanding how to align security efforts to meet objectives in both PCI DSS and the NIST Cybersecurity Framework.

Details about the Mapping of PCI DSS to the NIST Cybersecurity Framework will be coming soon to the PCI SSC website.”

08
Mar
19

Sins Of The Past

This was a question we got from our last PCI Dream Team session on the Cloud.

“Issue – found CVV in historical call recordings that need to be purge/delete. We are not able to purge the entire call record and still need to keep it for record retention. What tools should be evaluated to help address this issue?”

A lot of organizations are discovering that how they did things in the past did not meet PCI, GDPR or other legal or regulatory requirements when data in their possession needs to be protected.  Gone are those freewheeling days of collecting data without worrying about how to secure and protect it.  Customers and the public at large are realizing the value of their information and the need to protect it.  All of which starts organizations thinking about how to reduce the risk they have because they have all of this data and they are being held responsible for having it.  The patchwork of state laws in the US hold a lot of organizations at risk, some higher than others.

There are also the sins that come to light down the road.  It is not unusual to have a PCI in scope application crawl out of the woodwork years down the road at large organizations.  It should have been identified way back when the organization was starting out in PCI, but somehow was missed and just now turned up.  Unfortunately, these discoveries tend to turn up at the 11th hour of the organization’s current PCI assessment and there is no way to include the application without causing a delay in issuing the ROC.

Surprise!

So, let us talk about the last case first.  The application that we uncover very late in the PCI assessment.

What should happen and in the example cited did happen, was a conversation with the acquiring bank.  The situation was explained as well as the risk involved (it was storing encrypted PAN) and the bank was asked do we delay filing the ROC and assess this application (likely a delay of longer than 90 days) or do we keep moving ahead as planned and pick up the newly disclosed application in the next assessment?

The bank decided that they did not want to delay the ROC filing since it was just out of our QA process, had been sent to the client for their review and was due in around 30 days.

The client looked further into the application and determined that it could be easily remediated with tokenization from their gateway.  As a result, when time came for the next year’s assessment, the application had been remediated with tokenization.  We took a look at it and confirmed it no longer contained encrypted PAN and explained to the bank that it would no longer be in scope.

However, things do not always end that well.  I have also had occasions where no remediation was possible for a variety of reasons and had to go in the following year and assess the new discovered application in all its PCI compliance (and in some cases non-compliance) glory.

Remediate

Getting back to our original sin, so to speak.

First and foremost, you may not be able to remediate your files due to legal or regulatory constraints.  So, before you go charging ahead on your remediation efforts, make sure you discuss it with your legal and compliance folks to ensure you are not creating an even bigger problem.  Assuming you are allowed to remediate data, you can proceed with reading the rest of this section.

Structured data is typically easy to remediate.  You find out what XML tags to look for, fields or what database columns are involved, you develop a program to remediate the data to first six and/or last four for the PAN or erasing data for any information you were not supposed to keep and execute.  Easy.  Well, easy until you take into account backups which can complicate remediation if you cannot just erase the backups.

Unstructured data as with call recordings and notes/comments fields can be a nightmare to remediate.  The reason of course is that the data has no structure and does not necessarily occur in the same place.  Unlike XML or a database where data is at least tagged or in a column, unstructured data exists wherever it exists and programs to remediate the sensitive data need to find it and then eradicate it.  That introduces the problem of false positive results.  I wrote all about the “fun” of trying to find cardholder data (CHD) five years ago and it has not necessarily gotten any better.  The bottom line with unstructured data is that it may not be possible to completely remediate the problem.

However, the best you may be able to do is to remediate the data when it is encountered.  Going back to call recordings, if the quality assurance review process or any process that has someone review recordings encounters CHD they redact the information from the file so that it is no longer in that file.  Not perfect, but slowly you reduce the amount you are storing.  You still have to encrypt the files for protection, but you are making an effort to reduce risk by reducing the amount of viable data.

Isolate It

This most commonly occurs with call recordings, but I have encountered the occasional “legacy” application that it applied to as well.

In the either case, the old system is being decommissioned and a new solution (usually outsourced) is being implemented.  The question comes up, “what do we do with the old system?”  The reason is that for customer service, legal and/or regulatory reasons it cannot just be wiped and destroyed.  It needs to be retained for some period of time before that can happen.

The answer is to keep the system powered up, but off any other network.  If people need access, they need to go to a PC or workstation that is connected to a private, air gapped, isolated network that consists of the old system and the PCs or workstations to be used to access the old system.  No internet or other network access is provided, only a network that contains those few isolated systems.  This will allow the system and workstations to age yet remain protected because of the air gap.  Remember, the PCs and workstations will also age along because it is highly likely that new software may not allow connectivity to the old system.  This is why everything will need to be air gapped.

I usually get asked for the reason to keep the old solution powered up.  That comes from a study done long ago by IBM.  What the IBM study found was that systems that get powered off after years of operation have a tendency to fail after being powered off for any extended length of time (i.e., long enough to cool down).  As a result, if you intend to keep the system around and available, you best keep it powered up albeit isolated as discussed earlier.

One of the larger issues with isolation will be monitoring of the air gapped network to ensure it remains air gapped and how you respond if that air gapped is breached.  There are a number of ways to address this issue, so pick the solution that best fits your environment.

Isolation is not a perfect solution.  It will likely require a number of compensating control worksheets (CCW) to address the fact that you have a number of “antique” systems around.  So be prepared for that work effort as it will likely not be small.




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

August 2019
M T W T F S S
« Jul    
 1234
567891011
12131415161718
19202122232425
262728293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,108 other followers

Advertisements