Example of Operating Procedures for Information Processing Facilities

1.0 Introduction

1. This document states the procedures required for creating and maintaining a secure environment for the storage and dissemination of information at Information Processing Facilities.
   • It is critical that all the staffs at Information processing facilities are fully aware of the Policy, procedures, guidelines and best practices and commit to protecting the information of the XXX. Common sense and high ethical standards are required to complement the Procedure.
   • The procedures outlined represent the minimum security levels required at the Information Processing Facilities and must be used along with the  detailed security plan and additional policies

1.1 Background

1. This procedures applies to XXX’s Information processing facilities and are inclusive of their hardware facilities, software installations, and communication networks as well as information.
2. CISO has, among other responsibilities, the mandate to establish this procedure for information security and internal controls as well as contingency planning and disaster recovery at Information Processing facilities.

1.2 Audience

The procedures are for distribution to XXX’s Information Processing Facilities through their respective Security Representative who will then be responsible for communicating the details to XXX’s employees as well as contractors or other entities whose position responsibilities include the creation, maintenance, or access of XXX’s information residing on any computer system or platform.

2.0  Information

Management of information requires a working set of procedures that provide guidance and direction with regards to security. The primary focus is on the confidentiality and integrity of the information required for delivering information throughout the Organization.

2.1 Information Confidentiality

1. The overriding premise is that all information hosted or created at XXX’s Information Processing Facilities is property of the XXX. As such, this information will be used solely for performance of position related duties. Any transfers or disclosures are governed by this rule.
2. The confidentiality of all information created or hosted by XXX’s Information Processing Facilities is the responsibility of all XXX’s employees. Disclosure is governed by legislation, regulatory protections, rules as well as policies and procedures of the XXX and of the owning XXX. The highest of ethical standards are required    to prevent the inappropriate transfer of sensitive or confidential information.
3. Release of information is strictly for job related functions. Confidentiality is compromised when knowingly or inadvertently, information crosses the boundaries of job related activities.
4. Users must be required to follow good security practices in the selection and use of passwords. Passwords provide a means of validating a user’s identity and thereby establish access rights to information processing facilities or services. All agency staff must be advised to:
   • keep passwords confidential,
   • avoid keeping a paper record of passwords, unless this can be stored securely,
   • change passwords whenever there is any indication of possible system or password compromise,
   • select quality passwords with a minimum length of eight characters which are:
     • easy to remember,
     • not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers and dates of birth etc.,
     • free of consecutive identical characters or all-numeric or all- alphabetical groups,
   • change passwords at regular intervals (passwords for privileged accounts should be changed more frequently than normal passwords),
   • avoid reusing or cycling old passwords,
   • change temporary passwords at the first log-on,
   • not include passwords in any automated log-on process, e.g. stored in a macro or function key, and

2.2 Information Content

1. All information content hosted by XXX’s Information Processing Facilities is owned by and is the primary responsibility of the Facility in charge responsible for collecting and maintaining the authenticity, integrity and accuracy of information. The objective of the owning XXX’s Information Processing Facilities is to protect the information from inadvertent or intentional damage as well as unauthorized disclosure or use according to the classification standards and procedural guidelines of the owning XXX.
2. The following procedures must be followed by all staff at XXX’s Information Processing Facilities:
   • All information content must reflect the actual state of affairs of the Information Processing Facilities. Changes in the status of personnel who have system access are entered in the system immediately and the appropriate authorization / change form sent to the hosting Security Administration.

2.3 Information Access

1.Information access is subject to Access Control Policy and to the appropriate approval processes of the XXX. The Facilities in charge is responsible for maintaining current and accurate access authorities and communicating these in an agreed upon manner to the security function at the XXX’s Information Processing Facilities hosting the information.

2. XXX has a designated a security representative whose role includes:

• communicating the information security Policy to all their respective a employees,
• Communicating the appropriate procedures to the responsible user, owner, or people directly responsible for hosting   activities at Information Processing Facilities.
• granting user access to system functions, and
• reporting all deviations to the Policy, procedure.

3. Procedures for the Security Administration function are:

• Confirm set up to the Director and the individual concerned via  email when the set-up is complete for the role of Security Representative.
• Confirm set up to the Security Representative and the individual concerned when the set-up is complete for the use roles assigned.
• A daily report will be run by the dept. to list terminations. Security Administration will lock the access privileges at the end of day on the effective date. This does not preclude the responsibility of Facility in charge to notify the HR of terminations using agreed upon formal notice or by the phone and/or email in the case of dismissals.
• The HR dept. will run a weekly report of transfers and follow up with the Facility in charge concerned if a change notification is not received.
• Users not using the system for 60 days will be automatically deactivated. Security Administration will notify the Facility Head and will require an email or new activation form from the user dept.’s security representative to reactivate the individual.

4. The Facility in charge has the responsibility to adhere to procedures and put   into effect all authorized changes received from the CISO in a timely manner.

2.4 Information Security

1. The facility in charge collects and maintains (owns) the information is responsible for interpreting all confidentiality restrictions as well as establishing information classification and approving information access. It will staff a Security Administration  function whose responsibility will be operational control and timely implementation of access privileges.
2. System limitations may prevent all of the following procedures to be implemented, however, when possible, these rules apply:
   • Passwords will be required to be a minimum of 8 characters long, containing at least one (1) numeric character.
   • Passwords will expire in a maximum of 90 days.
   • Passwords will be deactivated if not used for a period of 60 days.

3. Employees that access the systems have the responsibility to protect the confidentiality of information which they use in the course of their assigned duties.

2.5  Information Availability

Information availability is the responsibility of the employees. Access to information will be granted as needed to all employees to support their required processes, functions and timelines. Proven backup and recovery procedures for all information elements to cover the possible loss or corruption of system data are the responsibility of the hosting employees. Required availability will vary with normal cycles of use (i.e. information is used constantly throughout the day, but is only periodically accessed during the evening by a backup process, becomes archival after the backup is complete). The following asset availability definitions should include a statement detailing over what time period the definition is accurate for (i.e. Constant during business hours, archival after year-end, etc.):

Availability	Frequency of Use	Loss / Absence Impact
Constant	Accessed at all times	Immediate cessation of supported business functions
Regular	Accessed   intermittently   by 1 individual but constantly by all users as a group    (i.e. email)	Interruption or degradation, but not cessation, of supported business functions
Periodic	Accessed intermittently, or on 1 a schedule (i.e. year-end records)	Delay of  supported  business functions
Archival	Not normally accessible	Disruption of business support objectives

The Facilities Security in charge will be responsible for:

1. publishing a Service Level Agreement for all users of the system including response time, hours of availability and all other services contracted,
2. ensuring all backups are current, secure and accessible,
3. ensuring information facilities and data can be recovered, and
4. ensuring adequate technical support for systems, data base access and operating systems.

3. Incident Management

1.Incident management responsibilities and procedures must be established by the CISO and its associates to ensure a quick, effective and orderly response to security incidents. Procedures must be established to cover all potential types of security incidents, including:

(A) information system failures and loss of service,
(B) denial of service,
(C) errors resulting from incomplete or inaccurate business information, and
(D) breaches of confidentiality.

2.In addition to normal contingency plans (designed to recover systems or services as quickly as possible), the procedures must also cover:
(A) analysis and identification of the cause of the incident,
(B) planning and implementation of remedies to prevent recurrence, if necessary,
(C) collection of audit trails and similar evidence,
(D) communication with those affected by or involved with recovery from the incident, and
(E) reporting the action to the security administration function at the hosting agency.

3.Audit trails and similar evidence must be collected and secured as appropriate, for:
(A) internal problem analysis,
(B) use as evidence in relation to a potential breach of contracts, policies, or regulatory requirements,
(C) use in the event of civil or criminal proceedings, e.g. under computer misuse or information protection, and
(D) use in negotiating for compensation from software and service suppliers.

4. Action to recover from security breaches and correct system failures should be carefully and formally controlled. The procedures must ensure that:
(A) only clearly identified and authorized staff are allowed access to live systems and information,
(B) all emergency actions taken are documented in detail,
(C) emergency action is reported to management and reviewed in an orderly manner, and
(D) the integrity of business systems and controls is confirmed with minimal delay.

4. Event Logging and Monitoring

1.Audit logs recording exceptions and other security-relevant events must be produced and kept for an agreed period to assist in future investigations and access control monitoring. Audit logs should include:

• user IDs,
• dates and times for log-on and log-off,
• terminal identity or location if possible,
• records of successful and rejected system access attempts, and
• records of successful and rejected data and other resource access attempts.

2. Certain audit logs may be required to be archived as part of the record retention procedures or because of requirements to collect evidence.

3. Procedures for monitoring use of information processing facilities must be established and the result of the monitoring activities reviewed regularly. Such procedures are necessary to ensure that users are only performing activities that have been explicitly authorized. The level of monitoring required for individual facilities should be determined by a risk assessment. Areas that should be considered include:

