26
Aug
15

A Better Mouse Trap?

I had the pleasure of recently talking to David Marsyla, CEO of PocketKey (http://www.pocketkey.com) about their new solution to secure card transactions. PocketKey is an independent attempt to address security issues with card transactions, particularly card-not-present (CNP) transactions such as those related to eCommerce. If any security solution was needed, it is in the CNP space.

While PocketKey seems to provide a very secure method of conducting transactions, during our conversation, I expressed my concerns about their business model.

  • We have seen this before. Back around the turn of the century, Visa, MasterCard and American Express all flirted with similar schemes that required their EMV cards to be inserted into a serial device connected to a PC to be used online. Unfortunately, very few Web sites ever supported their application programming interfaces (API) so these solutions disappeared as quickly as they had been rolled out.
  • It is not as portable as I would have hoped. PocketKey needs to be plugged into your PC, smartphone or other device that can provide Internet access. If an application on your device supports the PocketKey API, then the application can store the encrypted CHD information from the PocketKey for use in future transactions.
  • It requires application changes. In order for PocketKey to work, applications must be modified to handle the PocketKey API to get the full potential out of the solution. This means that PocketKey needs to get application providers on board for their solution to be implemented. In my very humble opinion, the best solution is one that does not require any application changes at the merchant end.
  • It requires the cooperation of transaction gateways, processors or banks. Not only do applications need to be addressed, but then card transaction gateways, processors or banks need to support PocketKey to work because the encrypted data generated by PocketKey needs to be converted at some point to actual cardholder data (CHD) for approval.
  • EMV provides similar capabilities. EMV cards have the ability to secure transactions through the use of dynamic primary account numbers (PAN), dynamic card verification values (CVV) and other security features. However these capabilities also require changes with applications as well as with transaction gateways, processors or acquiring banks in order to work. Do not be surprised if once the US EMV roll out is completed that, wonder of wonders, Visa and MasterCard then tout these “new” security features and push for their implementation by merchants, gateways, processors and banks.

It is not that these limitations cannot be surmounted so much as they require cooperation within the application and transaction processing communities to make it work. It is nice to see that someone is trying do something to address fraud problems. Card present fraud is almost a thing of the past and will be once magnetic stripes are completely gone (still a long time before this happens). However CNP fraud continues to grow as attackers find it the only way to quickly monetize their illegally obtained CHD.

I wish PocketKey all the best and hope they attract the necessary partnerships to make their business model work.

08
Aug
15

The Third Party Dilemma

I am starting to see more and more of this situation with my mid-size and larger clients, the third party that is using the client’s network to process and transmit cardholder data (CHD).

Where I consistently encounter this are at internal cafeterias where a third party operates the cafeteria and is providing their own point of sale (POS) solution to process card transactions. Another example where this is common are mailrooms that are operated by third parties and employees can buy stamps and ship personal packages with the third party taking cards for payment. Finally, another place where this is common is health care facilities, particularly hospitals, where the cafeteria is operated by a third party, the gift shop is operated by another third party, the pharmacy is operated by a third party and so on. As we go forward, I would expect that this situation will become more and more commonplace as organizations outsource more and more back office functions to third parties and focus on their core business.

A lot of these third parties have ended up on clients’ networks. They may or may not have been segmented away from the rest of the client’s network, but they typically sit behind the clients’ firewalls and other security measures. With the focus on requirements 12.8 and 12.9 regarding the management of third parties, these outsourcing environments are receiving new scrutiny as clients begin reassessing how these third parties are provided network and Internet access as well as PCI compliance, contract and other regulatory and legal issues.

So what are your options if you are involved in such arrangements? Here are some thoughts.

  • Ignore the problem and hope it goes away. Yes, believe it or not there are a lot of organizations that have found out that their organization is chock full of such situations and have just tossed up their hands and have decided to put off addressing the issue. Unfortunately, if the organization is required to perform a PCI assessment, this is not an option and they end up having to address it as part of their own assessment. Unfortunately, the problem does not go away because the third parties ask for an AOC of the organization for the network services they are providing.
  • Wide Area Ethernet. In this scenario, your organization becomes a telecommunications carrier providing Internet access to any third party over a separate WAN. This requires Ethernet WAN or Metro Ethernet equipment that support WAN grade service versus LAN grade service. Third parties are provided access to the Internet but must provide their own infrastructure such as firewalls and switches. The bottom line is that your organization becomes no different than any other carrier such as Verizon or AT&T and will be out of scope.
  • Wide Area Wi-Fi. Similar to Wide Area Ethernet using the same WAN infrastructure equipment but using Wi-Fi (802.11a/b/g/n/ac) to deliver network access. While this avoids installation of wiring infrastructure, it means a separate secured Wi-Fi network from your existing Wi-Fi. In addition, depending on how it is engineered, it could suffer from device overload if all of your third parties are in the same general area of your facility. But as with Wide Area Ethernet, your organization is considered a carrier and out of scope.
  • Another wireless alternative is putting your third parties on cellular connections. Where this can be problematic is in facilities that have poor cellular connectivity. In these situations, the organization may have installed cellular repeaters for carriers throughout the facility to improve cellular signals. However, not all of the facility may have repeater coverage where the third parties are located so there could be additional costs involved to get the coverage needed. Like Wi-Fi, cellular repeaters have limitations on the total number of connected devices, so areas where employees and the third parties congregate such as cafeterias could have issues with cellular access at breakfast, lunch and dinner times. This can be mitigated, but could create service issues for all users at heavy usage times.
  • P2PE or E2EE. Use of either of these solutions depends on your third party’s ability to use such a solution with their POS. With these solutions, you can create a separate VLAN for your third parties and they can all attached their points of interaction (POI, aka card terminals) to that VLAN and the traffic will be encrypted out to their respective processors. Where this solution does not work is when the third party uses a POS solution that does not support P2PE/E2EE. In addition, if all your third parties do not support P2PE/E2EE you may have to have a second solution for them. So it may be simpler to use one of the other solutions for consistency.
  • Physically Separate Third Party Network. This is a feasible option if you want to avoid the Wide Area equipment costs and requirements. However, the equipment used must be physically separate from your existing LAN equipment so as to qualify as being considered a carrier versus a service provider. As with the Wide Area solutions, you will not be providing firewalls or any other security services, just access to the Internet. Any security measures on this network would be the responsibility of each third party.
  • Separate Third Party VLAN. This is the option I typically encounter in most organizations. The organization’s network has a VLAN separate from its other networks but still relying on the organization’s infrastructure. The problem here is that this is not a carrier network because it is not physically separate from the internal network. Yes, there are ACLs in place that isolate the VLAN from others, but the infrastructure is shared and could come into scope if changes cause that to happen. This can still be acceptable if all third party traffic is encrypted such as with a VPN or P2PE/E2EE. But where this solution gets into trouble is when the organization providing the VLAN is also doing the encryption on behalf of the third parties. In the end, a VLAN solution will have to be assessed as a service provider because the organization is providing network access as a service not as a carrier.
  • Contract with their own carriers. This is an option, but potentially a rather messy option. That is because your third parties will need to contract with their own carrier which could create a wiring nightmare in your facilities. Particularly when new third parties come in or change carriers. There are ways to manage this but it requires planning and working with your third parties to make this effort successful.

These approaches all have their pluses and minuses, but hopefully you now have some ideas as to how to handle this issue.

02
Aug
15

Pushing The Limits

Here are some situations that QSAs encounter way too often.

  • Organizations that conduct their annual penetration test 30 days before the deadline to file their self-assessment questionnaire (SAQ) or Report On Compliance (ROC).
  • Organizations that conduct their final quarter vulnerability scan 30 days before the deadline to file their SAQ or ROC.
  • Organizations that decide to implement a compensating control worksheet (CCW) within 30 days before the deadline to file their SAQ or ROC.

Why are these situations a problem?

For the first two conditions, it is because if any of these results in a remediation effort, you either (a) have to remediate the findings and retest before filing your SAQ/ROC or (b) you have to put compensating controls in place and test those to ensure you are mitigating the risk of not remediating. Both of these situations can easily result in missing an organization’s compliance filing date.

For any CCW, it is a problem because you need to test all of the controls you are using to compensate for not being able to comply with a requirement and prove they are functioning as designed. In a lot of cases, those controls are going to be new controls and will take time to implement and then test.

While this “fire drill” is going on, your QSA sits and waits for you to complete remediation or implement your compensating controls so that they can test things and ensure that you are in compliance. Unfortunately, while your QSA waits, the stress of getting things done accumulates and people lash out at the QSA for their organization’s poor planning with the expectation that the QSA will just look the other way.

As a QSA, I would really like to help you. But as the old adage goes, poor planning on your part does not create an emergency on my part. Unfortunately, clients never see it that way when they are trying to hit a deadline, but it is still true.

So the way to minimize these situations is to plan ahead. Make sure that your annual penetration test is conducted no later than the start of the fourth quarter of your reporting period. This will give you around 90 days to address any issues and retest. For vulnerability scanning, I would also highly recommend doing your final quarterly vulnerability scan no later than the start of the fourth quarter of your reporting period as well for the same reason. These both are particularly true if your organization has a history of not getting passing results.

For CCWs, you want your QSA to identify those as soon as possible so that you can work on getting the controls in place and functioning. As a result, you should schedule your assessment to start no later than the third quarter of your reporting period and as early in that quarter as possible. If your organization is large, you may even want to start in the second quarter of your reporting period.

If you have CCWs in place and you will keep them in place for your coming assessment, you should be conduct your own testing prior to your QSA arriving to make sure you can fix any out of compliance situations.

So before you chew off the head of your QSA for some self-inflicted wound, think about how you got into this predicament. Next year plan better and your assessment will likely go better.

25
Jul
15

Compensating Control Refresher

From time to time, organizations find themselves in the predicament of not being able to meet a PCI DSS requirement due to business or technical constraints. To address that situation, the PCI SSC has provided the compensating control worksheet (CCW) as a way to work around those requirements that cannot be met directly as stated in the PCI DSS. When the CCW was updated back in 2010 for v1.2, I wrote about those changes and how to write a CCW. However, here we are at v3.1, five years down the road and I still see a lot of poorly and improperly written CCWs. As a result, I think it is time to take people through a refresher on the CCW.

First and foremost, the writing of any CCW is your organization’s responsibility. Your QSA can provide input and guidance, but the origination of the CCW is up to the organization. Once developed, your QSA can review it and make suggestions to enhance and improve the CCW. Once that has been completed, you will then want your acquiring bank to review it to ensure that they will accept it as part of your self-assessment questionnaire (SAQ) or Report On Compliance (ROC) filing.

Secondly, the format of the CCW is dictated by the Council and that format is provided in Appendix B of the SAQ D or in Appendix C of the ROC. Failure to use the proper format will create issues with your QSA, your bank and with the Council, particularly if you are doing a ROC. So please use the Council supplied format and not develop something on your own.

Finally, the PCI SSC has stated that any requirement can have a CCW. In the past, the Council instructed QSAs and ISAs that requirement 3.2 [Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process] was not allowed to have a CCW. At the 2014 Community Meeting, the Council backed away from that restriction and said that any requirement can have a CCW with no restrictions. However, as a QSA I would have a serious problem accepting a CCW for requirement 3.2 because storing sensitive authentication data (SAD) is the whole reason why the PCI DSS was created to stop.

To remind everyone, the CCW is broken into seven sections.

  • Identification of the PCI DSS requirement(s) being compensated.
  • The constraint or business justification for needing the CCW.
  • The original objective of the requirement(s) being compensated.
  • Identification of any additional risks because of the CCW
  • The compensating controls.
  • The procedures your QSA/ISA followed to confirm that the compensating controls are in place and functioning.
  • The procedures followed by your organization to maintain the compensating controls.

While the Council tells everyone to have an individual compensating control for each requirement, there are some places where a compensating control is the same for a number of requirements. This most often occurs for requirements in section 8 around the various user management requirements or 6.1, 2.2, 11.2 and the processes of vulnerability management. I would highly recommend using one CCW per requirement, but I can understand why you might combine some. Just be judicial in combining them. Also, list not only the number of the requirement(s), but also the text of the requirement from the Requirements column in the PCI DSS. While your QSA might have memorized the PCI DSS requirements, bankers and others that will read the CCW have typically not committed to that level of detail and it will help them with the context of the CCW.

The business justification needs to be more than just “we don’t want to” or “it was too hard”. Believe it or not, I have had a lot of organizations provide just such simplistic and silly reasons for justifying a CCW. Proper justifications can involve budgetary constraints, timing (e.g., not enough time to complete remediation by the end of the assessment period), application requirements (e.g., the application requires XP to run) and/or vendor requirements (e.g., the vendor requires a hardware upgrade to correct the issue). If you do have a target date for addressing the CCW, this is where you want to provide that information so that readers know that the CCW has some time limit.

The original objective is the easiest part of the CCW to develop. The Council has provided the “Guidance” column in the PCI DSS for each requirement and it is the verbiage in that Guidance column that you should use to explain the original objective of the requirement. If you are using the CCW for multiple requirements, this section can get rather lengthy and I would recommend identifying the Guidance information with its requirement to help understanding of the information.

The next section can sometimes be the toughest to develop and that is identification of any additional risks because you are using a CCW. In some cases, there may actually be no additional risk perceived by using a CCW. One such example is when organizations have a separate system management VLAN where network and system administrators can use telnet, SNMPv2 and other “unsecure” protocols in addition to SSH, RDP and other secure protocols to manage devices/systems. These system management VLANs typically require the use of an out of band (OOB) to gain access, administrator credentials different from the administrator’s user credentials and two factor authentication to name just a few of the controls you see in this example. These management/administrative VLANs are no more risky than using only secure protocols.

However, if you are compensating for having to keep Windows XP running, that will likely be a very different story and depending on the compensating controls put in place, the risk could be moderately higher than not have XP around. The key here is that it is that the risk should be assessed and then honestly discussed in the CCW. If you think you are going to say that having XP does not increase risk to your cardholder data environment (CDE), I would seriously think again regardless of your compensating controls in place because any outdated Windows implementation is a security problem waiting to happen regardless of how you think you have mitigated the risk.

The compensating controls section is where the rubber finally meets the road. It is here that you document each individual control that compensates for your organization’s inability to meet the requirement(s) in question. I recommend that people either bullet point or number list each individual control. The reason is that in the next two sections, you need to tie the validation and maintenance items to the controls in this section and doing some sort of list makes it easy for people to ensure they have covered all controls in each section.

The most common mistake made in this section is organizations state that they have a project to remediate the issue(s). Sorry, but this is NOT a control. It is nice information, but it is not a control that can be relied upon. QSAs never want to ever see such statements made about future projects ever in this section. This section is all about what you are doing from a controls perspective to manage the fact that you cannot meet the requirement(s).

Valid controls in this section must also go “above and beyond” what is required by the PCI DSS. Examples of “above and beyond” include:

  • Reviewing log data in real time for a particular condition that would indicate an out of compliance condition on a control. This is above and beyond because log data only needs to be reviewed daily for such conditions.
  • Using whitelisting to identify applications that do not belong on a PC and generating an alert in real time if such applications are found. Such technology is above and beyond because it is not currently required by the PCI DSS.
  • Using critical file monitoring to identify rogue applications that do not belong on a PC and generating alerts in real time if found. Critical file monitoring is a PCI requirement, but this goes above and beyond because monitoring is only required on a weekly basis.

The list here can go on and on, but hopefully I have given you some ideas of how to create compensating controls that can actually compensate for your inability to comply with the requirement(s).

One key point though is that you cannot use a requirement in the same requirement group to compensate for a different requirement in the same group. For example, requirement 6.4 has bunches of sub-requirements under it. You cannot write a compensating control for one sub-requirement in 6.4 and then use a different sub-requirement under 6.4 as one of your compensating controls regardless if it is above and beyond.

The next section will list how the controls were assessed by your QSA/ISA to prove they have been implemented. So using our previous bullet list, here is what the control validation bullets would look like.

  • Observed the system information event management (SIEM) solution and verified that alerts are generated in near real time for [control failure condition] and that the alert is followed up by the security analyst to determine if the alert is valid. If valid, the security analyst opens a service ticket and assigns that ticket to the appropriate area for further investigation.
  • Observed the [whitelisting solution name] and verified that if rogue applications are loaded on a workstation a near real time alert is generated back to the [whitelisting solution name] master console and that the alert is followed up by the security analyst to determine if the alert is valid. If valid, the security analyst opens a service ticket and assigns that ticket to the appropriate area for further investigation.
  • Observed the [critical file monitoring solution name] and verified that if rogue applications are loaded on a workstation a near real time alert is generated back to the [critical file monitoring solution name] master console and that the alert is followed up by the security analyst to determine if the alert is valid. If valid, the security analyst opens a service ticket and assigns that ticket to the appropriate area for further investigation.

Finally, you need to document what your organization will do to ensure that the controls remain implemented and effective. This is where most compensating controls fall apart. The organization gets through their assessment and then neglects to keep the compensating controls working. Using our list from the compensating controls section, the maintenance controls would look something like this.

  • [Organization name] reviews on a [weekly/monthly/quarterly] basis the SIEM and test that the alerts for the [control failure condition] are still functioning as designed.
  • [Organization name] reviews on a [weekly/monthly/quarterly] basis the [whitelisting solution name] and test that the alerts for rogue applications are still functioning as designed.
  • [Organization name] reviews on a [weekly/monthly/quarterly] basis the [critical file monitoring solution name] and test that the alerts for rogue applications are still functioning as designed.

A good idea in the maintenance section is to set timeframes for remediating any control testing failures.

One other important item of note about the controls, validation and maintenance lists. Notice that there are no “forward looking” statements made such as someone “will” perform or “will” review. CCWs must be shown to be in place and operating. A promise of implementing a control is NOT a control either. The control must be shown to be operating and maintained. That is an important point a lot of organization miss. It means that CCWs cannot be created at the last minute and then be operational past the filing of your SAQ or ROC. If you are going to have to use a CCW, that means you will need to identify the situation early and then get the compensating controls implemented, validated and through at least one maintenance cycle before it can be accepted.

CCWs can buy organizations time while they address issues that will take longer to address than their PCI assessment period. Unfortunately, there are organizations that see the CCW as a way to be judged PCI compliant without addressing their serious security shortcomings. It is not unusual for large organizations to have a number of CCWs particularly if they have legacy applications and hardware. However, I would highly recommend that all organizations only rely on CCWs if there are no other options to achieving PCI compliance.

21
Jul
15

An Update On Network and Dataflow Diagrams

A number of years ago, I wrote a post on how to diagram for your QSA. While my original post still has validity, there have been a few changes have occurred so I thought it was a good time to update everyone so that diagrams meet what your QSA needs for documentation.

One of the changes that came with v3 of the PCI DSS was with requirement 1.1.3 that now explicitly calls out that the data flow diagram be overlaid on the network diagram. The purpose of this was twofold. First, such an approach allows the organization being assessed to further refine their scope for their PCI assessment. Second, it allows the QSA an easier time to confirm that the scope of the PCI assessment is accurate.

Prior to v3, organizations had a tendency to deliver data flow diagrams that had no basis in reality as to how they were physically implemented. A lot of this was due to the fact that developers and networking types never communicated between one another. As a result, QSAs would hear comments such as, “All I know is it just works”, “You’ll have to ask the developers …” or “You’ll have to ask the networking people …”. This obviously resulted in a lot of discussions (i.e., arguments) over scope accuracy between QSAs and their clients. Under the new v3 requirements, hopefully all of those discussions will go a lot easier and faster.

Regardless of what requirement 1.1.3 states, QSAs are still encountering data flow diagrams that look more like cubist or surrealist paintings. This situation seems to be driven by the fact that a lot of organizations either do not want to or cannot get their developers and networking folks together to come up with a data flow diagram that can marry up to the network diagram. Let me tell you that going through this exercise greatly reduces the issues surrounding scope because scope becomes very clear once everyone can “see” how data flows through the network. However, it is not surprising when organizations come back and say they found the exercise too daunting. Lots of organizations operate in such a siloed structure, that: (1) it takes an act of God to get everyone necessary together for such a discussion, (2) everyone agrees on the flows and networks used and (3) somewhere there is a flow that no one knows about or knows how it works. All of this can be resolved, but it takes time and information to work out and can end up being incredibly tedious particularly in a complex environment.

Unfortunately, while the scope becomes much clearer once the dataflow is overlaid on the network, the scope also tends to end up much larger than anyone realized. That is because systems that were thought to not have any connectivity (Category 3) to the cardholder data environment (CDE) end up as connected systems that could impact or influence the security of the CDE (some form of Category 2). It is then that there is a “mad dash” to minimize the number of these systems that need connectivity, i.e., reduce scope. It is during these scope reduction efforts that we encounter twisted and contorted arguments regarding systems that are clearly in-scope, but the client does not want to be in-scope and will do anything and everything imaginable to remove them from scope. Some of these discussion become so tortured in their logic as to be laughable, e.g., “Can’t we just ignore them?” and my personal favorite, “If I paint these servers “blue” will they then be out of scope?”.

But to further confirm scope, v3 introduces us to a revised requirement 11.3 that went into effect on July 1, 2015. As part of that change, the penetration test methodology now requires that the penetration testing exercise prove that network segmentation is in place as documented and therefore further prove that the scope for PCI compliance is accurate. This basically requires the penetration tester to confirm that your network diagram overlaid with the dataflow in fact fully documents your organization’s scope for PCI compliance. Therefore, if your dataflow and network diagrams are junk, do not be surprised if your penetration tester and/or QSA come back and tell you that your scope is larger than you thought.

Behind the scenes, there has been a change made by the PCI SSC through their reviews of QSAs’ ROCs under their quality assurance program. The Council is concerned that the diagrams put in ROCs are not always legible to readers. While organizations provide the original diagrams, the Council wants diagrams in reports to be legible for the banks and processors when they review the reports. As a result, QSAs and ISAs have been informed that their ROCs need to break out or section large diagrams so that they are legible on standard paper (i.e., 8.5”x11” or A4). As a result, a lot of ROCs are exponentially increasing in size to accommodate the network and data flow diagrams that now require many additional pages to ensure that the diagrams are legible in the ROC.

This should bring us all back up to date on network and dataflow diagrams.

11
Jul
15

Get Over It, You Are A Service Provider

I get a lot of inquiries asking about these sorts of situations and thought I should clear this up before too many organizations get hurt. The scenario goes something like this.

“I outsource my eCommerce site to a third party. The third party’s Web site does a redirect to [pick your processor]. I asked the third party for their Attestation Of Compliance (AOC) and they are telling me they do not need to be PCI compliant because they are out of scope. This is because their servers do not process, store or transmit cardholder data (CHD).”

From the PCI DSS Glossary v3.1, the PCI SSC defines a ‘Service Provider’ as:

“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).”

