The "RISKY BUSINESS" Blog

So the childish side of me wants to say I told you so ... but I'm above that so I won't.

It's been a while that we have been banging the ISO27001 drum. So the recent influx of significant cloud computing organizations like Microsoft and Salesforce.com is only a surprise in that they got on the wagons sooner than we thought they would.

What does this mean to you?

If you work for a company that needs to provide third party attestation -- quite a lot. It means the tipping point on 27001 being the de facto form of attestation is nearer than we thought -- likely less than 18 months. So if you don't yet have an initiative in place - it's probably time to do so.

Where third party attestation is not required its less clear what this means. Best guess is that ISO27001 will become somewhat "de rigueur" in that you will have to rationalize why you chose not to align yourself with the standard to key stakeholders and management (rather than the converse).  I think it's hard to rationalize against leveraging a well vetted framework that simplifies Information Security by providing a method to our madness. Interestingly I had a conversation this week with the CISO of a $5 Billion entity that has no attestation requirements - yet he wants to move to ISO27001 for just that reason.

For an Intro to ISO 27001, download a copy of our CSO presentation.

Or, review a Case Study for ISO 27001 by clicking here.

Dear X,

At the close of our meeting you asked me to follow up with a proposal on how I think we (jointly) should approach your information security/information assurance requirements relating to (insert your relevant regulatory compliance issues here).  As you already know, I don't yet have enough knowledge of (insert your company name here) to answer that question definitively.  But "I'm not sure yet" is neither confidence inspiring nor all that useful.  So based on the four main ideas I took out of our meeting  (bullets below) I will lay out my best guess as to what our (joint) approach may be. 

PRIMARY CONCERNS:

• You have a growing demand to "prove" that you are compliant with relevant laws and regulations (most notably HIPAA/PII) which is challenging and time consuming.
• You have a relatively good security posture, although it lacks in documentation and formality.  This results in you feeling good about the 95% you "know", and nervous that the 5% you're not sure about is going to come back to bite you.
• The reason you are where you are, is that you have insufficient resources (time/training/manpower) to address security/assurance/attestation at a more "strategic" level.
• You are looking for a roadmap to confirm the 95%, address the 5%, and simplify the process of proving you are compliant with relevant laws and regulations to management and customers.

RISK-DRIVEN APPROACH
Our approach should be risk driven.  Fortunately, it does not seem as though there are any "urgent" risks that need to be addressed immediately,  which gives us greater flexibility in our approach.  Beginning with the end in mind is a fundamental tactic, so determining what the overall "target" is for our control environment is going to be helpful .  For now, I would restrict our efforts to the information security realm to ensure that we don't end up in a "boil the ocean" exercise (later we can look at integrating our information security controls into a larger Information Technology Control Framework like COBIT if it is warranted).   From an information security framework perspective, I'm a fan of ISO 27001 for a couple of reasons:

• It's proven: ~ 7,000 companies are already leveraging it, and ISO 17799 from which it is derived, has been in place over ten years and has been used by tens of thousands of organizations.
• It's an international standard that is "recognized" by everyone and is widely regarded as the de-facto standard by most.
  ISO 27001 has  been  "mapped" to HIPAA/PII and can be easily mapped to any new standard that you may need to comply with.  This simplifies proving compliance.
• It's certifiable (like ISO 9001) meaning that you can get those portions of your environment that are relevant to the handling of client data certified to be compliant with the standard by an independent entity.  This is the best possible form of attestation.

Alternatives include: a roll your own approach, the BITS Shared Assessment program (more financial services oriented) and HITRUST (purely Healthcare-centric).   I'm pretty confident that ISO 27001 would be the optimal approach for you.

PLANNING FOR ISO 27001
Assuming you agree, and you are not under any  short term requirement to be certified,  I would recommend a 1 - 2 year time target for certification.  You can try to do it faster (if necessary), but the controls in a strong control environment are highly interdependent and trying to move too far too fast often results in sub-optimal results.  Further, doing it faster would drive much of the work effort external to your organization and we have found that ensuring  your key folks are true stakeholders, is very important to long term project success.

