ISO17799 Newsletter - Issue 9

Welcome to the ninth issue of ISO 17799 News, designed to keep you abreast of developments and news with respect to ISO 27001, ISO17799 and information security.

The newsletter is absolutely free to our subscribers and provides guidance on various practical issues, plus commentary on recent Information Security incidents.

Included in this edition are the following topics:
1) Creating Information Classification Criteria
2) What is Information Security?
3) Standard Certifications
4) Disposal of Old and Obsolete Equipment
5) Section 11 - Getting Ready for BCP
6) ISO17799: a World Wide Phenomenon
7) ISO17799 Section 12: The Sarbanes-Oxley Act 2002
8) BCP Top Down
9) The FAQ: More Frequently Asked ISO17799 Questions
10) Controlling Changes to the Service Level Agreement
11) More ISO 17799 and Security Related Terms and Definitions
12) It Couldn't Happen Here.... Or Could It?

ESTABLISHING INFORMATION CLASSIFICATION CRITERIA
It is essential to classify information according to its actual value and level of sensitivity in order to deploy the appropriate level of security. A system of classification should ideally be:
- simple to understand and to administer
- effective in order to determine the level of protection the information is given.
- applied uniformly throughout the whole organization (note: when in any doubt, the higher, more secure classification should be employed).

With the exception of information that is already in the public domain, information should not be divulged to anyone who is not authorized to access it or is not specifically authorized by the information owner. Violations of the Information Classification Policy should result in disciplinary proceedings against the individual.

It is also sensible to restrict the number of information classification levels in your organization to a manageable number as having too many makes maintenance and compliance difficult. The following five levels of classification cover most eventualities:

Top Secret:
Highly sensitive internal documents and data. For example, impending mergers or acquisitions, investment strategies, plans or designs that could seriously damage the organization if lost or made public. Information classified as Top Secret has very restricted distribution indeed, and must be protected at all times. Security at this level is the highest possible.

Highly Confidential:
Information which is considered critical to the organization's ongoing operations and could seriously impede or disrupt them if made shared internally or made public. Such information includes accounting information, business plans, sensitive information of customers of banks (etc), patients' medical records, and similar highly sensitive data. Such information should not be copied or removed from the organization's operational control without specific authority. Security should be very high.

Proprietary:
Procedures, project plans, operational work routines, designs and specifications that define the way in which the organization operates. Such information is usually for proprietary use by authorized personnel only. Security at this level is high.

Internal Use Only:
Information not approved for general circulation outside the organization, where its disclosure would inconvenience the organization or management, but is unlikely to result in financial loss or serious damage to credibility/reputation. Examples include: internal memos, internal project reports, minutes of meetings. Security at this level is controlled but normal.

Public Documents:
Information in the public domain: press statements, annual reports, etc. which have been approved for public use or distribution. Security at this level is minimal.

Care should always be applied regarding a user's possible tendency to over classify their own work. It can sometimes be erroneously surmised that the classification level can reflect directly on the individual's own level of importance.

Asset classification is covered by Section 5 of the ISO17799 standard

WHAT IS INFORMATION SECURITY?
We are sometimes asked the most basic of information security question of all: "What is information security?". This can actually be surprisingly difficult to define. However, the introduction to the standard itself characterizes information security as the preservation of what is often known as CIA:

Confidentiality
Ensuring that information is accessible only to those authorized to have access

Integrity
Safeguarding the accuracy and completeness of information and processing methods

Availability
Ensuring that authorized users have access to information and associated assets when required.

It further explains that "information security is achieved by implementing a suitable set of controls", and that these need to be "established to ensure that the specific security objectives of the organization are met".

CERTIFICATIONS
Congratulations to all the following who we have recently added to our list of firms which have been certified with respect to BS7799 Part2 (now ISO 27001) for at least one system in at least one location: A3 Security Consulting; Atos Origin; Baltimore Technologies (Ireland); Mashreq Bank (UAE); Cable & Wireless; Hitachi; HMGCC; HM Land Registry; Misys Inernational Banking; Mitsue (Japan); Modulo Security (Brazil); Samsung; Fujitsu; Swiss Post; Total Network Solutions; Wipro Technologies (India)

More certifications will be listed in future issues.

DISPOSAL OF OLD OR OBSOLETE EQUIPMENT
"Equipment owned and/or used by the organization should only be disposed of in accordance with approved procedures including independent verification that the relevant security risks have been mitigated".