So here we go again – organizations splitting legal hairs, this time on the meaning of “directly involved.” The discussion from the service providers seems to revolve around the fact that issuing a redirect to the actual payment processor puts them out of scope because they are not “directly involved.”

I hate to rain on your parade, but it is my job.

First, as an outsourcer, you are a service provider to your customers. You can split legal hairs all you want on the first part of the definition, but your organization definitely meets the second part of the definition that this “also includes companies that provide services that control or could impact the security of cardholder data.”

Oh, that is right, you do not believe that your service could “control or impact the security of cardholder data.” Really? Your Web site that issues the redirect does not “control” the security of cardholder data or your site that issues the redirect could not impact the security of cardholder data if that redirect is changed. Who is liable for those problems? Your merchant customers? Think again and think about how that will play out in the media.

Second. To add insult to injury, a lot of you service providers point to SAQ A to support your argument. Seriously? SAQ A at least requires your organization to comply with certain requirements in sections 9 and 12 which means your organization is in scope for PCI compliance. Talk about twisted logic. But you are a service provider, so you cannot use SAQ A because only SAQ D or a Report On Compliance (ROC) can be used by service providers.

But if the first two points do not convince you, let us talk about how the card brands and payment processors dole out responsibility and liability if a problem occurs. Do you really believe that you have no skin in this game? As the outsourcer, you have all the skin in the game. If any redirect is tampered with, it’s not your merchant customers that will be on the hook. Yes, they will likely be the first one’s taken to the woodshed, but when the truth comes out that it was all your organization’s fault, your customers and their processors will come after your organization. It was not the merchants that created the problem, it was your organization. Your organization will be the one held liable for the problem, not your merchant customers.

