The "RISKY BUSINESS" Blog

To an "old school" infosec practitioner (like myself) confidentiality is the most emphasized element of the CIA triad (integrity/availability) because the risks associated with the failure to provide confidentiality are usually the biggest and the regulations can be the stickiest (e.g., PII, PCI, HIPAA).

"New school" practitioners are likely to view things a bit differently. When you have grown up with "where you are/what you did/who you did it with" posted for the world to see on MySpace/ Facebook ... the boundaries between private and public are pretty thin. Rather than ramp back, many are continuously broadcasting their whereabouts and activities using Four Square and Twitter.  GenY folks are just not all that concerned about confidentiality ... because they are not that concerned about privacy.

My conversations with GenY have altered my views on privacy quite a bit.  So has my work as a social engineer.  So has the fact that I have had my Personally Identifiable Information disclosed by multiple retailers and a mortgage company.  In short, the Genie is already out of the bottle and there is no way to get the cork back on.  If you don’t agree with me, Google yourself, and take a look at tools like pipl.com, paterva.com, and jigsaw.com. If you’re anyone who has at least partially embraced the internet -- birthdates, mortgages, judgments, addresses, your work history, your military records (including serial number), Social Security Numbers, purchases you made on Amazon, your woeful performance in your fantasy football league, posts you made on the dementia message boards -- are all just a click away.  

So if our "private" information is now "public" do we really need confidentiality?  Does it really matter if someone knows my Social Security Number? Driver’s License Number? Address?

Sadly it probably still does -- because those items are often inappropriately used as a form of authentication.  However, as GenY folks take more prominent roles in politics and information security I would not be surprised to see some big changes. Most notably a de-emphasizing of confidentiality and an emphasizing of authentication and authorization. 

I'm ready ...

The process of “realization” is an interesting one. 

My first thoughts on HITRUST tended towards the negative; “Why do we need another ISO-27001 derivative information security framework?” “Why not just get ISO-27001 certified?” “Is this going to be another pay-to-play framework like PCI that is more focused on generating revenue than it is on securing data?”  The latter concern was “enforced” by the HITRUST Alliance’s initial policy of only making the CSF available to those willing to pony up a couple of grand.

Fast forward a year plus and things are looking significantly different to me. 

• ISO-27001 holds tremendous promise as a form of third party attestation IF it is used right.  That is, it is important that the recipient of a 27001 certificate validates that the ISMS scope, the risks the ISMS scope considers, and the acceptable risk criteria established  align with the services being  utilized, the risks specific to the recipient of the certificate, and acceptable risk criteria established by the recipient. When considered in this context, I have come to see the “prescriptive” elements of HITRUST as being a “pre-definition” of the logical scope, risks, and risk acceptance criteria that are common to healthcare organizations.  So in a sense, the recipient of a HITRUST certification already knows that the scope, risks considered, and risk acceptance criteria are likely well aligned with their expectations. 
• There are some really smart people aligning themselves with HITRUST and it appears to be reaching a critical mass.  Should it hit its “tipping-point” it will move from “should we” to “we need”. 
• HITRUST has comported itself in a manner more consistent with being a trustable entity (think ISO or OWASP) than a non-trustable entity (think PCI).
• When you view HITRUST as ISO-27001 with a pre-defined scope, risk, and acceptable risk criteria the two “standards” don’t seem like an either/or proposition, rather they seem complementary in nature.  If I were a health care organization that would rather have an ISO-27001 certification – I would still choose to leverage the HITRUST CSF to simplify the process and benefit from the standards (e.g., HITECH, NIST, PCI) cross-mapping and the controls implementation guidance it provides.

So if you’re in the healthcare space and you are asking yourself which Information Security framework you should align yourself with … I would argue that there is no reason to make that decision.  By aligning yourself with HITRUST you are simultaneously aligning yourself with ISO-27001 at the same time. Hence, I think that we will soon start seeing healthcare entities with both certifications. 

Have noted a gradual and interesting change over the last few years.  Our security assessment “read-out” meetings where we discuss our findings in detail with the client have gradually become more strategic in nature.  We still spend quite a bit of time talking about the more tactical elements of risk mitigation (e.g., what configuration changes need to be made, what patches need to be deployed, what coding changes need to happen) however, we are now spending more time discussing the root cause of the issues and  what upstream changes are necessary to reduce the likelihood that the identified problems re-appear.

Even more interesting to me is that we are having conversations even further up the tactical/strategic continuum at initial meetings with our clients.  The momentum around ISO-27001 is remarkable.  There is a much smaller, but still notable buzz around OWASP as well.    Clearly, information insecurity is evolving. 

Personally, I’m excited by the change.  To me it represents a very significant inflection point – one where we stop looking for technical “silver bullets” to our pain points and we begin apply a more structured methodical system to being secure and proving we are compliant.  Leveraging the most open and trusted standards possible – especially those that are well vetted and widely recognized is common sense.

There are many implications to this shift up the continuum, I’m optimistic that the most notable will be that the process will become simpler resulting in a significant improvement in security postures.

