Archive for the ‘ISO 27001 / 27002’ Category

« Older Entries

ISO 27001:2013 – Understanding the New Standard

Posted by Ryan Mackie
April 2nd, 2013

Part 1: Scoping and the approach of implementing the ISMS

Organizations currently implementing or planning to implement a management system based on ISO 27001 will have a tough decision to make in the near future: Should management implement the information security management system (ISMS) based on ISO 27001:2005 or should ISMS implementation be delayed until the issuance of the new standard, ISO 27001:2013?  The decision of selecting either ISO27001 standard will have major implications as to how your organization approaches and designs your ISMS.

Organizations currently certified should not expect much difficulty in transitioning from the 2005 version to the 2013 version.  Organizations that are not currently certified will be impacted by the revised 27001 standard, which is expected to be released later in 2013.

Background

The draft version of the updated 27001 standard was recently released for review.  The draft version format of the updated 27001 standard was redesigned to better align with other ISO standards, such as ISO 9001 and ISO 20000.  Moreover, the draft version received slight modifications in both the management system requirements and the controls included in Annex A.  These modifications better interconnect software-based infrastructures (i.e. cloud computing) that have predominantly emerged within the last few years.

The intent and focus of the standard hasn’t changed in the 27001:2013 draft.  The standard remains focused on information security and an organization’s approach to design, plan, implement, and monitor a management system to effectively manage information security risk.  However, the foundation for designing and planning the management system has shifted to better align with the practical matters of today’s organizational environment.  This will come as a positive shift for several organizations as the scope moves away from assessing the risk approach, which organizations have historically struggled with during the implementation of their management system.

Scoping Your Information Security Management System Under ISO 27001:2013

By adopting the draft version of the standard, organizations will now have the ability to base the scope of their ISMS on the issues and objectives most meaningful to the organization’s risk environment.  The draft version takes into consideration the dependencies between the organization and third parties.  This is a critical component for organizations that have third party relationships (specifically data centers) that provide a key system or service to the organization.  Likewise, by adopting the draft version it is assumed that the organization will have a greater acceptance and understanding of scope limitations pertaining to third party relationships and dependencies.

See below for a comparison of the 2005 and 2013 versions of the standard:

27001:2005 Establishing the ISMS ISO 27001:2013 Context of the Organization
Define the scope and boundaries of the ISMS in terms of the following: 

  • characteristics of the business;
  • the organization;
  • its location;
  • assets and technology; and
  • details of and justification for any exclusions from the scope.
 Determine external and internal issues that are relevant to its purpose and that affect the ability to achieve the intended outcome of its ISMS. 

Determine interested parties that are relevant to the ISMS and their requirements relevant to information security.

Determine the boundaries and applicability of the ISMS to establish its scope and consider the following:

  • the previously determined external and internal issues;
  • the previously noted requirements of interested parties; and
  • interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations.

 

The draft version’s approach for defining the scope provides more directed guidance regarding necessary considerations which should ultimately formulate a more grounded scope.  This could potentially lead to a better defined implementation process for the foundations of their ISMS.  Organizations in the process of planning their ISMS or those that expect to undertake the project during the latter part of the year may have the opportunity to reassess their approach to implementation, should difficulties arise in defining the scope and/or potential scope creep.

What to do Today?

Organizations currently in the process of implementing an ISMS using the 27001:2005 standard may find it in their best interest to obtain and review the draft 27001:2013 standard so that the appropriate decision for the organization can be made.  In addition, please do not hesitate to contact BrightLine to schedule a call to discuss the ISO 27001 certification process and upcoming changes.  We are happy to provide your organization with a free consultation.

 

 

SocialTwist Tell-a-Friend

Tags: , ,
Posted in Compliance and Certification, ISO 27001 / 27002, News, Uncategorized | No Comments »

ISO 27001 Full Circle with Your Third Party Providers

Posted by Ryan Mackie
April 26th, 2012

My organization is seeking ISO 27001 certification but we outsource physical hosting to a third-party. 

How do I have to include that organization in the scope of my Information Security Management System (ISMS) when we are not responsible for those physical and environmental controls?