1. Authorized access, including detail such as:
   • the user ID,
   • the date and time of key events,
   • the types of events,
   • the files accessed, and
   • the program/utilities used.
2. All privileged operations, such as:
   • use of supervisor account,
   • system start-up and stop, and
   • I/O device attachment/detachment.
3. Unauthorized access attempts, such as:
   • failed attempts,
   • access procedure violations and notifications for network gateways and firewalls, and
   • alerts from proprietary intrusion detection systems.
4. System alerts or failures such as:
   • console alerts or messages,
   • system log exceptions, and
   • network management alarms.

5. Risk Management

Risk management encompasses risk assessment, risk mitigation as well as evaluation and assessment. The risk assessment process includes identification and evaluation of risks and risk impacts and recommendation of risk-reducing measures. Risk mitigation refers to prioritizing, implementing and maintaining the appropriate risk-reducing measures recommended from the risk assessment process. Through a continual evaluation process, the facility in charge is responsible for determining whether the remaining risk is at an acceptable level or whether additional security controls should be implemented to further reduce or eliminate the residual risk.

5.1 Risk Assessment

1. The Facility in charge will be responsible for determining the likelihood of an adverse event, the threats to system resources, the vulnerability of the system and the impact such an adverse event may have.
2. To determine the likelihood of an adverse event, consider:
   • Motivation
   • Nature of the vulnerability
   • Current controls
3. A threat needs, and cannot exist without a vulnerability. A vulnerability is a weakness that can be intentionally or accidentally triggered. Threats can be posed from a lot of sources, some of which are:
   • System Intruders (hackers)
   • Criminals
   • Terrorists
   • Espionage
   • Insiders which could be malicious or a result of poor training
4. In identifying the vulnerabilities, consideration must be given to:
   • Hardware
   • Software
   • Network
   • System Interfaces
   • Data and information
   • People who support and use the system.
   • Information sensitivity
5. The impact of an adverse event is the:
   • Loss of Integrity
   • Loss of Availability
   • Loss of Confidentiality

5.2 Risk Mitigation

Facility in charge is responsible for reducing risk to all information assets. The following are options provided in analyzing the alternatives.

1. Risk Assumption. To accept the potential risk and continue operating the IT system or to implement controls to lower the risk to an acceptable level.
2. Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo certain functions of the system or shut down the system when risks are identified).
3. Risk Limitation. To limit the risk by implementing controls that minimizes the adverse impact of a threat exercising a vulnerability (e.g., use of supporting, preventive, detective controls).
4. Risk Planning. To manage risk by developing a risk mitigation plan that prioritizes, implements and maintains controls.
5. Research and Acknowledgment. To lower the risk of loss by acknowledging the vulnerability or flaw and researching controls to correct the vulnerability.
6. Risk Transference. To transfer the risk by using other options to compensate for the loss, such as purchasing insurance.

6.0 Personnel/ User Issues

1. Personnel awareness of the information security Policy, procedures, guidelines and best practices is the responsibility of all employees. Adherence to the Policy, procedures, guidelines and best practices is the responsibility of Facility in charge on behalf of the employees.
2. Information security must be adopted at all levels as a “norm” of job performance. Information systems and data are vulnerable. With constant re-enforcement and monitoring, individuals will accept their responsibility to protect the information assets of the State and relate their performance in this area to standards of performance.
3. The IT staff must be alert and trained in offensive and defensive methods to protect the information assets. Adequate staffing and key position backup are essential to run and maintain a secure environment.

6.1 Staffing

Adequate staffing, training and backup are the responsibility of facility in charge. Facility in charge will be responsible for

1. ensuring qualifications meet position requirements,
2. identifying roles that will impact operations when not filled, i.e. if the incumbent leaves or cannot perform the function,
3. ensuring training is in place to keep key individuals current with the technology available in the marketplace (this is particularly important with regards to the Internet and data base controls), and
4. documenting contingency plans if critical functions are not available.

6.2 Awareness/ Training

1.The purpose of awareness presentations are simply to focus attention on security and are intended to allow individuals to recognize IT security concerns and respond accordingly. Awareness relies on reaching broad audiences, whereas training is more formal, having a goal of building knowledge and skills to facilitate job performance.

2.Effective IT security awareness presentations must be designed. Awareness presentations must be on-going, creative and motivational, with the objective of focusing attention so that the learning will be incorporated into conscious decision- making.

3.The CSIO will be responsible for:

• communicating the minimum standards for all related policies and procedures,
• providing recommendations for best practices in selected areas related to information security, and
• providing all necessary information for the development of an awareness program

4.Facility in charge will:

• create and present security awareness sessions for their staff members, and
• ensure all staff members have attended an awareness session.

5.All current employees as well as new employees or contractors when hired that have access to any information assets must be briefed by the Facility in charge as follows:

• the access requirements of their position or contract,
• their responsibilities for safeguarding sensitive information and assets,
• all information security policies, procedures, guidelines and best practices, and
• a written document outlining the contents of the briefing and the date, which should be signed by the individual briefed acknowledging receipt of its contents.

6.3 Personal Computer Usage

1.All users are given access to computers and other equipment at Information Processing Facilities for job related duties and this usage must remain in compliance with XXX’s policies as well as all laws governing usage and communication of information. Failure to comply will result in the denial of access privileges and may for employees lead to disciplinary action up to and including dismissal. For contractors, it may lead to the cancellation of the contractual agreement. Litigation may ensue.

2. In the effort to protect the integrity of the network and its systems, any proof of unauthorized or illegal use of any computer and/or its accounts will warrant the immediate access to these files, accounts and/or systems by the
security and information systems staff and appropriate action will be taken.

3.Information Security Policy for computer usage prohibits the use of its resources to:

• Send email using someone else’s identity (Email forgery).
• Take any action that knowingly will interfere with the normal operation of the network, its systems, peripherals and/or access to external networks.
• Install any system or software on the network without prior approval.
• Install any software systems or hardware that will knowingly install a virus, Trojan horse, worm or any other known or unknown destructive mechanism.
• Attempt IP spoofing.
• Attempt the unauthorized downloading, posting or dissemination of copyrighted materials.
• Attempt any unauthorized downloading of software from the Internet.
• Transmit personal comments or statements in a manner that may be mistaken as the position of the XXX.
• Access, create, transmit (send or receive), print or download material that is discriminatory, derogatory, defamatory, obscene, sexually explicit, offensive or harassing based on gender, race, religion, national origin, ancestry, age, disability, medical condition, sexual orientation or any other status protected by state laws.

4. Furthermore, it is the XXX’s position that all messages sent and received, including personal messages and all information stored on the electronic mail system, voicemail system or computer systems are XXX property regardless of the content. As such, it reserves the right to access, inspect and monitor the usage of all of its technology resources including any files or messages stored on those resources at any time, in its sole discretion, in order to determine compliance with its policies, for purposes of legal proceedings, to investigate misconduct, to locate information or for any other business purpose.

6.4 Email Usage

1. Electronic mail (email) is a highly efficient form of modern communication media. Used appropriately, email provides people with a means to communicate thereby facilitating business contact. However, this convenience also tempts users to experiment or take advantage of this media, resulting in email of unwelcome types (collectively known along with other unwelcome activity as Net Abuse). The improper use of this email technology may jeopardize systems integrity, security and service levels. Access to email is provided to users to assist them to perform their work and their use of email must not jeopardize operation of the system or the reputation and/or integrity of the XXX.

2. Email accounts are made available to all staff that require the service for the performance of job related functions. The following statements apply:

• All email and associated system resources are the property of the XXX. Email is subject to the restrictions on its use and the review process as per policy of Access control. Its use and content may be monitored.
• Users must comply with all applicable legislation, regulations, policies and standards. This includes complying with copyright and license provisions with respect to both programs and data.
• While email is provided as a business tool to users, its reasonable, incidental use for personal purposes is acceptable. This use must not, however, detrimentally affect employee productivity, disrupt the system and/or harm the XXX’s reputation.

3. Users may not:

• use email for commercial solicitation or for conducting or pursuing their own business interests or those of another organization,
• use email to distribute hoaxes, chain letters or advertisements and/or send rude, obscene, threatening or harassing messages,
• use email to distribute pornographic material or hate literature,
• use email to harass other staff members,
• use email to send executable programs or games,
• use email to send potentially offensive material, and
• propagate viruses knowingly or maliciously.

4. Users must not send, forward and/or reply to large distribution lists concerning non-XXX business. In addition, users must consider the impact on the network when creating and using large, work-related distribution lists.

5. Email is a record and therefore management of email must comply with existing legislation, regulations, policies and standards.

