SCOPE of ISMS

Hi all,



my company is ISO 9001 certified and we are currently working on
implementing an ISMS (ISO 27001).



We do have identified the processes which should be within the ISMS
scope and my question here is regarding the actual ISMS scope document
and ist required level of detail.



The structure I have in mind is as follows:



1. High-level executive summary of the ISMS scope

2. Responsibility for maintaining the scope document

3. ISMS Scope document change approval authority

4. Execution of ISMS scope document content

5. Review cycle of ISMS Scope document

6. Methods of defining the ISMS scope

7. Processes within the ISMS

7.1. Process 1: Name

7.1.1. Process 1: Reason why process is part of the ISMS

7.1.2 Process 1: Matrix: people involved in process and in what
function (decide, implement, etc)

7.1.3 Process 1: Locations and rooms where process is executed

7.1.4 Process 1: Key hardware needed for executing process

7.1.5 Process 1: Key IT-Applications/Software needed for executing
process

7.1.6 Process 1: Key communications technology needed for executing
process

7.1.7 Process 1: Key electronical and physical data needed for
executing process

7.1.8 Process 1: Key internal services/supporting processes needed
for executing process

7.1.9 Process 1: Key external services/supporting processes needed
for executing process

7.1. Process n: Name

7.n.1. Process n: Reason why process is part of the ISMS

7.n.2 Process n: Matrix: people involved in process and in what
function (decide, implement, etc)

7.n.3 Process n: Locations and rooms where process is executed

7.n.4 Process n: Key hardware needed for executing process

7.n.5 Process n: Key IT-Applications/Software needed for executing
process

7.n.6 Process n: Key communications technology needed for executing
process

7.n.7 Process n: Key electronical and physical data needed for
executing process

7.n.8 Process n: Key internal services/supporting processes needed
for executing process

7.n.9 Process n: Key external services/supporting processes needed
for executing process

8. Processes outside the ISMS

8.1. Process 1: Name

8.1.1. Process 1: Reason why process is not part of the ISMS

8.n. Process n: Name

8.n.1. Process n: Reason why process is not part of the ISMS

9. Version, Approval etc



I’d like to achieve the following: everybody in the company should get
a profound and clear understanding of the processes and underlying
assets within the scope and which ones are outside it. On the other
hand the scope document with its assets inventories should serve as
basis for the risk analysis.



As I don’t have any experiences I’d like to know if you think that
this approach is feasible.



What do you think? I’m looking forward to your replies,

Mat

Hello, Mat!

At first time we have designed a document for the ISMS scope description that had quite similar content, but then we desided to devide it into 3 seperate documents:

- ISMS description (contains several pages and includes high-level description of the ISMS scope - processes, people, assets, reasons why this scope was chosen and references to other 2 documents, mentioned below);

- asset inventory (for hardware, software, etc.);

- process description (detailed descriprion with diagrams of the processes in the ISMS scope).

