10 Golden Security Rules
The ISO17799 is a group of policies that would be well worth your time to get to know.
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
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
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.
Does ISO17799 Compare to Common Criteria?
|The information system standard we’ve heard
more about in the U.S. is Common Criteria, or International
Standard 15408, a joint effort of security organizations
in the U.S., Canada, France, Germany, the Netherlands
and the United Kingdom. In the U.S., this replaces the
earlier standard known as the rainbow series (remember
C2 certification and the orange book?). While ISO17799
offers a security policy framework, or code of conduct,
Common Criteria is a standard that identifies and evaluates
security features of computer systems and products.
Common Criteria allows consumers to evaluate the relative
security readiness of products and determine if they
meet certain requirements. It also allows them to identify
risk. Developers can create products against a standardized
set of security requirements and determine the support
they’ll need to provide. Products are submitted for
evaluation against some level of the standard.
Windows 2000 Professional, Server and Advanced Server
are in the evaluation stage. See http://niap.nist.gov/cc-scheme/InEvaluation.html
for more information.
To learn more about this standard, visit http://csrc.nist.gov/cc/
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.
- Computer and communication equipment, tapes and disks, and auxiliary
Information should be classified, labeled and handled appropriately according
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
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
- 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,
- 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
- 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
- Use a firewall.
- Set up separate logical domains or a virtual private network for
- 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
- 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
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.
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