6. Alleged inappropriate use of the email technology will be reviewed by the facility in charge on a case by case basis and may lead to disciplinary action up to and including dismissal. In respect to contractors, it may lead to cancellation of the contractual arrangement. In any of the cases, it may lead to litigation.

6.5 Internet/ Intranet security

1.The World Wide Web (WWW) is a system for exchanging information over the Internet. An Intranet is a proprietary network that is specific for our entity.

2.At the most basic level, the Web can be divided in two principal components:Web servers, which are applications that make information available over the Internet (in essence publish information) and Web browsers (clients), which are used to access and display the information stored on the Web servers. The Web server is the most targeted and attacked host on most organizations’ network. As a result, it is essential to secure Web servers and the network infrastructure that
supports them.

3.The specific security threats to Web servers generally fall into one of the following categories:

• Malicious entities may exploit software bugs in the Web server, underlying operating system or active content to gain unauthorized access to the Web server. Examples of unauthorized access are gaining access to files or folders that were not meant to be publicly accessible or executing privileged commands and/or installing software on the Web server.
• Denial of Service attacks may be directed to the Web server denying valid users an ability to use the Web server for the duration of the attack.
• Sensitive information on the Web server may be distributed to unauthorized individuals.
• Sensitive information that is not encrypted when transmitted between the Web server and the browser may be intercepted.
• Information on the Web server may be changed for malicious purposes. Web site defacement is a commonly reported example of this threat.
• Malicious entities may gain unauthorized access to resources elsewhere in the organization’s computer network via a successful attack on the Web server.
• Malicious entities may attack external organizations from a compromised Web server, concealing their actual identities and perhaps making the organization from which the attack was launched liable for damages.
• The server may be used as a distribution point for illegal copies software attack tools, or pornography, perhaps making the organization liable for damages.

4.The Facility in charge is responsible for the Web server. Some examples of controls to protect from unauthorized access or modification are:

• install or enable only necessary services,
• install Web content on a dedicated hard drive or logical partition,
• limit uploads to directories that are not readable by the Web server,
• define a single directory for all external scripts or programs executed as part of Web content,
• disable the use of hard or symbolic links,
• define a complete Web content access matrix that identifies which folders and files within the Web server document directory are restricted and which are accessible (and by whom), and
• use host-based intrusion detection systems and/or file integrity checkers to detect intrusions and verify Web content.

5.Maintaining a secure Web server is the responsibility of the facility in charge and involves the following steps:

• configuring, protecting and analyzing log files,
• backing up critical information frequently,
• maintaining a protected authoritative copy of the organization’s Web content,
• establishing and following procedures for recovering from compromise,
• testing and applying patches in a timely manner, and
• testing security periodically.

6.A firewall environment must be employed to perform the following general functions:

• filter packets and protocols,
• perform inspection of connections,
• perform proxy operations or selected applications,
• monitor traffic allowed or denied by the firewall, and
• provide authentication to users using a form of authentication that does not rely on static, reusable passwords that can be sniffed.

7.The Facility in charge’s responsible for Internet security will:

1. Keep operational systems and applications software up to date. Because software systems are so complex, it is common for security related problems to be discovered only after the software has been in widespread use. Although most vendors try to address known security flaws in a timely manner, there is normally a gap from the time the problem is publicly known, the time the vendor requires to prepare corrections and the time you install the update. This gap gives potential intruders an opportunity to take advantage of this flow and mount an attack on computers and networks. To keep this time interval as short as possible, it is required to stay aware of:
   • announcements of security-related problems that may apply,
   • immediate actions to reduce exposure to the vulnerability, such as disabling the affected software and
   • permanent fixes from vendors.
2. Restrict only essential network services and operating system on the host server.
   • Ensure that only the required set of services and applications are installed on the host server. Either do not install unnecessary services or turn the services off and remove the corresponding files (and any other unnecessary files) from the host.
3. Configure computers for file backup.
4. Protect computers from viruses and programmed threats.
5. Allow only appropriate physical access to computers.
6. Design, implement and monitor an effective firewall system.

7.0 Physical and Environmental Security

1.The Facility in charge has the responsibility for documentation, execution, monitoring and testing of a physical security plan for both computer and telecommunication assets. This physical security plan would evaluate the risks from potential losses due to

• physical destruction or theft of physical assets,
• loss or destruction of information and program files,
• theft of information,
• theft of indirect assets, and
• delay or prevention of computer processing.

2.Included in the plan would be measures for reducing the possibility of a loss and must address:

• changes in the environment to reduce exposure,
• measures to reduce the effect of a threat,
• improved control procedures,
• early detection, and
• contingency plans.

7.1 Operations center

The following are guidelines of the action items for establishing, implementing and maintaining a physical security program at the hosting agency:

• conduct a risk analysis,
• determine local natural disaster probabilities,
• protect supporting utilities.
• ensure computer reliability,
• provide physical protection.
• implement procedural security,
• plan for contingencies,
• develop security awareness, and
• validate the program.

7.2 Operations Monitoring

1.Facility in charge can monitor security effectiveness by comparing performance to the metrics in a service level agreement and incidents that occur in violation of security policies and procedures.

2.Guidelines for hosting agencies in establishing a service level agreement are:

• hours of system availability,
• hours of application system support,
• hours of technical support,
• off hours support,
• average system response time, and
• other metrics as suitable for agency specific applications.

3. Facilities in charge should have a goal of achieving 99.9%+ of the metrics established in the service level agreement. Failure to achieve these targets could be an indication of security breaches.

4. In so far as incidents are concerned, both offensive and defensive actions to protect the security of physical assets should be considered routine. Examples of offensive actions include:

• routine changes of passwords,
• develop an escalation procedure of incidents,
• routine changes of locks or combinations to the facilities,
• have more than one person knowledgeable for critical functions,
• rotate shifts or people between functions,
• monitor all incursion attempts,
• install latest versions of firewall software,
• maintain 24×7 vendor contact list,
• routine backups,
• off-site storage of system information and programs,
• redundant components, lines for critical systems, and
• testing of recovery procedures.

5. Examples of defensive actions include:

• report and action all deviations to security policies and procedures,
• shut down any infected machine immediately,
• disconnect any problem areas from the network,
• revoke privileges of users violating policies,
• assign severity to an issue and escalate, and
• acquire knowledgeable resources.

7.3 Back- Up of Information

Back-up copies of essential business information and software must be taken regularly. Adequate backup facilities should be provided to ensure that all essential business information and software can be recovered following a disaster or media failure. Backup arrangements for individual systems should be regularly tested to ensure that they meet the requirements of business continuity plans. The following controls must be considered:

• A minimum level of back-up information, together with accurate and complete records of the back-up copies and documented restoration procedures, should be stored in a remote location at a sufficient distance to escape any damage from a disaster at the main site. At least three generations or cycles of back-up information should be retained for important business applications.
• Back-up information should be given an appropriate level of physical and environmental protection consistent with the XXX’s Back up policy. The controls applied to media at the main site should be extended to cover the back-up site.
• Back-up media should be regularly tested, where practicable, to ensure that hey can be relied upon for emergency use when necessary.
• Restoration procedures should be regularly checked and tested to ensure that they are effective and that they can be completed within the time allotted in the operational procedures for recovery.
• The retention period for essential business information and also any requirement for archive copies to be permanently retained should be determined.

7.4 Access Control

Logical and physical access controls are required to ensure the integrity of the information and physical assets and should be done at per the XXX’s Access control policy. The following guidelines for controlling logical access should be implemented by the facilities in charge.

• document and adhere to procedures for granting, modifying and revoking access,
• ensure segregation of duties for access
• install detection mechanisms for unauthorized access attempts,
• timeout a session after 15 minutes of inactivity, and
• revoke access after an inactivity period of 60 days.

Physical access control guidelines for all employees include:

1. all telecommunication and computer related equipment are to be in a secured, locked environment,
2. access codes for secure environments must be changed at least every 60 days or in the event of an individual departing that previously had access,
3. account for all keys issued for those facilities using this method and replace locking mechanism when a key is missing,
4. when the system permits, log all accesses and retain, and
5. secure all peripherals such as air conditioning, generators, etc.
6. segregation of duties must be implemented to prevent unauthorized access to systems or data

7.5 Network

1. Unsecured connections to network services can affect the whole organization. Users must only have direct access to the services that they have been specifically authorized to use. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the organization’s security management and control.
2. The use of networks and network services covers:
   • the networks and network services which are allowed to be accessed,
   • authorization for determining who is allowed to access which networks and networked services, and
   • management controls to protect the access to network connections and network services.
