White Paper Guide For Developing Security Plans

Guide for Developing
Security Plans for Internet Sites,
Intranets and Extranets
An interpretation of NIST SP 800-18 Guide for
Developing Security Plans for Information
Technology Systems.

William L. Dana , CISM, CISSP
Dana Enterprises, Inc.

April 2003

Revision 1 Page 1 of 35
April 2003

This document maybe freely redistributed in its entirety without alteration. It may not be sold for
profit or used in commercial documents without the written permission of Dana Enterprises, Inc.
This document is provided "as is" without any express or implied warranty.

While all information in this document is believed to be correct at the time of writing, this
document is for educational purposes. The information provided here is for reference use only
and does not constitute the rendering of professional advice or recommendations by Dana
Enterprises, Inc.

Copyright © 2003
Dana Enterprises, Inc.
www.danaenterprises.org

April 2003

Table of Contents

Acknowledgements ......................................................................................................................... 5
Executive Summary........................................................................................................................ 6
1 Introduction..................................................................................................................... 7
1.1 Background ..................................................................................................................... 7
1.2 Major Application, General Support System, Web Support System Plans .................... 7
1.3 Relationship to Other NIST Security Documents........................................................... 8
1.4 Purposes of Security Plans .............................................................................................. 8
1.5 Security Plan Responsibilities......................................................................................... 9
1.6 Recommended Format .................................................................................................... 9
1.7 Advice and Comment on Plan ........................................................................................ 9
1.8 Audience ......................................................................................................................... 9
2 System Analysis ............................................................................................................ 10
2.1 System Boundaries........................................................................................................ 10
2.2 System Category........................................................................................................... 10
2.2.1 Major Applications ....................................................................................................... 11
2.2.2 General Support System................................................................................................ 12
2.2.3 Web Support System..................................................................................................... 12
3 Plan Development ......................................................................................................... 15
3.1 Plan Control .................................................................................................................. 15
3.2 System Identification .................................................................................................... 15
3.2.1 System Name/Title........................................................................................................ 15
3.2.2 Responsible Organization............................................................................................. 15
3.2.3 Information Contact(s) .................................................................................................. 15
3.2.4 Assignment of Security Responsibility......................................................................... 16
3.3 System Operational Status ............................................................................................ 16
3.4 General Description/Purpose ........................................................................................ 16
3.5 System Environment ..................................................................................................... 16
3.6 System Interconnection/Information Sharing ............................................................... 17
3.7 Sensitivity of Information Handled .............................................................................. 17
3.7.1 Laws, Regulations, and Policies Affecting the System ................................................ 18
3.7.2 General Description of Sensitivity................................................................................ 18
4 Management Controls ................................................................................................... 20
4.1 Risk Assessment and Management............................................................................... 20
4.2 Review of Security Controls ......................................................................................... 20
4.3 Rules of Behavior.......................................................................................................... 21
4.4 Planning for Security in the Life Cycle ........................................................................ 21
4.4.1 Initiation Phase.............................................................................................................. 22
4.4.2 Development/Acquisition Phase ................................................................................... 22
4.4.3 Implementation Phase ................................................................................................... 22
4.4.4 Operation/Maintenance Phase....................................................................................... 23
4.4.5 Disposal Phase .............................................................................................................. 23
4.5 Authorize Processing .................................................................................................... 23
5 Operational Controls ..................................................................................................... 25
5.WSS Web Support System – Operational Controls................................................................... 26

April 2003

5.WSS.1 Personnel Security ......................................................................................................... 26
5.WSS.2 Physical and Environmental Protection......................................................................... 26
5.WSS.2.1 Explanation of Physical and Environment Security................................................... 27
5.WSS.3 Production, Input/Output Controls ................................................................................ 27
5.WSS.4 Contingency Planning.................................................................................................... 28
5.WSS.5 Hardware and Software Maintenance Controls ............................................................. 28
5.WSS.6 Data Integrity/Validation Controls ................................................................................ 29
5.WSS.7 Documentation............................................................................................................... 30
5.WSS.8 Security Awareness and Training .................................................................................. 30
5.WSS.9 Incident Response Capability ........................................................................................ 31
6 Technical Controls ........................................................................................................ 32
6.WSS.1 Identification and Authentication .................................................................................. 32
6.WSS.1.1 Identification............................................................................................................... 32
6.WSS.1.2 Authentication............................................................................................................. 32
6.WSS.2 Logical Access Controls (Authorization/Access Controls) ........................................... 33
6.WSS.3 Public Access Controls .................................................................................................. 34
6.WSS.4 Audit Trails .................................................................................................................... 34

April 2003

Acknowledgements
I would first like to express my thanks to NIST and to Marianne Swanson who originally drafted
and published NIST Special Publication (SP) 800-18, Guide for Developing Security Plans for
Information Technology Systems. Without that document we would not have the current standard
or guidance for creating security plans.

April 2003

Executive Summary

NIST Special Publication (SP) 800-18, Guide for Developing Security Plans for Information
Technology Systems, has become the standard used but most all government agencies to develop
security plans and the de facto standard for a number of private sector businesses. However, like
Security Plans, NIST SP 800-18 needs to be reviewed from time to time to reflect changes. In
1998 when the publication became available it covered the major systems of the day: the general
support system (GSS) and the Major Applications (MA). Since 1998 we have seen the
development of a third system that is a neither truly a GSS or a MA but a fusion of the two, the
Intranet and Extranet, which this document refers to as a web support system.

The objective of this document is to try and provide an interpretation of NIST SP 800-18 to
reflect this new system and help people classify and secure their intranets and/or extranets with
customized security plans that will meet the rigor and requirements of Office of Management
and Budget (OMB) Circular A-130 - Management of Federal Information Resources, Appendix
III - Security of Federal Automated Information Resources, Public Law 100-235 - Computer
Security Act of 1987, and the Federal Information Security management Act (FISMA) of 2002.

As this document is an interpretation of NIST SP 800-18 and sections of that document will be
present in this document as they appeared in that document. Due to the original thoroughness of
NIST SP 800-18 there is no need to recreate a process that has proven to be reliable and proven.
Instead, this document seeks to expand upon the original to cover a new need.

April 2003

1 Introduction

With the push for more security along with the mandate and push for federal agencies to become
more accessible to citizenry, the development of federal Internet, Intranet, and Extranet portals
have been on the rise. NIST SP 800-18 was put forth in 1998 to help provide federal agencies a
way to adopt a set of minimum controls to protect their information technology (IT) resources.
At that time the primary resources were where were defined as General Support Systems (GSS)
consisting of Mainframes, Local Area Networks, and Wide Area Networks, and Major
Applications. The Internet as a place of commerce and business was just beginning to take off as
a requirement for business and even for government.

