CoCo Compliance Workshop General Guidance

1
CoCo Compliance Workshop General Guidance

• Speakers
• Nigel Rainford (Account Manager, North)
• Peter Fagan (High Level Security Introduction)
• Warren Cain (General CoCo Guidance)
• Niall McElroy (General CoCo Guidance).

2
Good Business Practice and 27001

• LA complying or in the process of complying to
  27001 will be addressing a significant number of
  the GC CoCo controls. The CoCo and 27001
  complement one another
• Best practice for configuration control
• Patch management
• User education
• etc
• Best practice for incident reporting
• Internal
• External (WARP etc).

3
CoCo Assessment
4
High Level Aim and Objectives

• Provide best practice on CoCo compliance
• Now
• Annual Review against action plan
• Future
• FAQs from other Local Authorities
• Implementation Awareness.

5
Common CoCo Issues

• User Education
• Definition of ITHC
• Sufficiently Complex password
• Baseline personal security check
• Firewall use and type
• New dedicated
• Existing chassis
• Network schematic level and detail
• Definition of mobile working
• Un-patchable software
• Equipment hardening
• Definition of hosts against specific CoCo
  controls
• Web browsers
• Use in admin mode
• Active code
• Macros
• Use
• Creation
• Removable media

6
Security Themes Throughout the CoCo (1)

• Defence In Depth - Not all Eggs in One Basket
• There is little point in having the most up to
  date technological solution if attackers can
  physically remove, damage or destroy systems and
  information
• All about sufficient risk mitigation e.g.
  physical security can sometimes be used as a
  replacement for technology
• e.g. If you have strong physical controls that
  only allow one person to gain access to a
  computer do you still need a password on the
  computer?

7
Security Themes Throughout the CoCo (2)

• Start with a secure system
• Lockdown all services
• Only unlock those services which your users
  require and for which there is a valid business
  case
• Leads to an inherently more secure system, but
  requires a culture change from the standard
  leave it all open and lock it down if there is a
  known vulnerability.

8
CoCo Controls

• 2.1 - Physical Security
• 2.2 - User Education
• 2.3 - Incident Response
• 2.4 - Compliance Checking
• 2.5 - Access Control
• 2.6 - Network Schematic
• 2.7 - IP Addressing
• 2.8 - Firewalls
• 2.9 - Intrusion Detection
• 2.10 - Mobile Working
• 2.11 - Proxies
• 2.12 - Service Obfuscation
• 2.13 - Protective Marking
• 2.14 - Operating System
• 2.15 - Configuration

• 2.16 - Software Policies
• 2.17 - Patch Management
• 2.18 - Vulnerability Scanning
• 2.19 - Web Browsers
• 2.20 - Content Analysis
• 2.21 - Personal Firewalls
• 2.22 - Macros
• 2.23 - Removable Media
• 2.24 - E-Mail
• 2.25 - Mail Servers
• 2.26 - Mail Labelling
• 2.27 - Multi-Domains
• 2.28 - Voice Over IP

9
2.1 - Physical Security

• Perform a review of Physical Security to include
• Electronic or key-coded access controls at
  perimeter
• Door closures to prevent doors remaining open
• Regular review of who has access
• Change of access codes monthly
• Eye-level signage that area is RESTRICTED
• More guidance available on CPNI website (Guidance
  Notes has links)
• All equipment must be secured prior to GCSx
  connection can Go Live.

10
2.2 - User Education

• As a minimum an LAs Information Security Policy
  should include
• Definition of Information Security
• Statement of Management Intent
• Brief Explanation of security policies,
  principles, standards and compliance requirements
  of particular importance to the organisation
• Definition of General and Specific Security
  Responsibilities
• References to supporting documents
• A sample Personal Commitment Statement is
  included in the Guidance Notes (pdf).

11
2.2 - User Education (cont)

• ISO 27001 provides comprehensive detail on policy
  areas that may need to be included
• Security policy
• Organising information security
• Asset management
• Human resources security
• Physical and environmental security
• Communications and operations management
• Access control
• Information systems acquisition, development and
  maintenance
• Information security incident management (new
  clause)
