Archive for the 'PCI Dream Team' Category

23
Apr
20

Upcoming PCI Dream Team Events

On Tuesday, May 5, at 11AM ET (3AM UTC) the Dream Team will be doing a virtual session for Secure360. Go here to register for the Secure360 Conference.

Then, on Wednesday, May 13, we are holding a GDPR Birthday Party on BrightTalk to celebrate the second birthday of GDPR.  While we will be taking PCI questions, we will also be entertaining questions on GDPR as well.  To register for the BrightTalk session, go here.

We look forward to your attendance at both of these events.  As always, if you cannot attend either of these sessions, you are more than welcome to submit questions at pcidreamteam AT gmail DOT com.

23
Mar
20

Work From Home PCI Considerations

The PCI Guru got a question regarding PCI compliance for service providers in today’s emergency work from home (WFH) environment from a blog reader and it got The PCI Dream Team thinking about how does that work?  So, thanks to David Mundhenk of Herjavec Group, Art “Coop” Cooper of NuArx, Ben Rothke of Tapad and Jeff Hall of Online Business Systems for contributing to this list.

Ben & David wrote a piece on the topic last week, and the Dream Team has a webinar on Dealing with PCI DSS Compliance During the COVID-19 Crisis on March 25.

Thanks to the Coronavirus crisis, organizations are now scrambling to get their employees working from home.  This is presenting a whole new series of challenges to their compliance, technology and information security teams as these employees are now operating in a potentially less secure and definitely less private environment.

Home networks are going to be less controlled and secure.  Making matters worse is that most home networks today are Wi-Fi based, not wired, so data is flowing over untrusted networks because everyone in the house knows the Wi-Fi password (assuming there is one and it is not the default).

Bring Your Own Device (BYOD)

The biggest issue we are encountering is those organizations that need to rely on workstations owned by employees because they do not have company-owned and configured equipment to provide.  I have seen many a Tweet and LinkedIn post discussing the shortages of equipment for work from home and what options do they have.  The problem stems from most business continuity plans focusing on events that affect a business location or a community, not the entire country.  As a result, the idea of a pandemic forcing people to work from home was not thought of as a realistic threat.

As a result, bring your own device (BYOD) is the only answer in the near term to getting people working from home.  In discussions not only amongst the Dream Team but with other QSAs, there just do not seem to be any good answers for using BYOD and maintaining PCI compliance.  None of us can come up with ways to maintain compliance with BYOD because there are just too many factors involved from anti-virus (many varieties), limited or non-existent central monitoring and management, vulnerability scanning, penetration testing, patching, differing hardware, differing operating systems and a host of other issues that make it impossible to verify compliance let alone maintain compliance.

One potential option to reduce risk and gain better control with BYOD is using virtual desktop infrastructure (VDI) solutions such as Citrix Workspace, VMware Horizon or Windows Remote Desktop Services.  If you have that infrastructure in place, then we would recommend expanding it for WFH remote access.  If you do not have that infrastructure, you may be able to use Amazon Web Services (AWS), Microsoft Azure, Google Cloud or similar cloud environments to stand it up quickly.  That would allow you to reduce the risk of the BYOD being used but there still would be the risk of memory scraping and keyboard logging on the BYOD that must be managed.

That is not to say that you should not use BYOD as you need to keep your business running.  What it does mean is that you need to have a serious talk to your acquirer to determine how to handle this situation, what the risks are to your solution and then communicate the results of that discussion formally to your QSA.  You may even want to have your QSA on those calls with your acquirer to assist.  In these desperate times, I doubt that any bank is going to say you cannot stay in business as long as you can provide some controls and do your best to manage the risk.

We view BYOD though as a short term solution and that a longer-term solution needs to be developed as current estimates seem to indicate that the crisis will likely extend past the original estimate of four weeks.  That longer-term solution would involve acquiring the necessary hardware and software to implement a managed, secured and controlled environment that can be tested to ensure PCI compliance.

Company Provided Hardware and Software