As with NIST 800-18, this document puts forth an interpretation of NIST SP 800-18 to reflect
the distributed nature of today’s technology.

This document provides an interpretation of the NIST SP 800-18 guideline for federal agencies
to follow when developing the security plans that document the management, technical, and
operational controls for federal web support systems (WSS).

1.1 Background
The completion of system security plans is a requirement of the Office of Management and
Budget (OMB) Circular A-130, “Management of Federal Information Resources,” Appendix III,
“Security of Federal Automated Information Resources,” updated in 1996, Public Law 100-235,
“Computer Security Act of 1987,” and of the Federal Information Security Management Act
(FISMA) of 2002.

OMB Circular A-130, Appendix III, does not distinguish between sensitive and non-sensitive
systems. Rather, consistent with the Computer Security Act of 1987, the Circular recognizes that
federal automated information systems have varied sensitivity and criticality. All federal systems
have some level of sensitivity and require protection as part of good management practice. The
generic term “system” is used in this document to mean a major application, a general support
system, or a web support system. The generic term “web support system” is used in this
document to define an Internet Site, Intranet or Extrane t.

NOTE: This document will only discuss the web support system in detail. Please refer to NIST
SP 800-18 for information on the guidelines for major applications and general support systems.

1.2 Major Application, General Support System, Web Support System Plans
All applications and systems are required to be covered by system security plans when they are
categorized as a “major application” or “general support system”. While there is no debate about
that, the question is what about the extranet or intranet and even possibility the Internet presence
the organization has created. Are they a major application or a general support system? Web
support systems (Internet sites, Intranets and Extranets) are unique in that they are a combination
of both.

April 2003

The blur for web support systems (WSS) is that like a major application it is dependent on a GSS
to function however like a GSS the WSS maybe the support platform that a major application my
be dependent on to function and deliver content. Considering the adva nces in web development
and resources this blur has only continued to increase in that WSS’s may support there own
authentication systems that are integrated with the GSS’s or in some cases completely separate.

In section 1.2 of NIST SP 800-18 on page 1, the document defines and provides examples of a
major application and a general support system. Similarly, this document tries to provide a
definition of what a WSS and a test to try and help determine if an organization should develop a
separate security plan for their WSS. For not all Internet Sites, Intranets, or Extranets may need
to be classified as a WSS and can be covered by an existing GSS or MA plan that has been
developed.

1.3 Relationship to Other NIST Security Documents
This document currently has no official relationship to any other NIST Special Publication or
Security Document. It is meant to help supplement NIST SP 800-18 and continue to round out
the NIST triad of security guidance (NIST Special Publication 800-12, An Introduction to
Computer Security: The NIST Handbook (Handbook) and NIST Special Publication 800-14,
Generally Accepted Principles and Practices for Securing Information Technology Systems
(Principles and Practices)).

There is no requirement or mandate for any federal agency or any other person to use this
document. There is no relationship or recognition of this document to FISMA, OMB, or any
other federal regulation, law or agency charged with the oversight of federal information
technology security and none should be drawn.

The official NIST Special Publications and Security documents can be obtained from the NIST
Computer Security Resource Clearinghouse Web site at the URL: http://csrc.nist.gov/

1.4 Purposes of Security Plans

Security plans are created as part of an overall security framework and can be viewed as a road
map for continuing to improve the security stance for not only the system it covers but for the
entire organization.

Security plans help to:
• Provide an outline of security measures for a system;
• Describe what measures are in place and what is planned with target implementation
dates;
• Assign responsibility and accountability to those in charge of security measures; and
• Define responsibility and expected behavior of the system users.

April 2003

1.5 Security Plan Responsibilities
Ultimately it is the Chief Security Officer (CSO) that is responsible for the overall development
of security plan(s) for an organization. However, it is the system owner that was appointed or
designated by the CSO that is actually responsible for preparing, implementing, and monitoring
the security plan for a given system.

While the actual development, implementation, and monitoring of a system security plan maybe
outsourced to a contractor, the system owner is not relived of their responsibilities as the system
owner or system security officer. They are still responsible to ensure that the security plan is
maintained as a living document that is reviewed periodically for modifications and completion
of planned milestones and identification of new vulnerabilities. It is also important that the
system owner and/or security officer is familiar with the day to day use of the system and not
delegate security oversight to technical personnel that are meant to support or develop the
system.

1.6 Recommended Format
This document uses the same format that NIST SP 800-18 recommend when it was published in
1998. Regardless of whether the NIST SP 800-18 recommendation is used or a format
developed by your organization is used, the key point is that a standardized approach to
developing and maintaining security plans is used and the level of detail included is constant
with criticality and importance to the organization’s mission. Additionally, the security plan
should fully identify and describe the controls currently in place or planned for the system and
include a unique list of rules of behavior specific to that system.

1.7 Advice and Comment on Plan
No security plan can be adequately developed by one person or just by the system owner.
Advice and comment for the security plan should be sought from individual both within and/or
outside the organization. Inside the organization advice and comments should be sought from
management, organization policy, system administrators, system developers and system users.
Outside advice and comments about the plan should be sough once the plan is drafted and before
it is implemented. Outside advice is meant to be provide by individuals independent of the
system owner’s reporting chain that have adequate knowledge or experience to ensure the plan
contains appropriate information and meets organizational security policy and standards.

1.8 Audience
This document is intended to be a supplemental guide to NIST SP 800-18 and was drafted to
augment that document. This document is written for use by individuals with little or no IT
security experience and for use as an auditing tool. As with the NIST document, the concepts
presented here are generic and can be applied to organizations in public and private sectors.

April 2003

2 System Analysis
A completed security plan contains technical information about a system, security requirements,
and the controls implemented to protect a system against known risks and vulnerabilities. The
first step in developing a plan is determining what type of sys tem is to be done and what type of
plan is required for a system. This section walks the reader through the analysis of a system to
determine the boundaries of the system and the type of system.

2.1 System Boundaries
System boundaries are a logical binding of processes and IT resources. The elements within this
logical boundary constitute a single system requiring a security plan. For GSSs and MAs each
element of a system must, as defined in NIST SP 800-18:

• Be under the same direct management control;
• Have the same function or mission objective;
• Have essentially the same operating characteristics and security needs; and
• Reside in the same general operating environment.

For a WSS the same general elements apply, however there can be differences. With a WSS the
elements of a system must:

• Have essentially the same operating characteristics and security needs; and
• Reside in the same general operating environment.

However unlike the GSSs and MAs, WSS may have some elements to them that are:

• Under different direct management control;
• Have different function(s) or mission objective(s); and
• May reside in multiple operating environments.

For example a WSS is depended on a server that supports or offers web services (e.g., HTTP,
FTP, ASP). The server providing these services, are typically under the direct management
control of the LAN or Data Center operational unit. However, the actual web pages view by the
web users are developed and maintained by a different group. A WSS can also have
components that span multiple operating environments to provide the required services to
support a WSS.

2.2 System Category
System Category is where each system is determined either to be a GSS, a MA, or a WSS. All
systems and applications should be covered by a security plan. In some cases applications are
considered covered under the umbrella of a GSS. Major Applications have their own unique
security plan that is coordinated with the security plan of the GSS that supports the MA. A WSS
is similar here to a MA in that it should have its own security plan that also requires coordination
with a GSS security plan.

April 2003

2.2.1 Major Applications
A major application is an application that because of the information contained, processed, or
transmitted in combination with their criticality and importance to the organizations mission
require additional management oversight. Major applications are systems that perform a clearly
defined function(s) for an organization. Typically a major application is one that is used to
support a specific mission-related function (e.g., accounting systems, human resources
information systems, customer relation management systems). While in most cases a major
application is a single software application, there are also cases where multiple individual
applications that are all related to the accomplishment of a single mission function (e.g. payroll
systems, customer relations/customer complaint systems). When a system is defined as a major
application that is dependent on a general support system, the major application owner must:

• Notify the GSS system owner that the application is critical or contains sensitive
information and provide any additional security requirements that will be required of the
GSS;
• Request a copy of the system security plan of the general support system and ensure it
provides adequate protection for the application and information;
• Provide the major application’s security plan to the operator of the general support
system; and
• Include a reference to the general support system security plan, including the unique
name/identifier information in Section 3.5, System Environment.

2.2.1.1 Major Application Determination Guidance
The following guidance is designed to assist a system owner in determining if the application
should be considered a Major Application. If a system owner can answer yes to the following
questions typically the application in question should be considered a major application.

• Is the application used to support a mission wide goal or does it provide an internal
support functio nal that allows the organization to accomplish mission wide goals?
• Is the application accessed by employees on a daily basis?
• Can the organization function without access to the system for over a month or longer?

There are three other questions that a system owner needs to be able to answer in order to make
the final determination about an application.

• Is the application provided for use by another organization?
• Does your organization have the responsibility for configuring the application and
maintaining the application?
• Is the organization responsible for the certification and accreditation for the application?

If the application is provided to your organization by another organization and is maintained by
the other organization then while the application may be considered a major application, your

April 2003

organization may not be responsible for developing a unique security plan for the application.
When this is the case, discussions with the organization or group that is providing the application
should take place to determine exact responsibilities for your organization. Even though your
organization my not be responsible for a security plan, you still may want to develop a security
plan for additional assurance of system security. Not being responsible for developing a security
plan does not relive an organization of security concerns and instead require coordination of the
organizations security efforts to meet or exceed those in the security plan or connection
agreements for the application from the other organization.

2.2.2 General Support System
A general support system is easier to define and is typically an interconnected information
resources under the direct management control of a group within the organization, typically the
IT Department.

Examples of some general support system are:

• A Local Area Network
• A Wide Area Network
• A Wireless Network
• A Radio Network
• A Voice over IP Network

A general support system includes hardware, software, information, data, applications,
communications, facilities, and people that provides support for a variety of users and/or
applications.

2.2.3 Web Support System
A web support system is a hybrid of a general support system and a major application. Under
NIST SP 800-18 an organization may be covering parts of their Internet sites, intranets, or
extranets with their GSS security plan or major application security plan. Unfortunately this may
result in security vulnerabilities not being mitigated or properly recognized. A web support
system, for this document, is defined as the information technology resources providing web
services. A web support system includes the web/internet service software (not the operating
systems), the web content pages, and web applications. A web support system will prove to be
unique in that developing a security plan for a WSS is that it will most likely require a matrix of
personnel that cross departments (e.g. business units and members of the IT department) within
an organization to ensure the security of a WSS.

April 2003

2.2.3.1 Web Support System Determination Guidance
Just as not all applications should be considered major applications, the existence of an Internet
web presence, intranet, or extranet does not automatically mean that they should be considered a
web support system requiring its own security plan. The following guidance is designed to assist
an organization in determining if their Internet web presence, intranet, and/or extranet should be
considered a web support system.

If a system owner can answer yes to the following questions typical the application in question
should be considered a web support system.

Internet Web Presence
• Is the site accessible by anonymous access?
• Is the site content static?
• Does the site host any open applications for user to submit request without requiring a
user id/password combination?

If the answers to the first two questions is ‘yes’ and the last one is ‘no’, this system should not be
considered a web support system and continued to be covered under a GSS security plan.

Intranet
• Does the organization have an intranet available to its employees requiring a user
id/password combination to access?
• Does the intranet host web applications that allow the employees to interact the
organizations applications (e.g., personnel information submission to HR or HR systems,
time & attendance application)?
• Can the organization function for an extended period of time (i.e., a month) without the
Internet site without any noticeable impact on the organizations operations?

If the answers to the first two questions is ‘yes’ and the last one is ‘no’, this system should be
considered a web support system and a separate security plan developed for this system.

Extranet
• Does the organization have an extranet available to its clients/vendors requiring a user
id/password combination to access?
• Does the extranet host web applications that allow the users to interact the organizations
applications (e.g., supply chain)?
• Does the extranet support any mission critical processes or objectives?
• Can the organization function for an extended period of time (i.e., a month) without the
extranet without any noticeable impact on the organizations mission?

If the answers to the first three questions is ‘yes’ and the last one is ‘no’, this system should be
considered a web support system and a separate security plan developed for this system.

In many cases an organization may a combination of Internet web presences / Intranet / Extranet.
Having multiple systems that the above guidance indicates that it maybe desirable to have a

April 2003

separated security plan does not mean that each system should have an independent security
plan. Since these are all similar systems one consolidated security plan for all these systems can
be developed and any unique differences between them discussed in the plan.

April 2003

3 Plan Development
The rest of this document helps guide the reader in writing a security plan for a web support
system. For guidance on developing on security plans for general support systems and major
applications the reader should refer to NIST SP 800-18. This document only provides guidance
for a web support system security plan based on an interpretation of that publication.

