Management guidance on network security

ISO/IEC TR 13335-5

TECHNICAL REPORT

Information technology Guidelines for the management of IT Security

Part 5: Management guidance on network security

TABLE OF CONTENTS

Foreword

Introduction

1. SCOPE

2. REFERENCES

3. DEFINITIONS

4. ABBREVIATIONS

5. STRUCTURE

6. AIM

7. OVERVIEW

7.1 Background

7.2 Identification Process

8 REVIEW CORPORATE IT SECURITY POLICY REQUIREMENTS

9 REVIEW NETWORK ARCHITECTURES AND APPLICATIONS

9.1 Introduction

9.2 Types of Network

9.3 Network Protocols

9.4 Network Applications

9.5 Other Considerations

10 IDENTIFY TYPES OF NETWORK CONNECTION

11 REVIEW NETWORKING CHARACTERISTICS AND RELATED TRUST RELATIONSHIPS

11.1 Network Characteristics

11.2 Trust Relationships

12 DETERMINE THE TYPES OF SECURITY RISK

13 IDENTIFY APPROPRIATE POTENTIAL SAFEGUARD AREAS

13.1 Introduction

13.2 Secure Service Management

13.2.1 Introduction

13.2.2 Security Operating Procedures

13.2.3 Security Compliance Checking

13.2.4 Security Conditions For Connection

13.2.5 Documented Security Conditions for Users of Network Services

13.2.6 Incident Handling

13.3 Identification and Authentication

13.3.1 Introduction

13.3.2 Remote Log-in

13.3.3 Authentication Enhancements

13.3.4 Remote System Identification

13.3.5 Secure Single Sign-on

13.4 Audit Trails

13.5 Intrusion Detection

13.6 Protection Against Malicious Code

13.7 Network Security Management

13.8 Security Gateways

13.9 Data Confidentiality Over Networks

13.10 Data Integrity Over Networks

13.11 Non-Repudiation

13.12 Virtual Private Networks

13.13 Business Continuity/Disaster Recovery

14 DOCUMENT AND REVIEW SECURITY ARCHITECTURE OPTIONS

15 PREPARE FOR THE ALLOCATION OF SAFEGUARD SELECTION, DESIGN, IMPLEMENTATION AND MAINTENANCE

16 SUMMARY

Bibliography

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.

The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.

In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report of one of the following types:

type 1, when the required support cannot be obtained for the publication of an International Standard, despite repeated efforts;

type 2, when the subject is still under technical development or where for any other reason there is the future but not immediate possibility of an agreement on an International Standard;

type 3, when the joint technical committee has collected data of a different kind from that which is normally published as an International Standard ('state of the art', for example).

Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to be reviewed until the data they provide are considered to be no longer valid or useful.

Attention is drawn to the possibility that some of the elements of this part of ISO/IEC TR 13335 may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

ISO/IEC TR 13335-5, which is a Technical Report of type 3, was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 27, IT Security techniques.

ISO/IEC TR 13335 consists of the following parts, under the general title Information technology Guidelines for the management of IT Security:

Part 1: Concepts and models for IT Security

Part 2: Managing and planning IT Security

Part 3: Techniques for the management of IT Security

Part 4: Selection of safeguards

Part 5: Management guidance on network security

Introduction

The purpose of this Technical Report (ISO/IEC TR 13335) is to provide guidance, not solutions, on management aspects of IT security. Those individuals within an organization that are responsible for IT security should be able to adapt the material in this report to meet their specific needs. The main objectives of this Technical Report are:

to define and describe the concepts associated with the management of IT security,

to identify the relationships between the management of IT security and management of IT in general,

to present several models which can be used to explain IT security, and

to provide general guidance on the management of IT security.

ISO/IEC TR 13335 is organized into five parts. Part 1 provides an overview of the fundamental concepts and models used to describe the management of IT security. This material is suitable for managers responsible for IT security and for those who are responsible for an organization's overall security programme.

Part 2 describes management and planning aspects. It is relevant to managers with responsibilities relating to an organizations IT systems. They may be:

IT managers who are responsible for overseeing the design, implementation, testing, procurement, or operation of IT systems, or

managers who are responsible for activities that make substantial use of IT systems.

Part 3 describes security techniques relevant to those involved with management activities during a project life cycle, such as planning, designing, implementing, testing, acquisition or operations.

Part 4 provides guidance for the selection of safeguards, and how this can be supported by the use of baseline models and controls. It also describes how this complements the security techniques described in Part 3, and how additional assessment methods can be used for the selection of safeguards.

Part 5 provides guidance with respect to networks and communications to those responsible for the management of IT security. This guidance supports the identification and analysis of the communications related factors that should be taken into account to establish network security requirements. It also contains a brief introduction to the possible safeguard areas.

Information technology Guidelines for the management of IT Security

Part 5:

Management guidance on network security

1. Scope

ISO/IEC TR 13335-5 provides guidance with respect to networks and communications to those responsible for the management of IT security. This guidance supports the identification and analysis of the communications related factors that should be taken into account to establish network security requirements.