For those companies that do have the equipment to send home with their employees, this is not a complete list, but a set of bullet points of ideas for how to address PCI compliance in our “new normal”.

  • The easiest topic is remote access. The PCI DSS explicitly calls out that a secure VPN (i.e., encrypted) with multi-factor authentication (MFA) for users to obtain access to the service provider network (8.3.2.a).  But where things can go sideways is complying with 8.3.1.a which requires MFA for non-console access to systems/devices in the cardholder data environment (CDE).  It goes awry because people think that the first MFA covers the MFA into the CDE and it does not.  The reason is that 8.3.1.a was designed to stop the phishing of Administrators to gain access to the cardholder data environment (CDE).  To stop that, you need additional MFA to access the CDE.  That does not mean a separate MFA solution (which would be ideal), but it does mean enforcing a delay in the single MFA so that the same MFA code cannot be used to access the internal network and then also the CDE.  A lot of organizations implement the delay in their remote logon script by invoking a timer delay that expires after the longest time a code can be active (usually 30 seconds).
  • A secure VPN is necessary to remove the home network from scope. Ideally, the VPN should be required to always be in use so that the workstation cannot get to the internet other than over the VPN.  For those that do allow the home network and internet to be accessible, you will need to ensure that the firewall on the workstation appropriately protects the workstation as well as implementing a host intrusion detection solution (HIDS).
  • VDI is also a solution because it allows for the use of thin-client and devices such as Chromebooks to be used to connect. Most VDI solutions also embed a secure remote connection via HTTPS or similar secure connectivity solutions.  If not then you will need to use a secure VPN as documented above.  However, even a thin client runs the risk of memory scraping and keyboard logging so you need to manage those risks.
  • Review all automated workflows to make sure that they are producing the necessary audit trails that will provide evidence for you PCI assessment of what is happening. Where this becomes problematic is when the workflows are developed only for PCI compliance and with the changes for remote operations, those workflows are not picking up new users, devices and other changes that were made to allow for remote work.
  • People that typically work together but now are remote will start using Microsoft Teams, Slack, Skype and other collaboration platforms to communicate and that may include sharing cardholder data (CHD) or sensitive authentication data (SAD) at times. You will need to train and quickly remediate situations if CHD/SAD enters these applications as well as periodically reminding these people that the use of these communication systems for transmitting SAD/CHD is not allowed.  If possible, enable data loss prevention (DLP) or similar capabilities to identify and then redact SAD/CHD in any of these communications.
  • If you are pushing out call center operations, remember that softphones will bring the workstation they connect into scope for PCI compliance because the workstation is now directly connected to the CDE which is, of course, the VoIP telephone system. That means an increase in scope and that those workstations need to be hardened, managed, logged and controlled for PCI compliance.  Call center operations may also require additional network segmentation to be put in place to ensure the size of your CDE does not exponentially grow.
  • While not entirely PCI related but needs to be noted are some other remote call center operation issues to consider that could make compliance with contractual obligations regarding privacy and confidentiality of data discussed or processed by the operator. You may need to supply operators with shredders, printers, additional monitors and other equipment to ensure privacy and productivity.  You may also have to instruct people to locate their work area to a bedroom or other room where a door can isolate the operator while they work so that family members do not come into contact with information or documents they should not view.
  • Ensure that you have ways to document changes happening, their review and approval. A lot of organizations have paper forms, Excel spreadsheets, email forms, etc. they use that sometimes can get lost in people’s inboxes, archives and folders or just lost, period.  You need to make sure that the change management system will work in the remote mode and that change evidence, reviews and approvals are maintained.
  • Logging should not be an issue unless your organization was not logging the VPN or other devices because they were not in scope for PCI compliance but now are in scope. So, you need to review your new workflows to ensure all devices and systems are logging to your SIEM or logging solution so that you comply with PCI requirement 10.
  • Encryption key management could become an issue particularly if your process does not support remote management. This can happen with some hardware security modules (HSM) and systems that require that the key custodians physically input their seed values into the device’s console.  So, going on-site may be required for encryption key changes and that may require formal approval from local authorities to occur.