3.1 Plan Control
All security plans should be considered sensitive in nature and the organization should protect
the document as required by the organization’s policies and not made widely available to
employees or the public. Additionally, all security plans should be placed under documentation
control and have revision marking and pagination information on each page to allow for updates
to the plan via change pages. A security plan should begin with the following system
identification sections.

3.2 System Identification
The first section of the security plan should provide the basic identifying information about the
system.

3.2.1 System Name/Title
List the unique name your organization has given to the web support system. For individual web
support systems this may be the name or URL of the intranet or extranet site. For a combined
plan, a generic title maybe chosen to encompass all the web presences the organization has.

3.2.2 Responsible Organization
The department or group with in the organization that is responsible should be listed here. This
section should include the organization name, department or group responsible, and the physical
address information.

If system maintenance is out sourced, this section should also list the name and address
information for the group maintaining the system.

3.2.3 Information Contact(s)
The information contact information should list the main points of contacts for this system. This
information should include contacts for the system owner(s), data owner(s), and GSS support
contact(s).

Include the name, title, physical address, phone number and e- mail address for all individuals.

April 2003

3.2.4 Assignment of Security Responsibility
One individual must be assigned responsibility in writing to ensure that the web support system
has adequate security. This person should be knowledgeable of the system and when possible
not be a system administrator or system developer. As with information contact, the name, title,
physical address, phone number and e-mail address for the individual assigned this
responsibility.

The person assigned this responsibility should be someone that has the ability and authority to
both oversee the development and maintenance of the web support system as well as being able
to interact with the IT support staff that will be maintaining the server(s) in the GSS that support
the web support system(s).

3.3 System Operational Status
Indicate the system’s operational status. A system can have multiple status selected, however
when more than one status is selected, this section should indicate which parts are in what status.
Additionally subsections for the security in the life cycle and specific controls for each part.

• Operational — the system is operating.
• Under development — the system is being designed, developed, or implemented.
• Undergoing a major modification — the system is undergoing a major conversion or
transition.

If the system is under development or undergoing a major modification, provide information
about the methods in place to assure that security requirements are included.

3.4 General Description/Purpose
Briefly describe in one to three paragraphs the function and purpose of the system (e.g.,
organization intranet, partner/customer extranet). A list of all web applications supported by the
web support system should be listed and if any are part of it area designated as a major
application or part of a major application. Additionally, list the name of the general support
system(s) that support the web support system (e.g., LAN). Include a list of user organizations,
whether they are internal or external to the system owner’s organization, and a general
description of the type of information and processing provided by the WSS for these groups.
Request information from both the general support system(s) owner and any application owners
(be sure to obtain a copy of the security plans) to ensure their requirements are met or are
sufficient for the general support system to support the needs of the web support system

3.5 System Environment
Briefly describe in one to three paragraphs the general description of the technical system. Any
environmental and/or technical factors that raise special security concerns should be included.
This section does not need to describe the details of the general support systems and should be
restricted to information specific to the web support system, such as:

April 2003

• Web Server Software Name, Manufacture, Revision, and Patch Level;
• Encryption and/or certificate technology;
• Reference the general support system that the web support system is dependent on;
• Scripting Languages supported (e.g., JavaScript, VBScript); and
• Any software specifically installed for functionality support on the web support system
(e.g., search engine software, chat room support).

This section should also include security software that has been installed assist in the protection
of the system and the information.

3.6 System Interconnection/Information Sharing
System interconnection information for a web support system is any connections that the
applications residing on the web support system make use of to call or process data. System
interconnections that are not documented and protected for a web support system can result in
these connections being compromised allowing the general support system or a major application
to be compromised.

OMB Circular A-130 states that there must be a written management authorization prior to
interconnection. For a web support system a Memorandum of Understanding should be created
for the interconnections that details the configuration of that interface.

For each system interconnection/information sharing connection provide the following
information:
• Interface Name;
• Organization owning the system being interfaced to;
• Type of interconnection (e.g., ODBC, audio/video streaming, etc.);
• Short description of any security concerns about the interconnection;
• Name and title of authorizing management official;
• Date of authorization;
• State if the interconnection is to a system of record;
• Sensitivity of the system being connected to;

This section should also include a description of how the web support system interfaces with
server authentication database(s) (e.g., Active Directory).

This section does not need to include a description about the general support system that the web
support system is dependent one. The system interconnection between the general support
system and web support system is understood as a dependency.

3.7 Sensitivity of Information Handled
Provide a description of the types of information handled by the system and an analysis of the
criticality of the information. The sensitivity and criticality of the information stored within,
processed by, or transmitted by a system provides a basis for the value of the system and is one

April 2003

of the major factors in risk management. The description must contain information on applicable
laws, regulations, and policies affecting the system and a general description of sensitivity as
discussed below.

3.7.1 Laws, Regulations, and Policies Affecting the System
List any laws, regulations, or policies that establish specific requirements for confidentiality,
integrity, or availability of data/information in the system. Each organization should determine
what laws or regulations are applicable to the system that should to be included in the security
plan. Examples might include:

• The Privacy Act;
• HIPAA;
• Section 508;
• E-Sign Act; and
• Gramm Leech Bliley Act.

Be sure to include any organizational policies, procedures, and/or handbooks that may be
applicable.

If the system processes records subject to the Privacy Act, include the number and title of the
Privacy Act system(s) of records and whether the system(s) are used for computer matching
activities.

3.7.2 General Description of Sensitivity
The general description of sensitivity reviews the system requirement against the need for
confidentiality, integrity, and availability. In addition to this, this section should also discuss the
system criticality.

3.7.2.1 System Criticality
Describe the systems importance in terms of mission supportive, mission important, or mission
critical.

3.7.2.2 System/Data Sensitivity
Describe the system in terms of confidentiality, integrity, and availability. In addition to this, the
general support system overall system sensitivity rating should be included.

An example of a system/data sensitivity section appears below:

Sensitivity
The sensitivity rating summarizes the sensitivity areas of the system. The overall system
sensitivity leve l is determined by the highest value in the Rating Column in the table below.
Therefore, the sensitivity level for the web support system is High Sensitivity.

April 2003

SENSITIVITY AREAS RATING
GSS HIGH
Confidentiality MEDIUM
Integrity HIGH
Availability HIGH

The criteria used to measure a system’s sensitivity include confidentiality, integrity, and
availability. The sensitivity areas for the web support system are described below.

Confidentiality - High
The system contains information that requires protection from unauthorized disclosure.