This question is common for organizations implementing an ISMS.  The struggle on how to treat a critical third party service provider occurs often when an organization is in the early stages of scoping their ISMS.  Some organizations attempt to scope the third party provider within their ISMS, which leads to difficulties when trying to treat the risks that might be applicable to a third party.  Other organizations take a more tolerant approach and “transfer” all applicable outsourcing risk to the third party service provider, without treating the risk at all.  The correct approach is actually somewhere in the middle.

Generally speaking, an organization must exclude a third party from their ISMS risk assessment process if the direct risks related to that third party cannot be reasonably treated by the organization.  For example, consider the physical access controls necessary to mitigate the risk that unauthorized access could be granted to production systems.  If the production systems are maintained at a third party data center, the organization is obviously not accountable for determining appropriate physical security controls, such as assigning access, granting access, monitoring access, and revoking access.

So, using the example described above, can the organization simply disregard consideration of these the issues under the guise that the third party data center is responsible for these risks and controls?  No.  As production systems would be considered a critical component of any organization’s ISMS, risk cannot be merely transferred to a third party.  There is inherent risk in any outsourced relationship and the greater the criticality to the ISMS, the greater the risk to the organization.  Management would be required to consider that risk and determine in what way that risk should be treated.

Controls applicable to the management and monitoring of third party service organizations are included within the ISO 27001 control set (specifically within A.6.2 and A.10.2).  While an organization cannot include the controls of a third party provider within their ISMS, they should have a process in place to evaluate and monitor the related third party provider controls to ensure that they are acceptably implemented and meet the expectations of the organization.  Evidence of that monitoring should be available as a record of the ISMS.

Though an organization’s certificate scope statement would not formally include the location and services of a third party provider, be sure that those services and locations would be included within the overall ISMS under the controls related to third-party management and monitoring.  Any appropriately designed ISMS must include a risk assessment process which considers risks related to the services provided by significant third parties such as data centers.

For more information about ISO 27001 visit BrightLine’s website.

SocialTwist Tell-a-Friend

Tags: ,
Posted in ISO 27001 / 27002, SSAE 16 / ISAE 3402 | No Comments »

Cloud Security Compliance – A Beautiful Mess

Posted by Ryan Buckner
January 28th, 2012

The following is a summary of thoughts based on an enthusiastic exchange at the Atlanta Chapter CSA Meeting on January 20th and was attended by BrightLine Shareholder Ryan Buckner.

First of all, I would like to say thank you to the host and the moderator for a truly fine job of creating this forum and to the attendees for their various perspectives.  The conference participants ran the gamut, and I was pleased to see representation from attorneys, accountants, consultants, and service providers.  As one would expect from the sizable audience, especially one with IT professionals, the conference demonstrated that the challenges the cloud community faces can be messy, but the conversations they spurn can be interesting and honest, and well …beautiful.

Much of the meeting brought to mind the old saying that “it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”  Our meeting was filled with various types of stakeholders, each with their own hammer.  The problem is that nobody seems to know if the problem is a nail.  As a practicing CPA and CISSP that manages over 100 SOC projects a year, I attempted to help provide clarity to the participants on SOC reporting topics.  There is still much work to be done in this area.  Others probably felt the same way about their respective “hammers”.

It felt premature to discuss solutions without the proper working groups.  I am also concerned that existing CSA research and guidance has not been given proper consideration.  If so, it would be pointless to waste time re-inventing CSA’s wheel or drafting solutions that are not in line with the general trajectory of CSA’s plans.

There was a healthy discussion on the usual compliance suspects with particular attention to the AICPA’s SOC reporting framework.  Although many seemed to have an opinion on this topic, I can report from the front lines that SOC 1 for cloud providers is prevalent and will remain that way so long as customers demand it.  My guess is that SOC 2 examinations make up less than 1% of all SOC examinations performed to date.  For that reason, I would be hesitant to hang my hat on it at this time.  But in a broader sense, I’m not convinced that the accounting industry should be the first place we look for solutions anyway.

Hopefully my contributions were helpful.  Certainly, the challenges are of the sort where more communication is probably better, and competence is a necessity.  It is clear the cloud community needs continued awareness, education, and sound guidance on these issues, and given that, the host’s efforts today are certainly part of the solution.  I was glad to attend, and look forward to the next discussion.

SocialTwist Tell-a-Friend

Tags: , , , ,
Posted in Assurance / Service Audits, Cloud Computing, ISO 27001 / 27002, SOC 1, SOC 2 | 1 Comment »