3. The path from the user terminal to the computer service must be controlled. Networks are designed to allow maximum scope for a sharing of resources and flexibility of routing. These features may also provide opportunities for unauthorized access to business applications, or unauthorized use of information facilities. Incorporating controls that restrict the route between a user terminal and the computer services its user is authorized to access, e.g. creating an enforced path can reduce such risks. The objective of an enforced path is to prevent any users selecting routes outside the route between the user terminal and the services that the user is authorized to access. This usually requires the implementation of a number of controls at different points in the route. The principle is to limit the routing options at each point in the network, through predefined choices.
4. The following methods should be implemented to limit the path to a service:
   • allocating dedicated lines or telephone numbers,
   • automatically connecting ports to specified application systems or security gateways,
   • limiting menu and submenu options for individual users,
   • preventing unlimited network roaming,
   • enforcing the use of specified application systems and/or security gateways for external network users,
   • actively controlling allowed source to destination communications via security gateways, e.g. firewalls, and
   • restricting network access by setting up separate logical domains, e.g. virtual private networks, for user groups within the organization.
5. External connections provide a potential for unauthorized access to business information, e.g. access by dial-up methods. Therefore, access by remote users must be subject to authentication. There are different types of authentication method, some of these provide a greater level of protection than others, e.g. methods based on the use of cryptographic techniques can provide strong authentication. It is important to determine from a risk assessment the level of protection required. This is needed for the appropriate selection of an authentication method.
   • Authentication of remote users should be achieved using one of the following techniques:
   • a cryptographic based technique,
   • hardware tokens,
   • a challenge/response protocol,
   • dedicated private lines or a network user address checking, and
   • call-back.
6. Dial-back and controls, e.g. using dial-back modems, can provide protection against unauthorized and unwanted connections to an organization’s information processing facilities. This type of control authenticates users trying to establish a connection to an organization’s network from remote locations. When using this control an organization should not use network services which include call forwarding or, if they do, they should disable the use of such features to avoid weaknesses associated with call forwarding. It is also important that the call back process includes ensuring that an actual disconnection on the organization’s side occurs. Otherwise, the remote user could hold the line open pretending that call back verification has occurred. Call back and controls should be thoroughly tested for this possibility.
7. A facility for automatic connection to a remote computer could provide a way of gaining unauthorized access to a business application. Connections to remote computer systems must therefore be authenticated. This is especially important if the connection uses a network that is outside the control of the organization’s security management. Node authentication can serve as an alternative means of authenticating groups of remote users where they are connected to a secure, shared computer facility.
8. Access to diagnostic ports must be securely controlled. Many computers and communication systems are installed with a dial-up remote diagnostic facility for use by maintenance engineers. If unprotected, these diagnostic ports provide a means of unauthorized access. They should therefore be protected by an appropriate security mechanism, e.g. a key lock to ensure that they are only accessible by arrangement.
9. Networks are increasingly being extended beyond traditional organizational boundaries as business partnerships are formed that may require the interconnection or sharing of information processing and networking facilities. Such extensions will increase the risk of unauthorized access to already existing information systems that use the network, some of which might require protection from other network users because of their sensitivity or criticality. In such circumstances, controls must be introduced in networks to segregate groups of information services, users and information systems.
10. The security of large networks should be controlled by dividing them into separate logical network domains, e.g. an organization’s internal network domains and external network domains, each protected by a defined security perimeter. Such a perimeter should be implemented by installing a secure gateway between the two networks to be interconnected to control access and information flow between the two domains. This gateway should be configured to filter traffic between these domains and to block unauthorized access in accordance with the organization’s access control procedures. An example of this type of gateway is what is commonly referred to as a firewall. The criteria for segregation of networks into domains should be based on the access control procedures and access requirements and also take account of the relative cost and performance impact of incorporating suitable network routing or gateway technology.
11. The connection capability of users must be restricted in shared networks, in accordance with the access control procedures.
12. Such controls should be implemented through network gateways that filter traffic by means of pre-defined tables or rules. The restrictions applied should be based on the access procedures and requirements of the business applications and should be maintained and updated accordingly. Examples of applications to which restrictions should be applied are:
    • electronic mail,
    • one-way file transfer,
    • both-ways file transfer,
    • interactive access, and
    • network access linked to time of day or date.
13. Shared networks must have routing controls to ensure that computer connections and information flows do not breach the access control policy of business applications. This control is essential for networks shared with third party (non-organization) users.
14. Routing controls should be based on positive source and destination address checking mechanisms. Network address translation is also a very useful mechanism for isolating networks and preventing routes to propagate from the network of one organization into the network of another. They can be implemented in software or hardware. Implementers should be aware of the strength of any mechanisms deployed. A wide range of public or private network services is available, some of which offer value added services. Network services may have unique or complex security characteristics.
15. A clear description of the security attributes of all network services used by the organization must be provided.

7.6 Electronic Commerce Security

1. Electronic commerce can involve the use of electronic data interchange (EDI), electronic mail and on line transactions across public networks such as the Internet. Electronic commerce is vulnerable to a number of network threats which may result in fraudulent activity, contract dispute and disclosure or modification of information and must be protected. The following issues must be resolved:
   • Authentication. What level of confidence should the customer and trader require in each other’s claimed identity?
   • Authorization. Who is authorized to set prices, issue or sign key trading documents? How does the trading partner know this?
   • Contract and tendering processes. What are the requirements for confidentiality, integrity and proof of dispatch and receipt of key documents and the non-repudiation of contracts?
   • Pricing information. What level of trust can be put in the integrity of the advertised price list and the confidentiality of sensitive discount arrangements?
   • Order transactions. How is the confidentiality and integrity of order, payment and delivery address details and confirmation of receipt, provided?
   • Vetting. What degree of vetting is appropriate to check payment information supplied by the customer?
   • Settlement. What is the most appropriate form of payment to guard against fraud?
   • Ordering. What protection is required to maintain the confidentiality and integrity of order information and to avoid the loss or duplication of transactions?
   • Liability. Who carries the risk for any fraudulent transactions?
2. Electronic commerce arrangements between trading partners should be supported by a documented agreement which commits both parties to the agreed terms of trading, including details of authorization. Other agreements with information service and value-added network providers may be necessary.
3. Consideration should be given to the resilience to attack of the host used for electronic commerce and the security implications of any network interconnection required for its implementation.

7.7 Mobile Computing

1. This must be in place and appropriate controls must be adopted to protect against the risks of working with mobile computing facilities, in particular in unprotected environments. For example, it should include the requirements for:
   • physical protection,
   • access controls,
   • cryptographic techniques,
   • back-ups, and
   • virus protection.
2. It should also include rules and advice on connecting mobile facilities to networks and guidance on the use of these facilities in public places.
3. Care should be taken when using mobile computing facilities in public places, meeting rooms and other unprotected areas outside of the organization’s premises. Protection should be in place to avoid the unauthorized access to, or disclosure of the information stored and processed by these facilities, e.g., using cryptographic techniques.
4. It is important that when such facilities are used in public places care is taken to avoid the risk of overlooking by unauthorized persons.
5. Equipment should be available to enable the quick and easy back-up of information. These back-ups should be given adequate protection against, e.g., theft or loss of information.
6. Suitable protection should be given to the use of mobile facilities connected to networks.
7. Remote access to business information across public network using mobile computing facilities should only take place after successful identification and authentication and with suitable access control mechanisms in place
8. Mobile computing facilities should also be physically protected against theft especially when left, for example, in cars and other forms of transport, hotel rooms, conference centers and meeting places. Equipment carrying important, sensitive and/or critical business information should not be left unattended and, where possible, should be physically locked away, or special locks should be used to secure the equipment.

7.8 Remote Computing

1. Remote computing uses communications technology to enable staff to work remotely from a fixed location outside of XXX. Suitable protection of the remote computing site should be in place against, e.g., the theft of equipment and information, the unauthorized disclosure of information, unauthorized remote access to the organization’s internal systems or misuse of facilities. It is important that remote computing is both authorized and controlled by management and that suitable arrangements are in place for this way of working.
2. Facility in charge should only authorize remote computing activities if they are satisfied that appropriate security arrangements and controls are in place and that these comply with the XXX’s security procedures and policies. The following should be considered:
   • the existing physical security of the remote computing site, taking into account the physical security of the building and the local environment,
   • the communications security requirements, taking into account the need for remote access to the organization’s internal systems, the sensitivity of the information that will be accessed and passed over the communication link and the sensitivity of the internal system, and
   • the threat of unauthorized access to information or resources from other people using the accommodation.
3. The controls and arrangements to be considered include:
   • the provision of suitable equipment and storage for the remote computing activities,
   • a definition of the work permitted, the hours of work, the classification of information that may be held and the internal systems and services that the user is authorized to access,
   • the provision of suitable communication equipment, including methods for securing remote access,
   • physical security,
   • the provision of hardware and software support and maintenance,
   • the process for back-up and business continuity, and
   • audit and security monitoring.

7.9 External Facilities

