|
||||||||||
![]() |
|
|
|||||||||||||||
|
Resources |
|
2.1 Physical Security
All hosts and network equipment MUST be located in secure accommodation commensurate with protecting assets carrying the Protective Marking of RESTRICTED.
2.2 User Education
All employees of the organisation and where relevant contractors and third party users MUST receive appropriate awareness training and awareness updates in organisational policies and procedures as relevant for their job function. A personal commitment statement or acceptable usage policy MUST be in place, or users MUST have otherwise positively confirmed their acceptance that communications sent or received by means of the GSi may be intercepted or monitored. Employees of the organisation who handle information carrying a protective marking of RESTRICTED MUST be made of aware of the impact of loss of such material and the actions to take in the event of any loss.
2.3 Incident response
Information Security events MUST be reported through appropriate internal management channels as quickly as possible. Management responsibilities SHOULD be established to ensure quick, effective and orderly response to Information Security incidents. The organisation MUST report Information Security incidents to UNIRAS.
2.4 Compliancy Checking
An IT Health Check SHOULD be performed every 12 months as part of the annual GSi re-authorisation submission.
2.5 Access Control
Each user of the GSX connected network MUST be allocated a unique user ID. Each user of the network connected to GSX MUST be reliably authenticated by means of a sufficiently complex password. Each user of the network connected to GSX who has regular access to RESTRICTED information or information that originates from the GSX MUST be at least 'Basic Check' cleared.
2.6 Network Schematic
The connecting organisation MUST submit a network schematic that details the networks that will utilise the GSX connection. This diagram MUST document all onward connections and remote access.
2.7 IP Addressing
The IP address block used for the organisations’ internal network SHOULD be one of those defined within RFC1918. Servers MUST have static IP addresses (even if DHCP is used).
2.8 Firewalls
A firewall MUST be installed between the organisation and the GSX. A firewall MUST be installed between the organisation and any third party networks it connects to. Additional recommendations contained within NISCC Technical Note 10/04 SHOULD be evaluated. Approval SHOULD be gained from NISCC before opening firewall ports not specified in this document. The firewall MUST be configured according to the guidance referenced from the Guidance Notes to this document to minimise the likelihood of successful attack against the network
2.9 Intrusion Detection
Intrusion detection mechanisms SHOULD be in place to identify potential attacks. If implemented, intrusion detection measures SHOULD monitor intrusions both within the organisation’s domain and between the organisation’s domain and connected networks. If implemented, intrusion detection mechanisms SHOULD include a signature-based network IDS where the signatures are checked for updates at least daily. If implemented, network-based intrusion prevention services may require connection inline within the network. In this case, organisations SHOULD ensure that the architecture and configuration of the IPS limits access to the management stations to authorised users only.
2.10 Mobile Working
If mobile services are accessed from outside the United Kingdom then users SHOULD be made aware of the risks of using IT equipment abroad. Mobile solutions accessing GSX connected networks MUST follow the guidance referenced from the Guidance Notes to this document. In the event that mobile solutions do not make use of assured protection they SHOULD at least make use of FIPS140-2 approved products. Mobile solutions such as Blackberry SHOULD be secured and architected in accordance with CESG Guidance.
2.11 Proxies
All HTTP and SMTP services SHOULD pass through a proxy server. Where you need to bypass the central GSi proxy for other services you MUST consult NISCC. Proxy servers MUST ensure users are authenticated and that access controls are enforced for each user.
2.12 Service Obfuscation
Measures SHOULD be put in place to minimise the details of the internal network structure and components that are passed outside the organisation. Network Address Translation (NAT) SHOULD be used to obfuscate details regarding the organisation’s internal IP address ranges. E-mails sent from GSX to other security domains (e.g. The Internet) SHOULD have their details obfuscated (e.g. headers replaced with the gateway details). Details of the particular types of security scanning and other tools that an e-mail may have passed through SHOULD be removed from the e-mail.
2.13 Protective Monitoring
Audit logs recording user activities, exceptions and information security events MUST be produced to assist in future investigations and access control monitoring. All logs MUST be retained for a minimum of six months. Organisations MUST also be aware of any additional legislation that may require them to hold logs for longer periods.
2.14 Operating System
Hosts MUST run a file system supporting access controls that limit access to only the required operations and data. (e.g. FAT32 is not sufficient.). Where Windows 98 hosts are still in use (pending upgrade) the hosts MUST use NTLM 2 to provide more secure network access.
2.15 Configuration
All hosts MUST be security hardened. Referenced guides MUST be evaluated and applied where practicable.Organisations SHOULD take steps to adequately disinfect any host that has been infected by malware.
2.16 Software Policies
All hosts MUST be security hardened. Referenced guides MUST be evaluated and applied where practicable. Organisations SHOULD take steps to adequately disinfect any host that has been infected by malware.
2.17 Patch Management
Countermeasures SHOULD be provided to prevent the execution of software not authorised by the administrator on hosts according to the organisations policy. Changes to the standard build of hosts SHOULD be denied unless there is a valid business case.
2.18 Vulnerability Scanning
A patch management scheme MUST be established for all software used on the network. Vendors' web sites, NISCC and UNIRAS alerts MUST be monitored and relevant software and service packs MUST be applied where practicable. Unpatchable software MUST not be used. Where legacy applications are in use that run on un-patchable software the organisation SHOULD identify an upgrade path for these applications.
2.19 Web Browsers
Hosts SHOULD be scanned for the presence of security vulnerabilities at least quarterly. Organisational policy SHOULD define the ports that are allowed to be open for each host and initiate incident response if an unknown port is open. The vulnerability scanner SHOULD not be run from the host being scanned. The signatures used to identify vulnerabilities SHOULD be up to date and the product SHOULD be supported by the vendor or distributor with signature updates.
2.20 Content Analysis
The network SHOULD at least identify viruses, macros, dangerous file-types (e.g. executable), mobile code and spyware. Content analysis of all incoming and outgoing data SHOULD be performed at the organisation's gateway and hosts. The gateway and hosts SHOULD use content analysis software from different vendors.
2.21 Personal Firewalls
Personal Firewalls MUST be installed. Unprivileged users and processes MUST not be able to disable or reconfigure the Personal Firewall software. The personal firewall MUST implement a default deny policy and SHOULD only allow those services that are explicitly required.
2.22 Macros
Support for macros MUST be disabled unless there is a valid BUSINESS CASE for their use. Where macros are used, macro security SHOULD be set to High so that only macros from Administrator-controlled sources are run.
2.23 Removable Media
Access to removable media SHOULD be disabled unless there is a valid BUSINESS CASE for their use. Any data introduced through removable media SHOULD be subject to the same countermeasures as any incoming e-mail (e.g. it SHOULD be checked by two, functionally different virus checkers). Removable media SHOULD be handled in a accordance with S(E)N's 04/03 and 04/04.
2.24 E-Mail
HTML SHOULD be disabled for incoming e-mails. Automatic previewing of E-mails SHOULD be disabled. Filtering against a white list of allowed attachment file types SHOULD be in place. Executables, scripts, HTML, encrypted or password-protected files SHOULD not be allowed unless there is a valid BUSINESS CASE for their use. The filename extension, contents and format of the file SHOULD be checked. E-mail MUST be virus checked at the network boundary and at the host. The two virus checkers SHOULD be functionally independent (produced by different vendors). E-mail MUST not be automatically forwarded to a lower classification domain. Where there is a valid business case to send bulk e-mail across the GSi to large numbers of recipients, or to send large file attachments, organisation's SHOULD contact Cable and Wireless to ensure that there is no impact on the availability of the GSi mail service.
2.25 Mail Servers
A Mail Transport Agent (MTA), capable of sending and receiving mail using SMTP in accordance with RFC822 MUST be used. All e-mail sent to lower protectively marked GSi domains and the Internet MUST be routed via the central GSi mail relay using the organisation's GSi connection. This means that all email sent to the Internet via this route MUST be scanned by the Message Labs service that scans all inbound and outbound GSi email traffic. An e-mail content check SHOULD be carried out on all inbound data to identify and block (or convert to benign text formats) HTML and active content. The mail server SHOULD initiate all transfers of mail to and from the mail proxy. The source e-mail address for all e-mail sent via GSX from a GSX-connected networked MUST be of the format username@organisation.gsx.gov.uk The format of the username portion of the e-mail address is at the discretion of the organisation. Countermeasures preventing spoofed GSX email entering the organisation's GSX connected network SHOULD be implemented.
2.26 Mail Labelling
The mail client or user SHOULD add a warning to each e-mail to the effect that all communications sent to or from their organisations may be subject to recording and/or monitoring in accordance with relevant legislation.
2.27 Multi-Domains
If GSX-connected applications are being presented to a domain with a lower protective marking organisations SHOULD seek to limit the attack path back into their GSIX connected network by at least implementing dual factor authentication for remote users and ensuring that any application is appropriately segregated from the rest of the internal network. If applications are being presented to a less trusted domain (e.g. The Internet) reference guides MUST be evaluated and applied where practicable. Where organisations wish to connect to other Public Sector networks that are connected to the GSi (e.g. PNN, NHS, TESTA) they MUST refer to the change control process referenced from this document.
2.28 Voice Over IP
Any VOIP implementation MUST review the NIST Security Considerations for Voice Over IP Systems guidance
|