I spoke this week at an event where I was discussing how globalization is impacting information security and used the McDonald's at the Louvre in Paris as a very sad example of how we are unfortunately losing our regional cultures. On the plus side, that same McDonald's and the 31,000 other McDonald's around the world can teach us a lot about information security.

As a person who enjoys dining and tries to eat healthy - I'm not a really big fan of eating at McDonald's.  That being said, I'm amazed by any company that can feed 47,000,000 (that's million!) people per day in 31,000 restaurants across 120 countries and have their dining experiences all be so remarkably consistent.  When you consider the cultural differences, supply chain logistics, and the fact that over 1,500,000 employees are involved in the process ... it's an incredibly remarkable feat (especially when you consider that the vast majority of their employees don't have a lot of education).  How do they do it?

McDonalds has developed nearly flawless, continuously improving, systems for EVERYTHING.  How burgers are cooked, the way the combo meals are packaged, the ratio of ice to soda in each cup, nothing is left to chance.  They have identified every possible process that could be systematized and then they've gone through the process of creating, documenting, implementing, and continuously improving each of those systems.  So what does this have to do with information security?  Everything.

We would all significantly benefit from developing an Information Security "playbook" like McDonald's has for their business that defines the "system" that we need to put in place and the information security processes that we need to operate and optimize.  Fortunately, the basic framework exists: ISO-27001.  It's an Information Security Management System supported by ~ 134 key processes (ISO-27002) that an organization needs to account for when securing their information and critical processes.  Better yet, it's a system that has already been vetted by thousands.

So the next time you are struggling with the challenges of knowing you're secure and proving you're compliant ... think about McDonald's.  Is your challenge more daunting than serving 47,000,000 people every day in  31,000 restaurants in 120 countries? 

Ever have one of those really intriguing moments ... where for the rest of the day your mind keeps circling back and considering the possibilities? I had one yesterday.

A client asked us to help them on a SIEM Proof of Concept leveraging OSSIM (Open Source Security Information Manager). We had tried OSSIM a few years ago with minimal success, but had been intrigued by Alien Vault's stewardship of the project, so we were excited to participate. We figured the best way to get started was to deploy OSSIM in our environment.

Just a few hours later our SIEM Practice Manager grabbed me by the arm with a big smile, "you gotta see this!"

Remarkably, our network had been auto-discovered, a Vulnerability Assessment had been run, net-flows were being captured, we had real-time visibility to network traffic, a snort ids sensor with an appropriate signature set had been deployed, and basic network monitoring functionality was in place.

Now if OSSIM doesn't sound like a conventional SIEM, it isn't. OSSIM integrates a diverse array of existing Open Source security tools into a unified whole which is notably more valuable than the sum of its parts. Surfing our security related data gave me greater insight into our operations and our information security posture. Very quickly we had a comprehensive view of our environment, with one notable exception, we were not yet monitoring device logs (which is really the lynch-pin of SIEM).

It took another 10 minutes or so and OSSIM was receiving logs from one of our more chatty Cent-OS boxes. After updating Snare on our 2008 Active Directory box OSSIM happily consumed our AD logs, although, the regex's will need a bit of fine-tuning to handle a few of the event types we want to capture.

So would Devin Woodcomb proclaim that OSSIM is "awesome"? Not sure yet, but I am intrigued as hell at its ability to provide significant value right out of the box. BTW, I wonder if mentioning that everything we have tested to this point is part of the open source version (free!) would tip his opinion ...

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! 

One of the hotter areas today is the integration of IAM and SIEM. When Identity & Access management (IAM) and Security Information Event Management (SIEM) are optimally integrated, user access compliance monitoring capabilities are increased significantly beyond what either SIEM or IAM can provide alone.

This is because IAM provides a context to user activity event data (e.g., role, entitlements, cross-referencing of multiple user IDs, account status) that can be directly leveraged by the SIEM to identify exceptions in real-time and initiate a workflow to remediate the issue. For example: triggering a suspension of all of a user's IDs and the initiation of a security incident after detecting that an individual attempted to access critical data using multiple user IDs, after access to said data had been terminated.

To this point the challenge has been getting IAM & SIEM to integrate (dynamically share information and allow processes to be remotely initiated). Fortunately, this has become much easier as those vendors that have both an IAM and SIEM offering (Novell, CA, IBM) have included the required integration into both IAM and SIEM on our behalf. I have had the opportunity to see the Novell Sentinel IAM/SIEM integration in action at a client site. It absolutely changes the way you think about security and compliance.

Click here for an excellent Gartner technical brief on the subject.

... tip of the cap to the late 90's FOX show "When Animals Attack!"

Remarkably, 32% of data breaches involved partners' networks being used by an external attacker. To be clear, the largest single source of risk in these organizations was a business partner.

I was (and still am) very surprised by this number. For years, we have stressed the risks associated with system interfaces to third parties and the often ill conceived/executed access connections/channels.

However, to this point I had no reason to believe that it represented that high a percentage of the risk.  Having a number of this nature makes it much easier to communicate the information security challenges relating to  business partner connections.

So, the next time you look at that partner provided and managed firewall that "secures" the connection between you and a partner, ask yourself if you know enough to know that the risk associated with it is fully understood and well controlled.

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.