1. The use of an external contractor to manage information processing or communication facilities may introduce potential security exposures, such as the possibility of compromise, damage or loss of data at the contractor’s site.
2. Prior to using external facilities, the risks must be identified, and appropriate controls agreed with the contractor and incorporated into the contract. Particular issues that should be addressed include:
   • identifying sensitive or critical applications better retained in-house,
   • obtaining the approval of business application owners,
   • implications for business continuity plans,
   • security standards to be specified and the process for measuring compliance,
   • allocation of specific responsibilities and procedures to effectively monitor all relevant security activities, and
   • responsibilities and procedures for reporting and handling security incidents.

7.10 Encryption

1. Encryption should be applied to protect the confidentiality of sensitive or critical information.
2. Based on a risk assessment, the required level of protection should be identified taking into account the type and quality of the encryption algorithm used and the length of cryptographic keys to be used.
3. Specialist advice should be sought to identify the appropriate level of protection, to select suitable products that will provide the required protection and the implementation of a secure system of key management. In addition, legal advice may need to be sought regarding the laws and regulations that might apply to the organization’s intended use of encryption.
4. The use of cryptographic controls for the protection of information must be developed and followed. Such procedures are necessary to maximize benefits and minimize the risks of using cryptographic techniques and to avoid inappropriate or incorrect use.
5. The following should be considered:
   • the management guidelines on the use of cryptographic controls across the organization,
   • including the general principles under which business information should be protected,
   • the approach to key management, including methods to deal with the recovery of encrypted information in the case of lost, compromised or damaged keys,
   • roles and responsibilities, e.g. who is responsible for: the implementation of the procedures; the key management,
   • how the appropriate level of cryptographic protection is to be determined, and
   • the standards to be adopted for the effective implementation throughout the organization (which solution is used for which business processes).

8.0 Business Continuity

1. Information Technology facilities and systems are vulnerable to a variety of disruptions, some of which are short term (measured in minutes and hours) and others lasting for a day or longer. The intent of Business Continuity Planning is to be alert and ready to sustain an organization’s processes during and following a significant unforeseen disruption in services caused by disasters and security failures.
2. Business continuity should begin by identifying events that can cause interruptions to business processes, e.g., equipment failure, flood and fire. This should be followed by a risk assessment to determine the impact of those interruptions (both in terms of magnitude and recovery time frame). Both of these activities should be carried out with full involvement from owners of business resources and processes. This assessment considers all business processes and is not limited to the information processing facilities.
3. A strategy plan, based on appropriate risk assessment, must be developed for the overall approach to business continuity.
4. CISO will develop contingency plans for each major application or general support system to meet the needs of critical IT operations in the event of a disruption extending beyond a given time period. The length of the time period may vary with the system or facility involved. The execution of such a capability will be documented in a formal contingency plan, be reviewed annually and updated as necessary by the hosting agency. It must account for differential daily backups and complete weekly backups to be conducted and sent to a designated off-site facility. As well, the plans should assign specific responsibilities to designated staff or positions to facilitate the recovery and/or continuity of essential IT functions. Designated personnel will be trained to execute contingency procedures. An annual test of the recovery procedures will be conducted.
5. Business continuity management should include controls to identify and reduce risks, limit the consequences of damaging incidents, and ensure the timely resumption of essential operations.

8.1 Contingency Plan

1. A contingency plan provides the documented organizational plan to mitigate risks of business interruption and minimize the impact of any disruption of service. It must maintain instructions for achieving a full or minimally acceptable set of business objectives in the absence of assets, through cost-effective strategies to provide replacements for assets as they become unavailable. The Plan must involve advance planning and preparations to respond to external circumstances as determined by a risk assessment and continue to provide a pre-determined acceptable level of business functionality. It must be defined, implemented, tested and maintained to ensure continuity of organizational services in the event of a disruption. Each contingency plan is unique and must be tailored to organization’s requirements; it must be flexible enough to allow additions, modifications and maintenance. The plan should minimize dependency on individuals for interpretation and implementation – in the event of emergency, key personnel may not be available. It must ensure completeness and establish critical decisions. Always make sure that the plan remains current. The following questions must be answered:
   • What risks the organization is facing in terms of their likelihood and their impact, including an identification and prioritization of critical business processes?
   • How long can the enterprise operate without this asset?
   • What are the impact interruptions are likely to have on the business (it is important that solutions are found that will handle smaller incidents, as well as serious incidents that could threaten the viability of the organization), and establishing the business objectives of information processing facilities?
   • What is the maximum acceptable delay before which temporary systems must be made available?
   • What is the minimum time in which temporary systems may be expected to become available?
   • At what minimally acceptable level of functionality can the enterprise operate?
   • How long can the enterprise operate at a minimally acceptable level of performance?
   • At what point can the enterprise begin to resume normal operations?
   • At what point must the enterprise begin to resume normal operations?
2. A Contingency Plan should contain the roles, responsibilities and procedures for restoring a system or facility following a major disruption. The following guidelines represent the stages to be followed in preparing and executing a Contingency Plan:
   • Documentation – A plan must be documented, tested and communicated. Included in the plan should be a mission, a scope of what is included and not included assumptions, requirements, staffing and responsibilities.
   • Notification/Activation – Internally within IT, the notification, timing and paths should be documented. There should only be one voice talking for the recovery team for communication and escalation outside the boundaries of IT. Immediately following damage assessment, the plan is activated.
   • Recovery – The sequence of recovery activities should be documented in procedures. These activities are to restore operations which may be in temporary locations or with incomplete data.
   • Reconstitution – Restoring facilities and systems to the “norm” will include testing and proof of operations viability.
   • What equipment / facilities are expected to be unavailable?
   • What is the timing of the disruption?
   • What records, files and materials may / may not be expected to be protected from destruction?
   • What resources are available or required following the event?
     • Applications / Processes
     • Functionality / Capacity
     • Equipment / Infrastructure
     • Staff /Skills
     • Connectivity / Network
     • Data Sources
     • Facilities / Services / Physical Premises
     • Transportation
     • Documentation / Reference material
     • Security Policies and Procedures
     • Specific Policies and Procedures
     • Authorization
3. Following is a list of considerations that, at a minimum, must be addressed in creating contingency plans:
   • What additional security measures are required to protect assets in the planning, execution and maintenance of procedures to assure business continuity?
   • What degree of functionality is still available at the main facility, if any?
   • Availability of staff to perform critical functions defined within the plan.
   • Ability of staff to be notified and report to the backup site(s) to execute contingency plans.
   • Backup files and recovery methods.
   • Off-site storage facilities and materials availability.
   • Disaster recovery plan.
   • Suitability of subsets of the overall plan, to be used to recover from minor interruptions.
   • Availability of an alternate facility.
   • Off-site availability of critical forms and supplies, either at an alternate facility or off-site storage.
   • Existence of a backup site for processing the organization’s work.
   • Availability of long distance and local communications lines.
   • Quality of surface transportation in from local to remote sites.
   • Ability of vendors to perform according to their general commitments to support the organization in a disaster.
   • Provisions for staff while at off-site location (food, water, telephones, beds, etc.) This list of considerations is not all inclusive and must be added to as appropriate.
4. General requirements of contingency plans must include:
   • Definitions of conditions under which the Business Recovery Strategy must be implemented.
   • Recovery point objective stages.
   • Recovery time objective stages.
   • Security preservation checklist.
   • Task Assignments.
   • Post-event Recovery Analysis.
   • Required resources, by priority.
   • Required recovery time / levels of availability of resources.
   • Documentation of normal and response procedures.

8.2 Disaster Recovery plan

1. A Disaster Recovery Plan is intended to maintain critical business processes in the event of the loss of any of the following areas for an extended period of time:

• desktop computers and portable systems,
• servers,
• Web sites,
• local area networks,
• wide area networks,
• distributed systems, and
• mainframe systems.

2. Teams should be formed to address each of the areas indicated consisting of a team lead and designate as well as key knowledge personnel required for that particular area. All contact information must be available for IT management, team members, all IT personnel and designated business unit management. When available, this information should include:

• work telephone number,
• pager number,
• home telephone number,
• cellular telephone number,
• work email address,
• home email address, and
• home address.

3. Upon receiving the information of a serious incident any member of management can invoke the Plan. Depending on the nature of the incident a command center will be established, and appropriate teams mobilized. Management and the team leads are responsible for contacting all required personnel. All roles would have designated in the event one or more individuals are unavailable.

4. Communications to the IT department is the responsibility of Management and the Team Lead. In respect to external communications, it is extremely important that there is a single point of disclosure in order to ensure accurate and timely updates. The following roles and individuals must be determined and documented:

• Upwards, within the affected part organization.
• Outwards to affected agencies.
• Outwards to the public.

5. Hard copies of the Plan must be:

• stored off site at a secure location,
• stored at the personal residence of the team leads,
• stored at the personal residence of all IT managers and directors, and
• stored on a secure internet site.

6. As soon as an emergency is detected:

