Security Advisor

10 Golden Security Rules

The ISO17799 is a group of policies that would be well worth your time to get to know.

• By Roberta Bragg
• 01/01/2002

A week before leaving for Australia I discovered that the airline I planned to use for travel within the country had gone into receivership and been grounded. Although my reason for travel was business, I’d planned to use the week after for a long put-off vacation and travel to Uluru, a famous, spiritually huge (or hugely spiritual) rock way off in the middle of nowhere, er... somewhere in the middle of Australia. OK, I admit it: my limited knowledge of Australia includes Crocodile Dundee; Steve Irwin, a.k.a the Crocodile Hunter; and Kanga from Winnie the Pooh (so the Hundred-Acre Wood didn’t exist in the Australian outback—but Kanga is a marsupial). Still, I expected there to be quick, alternative transport to my destination. There wasn’t. Trains and buses only travel in that direction once a week (and not directly). There was another airline, but I never got a seat. So, water bottle and vegemite sandwich in hand, I rented a car and drove some 3,000-plus miles round trip to see the sunrise over Uluru from camel back.

The Same, Yet Different
As I drove, all mellowed out by the scenery (or maybe it was the previous night’s good beer), I tried to analyze why I felt so comfortable, yet so exhilarated. I reasoned it was because everything was so different but so much the same. What made it that way was the adherence to the many standards and laws that span modern countries. Oh, the steering wheel was on the other side and I had to fight to remember to drive on the “wrong side” of the road, but there was a road with a center line painted down the middle. There were speed limits posted. There were fewer places to stop, but they were there; Australian roadhouses are sort of like a Quick Trip, Holiday Inn and Applebee’s all rolled into one, except there’s no franchise involved (and, thus, more personality) and no competition for hundreds of kilometers. There were rest stops with informative maps and warnings about cattle and kangaroos crossing the road (and plenty of dead ones in the morning being devoured by large buzzards that were unafraid of my approaching car).

All this got me thinking about how uncomfortable most of us are with the status of the security of our information systems and, especially, the security of systems belonging to others, which can endanger ours. “Standards,” I thought. “That’s the ticket.” Like rules of the road that keep us safe when obeyed, standards in security practices can save our butts when it comes to avoiding the potential compromise of our information systems. Standards won’t solve all our problems, but a lack of them only breeds more. This month, I’d like to tell you about one standard and ask: Are you following some standard code of practice for information-security management?

A Little Background
The security standard ISO17799 was originally prepared by the British Standards Institution as BS 7799, adopted by the Joint Technical Committee ISO/IEC JTC1, and approved by The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). BS 7799 was first published in 1995 as a code of practice (i.e. A common statement of procedures that would allow companies to develop, implement and measure security management). In 1998, key sections were changed to reflect an attempt to redirect its purpose to certification—a measurement against the code. In many instances this means the language was changed; instead of saying “should,” elements said, “shall.” In order to certify compliance, there have to be absolutes to measure against.

Many countries (Slovenia, Hungary, Scandinavia, South Africa, Australia and New Zealand) recognized and/or adopted BS 7799, making it internationally accepted prior to gaining official ISO status.

ISO17799 is still a “code of practice” and doesn’t currently contain the certification qualifications. It clearly doesn’t identify itself as the end-all and be-all. In fact, it identifies itself as “A starting point for developing organizational specific guidance.” You can read more about it at www.iso17799-web.com and purchase a copy of the standard at www.iso17799.net.

The ISO17799 Standard, after supplying generic information on defining goals and establishing a security policy, describes 10 security areas and lists practices for each area. The content varies from vague statements such as, “A policy is required…” to specifics like, “Passwords should be at least six characters long.” The comments below can’t replace the need to obtain and study the entire 100-page ISO17799 document, but they’ll give you a peek into the strategy it outlines. Note that the standard covers information security, not just information system security. More than computers must be involved if your security strategy is to work.

1. Security Policy
A policy is required; it should be set and approved and have the commitment and support of management. It also should include procedures for review and management of the policy itself. The policy document should be available to all employees and should include information such as:

• Importance of information security.
• Scope of the policy and support of management.
• Explanation of organizational security policies, how to comply with them, and the result of non-compliance.
• Specific information on tasks such as incident reporting.
• References to supporting documentation.

2. Organizational Security
Information security should be managed via a management framework that establishes how policy is approved, how security roles are assigned, and how security is implemented. Because all management shares responsibility, a forum or committee should be established to ensure clear direction, adequate funds and resources, and visible management support for the policy. This forum approves security policy; monitors changes in information system exposure (for example, changes to the Internet presence); reviews incidents and their handling; and approves security initiatives and their funding.

The forum may also approve access to external sources of security expertise and restrict contact to appropriate law enforcement, regulatory bodies and so on.

Other areas of organizational security include evaluating the risks of third-party access, including physical access to computer rooms and logical access to resources like databases. On-site contractor information access, third-party contracts and outsourcing are also relevant here.

3. Asset Classification and Control
All assets should be accounted for and have a nominal owner who’s responsible for it. Accountability should be assured. Assets include:

• Data in databases and files, system documentation, manuals, training materials, procedures and continuity plans.
• Software.
• Computer and communication equipment, tapes and disks, and auxiliary equipment.
• Services.

Information should be classified, labeled and handled appropriately according to classification.