The bottom line here is that you are a service provider and you are in-scope for PCI compliance. Get over it. You go right ahead and try to get around PCI compliance with your warped logic. When it hits the fan, it will be your organization that will be held liable, not your customers.

For all you merchants that are using these sorts of service providers, you need to either: [1] badger them to give you an AOC, [2] assess them as part of your own PCI assessment, or [3] find a new service provider that can provide an AOC. The choice is yours.

02
Jul
15

Policies, Standards And Procedures

Nothing bothers me more than asking for an organization’s firewall policy (or any policy actually) and getting my own personal version of ‘War and Peace’. The document is a mix of policies, standards and procedures all in a vain attempt to get as many topics covered as possible in a single document. And then the writers of these tomes wonder why no one actually reads them and therefore they have little or no compliance.

As that as our backdrop, here is my take on how to properly write policies, standards and procedures.

POLICY

Webster’s dictionary defines a policy as:

“a high-level overall plan embracing the general goals and acceptable procedures”

The key phrase here is “high level” not details like I encounter in most policies I read.

At a minimum, a policy needs to cover the following topics.

  • Problem statement. This section defines the problem or issue that the policy addresses. This should be no more than two paragraphs and should be devoid of technical terms or legalese if at all possible. If you are taking more than two paragraphs, then you either need to figure out how to be more concise or maybe you are covering too much ground with just one policy. Do not be surprised when you write your problem statement that you figure out ways to consolidate topics or better define topics. For example, why write separate electronic mail, letter writing, facsimile and texting policies when they are all forms of business communications and then just write a communication policy.
  • A bullet point or numbered list of the objectives of the policy. Are you protecting the assets of the organization? Are you minimizing the potential for fraud? Are you informing employees of their rights? Document the objectives you are trying to achieve with this policy.
  • Policy statement. Define the organization’s position and solution(s) regarding the problem documented from the problem statement.
  • Define who is responsible for what. Explain the responsibilities of boards, committees, all personnel, corporate officers of the organization and anyone else that is affected by this policy such as contractors or temporary help.
  • Policy management information. This is a block of information such as the date of issue, the last date of review, board approval date and other information that might be required to prove that policies are updated and reviewed.