• Business continuity management
• Compliance.

12
2.3 - Incident Response

• Policy for an LA User to report security
  incidents to local service desk or help desk to
  inform LA management of incidents
• Policy for LA Management to handle and manage
  incidents both locally
• Timely manner
• External relationship with Gov bodies e.g. WARP
• LA registration within WARP or GovCert UK body to
  actively monitor and act upon latest security
  alerts.

13
2.4 - Compliance Checking

• ITHC should be performed every 12 months on the
  internal LA network
• GC looking to provide minimum criteria for ITHC
  needs for GC in order to supplement local
  arrangements
• LA procedures for gateway penetration test should
  still be conducted
• 3rd Party CHECK team is recommended but not
  mandatory.

14
2.5 - Access Control

• Unique ID for each LA user will be required
• Sufficiently complex password is deemed as
• 7 character minimum
• Alpha-numeric with at least one digit
• changed periodically (60 90 days)
• Not reused within 20 password changes
• At least BC security check is required for those
  using GCSx services.

15
2.5 - Access Control (Basic Check)

• Can be done by the use of one or a combination of
  the following documents produced (Photocopies are
  not acceptable) and held on HR or personnel file
• (1). Full 10 year passport
• Or two from the below list
• (2). British driving licence
• (3). Form P45
• (4). Birth Certificate
• (5). Proof of residence i.e. council tax or
  utility bill
• Attach the Basic Check verification record form
• References should be attached for new applicants
• Other information relevant to security i.e. CRB
  check
• CRB check should be undertake if the role
  required needs CRB, not a requirement for GCSx.

16
2.6 - Network Schematic

• High Level Network Schematic
• Number of servers and total numbers of clients
• Do not need IP addresses
• Onward Sites and connections
• External sites connection to Local Authority
  servers
• Other Government department (NHS, PNN, etc)
• Internet security measures
• Local authority connection to ISP, firewalls,
  DMZs etc.

17
2.7 - IP Addressing

• RFC1918 compliance for private IP address scheme
  within the LA
• Fixed/static IP address must be used for LA
  server equipment.

18
2.8 - Firewalls

• Preferred solution is a dedicated GC firewall but
  
• Local authority can utilise existing physical
  channel on existing firewall chassis if they can
  demonstrate strong configuration control and
  management of the entire chassis
• New Firewall / Firewall Channel will be locked
  down (Ports and services) in accordance with the
  Take on Guide Summary Rule Base
• Ports
• SMTP Port 25
• DNS Port 53
• NTP Port 123
• Configuration control of the New Firewall (GC) /
  Firewall Channel is under GC control. All
  changes to GC enabled firewall / channel are
  under GC configuration control.

19
2.9 - Intrusion Detection

• If your LA has implemented either network or host
  intrusion detection then the MUST within section
  2.9 must be implemented
• Utilising approved one way TAPS
• LAs that have not formally undertaken host or
  network intrusion detection should declare via LA
  action plan if and when they intend to implement.

20
2.10 - Mobile Working

• Connections MUST employ at least the following
  controls in the short term
• Dual factor authentication
• A secure VPN tunnel between the client and GSi
  connected network that does not permit split
  tunneling
• Protection on the client in the form of a
  personal firewall (which may be incorporated into
  the VPN client)
• Make use of computing equipment owned by the
  organisation rather than the individual.

21
2.11 - Proxies

• All services to less trusted networks should pass
  through a content-aware proxy server
• Such proxies must authenticate the user, and
  where possible the internal client and external
  host
• A mail proxy can be situated in DMZ, with new
  external mail being pulled rather than pushed
  through the external boundary.

22
2.12 - Service Obfuscation

• No information about the technical configuration
  of your network should be sent out beyond network
  boundary
• Use of Firewalls, NAT and proxy servers should
  help greatly in this area.

23
2.13 - Protective Marking

• CESG Infosec Memorandum 22 - at least Partial
  Compliance
• Can be provided by GC Account Managers
• As a minimum, logs of the following to be kept
• Successful Login/Logoff
• Unsuccessful Login/Logoff
• Unauthorised Application Access
• File Access (?)
• System Changes
• Retained for 6 months on the system or readily
  available from backup devices i.e. tape drives
  etc.