Integrity - Medium
The system contains information, which must be protected from unauthorized, unanticipated, or
unintentional modification.

Availability - High
The system contains information or provides services that must be available on a timely basis to
meet mission requirements or to avoid substantial losses.

For detailed examples and descriptions of sensitivity and rating confidentiality, integrity, and
availability, please refer to section 3.7.2, General Description of Sensitive on page 15 of NIST
SP 800-18.

April 2003

4 Management Controls
This section is where the management control measures that are in place or planned for the
protection of the system should be talked about. It is important that for any measures tha t are
listed as planned that a target implementation date is associated with that measure. This will
allow you to use this document to help track progress. For more detail on management controls,
see NIST Special Publication 800-12, An Introduction to Computer Security: The NIST
Handbook.

4.1 Risk Assessment and Management
Discuss the methods used to assess the nature and level of risk to the system. Discuss the current
known threats, vulnerabilities, and effectiveness of current safeguards to the system. Be sure to
include the date the last risk assessment was conducted and who performed the assessment. If
there has not been a risk assessment conducted for the system, one should be planned and the
milestone for conducting the assessment (month and year) included in this section.

With the visibility of the web support system(s) on the internet part of the risk management for
this system is know exactly what protocols and ports are being used by the system. This section
will also help outline the business need for have a port open or service available on a WSS. In
this section a discussion of services, ports, and protocols should incorporated.

Some points to consider in this discussion are:
• Does the systems support web-based e- mail access;
• What ports are used by the system (e.g., 80, 443, 21); and
• What protocols are supported (e.g. HTTP, HTTPS, SSL 2.0, FTP, NNTP, SMTP).

4.2 Review of Security Controls
An independent review of security controls for a system is required to be performed every three
years. In this section the findings and recommendations from the last review / risk assessment
should be discussed in summary fashion. This discussion should also discuss the organizations
response to the findings and recommendations. If there were any findings or deficiencies that are
reportable under OMB Circular A-123 they should be indicated here. For findings or
recommendations that require a long-term mitigation effort that was accepted by the
organization, target milestone dates for the completion of the mitigation process should also
indicated in this section.

While OMB Circular A-130, requires an independent review of security controls every three
years, organizations should also have an internal security review process. This section should
outline the other types of security evaluations that the organization conducts on their system,
aside from the independent review. Include brief description of each type of review performed,
who performs the review, and the output/actions from the review.

The purpose of security reviews are to provide verification that controls are working as intended
but also to ensure the system continues to adjust to new security threats. For a web support
system, reviewing the controls and countermeasures only every-three years exposes the system

April 2003

to a high risk of vulnerability of being breeched. New vulnerabilities, attacks, and malicious
code designed to exploit web support system are discovered on almost a daily basis. Given the
high visibility of web support systems, at least once every six to nine months the web support
system should be reviewed to ensure its security stance is as strong as possible. These six to nine
month reviews should primarily be focused on the technical and operational controls of the web
support system that can be conducted with tools like vulnerability scanners.

4.3 Rules of Behavior
The rules of behavior for a web support system are very different from rules of behavior for
either a general support system or a major application. Depending on what the web support
system provides function for, an organization may not be able to have a signed signature page
from a user. Additionally, as part of the rules of behavior of the web support system should also
contain a privacy policy that outlines what information the web support system may collect and
how that information is used.

Rules of behavior for a web support system should include the following:
• Password policy;
• Usage Monitoring;
• Privacy Statement;
• Information collect by the system (e.g., cookies, IP address, referring URL)
• Limitation on use of information published on the system;
• Limitation on changing/uploading/downloading of information on the system;
• Discussion of copyrighted information; and
• Discussion of consequences of noncompliance with the rules published.

The rules of behavior should be made available to every user prior to receiving authorization for
access to the system either on a request for access form and on a content page readily identifiable
and accessible on the web support system. Depending on the sensitivity of the web support
system will determine if this content page needs to have parts of displayed as part of a warning
page prior to access any content on the web support system

4.4 Planning for Security in the Life Cycle
Planning for Security in the Life Cycle of a web support system is possibly more critical than
with a general support system or a major application in that the web support system is publicly
available on the Internet. Web support systems can also end up supporting a variety of web
based applications that with different authentication and security system. The Life Cycle for a
web support system should be a guidance principle that is used to unify the way the web support
system grows and applications are developed or put in place.

In this section, determine which phase(s) of the life cycle the system, or parts of the system, is in.
Identify how security has been handled during the applicable life cycle phase. Depending on the

April 2003

Life Cycle model chosen by the organization to cover the web support system, it will most likely
consist of the five basic phased outlined below.

All five phases (or how ever many phases there are in the life cycle plan adopted by your
organization) should be discussed in this section regardless of what phase the web support
system is currently in.

The following NIST Special publications may provide the reader with additional guidance about
this life cycle process:

• NIST SP 800-23, Guideline to Federal Organizations on Security Assurance and
Acquisition/Use of Tested/Evaluated Products;
• NIST SP 800-27, Engineering Principle for Information Technology Security (A Baseline
for Achieving Security);
• NIST SP 800-44, Guidelines on Securing Public Web Servers.

4.4.1 Initiation Phase
During the initiation phase, the need for a system is expressed and the purpose of the system is
documented. For a web support system, the initiation phase can also be the strategic vision for
the life of the web support system.

4.4.2 Development/Acquisition Phase
During this phase, the system is designed, purchased, programmed, developed, or otherwise
constructed. This phase may consist of other defined cycles depending on the life cycle model
adopted by the organization.

During this phase, security requirements should be developed at the same time system planners
define the requirements of the system. These requirements may be expressed as technical
features or operational practices. This phase, include a general description of any specifications
that are used and how they are being maintained.

4.4.3 Implementation Phase
In the implementation phase, the system’s security features are configured, enabled, and the
system is installed and tested. A design review and systems test must be performed prior to
placing the system into operatio n to assure that it meets security specifications. Once that is
complete the system can be authorized for processing. (See Section 4.5, Authorize Processing,
for a description of that requirement.)

The results of the design reviews and system tests should be fully documented, updated as new
reviews or tests are performed, and maintained in the official organization records. If the system

April 2003

or parts of the system are in the implementation phase, describe when and who conducted the
design reviews and systems tests. Include information about additional design reviews and
systems tests for any new controls added after the initial acceptance tests were completed.