4. Personnel Security
This doesn’t address user safety. Instead, it addresses the organization’s protection against user error, intentional abuse and fraud. It includes instructions on security responsibility definition, beginning at the recruitment stage and encompassing credit and background checks. Discussed is the need for confidentiality agreements, terms and conditions of employment, and user training on security policies and procedures.

5. Physical and Environmental Security
The goal here is protection from unauthorized access, damage and interference. The establishment of a physical security perimeter around business locations; entry controls; isolated delivery and loading areas; and the securing of cabling, UPSs, offices, rooms and facilities is discussed. Control requirements are listed for equipment so as to mitigate the risk of environmental issues, theft, electrical and chemical damage, secure disposal and offsite use.

6. Communications and Operations Management
Required documentation on procedures and processes should include:

• Documentation of all operations procedures.
• Documentation of all changes to equipment configuration and programs (change control).
• Incident management.
• Segregation of duties to reduce the risk of accidental or intentional system abuse or fraud.
• Separation of development and operational facilities.
• External facilities management.
• Systems planning and acceptance.
• Capacity planning.
• Protection and controls against malicious software.
• Information backup.
• Operator logs.
• Fault logging.
• Network management and controls.
• Media handling.
• Information handling.
• The security of documentation and specific areas is also covered, including:
• System documentation.
• Electronic commerce security.
• E-mail security, including compliance with data-protection legislation.
• Publicly available systems and how to protect them from modification using digital signatures.

7. Access Control
This is a long section of the document and one of the more specific. You may be doing many of these things already. For a complete listing you’ll need to read the standard, but here’s a sampling.

Documentation and enforcement of access controls for each user or group should be defined. Use the rule “what must be generally forbidden unless expressly permitted.” A few of the items discussed include the following:

• Use unique user IDs and make sure the level of access given to users is appropriate for the business purpose. There should be no sharing of accounts and no auto logon.
• Provide users with a written notice of their access rights and have them sign a statement indicating they understand access conditions.
• Immediately remove the rights of users that have changed jobs or left the country.
• Identify the privileges of each product, such as “OS” or “application.” Make sure they’re allocated on a need-to-use basis and, where possible, on an event-by-event basis.
• Assign privileges to different user identities based on the task performed. For instance, users should be doing normal business with a normal account and administrative functions with another.
• Temporary passwords should be communicated in a secure manner; no clear text.
• Review user access rights and privilege allocation at regular intervals.
• Change passwords regularly and when a possible compromise is indicated.
• The minimum length of a password should be six characters.
• Log off of a session before leaving the computer.
• Log off of the mainframe session when finished.
• Secure PCs with a key lock or other control (a password may be adequate in many cases).
• Allocate dedicated lines or telephone numbers.
• Prevent unlimited network roaming.
• Enforce the use of application and security gateways for external users.
• Use a firewall.
• Set up separate logical domains or a virtual private network for user groups.
• Remote connections should be protected by a cryptographic-based technique, token or challenge-response protocol.
• Use dial-back controls.
• Don’t use call forwarding.
• Ensure that disconnection on the organization side occurs.
• Authenticate access to the remote computer system.
• For a failed attempt, don’t indicate which part of the logon information is incorrect.
• Limit the number of unsuccessful attempts.
• Retain password history.
• Store passwords using a one-way encryption algorithm.

8. System Development and Maintenance
A development projects requirements statement should include necessities for controls, as well as the business value of information assets and the potential business damage due to the failure or absence of security.

Input data validation should include checks for out-of-range values, invalid characters in data fields, missing or incomplete data, the exceeding of upper and lower data volume limits, unauthorized or inconsistent control data, and the procedures for responding to these issues. Data balances should be validated, and data should be validated within the program.

The integrity of data and software (is the data received that which was requested?) should be checked. Message authentication (detecting corruption or changes to the contents of a transmitted message) should be performed.

An encryption/cryptographic/digital signature policy should exist that details when it’s necessary and how it will be accomplished.

Test data, wherever possible, should not consist of real data. Where real data must be used, it should be depersonalized before use, access controls should restrict access, the copy should be logged to provide an audit trail, and it should be removed immediately after use.

A system of change control, both to software and operating system configuration, should be established. This should include the evaluation of recommended changes such as operating system patches and provisions for updating business-continuity plans.

9. Business Continuity Management
A company should seek to identify the consequences of disasters, security failures and loss of service and should develop contingency plans. Risks should be understood in the terms of their likelihood. Regular testing, documentation and updates are required. Updates are required if there are changes in personnel, addresses or telephone numbers, business strategy, location, legislation and changes in contractors, suppliers and key customers.

10. Compliance
A company should avoid breaches of any criminal or civil law or contract. It should ensure the compliance with legal restrictions on the use of material, such as those protected by copyright, trademark or other restrictions. This includes the proper purchase and management of software licenses.

Provisions should be made for the safeguarding of organizational records, privacy of personnel information and the prevention of misuse.

Standards are Important
If you’ve been paying attention, you’ll note that many things listed in the standard are security policy statements you may have heard from many sources. I’ve talked about many of them in this column and at MCP TechMentor. The importance of this document is its comprehensive approach to information security and the agreement reached in an international body. If we all followed this policy, we might feel a little more comfortable when we have to drive down strange roads in the increasingly strange lands of the Internet.