This is a policy that addresses with issues that should be considered when disposing of old computer hardware, either for re-cycle/scrap or use by others. An example of a security risk involved is that the hard disk inside a unit has not been completely or properly wiped out. A practical example of this is old EPOS equipment: old credit card information is saved onto the hard disk and if not erased properly prior to being disposed of could easily be accessed. In this scenario, a retailer with an EPOS system has a legal and ethical duty to its consumers to protect their data from fraudulent use.

When implementing a policy on the disposal of old computer equipment, a wide variety of issues and scenarios need to be considered, such as
- Legacy data from old systems can still remain accessible and thus compromise the confidentiality of information.
- Inadequate planning for the disposal and upgrade of entire systems can threaten business continuity and result in severe loss.
- Equipment used periodically but infrequently may be disposed of accidentally.
- The disposal of old equipment can prevent the restoration of its associated data files on which you may be relying.
- Breaches of health and safety requirements threaten the well-being of your staff and render you liable to prosecution.
- During the legitimate disposal of unwanted equipment other items can be 'lost' or stolen.

If any of these issues sound far fetched, think again. Our incident archive is packed with examples of serious problems resulting from uncontrolled disposal.

This topic is dealt with in various sections of ISO17799, including 7 and 8.

ISO17799 SECTION 11: PREPARING FOR THE BUSINESS CONTINUITY PROCESS
For a business continuity plan to be successful, it is important that all members of staff have been trained properly and understand the business recovery process. In order for people to understand what will be required of them, it is important that the training itself is planned and delivered to the people on a structured basis. It is less likely that people will misunderstand their roles and responsibilities if they are able to digest the information given to them in advance.

Certainly, for larger organizations a formal training plan should exist. This plan should outline the scope, objectives and activities and should be assessed to make sure it is relevant for the procedures involved.

An example of a training objective could be "To train all staff in the particular procedures to be followed during the business recovery process". An example of the scope for the training might be "The training must be carried out in a comprehensive and exhaustive manner so that staff becomes familiar with all aspects of the recovery process. The training will cover all aspects of the Business Recovery activities section of the BCP including IT systems recovery".