This part of ISO/IEC TR 13335 builds upon Part 4 of this Technical Report by providing an introduction on how to identify appropriate safeguard areas with respect to security associated with connections to communications networks.

It is not within the scope of this TR to provide advice on the detailed design and implementation aspects of the technical safeguard areas. That advice will be dealt with in future ISO documents.

2. References

ISO/IEC TR 13335-1:1996, Information technology Guidelines for the management of IT Security Part 1: Concepts and models for IT Security

ISO/IEC TR 13335-2:1997, Information technology Guidelines for the management of IT Security Part 2: Managing and planning IT Security

ISO/IEC TR 13335-3:1998, Information technology Guidelines for the management of IT Security Part 3: Techniques for the management of IT Security

ISO/IEC TR 13335-4:2000, Information technology Guidelines for the management of IT Security Part 4: Selection of safeguards

ISO/IEC TR 14516:¹⁾, Information technology Guidelines on the use and management of Trusted Third Party (TTP) services

ISO/IEC 13888 (all parts), Information technology Security techniques Non-repudiation

ISO/IEC 15947:¹⁾, Information technology Security techniques IT intrusion detection framework

ISO/IEC 7498-1:1994, Information technology Open Systems Interconnection Basic Reference Model: The Basic Model

ISO 7498-2:1989, Information processing systems Open Systems Interconnection Basic Reference Model Part 2: Security Architecture

ISO/IEC 7498-3:1997, Information technology Open Systems Interconnection Basic Reference Model: Naming and addressing

ISO/IEC 7498-4:1989, Information processing systems Open Systems Interconnection Basic Reference Model Part 4: Management framework

(Other relevant, non ISO/IEC, references are given in the Bibliography.)

1)To be published.

3. Definitions

For the purposes of this part of ISO/IEC TR 13335, the definitions given in Part 1 of ISO/IEC TR 13335 apply: accountability, asset, authenticity, availability, baseline controls, confidentiality, data integrity, impact, integrity, IT security, IT security policy, non-repudiation, reliability, risk, risk analysis, risk management, safeguard, threat, vulnerability.

4. Abbreviations

EDI - Electronic Data Interchange

IP - Internet Protocol

IT - Information Technology

PC - Personal Computer

PIN - Personal Identification Number

SecOPs - Security Operating Procedures

TR - Technical Report

5. Structure

The approach taken in TR 13335-5 is to first summarize the overall process for identification and analysis of the communications related factors that should be taken into account to establish network security requirements, and then provide an indication of the potential safeguard areas (in doing so indicating where relevant content of other parts of TR 13335 may be used).

This document describes three simple criteria to aid those persons responsible for IT security to identify potential safeguard areas. These criteria identify (1) the different types of network connections, (2) the different networking characteristics and related trust relationships, and (3) the potential types of security risk associated with network connections (and the use of services provided via those connections). The results of combining these criteria are then utilised to indicate potential safeguard areas. Subsequently, a brief introductory description is provided of the potential safeguard areas, with indications

6. Aim

The aim of this document is to provide guidance for the identification and analysis of the communications related factors that should be taken into account to establish network security requirements, and to provide an indication of the potential safeguard areas.

7. Overview

7.1 Background

Government and commercial organizations rely heavily on the use of information to conduct their business activities. Loss of confidentiality, integrity, availability, non-repudiation, accountability, authenticity and reliability of information and services can have an adverse impact on an organizations business operations. Consequently, there is a critical need to protect information and to manage the security of IT systems within organizations.

This critical need to protect information is particularly important in today's environment because many organizations IT systems are connected by networks. These network connections can be within the organization, between different organizations, and sometimes between the organization and the general public. Both governmental and commercial organizations conduct business globally. Therefore they depend on all kinds of communication from computerized to other classical means. Their network needs have to be fulfilled, with network security playing an increasing significant role.

Clause 7.2 summarises the recommended process for the identification and analysis of the communications related factors that should be taken into account to establish network security requirements, and the provision of an indication of the potential safeguard areas. Subsequent clauses then provide further detail of this process.

7.2 Identification Process

When considering network connections, all those persons in the organization who have responsibilities associated with the connections should be clear about the business requirements and benefits. In addition, they and all other users of the connections should be aware of the security risks to, and related safeguard areas for, such network connections. The business requirements and benefits are likely to influence many decisions and actions taken in the process of considering network connections, identifying potential safeguard areas, and then eventually selecting, designing, implementing and maintaining security safeguards. Thus, these business requirements and benefits need to be kept in mind throughout the process. In order to identify the appropriate network related security requirements and safeguard areas, the following tasks will need to be completed:

review the general security requirements for network connections as set out in the organizations corporate IT security policy (see clause 8),

review the network architectures and applications that relate to the network connections, to provide the necessary background to conduct subsequent tasks (see clause 9),

identify the type or types of network connection that should be considered (see clause 10),

review the characteristics of the networking proposed (aided as necessary by the information available on network and application architectures), and the associated trust relationships (see clause 11),