4.4.4 Operation/Maintenance Phase
During this phase, the system performs its work. Once in operation during the life of the system
it will face modification by the addition of hardware and software and updated content pages. As
the system undergoes modifications, determine which phase of the life cycle the system
modifications are in and describe the security activities conducted or planned for that part of the
system. For the system in the operation/maintenance phase, the security plan documents the
security activities.

The following high- level items should be described:
• Security Operations and Administration.
• Operational Assurance.
• Audits and Monitoring.

4.4.5 Disposal Phase
The disposal phase of the IT system life cycle involves the disposition of information, hardware,
and software. If the system or part of the system is at the end of the life cycle, briefly describe in
this section how the following items are disposed:
• Information. Information may be moved to another system, archived, discarded, or
destroyed. When archiving information, consider the method for retrieving the
information in the future.
• Media Sanitization. The removal of information from a storage medium (such as a hard
disk or tape) is called sanitization. Different kinds of sanitization provide different levels
of protection. A distinction can be made between clearing information and purging.
There are three general methods of purging media: overwriting, degaussing (for magnetic
media only), and destruction.

4.5 Authorize Processing
Authorization to process is the formal acceptance of management of the risk associated with a
system and allows the system to go into the production environment. In this section of the
security plan information about the name and title of the management official providing the
authorization to process and the date the authorization was granted. If the system has not yet
been authorized to process, include the name and title of the person requesting authorization, the
date of the request, and the name and title of the person the request was sent to.

Depending on your organization this may be part of the certification and accreditation process.
For more information about authorize to process see section 4.5 on page 24 of NIST SP 800-18.

April 2003

NIST SP 800-37, Guidelines for the Security Certification and Accreditation of Federal
Information Technology Systems may also help the reader to better understand the certification
and accreditation process.

Once a system is authorized to process, it should under go a process to be re-authorized prior to
any major system change and at the very least every three years as part of the independent
security review process.

April 2003

5 Operational Controls
This chapter and Chapter 6, Technical Controls, the formats and related guidance provided is for
the web support system. For information on the formats and related guidance for major
applications or for general support systems, please refer to NIST SP 800-18. The section
numbering of these two chapters differs from the rest of the document and follows the same
general numbering that was put forth in NIST SP 800-18. The chapters are numbered as 5.WSS
and 6.WSS for web support system. This number system was continued from NIST SP 800-18
to allow the user to easily combine the original NIST SP 800-18 along with this documents
interpretation for web support systems.

April 2003

5.WSS Web Support System – Opera tional Controls
Operational controls are the security methods are a mix of technical (system) and non-technical
(human) controls that work in concert to protect a system. This section describes the operational
control measures that are currently in place or measures that are currently planned to be or are in
the process of being implemented along with a target implementation date.

5.WSS.1 Personnel Security
Intentional and unintentional acts by individuals cause the greatest disruption to a system. Most
system disruption can be traced back to the well- meaning action of an individual authorized to
use the system (e.g., installation of a new patch without having tested the patch first).

This section should outline and provide the details about personnel security measures put in
place for the web support system.

• Have all positions been reviewed for sensitivity level? If all positions have not been
reviewed, state the planned date for completion of position sensitivity analysis;
• A statement as to whether individuals have received the background screening
appropriate for the position to which they are assigned. If all individuals have not had
appropriate background screening, include the date by which such screening will be
completed;
• If individuals are permitted system access prior to completion of appropriate background
screening, describe the conditions under which this is allowed and any compensating
controls to mitigate the associated risk;
• Is user access restricted (least privilege) to data files, to processing capability, or to
peripherals and type of access (e.g., read, write, execute, delete) to the minimum
necessary to perform the job;
• Are critical functions divided among different individuals (separation of duties) to ensure
that no individual has all necessary authority or information access which could result in
fraudulent activity;
• Is there a process for requesting, establishing, issuing, and closing user accounts;
• What mechanisms are in place for holding users responsible for their actions; and
• What are the termination procedures for a friendly termination and an unfriendly
termination.

5.WSS.2 Physical and Environmental Protection
Physical and environmental security controls are implemented to protect the facility housing
system resources, the system resources themselves, and the facilities used to support their
operation. Typically, the components of the web support system reside with LAN general
support system or where the data center is located. When that is the case this section becomes a
reference point to the general support system that houses the web support system. However, if
the web support system is housed outside the data center or server room for a general support
system then you must briefly describe the physical and environmental controls in place.

April 2003

5.WSS.2.1 Explanation of Physical and Environment Security
In this section, describe where the web support system is located or hosted at. For example:

Web support system that resides in the data center:
The web support system is co- located within the data center for Organization ABC. All physical
and environmental security is handled by the data center and is covered by the LAN General
Support System Security Plan.

Web support system that resides outside of the data center OR outsourced for hosting:
The web support system located on the 3rd floor at Organization ABC’s Headquarters.

When the web support system resides outside of the organizations data center or is outsource to
another organization to be hosted, this section must also include a discussion about the locations:

• Access Control;
• Fire Safety Factors;
• Failure of Supporting Facilities;
• Structural Collapse; and
• Interception of Data.

5.WSS.3 Production, Input/Output Controls
In this section, provide a synopsis of the procedures in place that support the web support
system. Below is a sampling of topics that should be reported.
• User support;
• Audit trails for receipt of sensitive inputs/outputs;
• Procedures for restricting access to output products;
• Procedures and controls used for transporting or mailing media or printed output;
• Internal/external labeling for appropriate sensitivity (e.g., Privacy Act, Proprietary);
• External labeling with special handling instructions (e.g., log/inventory identifiers
controlled access, special storage instructions, release or destruction dates);
• Audit trails for inventory management;
• Media storage vault or library physical and environmental protection controls and
procedures;
• Procedures for sanitizing electronic media for reuse (e.g., overwrite or degaussing of
electronic media);
• Procedures for controlled storage, handling, or destruction of spoiled media or media that
cannot be effectively sanitized for reuse; and
• Procedures for shredding or other destructive measures for hardcopy media when no
longer required.

April 2003

5.WSS.4 Contingency Planning
Web support systems require appropriate emergency, backup, and contingency plans. These
plans should be coordinated with the general support system that supports the web support
system. In the event of a failure, this contingency plan will be road map for how the web support
system is restored to service. This plan maybe very simple in that it relies on a GSS Contingence
Plan or have a very detailed plan separate from the GSS.

When reviewing the General Support Systems plan for adequate coverage or developing a web
support system specific plan, include the following:

• Is tested contingency plan in place to permit continuity of mission-critical functions in
the event of a catastrophic event;
• Is tested disaster recovery plan in place for all supporting IT systems and networks;
• Is formal written emergency operating procedure posted or located to facilitate their use
in emergency situations;
• How often are contingency, disaster, and emergency plans tested;
• Are all employees trained in their roles and responsibilities relative to the emergency,
disaster, and contingency plans;
• Include descriptions of the following controls;
• Any agreements for backup processing (e.g., hot-site contract with a commercial service
provider);
• Documented backup procedures including frequency (daily, weekly, monthly) and scope
(full backup, incremental backup, and differential backup);
• Location of stored backups (off-site or on-site);
• Generations of backups kept; and
• Coverage of backup procedures, (e.g., what is being backed up).

5.WSS.5 Hardware and Software Maintenance Controls
These controls are used to monitor the installation of, and updates to, the web support system to
ensure that the software functions as expected and that a historical record is maintained of
application changes. This helps ensure that only authorized software is installed on the system.
These controls may also be termed version control, change management, or configuration
Management. The following questions are exa mples of items that should be addressed in
Responding to this section:

• Was the application software developed in- house or under contract;
• Are any COTS applications installed and running on the web support systems (e.g., a
search engine);
• If a COTS product (or shareware), were sufficient licensed copies of the software
purchased for all of the systems on which this application will be processed;
• Is there a formal change control process in place for the application, and if so, does it
require that all changes to the application software be tested and approved before being
put into production;
• Are all changes to the application software documented;

April 2003

• Are test results documented;
• How are emergency fixes handled;
• Are there organizational policies against illegal use of copyrighted software or shareware;
• Are there restriction/controls on those who perform maintenance and repair activities;
• Procedures used for items serviced through on-site and off-site maintenance (e.g., escort
of maintenance personnel, sanitization of devices removed from the site);
• Procedures used for controlling remote maintenance services where diagnostic
procedures or maintenance is performed through telecommunications arrangements;
• Describe the configuration management procedures for the system. Consider the
following items in the description:
o Version control that allows association of system components to the appropriate
system version;
o Procedures for testing and/or approving system components (operating system,
other system, utility, applications) prior to promotion to production;
o Impact analyses to determine the effect of proposed changes on existing security
controls to include the required training for both technical and user communities
associated with the change in hardware/software;
o Change identification, approval, and documentation procedures; and
o Procedures for ensuring contingency plans and other associated documentation
are updated to reflect system changes.
• Do the policies contain provisions for individual and management responsibilities and
accountability, including penalties;
• What products and procedures are used to protect against illegal use of software; and
• Are software warranties managed to minimize the cost of upgrades and cost
reimbursement or replacement for deficiencies.

5.WSS.6 Data Integrity/Validation Controls
Integrity controls protect the operating system, applications, and information on the web support
system from accidental or malicious alteration or destruction and to provide assurance to the user
that the informatio n has not been altered. A web support system may have its own set of
controls that work in conjunction with the controls in place on the general support system.

The following questions are examples of some of the controls that a web support system may
make use of:
• Is virus detection and elimination software installed? If so, are there procedures for:
o Updating virus signature files;
o Automatic and/or manual virus scans (automatic scan on upload of files); and
o Virus eradication and reporting.
• Are password crackers/checkers used;
• Are integrity verification programs used by applications to look for evidence of data
tampering, errors, and omissions;
• Is system performance monitoring used to analyze system performance logs in real time
to look for availability problems, including active attacks, and system and network
slowdowns and crashes; and
• Is there any encryption systems in use (e.g., SSL, Certificate, PKI).

April 2003

5.WSS.7 Documentation
Documentation is a very important security control for a web support system. As there is no
standard web support system configuration, the internally generated documentation is all an
organization may have that explains how software/hardware was configured for use.

Documentation for a web support system includes descriptions of the hardware and software,
configuration documentation about the hardware and software as it relates to the web support
system, policies, standards, procedures, backup and contingency activities, as well as
descriptions of user and operator procedures.

An example list is provided to show the type of documentation that would normally be
maintained for a system. The list is not intended to be all- inclusive or imply that all systems
should have all items listed.

Examples of Web Support System Documentation
Ø Vendor supplied documentation on web server software
Ø Vendor supplied documentation on COTS applications supporting web
functionality (e.g., search engine, web based training applications)
Ø Configuration settings for each web site and/or sub-web
Ø General Support System Security Plan
Ø Web Support System Security Plan
Ø User Manuals or FAQ pages
Ø Privacy Policy
Ø Risk Assessments
Ø Recovery Plan & Testing Plan
Ø Contingency Plan
Ø Authorize to Process Letter / C&A Package
Ø Memoranda of understanding with interfacing systems

5.WSS.8 Security Awareness and Training
Web support systems like general support systems and major applications should have a security
awareness and training program associated with it. The Computer Security Act requires federal
agencies to provide training in computer security awareness. OMB Circular A-130 further
enforces this requirement. The trick with web support systems is that most of them are public
facing and may be used by more than just the organizations employees and/or contractors. This
may require the organization to have a two-tracked security awareness and training program for a
web support system: Internal Training and External Training.

Internal Training
Internal training is geared around security awareness and training for the organizations
employees and contractors. This track may actually be combined with the general support
system awareness and training program or it may be a stand-alone module that only certain
personnel receive. Internal training should also have a special section to it devoted just to the

April 2003

risks of web development around the environment used by the organization for the web
programmers and developers.

External Training
External Training is geared to statements and static content pages that users of the system can
view. In some cases, the organization may also find the need to make use of pop- up screens to
provide this information. The external training needs to be geared toward the user population of
the web support system and around the controls applicable to those users.

Regardless of the type of training the organization makes use of for the web support system,
include in this section of the plan information about the following:

• The awareness program for the system (posters, booklets, etc.);
• The type and frequency of system-specific training provided to employees and contractor
personnel (seminars, workshops, etc.);
• The procedures for assuring that employees and contractor personnel have been provided
adequate training;
• The type and frequency of security awareness training provide to the public users.

5.WSS.9 Incident Response Capability
The web support system, being a public or semi-public facing system, is the front door to your
organization on the Internet. All web support systems should be include in the organizations
Incident Response System that is mandate by OMB Circular A-130 and that is normally
supported by the general support systems of the organization. In this section, describe the
incident handling procedures specifically targeted for the web support system.

Some of the areas of consideration that should be included in this section:
• Describe the incident response capability;
• What are the procedures for reporting and handling incidents;
• Who receives and monitors alerts/advisories and vendor updates;
• Describe any intrusion detection tools used; and
• Describe any other security tools in place to identifying and investigation of activity.

April 2003