Not too sure where to start? A template approach such as that used by The BCP Generator (http://www.bcpgenerator.com) can actually help you to generate your company's business continuity plan from start to finish.

ISO 27001 and ISO 17799: THE WORLD WIDE PHENOMINON
The source list for the most recent purchases of the ISO17799 is always popular: Argentina 2
Australia 14
Austria 8
Bahrain 1
Barbados 2
Belgium 11
Bermuda 2
Bosnia and Herzegovina 1
Brazil 7
Brunei 1
Canada 92
Cayman Islands 1
Chile 6
China 3
Colombia 6
Costa Rica 1
Croatia 2
Cyprus 2
Denmark 13
Egypt 4
Estonia 1
Faroe Islands 1
France 11
Germany 44
Gibraltar 1
Greece 4
Guatemala 1
Hong Kong 9
Hungary 4
Iceland 1
India 8
Indonesia 5
Ireland 20
Isle of Man 1
Israel 2
Italy 30
Jamaica 2
Japan 8
Jordan 2
Korea 1
Lebanon 2
Luxembourg 1
Malaysia 6
Malta 1
México 16
Netherlands 27
New Zealand 5
Norway 15
Panama 1
Peru 1
Philippines 1
Poland 3
Portugal 5
R.O.C. 3
ROMANIA 2
Russia 4
Saudi Arabia 6
Singapore 12
Slovak Republic 1
Slovenia 3
South Africa 7
Spain 19
Sultanate of Oman 1
Sweden 9
Switzerland 40
Taiwan 5
Thailand 2
Tunisia 1
Turkey 3
UK 327
United Arab Emirates 5
USA 481
Venezuela 2

The same warnings apply as normal: these are online credit card sales only from one source.Those cultures that are less familiar with this form of commerce will be under represented.

ISO17799 SECTION 12: SARBANES-OXLEY ACT
The Sarbanes-Oxley Act was signed into law in the United States on July 30th 2002, and introduced highly significant regulatory changes to financial practice and corporate governance. It introduced stringent new rules with the stated objective: "to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws".

Because this act internationally significant as well, each future edition of ISO 17799 News will feature an area of the Sarbanes Oxley Act that focuses on a particular topic of interest. This issue covers Investigations and Disciplinary Proceedings.

The Executive Management and Board of Directors are required to establish procedures for the investigations and disciplining of registered public accounting firms, or any person associated with that firm, where they may be considered to have been in violation of the Act. The Board may:
- Request sight of all relevant audit work papers and associated documentation
- Request a written explanation from the registered firm on the matters being investigated
- Request written testimony from any clients of the registered firm that may have been involved in matters being under investigation, including issuing of subpoenas

In the event of non-cooperation with the inspection, the Board may carry out sanctions, including suspension or revocation of registration.

The Board is required to notify the Commission of impending investigations in order that the Commissions division of enforcement may be involved as appropriate.

The Board is to take care that all relevant information and documents are kept appropriately confidential in case such evidence is required in a state or federal court as part of criminal or civil legal due process. Such information may be made available to various government agencies provided these bodies maintain such information as confidential and privileged.

Employees of the Board involved in investigations are immune from any civil liability to the same extent as federal government employees.

This section also contains detailed information on the disciplinary process and the civil penalties that may be imposed, including suspension of a public accounting firm and barring association during this suspension with organizations regulated by the SEC. The Board is required to inform the Commission and any appropriate regulatory bodies and the public (after any stay has been lifted) on the application of sanctions.

More information on the SOA can be found at: http://www.sarbanes-oxley-forum.com

BCP/DRP IS NOT JUST AN ACADEMIC EXERCISE
The recent disastrous events in the United Kingdom and the United States, when the electricity supply was interrupted without warning, has emphasized the urgency of the need for all organizations to prepare a Disaster Recovery Plan. Disaster Recovery Planning (DRP) is essential for the continuation of key business services, in the event of an unexpected occurrence that seriously disrupts the business process.

One information security issue when initiating the plan is that there may well be a lack of commitment from the Board or top management to formalize the BCP/DRP in terms of development, and if this is the case, it is likely to result in an inadequate process. For the DRP project to be effective, it is advised that a structured process is followed when initiating the plan and that the Board or Governing Body itself actually approves the project initiation formally and ensures that their will be adequate resources available to manage the project.

The importance of this level of commitment from the very top cannot be over emphasized.

A risk assessment should then be carried out to analyze the DRP security threat and analyses the nature of such unexpected occurrences, the potential impact it may cause, and the likelihood of these occurrences becoming serious incidents.

ISO17799 & ISO 27001 FAQ: MORE FREQUENTLY ASKED QUESTIONS
1) What controls are considered by the standard to be essential to an organization from a legal viewpoint?
Many sections embrace and cover legislative issues, but the following 3 areas are specifically highlighted: data protection and privacy of personal information; intellectual property rights; safeguarding or organizational records
2) And what about from a common best practice viewpoint?
The following areas are highlighted: security policy document; assignment of security responsibilities; business continuity management; security education and training; reporting of security incidents
3) Who actually wrote the security standard?
Originally a BSI/DISC committee, which included representatives from a wide section of commerce and industry. It was subsequently reviewed by an International Standards Organization committee and emerged through the ISO publication process.
4) Can I republish articles from the ISO17799 Newsletter internally, or even on our external internet site?
Yes, subject to a link to this website.
5) Where can I discuss ISO 17799 with other people online (eg: a message board)?
ISO17799 Forums exists at: http://www.17799.com and http://groups.yahoo.com/group/iso17799security/

CONTROLLING CHANGES TO THE SERVICE LEVEL AGREEMENT
From time to time, it may be necessary for either the Supplier or the Client to require changes to the services being delivered or other aspects of the servive level agreement. These changes need to be carefully controlled and should be covered by an approved and detailed procedure. It is recommended that change requests are formalized and agreed between the parties. If the changes to the services are reasonably simple then only minor changes to service listings need to be agreed. If, however, the changes to the Services are fundamental or complex, they may also require changes to be made to broader aspects of the agreement itself.

Changes to the Agreement should be handled under agreed change control procedures. It is normally recommended, however, that the Client organization establishes some form of specific Steering Committee which will be responsible for controlling and monitoring the SLA and changes to the Services, service measurement criteria or the Agreement itself. The following process is fairly common:
- The nominated Client Representative should submit a Services Change Request (SCR) on behalf of the user department to the Supplier for consideration, review and costing.
- The Supplier should review the feasibility of the Services Change Request and provide an estimate of the time and work effort
- The Client Representative and the Supplier should jointly present the Services Change Request to the SLA Steering Committee
- The Steering Committee should consider the impact on contracts and agreements between the two parties and the budgetary issues
- Steering Committee is to approve or reject the Services Change Request.
- The Service Change Request, if approved, is then incorporated into the Service Level Agreement.