determine the related types of security risk, where possible with the help of risk analysis and management review results - including consideration of the value to business operations of the information to be transferred via the connections, and any other information potentially accessible in an unauthorized way through these connections (see clause 12),

identify the references to the potential safeguard areas that may be appropriate, on the basis of the type(s) of network connection, the networking characteristics and associated trust relationships, and the types of security risk, determined (see clause 13),

document and review security architecture options (see clause 14),

prepare to allocate tasks for the detailed safeguard selection, design, implementation and maintenance, using the identified references to potential safeguard areas and the agreed security architecture (see clause 15).

It should be noted that general advice on the identification of safeguards is contained in Part 4 of TR 13335. This Part (5) of TR 13335 complements Part 4 and provides an introduction on how to identify appropriate safeguard areas with respect to security associated with connections to communications networks.

Figure 1 below explains the overall process of identification and analysis of the communications related factors that should be taken into account to establish network security requirements, and the provision of indications of potential safeguard areas. Each step of the process is described in further detail in the clauses following the figure.

Figure 1: Process for the Identification and Analysis of Communications Related Factors Leading to the Establishment of Network Security Requirements

It should be noted that, in Figure 1, the solid lines represent the main path of the process, and the dotted line where the types of security risk may be determined with the aid of results from a security risk analysis and management review.

In addition to the main path of the process, in certain steps there will be a need to re-visit the results of earlier steps to ensure consistency, in particular the steps Review Corporate IT Security Policy and Review Network Architectures and Applications. For example,

after types of security risk have been determined there may be a need to review corporate IT security policy because something has arisen that is in fact not covered at that policy level,

in identifying potential safeguard areas, the corporate IT security policy should be taken into account, because it may, for example, specify that a particular safeguard has to be implemented across the organization regardless of the risks,

in reviewing security architecture options, to ensure compatibility there will be a need to consider the network architectures and applications.

8 Review Corporate IT Security Policy Requirements

The organizations corporate IT security policy may include statements on the need for confidentiality, integrity, availability, non-repudiation, accountability, authenticity and reliability, as well as views on types of threat, and safeguard requirements, that relate directly to network connections.

For example, such a policy could state that:

availability of certain types of information or services is a major concern,

no connections via dial-up lines are permitted,

all connections to the Internet must be made through a security gateway,

a particular type of security gateway must be used,

no payment instruction is valid without a digital signature.

Such statements, views and requirements, being applicable organization-wide, must be accounted for in the determination of the types of security risk (see clause 12 below) and the identification of potential safeguard areas for network connections (see clause 13 below). If there are any such security requirements then these can be documented in the draft list of potential safeguard areas, and as necessary reflected in security architecture options. Guidance on the positioning of a corporate IT security policy document within an organizations approach to IT security, and on its content and relationships with other security documentation, is provided in Parts 2 and 3 of TR 13335.

9 Review Network Architectures and Applications

9.1 Introduction

Later steps in the process of moving towards the confirmation of potential safeguard areas, i.e. identification of the:

type(s) of network connection that will be used,

networking characteristics and associated trust relationships involved,

types of security risk,

and indeed the development of the list of potential safeguard areas (and later the related designs for securing a particular connection), should always be done in the context of the network architecture and applications that already exist or are planned.

Thus detail should be obtained of the relevant network architecture and applications, and reviewed, to provide the necessary understanding and context for the process steps that follow.

By clarifying these aspects at the earliest possible stage, the process of identifying the relevant security requirement identification criteria, identifying potential safeguard areas, and refining the security architecture, will become more efficient and will eventually result in a more workable security solution (see clauses 9.2 to 9.5 below).

At the same time, consideration of network and application architectural aspects at an early stage allows time for those architectures to be reviewed and possibly revised if an acceptable security solution cannot be realistically achieved within the current architecture.

The different areas that need to be considered under network architectures and applications include:

types of network,

network protocols,

network applications.

Some of the issues for review for each of these areas are discussed in clauses 9.2 to 9.4 below. Other considerations are introduced in clause 9.5.

(General guidance on network and application architectures can be found in ISO/IEC 7498.)

9.2 Types of Network

Depending on the area they cover, networks can be categorized as:

Local Area Networks (LAN), which are used to interconnect systems locally,

Metropolitan Area Networks (MAN), which are used to interconnect systems in a metropolitan range,

Wide Area Networks (WAN), which are used to interconnect systems in wider areas than MANs, up to a world wide coverage.

9.3 Network Protocols

Different protocols have different security characteristics and need to be afforded special consideration. For example:

shared media protocols are mainly used in LANs (and sometimes in MANs) and provide mechanisms to regulate the use of shared media among the systems connected. As a shared media is used, all information on the network is physically accessible by all connected systems,

routing protocols are used to define the route through the different nodes on which information travels within MANs and WANs. Information is physically accessible for all systems along the route, and routing may be changed, either accidentally or intentionally.

The protocols may be used on different network topologies, for example bus, ring and star, whether implemented through wireless or non-wireless technologies, which may have further impact on security.

9.4 Network Applications

The type of applications used over a network need to be considered in the context of security. Types can include:

terminal emulation based applications,