6 Technical Controls
Technical controls are the security controls that the system executes automatically. These
controls can provide automated login and protection of the system that can be used to facilitate
detection and investigation of security violations. While the controls themselves are technical
and in most cases automated, there is still a part to these controls that require personnel to audit
or monitor the output from these controls. Simply putting the controls in place and walking
away does not provide adequate security in the long term.

The controls put in place or planned should be consistent with the level of risk of the system, the
ability to manage the controls by personnel within the organization, and support the needs of any
web applications the web support system hosts.

6.WSS.1 Identification and Authentication
Access to the web support system usually requires the system to be able identify a user and
determine what rights that user has to the web support system. Depending on the web support
system users maybe required to login to the system to access it or just to perform certain
functions. Though some web support systems are completely public facing and don’t require
any login access, the system still should be set up to support the concept of least privilege and
user accountability.

6.WSS.1.1 Identification
In this section of the plan, describe how users are identified to the system.

Anonymous Access: What parts of the system can be access without a User ID being entered?

Unique Identification: What parts of the system require users to identify themselves before being
allowed to access the system?

Correlate Actions to Users: How does the system maintain the actions the users make while
using the web support system.

Maintenance of User IDs: An organization should ensure that all User IDs belong to currently
authorized users. Identification data must be kept current by adding new users and deleting
former users.

Inactive User IDs: User IDs that are inactive on the system for a specific period of time (e.g.,
three months) should be disabled.

6.WSS.1.2 Authentication
Authentication is how the system knows or validates a user is the person they claim to be. While
there are many means of establishing the authenticity of a user, typically most web support
system only makes use of a shared secret authentication system (e.g., password, PIN).

April 2003

In this section the web support system’s authentication control mechanisms should be described.
Some topics that should be included in this section are:

• Describe the user authentication systems;
• Describe the password creation and acceptability policy enforced by the system (e.g.,
length required, character set required);
• Describe the procedure for issuing passwords, handling lost passwords, password
changes;
• Describe the token system used, if implemented;
• How does the web support system request and receive User ID and Passwords (e.g., clear
text, SSL, NT Change and Response);
• Number of invalid login attempts allow and lock out procedures; and
• Describe how the system accommodates and handles electronic signatures (if needed);

6.WSS.2 Logical Access Controls (Authorization/Access Controls)
Logical access controls govern who has access to specific system resources and type of access
permitted. In this section the controls in place to restrict the activities of the users of the web
support system should be discussed.

• Describe what authority each class of users has (e.g.; anonymous user, browser, author,
publisher, webmaster);
• Discuss how separation of duties is enforced or how it is mitigated if separation of duties
is not enforced;
• What ability is available on a web site to run scripts, write, or execute programs;
• Does the web support make user of Access Control Lists and how often are they
reviewed for accuracy;
• Is Discretionary access control allowed;
• How is the web support system segregated from the rest of the IT infrastructure;
• Does the web support system enforce time-outs from inactivity;
• How long does a web support system maintain a logged in connection if communication
with the remote user is lost with out logout command issued;
• Does the system enforce any hours of operations;
• If SSL is used, what version(s) are accepted by the server and discuss the SSL Certificate
generation process;
• Discuss any encryption used, if any, other than SSL and describe the methodology used;
• Discuss protection of the web support system offered from any firewalls, routers, and
proxy servers in front and/or behind the web support system;
• Are login banners/screens/ pop-ups used:

It is recommended that a standardized log-on banner be placed on the system. Public Law 99-474
requires that a warning message be displayed; notifying unauthorized users that they have
accessed a U.S. Government computer system and unauthorized use can be punished by fines or
imprisonment. Some of the systems now in use are intended for unrestricted us e by the general

April 2003

public (e.g., Internet-based systems used for widespread public information dissemination), a
situation not prevalent when Public Law 99-474 was enacted. Due to their adverse impact on the
intended user population, highly restrictive warning banners may not be appropriate. The choice
of which screen warning banner to implement is up to the system owner and should be based on
system-specific technology limitations, data sensitivity, or other unique system requirements. In
this section, describe the rationale for electing to use or not use warning banners and provide an
example of the banners used. Where appropriate, state whether the Department of Justice,
Computer Crime and Intellectual Properties Section, approved the warning banner.

6.WSS.3 Public Access Controls
Since all web support systems have some aspect of them that are public facing and thus available
to public access, this section should talk in detail about the safeguards to ensure that the web
support system is not use to breech the confidentiality, integrity, or availability of the general
support systems and major applications of the organization. For the purpose of this document a
web site, an organizational intranet that can be accessed from the Internet via a user ID, and /or
extranet is considered to be public facing and have some level of public access.

Some possible controls or issues to talk about in this section are:
• How public users data is validated before the production data systems accept the data;
• What form, if any, of identification and authentication is required for users;
• How does the public “register” for access, if any is allowed;
• Does the system require any encryption to perform actions and protect data;
• Does the system verify data uploaded is virus- free;
• Is there the ability for users to verify a downloaded file is authentic and has not be altered
and is virus free (e.g. hash digests; PGP);
• Are there warning banners or disclaimers; and
• Are there special legal considerations for having the public having/not ha ving access.

6.WSS.4 Audit Trails
Most web support systems have their own unique set of audit trails that are available to be turned
on. These audit functions can assist you in tracking user activity, tracking problems, and
analysis usage and performance of a web support system. Unlike audit trails with general
support systems and major applications, audit trails on a web support system that capture user
information must be talked about in the privacy and security statement that is published on the
web support system. It is very important that your privacy statement(s) and your audit trail
controls are coordinated so that they are in-sync with each other. Since most web support
systems are also public facing systems, these audit trails should be reviewed frequently to
identify trends and specious behavior.

Some items that should be talked about in detail in this section are:
• What items does the web support system audit and record (e.g., referring URL, user IP,
User ID, content page view);

April 2003

• How are audit trails recorded (e.g., written to a database, written to a text file);
• Who has access to the audit trails;
• How often are the trails reviewed;
• Does the audit trail(s) support accountability and the ability for after-the- fact
investigations of how, when, and why normal operations ceased;
• Can the audit trails be correlated to intrusion detection information;
• How long are the audit trails maintained;
• Are web support system audit logs review and coordinated with general support audit
logs concerning the web support system; and
• Are any audit analysis tools used in a real- time or near real-time fashion.

April 2003

White Paper Guide For Developing Security Plans

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a White Paper Guide For Developing Security Plans

Semelhante a White Paper Guide For Developing Security Plans (20)

White Paper Guide For Developing Security Plans