The Guru’s rule of thumb is that a policy should be no longer than two to three pages in length. Actually the shorter the policy the better. Anything longer than that and it is not a policy.

As an example, here is that Communication Policy.

Problem Statement:

The organization provides employees with a variety of communication capabilities. As with any form of communication, care must be taken to ensure that the organization is represented appropriately and intellectual property is appropriately protected.

Objectives:

  1. Ensure the appropriate use of organization assets.
  2. Ensure the protection of the organization’s intellectual property and sensitive information.
  3. Notify employees of their rights when using organization-provided communication systems.

Policy Statement:

The organization provides a variety of communication systems including, but not limited to, written, pager, telephone, cellular telephone, facsimile, voice mail, electronic mail and instant messenger systems. These communication systems are for employee use in conducting organization business. The personal privacy of these communication systems is not guaranteed by the organization, as the organization may, from time to time, find it necessary to monitor communication systems and traffic to protect its intellectual property, sensitive information and other critical assets.

As with any method of communication, employees are to conduct such communication in a dignified and business-like manner. Failure of an employee to communicate with other persons in a dignified and business-like manner will result in disciplinary action and possibly termination.

While the use of the communication systems are specifically for conducting the business of the organization, management recognizes that personal use of the communication systems will occur. Employees are to minimize personal usage of the organization’s communication systems. Should personal usage become a problem, the organization will take steps to restrict personal communication that include, but are not limited to, disciplinary action and technical measures to limit or restrict personal communication.