store and forward or spooler based applications,

client server applications.

9.5 Other Considerations

When reviewing the network architecture and applications, consideration should also be given to existing network connections within, to or from the organization, and to the network to which the connection is proposed. The organizations existing connections may restrict or prevent new connections, e.g. because of agreements or contracts. The existence of other connections to or from the network to which the connection is required could introduce additional vulnerabilities and thus higher risks, possibly warranting stronger and/or additional safeguards.

10 Identify Types of Network Connection

There are many generic types of network connection that an organization may wish to utilise. Some of these types of connection can be made through private networks (to which access is restricted to a known community), and some could be made through public networks (to which access is potentially available to any organization or person). Further, these types of network connection could be used for a variety of services, e.g. electronic mail or Electronic Data Interchange (EDI), and could involve use of Internet, Intranet or Extranet facilities, each with differing security considerations. Each of the types of connection may have different vulnerabilities and thus associated security risks, and consequently eventually require a different set of safeguards.

Table 1 below shows one way of categorizing the generic types of network connection that may be required to conduct business, with a descriptive example shown for each type.

Taking due account of relevant network architectures and applications (see clause 9 above), one or more of the types shown in Table 1 should be selected as appropriate to the network connection(s) being considered.

It should be noted that the generic types of network connection described in this document are organized and categorized from a business perspective rather than a technical one. This means that two different types of network connection may sometimes be implemented by similar technical means, and that in some cases the safeguards may be similar, but there are other cases where they will be different.

Table 1: Types of Network Connection

11 Review Networking Characteristics and Related Trust Relationships

11.1 Network Characteristics

The characteristics of the existing or proposed network should be reviewed. It is particularly important to identify whether the network is:

a public network - a network accessible by anyone, or

a private network - a network consisting of owned or leased lines, therefore considered to be more secure than a public network.

It is also important to know the type of data transported by the network, for example:

a data network - a network transferring primarily data and making use of data protocols,

a voice network - a network intended for telephone but also usable for data, or

a network encompassing both data and voice.

Other information, such as whether the network is a packet or switched network, is also germane.

Further, it should also be established whether a connection is permanent, or established at need.

11.2 Trust Relationships

Once the characteristics of the existing or proposed networking have been identified, and at minimum it has been established if the network is public or private (see clause 11.1 above), then the related trust relationships should be identified.

Firstly, the applicable trust environment(s) associated with the network connection(s) should be identified using the simple matrix shown at Table 2 below.

Table 2: Description of Trust Environments

Secondly the relevant trust environment(s) (from Low, Medium and High) should be related to the applicable network characteristic (public or private) and the type(s) of network connection involved (from clauses 10.1 to 10.6) to establish the trust relationships. This can be accomplished using the matrix shown in Table 3 below.

Table 3: Identification of Trust Relationships

From Table 3 the reference category for each relevant trust relationship can be determined. All of the possible categories are described in Table 4 below.

Table 4: Trust Relationship References

These references will be used in clause 12 to confirm the types of security risk and identify potential safeguard areas.

This task can be aided as necessary by the information available on network architectures and applications (see clause 9).

Determine the Types of Security Risk

As reflected earlier, the majority of organizations today are dependent on the use of IT systems and networks to support their business operations. Further, in many cases there is a definite business requirement for the use of network connections between the IT systems at each organizations location, and to other locations both within and outside the organization. When a connection is made to another network, considerable care should be taken to ensure that the connecting organization is not exposed to additional risks. These risks could, for example, result from the connection itself or from network connections at the other end.

Whilst network connections are important for business reasons, it has to be recognized that the use of these connections could yield additional security risks - some possibly related to ensuring adherence to relevant legislation and regulation. The types of risk reflected in this clause relate to concerns about unauthorized access to information, unauthorized sending of information, the introduction of malicious code, denial of receipt or origin, and denial of service connection. Thus the types of security risk that an organization might face are loss of:

confidentiality of information,

integrity of information,

availability of information and service,

non-repudiation of commitments,

accountability of transactions,

authenticity of information,

reliability of information.

Not all of the possible types of security risk will apply to every location, or to every organization. However, the relevant types of security risk need to be identified so that potential safeguards areas can be identified (and eventually safeguards selected, designed, implemented and maintained).

Information should be gathered on the implications to business operations related to the types of security risk referred to above (desirably from the results of a security risk analysis and management review [1]), with due consideration of related potential threats and vulnerabilities. If one or more of these is likely to have other than minor adverse impact on the business operations of the organization, then reference should be made to the matrix in Table 5 below.

It is emphasized that in completing this task, use should be made of the results from security risk analysis and management review(s) conducted with regard to the network connection(s). These results will enable a focus, to whatever level of detail the review(s) have been conducted, on the potential adverse business impacts associated with the types of security risk listed above, as well as the threat types, vulnerabilities and hence risks of concern.

The relevant trust relationship references determined from using clause 11 above should be identified along the top of the matrix in Table 5, and the impacts of concern on the left hand side of the matrix. The references at the pertinent intersections should then be noted these are the references to the potential safeguard areas that are introduced in clause 13 below.

