Pau Lo
asked on
PCI DSS experts and monitoring compliance
Is there anything in PCI DSS that covers the following procedure. I assume its common for IT departments to determine a baseline security minimum standard for each system type/role. I.e. for laptop computers, I assume your security baseline would say laptop machines must have full disc encryption. But does PCI DSS (or any of these standards) recommend pro-active verifacation and monitoring that all your machines actually do have full disc encryption? If so could you point me in the direction of the section in PCI DSS that goes over this? I had a quick scan through but couldnt see to much in that area.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Dave Baldwin
One of the problems with portable things like laptops is that they can be stolen by people who have the keys to decode the data. The company or organization is still responsible for losing the data. And if the laptop is taken outside to unsecured places like the employee's home, that would be considered bad practice.
Keep pci data on the servers :) Keep LT's from accessing it, that's what we recommend. FDE is still a good practice for LT's nonetheless.
-rich
-rich
ASKER
But I was more looking at this as an example, and why all these standards seem to have a blind faith that whatever method you use to deploy (or build standards) disc encryption has worked and is enabled.
These standards never seem to have a requirement to monitor for compliance of your security standards, i.e. why doesnt it recommend a security admin to monitor that all of your laptops have encryption enabled? Surely things can go wrong that means unless you are monitoring the security compliance then you wouldnt have a clue about non compliant machines. Its just a set it and forget type mindset with these technical requirements, they completely overlook monitoring procedures for compliance.
So which control in PCI DSS has a requirement to proactively audit your machines to ensure they comply with security settings? As per most I suspect there isnt one.
These standards never seem to have a requirement to monitor for compliance of your security standards, i.e. why doesnt it recommend a security admin to monitor that all of your laptops have encryption enabled? Surely things can go wrong that means unless you are monitoring the security compliance then you wouldnt have a clue about non compliant machines. Its just a set it and forget type mindset with these technical requirements, they completely overlook monitoring procedures for compliance.
So which control in PCI DSS has a requirement to proactively audit your machines to ensure they comply with security settings? As per most I suspect there isnt one.
You really ought to read thru pci_dss_v2.pdf at least once. In that document, there are testing procedures listed beside each PCI DSS requirement. As for laptops, anything with cardholder data is supposed to be kept under lock and key and access restricted to only those who are authorized to access or use the data. That pretty means that laptops lose their usefulness since you can't take them anywhere.
You've found out what millions already know, it's a bunch of check-boxes and not much else. It's hard to make requirements beyond what PCI mandates in most organizations security takes a back seat and if they can get even close to PCI compliance they are 10 steps ahead of where they were before they read the DSS requirements.
Physical controls (section 9) are supposed to be in place for accessing PCI environments, but LT's are out of scope and not hinted at whatsoever.
Also FYI pci does recommend monitoring, and you get to fill in that portion with things you think you should monitor in addition to access, most people don't understand this sections additional intention.
As for the base-line security settings, PCI does not attempt to approach that subject, and rightly so. PCI is high level because they were kinda smart not to get into specific's. Creating baselines for Windows(|98|NT|2000|xp|200
It's not blind-faith because 9-10 times the FDE you choose will be very sufficient for keeping an attacker at bay should the LT be stolen. "Evil maid's" and cold-boot attacks are sexy and plausible in some cases, but not to a degree that it makes sense to force EVERYONE to have their security that "goes to 11". Security is always a trade-off, typically between ease of use, functionality and or -->budget<--. PCI can't mandate that PGP be used because it's not free and in fact costs lot's of money, it also would put PGP in a monopoly position, when TrueCrypt, FreeOTFE, CheckPoint, Seagate Momentus, Dell, DestCrypt, BitLocker, ScramDisk and so many others can do the job.
They leave it general because frankly that's the best way. There are too many variables to get technical.
Also as you seem to know already, some of these controls are paper-tigers if no one is monitoring them, and even if they are, some are for naught in many instances. There is a requirement for VPN users to have 2-factor authentication to make a connection to the PCI environment. 2-Factor only works at the initial VPN connection, once that is established, if a machine is compromised, the network layer can be used to gain access to the lan and the 2-factor part is never needed (\\ip.ip.ip.ip can't be 2-facotr'd in windows).
While PCI is far from perfect, and can be a pain (like most security), at a high-level it is a decent building block for a secure environment. Please note that even if you fail a PCI audit, you can still go about you're day to day until next year, they really don't do anything to anyone when they fail, I've audited many organizations, what the self-assessment questionnaire says and what you actually find are typically not even close to correct. So if anything PCI needs more enforcement by sanctions and fines, which I've personally never seen it do. Needs more "teeth" in that side of things than anywhere else in my opinion.
-rich
Physical controls (section 9) are supposed to be in place for accessing PCI environments, but LT's are out of scope and not hinted at whatsoever.
Also FYI pci does recommend monitoring, and you get to fill in that portion with things you think you should monitor in addition to access, most people don't understand this sections additional intention.
Regularly Monitor and Test NetworksThey expect you to audit your FDE, but aren't clear about that true enough.
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis
As for the base-line security settings, PCI does not attempt to approach that subject, and rightly so. PCI is high level because they were kinda smart not to get into specific's. Creating baselines for Windows(|98|NT|2000|xp|200
It's not blind-faith because 9-10 times the FDE you choose will be very sufficient for keeping an attacker at bay should the LT be stolen. "Evil maid's" and cold-boot attacks are sexy and plausible in some cases, but not to a degree that it makes sense to force EVERYONE to have their security that "goes to 11". Security is always a trade-off, typically between ease of use, functionality and or -->budget<--. PCI can't mandate that PGP be used because it's not free and in fact costs lot's of money, it also would put PGP in a monopoly position, when TrueCrypt, FreeOTFE, CheckPoint, Seagate Momentus, Dell, DestCrypt, BitLocker, ScramDisk and so many others can do the job.
They leave it general because frankly that's the best way. There are too many variables to get technical.
Also as you seem to know already, some of these controls are paper-tigers if no one is monitoring them, and even if they are, some are for naught in many instances. There is a requirement for VPN users to have 2-factor authentication to make a connection to the PCI environment. 2-Factor only works at the initial VPN connection, once that is established, if a machine is compromised, the network layer can be used to gain access to the lan and the 2-factor part is never needed (\\ip.ip.ip.ip can't be 2-facotr'd in windows).
While PCI is far from perfect, and can be a pain (like most security), at a high-level it is a decent building block for a secure environment. Please note that even if you fail a PCI audit, you can still go about you're day to day until next year, they really don't do anything to anyone when they fail, I've audited many organizations, what the self-assessment questionnaire says and what you actually find are typically not even close to correct. So if anything PCI needs more enforcement by sanctions and fines, which I've personally never seen it do. Needs more "teeth" in that side of things than anywhere else in my opinion.
-rich
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysisASKER
@DaveBaldwin - there are testing procedures, but are those intended for internal security officers to "self assess", or for external officers auditing compliance?
actually in all security compliance set, monitroring need not be explicit. when the time comes for compliance check, audit or pentest etc, the sad truth is most of the time gaps and non-compliance are surfaced. either you discover it earlier through constant checks and sensor else leave it to fate which most see security as after thought...Also being compliance does not mean it is secure system or architecture - minimally you meet some baseline and best practice and not "naked" to malicious acts...
"Regularly test security systems and processes "
E.g. PCI DSS compliance specifies that changes to existing data in log files must be detected, whereas the addition of new data can be ignored. For other files, such as critical configuration files, any change may be important. That said, you need then some form of Continuous File Integrity Monitoring then...
The whole idea for PCI is to reduce your scope and exposure for cardholder data. We dont really liken burning midnight oil for "exam" coming - last min rush is never in favour and always a hassle or even be successful in passing the checks. Increasingly, organisations are so focused on achieving compliance that they often miss the bigger, more important picture of ensuring consistent corporate data security through effective risk management. Achieving reliable and continuous information security needs to be based on real risk management and not sporadic compliancy metrics.
"Regularly test security systems and processes "
E.g. PCI DSS compliance specifies that changes to existing data in log files must be detected, whereas the addition of new data can be ignored. For other files, such as critical configuration files, any change may be important. That said, you need then some form of Continuous File Integrity Monitoring then...
The whole idea for PCI is to reduce your scope and exposure for cardholder data. We dont really liken burning midnight oil for "exam" coming - last min rush is never in favour and always a hassle or even be successful in passing the checks. Increasingly, organisations are so focused on achieving compliance that they often miss the bigger, more important picture of ensuring consistent corporate data security through effective risk management. Achieving reliable and continuous information security needs to be based on real risk management and not sporadic compliancy metrics.
I don't see a distinction as to who performs the testing. The testing procedures are clearly written down and if your 'internal security officers' ignore them, 'external officers auditing compliance' will not. They don't tell you who needs to do things. They do tell you what needs to be done and expect that you will take care of it.
If you had a serious breach and you were audited and they found that you hadn't performed due diligence in your monitoring and testing procedures, then you could have serious trouble in court if you were sued.
It's not unlike going 50 mph in a 40 mph zone. It probably doesn't matter until you hit someone. Then they will use it against you in court and add additional penalties for driving too fast.
If you had a serious breach and you were audited and they found that you hadn't performed due diligence in your monitoring and testing procedures, then you could have serious trouble in court if you were sued.
It's not unlike going 50 mph in a 40 mph zone. It probably doesn't matter until you hit someone. Then they will use it against you in court and add additional penalties for driving too fast.
Check the PCI councils website for approved QSA's (qualified security assessor's)
https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php
In the US there are about 141, so the PCI council does say use one of them, it doesn't say which. PCI again can't tell you HOW to test, only what to test FOR. Each solution is unique so it's hard to do more than generalize what to test for.
PCI is anything but clear, there are no clear testing procedures, and there can't be, but there are guidelines and measurements to abide by.
Sections 11-12 are very broad, but they expect documentation to be produced to your QSA.
-rich
https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php
In the US there are about 141, so the PCI council does say use one of them, it doesn't say which. PCI again can't tell you HOW to test, only what to test FOR. Each solution is unique so it's hard to do more than generalize what to test for.
PCI is anything but clear, there are no clear testing procedures, and there can't be, but there are guidelines and measurements to abide by.
Sections 11-12 are very broad, but they expect documentation to be produced to your QSA.
-rich
thought key is to priortise and set the goals. pci has a doc on this to assist if needed...below are the goals
@ https://www.pcisecuritystandards.org/documents/Prioritized_Approach_for_PCI_DSS_v20.xls
1 Remove sensitive authentication data and limit data retention. This milestone targets a key area of risk for entities that have been compromised. Remember – if sensitive authentication data and other cardholder data are not stored, the effects of a compromise will be greatly reduced. If you don't need it, don't store it
2 Protect the perimeter, internal, and wireless networks. This milestone targets controls for points of access to most compromises – the network or a wireless access point.
3 Secure payment card applications. This milestone targets controls for applications, application processes, and application servers. Weaknesses in these areas offer easy prey for compromising systems and obtaining access to cardholder data.
4 Monitor and control access to your systems. Controls for this milestone allow you to detect the who, what, when, and how concerning who is accessing your network and cardholder data environment.
5 Protect stored cardholder data. For those organizations that have analyzed their business processes and determined that they must store Primary Account Numbers, Milestone Five targets key protection mechanisms for that stored data.
6 Finalize remaining compliance efforts, and ensure all controls are in place. The intent of Milestone Six is to complete PCI DSS requirements, and to finalize all remaining related policies, procedures, and processes needed to protect the cardholder data environment.
Also from - http://www.theukcardsassociation.org.uk/security/PCIDSS_checklist.asp
*These actions need to be done EVERY year. If you don’t continue to do this, you will not maintain on-going compliance. Scans have to be undertaken on a quarterly basis.
@ https://www.pcisecuritystandards.org/documents/Prioritized_Approach_for_PCI_DSS_v20.xls
1 Remove sensitive authentication data and limit data retention. This milestone targets a key area of risk for entities that have been compromised. Remember – if sensitive authentication data and other cardholder data are not stored, the effects of a compromise will be greatly reduced. If you don't need it, don't store it
2 Protect the perimeter, internal, and wireless networks. This milestone targets controls for points of access to most compromises – the network or a wireless access point.
3 Secure payment card applications. This milestone targets controls for applications, application processes, and application servers. Weaknesses in these areas offer easy prey for compromising systems and obtaining access to cardholder data.
4 Monitor and control access to your systems. Controls for this milestone allow you to detect the who, what, when, and how concerning who is accessing your network and cardholder data environment.
5 Protect stored cardholder data. For those organizations that have analyzed their business processes and determined that they must store Primary Account Numbers, Milestone Five targets key protection mechanisms for that stored data.
6 Finalize remaining compliance efforts, and ensure all controls are in place. The intent of Milestone Six is to complete PCI DSS requirements, and to finalize all remaining related policies, procedures, and processes needed to protect the cardholder data environment.
Also from - http://www.theukcardsassociation.org.uk/security/PCIDSS_checklist.asp
*These actions need to be done EVERY year. If you don’t continue to do this, you will not maintain on-going compliance. Scans have to be undertaken on a quarterly basis.