24
2.14 - Operating System

• All servers and clients to run a secure file
  system such as NTFS
• Win 98 clients on the LA network must be enhanced
  by NTLM 2
• All equipment must be upgraded prior to GCSx
  connection can Go Live.

25
2.15 - Configuration

• All servers and clients in use should be Security
  Hardened
• Guidance for different Operating Systems is
  available in the Guidance Notes
• Such configuration should also form part of the
  local setup documentation for new servers/clients
• GC looking to provide best practice guide-lines.

26
2.16 - Software Policies

• Policy to disallow users from installing new
  software or altering standard configuration
  without administrator authorisation
• Implemented via software controls on clients
• Documented in security policy
• Allow those changes where a business case exists
  for changes to standard configuration of clients.

27
2.17 - Patch Management

• Policy in place for both patching of corporate
  servers and rollout to all clients, to include
• All software to be used on the network should be
  patchable
• Regular monitoring of major vendor websites and
  WARP alerts
• Identify upgrade path for any unpatchable
  software still on the network
• Provide business case for retention of obsolete
  and un-patchable software.

28
2.18 - Vulnerability Scanning

• All hosts on the network to be scanned remotely
  for vulnerabilities
• Nessus is a good example of vulnerability
  scanning software
• Basic engine is GNU
• www.nessus.org

29
2.19 - Web Browsers

• Set all security controls to HIGH on the use of
  Mobile Code
• A business case must be produced for any
  relaxation of the security controls.
• CESG MEMO 21 provides more detail on risk
  management of mobile code
• CESG Memo 21 available from GC Account Managers.

30
2.20 - Content Analysis

• Active Scanning for vulnerabilities across the
  network
• All incoming/outgoing traffic at network boundary
  should be scanned for vulnerabilities such as
• Viruses
• Spyware
• Harmful macros/mobile code
• Dangerous file types
• Use a different vendor for scanning software on
  servers/clients than that used on gateways.

31
2.21 - Personal Firewalls

• Particularly applicable for use on laptops
• Windows XP Firewall is an option, as long as user
  cant permanently disable it
• Must be kept up-to-date to be effective
• Remote working routers should also be firewalled.

32
2.22 - Macros

• A valid business case should exist for the use of
  Macros
• Where they are used, the macro security settings
  should be set to HIGH so that only controlled
  macros are allowed
• The number of users able to create macros should
  be limited.

33
2.23 - Removable Media

• Default to disabling use of removable media,
  unless there is a business case for its use.
• Where access is to be allowed, consider
  appropriate control software to mitigate risk
• Enable on-access virus scanning
• Can include
• Floppies
• CDs/DVDs
• External HDDs
• USB memory sticks
• Media card readers.

34
2.24 - E-Mail

• Disable features where they are not needed
• Automatic preview
• HTML
• Business case required if non-compliant
• Virus checking at gateway and clients
• Disable auto-forwarding of emails to lower
  classification domains e.g. Internet
• Can be implemented in Exchange
• To be part of IT / IS policy.

35
2.25 - Mail Servers

• The LA will present an RFC822 compliant Mail
  Transfer Agent (MTA)
• On day one control 2.25.1 will be for
  bi-directional classified data. LA Internet
  traffic will be served via LA ISP
• The LA mail server should initiate all mail
  transactions to and from the mail proxy
• All emails sent via the GCSx should must have a
  compliant email address in accordance with the
  Take On Guide
• username_at_organisation.gcsx.gov.uk

36
2.26 - Mail Labelling

• A suitable warning notification should be added
  to each e-mail to the effect that all
  communications sent to or from their
  organisations may be subject to recording and /
  or monitoring.

37
2.27 - Multi-Domains

• Section 2.7 is a control section that will be
  addressed when GCSx application needs have been
  expressed.

38
2.28 - Voice Over IP

• Any existing VOIP implementation should be
  reviewed against NIST security guide-lines
• Action plan to address any remedial work
• Any LA intending to implement a VOIP solution in
  the future should contact OGCbs for advice.