ISO 17799 BECOMES ISO 27002
===========================
Following the decision taken by ISO last year, ISO 17799 has finally
been renamed to ISO 27002. The change of name is simply that: a change
of name.
Logic Bomb Dangers Highlighted
==============================
The recent case of a former US Government contractor pleading guilty
to sabotaging Navy computers highlighted the need for constant
vigilance with respect to so-called 'logic bombs'.
Also known as 'slag code' and commonly associated with 'disgruntled
employee syndrome', a logic bomb is a piece of program code buried
within another program, designed to perform some malicious act. Such
devices tend to be within the province of technical staff
(non-technical staff rarely have the access rights and even more
rarely the programming skills required) and operate in two ways:-
1. 'Triggered Event' - for example, the program will review the
payroll records each day to ensure that the programmer responsible is
still employed. If the programmer's name is suddenly removed (by
virtue of having been fired) the Logic Bomb will activate another
piece of code to slag (destroy) vital files on the organization's
system. Smarter programmers will build in a suitable delay between
these two events (say 2-3 months) so that investigators do not
immediately recognize cause and effect.
2. 'Still Here' - in these cases the programmer buries coding similar
to the Triggered Event type but in this instance the program will run
unless it is deactivated by the programmer (effectively telling the
program - "I am still here - do not run") at regular intervals,
typically once each quarter. If the programmer's employment is
terminated unexpectedly, the program will not be deactivated and will
attack the system at the next due date. This type of Logic Bomb is
much more dangerous, since it will run even if the programmer is only
temporarily absent (eg through sickness, injury or other unforeseen
circumstances) at the deactivation point. The fact that it wasn't
meant to happen just then is of little comfort to organization with a
bombed system.
Logic bombs demonstrate clearly the critical need for audit trails of
activity on the system, as well as strict segregation of duties and
access rights between those staff who create systems (analysts,
developers, programmers) and the operations staff who actually run the
system on a day-to-day basis.
The History of The Information Security Standards
=================================================
Examination of the past often illuminates the present. This is
certainly the case in terms of untangling the different acronyms and
numbers associated with the information security standards.
The embryo of the security standards was actually a document published
by the UK Government's DTI in 1992. The was the 'Code of Practice',
for Information Security Management. This was subsequently upgraded by
BSI (the British Standards Institute) who published 'BS 7799-1 - Code
of Practice for Information Security' in 1995. BSI enhanced this
document, and also published a second part: BS7799-2, which was a
specification for security management, in the late nineties.
In 2000 ISO finally appeared on the scene, adopting BS 7799-1 and
renaming it to ISO 17799:2000. However, it wasn't until 2005 that they
eventually adopted BS7799-2, which became ISO 27001:2005. ISO 17799
was re-published in the same year, and as explained above, was renamed
to ISO 27002 in July 2007.
Also in 2005 BSI published BS7799-3. This is 'Guidelines for
information security risk management'. Again, the chances are that
this will eventually evolve into an ISO standard (possibly ISO 27005).
So we thus have:
ISO 27002:2005 - Code of Practice
ISO 27001:2005 - Specification for an ISMS
BS7799-3 - Risk Management.
It is not actually quite this simple though... because ISO are
attempting to 'normalize' their entire numbering system. They want all
their information security standards to be similarly numbered. That is
reasonable of course, but many would argue what is not reasonable is
simply to rename documents at a random point in time, rather than on
the next upgrade.
The full numbering intention is documented on the ISO 27000 Directory
(http://www.27000.org)
Information Ownership Issues
============================
It is essential that the ownership of information systems, data and
files is formally established within the organization. This formal
assignment invariably brings with it a more serious approach, 'top
down', to the whole issue of information security.
Historically, all electronic systems and data files were considered to
be "owned" by the IT department, but over recent years ownership has
correctly moved towards the areas or individuals who actually create
the information, or who are ultimately responsible for the data and
systems output.
Usually, the person who creates, or initiates the creation or storage
of the information, is the designated owner. In an organization,
possibly with divisions, departments and sections, the owner becomes
the unit itself with the person responsible being the designated
'head' of that unit.
The Information owner is normally responsible for ensuring:-
� that an agreed classification hierarchy is put in place and that
this is appropriate for the types of information processed for that
business / unit;
� that all information is classified and stored into the agreed types,
and that an inventory (listing) is created;
� that each document or file within each of the classification
categories, has its agreed (confidentiality) classification appended
to it.
� that for each classification type, the appropriate level of
information security safeguards are available (e.g. the logon controls
and access permissions applied by the Information Custodian provide
the required levels of confidentiality)
� that periodically there is a check to ensure that information
continues to be classified appropriately and that the safeguards
remain valid and operative.
If a designated owner of information leaves the organization, it is
important to ensure that a new owner or custodian is immediately
appointed to protect the approved levels of confidentiality and
approve or decline access requests.
Many organizations have seen a demonstrable improvement in the
cultural approach to security as a result of ownership clarification.
It is a move certainly long overdue for those whose IT departments are
still seen as data owners.
More ISO 17799/27001 Frequently Asked Questions
===================