SOC 2 Guidance Observations and Attestation Update

Posted by Ryan Buckner
May 23rd, 2011

In October, I posted an article on the various alternatives for CPA attestation reports.   This past week, the AICPA issued its guidance on Service Organization Controls (SOC) 2 reports and an update to that post was in order.  Here is what the newly released SOC 2 guidance states:

  • In order to qualify as an SOC 2 examination, the scope of the assessment must include one or more of the Trust Services Principles.
  • The resulting reports are titled “Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality and Privacy”, with the actual title adjusted according to the selected principle(s).
  • Unlike SOC 1, SOC 2 reports are meant to meet a broader range of use cases where organizations provide services that do not impact their customers’ controls over financial reporting.
  • Like SOC 1 (SSAE 16) examinations, SOC 2 reports can assess subject matter as of a point in time (Type 1) or over a period of time (Type 2).
  • Like SOC 1 (SSAE 16), SOC 2 reports include an auditor’s opinion letter, management’s assertion letter, a system description, and in the case of a Type 2 report, the tests of controls.

Regarding the first bullet above, SOC 1 has the necessary flexibility to allow the audit firm to examine all of the controls in place that are likely to be relevant to the customers’ internal controls over financial reporting.

SOC 2 is more prescriptive and, at least in part, sets forth the subject matter of the assessment by requiring the use of the Trust Services Principles (i.e., Security, Availability, Processing Integrity, Confidentiality, and Privacy) that are selected by the service organization.  It could be said that the resulting SOC 2 report is a hybrid of the SysTrust examination scope and the SOC 1 reporting format.  Some exceptions do apply, whereby a service organization can be exempt from certain criteria and there is flexibility to include additional subject matter.

It is also worth noting that the AICPA SOC 2 guide includes a separate appendix relating to considerations for attestations of cloud computing providers; making reference to research and controls models published by the Cloud Security Alliance.

Service organizations considering any of the Service Organization Controls (SOC) reporting options should gain an understanding of the frameworks and resulting reports.  In many cases, service organizations are likely to conclude that multiple SOC reports are appropriate, especially when combined with ISO 27001 certification.

SocialTwist Tell-a-Friend

Tags: , , , , ,
Posted in Cloud Computing, ISO 27001 / 27002, SOC 1, SOC 2, SOC Reports, SysTrust | No Comments »

Does SSAE 16 Certified = FISMA Certified?

Posted by Douglas Barbin
March 15th, 2011

Introduction

Over the past few months, several clients inquired about how their SAS 70 and now SSAE 16 audit controls correlate to FISMA.  The specifically wanted to know how if there is a relationship that they could use to attract public sector clients as these agencies continue to adopt cloud computing models.

DISCLAIMER:   Before anyone gets too worked up, please note that 1) there is no such thing as “SAS 70 Certified” or “FISMA Certified”, and 2) every client who asked me this question already knew that the SOC 1 / SSAE 16 examinations and FISMA have virtually nothing to do with each other.

Our clients understand that the controls surrounding their service can impact the controls of their customers.  In the case of SSAE 16, the link is the controls likely to be relevant to the financial reporting of the customers.  In the case of FISMA, the like is the controls that impact a federal agency customer’s overall security program.

With that, below are some observations on FISMA and how a Service Organization Control (SOC) examination (a.k.a. SSAE 16 assessment or SAS 70 audit) can help a provider organize their control activities and assertions in preparation for doing business with the federal government.

The Pragmatic Auditor’s Observations

There is a widespread misconception that both examinations result in a certification.  For example, a recent client was even asked by an agency procurement officer if they were “FISMA certified.”  Of course, this is nothing new in the SAS 70 world where these misperceptions are widespread and have historically been included on procurement checkboxes regardless of whether or not they were actually needed.  See our previous article on this topic for further analysis.

A service organizations controls are their controls…PERIOD.  How they are organized, assessed, and presented will vary widely.  FISMA does not contain requirements for detailed security controls or implementation.  It only contains the high level security program requirements.  For all else, it defers to NIST.  The most common utilized standard for this reference is the Special Publication Series 800-53 on information security.

With this, an alignment of the existing control activities to NIST standards may help a service provider communicate its controls in a form that is preferable to public sector customers.  An SOC 1 report can be a starting point for the identification of controls relevant to public sector agencies.

Client Example

