Compliance obligations need not stand in the way of better information security and risk management
I couldn’t help write this post when I noticed this press release based on an IDC Insights Survey of Oil & Gas Companies. I don’t have access to the full report so I am basing my comments solely on the contents of the press release.
I found the following two findings (copied from the press release) to be of interest :
- Security investments are not compliance driven. Only 10% of the respondents indicated that they are using regulatory compliance as a requirement to justify budgets.
- Tough regulatory compliance and threat sophistication are the biggest barriers. Almost 25% of respondents indicated regulatory environment as a barrier to ensuring security. In addition, 20% of respondents acknowledged the increasing threat landscape.
The good news here is that only 10% of the respondents used Regulatory Compliance needs to justify budgets. What that tells me (I hope it is the case) is that the remaining 90% make budgetary decisions based solely on the information security risks that their businesses face and not on the risks of not complying with regulations or audits. I would commend them for it… and I don’t think any good auditor (regulatory or internal/external) would have a problem with it either if the organization was able to “demonstrate” that the risk of not complying with a particular regulatory requirement was very low. Agreed.. you still need to be able to “demonstrate” which isn’t easy if one hasn’t been diligent with risk assessments.
The not-so-good news to me is the 25% number (I realize it might be low enough for some people).. that of folks indicating that regulatory compliance is a barrier to ensuring security. For those folks, I say “It really doesn’t need to be a barrier”, not if you have good information risk management governance and processes. I don’t know a single regulation that would force you to implement specific controls no matter what. Even if you are faced with an all-or-nothing regulation like PCI DSS, you can resort to using compensating controls (see here and here for some coverage of PCI DSS Compensating controls) to comply with a specific mandatory requirement. To repeat my argument in the previous paragraph, an auditor would be hard-pressed to fault you if you were able to clearly articulate that you went about the compliance program methodically by performing a risk assessment and prioritizing (by risk level) the need for specific controls required by the regulation. If you did that, you would focus on ”ensuring security” and not ignoring it for the sake of compliance.
Categories: Information Risk, PCI DSS Compliance, Regulatory Compliance, Risk Assessment, Security Tags: Assessment, Compliance, PCI DSS, Risk, Security
May we suggest some priority adjustments to your PCI DSS Compliance program?
It isn’t any news that achieving PCI DSS Compliance continues to be onerous for many merchants out there. PCI DSS is after all an all-or-nothing regulation meaning that not passing even one of over 200 requirements could prevent you from getting there. And then, if you do become compliant, there is really no assurance that you will have 100% security. This is something we have known all along to be true for any regulation and now we have one more statistic from the 2010 Verizon Data Breach Investigation Report to prove it … 21% of organizations facing payment card data breaches were compliant with PCI DSS at the time of the breach.
So, may be it is time to rethink our approach to PCI DSS compliance, in terms of how do we get there by way of addressing controls that carry higher breach risks before the others. That will at least help improve your organization’s security posture against potential breaches even if you are nowhere close to meeting all PCI DSS requirements. I think recent breach surveys or reports are a great source to identify such controls with an objective of prioritizing the remediation initiatives in the right order. Such prioritization should help in achieving a better security posture sooner, as we’ll see below.
I am not the first one to suggest a prioritized approach to achieving PCI DSS compliance. In fact, PCI SSC already has guidance on this, though the guidance itself is somewhat dated having been issued back in February 2009. Since then, the threat environment has probably evolved somewhat and exploitation of certain vulnerabilities isn’t quite of the same order relative to others. Therefore, I suggest leveraging the data breach findings to make necessary prioritization adjustments.
Here are some findings from three recent reports on which I am basing my recommendations:
|
#
|
Report
|
Findings
|
Relevant Controls (Our Analysis)
|
|
1 |
Verizon Data Breach Investigations Report 2010 |
· 61% of the breaches were discovered by a third party · 86% of victims had evidence of the breach in their log files |
· Technology – Monitoring, correlation, reporting and alerting off the log events · Process – Regular reviews of logs, log reports or alerts · People – Clear definition and assignment of responsibilities around log reviews and incident response |
|
2 |
Verizon Data Breach Investigations Report 2010 |
· 94% of breached records had malware as one of the causes and 96% of breached records involved hacking · 51% of malware was installed or injected remotely by the attacker (by obtaining privileged access to the system or other means such as SQL Injection) · 85% of records breached by malware involved the attacker gaining backdoor access to the system · 81% of records breached by malware involved data being sent to an external entity or site · 86% of records breached by hacking involved use of stolen login credentials · 86% of records breached by hacking involved use of stolen login credentials · 89% of records breached by hacking involved SQL Injection · 92% of records breached by hacking used web applications as the attack pathway |
· Technology – Proper configuration and lockdown of systems, strong access credentials, access controls or assurance, assessment of web applications and remediation for OWASP Top 10 vulnerabilities, deployment of Web Application Firewalls, Logging/Monitoring/Reporting/Alerting of important events on critical systems · Process – Configuration reviews, OWASP Top 10 vulnerability management, access assurance in the form of ongoing role/privilege management processes and periodic access certifications, regular reviews of logs, log reports or alerts, effective security incident response · People – Clear definition and assignment of responsibilities around configuration reviews, access certifications, log reviews and incident response
|
|
3 |
Verizon Data Breach Investigations Report 2010 |
· More than 50% of breaches remain undiscovered for months or more · 61% of the breaches were discovered by 3rd parties, and not the victim organization itself
|
· Technology – Monitoring, correlation, reporting and alerting off the log events · Process – regular reviews of logs, log reports or alerts · People – Clear definition and assignment of responsibilities around log reviews and incident response, User awareness and training |
|
4 |
Verizon Data Breach Investigations Report 2010 |
· Few breaches were caused due to exploitation of vulnerabilities for which a patch was available. · Likelihood of exploitation of an unpatched vulnerability is far less as compared to a vulnerability caused by a configuration issue. |
Lockdown (secure configuration) of systems may receive higher priority over application of vendor patches unless there is a specific reason not to do so |
|
5 |
Leaking Vault – Five years of data breaches – July 2010 |
· Drives/Media and hacking were the top two breach vectors · Documents and Fraud (Social Engineering) have been increasing in prominence as threat breach vectors recently · Of the breaches that involved hacking, SQL Injection, stolen credentials and malware accounted for most breaches |
· Technology – Disk/Tape encryption, appropriate system lockdown to prevent use of media such as USB drives , Encryption of unstructured data (documents), Refer to controls in #2 against hacking · Process – Physical Security, Encryption and Key Management · People – Awareness and Training |
|
6 |
Ponemon Institute – Annual Cost of Cybercrime study – July 2010 |
· The most costly cyber crimes are those caused by web attacks, malicious code and malicious insiders, which account for more than 90 percent of all cyber crime costs per organization on an annual basis. · The average number of days to resolve a cyber attack was 14 days with an average cost to the organization of $17,696 per day. The survey revealed that malicious insider attacks can take up to 42 days or more to resolve. |
Refer to #2 above |
Here then is a summary of the key controls in the above table, relevant PCI DSS requirements and priorities from the PCI SSC Guidance.
|
Key Control (Our Analysis) |
Relevant PCI DSS Requirement Numbers (See Notes below) |
|
Secure Configuration and Lockdown |
1.1.5 (2), 1.2 (2), 2.1 (2), 2.2.3 (3), 2.2.4 (3), 2.3 (2) |
|
Web Application Security |
6.5 (3) |
|
Strong Access Credentials including periodic changes in credentials (e.g. password) |
8 (4) |
|
Access Assurance (Least Privilege access based on users’ business or job roles, timely revocation of access privileges) |
7 (4), 12.2(6), 12.5.4(6), 12.5.5(6) |
|
Logging, Monitoring and Reporting |
10.1(4), 10.2(4), 10.3(4), 10.4(4), 10.5(4), 10.5(6), 10.7(4), 12.2(6), 12.5.2(6), |
|
Encryption (Data at rest, media), Physical security of media |
3.3(5), 3.4(5), 3.5(5), 9.5(5), 9.6(5), 9.7(5), 9.8(5), 9.9(5) |
|
Security Incident Response |
12.5.3(6), 12.9(6) |
|
Security Awareness and Training |
12.3(6), 12.3.10(6), 12.4(6), 12.6(6) |
Note: Numbers in brackets are the priority numbers from the PCI SSC guidance. Numbers in the guidance range from 1 through 6. A lower number indicates a higher priority.
As we can see from the table, there are several requirements which if addressed sooner, will actually improve an organization’s security posture against potential breaches, based on what we know from the recent breach studies. I would recommend increasing the priority of the requirements in red to at least 3 if not 2. I do realize that organizations may not be able to afford to address too many requirements at a higher priority. If that is the case, you may want to review the current priority 2 and 3 requirements against the key controls in the table above and then decide to push some of them lower down the priority order as applicable.
Hope this is useful! As always, we welcome your thoughts and comments.
RisknCompliance Services Note
We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in providing our clients with a much-wanted third-party assessment of their risk management or audit methodologies and programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and knowledgebase.
Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we could be of assistance to you.
Categories: Information Risk, PCI DSS Compliance, Regulatory Compliance, Security Tags: Breach, Compliance, PCI DSS, Risk, Security
Logging for Effective SIEM and PCI DSS Compliance …. UNIX, Network Devices and Databases
In one of my previous blogs, I covered the importance of logging the “right” events for an effective Log Management or Security Information and Event Management (SIEM) deployment … see here or here for a discussion on the two technologies. The blog also provided a suggested listing of the Windows or Active Directory events that you might want to log from a PCI DSS Compliance standpoint.
Clearly, no amount of investment in your Log Management or SIEM solution is going to do much good, unless you have been able to generate all the right logs to begin with … see a related discussion with the recognized PCI Expert and Author, Dr. Anton Chuvakin here.
I would like to extend my suggested list in the previous post to cover a few other systems here, specifically UNIX/LINUX, Network Devices and Databases. Note that this list is only a starting point so you can work with the respective System Specialists or Administrators in your organization to generate these events.
UNIX/LINUX Logging for Effective SIEM and PCI DSS Compliance
Logging of Network Devices for Effective SIEM and PCI DSS Compliance
-
Database Logging for Effective SIEM and PCI DSS Compliance
Categories: HIPAA/HITECH Compliance, PCI DSS Compliance, Regulatory Compliance, Security, SIEM Tags: Compliance, HIPAA, HITECH, Logging, PCI DSS, SIEM
PCI DSS – Quick and Dirty?
I recently received a tweet titled “PCI DSS Compliance – Quick and Dirty”. I think it is safe to say that such a title is bound to grab immediate attention of anyone that has been associated with PCI DSS in one form or another. I immediately clicked the link on the tweet which took me to this page.
Not sure what the tweet’s originator meant to convey… Neither am I sure there is anyone that knows or has a quick and dirty approach to PCI DSS Compliance. Not unless perhaps, yours is a highly mature Security and Data Protection program…. I mean really high, perhaps the 90th percentile or higher. PCI DSS being perhaps the most prescriptive security standard out there, the reality is that most organizations will have a fair bit of work to do before they can claim compliance.
The link on the tweet points to the “Prioritized Approach for PCI DSS”. The document was put out by PCI SSC to assist merchants and Service Providers in undertaking a prioritized remediation effort when they may have gaps in a large number of control requirements. As the document says, the prioritized approach was developed based on extensive feedback from assessments, breaches and investigations, among other things.
Quoting from the document itself… “It is not intended as a substitute, short cut or stop-gap approach to PCI DSS compliance”.
And then, there is this quote … “To achieve PCI DSS compliance, an organization must meet all PCI DSS requirements, regardless of the order in which they are satisfied or whether the organization seeking compliance follows the PCI DSS Prioritized Approach”.
That said, as a security practitioner, I really wish there will come a day when compliance with a standard like PCI DSS can be quick and dirty for most organizations.
Categories: PCI DSS Compliance, Regulatory Compliance, Security Tags: Compliance, PCI DSS, Risk, Security
New details released regarding Internal Security Assessor (ISA) program for PCI DSS
PCI SSC has just released new details regarding the training schedule for the ISA program. The program is obviously PCI SSC’s response to the often heard complaints from merchants and service providers about high costs involved with maintaining PCI DSS compliance. Be sure to read the program validation requirements as well as the FAQs.
Key requirements to note are:
- ISAs have to be on full –time employment with the sponsor companies. Specifically , ISAs will not retain the certification upon termination of employment and so can’t carry the certification to a new employer.
- ISAs need to be recertified annually. The recertification process includes ISA Program training and passing the examination every year.
- ISAs have to be part of a dedicated Internal Audit department.
Important to note is the scope/objective of the ISA program which reads as “to improve the organization’s understanding of the PCI DSS, facilitate the organization’s interactions with QSAs, enhance the quality, reliability, and consistency of the organization’s internal PCI DSS self-assessments, and support the consistent and proper application of PCI DSS measures and controls”. It also says that the “ISA qualification does not entitle an ISA to perform special functions or conduct QSA Assessments".
Here is another interesting blog post on this topic.
Categories: PCI DSS Compliance, Regulatory Compliance Tags: Compliance, PCI DSS
Logging for PCI DSS Compliance
PCI DSS has had specific requirements for logging and review of those logs for sometime now. The logging requirements (under Requirement 10 ) have a primary objective of supporting forensics in the event of a breach of cardholder data. I believe it is fair to say that PCI DSS has played a large role in bringing into limelight the topic of Log Management, in effect creating an assured market for several vendors who are vying for a piece of the PCI business out there.
While most Log Management vendor solutions are featured enough and support quick deployments (normally a selling point one hears from most vendors), I believe it is important for PCI merchants and service providers to take that with a grain of salt. Granted that most vendor solutions have features for effective log parsing, normalization, reporting, alerting etc… As I am sure anyone that has worked on PCI DSS (or for that matter any Log Management or SIEM deployments) would attest, an effective deployment requires deliberate planning and ground work. And in my view, the most critical step for an effective Log Management solution (and most certainly those focused on PCI DSS Compliance) is the very first step, which is Log Generation (see NIST 800-92 Guide to Computer Security Log Management to learn more about Log Management processes). After all, you can get to managing and analyzing logs only if you generate them and more importantly from a PCI DSS standpoint, generate all the right logs!
To illustrate the point, below is a partial suggested list of events you might want to log on Windows and Active Directory. One really can’t overemphasize the need for various system administrators to work closely with the PCI readiness teams to make this happen. I have also included sample mappings to PCI DSS requirements, the likes of which you can use to demonstrate due diligence to your QSA.
Hope you find this information useful and I welcome your comments!
|
# |
Event Description |
Windows Event Id#
- Vista or Windows Server 2008 |
PCI DSS Requirements |
||
|
Logon events |
|||||
|
1 |
Successful Logon – Privileged users only |
4624 |
6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2 |
||
|
2 |
Logoffs – Privileged users only |
4634 |
6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2 |
||
|
3 |
Failed Logon attempts – All users |
4625 |
6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2 |
||
|
4 |
Account Lockouts – All users |
4740 |
8.5.13, 10.2.4 |
||
|
5 |
Account Lockout Release – All users |
4767 |
8.5.13, 10.2.2, 10.2.4 |
||
|
6 |
Privilege escalation through “Run as” |
? |
10.1, 10.2.1, 10.2.2 |
||
|
|
Object access events |
||||
|
7 |
All access to folders containing Cardholder Data |
5143 |
10.2.1 |
||
|
8 |
Changes to access privileges on folders containing Cardholder Data |
4670 |
10.2.1,10.2.2 |
||
|
9 |
Changes to ownership on folders containing Cardholder Data (“Take Ownership”) |
4670 |
10.2.1,10.2.2 |
||
|
10 |
All access to files containing Cardholder Data |
4663,? |
10.2.1 |
||
|
11 |
Changes to access privileges on files containing Cardholder Data |
4670 |
10.2.1 |
||
|
12 |
Changes to ownership on files containing Cardholder Data (“Take Ownership”) |
4670 |
10.2.1,10.2.2 |
||
|
13 |
Creation or deletion of files in folders containing Cardholder Data |
4660, 4663 (Delete)
|
10.2.1 |
||
|
14 |
Access to (Read, Modify or Delete) Security Event Logs by anyone other than the Windows system or the account used for log collection by the Log Management Solution |
? |
10.2.2, 10.2.3, 10.2.6, 10.2.7, 10.5 |
||
|
15 |
Changes to %SYSTEMROOT%\SYSTEM32 folder contents (System Level Object) |
5143 |
10.2.7 |
||
|
16 |
A registry value was modified (System Level Object) |
4657 |
10.2.7 |
||
|
|
Account Management |
||||
|
17 |
User Account Created |
4720 |
7.1.4, 8.1, 8.5.1,10.2.2 |
||
|
18 |
User Account Enabled |
4722 |
7.1.4, 8.1, 8.5.1, 8.5.6,10.2.2 |
||
|
19 |
Password Change/Reset Attempted |
47239(Change), 4724(Reset) |
8.5.3, 8.5.9 |
||
|
20 |
Account Password Set |
4738(?) |
8.5.3, 8.5.9 |
||
|
21 |
User Account Disabled |
4725 |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
22 |
User Account Deleted |
4726 |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
23 |
User Account Changed |
4738 |
6.3.3, 7.1.4, 8.1, 8.5.1,10.2.2 |
||
|
24 |
Security Group Created |
4727 (Global Group) 4731 (Local Group) |
6.3.3, 7.1.1, 7.1.4,10.2.2 |
||
|
25 |
Security Group Member Added |
4728(Global Group) 4732(Local Group) |
6.3.3, 7.1.2,10.2.2 |
||
|
26 |
Security Group Member Removed |
4729(Global Group) 4733(Local Group) |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
27 |
Security Group Deleted |
4730(Global Group) 4734(Local Group) |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
|
Directory Service access events |
||||
|
28 |
Creation of new group policies |
? |
10.2.2, 10.2.7 |
||
|
29 |
Changes to group (Active directory) or server policies |
? |
10.2.2, 10.2.7 |
||
|
30 |
Application of group policies to a container |
6144(?) |
10.2.2, 10.2.7 |
||
|
|
Privilege use events |
||||
|
|
Privilege use (Failure only) for the following user groups:
|
||||
|
31 |
Server or Domain Administrators |
4674(?) |
10.2.2 |
||
|
32 |
Account Operators |
4674(?) |
10.2.2 |
||
|
33 |
Accounts (User, service or process) with access to Cardholder Data |
4674(?) |
10.2.2 |
||
|
|
System events |
||||
|
34 |
Windows – Starting up |
4608 |
10.2.2 |
||
|
35 |
Windows – Shutting down |
4609 |
10.2.2 |
||
|
36 |
An authentication package was loaded by the Local Security Authority. |
4610 |
10.2.5 |
||
|
37 |
A trusted logon process has registered with the Local Security Authority. |
4611 |
10.2.5 |
||
|
38 |
Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages. |
4612 |
10.2.3, 10.2.6, 10.2.7, 10.5 |
||
|
39 |
A notification package was loaded by the Security Accounts Manager |
4614 |
10.2.5 |
||
|
40 |
Server time out of synchronization with Domain Controller |
4616(?) |
10.4 |
||
|
|
Windows updates |
||||
|
41 |
Windows Software Update Services – Successes and Failures |
? |
6.1 |
||
Categories: PCI DSS Compliance, Regulatory Compliance Tags: Compliance, Logging, PCI DSS
PCI DSS update related to digital audio recordings containing cardholder data
PCI SSC released another update yesterday related to digital audio recordings. The update provides further clarification (to the update on January 22) on the storage of sensitive data in digital audio recordings after authorizing transactions.
As always, RisknCompliance recommends that organizations look at options to avoid storing CVV or like codes in their call center recordings after authorizing transactions. If the data is stored, they would be faced with the extra burden associated with compensatory controls (documentation, demonstrating effectiveness etc.)
(PCI SSC FAQ updates reproduced below)
————————————————————————————————————
PCI SSC FAQ – 5362 dated February 18, 2010
Question: Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of PCI DSS?
This response is intended to provide clarification for call centers that record cardholder data in audio recordings, and applies only to the storage of card validation codes and values (referred to as CAV2, CVC2, CVV2 or CID codes by the payment brands).
It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.
It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.
Where technology exists to prevent recording of these data elements, such technology should be enabled.
If these recordings cannot be data mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call recording formats.
This requirement does not supersede local or regional laws that may govern the retention of audio recordings.
————————————————————————————————————
PCI SSC FAQ – 5362 dated January 22, 2010
“It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.
It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.
On an exception basis, storage of CAV2, CVC2, CVV2 or CID codes in an analog format after authorization is allowed; as these recordings cannot be data mined easily. However the physical and logical protections defined in PCI DSS must still be applied to these analog call recording formats.
Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors. All other recordings containing cardholder data captured by call centers must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4.”
Categories: PCI DSS Compliance Tags: Call Centers, Compliance, PCI DSS