• Identify the problem and,
  • Notify emergency services in cases of physical threats to personnel or facilities,
  • Notify the CISO and his alternate.
  • Notify the appropriate team leads. In the event of a mainframe disaster, notify all team leads.
  • Notify vendors and business partners.
• Evacuate the premises if there are concerns of personal safety. All personnel should:
  • be aware of evacuation routes and
  • have in possession or be aware of notification numbers.
• educe any exposure:
  • In the event of air conditioning failure (this usually involves powering down the systems at a temperature determined by the tolerances set by the manufacturer),
  • In the event of fire (this usually involves the automatic releasing of fire retardant, cutting of power, notification to emergency services and evacuation),
  • In the event of electrical failure (If a UPS and generator are available, usually the only action is to monitor fuel levels of the generator. If a UPS only is available, shut down procedures should begin and be terminated with at least 20% of rated capacity left),
  • In the event of flood, water or wind damage (this usually involves the normal powering down all systems if possible. If not, the immediate cut off of power is required, followed by notification to emergency services and evacuation),
  • In the event of malicious intrusion (this usually involves the immediate isolation of affected hardware from all networks and connectivity. Usually, the extent of exposure and damage is not immediately known so the immediate isolation of all network links is recommended and processing on affected facilities halted pending analysis by crisis teams).
• Initiate backup site process:
  • The Plan Coordinator establishes a command-and-control center (usually an onsite and offsite center have been previously identified and the necessary computer and communication links are readily available).
  • The Plan Coordinator ensures all team leaders are notified (usually it is the responsibility of the Team Lead to get in touch with all team members).
  • The Plan Coordinator notifies the off-site storage facility that a contingency event has occurred and to ship the necessary materials as determined in the damage assessment to the alternate site.
  • The Plan Coordinator notifies the alternate site that a contingency event has occurred and to prepare the facility for the organization’s arrival.
  • Both upward and outward communication on status is the responsibility of the Plan Coordinator (usually set times are pre-established such as: immediate after 1 hour, after 3 hours, etc. or at major milestones such as problem determination, resolution plan, when planned resumption of services is known and start-up of services is accomplished).
  • The Plan Coordinator is responsible for managing expectations.
• Initiate recovery at the alternate site:
  • Contingency plan is followed using documented recovery points and defined priorities.
  • The Plan Coordinator reviews responsibilities with all team members and establishes recovery logs.
  • Recovery goals and procedures are established and prioritized by the Plan Coordinator.

7. The Disaster Plan appendices should include:

• Personnel Contact List
• Vendor Contact List
• Equipment and Specifications.
• Service Level Agreements.
• Related Contracts.

8.3 Business Recover Strategy

1. A Business Recovery Strategy provides the documented organizational plan to restore full business functionality as quickly and as cost-effectively as possible. The Business Recovery Strategy is initiated as soon as the enterprise is deemed able to resume normal operations following a disaster.
2. The Business Recovery Strategy must involve advance planning and preparations to recover from external circumstances. Recovery strategies must be created, implemented, tested and maintained to ensure restoration of organizational services in the event of an interruption.
3. A “worst case scenario” must be the basis for developing the plan, where the worst-case scenario is the destruction of the main or primary facility. Because the plan is written based on this premise, less critical situations can be handled by using subsets of the plan, with minor (if any) alterations required. Recovery from, or mitigation of a scenario should not be considered an all-or-nothing proposition. Many stages may be required, each with its own success conditions, before a ‘final’ state of continuity or recovery is reached.
4. Specific goals of the Business Recovery Strategy must include:
   • Complete service functionality recovery objectives, in stages, by delay, duration and degree.
   • Details of processes already in place to recover from an incident.
   • Details of what degree of business functionality they may be expected to restore.
   • In what length of time existing process may be expected to restore service.
   • Requirements to bridge from existing processes to sufficient processes.
   • Lead time to secure additional resources.
5. The Business Recovery Strategy must include detailed, step-by-step instructions for how to replace / restore the following, in appropriate sequence:
   • Applications / Processes
   • Functionality / Capacity
   • Equipment / Infrastructure
   • Staff /Skills
   • Execution Duration / Delay
   • Connectivity / Network
   • Data Sources
   • Facilities / Services / Physical Premises
   • Transportation
   • Documentation / Reference material.

9.0 Data Center Management

1. Related specifically to security of information and data center management, the pace of change, the reality of the World Wide Web and the increasing numbers of internal and external portals demand constant monitoring with both offensive and defensive strategies.

9.1 Process

1. The process should specify the instructions for the detailed execution of each job including the following:
   • processing and handling of information,
   • scheduling requirements, including interdependencies with other systems, earliest job start and latest job completion times,
   • instructions for handling errors or other exceptional conditions, which might arise during job execution, including restrictions on the use of system utilities,
   • support and owner contacts in the event of unexpected operational or technical difficulties,
   • special output handling instructions, such as the use of special stationery or the management of confidential output, including procedures for secure disposal of output from failed jobs, and
   • system restart and recovery procedures for use in the event of system failure.
2. The process should also be prepared for system housekeeping activities associated with information processing and communication facilities, such as computer start-up and close-down procedures, back-up, equipment maintenance, computer room and mail handling management and safety.

9.2 Operational Change Control

1. Changes to information processing facilities and systems must be controlled. Inadequate control of changes to information processing facilities and systems is a common cause of system or security failures. Formal management responsibilities and procedures should be in place to ensure satisfactory control of all changes to equipment, software or procedures.
2. Operational programs should be subject to strict change control. When programs are changed an audit log containing all relevant information should be retained. Changes to the operational environment can impact applications. Wherever practicable, operational and application change control procedures should be integrated.
3. In particular, the following controls must be implemented:
   • identification and recording of significant changes,
   • assessment of the potential impact of such changes,
   • formal approval procedure for proposed changes,
   • communication of change details to all relevant persons, and
   • procedures identifying responsibilities for aborting and recovering from unsuccessful changes.

9.3 Segregation of Duties

1. Duties and areas of responsibility must be segregated in order to reduce opportunities for unauthorized modification or misuse of information or services.

2. Small agencies may find this method of control difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision must be implemented. It is important that security audit remains independent.

3. Care should be taken that no single person can perpetrate fraud in areas of single responsibility without being detected. The initiation of an event should be separated from its authorization.

4. The following controls must be implemented:

• It is important to segregate activities which require collusion in order to defraud, e.g. raising a purchase order and verifying that the goods have been received.
• If there is a danger of collusion, then controls need to be devised so that two or more people need to be involved, thereby lowering the possibility of conspiracy.
• Separation of duties of both physical and logical access controls must be implemented to separate the access and functions of:
  • information systems and infrastructure administration to include configuration;
  • security, audit, and accountability functions;
  • privileged users and power user functions.
  • data analysis and report generation functions.
  • general user functionality and associated access must be segregation between user and administrative functions and access must be maintained.

9.4 Separation of Development and Operational Facilities

1. Development and testing facilities must be separated from operational facilities. Rules for the transfer of software from development to operational status should be defined and documented.
2. Development and test activities can cause serious problems, e.g. unwanted modification of files or system environment or of system failure. The level of separation that is necessary, between operational, test and development environments, to prevent operational problems should be considered. A similar separation should also be implemented between development and test functions. In this case, there is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access.
3. Where development and test staff have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational information. On some systems this capability could be misused to commit fraud or introduce untested or malicious code. Untested or malicious code can cause serious operational problems.
4. Developers and testers also pose a threat to the confidentiality of operational information. Development and testing activities may cause unintended changes to software and information if they share the same computing environment. Separating development, test and operational facilities is therefore desirable to reduce the risk of accidental change or unauthorized access to operational software and business information.
5. The following controls should be considered:
   • Development and operational software should, where possible, run on different computer processors, or in different domains or directories.
   • Development and testing activities should be separated the best way possible.
   • Compilers, editors and other system utilities should not be accessible from operational systems.
   • Different log-on procedures should be used for operational and test systems, to reduce the risk of error. Users should be encouraged to use different passwords for these systems and menus should display appropriate identification messages.
   • Development staff should only have access to operational passwords where controls are in place for issuing passwords for the support of operational systems. Controls should ensure that such passwords are changed after use.

9.5 Systems planning and acceptance.

To minimize the risk of systems failure:

1. Advance planning and preparation are required to ensure the availability of adequate capacity and resources.
2. Projections of future capacity requirements should be made, to reduce the risk of system overload.
3. The operational requirements of new systems should be established, documented and tested prior to their acceptance and use.

9.6 Capacity planning

