<?xml version="1.0"?>
<standard status="released">
<standardinfo>
<title>Generic Security Standard</title>
<titleabbrev>LCZ-GSS</titleabbrev>
<edition>1.1</edition>
<pubdate>16 May 2009</pubdate>
<abstract>
<para>This document defines a set of baseline generic information security controls 
applicable to any computerised information system. Additionally it provides guidance
to administrators, developers and security personnel to assist in enhancing the security
of implementations of applications and the technologies that underpin them.</para>
</abstract>
<revhistory>
<revision>
<revnumber>1.1</revnumber>
<date>16 May 2009</date>
<authorinitials>FOD</authorinitials>
<revremark>Revised for re-release</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>13 January 2003</date>
<authorinitials>LCZ</authorinitials>
<revremark>Initial Draft for public release</revremark>
</revision>
</revhistory>
<copyright>
<year>2001</year><year>2002</year><year>2003</year><year>2009</year>
<holder>Frank O'Dwyer</holder>
</copyright>
</standardinfo>
<intro>
<objectives>
<objective>To define a set of baseline generic information security controls
applicable to any computerised information system.</objective>
<objective>To provide guidance to administrators, developers and security personnel to assist
in enhancing the security of implementations of applications and the technologies
that underpin them.</objective>
</objectives>
<scope>
<para>Controls specified in this document apply to all IT platforms.</para>
<para>All of the organisation's information systems
will be subject to the policies specified within
this generic security standard. The policies will be applied to new and existing installations.
</para>
</scope>
<out-of-scope>
<para>Compliance with this standard will not provide <quote>in depth</quote> security architecture or intelligent security design guidance
to projects. As a consequence, for high impact or safety-critical business applications, additional guidance will still need to be 
sought from your Information Security team consultancy function or other appropriate source of security skill.  
</para>
<para>This is a generic standard. Controls specific to particular technologies are not 
defined here but will be the subject of additional standards.
</para>
<para>Compliance with this standard does not negate the need for an overall security review 
of a proposed application.
</para>
</out-of-scope>
<commonintrostuff/>
<relateddocs/>
<definitions>
<definition>
<para>An <quote>Information Asset</quote> equates to any computerised information system 
or component thereof and thus includes an application, an item of off the shelf software, hardware, media, 
a data item, a data item repository and associated communications networks.</para>
<para>The specification of 
the Information Asset in question will usually be given so that this document is unambiguous, except
where a control relates to any <quote>Information Asset</quote>. </para>
</definition>
<definition>
<para>The use of <quote>must</quote> or <quote>will</quote> indicates what the author considers to be a mandatory control.</para>
<para>However, whether the controls listed here are mandatory for your organisation is entirely at your organisation's discretion and
thus they should be interpreted as representing the strongest recommendation of the author.</para>
</definition>
<definition>
<para>The use of <quote>should</quote> or <quote>recommended</quote> or <quote>ought</quote> indicates
that the author believes that the controls in question are worthwhile and should be implemented unless such
an implementation is impossible, onerous or impractical. Again, the implementation of controls so recommended
in this document is entirely at your organisation's discretion.</para>
</definition>
</definitions>
</intro>
<controlchapter><title>Desktop Security Requirements</title>
<controlsection><title>Logical Access Controls</title>
</controlsection>
<controlsection><title>Security Management and Administration</title>
</controlsection>
<controlsection><title>Security Incident Reporting</title>
</controlsection>
<controlsection><title>Physical Access Controls</title>
</controlsection>
<controlsection><title>Protection from malicious software</title>
</controlsection>
</controlchapter>
<controlchapter><title>Portable and off site computing requirements</title>
<controlsection><title>Physical access controls</title>
</controlsection>
<controlsection><title>Security management and administration</title>
</controlsection>
<controlsection><title>General security points</title>
</controlsection>
<controlsection><title>Logical access controls</title>
</controlsection>
<controlsection><title>Protection from malicious software</title>
</controlsection>
</controlchapter>
<controlchapter><title>Network Security Requirements</title>
<controlsection><title>Data Back-up controls</title>
</controlsection>
<controlsection><title>Dialup Connection Security</title>
</controlsection>
<controlsection><title>Dialup Security Management Issues</title>
</controlsection>
<controlsection><title>Third Party Access - Customers</title>
</controlsection>
<controlsection><title>Access controls</title>
</controlsection>
<controlsection><title>Management Controls</title>
</controlsection>
<controlsection><title>Physical security controls</title>
</controlsection>
<controlsection><title>Network Devices</title>
</controlsection>
</controlchapter>
<controlchapter><title>Personnel Security</title>
<controlsection><title>Security in job descriptions</title>
</controlsection>
<controlsection><title>Reporting of security matters</title>
</controlsection>
<controlsection><title>Recruitment</title>
</controlsection>
<controlsection><title>Education and Awareness</title>
</controlsection>
</controlchapter>
<controlchapter><title>User Configuration</title>
<controlsection><title>User Administration</title>
<control level="baseline" techversion="Any" title="Each user must be given a unique account" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-USER-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:User Administration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Each user must be given a unique account with which to access an information asset.</policy-statement>
<checklist-question>Has each user been given a unique account?</checklist-question>
<howto>
<step>Create a unique user account for all who access the information system.</step>
<step>Identify shared accounts and replace with unique accounts for the sharing users </step>
</howto>
<risks-addressed>
<risk>Sharing accounts may result in a loss of availability during password change</risk>
<risk>Sharing accounts results in password disclosure </risk>
<risk>Sharing accounts may result in unauthorised access</risk>
<risk>Sharing accounts may result in fraudulent misuse</risk>
<risk>Sharing accounts may result in malicious misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="A pre-defined naming convention should be used for user accounts" environment="Any" pleading="recommended" versionMaj="1" id="GSS-USER-5" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:User Administration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>User accounts should be set up in accordance with a pre-defined naming convention.</policy-statement>
<checklist-question>Are user accounts set up in accordance with a pre-defined naming convention?</checklist-question>
<howto>
<step>A recommended naming convention is first 3 letters of surname max, first letter of forename and next available two digit numeric counter. For example, &quot;Calum Cooper&quot; equates to COOC01. The use of such a convention caters for technologies that restrict username maximum length to 6 characters but will nonetheless render consistent, unique usernames across all technologies for all users.</step>
<step>The application/system authentication subsystem should be designed to permit usernames of the length required by your convention to be supported</step>
</howto>
<risks-addressed>
<risk>Access may not be removed due to inconsistent user naming</risk>
<risk>Unauthorised access to such accounts may then occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="All requests for user account creation must be correctly authorised" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-USER-4" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:User Administration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>All requests for user account creation must be correctly authorised.</policy-statement>
<checklist-question>Does a business process exist to ensure that all requests for user account creation are correctly authorised?</checklist-question>
<howto>
<step>The creation of a user account must be approved by the business owner of the application in question or their nominee. </step>
<step>Where the account requested is for a non-application type system, the account request must be approved by the user&apos;s line manager</step>
</howto>
<risks-addressed>
<risk>Unauthorised access may be granted</risk>
<risk>Unauthorised functionality may be granted</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Temporary or contract user accounts should have fixed period lifetimes" environment="Any" pleading="recommended" versionMaj="1" id="GSS-USER-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:User Administration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Temporary or contract users should be given accounts with fixed period lifetimes in accordance with the duration of their contracts/period of engagement.</policy-statement>
<checklist-question>Have temporary or contract users been given accounts with fixed period lifetimes?</checklist-question>
<howto>
<step>User account management should be used to set a user account lifetime</step>
<step>Application logic should enable a user account lifetime to be set.</step>
<step>Ensure that the system date and time are correctly set</step>
<step>The process for getting access must obtain employment end dates.</step>
<step>During account creation ensure that the employment end date is entered.</step>
</howto>
<risks-addressed>
<risk>Unauthorised access may occur</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Account login time restrictions should be put in place to prevent access outside of required working hours" environment="Any" pleading="recommended" versionMaj="1" id="GSS-USER-9" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:User Administration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Account login time restrictions should be put in place to prevent access outside of required working hours</policy-statement>
<checklist-question>Are account login time restrictions in place to prevent access outside of required working hours?</checklist-question>
<howto>
<step>Determine required access times for users</step>
<step>Implement login time restrictions outside of these working hours</step>
</howto>
<risks-addressed>
<risk>Unauthorised access may occur</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="User accounts logged in after hours should be disconnected" environment="Any" pleading="recommended" versionMaj="1" id="GSS-USER-10" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:User Administration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>User accounts logged in after hours should be disconnected</policy-statement>
<checklist-question>Are user accounts logged in after hours should disconnected?</checklist-question>
<howto>
<step>Determine required access times for users</step>
<step>Implement login time restrictions outside of these working hours</step>
<step>Set the system to automatically disconnect users outside of these working hours</step>
</howto>
<risks-addressed>
<risk>Unauthorised access may occur</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Default Accounts</title>
<control level="baseline" techversion="Any" title="Delete all non-essential default accounts after installation" environment="Any" pleading="recommended" versionMaj="1" id="GSS-USER-6" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Default Accounts" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Guest accounts and all non-essential default accounts should be deleted from the system following initial installation</policy-statement>
<checklist-question>Have guest accounts and all non-essential default accounts been deleted from the system following initial installation?</checklist-question>
<howto>
<step>If it is impossible or undesirable then default accounts must be disabled.</step>
<step>Do not delete accounts absolutley required to run system processes</step>
<step>Do not lock yourself out of the system by disabling all accounts </step>
<step>Create the appropriate administrative accounts required for support</step>
</howto>
<risks-addressed>
<risk>Unauthorised unprivileged access may be obtained</risk>
<risk>Unauthorised privileged access may be obtained</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Generic accounts should not be created" environment="Any" pleading="recommended" versionMaj="1" id="GSS-USER-8" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Default Accounts" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Wherever possible, generic accounts should be avoided</policy-statement>
<checklist-question>Have all generic accounts been removed or disabled?</checklist-question>
<howto>
<step>Provide individual, non-shared accounts for all users.</step>
<step>Generic accounts should only be created where it is unavoidable to do so</step>
<step>Any generic accounts should not be capable of being logged into by users</step>
</howto>
<risks-addressed>
<risk>Unauthorised non-privileged access may occur</risk>
<risk>Unauthorised privileged access may occur</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Passwords of all default acccounts must be changed from their initial value" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-USER-7" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Default Accounts" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The passwords of all accounts created during software installation must be changed from their default values immediately upon completion of the installation</policy-statement>
<checklist-question>Have the passwords of all accounts created during software installation been changed from their default values?</checklist-question>
<howto>
<step>Identify accounts created during the installation of the software item in question.</step>
<step>Change the passwords for each account created.</step>
</howto>
<risks-addressed>
<risk>Unauthorised non-privileged access may be obtained</risk>
<risk>Unauthorised privileged access may be obtained</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Roles, Views, and Access Control</title>
<control level="baseline" techversion="Any" title="Access permissions on sensitive objects should be as restrictive as possible" environment="Any" pleading="recommended" versionMaj="1" id="GSS-ACCE-5" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Access permissions on sensitive objects should be as restrictive as possible</policy-statement>
<checklist-question>Are the access permissions on sensitive objects as restrictive as possible?</checklist-question>
<howto>
<step>Identify the sensitive objects</step>
<step>Identify what the minimum access control permissions that are required for each object whilst ensuring normal functioning</step>
<step>Set the minimum access control permissions against each oject</step>
<step>Monitor for changes to these permissions</step>
</howto>
<risks-addressed>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Access to data, system and application software objects must be consistently enforced in line with access controls throughout the entire application architecture" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ACCE-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Access to data, system and application software objects must be consistently enforced in line with access controls throughout the entire application architecture</policy-statement>
<checklist-question>Is access to data, system and application software objects consistently enforced, in line with access controls throughout the entire application architecture?</checklist-question>
<howto>
<step>if a user has access to functions x, y, z and data items a, b and c check that at the database level, the operating system level and at the network level that the user is unable to use these different view points to exceed these access restrictions.</step>
</howto>
<risks-addressed>
<risk>Subverting application access control through direct access to the database</risk>
<risk>Subverting applicaton access control by direct access to the operating system</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Users should be provided with captive, menu driven accounts and prevented from accessing functions or data at the operating system level." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ACCE-4" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Users should be provided with captive, menu driven accounts and prevented from accessing functions or data at the operating system level.</policy-statement>
<checklist-question>Are users provided with captive, menu driven accounts and prevented from accessing functions or data at the operating system level?</checklist-question>
<howto>
<step>Use OS access controls to prevent access to the command line.</step>
<step>Develop the application such that the underlying OS is invisible to the user.</step>
</howto>
<risks-addressed>
<risk>Subverting applicaton access control by direct access to the operating system</risk>
<risk>Subverting DBMS access control by direct access to the operating system</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Application users must not be able to access the underlying operating system upon which their application is running." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ACCE-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Application users must not be able to access the underlying operating system upon which their application is running.</policy-statement>
<checklist-question>Can application users access the underlying operating system upon which their application is running?</checklist-question>
<howto>
<step>Use OS access controls to prevent direct access by users.</step>
<step>Ensure all user access is provided through the application interface.</step>
</howto>
<risks-addressed>
<risk>Subverting applicaton access control by direct access to the operating system</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Command line access should be denied except for administrative users." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ACCE-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Command line access should be denied except for administrative users.</policy-statement>
<checklist-question>Is command line access denied except for administrative users?</checklist-question>
<howto>
<step>Use OS access controls to prevent access to the command line.</step>
<step>Use build tailoring to remove access to command line prompts</step>
</howto>
<risks-addressed>
<risk>Subverting applicaton access control by direct access to the operating system</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Access or functionality provided to users at remote or untrusted locations should be kept to a minimum level." environment="Any" pleading="recommended" versionMaj="1" id="GSS-ACCE-6" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Access or functionality provided to users at remote or untrusted locations should be kept to a minimum level.</policy-statement>
<checklist-question>Is access or functionality provided to users at remote or untrusted locations kept to a minimum level.</checklist-question>
<howto>
<step>Use OS access controls to prevent unnecessary access by remote non-privileged users</step>
<step>Ensure that the access control permissions on the data objects available to remote users are the minimum required</step>
</howto>
<risks-addressed>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Application privilege, functionality allocations and logical access controls at the operating system and database level must be able to support and implement any legal or regulatory control requirements for the application/system in question." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ACCE-7" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Application privilege, functionality allocations and logical access controls at the operating system and database level must be able to support and implement any legal or regulatory control requirements for the application/system in question.</policy-statement>
<checklist-question>Are any legal or regulatory control requirements supported and implemented by the application/system implementation?</checklist-question>
<howto>
<step>Ensure that any legal or regulatory controls required to be delivered by an application are well defined and well understood.</step>
<step>For each of these regulatory/legal controls, constraints, requirements that the design or the actuality of the application is able to support them.</step>
<step>For new applications, design the application to deliver against these regulatory/legal requirements.</step>
<step>For existing applications determine through a gap analysis the components that need to be delivered or enhanced to deliver against these regulatory requirements,</step>
</howto>
<risks-addressed>
<risk>Regulatory non-compliance</risk>
<risk>Legal non-compliance</risk>
<risk>Legal action</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Enforce appropriate administrative segregation of duties" environment="Any" pleading="recommended" versionMaj="1" id="GSS-ACCE-8" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>System administration, operations, security administration and security monitoring should be defined as discrete groups and granted only those privileges required to perform their respective job functions.</policy-statement>
<checklist-question>Are system administration, operations, security administration and security monitoring defined as discrete functional groups and granted only those privileges required to perform their respective job functions.</checklist-question>
<howto>
<step>Use OS administrative controls to grant access and privileges only to those who require them based upon their job function.</step>
<step>For an application under development ensure that the administrative functionality includes the ability to separate function and privilege and that the application supports the notion of the job functions.</step>
</howto>
<risks-addressed>
<risk>Regulatory non-compliance</risk>
<risk>Legal non-compliance</risk>
<risk>Legal action</risk>
<risk>Subverting organisational control</risk>
<risk>Subverting operational control</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Access to the super user/administrator user account must be controlled" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ACCE-9" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Roles, Views, and Access Control" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Processes and procedures should be developed to control access to the superuser/administrator account. In particular, the password for this account should be maintained under management control.</policy-statement>
<checklist-question>Is access to the superuser/administrator account maintained under management control?</checklist-question>
<howto>
<step>Use OS administrative controls to grant access and privileges only to those who require them based upon their job function.</step>
<step>Maintain the password for the superuser/administrator accounts in a physically secure manner with tamper evident packaging e.g. an envelope with edges and flaps sealed in pressure sensitive tape, such that any attempted access to the password value is detectable.</step>
<step>Maintain records of the use made of the superuser password and change the password after it has been used to a new value.</step>
<step>Store the password values using the tamper evident packaging described above in a fire proof safe.</step>
<step>Place the keys to the safe under dual management control. </step>
</howto>
<risks-addressed>
<risk>Regulatory non-compliance</risk>
<risk>Legal non-compliance</risk>
<risk>Legal action</risk>
<risk>Subverting organisational control</risk>
<risk>Subverting operational control</risk>
<risk>Compromise of the entire system</risk>
<risk>Subversion of management control</risk>
<risk>Subversion of organisational control</risk>
<risk>Bypass of functional control</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Privileges</title>
<control level="baseline" techversion="Any" title="User accounts must be created with least privilege" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-PRIV-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Privileges" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>User accounts should be created and maintained with the fewest privileges required to successfully execute the users job function.</policy-statement>
<checklist-question>Are user accounts created and maintained with the fewest privileges required to successfully execute the users job functions?</checklist-question>
<howto>
<step>Determine the implications of each privilege within the Information Asset.</step>
<step>Grant only privileges necessary for the user to perform their job function.</step>
</howto>
<risks-addressed>
<risk>Misuse of privilege can be accidental or malicious</risk>
<risk>The less privilege held the less the potential impact misuse might have</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Software should run with minimum privilege" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-PRIV-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Privileges" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Programmes, utilities and application software should be developed to run with the minimum of privileges to successfully perform their function.</policy-statement>
<checklist-question>Is software installed and run with the minimum privileges required to successfully execute its function.</checklist-question>
<howto>
<step>Define the functions the software under development needs to perform.</step>
<step>For each function, determine any requirement for an elevated privilege.</step>
<step>Grant only those privileges specifically identified as required.</step>
</howto>
<risks-addressed>
<risk>Software always contains bugs which may allow privileges  to be miused.</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Non-administrative users must not be given administrative privileges or rights" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-PRIV-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Privileges" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Non-administrative users must not be granted administrative privileges or rights</policy-statement>
<checklist-question>Are non-administrative users  granted administrative privileges or rights?</checklist-question>
<howto>
<step>Ensure that administrative privileges are only granted to identified administrative users</step>
</howto>
<risks-addressed>
<risk>Misuse of privilege, accidental or deliberate may result in system compromise</risk>
<risk>Privileged accounts are the most prized target for attackers</risk>
<risk>The fewer administrative privileged accounts the better</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Authentication/Password Configuration</title>
<control level="baseline" techversion="Any" title="Passwords must be stored in a one-way hashed format" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-8" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Passwords must be stored in a one-way hashed format.</policy-statement>
<checklist-question>Are passwords stored in a one-way hashed format?</checklist-question>
<howto>
<step>A one way hashing algorithm such as SHA-1 must be used to transform the password entered by the user to its encrypted value.</step>
<step>A salt-value must be used to reduce the ease with which dictionary based/known ciphertext attacks may be launched against the hashed values</step>
<step>An iteration count may also be used to further complicate dictionary attacks</step>
<step>The hash values must be accessible only to privileged users or the system</step>
</howto>
<risks-addressed>
<risk>Bulk cracking of passwords depends on access to the hashed values</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="above baseline" techversion="Any" title="The password minimum length for users must be 8 characters minimum." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-12" availability-level="above baseline" disclosure-level="above baseline" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="above baseline" dp-level="above baseline" safety-level="above baseline">
<revhistory>
</revhistory>
<policy-statement>In higher risk environments or uses, the password minimum length for end users must be set to 8 characters.</policy-statement>
<checklist-question>Is the password minimum length 8 characters?</checklist-question>
<howto>
<step>Configure the information asset to enforce a password min length of 8.</step>
<step>If developing an authentication subsystem ensure it supports 8 char min length</step>
</howto>
<risks-addressed>
<risk>Shorter passwords are easier to guess or exhaustively search.</risk>
<risk>Accounts may therefore be easily compromised.</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Passwords must be transmitted across the internal network in encrypted form" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-9" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>When a password is entered and transmitted across the internal network it should be done so in encrypted form.</policy-statement>
<checklist-question>Are passwords transmitted across the internal network in encrypted form?</checklist-question>
<howto>
<step>If the solution includes an encryption option, turn it on.</step>
<step>Consider use of SSL or TLS for encryption of TCP connections.</step>
<step>Consider use of IPSEC for network level encryption.</step>
</howto>
<risks-addressed>
<risk>Unencrypted passwords are subject to disclosure.</risk>
<risk>Passwords discovered may be used for unauthorised access</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Passwords must be at least 6 characters in length" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH_11" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Password minimum length for non-privileged users must be 6 characters.</policy-statement>
<checklist-question>Is the password minimum length for non-privileged users 6 characters?</checklist-question>
<howto>
<step>Configure the information asset such that the password minimum length is 6.</step>
<step>If developing an authentication subsystem ensure it supports this control.</step>
</howto>
<risks-addressed>
<risk>Passwords shorter than 6 characters may be easily guessed.</risk>
<risk>Passwords shorter than 6 characters may be easy to exhaustively search.</risk>
<risk>Unauthorised access may be obtained</risk>
<risk>Malicious misuse may occur</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="A warning banner must be displayed prior to login" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-21" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Prior to logon, all systems must display a warning message advising of the consequences of misuse and that monitoring of usage may be performed.</policy-statement>
<checklist-question>Is a warning banner displayed prior to login?</checklist-question>
<howto>
<step>The banner text used must be approved in your legislative environment.</step>
<step>The banner text used must be appropriate to the culture of your organisation.</step>
<step>Setup the information asset to display the chosen messages prior to logon.</step>
<step>If the OS cannot provide this facility it should be developed in the application.</step>
</howto>
<risks-addressed>
<risk>Warning against misuse makes it clear that access must be authorised</risk>
<risk>Systems that &quot;welcome&quot; users before authentication may legitimise attacks</risk>
<risk>Prosecution of abusers may be inhibited by a failure to warn </risk>
<risk>Other legal infringements may occur if warnings are not given in advance</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="The repository used to store hashed passwords must not be accessible to non-privileged users" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-10" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Password files must not be accessible to non-privileged users.</policy-statement>
<checklist-question>Are password files/password repositories accessible to non-privileged users?</checklist-question>
<howto>
<step>Use OS access controls to prevent access by local non-privileged users</step>
<step>Use distributed access control to deny access to remote non-privileged users</step>
</howto>
<risks-addressed>
<risk>Access to password files may allow malicious users to subvert passwords</risk>
<risk>Unauthorised access to business systems may occur as a result.</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="An idle timeout facility should be in place on desktop workstations/terminals" environment="Any" pleading="recommended" versionMaj="1" id="GSS-AUTH-20" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Desktop hardware systems such as workstations/terminals etc should have an idle timeout facility such that after a period of inactivity the workstation/terminal user must re-authenticate to resume access.</policy-statement>
<checklist-question>Is an idle timeout facility in use on the desktop?</checklist-question>
<howto>
<step>Use OS access controls to enforce an idle timeout</step>
<step>Where it is unavailable it must be developed as a component of the application</step>
</howto>
<risks-addressed>
<risk>Unattended logged in desktops are open to misuse by all with access to it</risk>
<risk>Unauthorised access may be obtained</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Date and time of last login must be displayed following successful login" environment="Any" pleading="recommended" versionMaj="1" id="GSS-AUTH-19" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Successful log-ons should be followed immediately by a display of the date and time of the last log-on, together with details of any unsuccessful attempts since that time.</policy-statement>
<checklist-question>After a successful log-ons is the date and time of the last log-on, together with details of any unsuccessful attempts since that time, displayed?</checklist-question>
<howto>
<step>Configure the asset to to display the last login and failed attempts after login</step>
<step>Implement a product to provide this information if not available inherently</step>
<step>If developing an authentication subsystem build these features in</step>
</howto>
<risks-addressed>
<risk>Last logins will indicate anomalous use</risk>
<risk>Failures since last login also indicate attempts to gain access</risk>
<risk>A failure to report on these things may permit ongoing breaches</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="User passwords must expire after a maximum of 60 days" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-14" availability-level="baseline" disclosure-level="baseline" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="baseline" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>User account passwords must expire after a maximum of 60 days.</policy-statement>
<checklist-question>Do user account passwords expire ater 60 days?</checklist-question>
<howto>
<step>Configure the information asset to set password lifetimes to 60 days.</step>
<step>Develop the authentication system of the asset to support variable lifetimes</step>
</howto>
<risks-addressed>
<risk>Infrequently changed passwords are more likely to be guessed.</risk>
<risk>A guessed password is usable for longer than those more frequently changed</risk>
<risk>Unauthorised non-privileged access may be obtained</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Passwords must not be echoed on screen in plain text" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-7" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>A password must not be echoed on screen in plain text, whether entered by a user during logon or password change.</policy-statement>
<checklist-question>Are passwords echoed on screen using asterisk characters or similar, rather than plain text?</checklist-question>
<howto>
<step>Ensure that the password change function in the authentication subsystem is developed so as to mask the characters entered during the login dialogue or the password change dialogue.</step>
</howto>
<risks-addressed>
<risk>Disclosure of a password may result in unauthorised access</risk>
<risk>Unauthorised access may result in fraudulent misuse</risk>
<risk>Unauthorised access may result in malicious misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Passwords must be expired following reset or account creation" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-22" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>To ensure that the period of time is minimised during which more than one user knows the password for the same account, passwords must be set in an expired form when accounts have been newly created or after a password is reset.</policy-statement>
<checklist-question>Are passwords set to be expired following password or account creation?</checklist-question>
<howto>
<step>Ensure new accounts are created with the password set expired.</step>
<step>Ensure that reset account passwords are set to as expired.</step>
<step>If developing an authentication system ensure it supports password expiry.</step>
</howto>
<risks-addressed>
<risk>When a new account is created the creator and the user know the password</risk>
<risk>When a password is reset the restter and the user know the password</risk>
<risk>New and reset passwords are often set to a well known default value</risk>
<risk>A loss of accountability results from these problems</risk>
<risk>Unauthorised access may ensue</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Authentication failure must not indicate which authentication field is invalid" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-6" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Authentication failure messages must not indicate which of the authentication fields are invalid</policy-statement>
<checklist-question>Do authentication failure messages hide which of the authentication fields are invalid?</checklist-question>
<howto>
<step>Ensure that the authentication subsystem provides no information during failure</step>
</howto>
<risks-addressed>
<risk>Providng knowledge of which component is wrong aids an attacker</risk>
<risk>This allows a more focused attack</risk>
<risk>Unauthorised access may occur as a result</risk>
<risk>Malicious misuse may occur</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="There should be a mechanism to prevent the selection of weak, easily guessed, passwords." environment="Any" pleading="recommended" versionMaj="1" id="GSS-AUTH-18" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>There should be a mechanism to prevent the selection of weak, easily guessed, passwords.</policy-statement>
<checklist-question>Is there a method of preventing the selection of weak, easily guessed passwords?</checklist-question>
<howto>
<step>Use the information assets configuration controls to increase pwd complexity</step>
<step>If developing an authentication system include password complexity controls</step>
<step>Implement password complexity/filtering software additionally where required.</step>
<step>Reject passwords that are present in a dictionary of common passwords</step>
<step>Reject passwords derived from dictionary words (e.g. &quot;word123&quot;)</step>
<step>Reject passwords equal to or derived from user ID</step>
<step>Reject passwords that are based on information about the user that may be guessed</step>
<step>Require passwords to include punctuation and digits as well as letters</step>
<step>Consider also requiring upper case characters in passwords</step>
</howto>
<risks-addressed>
<risk>Weak passwords may be easily guessed.</risk>
<risk>An easily guessed password allows accounts to be subverted and access gained.</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="above baseline" techversion="Any" title="Strong authentication should be implemented" environment="Any" pleading="recommended" versionMaj="1" id="GSS-AUTH-4" availability-level="above baseline" disclosure-level="above baseline" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="above baseline" dp-level="above baseline" safety-level="above baseline">
<revhistory>
</revhistory>
<policy-statement>For above baseline applications/systems stronger forms of authentication are required than reusable passwords. Under such circumstances the use of tokens, smartcards, biometrics and zero knowledge proof authentication mechanisms are considered as potential solutions.</policy-statement>
<checklist-question>For above baseline applications, has a strong authentication mechanism been implemented?</checklist-question>
<howto>
<step>Use available &quot;strong&quot;  authentication where your organisation already has this</step>
<step>Where no infrastructure is available, a deployment should be undertaken.</step>
</howto>
<risks-addressed>
<risk>Strong authentication provides greater assurance of identity</risk>
<risk>Unauthorised access may be obtained</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Users must provide a valid username and password to access an information asset" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-3" availability-level="baseline" disclosure-level="baseline" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="baseline" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>For baseline applications, users must provide a valid username and password to access an information asset.</policy-statement>
<checklist-question>For baseline applications, are users required to provide a valid username and password?</checklist-question>
<howto>
<step>Use OS authentication to enforce username and password control</step>
<step>Ensure  the authentication mechanism supports usernames and passwords</step>
</howto>
<risks-addressed>
<risk>Unauthenticated access allows arbitrary access</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="A software locking on demand facility should be available on the desktop" environment="Any" pleading="recommended" versionMaj="1" id="GSS-AUTH-23" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Desktop hardware systems such as workstations/terminals etc should allow the user to lock their workstation without the need to logout of the underlying applications.</policy-statement>
<checklist-question>Is a desktop software locking facility available to users?</checklist-question>
<howto>
<step>Use OS functionality to permit localised locking of workstations.</step>
<step>If no such facility exists applications should be locked where possible</step>
<step>Applications without a lock facility should be logged out when unattended.</step>
</howto>
<risks-addressed>
<risk>Unattended logged in workstations or application terminals are vulnerable</risk>
<risk>Physical access may allow unauthorised logical access to occur</risk>
<risk>Unauthorised logical access may result in fraudulent misuse</risk>
<risk>Unauthorised logical access may result in malicious misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Administrative user passwords must have a maximum  lifetime of 30 days" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-15" availability-level="baseline" disclosure-level="baseline" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="baseline" dp-level="baseline" safety-level="baseline">
<revhistory>
</revhistory>
<policy-statement>Administrative accounts must have a maximum password lifetime of 30 days</policy-statement>
<checklist-question>Do administrative accounts have a maximum password lifetime 30 days?</checklist-question>
<howto>
<step>Configure all admin accounts to have 30 day pass lifetimes</step>
<step>If developing an authentication system ensure it supports variable pwd lifetimes</step>
</howto>
<risks-addressed>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Admin user passwords must have a maximum lifetime of 7 days" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-16" availability-level="above baseline" disclosure-level="above baseline" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="above baseline" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Admin user passwords must have a maximum lifetime of 7 days.</policy-statement>
<checklist-question>Do admin user passwords have a maximum lifetime of 7 days?</checklist-question>
<howto>
<step>Configure administration accounts to have a password lifetime of 7 days</step>
<step>If developing an authentication system ensure it supports variable pwd lifetimes</step>
</howto>
<risks-addressed>
<risk>The longer a pwd goes unchanged the greater the chance of compromise</risk>
<risk>Administrative users passwords are the most prized by attackers</risk>
<risk>Unauthorised privileged access may be obtained.</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="The system must prevent password re-use for at least 12 changes" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-17" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The system should prevent password re-use for at least 12 changes. That is, the authentication subsystem must include a password history function that prevents a password being set that figures in the 12 previously used passwords for that user.</policy-statement>
<checklist-question>Is a password history function enabled preventing the 12 previous passwords being reused?</checklist-question>
<howto>
<step>Configure the pwd history function to prevent  reuse of last 12 passwords.</step>
<step>If developing an authentication system ensure it includes a history function.</step>
<step>Ensure the function provides equal protection to historic pwds as to the current</step>
<step>Ensure that historic passwords are stored in one way hashed form.</step>
<step>Ensure that access to historic pwd values is not available non admin users</step>
</howto>
<risks-addressed>
<risk>Reusing the same passwords may lead to a password compromise</risk>
<risk>A password compromise may lead to unauthorised access</risk>
<risk>Unauthorised access may lead to fraudulent misuse</risk>
<risk>Unauthorised access may lead to malicious misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="The user identifier and the password must be validated in a single operation" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-AUTH-5" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="User Configuration:Authentication/Password Configuration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The user identifier and the password entered must be validated in a single operation and not as separate steps.</policy-statement>
<checklist-question>Is the user identifier and password validated in a single operation?</checklist-question>
<howto>
<step>Only authenticate when both the username and the password have been entered.</step>
</howto>
<risks-addressed>
<risk>Indicating the step that has failed during authentication aids an attacker</risk>
<risk>Unauthorised access may result</risk>
<risk>Fraudulent misuse may occur</risk>
<risk>Legal or regulatory obligations may be breached</risk>
<risk>Malicious misuse may occur</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
</controlchapter>
<controlchapter><title>Security Compliance</title>
<controlsection><title>Security Compliance Checking</title>
<control level="baseline" techversion="Any" title="Live data must not be supplied to 3rd parties for testing" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-TEST-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Compliance Checking" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Live data must not be supplied to external organisations for the purpose of testing application changes or for the diagnosis/resolution of problems.</policy-statement>
<checklist-question>Is it ensured that live data is not supplied to 3rd parties for testing?</checklist-question>
<howto>
<step>The procedures for support by third parties must not permit live data disclosure</step>
</howto>
<risks-addressed>
<risk>Business information may be disclosed.</risk>
<risk>Legal/regulatory rules may be breached</risk>
<risk>Censure from regulatory bodies may occur as a result</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Administrators must use analysis tools to detect account weaknesses" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-9" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Compliance Checking" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The administrators must have and make use of security administration tools which facilitate the identification of security weaknesses  e.g. dead, unused or inappropriate accounts, accounts without password protection or accounts with weak passwords.</policy-statement>
<checklist-question>Do the administrators use analysis tools to detect account weaknesses?</checklist-question>
<howto>
<step>Install a security analysis tool</step>
<step>Use the analysis tool to identify account weaknesses</step>
<step>Use the output to define an action plan for changes</step>
<step>Implement the changes</step>
</howto>
<risks-addressed>
<risk>Analysing account security helps to implement controls compliance</risk>
<risk>A failure to analyse account security may allow attackers to gain access</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Security Management</title>
<control level="baseline" techversion="Any" title="Information owners must annually audit their user community" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MAN-7" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Information Asset Owners must conduct an annual audit of their user community in order to ensure that  each user has a continuingly valid need to access the information asset</policy-statement>
<checklist-question>Do the information owners annually audit their user community?</checklist-question>
<howto>
<step>Produce a schedule of all information assets and their respective owners. </step>
<step>Produce a list of users for the information asset concerned.</step>
<step>Provide the information to the owner and action any account changes resulting</step>
</howto>
<risks-addressed>
<risk>Ongoing unauthorised access may result in a breach of controls</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Physical output should be afforded appropriate physical protection" environment="Any" pleading="recommended" versionMaj="1" id="GSS-PHYS-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The control of physical output from an application, such as printouts, should be afforded consistent levels of physical control and protection that are logically in place within the application from which it originates</policy-statement>
<checklist-question>Is physical output afforded appropriate physical protection?</checklist-question>
<howto>
<step>Identify the physical outputs from the system.</step>
<step>Identify how the electronic equivalents are controlled within the application</step>
<step>Put in place physical security controls to ensure the protection over the outputs</step>
<step>Shred sensitive documents</step>
</howto>
<risks-addressed>
<risk>There is no point having good logical controls if other output is poorly handled</risk>
<risk>Dumpster diving often reveals sensitive information</risk>
<risk>Unauthorised access may be obtained</risk>
<risk>Unauthorised access mar result in fraudulent or malicious misuse</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="A recovery plan should be in place for every system within acceptable time" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-DISA-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>An appropriate recovery plan must be in place for each information asset to enable processing to resume within an acceptable time delay in the event of a disaster.</policy-statement>
<checklist-question>Is a recovery plan in place for every system within an acceptable time?</checklist-question>
<howto>
<step>Determine the business impact of a loss of service.</step>
<step>Produce a resumption plan based upon the critical time scale</step>
<step>Walk through the plan to test its likelihood of success.</step>
<step>Revisit the plan with any changes arising from the testing.</step>
</howto>
<risks-addressed>
<risk>Business information and applications may be unavailable.</risk>
<risk>Money may be lost.</risk>
<risk>Service may be lost</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="All user owned files must be reassigned 6 weeks after the user leaves or deleted" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-6" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Six weeks after a user leaves, with the approval of the appropriate line manager, all accounts that belong to the leaver must be deleted. At which time any files owned by these accounts must be either deleted or reallocated.</policy-statement>
<checklist-question>Are all files reassigned 6 weeks after a user leaves or deleted?</checklist-question>
<howto>
<step>The leaver process should say user files are deleted or reassigned after 6 weeks</step>
</howto>
<risks-addressed>
<risk>Orphaned data ojects may contain sensitive information</risk>
<risk>These objects may become owned by newly created users</risk>
<risk>Access to these objects may be unauthorised</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Contingency plans must be kept up to date." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-DISA-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Contingency plans must be kept up to date.</policy-statement>
<checklist-question>Are the contingency plans kept up to date?</checklist-question>
<howto>
<step>On an annual basis repeat the business impact assessment for the system</step>
<step>If the analysis has changed check the plan is adequate.</step>
<step>On an annual basis review the technical aspects of the restoration plan</step>
<step>Determine if the technical plan are able to support the asset in its current state. Where it cannot, additional provisioning should be put in place.</step>
</howto>
<risks-addressed>
<risk>Requirements change and that should be reflected in the recovery pan</risk>
<risk>A failure to reflect that in the plan may render it ineffective</risk>
<risk>Business information and applications may be unavailable.</risk>
<risk>Money may be lost</risk>
<risk>Service may be denied</risk>
<risk>Reputation of your organisation may be damaged</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Insurance arrangements should be adopted to provide additional protection" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-DISA-5" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Insurance arrangements should be adopted to provide additional protection against certain risks</policy-statement>
<checklist-question>Have insurance arrangements been adopted to provide additional protection?</checklist-question>
<howto>
<step>If a loss from a disaster can be well defined, an insurance policy is prudent</step>
</howto>
<risks-addressed>
<risk>The financial consequences of a breach or loss of service can be mitigated</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Contingency plans must be based upon risk analysis" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-DISA-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Contingency plans must be based upon risk analysis</policy-statement>
<checklist-question>Are contingency plans based upon risk analysis?</checklist-question>
<howto>
<step>Perform an impact assessment to determine the impact of loss of service.</step>
<step>Based upon the impact of the loss of service build an appropriate plan</step>
</howto>
<risks-addressed>
<risk>Failing to resource where really needed may lead to a crucial loss of service</risk>
<risk>Loss of service for some systems may threaten the viability of the organisation</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Changes must not compromise security" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-12" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The change management function must ensure that changes do not compromise security controls.</policy-statement>
<checklist-question>Is it ensured that the change management function ensure that changes do not compromise security controls.</checklist-question>
<howto>
<step>Ensure any change control committees are attended by information security.</step>
<step>Ensure all changes include authorisation from the information security dept.</step>
</howto>
<risks-addressed>
<risk>Unauthorised changes may result in unauthorised access </risk>
<risk>Unauthorised changes may lead to a loss of service</risk>
<risk>Unauthorised access may result in fraudulent or malicious misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Static data should be replicated where it is a single point of failure" environment="Any" pleading="recommended" versionMaj="1" id="GSS-AVAI-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Where a high impact application is reliant upon static data, this data should be replicated so as to avoid a single point of failure</policy-statement>
<checklist-question>Is static data replicated so as to avoid a single point of failure?</checklist-question>
<howto>
<step>Perform an impact assessment to determine if it is a high impact application</step>
<step>Determine from the application data model the repositories of static data</step>
<step>Decide whether the loss of the statc data is likely to severely impact the app</step>
<step>Where the loss of the static data is of high impact ensure that this is replicated.</step>
</howto>
<risks-addressed>
<risk>Fault tolerance is crucial to ensure continuity of service for high impact systems</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="User Administration must be clearly defined with documented procedures" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>User administration must be a clearly defined function with documented procedures</policy-statement>
<checklist-question>Is user administration a clearly defined function with documented procedures</checklist-question>
<howto>
<step>Identify the parties responsible for the administration of users for the system</step>
<step>Identify the information owner for the information asset under consideration.</step>
<step>Write procedures for the creation, modification and deletion of user accounts.</step>
<step>Ensure these procedures include stages for authorisation for all access</step>
</howto>
<risks-addressed>
<risk>Ensuring access granted is correct and authorised is crucial</risk>
<risk>A failure to grant access appropriately may result in misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Admin staff must be trained with clearly defined responsibilities" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-14" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The ongoing administration of platforms must be performed by trained staff with clearly defined responsibilities.</policy-statement>
<checklist-question>Are admin staff trained with clearly defined responsibilities?</checklist-question>
<howto>
<step>Ensure that all administrative jobs are well defined.</step>
<step>Ensure all administrators are trained in order to execute their job functions</step>
</howto>
<risks-addressed>
<risk>Training helps to prevent mal administration taking place</risk>
<risk>Maladministration may result in unauthorised access</risk>
<risk>Maladministration may result in a loss of service</risk>
<risk>Maladministration may result in a loss of data integrity</risk>
<risk>Unauthorised access may result in fraudulent or malicious misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Live data for internal testing should be anonymised before use" environment="Any" pleading="recommended" versionMaj="1" id="GSS-TEST-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The use of live data internally for testing should only be performed when the data has been desensitised i.e. all sensitive data overwritten</policy-statement>
<checklist-question>Is live data for internal testing anonymised before use?</checklist-question>
<howto>
<step>Ensure testing procedures include live data anonymisation</step>
<step>Ageing the data may be the only requirement.</step>
</howto>
<risks-addressed>
<risk>Testing users are not usually the same as the live users</risk>
<risk>Data may therefore be disclosed without authorisation</risk>
<risk>Legal/regulatory rules may be breached</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="When any individual leaves the organisation all access must be disabled." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-5" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>When any individual leaves the organisation all access must be disabled  immediately.</policy-statement>
<checklist-question>Is it ensured that when any individual leaves the organisation all access is  disabled immediately?</checklist-question>
<howto>
<step>Ensure that when someone leaves the security admin function is notified </step>
</howto>
<risks-addressed>
<risk>Removing access when no longer required protects against misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Changes to all live systems must be under a change management process" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-11" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Changes to all production systems must be controlled by a change management process</policy-statement>
<checklist-question>Are all changes to production systems controlled by a change management process?</checklist-question>
<howto>
<step>Ensure change processes are developed and in place for live systems.</step>
<step>Ensure that changes are subject to comment and approval prior to committing Ensure the process has the objective of ensuring continuity and quality of service.</step>
</howto>
<risks-addressed>
<risk>Change management forces inspection of planned changes</risk>
<risk>This inspection provides the opportunity to identify errors and pitfalls</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="All systems must have a nominated IT Custodian" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-10" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>All systems must have a nominated IT Custodian</policy-statement>
<checklist-question>Do all systems have a nominated IT Custodian?</checklist-question>
<howto>
<step>Ensure someone from IT is nominated as the contact for the information asset</step>
</howto>
<risks-addressed>
<risk>An individual with responsibility for a system will ensure proper support</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Contingency plans must be subject to periodic tests." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-DISA-4" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Contingency plans must be subject to periodic tests.</policy-statement>
<checklist-question>Are the contingency plans subject to periodic tests.</checklist-question>
<howto>
<step>Following a change to the plan, the plan should be re-tested.</step>
<step>Following changes in the staff, the plan should be re-tested.</step>
<step>Following the elapse of one year the plan should be re-tested.</step>
</howto>
<risks-addressed>
<risk>Testing a plan helps to ensure it will serve the purpose</risk>
<risk>A failure to test it means that any failings will only be found when in use for real</risk>
<risk>Business information and applications may be unavailable.</risk>
<risk>Money may be lost</risk>
<risk>Reputation of the organisation may be damaged</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Admin procedures must be documented, available and up to date" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-15" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Administrative procedures must be documented, comprehensive, up-to-date, accessible to authorised staff and protected from unauthorised access or loss.</policy-statement>
<checklist-question>Are the admin procedures documented, up to date and available to those who need them?</checklist-question>
<howto>
<step>Ensure that routine administrative tasks are documented.</step>
<step>Ensure that administration documents are maintained up to date.</step>
<step>Ensure that administration documents are tested.</step>
<step>Ensure that admin documentation is protected from unauthorised access</step>
</howto>
<risks-addressed>
<risk>A failure to maintain admin procedures may result in maladministration</risk>
<risk>A failure to perform administration correctly may result in a loss of service</risk>
<risk>A failure to perform administration correctly may result in a loss of integrity</risk>
<risk>A failure to perform administration correctly may result in disclosure</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="An undo function should be in the user interface for all atomic operations." environment="Any" pleading="recommended" versionMaj="1" id="GSS-INTE-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>An undo function should be available in the user interface for all atomic operations.</policy-statement>
<checklist-question>Is an undo function available in the user interface for all atomic operations?</checklist-question>
<howto>
<step>Design the app so that atomic operations can be undone via the user interface</step>
</howto>
<risks-addressed>
<risk>People make mistakes and an undo function provides rectification</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Emergency changes must include retrospective security authorisation" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-13" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Ensure that emergency changes are subject to retrospective approval from the organisations information security function</policy-statement>
<checklist-question>Are emergency changes subject to retrospective approval from the organisations information security function?</checklist-question>
<howto>
<step>Ensure emergency change procedures include retrospective security approval</step>
</howto>
<risks-addressed>
<risk>Emergency changes may be used to mask unauthorised activity</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Old userids must not be re-issued to a new user." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Old user ids must not be re-issued to a new user</policy-statement>
<checklist-question>Is it ensured that old user ids are not re-issued to a new user?</checklist-question>
<howto>
<step>In conjunction with the information owner define templates for the various roles</step>
<step>Ensure the process for creating/modifying accounts refers to the templates</step>
<step>Create a blank disabled template for each of the roles to use during the process</step>
</howto>
<risks-addressed>
<risk>Re-issuing old ids may allow access to objects that was not expected</risk>
<risk>Access to these objects may be unauthorised</risk>
<risk>Such access may lead to fraudulent or accidental misuse of the system</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Addition, modification and deletion of users must create an audit trail " environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The addition, modification and deletion of users must create an appropriate audit trail which identifies when change was actioned, the actioning party and the authorising party.</policy-statement>
<checklist-question>Does the addition, modification and deletion of users create an audit trail?</checklist-question>
<howto>
<step>Use OS access controls to prevent access by local non-privileged users</step>
<step>Use distributed access control to prevent access by remote users</step>
</howto>
<risks-addressed>
<risk>A failure to create an audit trail may mask malicious behaviour</risk>
<risk>A failure to follow appropriate procedures may result in unauthorised access</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Registers of users must be protected from loss and unauthorised access" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-MANA-8" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Security Compliance:Security Management" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Registers of users must be protected from loss and unauthorised access</policy-statement>
<checklist-question>Are the registers of users protected from loss and unauthorised access</checklist-question>
<howto>
<step>Use access controls to prevent access by local non-privileged users</step>
<step>Use safes or secure filing cabinets to protect registers of user accounts</step>
</howto>
<risks-addressed>
<risk>Unauthorised access to registers provides attackers with intelligence</risk>
<risk>This information may be used to gain unauthorised access</risk>
<risk>Unauthorised access may be used for fraudulent or malicious misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
</controlchapter>
<controlchapter><title>Software Requirements</title>
<controlsection><title>Software legislation and compliance</title>
</controlsection>
<controlsection><title>Software acquisition and implementation</title>
</controlsection>
</controlchapter>
<controlchapter><title>Network Security Configuration</title>
<controlsection><title>Network Interface Considerations</title>
<control level="baseline" techversion="Any" title="All phone lines within the company should be periodically swept for wire taps." environment="Internal" pleading="recommended" versionMaj="1" id="GSS-NET-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Network Security Configuration:Network Interface Considerations" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>All phone lines within the company should be periodically swept for wire taps.</policy-statement>
<checklist-question>Are all phone lines within the company should periodically swept for wire taps?</checklist-question>
<howto>
<step>Obtain a reflectometer</step>
<step>Use the reflectometer to detect any unauthorised attachments to the lines</step>
</howto>
<risks-addressed>
<risk>The risk of eavesdropping</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Switching based LANs should be implemented " environment="Internal" pleading="recommended" versionMaj="1" id="GSS-NET-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Network Security Configuration:Network Interface Considerations" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Switching based LANs should be implemented </policy-statement>
<checklist-question>Is switching used on LANs?</checklist-question>
<howto>
<step>For new LANs implement switches</step>
<step>For existing LANs implement a migration plan to move to switching</step>
</howto>
<risks-addressed>
<risk>The risk of eavesdropping on the LAN is reduced</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Modem telephone numbers should be changed on a periodic basis where possible" environment="Internal" pleading="recommended" versionMaj="1" id="GSS-NET-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Network Security Configuration:Network Interface Considerations" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Modem telephone numbers should be changed on a periodic basis where possible</policy-statement>
<checklist-question>Are modem telephone numbers changed on a periodic basis?</checklist-question>
<howto>
<step>On an annual basis get new numbers for your modem phone lines</step>
</howto>
<risks-addressed>
<risk>The risk of eavesdropping on the LAN is reduced</risk>
<risk>Hacking</risk>
<risk>Identification of illicit usage</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Internet Considerations</title>
<control level="baseline" techversion="Any" title="Sensitive data must be encrypted in transit across an untrusted network" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-NETW-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Network Security Configuration:Internet Considerations" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Encryption should be used to prevent disclosure of sensitive data whilst in transmission across an untrusted network</policy-statement>
<checklist-question>Is encryption used to prevent disclosure of sensitive data whilst in transmission across an untrusted network?</checklist-question>
<howto>
<step>If the solution includes an encryption option, turn it on.</step>
<step>Consider use of SSL or TLS for encryption of TCP connections.</step>
<step>Consider use of IPSEC for network level encryption.</step>
</howto>
<risks-addressed>
<risk>Unencrypted data can be read and altered on an unencrypted network.</risk>
<risk>Unencrypted data can be replayed on an unencrypted network.</risk>
<risk>Sensitive data items such as passwords can be disclosed</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
</controlchapter>
<controlchapter><title>Asset Security Requirements</title>
<controlsection><title>Ownership, Accountability and Inventories</title>
</controlsection>
<controlsection><title>Classification Labelling</title>
</controlsection>
</controlchapter>
<controlchapter><title>Compliance</title>
<controlsection><title>The Companies Act 1985</title>
</controlsection>
<controlsection><title>Data Protection Act 1998</title>
</controlsection>
<controlsection><title>Computer Misuse Act 1990</title>
</controlsection>
<controlsection><title>Information Security Policy</title>
</controlsection>
</controlchapter>
<controlchapter><title>Physical Security Requirements</title>
<controlsection><title>Outer perimeter - public access space</title>
</controlsection>
<controlsection><title>Inner perimeter - general space</title>
</controlsection>
</controlchapter>
<controlchapter><title>Internet/Email Security Requirements</title>
<controlsection><title>General Internet security requirements</title>
</controlsection>
</controlchapter>
<controlchapter><title>Configuration</title>
<controlsection><title>Files and File Permissions</title>
</controlsection>
<controlsection><title>Administration</title>
<control level="baseline" techversion="Any" title="All system administration should be performed using named accounts owned by the individual administrators " environment="Any" pleading="recommended" versionMaj="1" id="GSS-ADMIN-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Configuration:Administration" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>All system administration should be performed using named accounts owned by the individual administrators </policy-statement>
<checklist-question>iS system administration performed using named accounts owned by the individual administrators?</checklist-question>
<howto>
<step>Create administrative accounts for each administrator on the system</step>
<step>Disable the default administrator account if possible</step>
</howto>
<risks-addressed>
<risk>Loss of administrative accountability.</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Backups</title>
<control level="baseline" techversion="Any" title="Backup recovery timescales must be verified as acceptable" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-BACK-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Configuration:Backups" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The ability to recover data from backup media within timescales acceptable to the organisation must be verified.</policy-statement>
<checklist-question>Have the backup recovery timescales between verified as acceptable to the organisation?</checklist-question>
<howto>
<step>Determine the data recovery times required for the application in question.</step>
<step>Determine the length of time it takes to perform a restore</step>
<step>Where these two times conflict adjust the recovery process accordingly.</step>
</howto>
<risks-addressed>
<risk>Recovering data from backups within certain timescales may be critical</risk>
<risk>A failure to recover in a timely manner may cause financial loss</risk>
<risk>A failure to recover in a timely manner may cause a loss of business</risk>
<risk>A failure to recover in a timely manner may cause a loss of reputation</risk>
<risk>A failure to recover in a timely manne may cause censure</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Backup media must be stored securely at a remote location when not in use" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-BACK-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Configuration:Backups" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Backup media, except when in use, must be stored at a secure location, remote from the originating information asset to which it relates.</policy-statement>
<checklist-question>Are backup media stored securely at a remote location when not in use</checklist-question>
<howto>
<step>Develop a backup cycle that demands storage of media at a secure remote site.</step>
</howto>
<risks-addressed>
<risk>Should the information asset be destroyed ensure the backup does not go with it</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="above baseline" techversion="Any" title="Highly confidential data on backup media should be encrypted." environment="Any" pleading="mandatory" versionMaj="1" id="GSS-BACK-4" availability-level="Any" disclosure-level="above baseline" technology="Any" versionMin="0" section="Configuration:Backups" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Highly confidential data on backup media should be encrypted to prevent disclosure.</policy-statement>
<checklist-question>Ar backups encrypted where it has been identified that highly confidential data is being written?</checklist-question>
<howto>
<step>Ensure that the backup solution includes an encryption option.</step>
<step>Use the encryption option to protect the backups.</step>
</howto>
<risks-addressed>
<risk>Legal proceedings may result </risk>
<risk>The organisation may be subject to censure</risk>
<risk>The reputation of the organisation may be damaged</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Backup media must no be used more times than recommended maximum" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-BACK-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Configuration:Backups" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Backup media must not be used more times than the number recommended by the media manufacturer.</policy-statement>
<checklist-question>Is the number of times backup media are used recorded and prevented from being used more times than the manufacturers recommended maximum?</checklist-question>
<howto>
<step>Identify the number of times the media can be used.</step>
<step>Develop a backup cycle that includes a procedure for checking media ageing.</step>
<step>Destroy the media securely at the end of its useful life</step>
</howto>
<risks-addressed>
<risk>Recovering data is dependent upon the ability to successfully read the media</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
</controlchapter>
<controlchapter><title>System Development and Maintenance Requirements</title>
<controlsection><title>General Software Requirements</title>
</controlsection>
<controlsection><title>Change Control Procedures</title>
</controlsection>
<controlsection><title>Application system security</title>
</controlsection>
<controlsection><title>Security requirements for Analysis and Specification</title>
</controlsection>
<controlsection><title>Test Data Security</title>
</controlsection>
<controlsection><title>Control of operational software</title>
</controlsection>
<controlsection><title>Security of electronic office systems</title>
</controlsection>
</controlchapter>
<controlchapter><title>Installation</title>
<controlsection><title>Setup Choices</title>
<control level="baseline" techversion="Any" title="The latest version of the operating system should be installed wherever possible" environment="Any" pleading="recommended" versionMaj="1" id="GSS-INST-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Installation:Setup Choices" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The latest version of the operating system should be installed wherever possible</policy-statement>
<checklist-question>Is the latest version of the operating system installed wherever possible?</checklist-question>
<howto>
<step>Obtain the latest version of the operating system</step>
<step>Install the latest version of the operating system</step>
</howto>
<risks-addressed>
<risk>Later versions of software often contain security fixes</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="The RAID level selected should be appropriate to the criticality of the applications and the risks associated with disk failure" environment="Any" pleading="recommended" versionMaj="1" id="GSS-HARD-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Installation:Setup Choices" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The RAID level selected should be appropriate to the criticality of the applications and the risks associated with disk failure</policy-statement>
<checklist-question>Is the RAID level selected appropriate to the criticality of the applications and the risks associated with disk failure?</checklist-question>
<howto>
<step>Identify the raid levels available</step>
<step>Identify the availability requirements of the system</step>
<step>Implement the most appropriate raid level according to the availability requirements</step>
</howto>
<risks-addressed>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="All servers should be connected to an uninterruptible power supply" environment="Any" pleading="recommended" versionMaj="1" id="GSS-HARD-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Installation:Setup Choices" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>All servers should be connected to an uninterruptible power supply</policy-statement>
<checklist-question>Are all servers connected to an uninterruptible power supply?</checklist-question>
<howto>
<step>Ensure that machine rooms are served with UPS capability</step>
<step>Connect the servers to the UPS</step>
</howto>
<risks-addressed>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="The most secure implementation of the operating system should be selected at installation time" environment="Any" pleading="recommended" versionMaj="1" id="GSS-INST-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Installation:Setup Choices" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The most secure implementation of the operating system should be selected at installation time</policy-statement>
<checklist-question>Is the most secure implementation of the operating system selected at installation time?</checklist-question>
<howto>
<step>Security related choices at installation time should be selected on the basis of the most secure option.</step>
</howto>
<risks-addressed>
<risk>Extended security functionality is often only available if selected as an installation option.</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="All available patches for the operating system should be applied" environment="Any" pleading="recommended" versionMaj="1" id="GSS-INST-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Installation:Setup Choices" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>All available patches for the operating system should be applied</policy-statement>
<checklist-question>Are all available patches for the operating system applied?</checklist-question>
<howto>
<step>Identify available patches for the operating system</step>
<step>Test the patches</step>
<step>Implement the patches</step>
</howto>
<risks-addressed>
<risk>Security vulnerabilities may go unfixed</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
</controlchapter>
<controlchapter><title>Auditing and Monitoring</title>
<controlsection><title>Events to be alerted in real-time</title>
<control level="baseline" techversion="Any" title="Systems must be able to detect/alert attempts to breach controls in real time" environment="Any" pleading="recommended" versionMaj="1" id="GSS-ALER-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Events to be alerted in real-time" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Information Assets must be able to detect attempts to circumvent security controls and to provide alerts in real time of such attempts. For example repeated unsuccessful login attempts above a certain threshold should raise an automatic alarm to the security monitoring function or system administration team.</policy-statement>
<checklist-question>Is the system able to detect/alert attempts to breach controls in real time?</checklist-question>
<howto>
<step>Use the native real time security alerting system to provide alerts</step>
<step>Where an asset is under development ensure it includes an alert mechanism</step>
<step>Consider the deployment of event monitoring software to interpret events</step>
</howto>
<risks-addressed>
<risk>A failure to identify attempted breaches allows attempts to continue</risk>
<risk>Ongoing attempts to gain access will eventually succeed if left unchecked</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Systems must have a form of breakin evasion" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-RESP-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Events to be alerted in real-time" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Systems must be able to measure the number of consecutive log-on attempts irrespective of time span, and no more than six such failures must be allowed before automatic protective action occurs.</policy-statement>
<checklist-question>Does the system have a form of breakin evasion?</checklist-question>
<howto>
<step>Use the native O/S and authentication subsystem to identify breakin attempts</step>
<step>Employ breakin evasion techniques when the threshold is breached, such as;</step>
<step>Not permiting any further login attempts from that source</step>
<step>Hanging up the line if it is a dial connection</step>
<step>Not permitting login regardless of authentication of the userid and password</step>
<step>Disabling the user account that is subject to the login failures.</step>
<step>Where an app is under development it should include breakin evasion ability </step>
</howto>
<risks-addressed>
<risk>The ability to take positive action during attack safequards the system.</risk>
<risk>A failure to take action may result in a successful breach of the system</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Audit log destination and format</title>
<control level="baseline" techversion="Any" title="Audit log content must not be modifiable to non-privileged users or apps" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ELOG-4" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Audit log destination and format" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Audit log content must not be writable or modifiable to non-privileged users and applications</policy-statement>
<checklist-question>Has it been ensured that the audit log content is not writable or modifiable by non-privileged users and applications?</checklist-question>
<howto>
<step>Use access control to prevent write access by non-privileged users and apps</step>
</howto>
<risks-addressed>
<risk>The ability to modify the content of the event log may mask malicious actions</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Audit log records must be retained for a minimum of thirteen months" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ELOG-5" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Audit log destination and format" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Audit log records must be retained for a minimum of thirteen months</policy-statement>
<checklist-question>Are the audit log records retained for a minimum of thirteen months?</checklist-question>
<howto>
<step>Ensure the backup procedure ensures audit log data is retained for 13 months</step>
</howto>
<risks-addressed>
<risk>You may need to reconstruct events over the course of a financial year</risk>
<risk>A failure to keep this data may mask malicious events</risk>
<risk>A failure to keep this data may make reconstruction of events impossible</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Audit logs must only be written to by the operating system or trusted apps" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ELOG-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Audit log destination and format" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Audit/event logs must only be written to by trusted operating system and application software</policy-statement>
<checklist-question>Is the audit/event log only written to by the operating system or trusted apps?</checklist-question>
<howto>
<step>Use access control to prevent writes from non-privileged users and software.</step>
<step>Use distributed access control to prevent access by remote non-privileged users</step>
</howto>
<risks-addressed>
<risk>The ability to write to the event log may be used to right misleading events</risk>
<risk>The ability to delete events from the event log may mask malicious behaviour</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="above baseline" techversion="Any" title="Critical applications systems must maintain their own audit trails" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ELOG-6" availability-level="above baseline" disclosure-level="above baseline" technology="Any" versionMin="0" section="Auditing and Monitoring:Audit log destination and format" integrity-level="above baseline" dp-level="Any" safety-level="baseline">
<revhistory>
</revhistory>
<policy-statement>Critical application systems must maintain their own audit trails</policy-statement>
<checklist-question>Does the application maintain its own audit trail?</checklist-question>
<howto>
<step>Use the inbuilt auditing subsystem of the system to create an audit log.</step>
<step>If developing, ensure the app includes support for writing to its own audit log</step>
</howto>
<risks-addressed>
<risk>Critical apps must keep a record of events that are not subject to interference</risk>
<risk>Failing to maintain an event log may make reconstruction of events impossible</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Audit log content must not be visible to non-privileged users" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ELOG-3" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Audit log destination and format" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Audit log content must not be visible to non-privileged users</policy-statement>
<checklist-question>Is the audit log content prevented from access by non-privileged users</checklist-question>
<howto>
<step>Use OS access controls to prevent read access by non-privileged users</step>
<step>Use distributed access control to prevent access by remote non-privileged users</step>
</howto>
<risks-addressed>
<risk>Audit logs often contain information and events useful to attackers</risk>
<risk>Providing access to this information may lead to unauthorised access</risk>
<risk>Unauthorised access may lead to malicious or fraudulent misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
<controlsection><title>Events to be audited</title>
<control level="baseline" techversion="Any" title="Events captured must be sufficient to establish accountability for actions" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-EVEN-1" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Events to be audited" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The security events recorded within the log of an Information Asset must be sufficient to establish individual accountability for actions performed and be able to support the investigation and resolution of suspected violations.</policy-statement>
<checklist-question>Are the events captured must be sufficient to establish accountability for actions?</checklist-question>
<howto>
<step>Define the set of events to be recorded within the auditing subsystem</step>
<step>If an app is in development ensure that business events are captured</step>
<step>If an app is in development ensure that technical events are captured</step>
</howto>
<risks-addressed>
<risk>Capturing events allows an audit trail of activity to be created</risk>
<risk>A failure to capture events prevents abnormal activity from being identified</risk>
<risk>This allows an attackers behviour to unnoticed.</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Audit logs must be reviewed periodically to identify suspicious event patterns" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-RESP-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Auditing and Monitoring:Events to be audited" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Audit logs must be reviewed periodically to identify security incidents or suspicious patterns of events.</policy-statement>
<checklist-question>Are audit logs reviewed periodically to identify security incidents or suspicious patterns of events?</checklist-question>
<howto>
<step>Define patterns of events that are normal for the system in question </step>
<step>Investigate patterms of events that fall outside these normal patterns</step>
<step>If the pattern proves to be valid add it to the normal pattern knowledge base.</step>
<step>If the pattern remains anomalous analyse it on the basis that it is an attack</step>
</howto>
<risks-addressed>
<risk>Attacks may go unidentified </risk>
<risk>Fraudulent activity may go unidentified</risk>
<risk>Breaches of business rules may go unidentiified</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlsection>
</controlchapter>
<controlchapter><title>Other</title>
<control level="baseline" techversion="Any" title="Cryptographic controls should be used to verify the integrity of transactions" environment="Any" pleading="recommended" versionMaj="1" id="GSS-INTE-4" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Other" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Cryptographic controls such as message authentication codes, digital signatures etc should be used to verify the integrity of critical transactions</policy-statement>
<checklist-question>Are cryptographic controls used to verify the integrity of transactions?</checklist-question>
<howto>
<step>Identify the critical transactions within the application</step>
<step>Use cryptographic integrity checks to validate the data within these functions</step>
</howto>
<risks-addressed>
<risk>Business information may be accidentally or maliciously altered.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Audit logs must be protected from deletion" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-ELOG-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Other" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Audit logs must be protected from deletion</policy-statement>
<checklist-question>Is the audit/event log protected from deletion</checklist-question>
<howto>
<step>Use OS access controls to prevent delete access by non-privileged users</step>
</howto>
<risks-addressed>
<risk>Deletion of the event log may be used to mask malicious actions</risk>
<risk>Deletion of the event log may mask fraudulent misuse</risk>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="above baseline" techversion="Any" title="Ensure keys and algorithms used to encypt backups are correctly stored" environment="Any" pleading="mandatory" versionMaj="1" id="GSS-BACK-5" availability-level="Any" disclosure-level="above baseline" technology="Any" versionMin="0" section="Other" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>The protection of encryption keys and algorithms used in encrypting backups needs to be ensured to reduce the risk of the keys and algorithms being disclosed, altered or destroyed

