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
A security program and it’s controls are a hypothesis put in place and evaluated within an organization based on a set of assumptions and expected value. This is a critical success factor in an information security compliance program.
The concept of testing the viability of a hypothesis is not new and one that is commonly missing within organization’s security compliance programs. Consider all the areas within the business where testing of hypothesis exists and the result are fed back into the development process. In some cases products may be dreamed-up; prototyped; tested; iterated, and perhaps shelved or launched. Software development (SDL) includes developing code, testing it against use cases, and continually evaluating it against performance requirements, customer acceptance criteria, security!! requirements, and of course regulatory considerations.
Organizations are not lacking in the ability of scientific method, metrics, performance testing, or hypotheses. The opportunity lies in establishing proper use cases as they relate to information security compliance, and rigorously challenging and tracking these policies, practices, and procedures against the real life result of such a deployment.
A few mythes to dispel:
- Organizations can define metrics and KPI based on the root cause analysis and driver for a set of security program controls
- Metrics and KPI should be tracked, challenged regularly, and brought to executive levels for acceptance of performance (an important element in driving definition of value with security programs to core business initiatives)
- Controls do not beget controls
- Technology need not beget more technology or safeguards
Sometimes there is no solution that is guaranteed, so transparency on performance, predictability, impact, cost, and residual risk are key factors for all involved
The takeaway’s here include at least the following considerations:
- Identify why such policies, practices, and controls are deployed.
- Determine the root cause these are solving.
- Define the performance expected.
- Measure that performance against the metric.
- Is the the performance conforming to objectives.
- Are the metrics appropriate for reaching the conclusion sought by the root cause and technology information available.
- Can security compliance program elements be consolidated to address the root causes
- Can efficiencies be gained by consolidating technology and safeguards
- Are there architecture opportunities that can be considered
- Are there business procedure changes that could better enable the business activity and directly improve the overall state of the business
There are numerous additional considerations, but as in all enhancements – focus on a small set of tasks and iterate. Through a few cycles efficiencies will be gained internally, and the practices will begin to transform to reflect the culture and operating habits of the business. A word of caution though, don’t elongate the process. Once a method is established and advantages realized, scale rapidly to high impact areas (definition may be based upon user impact; risk impact; dollar to revenue served, etc..)
The thoughts here are based on personal experience building and designing global security programs. Some elements described may need customization in approach and process based on your own organization’s structure.
Posted in IT Controls, Security
Tagged 2012, best practices, cio, ciso, Compliance, cybersecurity, it compliance and controls, IT Controls, james deluccia, jdeluccia, metrics, performance improvement, regulation
A challenge for large businesses is addressing their own information security needs to manage their operations in a manner that allows them to be resilient and adaptable in an ever competitive market place. Each organization is different – the risks and the needs to mitigate. A painful evolution of the past decade has been the mistaken direction organizations have taken to build / address singular compliance instances. Meaning, organizations develop programs to address single compliance requirements – vendors, SEC, industry, etc … Not that these are not important, but a natural effect of this is the perception that the security “controls” (even the word doesn’t lend itself in the right non-audit light) are there to achieve compliance.
The mistake is achieving compliance to compliance requirements alone. There is a gap in the business’ OWN needs. Over the past year I have spoken on this topic publicly at conferences and my book has a huge focus on aligning and establishing business requirements cohesively.
To elaborate on the graphic … the CxO office must be aware and share their strategy – typically easy to find, as I generally begin building these programs from the 10-k reports over last two years. These feed the information security program elements and form the decision framework against all technology, security controls, risk frameworks, sourcing considerations, recovery timelines, etc… In addition, the compliance elements must be addressed – but with the understanding these are risk transfer activities by third parties. Not to be the basis of the enterprise program, but a singular consideration.
The capability of the organization to address market competitive requirements is based upon the proper balance. Here you can see the target is 85% of the program is made up by the business’ own innovative and market driving / supporting activities. 15% of the program to meeting these ‘license to operate’.
The takeaway is to challenge your organization’s singular managed compliance initiatives and a deep dive on budget alignment to business revenue generation. There must be rationalization to the safeguards to make the business efficient and effective – that includes safeguarding and enabling the business to conduct business, everywhere.
Posted in Compliance
Tagged 2012, audit, Compliance, CxO, cybersecurity, fisma, hipaa, hitech, infosec, it compliance and controls, IT Controls, james deluccia, jdeluccia, nist, pci, PCI DSS, regulation, Security, sox
MasterCard published a very brief document outlining the very popular Use Case where a Merchant leverages a third party e-commerce system for processing transactions by redirecting to a separate hosted site. The attraction is the obvious shift of the payment card environment to that of the hosted page provider. This does help in reducing the PCI DSS scope, but as highlighted within the paper “…does not remove the need for a robust information security program.”
The brief highlights there is a risk to Merchants (“Based on the current compromise and attack trends”) where attackers may attack the Merchant’s web environment to redirect the traffic from the approved Hosted-Page vendor to a malicious party site. This can be executed with a fake page where nothing but an error occurs, or the attackers can proxy (pass through) the traffic to the true Host-Page vendor. This second approach allows the transaction to occur without any notice to the user of the attack.
The attack mitigation presented (follow best practices) are expected. It does not say to solely or specifically to follow PCI DSS specifications, but instead to follow best practices appropriate for the web environment itself.
An additional attack mitigation stated is to establish SSL tunnels to fixed addresses and certificates. This is definitely effective when securing the point to point connection, but generally would be ineffective from the attack described (as an attacker could simply compromise from the Merchant Host itself).
An alternative mitigation approach to consider would be expanding the monitoring & response capabilities. As an example, if traffic is being redirected and the host Merchant server is compromised than the next best technique would be (among many) to have automatic triggers at the IPS, FW, and ACL points when these hosts are transmitting to unapproved targets. This highlights the important need of when procuring services with valuable data, to have a deep process of onboarding the Service Provider in a manner that brings to light these technical details and establishes operational response capabilities jointly with the vendor.
The article is short and worth a read. A key question that rang throughout the article was – does the issuance of this guidance make it clear that if the Use Case Attack happens than Y Merchant is deemed out of PCI DSS compliance? The closing paragraph provides some light. Would love others thoughts here too!
“While a merchant may be able to reduce or remove the scope of its environment’s applicability to comply with PCI DSS requirements by using hosted payment pages, it does not remove the merchant’s risk of being involved in, or even the source of, an account data compromise event.
Merchants still have a duty to employ security controls based on industry best practices to their web based environment to protect payment card data.”
Link directly to the guidance.
Posted in Compliance
Tagged 2012, attack, best practices, cloud computing, cloud practices, Compliance, deluccia, guidance, it compliance and controls, IT Controls, jdeluccia, man in the middle, mastercard, pci, PCI DSS, regulation, Security