19.12.2012 Views

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Safeguard Catalogue - Organisation Remarks<br />

____________________________________________________________________ .........................................<br />

S 2.8 Granting of (application/data) access<br />

permissions<br />

Initiation responsibility: Head of <strong>IT</strong> Section, <strong>IT</strong> Security Management<br />

Implementation responsibility: Administrators; persons responsible for<br />

substantive tasks<br />

Such access permissions determine which person will, on the basis of his/her<br />

function, be authorised to use applications or data. <strong>The</strong> access permissions<br />

(e.g. read, write, execute) to <strong>IT</strong> applications, parts of applications, or data,<br />

depend on the function fulfilled by the given person, e.g. application<br />

supervisor, scheduler, system program, application developer, system administrator,<br />

auditor, data acquisition operator, desk officer. In any case, only so<br />

many access permissions as are required for task performance (need-to-know<br />

principle) should be granted. Enforcement of access rights must be through the<br />

administration of rights of the <strong>IT</strong> system.<br />

A variety of <strong>IT</strong> systems allow various privileges to be defined as group<br />

privileges or as profiles (e.g. data acquisition operators). This definition<br />

corresponds to the technical implementation of privileges allocated to a<br />

function. It is beneficial for the administration of the privileges of an <strong>IT</strong><br />

system to compile such groups or profiles, thus considerably simplifying the<br />

allocation and updating of privileges.<br />

<strong>The</strong> person responsible in each given case must arrange for, and document, the<br />

assignment of, and changes in, access privileges. Such documentation must<br />

show:<br />

- what function, in compliance with the separation of functions (cf. S 2.5<br />

Division of responsibilities and separation of functions), is provided with<br />

what access privileges;<br />

- which groups or profiles are in place;<br />

- what person performs what function;<br />

- the access privileges granted to a person; and<br />

- the conflicts entailed by the granting of access privileges to persons. Such<br />

conflicts may, for instance, result from incompatible functions being<br />

performed by one person or from the fact that, depending on the given <strong>IT</strong><br />

system, it is not possible to separate certain access privileges.<br />

Additional controls:<br />

- Does up-dated documentation on the granted access privileges exist?<br />

- Are requested access privileges or changes to granted access privileges<br />

being confirmed or verified by the responsible persons?<br />

- Is there a standard procedure for granting and revoking access privileges?<br />

<strong>The</strong> approach to the separation of functions and granting of privileges is<br />

illustrated in the following example.<br />

<strong>The</strong> <strong>IT</strong> application considered here is a system for travel expenses accounting.<br />

<strong>The</strong> relevant rooms are shown in the graph below. <strong>The</strong> <strong>IT</strong> system consists of a<br />

____________________________________________________________________ .........................................<br />

<strong>IT</strong>-<strong>Baseline</strong> <strong>Protection</strong> <strong>Manual</strong>: Oktober 2000

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!