Posts Tagged ‘clarification

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.

01
Jun
15

Supplemental Validation Procedures Coming

In the April 2015 Assessor Newsletter (received just last week) from the PCI SSC was the following announcement.

Coming Soon – Supplemental Validation procedures for Designated Entities

The analysis of PCI DSS compliance trends as well as the recent data breaches involving cardholder data has revealed that many organizations continue to view PCI DSS compliance as a periodic exercise only, and fail to implement processes to ensure that their PCI DSS controls are continuously enforced. This approach has been shown to result in a lapse in security controls between validation assessments. Organizations must remember that security is an ongoing process that must be incorporated into an entity’s overall strategy and PCI DSS security controls must be maintained on a continual basis.

In response to these trends, the PCI SSC is planning to issue additional validation procedures that are designed to help organizations illustrate how they are maintaining PCI DSS security controls on an ongoing basis. These supplemental validation procedures are due to be published in the upcoming weeks, along with guidance for understanding how and to whom these procedures may apply. Stay tuned!

Could it be that business as usual (BAU) is coming before v4 of the PCI DSS is released?

Who are these “designated entities”?

As the newsletter says, “Stay Tuned!”

UPDATE: On Friday, June 5, the Council issued the ‘PCI DSS Designated Entities Supplemental Validation’ standard. It can be downloaded from the Council’s Web site.  The document gives the following as examples where these supplemental procedures apply as entities that: (1) store, process, and/or transmit large volumes of cardholder data, (2) provide aggregation points for cardholder data, (3) have suffered significant or repeated breaches of cardholder data, or (4) anyone the card brands determine should go through this process.

15
May
15

Whole Disk Encryption Explained

There are a lot of security professionals and lay people that seem to believe that encryption is encryption and that is simply not the case. Worse yet, vendors play into this misconception and obfuscate the issue with lots of words and phrases discussing seemingly complicated encryption key management procedures and the like that are actually meaningless when it comes to protecting data on running systems. As a result, it is time to clarify all of this misunderstanding.

First things first, we need to discuss how whole disk encryption works. As its name implies, whole disk encryption encrypts an entire disk drive. When a file on the whole disk encrypted drive is accessed, the encryption solution decrypts the file necessary using the decryption key provided at system startup and the rest of the drive remains encrypted. That way if a system failure occurs or the system is shutdown deliberately, the drive is always protected.

That is the key concept of whole disk encryption. The drive is technically only encrypted when the system is shutdown. If the system is running, the encryption is technically not in place because the operating system has the decryption key to access the disk at will. This is why whole disk encryption is great for devices like notebooks and the like that are shutdown at some point.

This is also why whole disk encryption is meaningless when applied to a server. When is a server shut down? Never. When using whole disk encryption on a running server, the only control that protects data is access controls, not encryption.

So using this definition, let us examine requirement 3.4.1 in the PCI DSS. That requirement states:

“If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.”

The first statement that throws people is “logical access must be managed separately and independently of native operating system authentication and access control mechanisms”. In short, whole disk encryption cannot rely only on the operating system’s authentication process.

The best example of this is Microsoft BitLocker. BitLocker has a number of modes under which it can operate. It can integrate with Active Directory (AD), it can rely on a trusted platform module (TPM) chip in the computer or it can operate stand-alone.

In stand-alone mode, BitLocker requires the user to provide the BitLocker key by either manually keying it in or providing it on a USB device that stores the BitLocker key in order to boot the system. If that key is not provided, the system will not even offer the user to logon. This form of BitLocker meets the requirements set forth in requirement 3.4.1.

But then the requirement goes on and say, “Decryption keys must not be associated with user accounts”.

In stand-alone mode, the BitLocker key is not associated with the user’s credentials so it also meets this part of 3.4.1.

However, in the AD or TPM modes, BitLocker operates behind the scenes and the end user never knows that their disk is encrypted and the user still logs onto the system as always using their Windows credentials. These modes do not meet the independence requirement in 3.4.1 because all that is protecting the data is the user’s Windows credentials. And in the case of AD mode, BitLocker also does not meet the user credential disassociation requirement because the BitLocker decryption key is tied to the user’s Windows credentials.

But if people would fully read the Guidance column for requirement 3.4.1 they would read the following at the end of the guidance for 3.4.1 where the Council states:

“Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”

BINGO!

Whole disk encryption helps protect data in the event of physical loss of a disk. Period.

So with a server that never shuts down, if a drive in a SAN or NAS fails, the failed disk with whole disk encryption will be encrypted when it is pulled from the array. But if things are running just fine, whole disk encryption does nothing to protect the data.

So do not be baffled by the statements from those vendors trying to convince you that whole disk encryption on your server is going to protect your data while the server is running. That is not true.

Now you know.

16
Apr
15

ASV Guidance For SSL/TLS Vulnerabilities

Hidden by all of the news about v3.1 of the PCI DSS being published, is a notice that was sent to all PCI approved scanning vendors (ASV) from the PCI SSC regarding how to handle SSL and “early TLS” vulnerabilities.

In regards to the “early TLS” comment, the Council did define the term by referencing everyone to NIST SP800-52 rev1. That NIST document essentially tells the reader that while TLS 1.1 is allowed, whenever possible, TLS 1.2 should be the only version used. In fact, NIST is highly recommending that all government entities move to TLS 1.2 by January 1, 2016.

FYI TLS 1.3 is in a draft specification by the IETF as we speak. I would expect that we will see TLS 1.3 released by the time the PCI SSC’s June 30, 2016 deadline.

With that covered, what is an ASV to do with a scanning customer’s SSL and TLS 1.0/1.1 issues?

According to the letter sent to the ASVs:

Prior to 30 June 2016: Entities that have not completed their migration should provide the ASV with documented confirmation that they have implemented a risk mitigation and migration plan and are working to complete their migration by the required date. Receipt of this confirmation should be documented by the ASV as an exception under “Exceptions, False Positives, or Compensating Controls” in the ASV Scan Report Executive Summary and the ASV may issue a result of “Pass” for that scan component or host, if the host meets all applicable scan requirements.”

The key here is that you must be mitigating the vulnerability and working to migrate to TLS 1.2.

So what would a mitigation plan look like? Most likely you would monitor for usage of SSL or TLS 1.0/1.1 connections to your devices that only support SSL and TLS 1.0/1.1.

For those of you that are not going to be able to migrate to TLS 1.2, the Council gives ASVs guidance there as well.

After 30 June 2016: Entities that have not completely migrated away from SSL/early TLS will need to follow the Addressing Vulnerabilities with Compensating Controls process to verify the affected system is not susceptible to the particular vulnerabilities. For example, where SSL/early TLS is present but is not being used as a security control (e.g. is not being used to protect confidentiality of the communication).”

The reason the Council has to be able to provide a solution past June 30, 2016 here is that it is my understanding that a lot of comments were received about “baked in” SSL that was going to require wholesale replacement of devices to correct the problem. A lot of those devices are IP-based point of interaction (POI) devices. ASVs have been instructed on the process to use to reduce the CVSS so that the vulnerability is no longer considered “high”.

If you have any further questions regarding this announcement, I would discuss it with your ASV. As with all things PCI, every ASV will have variations based on their own risk adversity as to what this pronouncement says.




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

July 2015
M T W T F S S
« Jun    
 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 1,292 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,292 other followers