These are the top of mind ideas that we were able to come up with for this discussion.  However, every environment is different so not everything discussed may be possible for your organization to use and maintain compliance.  We would recommend you work with a QSA to make sure that what you are attempting to do is not creating risks you are unwilling to accept or if you cannot manage appropriately.

We wish all of you the best of luck during this crisis.  We will get through this, but it will likely take some ingenuity in how that happens.

Also, be aware that the Council and the Card Brands are working on this topic as well and I expect more from them in the coming weeks.

Stay safe and healthy.

 

Other WFH resources:

CISA Coronavirus Guidance – https://www.cisa.gov/coronavirus

NIST Teleworking Guidance – https://csrc.nist.gov/publications/detail/sp/800-46/rev-2/final

SANS Work From Home Webcast – https://www.sans.org/webcasts/archive/2020

20
Mar
20

Special PCI Dream Team COVID-19 Session

On Wednesday, March 25, at 1800 UTC (2PM ET) the PCI Dream Team of Ben Rothke, David Mundhenk, Art Cooper and Jeff Hall will be on BrightTalk to discuss the impact on PCI compliance of the current COVID-19 crisis.

This should be a tough session as a lot of organizations are facing difficult decisions as they try to implement work from home (WFH) as well as maintain PCI compliance.  Thanks to the crisis, there are constraints that ordinarily would not be a problem such as a difficulty in obtaining hardware and remotely connecting a large workforce.

To register for the session, go here.

As usual, if you are unable to attend, please send your questions ahead of the session to pcidreamteam AT gmail DOT com.

We look forward to your questions and hope we can provide some help.

Thank you to all of you that attended. We had a lot of great questions from the attendees. We apologize for not being able to get to all of the questions, but I intend to follow up on a few of those in future blog posts.

20
Jan
20

PCI Dream Team LIVE!

We finally have a date and time for the LIVE PCI Dream Team session at Secure360 in Minnesota.  The PCI Dream Team will be appearing on Tuesday, May 5, at 1:15PM in Waconia 2.  Secure360 is the oldest, largest and best security event in the Upper Midwest.

As with all PCI Dream Team events we will be accepting your questions through our pcidreamteam AT gmail DOT com email account. (You can always submit questions through this email address and we will address them at our next session).

This year’s Secure360 will be at Mystic Lake Center which is a great venue near Prior Lake southwest of Minneapolis.

We look forward to seeing all of you there!

 

26
Dec
19

The PCI Dream Team Kicks Off The New Year

On Tuesday, January 14, at 1800 UTC (1PM ET) the PCI Dream Team will be back in session on BrightTalk for one hour.  If you would like to attend, please register here. As always, the session will be recorded for playback at a later time.

While you can submit questions during the BrightTalk session, do not forget that you can also submit your questions for this Dream Team session at pcidreamteam AT gmail DOT com. We will do what we can to get to all questions during our hour.

Also, the PCI Dream Team will be doing a LIVE session at the 2020 Secure360 conference in the Twin Cities of Minnesota on May 5 – 6 (time and date yet to be determined). So if you want to attend a great security conference and get to meet and greet the PCI Dream Team, please attend Secure360 in 2020.

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.

Thank you to al that attended out latest session. We received a lot of great questions and those we did not get to we are saving those questions for out next session.

