What are the boundaries for ISO 27000?

I am curious what the boundaries are from a technology standpoint?  I was told that you could have many "trusted" connections to non ISO 27000 compliant entities and it would not affect the certification of the original environment.  It did not matter how these other environments were configured nor if they were ISO 27000 compliant.  I know with PCI and other such controls this would matter (one could have a stateful firewall dividing the environments for PCI - amongst other considerations).  It is obvious that if you had an open connection between environments that had poor security, it would represent a higher risk, but could such changes affect the certification of an environment from an ISO 27000 perspective?  While I have read through the controls and it seems wrong to me, I don't understand how the full certification process takes place.  My skepticism abounds.  Can you provide a link justifying your perspective?


Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
ISO 27000 looks at ISMS (info security mgmt system) with controls mapped to safeguard and reduce risk created by unnecessary ICT exposure to the system. People, technology and process are typical part of the controls and the recent 2013 version (2005 is older one)  takes over but the "new" inclusion I see is really the risk assessment emphasis. In specific, 27001:2013 (or even 2005) still covers the below
- establish a ready and updated understanding in your existing inventory of IT initiatives,
- ensure information availability and robustness in the control that are and should be in place
- follow consistent review cycle of ISMS implementation phases that is repeatable and governed with mgmt oversight.

Also know about 27001 vs 27002 http://www.experts-exchange.com/Security/Misc/Q_28548488.html

Risk assessment is the same for any standard and asset to protect is the surrounding objective for the writing and control are stipulated to be applicable, and relevant to them. PCI-DSS focus really on the Card Detail (CD) protection as compared to ISO27001 as latter look at asset of the data which is not necessarily only CD. There is a great deal in sieving out threat agent, associated vulnerability, derive the risk exposure level and identify the mitigation/remediation controls or measures. This works for all. Do not mix standard and security is not about compliance but is on being relevant and pragmatic to secure the critical asset with minimal risk exposure suited for the organisation risk appetite.