Gaining Senior Management buy-in is also critical.  A 27001 Gap Assessment is the best way to get a sense of the work effort necessary to get to ISO 27001 certification and communicate the staffing/budget requirements for the same.  So a Gap Assessment would likely be the first activity relating to ISO 27001, and would provide a measure of where we are,  where we need to get to, and what it will take to do so.

MANAGING THE "INTERIM"
One challenge to the approach outlined is "proving" you are secure to customers/business partners in the interim (between now and ISO 27001 certification).  An approach that we usually (successfully) employ is to use a Vulnerability Assessment and Penetration Test (VA/PT) to "substantiate the net-effectiveness" of your current control environment.  In addition to being short term attestation, the VA/PT also provides valuable input into the ISO 27001 Gap Assessment (and longer term, the Risk Assessment that is integral to ISO 27001).  Where attestation requirements are a bit higher, we often supplement the VA/PT results with a Security Data Flow Diagram (SDFD) depicting key security treatments throughout your client's data-lifecycle.  The SDFD is also leveraged during the ISO 27001 Risk Assessment phase.

Please call me on my cell (732) 267-6324 when you have a few minutes to discuss this further.

PS: You might also want to check out our ISO 27001 Case Study and other ISO 27001 resources for further information! 

Call me jaded but my level of distrust goes up when an organization:

• Pronounces itself as the "Information Security" guardian of an industry segment
• Develops a "proprietary" framework/standard that it rationalizes based on the uniqueness of the industry
• Develops its own certification programs and charges exorbitant fees to qualify entities for certification

Perhaps I am just cynical based on our mutual experience with the  "Payment Card Industry Standards Council" and the PCI-DSS program which has only succeeded in reducing the risk to the payment brands at the expense of the merchants and the card owners. 

My lack of trust in all things PCI-related is well illustrated by the recent "gift card" I gave to my nephew for graduating high school.  He called me embarrassed to report that the card balance was zero and that the credit card company had told him that it had already been used.  After a considerable time on the line the credit card company finally "admitted" that the card had been used five days prior to my purchasing it.   If the credit card companies can't prevent/detect this proactively - what faith can we have in them or their ability to govern?

On learning of HITRUST I was hopeful that it would be different.  But on first blush it looks like they have stolen a page or two out of the Payment Card Industry Standards Council playbook.  For example,  the costs involved for a consulting/auditing firm to be "qualified" exceed $20,000.  Initially the standard was only available at a significant cost. On a more positive note, the Alliance recently announced that the Common Security Framework (the standard) will now available for free (however, after 30 minutes on the site today - I still can't find it).

Hopefully, I am wrong and HITRUST will be a shining beacon for Information Assurance - but I'm not so sure.  I would rather have a comprehensive, non-industry specific, standard (e.g., ISO-27001) achieve sufficient status that these entities don't feel the need to develop proprietary standards.  The benefits would be significant.

Robert Carr, the CEO of Heartland Payment Systems,  had some very candid and controversial thoughts relating to the Payment Card Industry Data Security Standard (PCI-DSS), the Qualified Security Auditors (QSA) who certified their environment as PCI Compliant before their massive (up to 100M card) breach, and the difference between being compliant and being secure. Article here

The part that really jumped out to me was the statement about the QSA failing to check Heartland's vulnerability to a "common attack vector". Without additional information it's difficult to determine if the criticism is fair.

Did the companies that were previously attacked using that vector disclose it? Had the vulnerability been disclosed by the researcher(s) that discovered it (or were they waiting for the vendor to issue a patch)? What if the "common attack vector" only rates as a low-medium vulnerability by PCI's own scanning standards? There's a potential information asymmetry problem that works against the auditor in these situations. Has Heartland shared detailed information of their attack with the QSA community as a whole to prevent the same situation from occurring elsewhere? 

Is it the QSA's obligation to stay aware of common attack vectors or is it the PCI Council's responsibility to  promulgate "common attack vectors" to them.  I believe it's both, but more important that the PCI Council does so as they have visibility across every PCI Compliance Audit and data breach. Assuming the PCI Council does promulgate this information to QSAs, but not to the companies themselves or other non-QSA auditors that do PCI DSS work (like us), then the council is creating additional incentive to pay the hefty fees to be QSA certified at the expense of the companies and the consumers.  This shouldn't be all that much of a surprise. Ask yourself why we haven't gone to two factor authentication on credit cards to reduce fraud ? (hint: because it's cheaper to let companies like Heartland take the fall)