Responsibilities:

The Corporate Security Officer (CSO) is responsible for development, implementation, dissemination, and monitoring of appropriate communication policies, standards and procedures. The CSO is also responsible for the development and implementation of an internal training program to educate personnel on the communication policies, standards and procedures.

Employees, contractors and temporary personnel will be required to attend a policy training course as well as sign an acknowledgement statement that refers to the organization’s policies regarding the use of the organization’s communication systems at time of on-boarding and annually thereafter. Failure to sign this statement will be grounds for termination of employment/contract.

Information systems management is responsible for implementing, maintaining and monitoring appropriate methods for securing and monitoring automated communication systems.

Internal Audit is responsible for periodic audits of the organization’s automated communication systems capabilities to ensure compliance with the communication policies, standards and procedures.

The head of Human Resources is responsible for the management oversight of this policy.

There are a number of other policies, standards and procedures that support this simple policy. All of those support and facilitate this document. But hopefully this provides you an example of what a policy should look like.

STANDARD

To continue with definitions, Webster’s defines a standard as:

“something established by authority, custom, or general consent as a model”

The key word with this definition is “model”. Standards define for example how device names will be formed, how IP address ranges will be defined and where those addresses will be used, how to properly code in various programming environments, network architecture for where and how to use firewalls and other security devices and the obvious how devices will be configured.