</policy-statement>
<checklist-question>Are the encryption keys and algorithms used in encrypting backups protected against disclosure, alteration or destruction?

</checklist-question>
<howto>
<step>The backup solution must include key management to prevents key discloure</step>
<step>The backup solution must include key management to prevents key alteration</step>
<step>The backup solution must include key management to prevents key destruction</step>
</howto>
<risks-addressed>
<risk>Key and algorithm information may be accidentally or deliberately altered</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
<control level="baseline" techversion="Any" title="Dialogues should include a commit function" environment="Any" pleading="recommended" versionMaj="1" id="GSS-INTE-2" availability-level="Any" disclosure-level="Any" technology="Any" versionMin="0" section="Other" integrity-level="Any" dp-level="Any" safety-level="Any">
<revhistory>
</revhistory>
<policy-statement>Dialogues should be developed in the application interface that seek confirmation prior to committing a sensitive transaction within the application</policy-statement>
<checklist-question>Are dialogues included in the application interface that seek confirmation prior to committing a sensitive transaction within the application?</checklist-question>
<howto>
<step>Identify the sensitive functions that will be in the application.</step>
<step>Ensure that for these functions include confirmation dialogues are developed</step>
</howto>
<risks-addressed>
<risk>Business information may be accidentally or maliciously altered.</risk>
<risk>Business information may be disclosed.</risk>
<risk>Business information and applications may be unavailable.</risk>
</risks-addressed>
</control>
</controlchapter>
</standard>