We decided to separate them because asset inventory is rather dynamic (people leave their positions, software and hardware upgrades and so on) - so it will be reviewed and changed more often than other 2 documents. Also this separation allow us not to make the ISMS description extremely massive (for example, for top executives of the company it's not interesting to see how many servers are involved in the ISMS scope). One more detail - the ISMS scope description should not be a confidential document (because clients and partners should have a possibility to see it), that's why we decided not to inlude to much detailed information in it.

Best regards,

Anna



Hello,
I have an information security policy document that complies with the
requirements of ISO 27001 and then the following supporting policies:

Email AUP
Internet AUP
Clear Desk Policy
Software Policy
Unauthorised Access Policy
Antivirus Policy
Disposal of ICT Equipment Policy
ICT Procurement Policy
Information Asset Protection Policy
Information Backup and Storage Policy
Password Policy
Physical Security Policy
Removable Media Policy
Reporting Information Security Events Policy
Telephones Policy

Dear all,

System and user activities should be logged. In windows , we have system, security and application logs. What is captured in the logs depends on the organisation policy and the granularity , the organisation want to go.

In addition the organisation may also capture IPS, HIPS and Malware activities.

All these activities captured are events. Depending on the security policy and procedures , some of these events become security incidents and require incident handling and response.

Today , there are collation and correlation systems called Security event and information system which help in getting the logs from the various systems , collate it and correlate and declare as an incident.

Now coming to the vulnerability scanning and find a vulnerability. If it is proactive and part of scheduled vulnerability scanning and you find one server not patched . This could have happened because of change activity or patch was not applied at ll. This means patch management process was not thorough. If this is known vulnerability and should have been patched , then incident ticket be created , the incident be contained and patch applied through change management.

If it is new vulnerability , then the patch should be applied as part of change management . Incident ticket is not created for this case.

Best Regards

Ram

- Hide quoted text -

On Wed, Mar 10, 2010 at 11:58 AM, Gary Hinson <Gary@isect.com> wrote:

Hi Marck.

> However, there's still this subject of business continuity implied in
> the scope of security incident definition that leads me to confussion.

?? The security incident definition in ISO/IEC 27000 doesn't explicitly mention business continuity
per se.

"information security incident: single or a series of unwanted or unexpected information security
events (2.20) that have a significant probability of compromising business operations and
threatening information security (2.19)"

I guess you are referring to the phrase 'compromising business operations', which could be taken to
imply something about business disruption.

> Should only a disruption in business continuity which was caused by a
> security incident be reported in the incident reports of the
> organization?

Not exactly. Let's look at the '27000 definition in some detail. Noted follow.

The definition essentially states that events that have 'a significant probability' [A] of
'compromising business operations' [B] and 'threatening information security' [C], qualify as
information security incidents.

[A] 'Significant probability' includes both events that *definitely* do, or *most likely* will,
cause problems for the business as incidents. In other words, it is not absolutely essential to
know for certain that there have been significant impacts.

[B] 'Compromising business operations' is open to interpretation, but I believe the intended meaning
was that incidents are significant, damaging the organization in some meaningful way (i.e. causing
significant direct or indirect costs, value degradation, losses, disruption, damaged
reputation/brand or whatever), not just some trivial annoyance that has little real impact. (That's
the point I was making in my last reply.) Your interpretation may well differ from mine, and that's
cool: as I said, it's your call. Maybe others who are still with us on this thread would care to
comment, either way?

[C] Given that information security is formally defined in '27000 (as CIA, plus other factors),
'threatening information security' I believe is intended to include events that *threaten* to
compromise C and/or I and/or A (and/or the other factors), whether or not they *actually* damage
CIA+. For example, if some confidential personal or proprietary information is inappropriately
exposed on the Internet or in a plaintext email, whether the information is definitely compromised
(e.g. appears in the news headlines) or not, doesn't particularly matter: it may still be a serious
incident as far as the organization is concerned. Likewise if, say, a malware infection
*potentially* damages the integrity of data in an important database: the untrustworthiness of the
database after infection (whether or not it is known, for certain, to have been corrupted or
whatever) may cause real issues for the business, so this would count as an incident.

> My understanding is that a denial of service attack on our database
> servers qualifies as a business continuity security incident and
> should be registered.

Agreed, that is one single incident.

> However according to ISO 27001, should we register an unexpected error
> on those same database servers which was not caused by an related
> security issue and had effect on business continuity?

An "unexpected error" *does* sound like an information security event to me, contrary to your
statement that it "was not cause by an related security issue". If the "unexpected error" caused
some meaningful business problem, or had the potential to have done so, then yes this is indeed an
incident.

Don't get caught in the trap of thinking that "security" is all about deliberate attacks, hacks,
malware infections or whatever. It equally includes accidental, blameless causes such as bugs,
storms, fires and so forth. The important point is not how the event was caused, but how severe it
was and how much damage it caused. Try to keep that business focus in mind all the time. We are
not just securing stuff for the hell of it, but because the business needs it.

> Altough it's obvious that a business continuity plan is started as
> soon as the event affects normal operations of business , i am trying
> to understand if Incident Managament should keep track of such events.

The only situation I can think of where a business continuity plan might be invoked *not* in
response to a security incident, would be a BCP exercise or test, in which case the invocation is
deliberate and pre-approved by management. Management would only do this if they anticipated the
benefits of the exercise/test (namely the assurance from successful testing that it would actually
work properly if needed for real, and the personnel training value of exercising the plan)
outweighing the risks and costs such as business disruption caused by invoking the plan. If in fact
the exercise/test went horribly wrong, it could turn into an event, an incident or even a total
bloomin disaster if the costs far outweighed the benefits!!

Kind regards,
Gary

Gary Hinson
UPS is an oxymoron
www.NoticeBored.com Creative awareness materials

MORE