Table 5: Types of Security Risk and References to Potential Safeguard Areas

It should be noted that the table appears to indicate that the more a user is trusted, the more controls are necessary. There are two reasons for this.

Firstly, there are a number of controls described in Part 4 of TR 13335 (and thus not repeated in this TR) that would be selected to protect the host IT facilities, including for identification and authentication, and logical access control. The configuration of the permissions (privileges) in the lower trust situations needs to ensure that access is only provided to resources that are consistent with the trust model and needs of the intended access. In low trust situations the strength of identification and authentication, and logical access control, safeguards (as described in Part 4 of TR 13335), needs to be higher than in high trust situations. If this cannot be assured, then relevant additional controls would need to be implemented.

Secondly, trusted users are usually given access to more important/critical information and/or functionality. This can mean a need for additional safeguards, as a reflection of the value of the resources accessed and not on the trust in the users.

Identify Appropriate Potential Safeguard Areas

Introduction

On the basis of the references identified from using clause 12, the potential safeguard areas should now be identifiable from clause 13. Clauses 13.2 to 13.13 introduce potential safeguard areas that should be selected as appropriate after use of clause 12 above. It should be noted that a particular security solution may in fact encompass a number of the potential safeguard areas introduced in clauses 13.2 to 13.13.

It should be noted that there are a number of safeguards that are relevant to IT systems whether or not they have any network connections. These safeguards should be selected through the use of Part 4 of TR 13335. It should also be noted that this TR assumes that baseline safeguards as described in Part 4 of TR 13335 would be in place for an organizations systems from which network connections are made.

This list of potential safeguard areas will need to be thoroughly reviewed in the context of the relevant network architectures and applications. It will then be used as the basis to prepare for the later allocation of detailed security safeguards selection, design, implementation and maintenance (see clause 15 below).

Secure Service Management

Introduction

A key security requirement for any network is that it is supported by secure service management activities, which will initiate and control the implementation, and operation, of security. These activities should take place to ensure the security of all of an organizations IT. With regard to network connections, management activities should include:

definition of all responsibilities related to the security of network connections, and designation of a security manager with overall responsibility,

documented system security policy, and accompanying documented technical security architecture

documented security operating procedures (SecOPs),

the conduct of security compliance checking, to ensure security is maintained at the required level,

documented security conditions for connection to be adhered to before connection to is permitted,

documented security conditions for users of network services,

a security incident handling scheme,

documented and tested business continuity/disaster recovery plans.

It should be noted that this clause builds upon aspects described in Part 4 of TR 13335. Only those topics that are especially important with regard to the use of network connections are further described in this document. For topics not mentioned further here, the reader should thus consult Part 4 of TR 13335.

Security Operating Procedures

In support of the system security policy, security operating procedures (SecOPs) documents should be developed and maintained. They should contain details of the day-to-day operating procedures associated with security, and who is responsible for their use and management.

Security Compliance Checking

For network connections, security compliance checking should take place against a comprehensive checklist constructed from the safeguards specified in the:

'system' security policy

related SecOPs,

technical security architecture,

security gateway service access (security) policy,

business continuity plan(s),

where relevant, security conditions for connection.

This should occur prior to live operation of any network connection, prior to a major new release (related to significant business or network related change), and otherwise annually.

Security Conditions For Connection

Unless security conditions for connection are in place and contractually agreed, an organization is in effect accepting the risks associated with the other end of a network connection.

As an example, organization A may require that before organization B can be connected to its systems via a network connection, B must maintain and demonstrate a specified level of security for its system involved in that connection. In this way A can be assured that B is managing its risks in a way that is acceptable. In such cases A should produce a security conditions for connection document that details the safeguards to be present at Bs end. These should be implemented by B, followed by that organization signing a binding statement to that effect and that security will be maintained. A would reserve the right to commission or conduct a compliance check on B.

There will also be cases where organizations mutually agree a security conditions for connection document which records obligations and responsibilities for all parties, including reciprocal compliance checking.

Documented Security Conditions for Users of Network Services

Users authorized to work remotely should be issued with a documented security conditions for users of network services document. This should describe user responsibilities for the hardware, software and data in relation to the network, and its security.

Incident Handling

Unwanted incidents are more likely to occur, and more serious adverse business impact to result, where there are network connections (as opposed to where there are none). Further, with network connections to other organizations in particular there could well be significant legal implications connected with incidents.

Thus, an organization with network connections needs to have a well documented and implemented incident handling scheme and related infrastructure in place to be able to respond quickly as incidents are identified, minimise their impact and learn the lessons to attempt to prevent re-occurrence.

Identification and Authentication

Introduction

It is important to ensure that the security of network service and related information is preserved by restricting access through connections to authorized personnel (whether internal or external to the organization). Requirements for these are not exclusive to the use of network connections, and thus detail appropriate to the use of a network connection should be obtained by using Part 4 of TR 13335.

Four safeguard areas that could be relevant to the use of network connections, and the IT systems directly related to such connections, are introduced in clauses 13.3.2 to 13.3.5 below.

