I read a short section in Bruce Schneier’s book Liars and Outliers that tells the tale of Jamaica Ginger:
“an epidemic of paralysis occurred as a result of Jamaica Ginger… it was laced with a nerve poison… and the company was vilified”, but not until 10s of thousands were victims, this resulted in the creation of the FDA.
To date, throughout most industries there is no absolute requirement with meaningful incentives to introduce and sustain operational information technology safeguards. There are isolated elements focused on particular threats and fraud (such as, PCI for the credit card industry, CIP for the Energy sector, etc…). So what will result in the Jamaica Ginger of information security?
Some portend that a cyber-war (a real one) that creates such societal disruption; a long enough sustained negative impact to survive the policy development process, and driven enough motivation to be complete. OSHA, FDA, and other such entities exist as a result of such events.
The best action enterprises can follow is to mature and engage sufficient operations that address their information technology concerns in the marketplace. As a means of self preservation; selfish (perhaps) demonstration of a need to NOT have legislation or a body established (such as the Federal Security Bureau), and ultimately preparedness should such a requirement be introduced the changes to your business would be incremental at best.
Posted in audit, Compliance, IT Controls
Tagged 2013, best practices, china, Compliance, cybersecurity, europe, fines, fisma, it compliance and controls, IT Controls, james deluccia, jdeluccia, pci, PCI DSS, regulation, Security
The payment card industry standard articulates very prescriptively what should be done for all system components that are within the payment card process. An area of usual confusion is the depth of abstraction that should be applied to the “connected system” element of the standard. Specifically, the standard states the following:
The PCI DSS security requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. ―”System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (for example, Internet) applications.
– PCI DSS 2.0 page 10
To simplify – there are the system components that are involved with the payment card process, and then there are the supporting systems (connected systems) that also are in scope of PCI DSS. An example would be the patch server where the in-scope PCI system is receiving patches (but there are dozens).
So a rule of thumb on scope most offered in the industry is:
If you can digitally communicate with the system it is a connected system (this includes UDP, TCP, etc …) it is in scope.
A nice write up by Jeff Lowder referring to specifically the security system components can be found here written in 2010.
A Korzybski abstraction problem:
How many levels of abstraction should one undertake? Meaning – should that same patch server then be examined to see what systems are connecting to it and thus also be included in the ‘connected system’ web?
The answer here is generally no – the abstraction is only one level deep. That doesn’t mean best practice risk and security practices evaporate, so no leaving that server unpatched on the internet or anything.
What Requirements of PCI DSS should be applied to these ‘connected systems’?
The standard makes it clear in the beginning “The PCI DSS security requirements apply to all…” So, every PCI control applies to the connected system under discussion and identified through the abstraction of the services supporting the CHD environment itself. Limitations can be applied to the core system components that make up this “connected system”. Such as in the virtualization space, the hypervisor risks and controls are differentially applied from the entire standard. These exceptions from fully applying the PCI standard directly to the connected system must be limited and done with clear awareness. [Updated: All requirements should be considered … each QSA is different but addressing the risk with an eye towards compliance is the best and safest bet. Shopping for someone to accept a state of controls is a painful road]
An “Open PCI DSS Scoping Toolkit“(pdf) published on August 24, 2012 is available that provides an excellent structure in methodically determining scope and the controls that would be applicable. While not a product of the PCI SSC or a technical group – there is good content here that should be carefully considered as part of every security and compliance strategy. Thanks to Eric Brothers for the note! [Updated 12/5/2012]
Another good write up is offered here where a good articulation on the two factor authentication exception; file integrity monitoring exception, and a few other practices are nicely elaborated by Andrew Plato (Plus check out the comment threads.. very informative though proceed with caution as this is one QSA interpretation). Definitely worth a review, though sadly after a review there appears no other elaborations within the PCI SSC on this topic.
This write-up is an exploratory effort to seek clarity by consolidating thoughts of leading individuals in the payment card space and client environment realities. Any additional insights or perspectives you have are welcomed and requested in the comments below! I’ll update as anything is shared.
Posted in Compliance, IT Controls, PCI DSS
Tagged 2012, audit, best practices, Compliance, connected system, it compliance and controls, IT Controls, james deluccia, jdeluccia, pci, PCI DSS, remote access, Security, virtualization, visa
Organizations struggle with a complex information security compliance program needs placed upon the organization. Mature organizations participate in regular self review and improvement activities on an annual basis, and in some organizations as regular as monthly. These organizations are fortunate to have larger security teams that reflect the global (think Fortune 500) deployment of assets. This network provides an immensely valuable feedback loop on the following, among many others:
- What are effective practices
- What policies are great for the business, and where are exceptions being raised frequently that may indicate unknown business requirements
- Attack patterns and weaknesses in the security program based on statistical review of events within the business
- Where are programs meeting customer / client requirements – based on sales attributions and audit findings, respectively.
For organizations of this sophistication and those of all other sizes there is an additional input that raises the overall efficiency and effectiveness of the security compliance program. That is through a self comparison against public data. Specifically data released by government audits, intelligence committee reports, and guidances / complaints issued by government enforcement agencies. These are immensely helpful in providing businesses across all sectors insights into security threats, trends, shifting perceptions of “due care”, and areas where risks are ebbing and flowing.
A simple set that an organization may consider includes:
The takeaway here is that every organization should regularly identify these sources, consolidate them in a manner that can be analyzed, and develop an intelligence report on any gaps in practice and security controls as documented by these organizations. These apply to every organization and not simply those in the government space. The process of careful analysis against the organization’s strategy combined with the rote knowledge of the practitioners internally can support realizing these benefits.
The genesis of this article was inspired through close workings with Fortune 50 organizations and developing leading global security programs. A nice article illuminating this and other opportunities for improvements to security compliance programs is by Adam Shostack, in “The evolution of information security“. A very good read.
Thoughts .. and expansions of idea are always welcome!
James DeLuccia IV
Posted in Compliance
Tagged 2012, audit, best practices, Compliance, cybersecurity, fisma, it compliance and controls, IT Controls, james deluccia, jdeluccia, pci, PCI DSS, Security
The recently published, Simplify Cybersecurity With PCI, by Heidi Shey and John Kindervag is an interesting and valuable read. The premise is that the government regulations (any really) are generally obtuse and ideal focused without prescriptive how-to descriptions. While the payment card industry standard (PCI DSS v2.0 in this case) is direct on what and how technology controls should be deployed. The authors present a synergy that exists that can help an organization establish a security program.
I would definitely recommend businesses struggling to establish a security program to review the concept. I would challenge those involved in establishing security programs and enhancing such programs to focus on their core business strategies and focus on an iterative cycle, and not simply a controls exercise. Ultimately I agree there are synergies as described by the authors, and I feel the mappings is quite insightful, but I would pair this with the cyclical nature of an ISMS to round out the edges and make it a more pragmatic and ultimately effective program.
One note also, is that the authors intend that the PCI DSS standard is appropriate for mapping, but I would caution readers and all who utilize PCI DSS. The standard is specifically articulated for a set of risks and typically bounded by scope of the card data environment. When utilizing these standards it is important to eliminate and or address these pre conditional weaknesses first, prior to establishing a proper security, and ultimately compliance program.
Other thoughts? I have personally done many mappings (most recent 134 global regulations and guidances) and can appreciate the value of such alignments, but also with each standard carries assumptions that must be managed at the program level.
Posted in IT Controls, PCI DSS
Tagged 2012, best practices, Compliance, crossmap, cybersecurity, fisma, forrester, it compliance and controls, IT Controls, james deluccia, jdeluccia, nist, pci, PCI DSS, Security
Why should an organization address and comply at least with industry supported practices? A question of compliance versus driving business value, and one often raised in the Payment Card space is important to understand and convey at every level of an organization. The importance is building an organization’s security and compliance program in a manner that cohesively manages the demands of client requirements, government cares, and general competitiveness. In an era where competitiveness includes thwarting attackers focused on poisoning your supply chains with misinformation or directly seeking to “acquire” the Intellectual Property that makes the business competitive. The executive and board of directors within an organization are acutely seeking demonstration of focus and effectiveness.
So what are the risks to an organization not managing the risks of an industry standard?
To answer that below I will speak directly to PCI (to eliminate the obnoxious “it depends” statements) and about a Fortune 500 company that has other intellectual property.
Ultimate risk to an organization out of compliance with PCI is well documented (on the Card Brand sites themselves and breach news sites), but stems from a violation of contractual agreements with the business’ banks and ultimately the card brands. This contractual obligation (and violation) can be determined without a breach. The violation (profiled in a public court case out West) can be identified when a QSA / Forensics team from the Card Brands / or any of their team members conduct an assessment of compliance to the organization. The court case referenced is of a restaurant that had been suspected of a Common Point of Fraud; proven to not have been breached, but in violation of PCI DSS based on forensics report issued to Bank & Card Brands). So, the risk and associated damages can result from a breach (classic) or simply by confirmation that the business violated the contract established with the Card Brands.
The highlight here is being compliant means addressing the threat vectors to the business and the assets requiring protection. Failure to achieve those results from either path can result in a number of business and financial negative events. These, in part, are described below:
- Financial punitive fines by the Card Brands ($500k is a number published by the Card Brands)
- Per account # breached associated costs & fines – this number is a hard figure to lock down .. $100-$170 per card in some cases
- Higher interchange fees per card transaction for the entire legal entity – this is very costly and most damaging
- FTC and public government actions, that may include recurring privacy audits (such as 20 years of third party audits)
- Automatic level 1 status for the company (which requires annual onsite attestation)
- If you look at TJX and the other public breaches they have published hose expenses around $130M+
- Civil / class action lawsuits likely
There are also reputation and periphery risks to the business:
- The company possesses additional data protected and considered sensitive by industry and governments around the world, PCI Data is one element but it is likely that these systems share networks, applications, and permissions. The breach of one could inadvertently result in the breach of the other (PII)
- Not at least complying / deploying operational security controls broadly considered baseline practice would be damaging in an era when security of data and confidence is so important
The highlight here is that the risk is not addressed by the issuance of a ROC by a QSA or having run assessments, but that the security and risk programs are operational and effective. These ROC and assessments are simply attestations of a program that is mature and functioning. Compliance is not deemed by a ROC nor does it provide safe-harbor in the common sense of the term. A long standing statement by the PCI SSC is that “no compliant organization has had a breach” <– including TJX, Heartland Payments, and Global Payments all breached with current ROCs signed by TrustWave.
The success of the PCI program is the ultimate reduction of risk and adequate security controls of the organization. The risks addressed through a cohesive integration with the operational elements of the business are the critical success factors.
James DeLuccia IV
Posted in Compliance
Tagged 2012, audit, Compliance, cybersecurity, data breaches, forensics, it compliance and controls, IT Controls, james deluccia, jdeluccia, pci, PCI DSS, Security, visa