If you are going to the 2019 (ISC)2 Security Congress in Orlando (https://congress.isc2.org/events/-isc-security-congress-2019/event-summary-f1be4e92a1b54d92acdb1b8007fe91cf.aspx) you will be able to see the PCI Dream Team in person. We will be speaking on Wednesday, October 30, at 830AM in Northern E2. We hope to see you in person in Orlando.

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.

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.

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.

19
Dec
18

The Remote Worker Dilemma

We received the following question during the last PCI Dream Team session back in October.

“We have a call center that sometimes takes a credit card numbers from customers.  Our senior management keeps pushing us to come up with a work-from-home option for some of our call center employees in case of DR and Business Continuity.  We keep telling them that PCI says that all components of such a home setup is subject to PCI standards and thus is impossible, Have any of you seen any solution that would allow this?”

Since that session the Council released the new telephony information supplement that has created a stir in the PCI community.  I wrote about the new information supplement a few weeks back so I will not cover that here, but I will rely on it to answer this question.

First and foremost, remote workers are allowed under the PCI DSS as there are no requirements that prohibit it.  However, there are PCI-related considerations when you want to implement such an approach.

You will obviously need to develop PCI compliance policies, standards and procedures that will support remote working.  If your organization already has policies, standards and procedures for clean desks, secured work area, protection of information, proper handling of sensitive authentication data (SAD) or cardholder data (CHD), then you probably have the bulk of what you need.  You will need somewhere in your documentation to allow for your organization to conduct annual and spot inspections of remote working environments for compliance with organization policies, standards and procedures.

If you do not have those policies, standards and procedures, then you will need to get those published, approved and all employees and contractors to formally acknowledge them.  Most organizations’ policies, standards and procedures work just fine for corporate environments but do not consider the situation when workers are not in a corporate facility.  As a result, it is not unusual to see organizations develop policies, standards and procedures that take into account that the remote workers’ working environment might not necessarily be as secure as those at a corporate controlled office.

The annual inspection can consist of the remote worker taking a picture of their work environment and filling out a form that ensures the remote worker is complying with relevant organizational policies, standards and procedures as related to remote working.  I have clients that have remote workers fill out the relevant PCI SAQ depending on their remote worker environment.  In all cases, the employee signs the form/AOC stating that they are compliant with all relevant policies, standards and procedures.

It is when the organization has questions, issues or concern with a remote worker is when the spot inspection clause becomes useful.  The spot inspection capability allows organization management or an auditor to go to the remote worker’s location and personally examine the work area to ensure that it complies with all policies, standards and procedures.

With the paperwork out of the way, let us now discuss the technical challenges related to remote workers.  The goal here is to minimize the PCI scope of the remote worker’s configuration.

The easiest way to do this is using a point-to-point encryption (P2PE) validated solution or an end-to-end encryption (E2EE) solution for the keying of SAD/CHD.  Of course, this means that you will have to ensure that your application will work properly with a P2PE/E2EE solution which further means not allowing SAD/CHD to be keyed through anything other than a P2PE/E2EE validated terminal also referred to as the point of interaction (POI).  This can also mean pairing the P2PE/E2EE solution with tokenization if your application is expecting CHD back at the end of the transaction.

But P2PE/E2EE only addresses the transaction, not the conversation that results in the transaction.  To reduce costs of remote workers, organizations typically implement a softphone.  Softphones are great.  However, they result in a PCI scoping problem.  As a reminder, when a telephone system is used for having conversations involving SAD/CHD, it puts that system and networks in the cardholder data environment (CDE) also known as a Category 1 system.  As a result, any other system that connects to the telephone system is now also part of the CDE.  Since a soft phone cannot be readily logically or physically segmented from the workstation it connects, it drags the workstation into PCI scope regardless of whether or not SAD/CHD is discussed.

The solution to the softphone issue is to use a physical VoIP phone with a headset.  But it is not as simple as just swapping in a physical phone for the softphone.  That physical phone needs to be on a logically or physically segmented network that does not include any devices that you desire to be out of PCI scope.  It is that segmentation that drives up the cost of the remote worker configuration because you now need to have a managed network device to allow for separate VLANs or physically separate network connections.  Not impossible, just costlier than delivering a cable/DSL modem with four Ethernet ports to the remote worker’s location and being done.

As a result of all of this, it is not unusual for organizations that allow for remote workers that need to be PCI compliant to supply those remote workers with a US Department of Defense compliant document shredder, computer or workstation, router, network switch, display(s), keyboard(s), secure POI(s), telephone(s) and any other equipment necessary to ensure compliance with the PCI standards.

In addition to this, there may be other requirements due to the European Union’s General Data Protection Requirement (GDPR), Health Insurance Portability and Accountability Act (HIPAA) or other security or privacy regulations or requirements.




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

July 2020
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  

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

Join 2,264 other followers