Remote Log-in

Remote log-ins, whether from authorized personnel working away from the organization, from remote maintenance engineers, or personnel from other organizations, are accomplished either via dial-ups to the organization, Internet connections, dedicated trunks from other organizations, or shared access through the Internet. They are connections established at need by either internal systems or contractual partners using public networks. Each type of remote log-in requires additional safeguards appropriate to the nature of the connection type. Safeguard examples are:

not allowing direct access to system and network software from accounts used for remote access, except where additional authentication has been provided (see clause 13.3.3 below), and perhaps end-to-end encryption,

protecting information associated with e-mail software and directory data stored on PCs and laptops used outside of an organizations offices by its personnel, from unauthorised access.

Authentication Enhancements

The use of user id/password pairs is a simple way to authenticate users, but they can be compromised or guessed. There are other more secure ways to authenticate users, particularly for remote users. Authentication enhancements are needed when there exists a high possibility that an unauthorized person may gain access to protected and important systems. This may be, for example, because the access may be initiated using public networks, or the accessing system may be out of the direct control of the organization (e.g. laptop).

Where authentication enhancements over network connections are required (for example, by contract) or justified by the risks, an organization should consider strengthening the person authentication process by implementing relevant safeguards. Examples are:

using other means of identification to support the authentication of users, such as remotely verified tokens, smart cards and magnetic stripe cards (e.g. through readers attached to PCs), hand held one time pass key generation devices, dial-back modems, and biometric based facilities,

ensuring that the token or card can only function in conjunction with the authorized user's authenticated account (and preferably, that user's PC and location/access point) and, for example, any related Personal Identification Number (PIN) or biometric profile,

the use of caller line verification,

using links via modems that are disconnected when not in use, and only connected after verification of the callers identity.

Remote System Identification

As implied in clause 13.3.3 above, where relevant authentication should be enhanced by verification of the system (and its location/access point) from which external access is made.

It should be recognised that different network architectures can offer differing identification capabilities. Thus the organization may achieve enhanced identification by choosing an appropriate network architecture. All security safeguard capabilities of the chosen network architecture should be considered.

Secure Single Sign-on

Where network connections are involved, users are likely to encounter multiple identification and authentication checks. In such circumstances users may be tempted to adopt insecure practices such as writing down passwords or re-using the same authentication data. Secure single sign-on can reduce the risks of such behaviour by reducing the number of passwords that users have to remember. As well as reducing risks, user productivity may be improved and help desk workloads associated with password resets may be reduced.

However, it should be noted that the consequences of failure of a secure single sign-on system could be severe because not one but many systems and applications would be at risk and open to compromise (sometimes termed the keys to the kingdom risk).

Stronger than normal identification and authentication mechanisms may therefore be necessary, and it may be desirable to exclude identification and authentication to highly privileged (system level) functions from a secure single sign-on regime.

Audit Trails

It is important to ensure the effectiveness of network security through detection, investigation and reporting of security incidents. Sufficient audit trail information of error conditions and valid events should be recorded to enable thorough review for suspected, and of actual, incidents. However, recognising that recording huge amounts of audit related information can make analysis difficult to manage, and can affect performance, care has to be taken over time in what is actually recorded

Most audit safeguards required in relation to network connections and related IT systems can be determined by using Part 4 of TR 13335. For network connections, auditability of the following types of event is important:

remote failed log-on attempts with dates and times,

failed re-authentication (or token usage) events,

security gateway traffic breaches,

remote attempts to access audit trails,

system management alarms with security implications (e.g. IP address duplication, bearer circuit disruptions).

Audit trails will contain sensitive information or information of use to those who may wish to attack the system through network connections. Further, possession of audit trails may provide proof of transfer over a network in the event of a dispute, and are therefore particularly necessary in the context of ensuring integrity and non-repudiation. Therefore all audit trails should be appropriately protected.

Intrusion Detection

As network connections increase, it will become easier for intruders to:

find multiple ways to penetrate an organizations IT systems and networks,

disguise their initial point of access, and

access through networks and target internal IT systems.

Further, intruders are becoming more sophisticated, and more advanced methods of attack and tools are easily available on the Internet or in the open literature. Indeed, many of these tools are automated, can be very effective, and easy to use - including by persons with limited experience.

For most organizations it is economically impossible to prevent all potential penetrations. Consequently, some intrusions are likely to occur. The risks associated with most of these penetrations can be addressed through the implementation of good identification and authentication, logical access control and accounting and audit safeguards, together with an intrusion detection capability. Such a capability provides the means by which to predict intrusions, and identify intrusions in real-time and raise appropriate alarms. It also enables local collection of information on intrusions, and subsequent consolidation and analysis, as well as analysis of an organizations normal IT patterns of behaviour/usage.

In many situations it may be clear that some unauthorized or unwanted event is happening. It could be a slight degradation in services for apparently unknown reasons, or it could be an unexpected number of accesses at unusual times, or it could be the denial of specific services. In most situations it is important to know the cause, severity and scope of the intrusion as soon as possible.