1. Capacity demands must be monitored, and projections of future capacity requirements made to ensure that adequate processing power and storage are available. These projections should take account of new business and system requirements and current and projected trends in the organization’s information processing.
2. Mainframe computers require particular attention, because of the much greater cost and lead time for procurement of new capacity. Operations managers of mainframe services should monitor the utilization of key system resources, including processors, main storage, file storage, printers and other output devices and communications systems. They should identify trends in usage, particularly in relation to business applications or management information system tools.
3. These managers should use this information to identify and avoid potential bottlenecks that might present a threat to system security or user services and plan appropriate remedial action.
4. Acceptance criteria for new information systems, upgrades and new versions must be established and suitable tests of the system carried out prior to acceptance. Operations managers should ensure that the requirements and criteria for acceptance of new systems are clearly defined, agreed, documented and tested.
5. The following controls should be considered:
   • performance and computer capacity requirements,
   • error recovery and restart procedures and contingency plans,
   • preparation and testing of routine operating procedures to defined standards,
   • agreed set of security controls in place,
   • effective manual procedures,
   • business continuity arrangements as required,
   • evidence that installation of the new system will not adversely affect existing systems, particularly at peak processing times, such as month end,
   • evidence that consideration has been given to the effect the new system has on the overall security of the organization, and
   • training in the operation or use of new systems.
6. For major new developments, the operations function and users should be consulted at all stages in the development process to ensure the operational efficiency of the proposed system design. Appropriate tests should be carried out to confirm that all acceptance criteria are fully satisfied.

9.8 Operations and Fault logging

1. Operational staff must maintain a log of their activities. Logs should include as appropriate:
   • system starting and finishing times,
   • system errors and corrective action taken,
   • confirmation of the correct handling of data files and computer output, and
   • the name of the person making the log entry.
2. Faults must be reported, and corrective action taken. Faults reported by users regarding problems with information processing or communications systems should be logged. There should be clear rules for handling reported faults including:
   • review of fault logs to ensure that faults have been satisfactorily resolved, and
   • review of corrective measures to ensure that controls have not been compromised and that the action taken is fully authorized.

9.9 Management of Removable computer media

Appropriate Process must be established to protect documents, computer media (tapes, disks, cassettes, etc.), input/output data, and system documentation from damage, theft and unauthorized access. The following should be followed:

• If no longer required, the previous contents of any re-usable media that are to be removed from the organization should be erased.
• Authorization should be required for all media removed from the organization and a record of all such removals maintained.
• All media should be stored in a safe, secure environment, in accordance with manufacturers’ specifications.
• All process and authorization levels should be clearly documented.

9.10 Disposal of Media

Process for the secure disposal of media should be established to minimize this risk. The following controls should be considered:

1. Media containing sensitive information should be stored and disposed of securely and safely, e.g., by incineration or shredding or emptied of information for use by another application within the organization.
2. The following list identifies items that might require secure disposal:
   • paper documents,
   • voice or other recordings,
   • output reports,
   • one-time-use printer ribbons,
   • magnetic tapes,
   • removable disks or cassettes,
   • optical storage media (all forms and including all manufacturer software distribution media),
   • program listings,
   • test information, and
   • system documentation.
3. It may be easier to arrange for all media items to be collected and disposed of securely, rather than attempting to separate out the sensitive items.
4. Disposal of sensitive items should be logged where possible in order to maintain an audit trail.
5. Disposal of certain hardware must conform to the current EPA requirements or other relevant legislation in effect.

9.11 Exchanges of Information and Software

1. Exchanges of information and software between organizations should be controlled and should be compliant with any relevant legislation.
2. Exchanges should be carried out on the basis of agreements. Procedures and standards to protect information and media in transit must be established. The business and security implications associated with electronic data interchange, electronic commerce and electronic mail and the requirements for controls should be considered.
3. Agreements, some of which must be formal, must be established for the electronic or manual exchange of information and software between organizations. The security content of such an agreement should reflect the sensitivity of the business information involved. Agreements on security conditions should include:
   • responsibilities for controlling and notifying transmission, dispatch and receipt,
   • process for notifying sender, transmission, dispatch and receipt,
   • minimum technical standards for packaging and transmission,
   • courier identification standards,
   • responsibilities and liabilities in the event of loss of information,
   • information and software ownership and responsibilities for information protection, software copyright compliance and similar considerations,
   • technical standards for recording and reading information and software, and
   • any special controls that may be required to protect sensitive items, such as cryptographic.
4. Information can be vulnerable to unauthorized access, misuse or corruption during physical transport, for instance when sending media via the postal service or via courier. As such, media being transported must be protected from unauthorized access, misuse or corruption.

9.12 Publicly Available systems

1. Information on a publicly available system, e.g., information on a Web server accessible via the Internet, may need to comply with laws, rules and regulations in the jurisdiction in which the system is located or where trade is taking place. There must be a formal authorization process before information is made publicly available and the integrity of such information must be protected to prevent unauthorized modification.
2. Software, data and other information requiring a high level of integrity, made available on a publicly available system, should be protected by appropriate mechanisms, e.g. digital signatures. Electronic publishing systems, especially those that permit feedback and direct entering of information, should be carefully controlled so that:
   • information is obtained in compliance with any information protection legislation,
   • information input to and processed by the publishing system will be processed completely and accurately in a timely manner,
   • sensitive information will be protected during the collection process and when stored, and
   • access to the publishing system does not allow unintended access to networks to which it is connected.

9.13 Use of system utilities

1. Most computer installations have one or more system utility programs that might be capable of overriding system and application controls. Use of these system utility programs must be restricted and tightly controlled. The following controls should be considered:
   • use of authentication procedures for system utilities,
   • segregation of system utilities from applications software,
   • limitation of the use of system utilities to the minimum practical number of trusted authorized users,
   • authorization for ad hoc use of systems utilities,
   • limitation of the availability of system utilities, e.g. for the duration of an authorized change,
   • logging of all use of system utilities,
   • defining and documenting of authorization levels for system utilities, and
2. removal of all unnecessary software-based utilities and system software.

9.14 Monitoring system access and use

1. Systems should be monitored to detect deviation from access control policy and record system events to provide evidence in case of security incidents. System monitoring allows the effectiveness of controls adopted to be checked.
2. Audit logs recording exceptions and other security-relevant events must be produced and kept for a period defined by the agency and within the mandate of legislation to assist in future investigations and access control monitoring. Audit logs should also include:
   • user IDs,
   • dates and times for log-on and log-off,
   • terminal identity or location, if possible,
   • records of successful and rejected system access attempts, and
   • records of successful and rejected data and other resource access attempts.
3. Certain audit logs may be required to be archived as part of the record retention procedures or because of requirements to collect evidence.
4. Process for monitoring use of information processing facilities must be established and the result of the monitoring activities reviewed regularly. Such process are necessary to ensure that users are only performing activities that have been explicitly authorized. The level of monitoring required for individual facilities should be determined by a risk assessment. Areas that should be included are:
   • authorized access, including detail such as:
     • the user ID,
     • the date and time of key events,
     • the types of events,
     • the files accessed, and
     • the program/utilities used.
   • all privileged operations, such as:
     • use of supervisor account,
     • system start-up and stop, and
     • I/O device attachment/detachment.
   • unauthorized access attempts, such as:
     • failed attempts,
     • access procedure violations and notifications for network gateways and firewalls, and
     • alerts from proprietary intrusion detection systems.
   • system alerts or failures such as:
     • console alerts or messages,
     • system log exceptions, and
     • network management alarms.
5. The result of the monitoring activities should be reviewed regularly. The frequency of the review should depend on the risks involved. Risk factors that should be considered include:
   • the criticality of the application processes,
   • the value, sensitivity or criticality of the information involved,
   • the past experience of system infiltration and misuse and
   • the extent of system interconnection (particularly public networks).
6. A log review involves understanding the threats faced by the system and the manner in which these may arise. System logs often contain a large volume of information, much of which is extraneous to security monitoring. To help identify significant events for security monitoring purposes, the copying of appropriate message types automatically to a second log and/or the use of suitable system utilities or audit tools to perform file interrogation should be considered. When allocating the responsibility for log review a separation of roles should be considered between the person(s) undertaking the review and those whose activities are being monitored.
7. Particular attention should be given to the security of the logging facility because if tampered with it can provide a false sense of security. Controls should aim to protect against unauthorized changes and operational problems including:
   • the logging facility being de-activated,
   • alterations to the message types that are recorded,
   • log files being edited or deleted, and
   • log file media becoming exhausted and either failing to record events or overwriting itself.

9.15 Control of Operational Software

1. Control must be applied to the implementation of software on operational systems. To minimize the risk of corruption of operational systems, the following controls should be considered:
   • The updating of the operational program libraries should only be performed by the nominated librarian upon appropriate management authorization.
   • Operational systems should only hold executable code.
   • Executable code should not be implemented on an operational system until evidence of successful testing and user acceptance is obtained and the corresponding program source libraries have been updated.
   • An audit log should be maintained of all updates to operational program libraries.
   • Previous versions of software should be retained as a contingency measure.