It is allowable to put hyperlinks to Internet documents or other reference documents so that you do not have to constantly update those documents. Where I encounter this the most is with device configuration standards. An organization that for example has Cisco equipment can provide hyperlinks to the relevant Cisco configuration and security standards for the various versions of IOS or Nexus standards on Cisco’s Web site so that the organization can leverage Cisco’s documentation.

Standards can be long or short, but the key is that a standard needs to address the model you are trying to establish.

PROCEDURE

Webster’s defines a procedure as:

“a series of steps followed in a regular definite order”

A proper procedure is a checklist or a numbered list that tells anyone how to complete some process. Examples of procedures are:

  • Checklists for configuring a device that proves that the standard(s) involved were followed.
  • Daily operations checklists to document that all daily procedures were performed.
  • Monitoring procedures for ensuring that all devices are properly monitored.
  • Incident response procedures documenting how to respond correctly to particular alerts that could be an incident.

The key though with procedures is that they must be complete so that anyone can perform them. And when I say anyone, I mean anyone. If you have never been through procedure writing, the best example I can give you is to write down instructions for tying a pair of shoes and then give them to a co-worker and have them follow those instructions. You should find that it is not as easy as you might think and will take many revisions to get a set of working instructions.

When I was a CIO, the way I tested procedures was to perform them myself. What started this practice was an extended power outage one night and our UPS systems required us to shut down the data center. When the power came back on around 4AM, the night operator was not able to get the systems back up and running because he had no procedures to follow. As a result, when I got in at 6AM systems were still powered down and the day operator was waiting for some key people to get everything back up. I gave the IT staff three days to prepare start up and shut down procedures for all systems and then came in on a Sunday and tried them out myself. Needless to say, that Sunday did not go as well as people expected and a lot of updates and changes to those procedures were made. However, once those procedures were complete, I could have gotten the Chairman of the Board to restart the data center.

Hopefully this gives you the guidance you need to properly write policies, standards and procedures. I think you will find as I have that properly written, such documentation can be very useful in clearly communicating with everyone involved in your organization.




Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

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

September 2015
M T W T F S S
« Aug    
 123456
78910111213
14151617181920
21222324252627
282930  

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

Join 1,323 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,323 other followers