It should be noted that this capability is more sophisticated than the audit trail analysis tools and methods that are implied in clause 13.4 above and the related clause of Part 4 of TR 13335. The more effective intrusion detection capabilities use special post-processors that are designed to use rules to automatically analyze past activities recorded in audit trails and other logs to predict intrusions, and to analyze audit trails for known patterns of malicious behaviour or behaviour which is not typical of normal usage.

For more detail the reader should refer to ISO/IEC 15947 - IT Intrusion Detection Framework.

Protection Against Malicious Code

Users need to be aware that malicious code may be introduced into their environment through network connections. Malicious code may not be detected before damage is done unless suitable safeguards are implemented. Malicious code may result in compromise of security safeguards (e.g. capture and disclosure of passwords), unintended disclosure of information, unintended changes to information, destruction of information, and/or unauthorized use of system resources.

Some forms of malicious code can be detected and removed by special scanning software. Scanners are available for firewalls, file servers, mail servers, and workstations for some types of malicious code. Further, to enable detection of new malicious code it is very important to ensure that the scanning software is always kept up to date, through at least weekly updates. However, users and administrators should be made aware that scanners cannot be relied upon to detect all malicious code (or even all malicious code of a particular type) because new forms of malicious code are continually arising. Typically, other forms of safeguard are required to augment the protection provided by scanners (where they exist).

Users and administrators of systems with network connections should be made aware that there are greater than normal risks associated with malicious software when dealing with external parties over external links. Guidelines for users and administrators should be developed outlining procedures and practices to minimise the possibility for introducing malicious code.

Users and administrators should take special care to configure systems and applications associated with network connections to disable functions that are not necessary in the circumstances. (For example, PC applications could be configured so that macros are disabled by default, or require user confirmation before execution of macros.)

Further detail on malicious code can be found in Part 4 of TR 13335.

Network Security Management

The management of any network should be undertaken in a secure manner, and indeed provide support for the management of network security. This should be accomplished with due consideration of the different network protocols available and related security services.

In furtherance of this, an organization should consider a number of safeguards, the majority of which can be identified through using Part 4 of TR 13335. In addition, remote diagnostic ports, whether virtual or physical, all should be protected from unauthorized access.

Security Gateways

A suitable security gateway arrangement will protect the organizations internal systems and securely manage and control the traffic flowing across it, in accordance with a documented security gateway service access policy (see below).

A security gateway should:

separate logical networks,

provide restricting and analysing functions on the information which passes between the logical networks,

be used by an organization as a means of controlling access to and from the organizations network,

provide a controlled and manageable single point of entry to a network,

enforce an organizations security policy, regarding network connections,

provide a single point for logging.

For each security gateway a separate service access (security) policy document should be developed and implemented for each such connection to ensure that only the traffic authorised for that connection should be allowed to pass. It must be possible to define permitted connections separately according to communications protocol and other details. In order to ensure that only valid users and traffic gain access from communications connections, the policy should define and record in detail the constraints and rules applied to traffic passing into and out of each security gateway, and the parameters for its management and configuration.

With all security gateways, full use should be made of available identification and authentication, logical access control and audit facilities. In addition, they should be checked regularly for unauthorized software and/or data and, if such is found, incident reports should be produced in accordance with the organizations security incident handling scheme.

It is emphasised that the connection to a network should only take place after it is checked that the selected security gateway suits the requirements of the organization, and that all risks resulting from such a connection can be managed securely. It should be ensured that by-passing the security gateway is not possible.

Data Confidentiality Over Networks

In circumstances where preservation of confidentiality is important, encryption safeguards should be considered to encrypt information passing over network connections. The decision to use encryption safeguards should take account of:

relevant government laws and regulations (especially where the network connection involves several countries or jurisdictions),

the requirements of key management and the difficulties that need to be overcome to ensure that real security improvements are achieved without creating significant new vulnerabilities, and

the suitability of the encryption mechanisms used for the type of network connection involved and the degree of protection required.

Data Integrity Over Networks

In circumstances where preservation of integrity is important, digital signature and/or message integrity safeguards should be considered to protect information passing over network connections.

Message integrity safeguards (for example using message authentication codes) are appropriate in cases where protection against accidental or deliberate alteration, addition or deletion of information is the prime requirement.

Digital signature safeguards can provide similar protection to message authentication safeguards, but also have properties that allow them to enable non-repudiation procedures (see clause 13.11 below). The decision to use digital signature or message integrity safeguards should take account of:

relevant government laws and regulations (especially where the network connection links several countries or jurisdictions),

relevant public key infrastructures,

the requirements for key management and the difficulties that need to be overcome to ensure that real security improvements are achieved without creating significant new vulnerabilities,

the suitability of the underlying mechanisms used for the type of network connection involved and the degree of protection required, and

reliable and trusted registration of users or entities associated with keys (certified where relevant) used in digital signature protocols.

Non-Repudiation

Where there is a requirement to ensure that substantive proof can be provided that information was carried by a network, safeguards such as the following should be considered:

communication protocols that provide acknowledgement of submission,

application protocols that require the originators address or identifier to be provided and check for the presence of this information,