I think the PCI Council is a great example of an industry association failing to fulfill their role of building trust between their members and their consumers (another great example).  How many more PCI-compliant merchants will get hacked before that trust is completely eroded? As trust decreases, so does the industry's pricing power and the only way out of this mess is providing a higher level of assurance that will cost the merchants more money - but who's going to pay more money for a PCI audit if they don't feel compliance will actually secure them from hackers?

An incentive for conformance (i.e. compliance) is not an incentive for performance (i.e. effective security). Until PCI either gets the incentives right or implements technology that's secure by default the problem will only get bigger.  How many more PCI-compliant breaches will it take before the government intervenes?

Just hung up the phone on an interesting call with a potential client that re-enforced the oft misunderstood reality;

Not all compliant systems are secure, but secure systems can easily prove their compliance with regulations.

To fulfill the obligations of a business partner contract the client  needs to "have an annual penetration test conducted by an appropriately qualified entity".  The discussion centered around whether they should test the application they had deployed under contract, the hosted network infrastructure, or both.

On a relative basis, application penetration testing costs considerably more than network penetration testing - especially for an application that has the complexity and risk profile of the application they had built on their client's behalf.  The application also generally represents the lion's share of the risk.  In this case that was even more so because:

• the organization was running monthly Network Vulnerability Assessments on the network and diligently addressing vulnerabilities identified; and,
• the development team got very quiet when I asked about how they integrated security into the development lifecycle (e.g., Open SAMM) and whether they incorporated the OWASP Top 10 into their security objectives/requirements.

As you can likely already surmise - they opted to be compliant, not secure, and are going to just conduct the network penetration test "for now".  In my humble opinion, this is a short-sighted approach that leaves them and the business partner at great risk.

The business partner is actually most to blame.  This particular system processes and transmits a wealth of Personally Identifiable Information (PII) that is subject to 45+ state and federal regulations.  Failing to identify a more appropriate standard, whether it be the Massachusetts law (likely the most onerous) or ISO 27001 (or similar), put them in the position that their business partner could easily decide to be compliant with the contract rather than secure.

Remember compliance and security are different beasts - you may be compliant with a standard by enabling logging, but unless you are logging the specific events that represent the greatest risk in your environment, you are likely not secure.

While we can all agree on the importance of protecting information and information systems, it's much harder to agree on how we define the state of being secure.  Is it the state where all information security risks are completely eliminated (not possible)?  Is it the state where all security risks are mitigated to an acceptable level (which risks and whose definition of acceptable)?  Even if we reach consensus and achieve the agreed upon state - we all understand that it is fleeting and will only last until a change (often outside of our control) denigrates it.

It is because the assurance we receive is often only valid at an "instant in time" (e.g., a penetration test) that trust is so important.  If we don't trust that the person/team/organization responsible to ensure critical information is handled in the manner we aspire to moving forward, then we really have little or no assurance. 

We were recently engaged by a pharmaceutical firm to assess whether a third party developed and hosted implementation of a multi-million dollar clinical trials solution achieved the security objectives defined in the contract. The report would also form the basis of a new contract intended to "remedy" the existing challenges. 

The meeting took a very interesting turn when I asked "Should we really be discussing a new contract when it is obvious that the service provider has proven they are not trustworthy?" (the impact of the vendor failing to achieve critical security objectives could cost the pharmaceutical tens of millions)