There is a good discussion (http://www.experts-exchange.com/Security/Digital_Forensics/Q_28589709.html) on the process and verification process that is the really meat for environment of what you mentioned. They can be extranet, intranet, internet, covert channel, overt channel etc. Mixture of environment create different risk but you will always start off with risk assessment, threat modelling to identify trust boundaries, divide and conquer to spread the measure determination to isolate and contain damages if breach happened - it is all in security designing.

But if you are saying to harmonisation standard - that is also done by all since they are grappling also to better say if I comply Standard A, is it complying Standard B or I should do A and B, or Standard C is more appropriate ... compliance can be an "devil" itself . Eventually clause match clauses and differs by the wording - see the table under "COBIT mapped with ITIL and ISO 27002" http://www.rwsp.org/projects/137-effectiveness-of-the-pci-dss-20-on-preventing-security-breaches.html

probably as reference catch ENISA - Shortlisting network and information security standards and good practices on survey gathered from many and good factor to catch is the below. There is no perfect security or silver bullet it all depends on the risk appetite and level up with the concurred action to take for a secure and safe service provision to your users and environment.

- Costs and benefits of implementing security baselines
- Major obstacles and difficulties in implementing different security measures

Pardon me if I have digress ...
bbaoIT ConsultantCommented:
first to clarify that i think you are referring to ISO/IEC 27000 SERIES, not the particular ISO/IEC 27000 standard which, as the first part of 27000 series, covers OVERVIEW and VOCABULARY only.

> It did not matter how these other environments were configured nor if they were ISO 27000 compliant.

YES. it means three points.

1. it is the certified body itself that became 27000 compliant, not the external bodies (other environments) directly or indirectly connecting to the certified body.

2. it is the certified body's responsibility to keep everything, including the interfaces to external bodies, in control according to what have been defined in the management system's quality manuals. be aware this is a dynamic process, a healthy quality system is always in a Plan-Do-Check-Action loop.

3. certificate itself is just a piece of paper demonstrating what the organisation did in the past and its overall competence when being reviewed. the competence shows the organisation is capable in KEEPING the system in a good condition, which means PDCA is always running, and any impact and/or risk from the environment should be well managed.

basically these three points can cover all your concerns, especially the 3rd one which seems to be confusing you much.

> but could such changes affect the certification of an environment from an ISO 27000 perspective?

as mentioned above, a good 27000 certified body has the capability to know the changes and modify its system accordingly. the environment is dynamic, the certified system is dynamic, TOO.

BTW, that's why any this kind of certificate should be reviewed and renewed timely.

> I don't understand how the full certification process takes place

basically a certification process is just to review an organisation's regulations in documents to make sure they meet all essential requirements of standard (27000 series here), then check the organisation's records to make sure what they have done meets what they said. that's it.
awakeningsAuthor Commented:

    Thank you for the responses.  If I may make a request, be very simple with me.  I do understand several compliance models, but I'm still wrapping my head around ISO 27K.  So Let me pretend that Environment A is ISO 27000 compliant and certified by BSI (or another authorized entity).  Environment A then connects to Environment B, C, and D. that are not ISO 27000 compliant or certified.  Let us assume that they are well below the ISO 27K standards.  Let us further assume that they open the flood gates and have network connections open between environments A, B, C, and D.  If the auditors come around the next time, would A still be ISO certified despite those extra control environments being much lower than Environment A.  To me there would be many gaps and the company would be at risk of losing its ISO 27000 certification the next time the auditors came around.  I want to know why my assumption is wrong.  What then happens if the lower compliant areas, start to use some of the same tools (email or IM for example), but lack things like change management, incident management, etc. etc.  I understand how to architect and design systems and programs that are compliant, but given that I was told that Environment A would remain certified the next time the auditors around despite no boundaries being set up between B, C, and D, I am confused how scope is set.  I can fully identify risk from B, C, and D, as well, but quantification of risk does not equal compliance.

   Am I making sense?  In short, can one certify one "system" as ISO compliant if all the ISO controls are met despite strong interconnections (Intranet, Extranet, Overt Channels, Covert Channels, etc. not even close to compliant.  I am left scratching my head.


Discover the Answer to Productive IT

Discover app within WatchGuard's Wi-Fi Cloud helps you optimize W-Fi user experience with the most complete set of visibility, troubleshooting, and network health features. Quickly pinpointing network problems will lead to more happy users and most importantly, productive IT.

btanExec ConsultantCommented:
If the auditors come around the next time, would A still be ISO certified despite those extra control environments being much lower than Environment A.
Env A is still certified at that point of time of checks (same as any compliance std, as good as that juncture) and in reference to the "gap analysis" based on “the relevant parts of the organization” relates to the scope of your intended certification. Threat landscape changes, you are not certified against those landscape but how effective the controls during the analysis is able to address the risk and gaps of the scope using the mgmt systems in place in safeguarding the information. So strictly speaking EnvA is still good ..note the assessment previously done should already covers all existing information types, systems, people, policies, processes, and technologies. It is certified till proven that there is significant changes in the ISMS to address new risk.

I want to know why my assumption is wrong.  What then happens if the lower compliant areas, start to use some of the same tools (email or IM for example), but lack things like change management, incident management, etc. etc.
As mentioned, if the risk of data leakage previously addressed using ISMS is well addressed e.g. end to end data and channel protected, it wouldnt matter if it is connected to any other network, as it is "unprotected" at the juncture of the intended destined recipient or system. Furthermore, certification should be not be implementation specific (these are means to end) as that is dynamic, instead it is process and scope focus. Unless the assessment is not comprehensive due to substantial gap identified cannot be addressed by EnvA existing ISMS controls (e.g. those of 27002), then it need to be reviewed again.

I was told that Environment A would remain certified the next time the auditors around despite no boundaries being set up between B, C, and D, I am confused how scope is set.  I can fully identify risk from B, C, and D, as well, but quantification of risk does not equal compliance.
This is as mentioned above already, it is as good as the scope and gap analysis at that juncture of assessment. Certification is not for life but a good state at the point of thorough agreement by auditor and your mgmt. It stands till it is proven otherwise insufficient, there should be review cycle as deemed by the environment exposure and have internal audit readily having regime to check and review the risk as ISMS changes with the landscape. Remember change is constant, hence furthermore there must not be mindset of "shoot and forget", you dealing with dynamic parameter such as environment, process, technology and people in context of ISMS.

Am I making sense?  In short, can one certify one "system" as ISO compliant if all the ISO controls are met despite strong interconnections
yes you can and strong stand come as you review again the cycle went through esp the gap analysis portion. Note the cyclic process of review the phases below "again" as due diligence and assurance it stand good even without certification and the change in the outside environment that "touch" your Env A. Remember the hard work in getting the processes in place, so even re-certify is going through the relevant phases again. ISMS is living thing.
- Get management support
- Define ISMS scope
- Inventory your information assets
- Conduct an information security risk assessment
- Prepare a Statement of Applicability / Prepare Risk Treatment Plan
- Develop ISMS implementation program
- Run the ISMS implementation program
- Operate the ISMS
- Collect ISMS operational artifacts
- Review compliance
- Undertake corrective actions
- Conduct a pre-certification assessment
- Certification audit

As a whole, note that the auditors check evidence such as those above and attempt to confirm that the ISMS remains suitable and sufficient to meet the organization’s information security requirements, and actually meets the requirements in practice. Controls already in place are not wasted. There maybe probably need improvements, if risk and gap surfaced significant.

At the end of the day, it is a matter of judgment as to whether the standard’s requirements are satisfied sufficiently to issue or renew a certificate.

Note that there should be periodic follow-ups (aka "surveillance audits”, or even CAVs “Continual Assessment Visits”) for as long as the organization chooses to maintain its certification.  The certificates is valid for three years so there is a formal re-certification every three years, but these additional interim reviews are common, especially in larger organizations. Assess if your ISMS changes are deemed substantial still as mentioned (repeatably above) to really warrant re-certification.

But I do see overall, it depends on several factors such as:
The scale or size of the change/s; nature or type of change/s; Likely impact of business and organizational changes on your ISMS and/or the must to re-validate the information security risks and treatments required; also has ISMS last certification or surveillance audit is too long before the next one comes; and changes to ISO policies as well...

The best advice is still to stay in touch with your certification body, keeping them updated with any (significant) changes and giving them the opportunity to say whether further surveillance visits or compliance audits are in order.  Build a good working relationship internally with your auditors and externally with the certification bodies engaged. There should not be any surprises for all. It is an informed decision.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bbaoIT ConsultantCommented:
basically, you are asking the exact same questions, again. obviously the answers are the same. :)
awakeningsAuthor Commented:

    Ok...  Now I get it.  It is starting to sink in.  It is similar to other standards, but not so much based specifically on technology, but process or programs.  So what I am hearing is risk may change which will affect how ISMS is performed as a result of those changes.  So specific boundaries are not as important with ISO as it is with other standards.  Other standards are data-centric so the architecture and processes need to be built around data flow.  So if Environment B is tacked onto Environment A and data was flowing through it, but it wasn't up to speed, it would affect the compliance of A overall.  I am used to auditors looking for any reason for scope creep to nail you with more audit findings.  This is not done with ISO 27K to the same degree.  It is also a "friendlier" report with the auditors than what I am used to.  I really want to thank you for taking the extra time to get the concept through my thick skull.  I learned a great deal and I appreciate it.  Thank you both.
awakeningsAuthor Commented:
Fantastic feedback!
btanExec ConsultantCommented:
Yap, ppl tend to be on the conservative side. Always ask 'will i be affected even when (not if) the "black swan" event happened" - be good to stand in your incident response and preventive measures. At strategic pt of boundaries identified, in fact it is becoming perimeter-less (think of portable device), there may be need to be prescriptive. So ISO may be too generic. For a more prescriptive and detailed in technical controls, you may want to check out NIST SP800-53 and its 53A which accompanies as a control assessment guide (53A). Good thing is they are free ... thks for the discussion.
awakeningsAuthor Commented:

     I know the 800 series controls very well.  I did FISMA: High for years (and the DISA STIGS).  The NIST SP series were constantly references in most of the frameworks I have worked with.  I've done a ISO 27K gap assessment and I've worked with many PCI folks on many projects including architecture and gap assessments, but not so much on ISO 27K boundaries.  The topic of boundaries has come up many times in the work I have been on so making clear distinctions is always important to me.  Now I've learned a bit more about the ISO 27k model.  I am getting there slowly!  Thanks again!
bbaoIT ConsultantCommented:
be aware that a certificate does not mean something assured forever, it is just a piece of paper showing the credit in the past and giving the confidence for today.

however, a certificate does NOT guarantee the future as things may change, including the environments which you concern most, and that's why the certified system must be running a PDCA loop and internal/external audits are also required in a time basis, which minimise internal and external risks, such as those you mentioned above.

it is a dynamic process, not static (which may cause the issues you worried about).
btanExec ConsultantCommented:
thanks all for sharing - change is the only constant, even standard are "living thing". Eventually we PDCA and able to stand confidently with our verifiable proven measures (and not just claims)
awakeningsAuthor Commented:

     You are beginning to sound like Heraclitian (from Heraclitus - the Greek philosopher of change) philosophers.  :)  "One can never step into the same river twice" is a known phrase from Heraclitus.  :)  But the point is well taken and understood for all compliance models about change being constant.  PDCA is common in many compliance models (even if they do not mention explicitly).  The 3 year cycle is something that surprises me for the certification as I was told the cycle could be 6 months for the audit.  I think now this person meant for PDCA and not the certification.

   Thank you very much for educating me.  The lessons are not falling on deaf ears.  :)

btanExec ConsultantCommented:
That is a good catch :-) Oops ... Just my last "words" (no worries)
There isn't a strict timeline per se for the re-certification. As long as the RTP and SOA and doc required major changes, or as shared the ISMS is undergoing some changes, there is need to review and decide the next move and maybe re-certification. Some info on the below
Continuous Improvement
It is important to understand that certification is not a one-off exercise. To maintain the certificate the organization will need to both review and monitor the information security management system on an on-going basis.
ISMS management should review risk assessments, the RTP, the SOA, and policies and procedures at least annually.
The 2005 version of the standard heavily employed the PDCA, Plan-Do-Check-Act model to structure the processes, and reflect the principles set out in the OECG guidelines (see oecd.org). However, the latest, 2013 version, places more emphasis on measuring and evaluating how well an organisation's ISMS is performing.
awakeningsAuthor Commented:
Thanks!  These are good resources!  I really appreciate it.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.