gateways that check sender and receiver address formats for validity of syntax and consistency with information in relevant directories,

protocols that acknowledge delivery from networks, and

protocols that include mechanisms that allow the sequence of information to be determined.

Where it is important that information transmission or receipt can be proven should it be contested, further assurance should be provided through the use of a standard digital signature method. Senders of information, where proof of source is required, should seal the information using a digital signature to a common standard. Where proof of delivery is required, senders should request a reply sealed with a digital signature. To achieve this level of assurance the following should be considered:

use of non-repudiation mechanisms (digital signature, time stamping, etc.) supported by a trusted third party such as a certification authority, and associated public key infrastructure,

logging messages using mechanisms that prevent alteration of logs,

mechanisms to protect secret and/or private (signature) keys against unauthorised use, and

archiving any certificates or keys necessary to resolve disputes to ensure their availability and integrity for the required time (which may be longer that the period of use of the associated keying material).

Further information on non-repudiation protection is covered in TR 14516 and ISO/IEC 13888.

Virtual Private Networks

A Virtual Private Network (VPN) is a private network which is implemented by using the infrastructure of already existing networks. From a user perspective a VPN behaves like a private network, and offers similar functionality and services.

In VPNs, cryptographic techniques are used to implement security functionality and services, especially if the network on which the VPN is built on is a public network (for example, the Internet). In most implementations the communications links between the participants are encrypted to ensure confidentiality, and authentication protocols are used to verify the identity of the systems connected to the VPN. Typically, the encrypted information travels through a secure 'tunnel' that connects to an organisations gateway, with the confidentiality and integrity of the information maintained. The gateway then identifies the remote user and lets the user access only the information they are authorised to receive.

As for all private networks, it is very important to implement adequate security measures on all systems connected to a VPN, for example to ensure that only authorized links to other networks are possible.

A VPN may be used in various situations, such as to:

implement remote access to an organisation from mobile or off-site employees,

link different locations of an organisation together, including redundant links to implement a fall-back infrastructure,

set up connections to an organisations network for other organisations/business partners.

Business Continuity/Disaster Recovery

It is important that safeguards are in place to ensure the ongoing function of the business in the event of a disaster by providing the ability to recover each part of the business subsequent to a disruption in an appropriate time frame. Guidance on business continuity/disaster recovery planning as a whole, including the development of an appropriate business continuity/disaster recovery strategy and related plans, and their subsequent testing, can be obtained in Part 4 of TR 13335.

From the network connections perspective, it is the maintenance of those connections, the implementation of alternative connections of sufficient capacity, and the recovery of connections subsequent to an unwanted event, that have to be addressed. These aspects and requirements should be based on the importance of the connections to the functioning of the business over time, and the projected adverse business impacts in the event of a disruption. Whilst connectivity can afford many advantages to an organization, in the event of a disruption, in terms of flexibility and the ability to make use of creative approaches, they can also represent points of vulnerability and single points of failure, which could have major disruptive impacts on the organization.

Document and Review Security Architecture Options

The documentation of the possible security architecture options provides a means for the examination of different solutions, and a basis for trade-off analysis. This also facilitates the resolution of issues associated with technical constraints, and contentions between the needs of the business and for security, that will often arise.

In documenting the options, due account must be taken of any corporate IT security policy needs (see clause 8 above), the relevant network architecture and applications (see clause 9 above), and the list of potential safeguard areas produced according to clauses 12 and 13. In accomplishing this, account should be taken of any existing security architectures. Once the options have been documented and reviewed, the preferred security architecture should be agreed. Then, changes might result to the network and application architectures (to ensure compatibility with the preferred security architecture), and/or the list of potential safeguards (e.g. because it is agreed that the security architecture can only be technically implemented in a particular way, necessitating an alternative to an identified safeguard).

Prepare for the Allocation of Safeguard Selection, Design, Implementation and Maintenance

Using the list of potential safeguard areas (see clause 13 above), and the agreed security architecture (see clause 14 above), an organisation should commence preparations for the planning and allocation of tasks for the detailed security safeguard selection, design, implementation and maintenance.

Summary

This TR (Part 5) provides guidance to an organization connecting its IT systems to networks. The approach taken is to first summarize the overall process for identification and analysis of the communications related factors that should be taken into account to establish network security requirements. Then an indication of the potential safeguard areas is provided (in doing so indicating where relevant content of other parts of TR 13335 may be used). This TR then describes three simple criteria to aid those persons with responsibility for IT security to identify the potential safeguard areas. These are:

different types of network connections,

different networking characteristics and related trust relationships,

potential types of security risk associated with network connections and the use of services provided via those connections.

Then the selection criteria are reflected in a matrix used to indicate potential safeguard areas. Subsequently, a brief introductory description is provided of the potential safeguard areas.

Bibliography

IETF Site Security Handbook, of September 1997 (RFC 2196).

IETF Site Security Handbook Addendum for ISPs, of 15th August 1999.

NIST Special Publication 800-10: Keeping Your Site Comfortably Secure: An Introduction to Firewalls.