For my money, no contract, no matter how carefully worded, will make a company trustworthy.  And without trust we have no confidence/assurance that critical information will remain secure. 

This posting is intended for my fellow auditors working in the Fortune 1000 world.

The Yankees are no longer winning the World Series every year, Bill Clinton lives in NY not Washington DC, and Y2K is a laughable memory, not a potential Armageddon. Its 2009, not 1999, so please, please, stop requesting SAS-70 reports from entities that process information on your behalf.

I will begrudgingly give the AICPA some credit for realizing in 1993 that the world needed a standard way to say "How do I know what you are doing due diligence to keep our data secure"? 

However, they encumbered it with 2 basic flaws. 

1. It was a mechanism to document a control environment and its operation, not a standard for the operation of a secure environment.  Sadly, too many of my fellow auditors took it as the latter, not the former, and just checked the box on their paperwork instead of "opining" on whether the documented environment was aligned with their information security requirements.
2. The AICPA, in a very self serving manner, mandated that only a CPA (to be clear -- an accountant) could issue a SAS-70. Apologies to those whom I may offend, but with rare exception, the CPA's turned Information Systems auditors I have met are marginal information systems auditors (at best). 

I believe ISO27001 (though not without a few flaws) is probably the best general purpose form of Information Security attestation available right now.  NIST has some great stuff, especially if you work in the government space.  If the data being processed on your behalf is "mono-compliant" you may be able to get away with the associated standard (e.g., HIPAA, PCI, PII).

Yes, that was "Guns and Roses" you just heard on the radio. However, it was a Classic Rock station, not a Top 40 station (which now plays Pink adnauseam), so please change your "due diligence" paperwork to reflect the year.

On my flight back from Phoenix I had an interesting experience that reminded me that what we do is still as much an art as it is a science.

I was asked to review “Managements Response” to the findings & recommendations we provided during the Security Certification and Accreditation process for a very large, mission critical, application for a government client. In doing so, I often referred back to our original reports to ensure that the responses/schedule that they proposed were reasonable, appropriate, and likely to achieve the security objectives that management had defined for the project.

During the review I suddenly felt a little queasy. Unfortunately, the blame was mine (not the gourmet airline cuisine); in reviewing our findings and recommendations it became apparent that we had failed to identify a (perhaps significant) risk. There’s still a little five year old left in me – as the first thought that popped into my head was “If I don’t tell anyone …”.

As you might imagine not missing security risks is pretty important for an Information Assurance firm. To that end we have formalized our processes wherever possible, including at least one Quality Assurance review by a second consultant. In this particular case I had provided QA and had missed the same issue that the primary security consultant had.

Thoughts swirled …. Why on review did this issue suddenly become apparent? What can we do to reduce the likelihood that this happens again? More importantly what can we do to prevent this from happening again? Even more importantly – what did we need to do to prevent this issue from delaying the deployment of business significant changes to this critical application?

First the great news – after considerable angst on our part we determined that the “new risk” was fully mitigated by an existing technical control. The application rolled out to everyone’s satisfaction on schedule. The good news – we have made several subtle changes to our QA process to make this less likely to happen. We also sampled a number of our previous Certification projects to ensure that this was an isolated incident. The less than good news – the reminder that despite progress, Information Assurance is still as much an art as it is a science.

On both sides of the fence (build versus assess) there have been some significant Information Assurance advances over the last five years that have moved us more towards a “science”. Dozens of major universities are now offering excellent programs. OSSTMM is a very intriguing methodology for security testing that we are increasingly leveraging elements of. We utilize elements of prevailing logical frameworks and/or good practices (ISO 27001 and 27002, COBIT, CIS, NIST, and OWASP) which allow us to take as consistent and methodical approach as possible . Unfortunately, as new technologies emerge (e.g., flash, Web Services/SOA) the frameworks are still alrgely applicable but good pratices often trail.

So for now, my goal will have to be more Leonardo Davinci than Albert Einstein — as comfortable with a paint brush as I am with a telescope.