For a service level agreement template and pre-defined process covering SLAs see: http://www.service-level-agreement.net

NOTE: If you haven't got a formal service level agreement in place for your critical services... you should have!

ISO 17799 / ISO 27001 RELATED DEFINITIONS AND TERMS
In each newsletter we include a selection of definitions and terms to explain some of the jargon and language used by information security and IT professionals. In this issue, we have provided a selection of terms that all start with the letter 'P':

Pickling
Archiving a working model of obsolete computer technology so that a machine will be available to read old archive records which were created and stored using that machines' system. Reportedly, Apple Computers have pickled a shrink-wrapped Apple II machine so that it can read Apple II software (if necessary) in the future.

Polymorphic
Term used to describe a virus which changes itself each time it replicates in an attempt to hide from Anti-virus software.

Polling
Checking the status of an input line, sensor, or memory location to see if a particular external event has been registered. Typically used on fax machines to retrieve information from a remote source - the user will dial from one fax machine to another, then press the polling button to get information from the remote fax machine.

Proto-hacker
Individual who has risen above the tinkering Anorak level with aspirations to be a Hacker - but does not yet have the necessary skills to crack a major system. Can cause much damage by clumsy entry Hacking and blundering around the system corrupting files - albeit unintentionally. Proto-hackers may have marginally more technical skills than Anoraks but still display immaturity by leaving calling cards, messages, graphics, etc. As a result most of them are identified and caught before they graduate to being full Hackers

Protocol
A set of formal rules describing how to transmit data, especially across a network. Low level protocols define the electrical and physical standards to be observed, bit- and byte-ordering and the transmission and error detection and correction of the bit stream. High level protocols deal with the data formatting, including the syntax of messages, the terminal to computer dialogue, character sets, sequencing of messages etc. Some examples of protocols are: TCP/IP, the protocol used on the internet to send and receive information (HTTP is a subset of TCP/IP).

IT COULDN'T HAPPEN HERE....COULD IT?
Every issue of The ISO17799 Newsletter features at least one TRUE story of an information security breach and its consequences:

1) The 'Perfect' Business Continuity Plan
Yes, we have published this one previously - but it is our favorite true story!

A major financial institution took pride in its business continuity planning, and had in place what it considered to be a comprehensive plan of the highest quality. Indeed, the plan itself had been fully tested only days prior to the fateful incident.

On a quiet Sunday afternoon, the tranquility was disturbed by a large explosion in their main office block in the center of a large city. It was not a bomb or terrorist incident, but a serious gas explosion.

The company confidently swung the BSP into full effect, almost as quickly as the media hit town, to immediately discover something that the plan, as good as it was, had overlooked! The streets were full of paper from the office containing a wide variety of confidential customer information. Sensitive data was lying around for any passer by or observer to simply pick up and read.

For all the planning and testing, a single security lapse had cost them dear, as this aspect of the incident was reported again and again.

The moral of the story is of course that the office clean desk policy, and secure filing of confidential data policy, can actually prove to be extremely important!

2) A Simple One - But A common One
This one worked for years. The problem is that it still does!

A mainframe programmer in a large organixation thought it would be a hoot to collect the passwords of his colleagues and explore what they actually had filed under their own userids.

To achieve this, he wrote a very simple script to emulate the exact look of thestandard welcome screen for logon. The script didn't logon of course, instead it provided a duplicate of the user-id/password screen, and then filed the input provided by the user to a common area. Instead of then logging the user onto the system, it presented the 'System is not available' message. The user invariably got up and walked away at this point, enabling him to quickly retrieve the gathered authentication details.

Unfortunately, armed with a growing number of access details, he just could resist going further than just being nosey. He began to actively seek more information, first on himself, then on others. Realizing that he could do so apparantly anonymously, he was soon changing information. Quickly, he was out of control and was accessing and changing files almost every day.

He was only caught when someone spotted that the 'last logon' date for their account was clearly incorrect (they had only just returned holiday). Their report was taken seriously, and observation and investigation initiated.

Hardly surprisingly, his excuse that he was "only having fun" was not enough to save him.