2. Vendor supplied software used in operational systems should be maintained at a level supported by the supplier. Any decision to upgrade to a new release should take into account the security of the release, i.e. the introduction of new security functionality or the number and severity of security problems affecting this version. Software patches should be applied when they can help to remove or reduce security weaknesses.

9.16 Access control to source library

In order to reduce the potential for corruption of computer programs, strict control must be maintained over access to program source libraries.

1. Program source libraries should not be held in operational systems.
2. A program librarian should be nominated for each application.
3. IT support staff should not have unrestricted access to program source libraries.
4. Programs under development or maintenance should not be held in operational program source libraries.
5. The updating of program source libraries and the issuing of program sources to programmers should only be performed by the nominated librarian upon authorization from the IT support manager for the application.
6. Program listings should be held in a secure environment.
7. An audit log should be maintained of all accesses to program source libraries.
8. Old versions of source programs should be archived, with a clear indication of the precise dates and times when they were operational, together with all supporting software, job control, data definitions and procedures.
9. Maintenance and copying of program source libraries should be subject to strict change control procedures.

9.17 Change Control Process

1. The implementation of changes must be strictly controlled by the use of formal change control procedures to minimize the risk of system corruption. These formalized change controls must be enforced. They should ensure that security and control procedures are not compromised, that programmers are given access to only those units required for their work and that formal approvals are obtained. Changing application software can impact the operational environment. Whenever practical, application and operational change procedures should be integrated. These processes should include:
   • maintaining a record of agreed authorization levels,
   • ensuring changes are submitted by authorized personnel,
   • reviewing controls and procedures to ensure they will not be compromised by the changes submitted,
   • identifying all the software, databases and hardware that require change,
   • obtaining formal approval before work commences,
   • ensuring the changes are carried out to minimize any possible disruptions,
   • ensuring the system documentation is current,
   • maintaining version control on all updates,
   • maintaining an audit trail of all change requests,
   • ensuring that operational documentation and user procedures reflect the new environment, and (K) ensuring that the changes are implemented without business disruption.
2. Test environments should be separated from development and production environments.

9.18 Restrictions on changes to software

Modification to software packages must be discouraged and essential changes controlled. Only when deemed essential, should the packages be modified. The following points should be considered:

1. the possibility of controls and processes included in the base software being compromised,
2. the necessity of obtaining the vendor’s consent,
3. the possibility of the vendor including the changes into the base offering, and
4. the impact of incorporating these changes in future releases of the base software.

9.19 Intrusion Detection System (IDS)

1. Network IDS utilize traffic analysis to compare session data against a known database of popular application attack signatures. On detection, the network IDS can react by logging the session alerting the administrator, terminating the session and even reconfiguring the firewall or router to block selected traffic
2. Host IDS compare application / internal service log events against a known database of security violations and custom policies. If a breach of policy occurs, the host IDS can react by logging the action alerting the administrator and, in some cases, stopping the action prior to execution.
3. Application-Level IDS rely upon custom applications to log unauthorized or suspect activity and / or produce an alert. An example of an Application-Level IDS would be a Web application which maintains its own internal user / password system. Attempts to circumvent this system would not be noticed by a Network IDS or recorded by a Host IDS.

9.20 Controls on Malicious software

1. Detection and prevention controls to protect against malicious software and appropriate user awareness procedures must be implemented. Protection against malicious software should be based on security awareness appropriate system access and change management controls. The following procedures should be implemented:
   • compliance with software licenses and prohibiting the use of unauthorized software,
   • protection against risks associated with obtaining files and software either from or via external networks or on any other medium, indicating what protective measures should be taken,
   • installation and regular update of anti-virus detection and repair software to scan computers and media either as a precautionary control or on a routine basis,
   • regular reviews of the software and information content of systems supporting critical business processes—the presence of any unapproved files or unauthorized amendments should be formally investigated,
   • verification of files on electronic media of uncertain or unauthorized origin, or files received over un-trusted networks, for viruses before use,
   • verification of any electronic mail attachments and downloads for malicious software before use—this check may be carried out at different places, e.g., at electronic mail servers, desk top computers or when entering the network of the organization,
   • assignment of responsibilities to deal with the virus protection on systems, training in their use, reporting and recovering from virus attacks,
   • appropriate business continuity plans for recovering from virus attacks, including all necessary data and software back-up and recovery arrangements,
   • verification of all information relating to malicious software and ensure that warning bulletins are accurate and informative, and
   • verification that qualified sources, e.g., reputable journals, reliable Internet sites or anti-virus software suppliers are used to differentiate between hoaxes and real viruses.
2. Staff should be made aware of the problem of hoaxes and what to do on receipt of them. These controls are especially important for network file servers supporting large numbers of workstations.

9.21 Firewalls

1. Firewalls’ functionality must be documented and detail how they manage security policy as applied to network traffic and how they maintain internal security.
2. System documentation must detail the following:
   • Purpose / Business rationale for the system
   • Services offered, including business rationale
   • Rationale for the choice of platform, operating system, components and configuration.
   • Adjacent or integrated systems.
   • Modifications to the default system software configuration
   • Installed software
   • Installed software configuration
   • Installed hardware
   • Installed hardware configuration
   • Support contracts
   • Software licenses
   • Hardware lease details
   • Process for shutdown, restart and recovery
   • System maintenance schedule

9.22 External Facilities Management

1. The use of an external contractor to manage information processing facilities may introduce potential security exposures, such as the possibility of compromise, damage, or loss of data at the contractor’s site. Prior to using external facilities management services, the risks must be identified, and appropriate controls agreed with the contractor, and incorporated into the contract.
2. Particular issues that should be addressed include:
   • identifying sensitive or critical applications better retained in-house,
   • obtaining the approval of business application owners,
   • implications for business continuity plans,
   • security standards to be specified, and the process for measuring compliance,
   • allocation of specific responsibilities and procedures to effectively monitor all relevant security activities, and
   • responsibilities and procedures for reporting and handling security incidents.

10.0 Legal Requirements

All security related aspects of information processing may be subject to statutory or contractual security requirements. Each agency must be aware of their responsibilities as dictated by legislation and other legal commitments particularly as they apply to the information systems and practices required by the federal and state governments. All agencies should put in place the appropriate procedures to ensure compliance with legal considerations.

10.1 Software Copyright

Proprietary software products are usually supplied under a license agreement that limits the use of the products to specified machines and may limit copying to the creation of back-up copies only. The following controls should be implemented:

1. publishing software copyright compliance procedures which define the legal use of software and information products,
2. maintaining awareness of the software copyright and acquisition procedures and giving notice of the intent to take disciplinary action against staff who breach them,
3. maintaining appropriate asset registers,
4. maintaining proof and evidence of ownership of licenses, master disks, manuals, etc.,
5. implementing controls to ensure that any maximum number of users permitted is not exceeded,
6. carrying out checks that only authorized software and licensed products are installed,
7. providing procedures for maintaining appropriate license conditions, and
8. providing procedures for disposing or transferring software to others

10.2 Protection of Information

1. Important records of an organization must be protected from loss, destruction and falsification. Some records may need to be securely retained to meet statutory or regulatory requirements as well as to support essential business activities. The time period and information content for retention may be set by federal and state laws or regulations.
2. Records should be categorized into record types, such as accounting records, database records, transaction logs audit logs and operational procedures, each with details of retention periods and type of storage media, e.g. paper, microfiche, magnetic, optical. Any related cryptographic keys associated with encrypted archives or digital signatures, should be kept securely and made available to authorized persons when needed.
3. Consideration should be given to the possibility of degradation of media used for storage of records. Storage and handling procedures should be implemented in accordance with Manufacturer’s recommendations.
4. Wherever electronic storage media are chosen, procedures to ensure the ability to access information (both media and format readability) throughout the retention period should be included, to safeguard against loss due to future technology change.
5. The system of storage and handling should ensure clear identification of records and of their statutory or regulatory retention period. It should permit appropriate destruction of records after that period if they are not needed by the organization.
6. To meet these obligations, the following steps should be taken within an organization:
   • Guidelines should be issued on the retention, storage, handling and disposal of records and information.
   • A retention schedule should be drawn up identifying essential record types and the period of time for which they should be retained.
   • An inventory of sources of key information should be maintained.
   • Appropriate controls should be implemented to protect essential records and information from loss, destruction and falsification.

10.3 Privacy of Personal information

1. In many cases, legislation controls the processing and transmission of personal information (generally information on living individuals who can be identified from that information). Such controls impose responsibilities on those collecting, processing and disseminating personal information.
2. Controls must be applied to protect personal information in accordance with relevant legislation. Compliance with information protection legislation requires appropriate management structure and control. It is the responsibility of the owner of the information to ensure the information is protected and that there is awareness by all users of the information protection principles defined in the relevant legislation.