2011 featured plenty of news about high-profile data loss and cybercriminal activity. And so did 2012. Any guesses for 2013?
Some common causes emerge in all of these cases. Poorly managed infrastructure, insecure web applications, and a lack of attention to security procedures are often cited.
But how do these conditions arise? How is it possible that otherwise capable and competent organisations fare so badly?
Our work with clients around the World gives us a privileged insight in to the security infrastructure of numerous organisations, from the largest to the smallest, and from the simplest the most complex. In all cases where data loss or compromise has taken place, common themes emerge.
Here then, are 7 significant warning signals to look out for. Why not score yourself?
- Management belief that it’s getting harder to defend your data, and the bad guys will get in anyway if they want to. This unfortunate attitude is especially dangerous if it comes from the top of the organisation. It indicates a lack of understanding of security issues as well as a disregard for the information assets of the company.
- Internal memos stating that “security is everyone’s responsibility”. Organisations should adopt internal programmes to raise security awareness but this is a different kind of message. It says “Security is nobody’s specific responsibility”. It makes about as much sense as a team where everyone is the manager.
- There is no IT executive who can articulate the relationship between the terms “regulatory compliance” and “corporate information security”. If an exec is confused by the difference between an audit standard and the protection of valuable data assets of the Company, then the organisation is already at a disadvantage.
- A security team who are so difficult to work with that the business simply ignores them. It is an unfortunate fact that there sometimes exists an “us and them” attitude; and it can emanate from the infosec team. Security has to support the business, rather than be tolerated by it.
- A compliance project that only extends to achieving compliance rather than maintaining it. PCI compliance, for example, is re-validated once per year. But PCI DSS requires that a compliant state is maintained at all times, not just on the day of the assessment.
- Blind faith in security products. Security products are a useful and often essential part of a secure infrastructure. But it’s vital that organisations have the skills to configure, operate and react to the events that such products detect and disclose. Otherwise, they are a waste of time and money, or worse, a source of false or incomplete information.
- The use, in any compliance or security discussion, of the phrase “ticking the boxes” to describe the validation of a compliant or secure environment. This last point is included to underline all of the others. “Box ticking” suggests an attitude to security that takes no account of what is actually going on. It suggests that instead of real, practical implementation of policy, we have a discussion-based activity. A piece of paper rather than observable evidence. It pays lip-service to real security and it is to be avoided.
How did you score?
0 – Congratulations, you’re running a tight ship. In fact you’re so busy you probably haven’t even read this post.
1-4 – Security probably feels like an uphill struggle right now, but it gets easier as you improve.
5-7 – Unfortunate. Even though no box remains un-ticked, there’s still work to do.
You might be interested to read the recently published output from the PCI Risk Assessment SIG (Special Interest Group). There’s guidance in there on what constitutes a risk assessment process, and what it should cover. The document makes specific reference to PCI DSS requirement 12.1.2:
“12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. (Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.)”
You can get a copy from here.
If you’re interested in contributing to a PCI SSC SIG in the future, then you can do so as a Participating Organisation (PO). More information on becoming a PO is available here.
PCI requirement 6.2 “Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities” includes the additional note:
“The ranking of vulnerabilities as defined in 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement.”
As the summer (at least in the Northern Hemisphere) is almost upon us, this seems like a good time to remind ourselves what this deadline means to your PCI compliance activities.
Here are the details, as supplied by the PCI SSC.
1. After June 30, 2012, organizations will be required to assign risk rankings to newly detected vulnerabilities affecting the CDE as part of the ongoing vulnerability identification process established in Requirement 6.2. Guidelines for classifying risk are provided by the Council as follows:
- Risk ranking systems should be based upon industry standards or best practices.
- The risk ranking assignment should classify risk in a manner which facilitates prioritisation for remediation. (Example: High, Medium, Low)
2. When application development is in scope of an entity’s CDE, Requirement 6.5.6 will necessitate testing against the vulnerabilities classified as “high” risk as part of the secure application development process.
3. Additional Testing Procedures are indirectly affected by the cutoff date and include:
2.2.b: Updating of system configuration standards as new vulnerabilities are identified
10.4.a: Vulnerability identification in time synchronization technologies
11.2.1.b: Internal vulnerability scanning relative to vulnerabilities classified as “high”
11.2.3.b: Internal vulnerability scanning relative to vulnerabilities classified as “high”
Bear in mind that if you are undergoing an assessment after June 30th this year, there will be additional requirements to meet regarding the above.
One of the great challenges of PCI compliance (or indeed any other compliance activity) is understanding the jargon. Qualified Security Assessors (QSAs) talk extensively about “validation”, “assessment” and “evidence” all day long, but sometimes the reasoning behind these terms is obscured.
Part of the issue here is that, statements can be made behalf of products or services claiming that they are “PCI Compliant”. However such claims need to be assessed carefully.
For example, do you know why you should be seek further information when a software vendor to states categorically that their log management/file transfer/integrity monitoring/etc software is PCI compliant? (hint: there is no way for such applications to be assessed outside of your own card data environment)
Here are the key questions to ask when substantiating claims of PCI compliance:
- Who. Who is claiming compliance? Is this claim from a merchant, a service provider, or a product vendor?
- Which. With which standard are they claiming compliance? There are a number to choose from; PCI DSS, PA DSS, PCI PTS, etc.
- How. Claims need to be substantiated formally. There are formal documents to attest to this, reflecting how the entity has been assessed, and by whom.
To help you do this, we’ve created a short PDF. It will help you separate facts from fluff and clarifies an area that can easily become confused in today’s multi-party, multi-vendor PCI environments.
Get it here: PCI Validation Evidence.
A FAQ, which is neatly addressed in the PCI SSC guidance note available from here.
If you can answer “yes” to any of the following questions, then your application is not eligible for validation under PA DSS (but may still be required to operate in a PCI DSS compliant fashion)
- Is this a beta version of the application?
- Does the application handle cardholder data, but the application itself does not facilitate authorization or settlement?
- Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?
- Does the application require source code customization or significant configuration by the customer (as opposed to being sold and installed “off the shelf”) such that the changes impact one or more PA-DSS requirements?
- Is the application a back-office system that stores cardholder data but does not facilitate authorization or settlement of credit card transactions? For example Reporting and CRM, or Rewards or fraud scoring
- Is the application developed in-house and only used by the company that developed the application?
- Is the application developed and sold to a single customer for the sole use of that customer?
- Does the application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components?
- Does the application depend on other software in order to meet one or more PA-DSS requirements, but is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software?
- Is the application a single module that is not submitted as part of a suite, and that does not facilitate authorization or settlement on its own?
- Is the application offered only as software as a service (SAAS) that is not sold, distributed, or licensed to third parties?
- Is the application an operating system, database or platform; even one that may store, process, or transmit cardholder data?
- Does the application operate on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing?
Point 13 above is expanded upon in the SSC document “Mobile Payment Acceptance FAQ“, where the different categories of mobile payment acceptance applications are detailed.