I recently went through an exercise like this with a managed service and hosting provider client.  They had a fairly extensive set of controls (over 100) that were tested for their Type 2 SAS 70.  Physical security, environmental controls, logical access, backups, and availability were the notable links to the more than 200 security baseline controls in appendix D of 800-53.  Other control areas such as customer support, provisioning, and general operations had no relevance to the NIST standard.  On the flip side, there were multiple areas of 800-53 such as crypto and application development that had no relevance to the service performed by the provider.

Key Findings:

  1. Is my client FISMA compliant or certified?  Nope.  They’re not an agency.
  2. Do they have controls which would be relevant to an agency customer undergoing their annual FISMA assessment?  Sure.  Some will meet the requirements, some may not, and some will not be applicable at all.
  3. How should they best present these controls to agencies?  Truthfully, it depends on the agency/customer.  One agency may want to see a specialized attestation.  Some may demand ISO 27001 certification.  Others may send their own auditors to have a look.  Frankly, FISMA itself is a moving target with introduction the Federal Risk and Authorization Management Program (FEDRAMP).

I simply reference SAS 70 audits and SSAE 16 assessments as they are one source of control activities documented within an organization.  Any other assessments such as PCI DSS or ISO 27001 and 27002 standards would assist as well.

Looking forward, I believe CloudAudit (www.cloudaudit.org) presents an opportunity for providers to organize and map their controls in a manner that allows them to slice and dice for the particular use case.  This group, which I am one of the leaders of, is about providing mechanisms to share common control data and assertions that span across multiple compliance requirements and use cases.

Most importantly, providers should be agile in their ability to communicate with agencies, auditors, and others who may seek out this information.

SocialTwist Tell-a-Friend

Tags: , , , , ,
Posted in ISO 27001 / 27002, SAS 70, SOC 1, SSAE 16 / ISAE 3402 | No Comments »

ISO 27001 Certification and PCI DSS 2.0 – Significant Achievements for Amazon

Posted by Douglas Barbin
December 15th, 2010

Over the past several months have been two key announcements from Amazon.  The first was that AMS achieved ISO 27001 certification.  The second was that it had undergone PCI validation.   Almost a month later these announcements continue to drive additional press including recent  articles from InformationWeek and one from Redmond Magazine.

The FAQs on the Amazon cite reference ISO 27001 certification for Amazon’s security program while PCI validation specifically cites: Amazon Elastic Compute Cloud (EC2), the Amazon Simple Storage Service (S3), Amazon Elastic Block Storage (EBS), and the Amazon Virtual Private Cloud (VPC).

Late last year Amazon was criticized for announcing that it had undergone a Type 2 SAS 70 audit without specifying what the underlying control objectives were.  While this is normal to an auditor who knows that SAS 70 reports are auditor to auditor communication, the security community wanted more specifics.  While not going to the degree of disclosing all of the its security controls to the public, Amazon has taken steps to leapfrog many of its competitors with respect to independent audits and certifications.

Key points when considering Amazon’s recent announcements:

  • Like all audits and certifications, the PCI DSS and ISO 27001 certification have defined scope.
  • In the case of PCI, the report on compliance (ROC) should include an explicit scope statement which defines what controls AWS is responsible for versus its customers.
  • The ISO 27001 certification is not as prescriptive as some may expect.  The certification focuses on the process of managing Amazon’s Information Security Management System (ISMS) and that it consider 133 controls that are listed in Appendix A of the ISO standard.
  • These 133 controls are aligned with the best practices laid out in the ISO 27002.  Many do not understand that ISO 27002 is a code of practice or guideline and not something that an organization can be certified against.

Still, this is a very significant milestone for Amazon.  If you look at the marketplace today, SAS 70 audits have become the price of entry.  Most cloud providers that handle data that impact their customers’ financial statements undergo a SAS 70 audit.  PCI was the next phase of adoption for providers wishing to service companies that handle cardholder data.  AWS has achieved both of these as well as ISO 27001 certification, a distinction held by very few organizations within the US.  In addition, they early adopted against the PCI DSS 2.0 standard which includes requirements to scope and assess any underlying virtualization technology that is in use.

SocialTwist Tell-a-Friend

Tags: ,
Posted in ISO 27001 / 27002, Payment Card Industry (PCI) Data Security | No Comments »

« Older Entries