configuration management policy - blaenau gwent county...

of 8

Security Classification: OFFICIAL Handling Instructions: Internal Use Only

Document Reference: INFOSEC-DOC-CONPLY-001 Version: 0.1 Status: Draft

Document Owner: Information Security Officer

Document Author: Gavin Knapp

Configuration Management Policy

of 8

Authorisation & Document Control: Authorised By: Position Approved by: Dave McAuliffe (CFO, SIRO) Document Owner: Gavin Knapp (Information Security Officer) Authorised by:

Document History

Author Version Date Review Date Reason for Change Gavin Knapp 0.1 13/11/2014 13/11/2015 Initial draft

Document References Ref Document Reference Title 1 INFOSEC-DOC-VULPLY-001 BGCBC Vulnerability Scanning Policy 2 INFOSEC-DOC-PATPLY-001 BGCBC Patch Management Policy 3 INFOSEC-DOC-PATSTD-001 BGCBC Patch Management Standard 4 INFOSEC-DOC-PATGUI-001 BGCBC Patch Management Guidance 5 PSN Code of Connection https://www.gov.uk/apply-for-a-public-

services-network-psn-customer-compliance-certificate

6 GOV.UK End User Devices Security and Configuration Guidance

https://www.gov.uk/government/collections/end-user-devices-security-guidance

7 US National Security Agency’s (NSA’s) security configuration guides

http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml

8 The Centre for Internet Security www.cisecurity.org 9 The Standard of Good Practice

(SoGP) provided by the Information Security Forum (ISF).

www.securityforum.org

10 The US National Institute of Standards and Technology (NIST), Computer Security Resource Centre (CSRC)

http://csrc.nist.gov

11 Sans Institute www.sans.org 12 Centre for the Protection of National

Infrastructure (CPNI) www.cpni.gov.uk/advice/cyber/Critical-controls/

Definitions Title Definition ITHC IT Health Check CoCo Code of Connection PSN Public Services Network SLT Senior Leadership Team CM Configuration Management PCI Payment Card Industry

of 8

Contents

Introduction ........................................................................................................................... 4

1.1 Purpose .................................................................................................................. 4

1.2 Scope Statement .................................................................................................... 4

1.3 Responsibility and Authority .................................................................................... 4

1.4 Non-Compliance ..................................................................................................... 5

1.5 Review and Amendments ....................................................................................... 5

1.6 Configuration Management (CM) ............................................................................ 5

1.7 Configuration lockdown / Standard builds ............................................................... 6

1.8 PSN Compliance Requirements.............................................................................. 7

of 8

Introduction

1.1 Purpose The purpose of this policy is to ensure that all council owned devices are managed with a baseline set of controls to ensure the integrity of the device and to ensure devices are protected against unauthorised changes. These mechanisms are intended to reduce or eliminate vulnerabilities and exploits with limited impact to the business.

Help investigate possible security incidents to ensure systems conform to the Council’s security policies and the PSN code of connection.

Aid with the Council’s Patch Management regime. Enable the Council to comply with PSN Information Assurance conditions. Reduce the likelihood of council data being of a compromised and enable the Council

to fulfil its responsibilities to the Data Protection Act. Enable the Council to comply with PCI obligations

1.2 Scope Statement This policy applies to any device or system owned or managed by, or on behalf of the Council. This includes systems that contain company or customer data owned or managed by the Council regardless of location. The following areas fall under the scope of this

Microsoft Windows servers managed by the Server Team Cisco/Avaya/Nortel/Vasco equipment managed by the Network Team Workstations (desktops and laptops) or handheld devices managed by the Corporate

IT Helpdesk Team. Any other existing/future software or any other existing/future software or hardware

introduced to the Council’s network. Software or hardware services provided to the Council by 3rd party organisations Database servers maintained by the Applications and Development teams Web Servers maintained by the Development Team Any Software or Hardware connected to the Council’s network.

1.3 Responsibility and Authority This policy is issued under the authority of the Chief Executive Officer. Responsibility for implementation of this policy is set out below:

The following table identifies who within Blaenau Gwent County Borough Council is Accountable, Responsible, Informed or Consulted with regards to this policy. The following definitions apply:

Responsible – the person(s) responsible for developing and implementing the policy.

Accountable – the person who has ultimate accountability and authority for the policy.

Consulted – the person(s) or groups to be consulted prior to final policy implementation or amendment.

Informed – the person(s) or groups to be informed after policy implementation or amendment.

of 8

Responsible Information Security Officer, IT Manager, IT Team Leaders, System Owners

Accountable Council’s Senior Information Risk Officer (SIRO), Information Asset Owners, Head of IT

Consulted Information Governance Forum, Organisational Development, Legal department, Audit department, Full Council and Blaenau Gwent Leadership Group, ICT Management and Team Leaders.

Informed All Council employees, Members and partner organisations.

1.4 Non-Compliance If it is not possible to comply with the requirements of this Configuration Management Policy then the following shall be undertaken:

Permission shall be sought from the Information Security Manager as soon as possible in writing, stating the scope of the non-compliance, the business justification for this non-compliance and the name of the Manager who will take responsibility for this non-compliance;

The Information Security Manager shall assess the risks of this non-compliance and involve other relevant parties and risk stakeholders as appropriate; and

The Information Security Manager shall then advise the requestor whether the non-compliance is acceptable or not.

1.5 Review and Amendments The Configuration Management Policy is subject to SLT review and approval prior to full issue. The Vulnerability Scanning Policy shall be reviewed on an annual basis or in the event of:

Any new or changed threats to the Council environment; Significant changes to industry good practice; Any significant changes to the operating systems used; Responses to any security incidents that are discovered in relation to Council

Information Systems, data and services; Any remediation from the Council’s annual ITHC

1.6 Configuration Management (CM) The ICT Department shall develop and maintain a configuration management (CM)

procedure for all standard ICT systems. The ICT Department shall maintain a configuration database that accurately captures

the most up to date 'build' state for all operational production systems. The Server and ICT Support Team shall implement server, workstation, virtual

machine and mobile device standard builds. These shall be locked down in accordance with the configuration management procedure.

The ICT Department shall implement a configuration control process in place which prevents unauthorised changes to these standard builds. All changes to standard builds and systems should be formally approved and all standard build documents should be updated accordingly.

The change control process shall be followed whenever a modification to a standard build is required. Security representative(s) should be consulted as part of the

of 8

change process, to assess whether the change is security-impacting (i.e. could affect the security of the ICT system).

1.7 Configuration lockdown / Standard builds The Server Team shall develop and maintain configuration lockdown policies for the different components of the ICT environment, including end user/mobile network devices. These shall apply appropriate hardening templates to the standard builds as part of a defence-in-depth approach in order to:

Install only those software components that are going to be used; Disable all unused services/functions; Configure the component to minimise known vulnerabilities; Prevent unauthorised alteration of the configuration (e.g. by end users). Work on the principle of least privilege.

The principle is that if software is not installed in the first place, it cannot be vulnerable. Therefore only software and applications that are required for business use should be installed and service providers/suppliers should be required to minimise the software footprint on all client and server devices that they provide. This should ensure that components are configured and “hardened” to protect against attacks that manage to get past an organisation’s perimeter and network based defences. This may also improve system performance. A lockdown will reduce the attack surface of the component by minimising the user's (and the malicious software’s) ability to change critical configuration and gain access to services that allow execution of privileged commands. A lockdown approach can also control authorised applications and executables, enforce boot sequence control and limit access to I/O devices. Where possible a recognised lockdown configuration should be used, for example the Government Assurance Pack (GAP) available from CESG (see CESG GAP FAQs), or an appropriate alternative (e.g. NSA security configuration guides – see below. Operating System and application vendors often provide useful guidance on how their products can be effectively locked down as well. Vendor websites are a useful resource when locking down or hardening systems. Other sources of lockdown information are listed below:

US National Security Agency’s (NSA’s) security configuration guides (see http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml).

The Centre for Internet Security provides a number of benchmarks for various products that are available on the Internet for download. Further information can be found at www.cisecurity.org.

The Standard of Good Practice (SoGP) for Information Security provided by the Information Security Forum (ISF) provides further useful information with regard to system lockdown this is available online at www.securityforum.org.

of 8

The US National Institute of Standards and Technology (NIST), Computer Security Resource

Centre (CSRC) provides useful guidance information when considering secure configurations. These are available online at http://csrc.nist.gov

The SANS Institute provides useful information security resources including additional information and guidance on security lockdown and system hardening using the SANS Institute’s Twenty Critical Security Controls for Effective Cyber Defence. Further information is provided online at www.sans.org can be found at www.cpni.gov.uk/advice/cyber/Critical-controls/. An example configuration lockdown/standard build process for an end user device (EUD) is shown in Figure 1:

Figure 1: Example standard build/lockdown conceptual process

1.8 PSN Compliance Requirements A summary of the compliance requirements relevant to patch and configuration management (as per the PSN Code Template) is shown in the table below.

Condition No. Subject PSN IA Condition ISO/IEC 27001 Annex A control

CON.1 Configuration

Hardware and software shall be locked-down in accordance with the organisations lock down policy and is part of an overall risk managed approach so that functionality is limited to what is

A.12.5.2, A10.1.2

of 8

required for the provision or consumption of the PSN service.

CON.3 Configuration

Organisations shall have in place a configuration control process which prevents unauthorised changes to the standard build of network devices and hosts

A.10.1.2

Security Classification: OFFICIAL

Handling Instructions: Internal Use Only

Document Reference: INFOSEC-DOC-chmanpol1-01

Version: 0.1

Status: Draft

Document Owner: XXXXXXXXX

Document Author: Allwyn Taylor

Change Management 1 Policy

M

Authorisation & Document Control:

Document Owner: Chief Executive Officer

Approved by: Dave McAuliffe (CFO, SIRO)

Document History

Author Version Date Review Date Reason for Change

A.Taylor 0.1 8/1/2015 8/1/2016 New Document

Document References

Ref Document Reference Title

1 INFOSEC-DOC-CHMANPOL2-001 BGCBC Change Management Process

2 INFOSEC-DOC-CHMANPOL3-001 BGCBC Technical Advisory Board TOR

3

Definitions

Title Definition

Contents

1. Objectives ............................................................................................................. 4

2. Scope ................................................................................................................... 4

3. Role of the Change Board .................................................................................... 5

4. Types of Change .................................................................................................. 5

5. Assessment, Planning and Authorisation .............................................................. 5

Assessment ............................................................................................................. 6

Planning ................................................................................................................... 6

Authorisation ............................................................................................................ 6

Evaluation ................................................................................................................ 6

6. Composition of the CB .......................................................................................... 7

7. General Conditions & Working Practices .............................................................. 7

of 7

1. Objectives The aim of Change Management policy is to support continual service improvement and

best practice standards within Blaenau Gwent CBC. This will ensure efficient and

prompt handling of all changes. It is critical that all changes to the ICT service are

recorded, maintained and implemented with minimum risk to the business.

The objectives of the Change Board (CB) are contributing to the objective of Change

Management by advising, assessing, planning, authorising and evaluating activities.

2. Scope The Change Management Policy is applicable to the entire BGCBC ICT service which

includes:

· Application Service

· Database Service

· Infrastructure Service

· Desktop Service

· Operational Service

· Development Service

· Hardware

· Applications & Systems Software and Patch Management

· Hosting Equipment

· Documentation and Procedures relating to the operations, support and maintenance of the IT service.

The policy also describes the role of the Change Board (CB) that manages the change

process.

The policy includes all Blaenau Gwent CBC partner organisations and the external

suppliers who provide a service for or on behalf of Blaenau Gwent CBC. Therefore it is

expected that the BGCBC partners adopt this policy and dovetail this BGCBC Change

Management Policy into their organisations Change Management processes.

Blaenau Gwent CBC has ultimate authority over all Changes. The role of the CB is to

ensure that Changes do not conflict, get scheduled concurrently or impact upon each

other. Changes will also be assessed with regards to compliance with the Strategy. All

Requests For Change (RFC) that are deemed to have strategic or design impact will be

referred to the Change Board (CB). The CB representatives may approve/Reject or

Defer the RFC or ask that the Change Manager gather further information from the

Client. The CB may then approve or decline the RFC.

Changes which are deemed to have a potential impact upon Information Management will be referred to have approval from the appropriate Information Manager or the Information Security Officer. All RFCs are to be logged within the ICT Support desk software Portal. Blaenau Gwent CBC has a Change Manager who will produce guidance for the Service Desks to ensure that the most appropriate route for RFC filtering, approval, authorisation and implementation is taken. The status of each RFC must be recorded by the ICT Support desk software Portal and hence all communication will be through the Change Manager.

of 7

3. Role of the Change Board The Change Board is a body that approves Change and is represented by stakeholders from each operational unit in the BGCBC IT Service. The membership of the CB should have sufficient knowledge and authority to approve Changes for their service areas, business/financial, technical design, security and strategic viewpoint. RFCs should be circulated to the CB one week ahead of the CB meeting so that requests for additional information, comments and queries can be addressed in advance. In order to ensure the efficient handling of RFCs CB members must be well prepared, and have completed an impact assessment on behalf of their service area to make an approve/decline decision during the CB meeting.

The CB may approve a Change but may decide that the resource, cost, risk and impact is significant and that the Change must be managed as a project. In this event the status of the RFC will be updated and the build, test and implementation will be referred to the relevant partners ICT Programme Board. Final authorisation is to be given by all members present at the CB and/or a member of the SMT. the CB is an advisory board for approval purposes.

4. Types of Change There are 3 types of Change:

Normal Change These will be progressed via the normal Change Process as described in the BGCBC IT Change Management Process.

High Priority Change These will be progressed via the High Priority Change Process as described in the BGCBC IT Change Management Process.

Emergency Change These will be progressed via the emergency Change Process as described in the BGCBC IT Change Management Process.

5. Assessment, Planning and Authorisation The role of the CB in assessment and planning includes the authorisation of RFCs.

All Emergency Changes will be assessed by the eCB group. Membership of the eCB may vary according to the circumstances. If the relevant Work Stream Manager for each Service is not available, then at least one

other member of that Service Area who works closely with the WSM and is up to date of

the current Projects in their Project Plans will be included on the eCB including the

Change Manager or a nominated individual must authorise the Emergency Change

before its implementation and should consider the effect on all Service components and

their suppliers. Once Impact Assessment by all Service Areas and Security are collated

by the Change Manager, a member of SMT will be requested to approve the Change via

Email.

of 7

Assessment All RFCs will be circulated to the CB members at least a week before the meeting. All RFCs will then be reviewed for impact, resource and cost. The consequences of a RFC on the service level, infrastructure and the organisation

need to be assessed before a RFC can be authorised. In this capacity the CB members

carry out impact analysis to assess the consequences of a RFC on for example the:

· IT infrastructure

· Service level

· Security

· Other changes

· Available manpower/resources

· Necessary investments

Planning The CB members are involved in the planning or scheduling of Changes. In order to gain control over the time required for all the events involved in a Change, a number of aspects of the Change must be clear:

All required activities for the change must be identified

· Next determine the interdependence of the various activities in order to find out which activities can be carried out successively or simultaneously

· By combining this information with the time required for each activity, an estimate can be made of the required people and resources

· Following on from this, a planning schedule can be made for each Change

· This schedule needs to be regularly checked and if necessary, adjusted

Where possible, RFCs should be scheduled into predefined Change Slots or into

scheduled Releases which are to be agreed by the appropriate ICT Programme Board.

The output of CB should be the issue, on a regular basis, of a Forward Schedule of

Changes (FSC). This schedule contains all relevant information on authorised Changes.

The FSC should be made available to the entire organisation.

Authorisation After the assessment and planning activities a RFC will be authorised or declined.

Depending on the impact (size and risk) and priority of the Change, approval could be

obtained from several sources, for instance financial, technical and business approval.

Evaluation The CB members evaluate implemented Changes by means of a Post Implementation

Review (PIR) when necessary. If the Change is a success the RFC may be closed and

the results are filed.

The evaluation of a change should include the following aspects:

· Impact

· Effort required

· Planning

· Result

of 7

· Quality

The objective of the evaluation is to constantly improve the Change Management process and take the necessary measures to prevent the future recurrence of any detected shortcomings.

6. Composition of the CB Full CB membership is available in the BGCBC IT Change Board document.

7. General Conditions & Working Practices · The CB will meet weekly

· Updates, notes and actions will be high-level in order to reduce bureaucracy

· Attendance of permanent CB members is mandatory (or a delegate required)

· CB members are allowed to invite additional expertise, Project Managers, and so forth when required

· Consensus is required for authorisation of RFCs. In the case when no consensus is reached and delay is no option, the RFC is presented to the Chief Operating Officer for final decision or escalation.

· Initial assessment of RFCs by CB members must be completed prior to CB meeting

· The CB should be alert to changes and releases that bypass the change management processes. In such instances the change will be highlighted as non-compliance log and escalate to senior ICT management.

of 7



Document Reference: INFOSEC-DOC-PATPLY-001

Version: 0.1

Status: Draft



BGCBC Patch Management Policy

of 7




Document History


Gavin Knapp 0.1 13/11/2014 13/11/2015 Initial draft

Document References


1 INFOSEC-DOC-VUPLY-001 BGCBC Vulnerability Scanning Policy

2 INFOSEC-DOC-PATGUI-001 BGCBC Patch Management Guidance

3 INFOSEC-DOC-CONPLY-001 BGCBC Configuration Management Policy

4

Definitions

Title Definition

PSN Public Services Network

CoCo Code of Connection

CESG Communications-Electronics Security Group (the National Technical Authority for Information Assurance within the UK)

CPNI Centre for the Protection of National Infrastructure

NIST National Institute for Standards and Technology

SANS SANS Institute (SysAdmin, Audit, Networking and Security)

CIS Centre for Internet Security

of 7

Contents

Introduction ........................................................................................................................... 4

Purpose ............................................................................................................................. 4

Scope Statement ............................................................................................................... 4

Responsibility and Authority .............................................................................................. 4

Non-Compliance ................................................................................................................ 5

Patch Management ........................................................................................................... 5

Patch Management Principles ........................................................................................ 6

Configuration Management Program ................................................................................. 7

of 7

Introduction

Purpose

Security vulnerabilities are inherent in computing systems and applications. These flaws

allow the development and propagation of malicious software which can disrupt normal

business operations in addition to placing the Councils data at risk.

In order to effectively mitigate this risk, software "patches" are made available by vendors to

remove a given security vulnerability. Given the large number of computer workstations and

servers that comprise the Councils networks, it is necessary to utilise a patch management

policy that can effectively distribute security patches when they are made available.

The purpose of this policy is to ensure computer systems attached to the Council’s network

are updated accurately and timely with security protection mechanisms (patches) for known

vulnerabilities and exploits. These mechanisms are intended to reduce or eliminate

vulnerabilities and exploits with limited impact to the business.

Patch management will be deployed when necessary so long as it doesn’t affect the

Councils business as usual operations.

Scope Statement

This policy applies to all employees, members, contractors, consultants, temporary

employees, and other workers at the Council including all third party companies. This policy

applies to all equipment that is owned or leased by the Council such as all servers,

application software, computers, laptops, tablets, peripherals, routers, and switches.

The following systems have been categorised according to management:

● Unix servers managed by the Server Team ● Microsoft Windows servers managed by the Server Team ● Cisco/Avaya/Nortel/Vasco equipment managed by the Network Team ● Workstations (desktops and laptops) or handheld devices managed by the

Corporate IT Helpdesk Team. ● Any other existing/future software or any other existing/future software or

hardware introduced to the Council’s network. ● Software or hardware services provided to the Council by 3rd party

organisations ● Database servers maintained by the Applications and Development teams ● Web Servers maintained by the Development Team ● Any Software or Hardware connected to the Council’s network.

Responsibility and Authority

This policy is issued under the authority of the Chief Executive Officer. The following table

identifies who within Blaenau Gwent County Borough Council is Accountable, Responsible,

Informed or Consulted with regards to this policy. The following definitions apply:

of 7

• Responsible – the person(s) responsible for developing and implementing the policy. • Accountable – the person who has ultimate accountability and authority for the policy. • Consulted – the person(s) or groups to be consulted prior to final policy

implementation or amendment. • Informed – the person(s) or groups to be informed after policy implementation or

amendment.

Responsible Information Security Officer, IT Team Leaders, System Owners

Accountable Council’s Senior Information Risk Officer (SIRO), Information Asset Owners

Consulted Information Governance Forum, Organisational Development, Legal department, Audit department, Full Council and Blaenau Gwent Leadership Group, ICT Management and Team Leaders.


Non-Compliance

Failure to properly configure new workstations is a violation of this policy. Disabling,

circumventing or tampering with patch management protections and/or software constitutes

a violation of the Information Security Policy.

If it is not possible to comply with the requirements of this Patch Management Policy then the following shall be undertaken:

· Permission shall be sought from the Information Security Manager as soon as possible in writing, stating the scope of the non-compliance, the business justification for this non-compliance and the name of the Manager who will take responsibility for this non-compliance;

· The Information Security Manager shall assess the risks of this non-compliance and involve other relevant parties and risk stakeholders as appropriate; and

· The Information Security Manager shall then advise the requestor whether the non-

compliance is acceptable or not.

Patch Management

Many computer operating systems such as Microsoft Windows, Mac OS and others include

software application programs which may contain security flaws.

Occasionally, one of those flaws could permit a hacker to compromise a computer. A

compromised computer threatens the integrity of the network and all computers connected

to it. Almost all operating systems and many software applications have periodic security

patches released by the vendor that need to be applied. Patches which are security related

or critical in nature should be installed when appropriate and have been fully risk assessed

in order not to compromise the normal business operations of the Council.

In the event that a critical or security patch cannot be centrally deployed by the Council, it

must be installed in a timely manner using the best resources available. In the case of non

of 7

Microsoft desktop operating systems where a centralised deployment is not available, the

installation should occur in a timely manner by a member of the Councils ICT staff.

Patch Management Principles

· Patching should follow BGCBC’s specified and published principles and policies;

· Shall be in line with all appropriate legislation.

· Follow the IA conditions set out in the PSN CoCo.

· Where feasible be in line with Industry Standards and Good Practice Guides

including but not limited to PSN, CPNI, NIST, SANS, CIS and CESG.

· The Council’s patch management and configuration management procedures should be used to enable identification of which patches need to be/have been applied to which ICT assets;

· Only software necessary to deliver the organisation’s business should be installed (to minimise the need to patch) and it should be configured such that it minimises the vulnerabilities available to potential attackers (“the attack surface”);

· Only the latest stable release of software should be used, not necessarily the latest released version (sometimes the latest version has more vulnerabilities and should not be used until the first service update release, e.g. service pack).

· An effective monitoring process shall be carried out by teams involved with Patch Management. Vulnerability scanning shall also take place and alerts shall be acted upon within an agreed timescale.

· The sources of patches should be confirmed and those patches should be evaluated and regression tested before deployment into a live ICT infrastructure;

· Updates and patches should be deployed into the ICT infrastructure as quickly as possible to minimise exposure times to known vulnerabilities (particularly if a critical vulnerability);

· The update and patching process should be integrated between operational and security management teams to achieve an effective decision-making process and minimise and resolve delays caused by conflicts in business priorities;

· The update and patching process should be integrated between operational and security management teams to achieve an effective decision-making process and minimise and resolve delays caused by conflicts in business priorities;

· A retrieval and deployment architecture for updates and patches should be implemented that is appropriate for their use informed by the output of a technical risk assessment and organisational risk appetite;

· Good update and patch processes/regimes should be enforced to make it more difficult for potential attackers to successfully attack an ICT infrastructure and therefore the information held on it.

· Scheduling of patches should be clearly thought out to limit the impact on essential services and users

· Vulnerabilities should be patched as soon as is practical, particularly for business critical systems. Processes shall identify the appropriate prioritisation, testing, implementation and regression regime that balances the need for maintaining the secure configuration of the organisation with the need for robust configuration controls.

Information about technical vulnerabilities relating to ICT components being used by the Council should be obtained (as part of the threat intelligence gathering process, through IT Health Checks and vulnerability assessments). The Council's exposure to discovered

of 7

vulnerabilities shall be evaluated and appropriate measures taken to address the associated risks

Configuration Management Program

· The ICT Department shall maintain a current functional software code library

containing the most recent, stable, deployed software versions used on the Council’s

network.

· The Server Team shall maintain a current hardware inventory of all core servers and

be made available to authorised staff only.

· The ICT Department shall maintain a network schematic map containing all switches,

routers and firewalls. The Council uses Alienvault and WHATSUP for real-time

monitoring and Analysis

· For systems not directly managed by the ICT Department the Systems Owner shall

be accountable for ensuring the level of patching remains acceptable and compliant

with the Councils information security policies, relevant legislative or regulatory

compliances and the PSN CoCo IA Conditions.



Document Reference: INFOSEC-DOC-FOIPLY-001

Version: 1.0

Status: Release

Document Owner: Information and Governance Officer

Document Author: Paul Amos

Freedom of Information Policy

M

FF



Approved by: Information Governance Forum, CMT, Full Council

Document History


Document References


1

2

3

Definitions

Title Definition

FOIA FOIA

ICO Information Commissioner’s Office

Contents

1. Purpose ........................................................................................................................................... 4

2. Scope ............................................................................................................................................... 4

3. Key Features of the FOIA ................................................................................................................ 4

4. Implementation Responsibilities .................................................................................................... 5

5. Legal Requirement .......................................................................................................................... 5

6. The Scheme ..................................................................................................................................... 5

7. Publication Scheme and Information Register ............................................................................... 6

8. Internal Procedure for Processing FOI Requests ............................................................................ 7

9. Procedure for making a request for information ........................................................................... 8

10. Timeframe for a response ........................................................................................................... 8

11. Requesting Clarification .............................................................................................................. 8

12. Third Party Consultations ............................................................................................................ 9

13. Charging for information ............................................................................................................ 9

14. Receiving a response ................................................................................................................. 10

15. Refusing a request for information ........................................................................................... 10

16. Complaints ................................................................................................................................ 12

17. Appealing a Refusal Notice ....................................................................................................... 13

18. Appealing to the ICO ................................................................................................................. 13

1. Purpose The objective of the Freedom of Information Policy is to outline the policy and

procedures in place that must be adhered to at all times when dealing with Freedom

of Information requests.

It establishes the principles that underpin the Council’s approach to promote open

government by following set procedures for dealing with requests for information.

2. Scope This policy applies to all Blaenau Gwent County Borough Council (BGCBC)

employees and members. The document outlines how employees and members

should handle requests for information by members of the public.

This is not a legal document. It does not confer rights nor override any legal or

statutory provisions which either require or prevent disclosure of information.

This document takes into account the key features of the FOIA and outlines what

steps the Council will take to comply with the FOIA.

This document outlines how an applicant can make a request for information under

the FOIA.

Throughout this document all references to the Council are references to Blaenau

Gwent County Borough Council.

3. Key Features of the FOIA

The FOIA provides public access to recorded information held by the Council and

places two general duties on the Council;

a. To confirm or deny that it holds the information requested and

b. If the information is held give the requestor access to it.

The FOIA also provides that some documents are subject to exemptions; these are

set out under Part II of the FOIA. Some exemptions are subject to a public interest

test.

The FOIA provides that in addition to the exemptions, the Council may refuse to

confirm or deny holding information and/or to give access to it on the ground of

excessive cost, vexatious requests, where the request has been repeated or if the

applicant has not provided sufficient detail to identify the information required.

The FOIA allows the Council to charge fees in accordance with regulations to be

made by the Home Secretary and exempts the Council from disclosing information

until the fee has been paid. It also exempts the Council from the obligation to

disclose the information requested if the cost of doing so exceeds a specified

threshold.

The FOIA requires the Council to provide advice and assistance to people seeking information. It requires the Council to state the basis for the refusal of a request for information and to provide advice on how to complain in those circumstances. The FOIA also places statutory time limits for complying with a request for information on the Council which is 20 working days from the date of receipt.

4. Implementation Responsibilities The Information and Governance Officer shall develop, maintain, and publish

processes to achieve compliance with this policy. Any queries can be directed to

[email protected].

All Heads of Service shall be responsible for implementing this policy within their

areas of responsibility.

The Information and Governance Officer is available to provide advice and guidance

relating to Freedom of Information requests to employees and members when

required.

5. Legal Requirement The Council will set out in its Freedom of Information publication (FOI) scheme:

· The classes of information which the Council publishes or intends to publish;

· The manner in which the information is or is intended to be published; and

· Whether the information is or is intended to be available free of charge or on payment.

6. The Scheme The Council scheme covers information already published and information which is to be published in the future. Some information may not be made public, for example personal information about named persons. The Council’s publication scheme conforms to the model scheme for local authorities approved by the Information Commissioner.

The Council’s policy is that: An enquirer must be informed whether the Council holds that information or not, and if it does, it must supply the information:

· The information must be supplied within 20 working days of the request;

· The information can include personal or non-personal information, but no information relating to named individuals will be released;

· Other information that the Council considers to be of a sensitive nature may also be withheld. In so deciding the Council will consider whether it should be released in the public interest, if in withholding the information is greater than the public interest in releasing it;

· The Information and Governance Officer will administer the Council's process for providing information. In so doing the Information and Governance Officer will take into account the ICO Code of Practice.

7. Publication Scheme and Information Register

The Council will maintain an information register as part of its publication scheme which provides a means by which the public can identify key information produced by the council in the course of its business.

The publication scheme can be found on the Council’s website http://www.blaenau-gwent.gov.uk/

The Council will maximise the use of its website to publish information, In addition the scheme and other information will be available at Council Offices.

8. Internal Procedure for Processing FOI Requests The full Internal Procedure can be found on the supporting guidance document: ‘BG Info Requests - Internal Procedure’. Please find the process in summary below:

Request received in writing

by the Information and

Governance Officer

Request logged and

Acknowledgement of receipt

sent to the requester

Request sent onto the

relevant Department

Information provided to the

Information and

Governance Officer

Information and Governance

Officer responds directly to

the requester

9. Procedure for making a request for information

All requests must be made in writing and sent to the Information & Governance Officer for processing. Blaenau Gwent County Borough Council Legal & Corporate Compliance Division General Offices Steelworks Road Ebbw Vale Gwent NP23 6DN Email: [email protected] Phone: 01495 355080 There are numerous ways a request can be submitted to the Council. The main methods used are via the post or by email (using the details outlined above)

10. Timeframe for a response The Council will inform the applicant in writing whether we hold the information requested and if so, communicate that information to the applicant, no later than 20 working days after receipt of the request. The 20 working days runs from the day after the Council receives the request. Where a request for information is received after the close of the Council offices, which is 5pm Monday – Friday, it will be received by the Council the following working day. A request is classed as received as soon as it is delivered to the Council, or it is within the Council’s possession.

11. Requesting Clarification In the event that a request received from an applicant is unclear or is not specific enough the Council may request clarification. The Council is not required to respond to a request for information until the further information has been provided. Therefore the 20 working day deadline will not start until the Council receives the information required, which will enable the Council to prepare the required response. The Council will contact the applicant seeking further information as soon as possible, and will not under any circumstances, cause a delay for response in order to have more time to prepare a response. The Council will acknowledge the applicants clarification promptly and respond in the same manner as other FOI requests.

12. Third Party Consultations There are instances where information requested concerns the details of or documents that have been provided by another organisation, public body or individual, these are known as third parties. In these circumstances the Council will need to take reasonable steps to contact and consult with the third party prior to the release of the information. During the consultation with the third parties the identity of the individual will not be disclosed. If the applicant’s identity is required by the third party the Council will seek permission from the applicant first. Although the third party will be consulted, the decision as to whether or not to release the information will remain with the Council. Each case will be considered based on its individual merits.

13. Charging for information There are instances when the Council can charge for complying with a request for information. Currently, the cost limit for complying with a request or a linked series of requests from the same person or group is set at £450. The Council is able to refuse a request if we estimate that the cost of compliance would exceed this limit. This provision is found at section 12 of the FOIA. The Council may also refuse a request if deciding whether we hold the information would exceed the cost limit, for example, because it would require an extensive search in a number of locations. When calculating the costs of complying, the Council is able to aggregate the costs of all related requests received within 60 days from the same applicant or from applicants who seem to be working together. When estimating the cost of compliance, the Council will take into consideration the cost of:

· Determining whether we hold the information requested

· Locating the information

· Retrieving the information or documents

· Extracting the information from the documents containing it The cost of staff time associated with these activities is currently calculated at a flat rate of £25 per hour. This hourly rate has been set by Parliament and therefore cannot be altered by the Council. On this basis, it would take 18 hours or more to reach the appropriate limit. When considering the costs of replying to a request, the Council will not include the time spent deciding whether or not information is exempt from disclosure when calculating the cost of responding.

Where the limit is not exceeded, or complying with a request will take less than 18 hours, the Council is only able to charge the applicant for the cost associated with providing the information, for example photocopying and postage. These are collectively known as disbursements. The Council charges are as follows:

· A4 Black and White £0.10p (single sheet)

· A4 Colour £0.15p (single sheet)

· A3 Black and White £0.20p (single sheet)

· A3 Colour £0.30p (single sheet) Postage charges will vary depending on the size and weight of the parcel. If an applicant is required to pay a fee, according to Section 9 of FOIA the 20 working day deadline for a response will not start until the fee has been received by the Council.

14. Receiving a response The Council will aim to provide responses to all requests for information within the 20 working day time limit. Responses to requests will be in an easy to read clear language normally in black, Arial font and size 12. There are instances where an applicant may request their response to be in a specific format. Where reasonably practicable the Council will comply with the stated preference. Where it is not reasonably practicable to comply with the applicants preferences an explanation as to why this is will be given. The Council will respond promptly and positively to each request. A detailed and comprehensive response will be provided to the applicant requesting information. The Council will be as open and helpful as possible ensuring compliance with the FOIA and all other legislation.

15. Refusing a request for information The Council is not always able to provide the information that is requested under the FOIA. There are occasions where there will be a good reason why the Council should not disclose some or all of the information requested. The Council can refuse all or part of a request under the following circumstances:

· It would cost too much or take too much staff time to deal with the request.

· The request is vexatious.

· The request repeats a previous request from the same person.

· If one of the exemptions under part II of the FOIA apply The FOIA contains a number of exemptions that allow the Council to withhold information, therefore refusing entry into the public domain. It also enables the Council to refuse to confirm or deny whether the information requested is held.

Exemptions exist to protect information that should not be disclosed, for example because disclosing it would be harmful to another person or it would be against the public interest. Some exemptions contained within part II of the FOIA relate to a particular type of information, for instance, formulation of Council policy and procedures. Other exemptions are based on the harm that would arise or would be likely arise from disclosure, for example, if disclosure would be likely to prejudice a criminal investigation or prejudice someone’s commercial interests. There is also an exemption for personal data (this information relates to or identifies a living individual) if releasing it would be contrary to the Data Protection Act 1998. When applying an exemption, the Council will consider the information contained within a document separately against each exemption. This may mean that an exemption may only apply to part of the information requested, or that different exemptions apply to different sections of a document. There are two types of exemptions, absolute exemptions and qualified exemptions. An absolute exemption provides an automatic right to refuse the disclosure of information. Qualified exemptions are subject to a Public Interest Test (PIT). This is a balancing exercise used to weigh arguments for and against disclosure. As a result before withholding information under a qualified exemption, the Council must consider the public interest arguments. The FOIA requires the Council to disclose information unless there is good reason not to, so the exemption can only be maintained (upheld) if the public interest in doing so outweighs the public interest in disclosure. The Council considers each request submitted on a case by case basis. We do not apply blanket exemptions to particular pieces of information. As such we do not automatically withhold information. There are certain circumstances whereby the Council is unable to confirm or deny that the information requested exists. This situation arises when even confirming information is held would be damaging. In these instances the Council will give a neither confirm nor deny response. This response will be applied consistently in any case where confirming or denying the existence of information could be classed as harmful. The Council will issue a refusal notice within the neither confirm nor deny response. Due to the nature of the response the Council would not address the question of whether any information that is held should be disclosed. As a general rule, the Council will not take into account the identity or intentions of a requester when considering whether to comply with a request for information. However, the Council is able to refuse to comply with a request that is vexatious. A vexatious request is a repeated request from the same applicant. When assessing whether a request is vexatious, the FOIA permits the Council to take into account the context and history of a request, including the identity of the

requester and the Councils previous contact with them. The decision to refuse a request often follows a long series of requests and correspondence. When deciding whether a request is vexatious, the Council will consider a number of different factors, including:

· how much work complying with the requests creates;

· the applicant’s tone and manner when communicating with the Council;

· whether the request appears obsessive; and

· whether there is any value in the request If the Council refuses all or part of a request a Refusal Notice will be issued to the applicant. The refusal notice will detail whether the Council is refusing to disclose information that is held, refusing to confirm or deny that the information is held, refusing to deal with a vexatious request or whether the cost of complying with a request exceeds the appropriate limit (£450). The refusal notice will state what exemption has been applied and why. If the exemption is a qualified exemption then the public Interest test will be applied and the Council’s reasoning for applying the exemption will be explained.

16. Complaints The Council will provide a right of complaint where the requester is not satisfied with

the response received to a request for information.

If an applicant is unhappy with the service they have received they should firstly contact the Information and Governance Officer outlining any issues they have. The Information and Governance Officer will try and resolve the issues quickly and courteously, and offer the applicant any help required in order to resolve the issues. The Information and Governance Officer will try to sort out any mistakes or misunderstandings as soon as possible, in order to resolve the problem as soon as possible in an informal way. If the applicant is dissatisfied with the Information and Governance Officers decision they have the right to make a formal complaint using the Councils Corporate Complaints Procedure. Corporate Complaints are handled by the Councils designated Complaints Officer. If an applicant wishes to make a formal complaint about the handling of their request, they will be required to complete a Complaints Form. Applicants can find more information about how to make a formal complaint by reading the Compliments, Comments and Complaints Procedure on our external website www.blaenau-gwent.gov.uk.

If you are still not satisfied after your complaint has been dealt with via an internal

review, you have a further right of complaint to the Information Commissioner. The

details will be provided to you and can also be found in the Publication Scheme.

17. Appealing a Refusal Notice If the Council issues a Refusal Notice and the applicant believes that an error has been made they are able to appeal the Councils decision by seeking an internal review. The Monitoring Officer handles all internal reviews on behalf of the Council. Once an appeal has been received the Monitoring Officer will acknowledge receipt and reconsider the request. The Monitoring Officer will consider the initial request, the Councils refusal notice and any other supporting documents that were used in reaching the decision to refuse the request. The Monitoring Officer will then reconsider whether or not a correct decision has been made in refusing the request. The applicant will be notified of the outcomes of the internal review as soon as possible. All internal reviews will be concluded within 40 working days. If an applicant’s appeal is successful they will receive the information they requested within that response. If the appeal is unsuccessful Monitoring Officer will provide a detailed explanation of the findings and supply further information.

18. Appealing to the ICO If an applicant is not satisfied with the outcome of the internal review they have the right to submit a complaint to the ICO. The ICO will make an initial assessment of the case before carrying out an investigation. The ICO has written guidance notes for applicants on how to complain to the ICO and published it on their website, www.ico.gov.uk The Information Commissioners Welsh Office contact details are: Information Commissioner’s Office (Wales) 2nd Floor, Churchill House, Churchill Way, Cardiff CF10 2HH Tel: 029 2067 8400 Fax: 029 2067 8399 Email: [email protected] Website: www.ico.org.uk

Further information If you need any more information about this policy or any other aspect of freedom of information, please contact The Information and Governance Officer: Blaenau Gwent County Borough Council Legal & Corporate Compliance Division General Offices Steelworks Road Ebbw Vale Gwent NP23 6DN Email: [email protected] Phone: 01495 355080 This Policy will be reviewed and considered from time to time in line with new decisions of the Information Commissioner, Tribunal and courts on freedom of information cases.

of 7


Handling Instructions: BGCBC Internal use only

Document Reference: INFOSEC-DOC-VUPLY-001

Version: 0.1

Status: Draft



Vulnerability Scanning Policy

M

of 7




Document History


Gavin Knapp 0.1 13/11/2014 13/11/2015 Initial draft

Document References


1 INFOSEC-DOC-PATSTD-001 BGCBC Patch Management Standard

2 INFOSEC-DOC-PATGUI-001 BGCBC Patch Management Policy

3 INFOSEC-DOC-CONPLY-001 BGCBC Configuration Management Policy

4 http://www.cisecurity.org/about/CHToolkits.cfm CIS Cyber Hygiene Toolkits

5 http://www.nist.gov/cyberframework/ NIST Cyber Security Framework

6 https://www.pcisecuritystandards.org/security_standards/ PCI Data Security Standard

7 https://www.owasp.org/index.php/Main_Page OWASP

Definitions

Title Definition

SLT Senior Leadership Team

VPN Virtual Private Network

PSN Public Services Network

CMT Corporate Management Team

of 7

Contents

Introduction ........................................................................................................................... 4

1.1 Purpose .................................................................................................................. 4

1.2 Scope Statement .................................................................................................... 4

1.3 Responsibility and Authority .................................................................................... 4

1.4 Non-Compliance ..................................................................................................... 5

1.5 Review and Amendments ....................................................................................... 5

1.6 Scanning ................................................................................................................. 5

1.7 Policy Principles ...................................................................................................... 6

Appendix A ........................................................................................................................... 7

CVSS Scoring and Remediation Timescales ..................................................................... 7

of 7

Introduction

1.1 Purpose

The purpose of this policy is to allow IT Services within Blaenau Gwent County Borough Council to scan devices attached to the Council’s network for vulnerabilities. This is to assist in maintaining a secure and reliable infrastructure. Vulnerability scanning may be conducted to:

· Identify compromised systems within the council’s network;

· Identify virus infected machines within the council’s network;

· Identify poorly configured and potentially vulnerable systems attached to the council’s network;

· Any device requesting a firewall rule;

· Investigate possible security incidents to ensure systems conform to the Council’s security policies and the PSN code of connection.

· Aid with the Council’s patch management policy and procedures.

· Aid with the Council’s configuration management policy and procedures.

· Enable the Council to comply with PSN Information Assurance conditions, relevant legislation or other regulatory compliances.

1.2 Scope Statement

This policy applies to any device or system owned or managed by, or on behalf of the Council. This includes systems that contain company or customer data owned or managed by the Council regardless of location. The following areas fall under the scope of this

· Microsoft Windows servers managed by the Server Team

· Cisco/Avaya/Nortel/Vasco equipment managed by the Network Team

· Workstations (desktops and laptops) or handheld devices managed by the Corporate IT Helpdesk Team.

· Any other existing/future software or any other existing/future software or hardware introduced to the Council’s network.

· Software or hardware services provided to the Council by 3rd party organisations

· Database servers maintained by the Applications and Development teams

· Web Servers maintained by the Development Team

· Any software or hardware connected to the Council’s networks.

1.3 Responsibility and Authority

This policy is issued under the authority of the Chief Executive Officer. Responsibility for

implementation of this policy is set out below:

The following table identifies who within Blaenau Gwent County Borough Council is Accountable, Responsible, Informed or Consulted with regards to this policy. The following definitions apply:

• Responsible – the person(s) responsible for developing and implementing the policy. • Accountable – the person who has ultimate accountability and authority for the policy.

of 7

• Consulted – the person(s) or groups to be consulted prior to final policy implementation or amendment.

• Informed – the person(s) or groups to be informed after policy implementation or amendment.

Responsible Chief Executive, Information Security Officer, IT Team Leaders

Accountable Council’s Senior Information Risk Officer (SIRO), Information Asset Owners

Consulted Information Governance Forum, Organisational Development, Legal department, Internal Audit, Full Council and Blaenau Gwent Leadership Group, ICT Management and Team Leaders.


1.4 Non-Compliance

If it is not possible to comply with the requirements of this Vulnerability Scanning Policy then the following shall be undertaken:

· Permission shall be sought from the Information Security Manager as soon as possible in writing, stating the scope of the non-compliance, the business justification for this non-compliance and the name of the Manager who will take responsibility for this non-compliance;

· The Information Security Manager shall assess the risks of this non-compliance and involve other relevant parties and risk stakeholders as appropriate; and

· The Information Security Manager shall then advise the requestor whether the non-compliance is acceptable or not.

· Non-compliant devices or systems may be temporarily disconnected if the risk to BGCBC warrants it, until remediation of vulnerabilities can be applied.

1.5 Review and Amendments

The Vulnerability Scanning Policy is subject to review and approval prior to full issue.

The Vulnerability Scanning Policy shall be reviewed on an annual basis or in the event of:

§ Any new or changed threats to the Council environment;

§ Significant changes to industry good practice;

§ Any significant changes to the detection of vulnerabilities;

§ Responses to any security incidents that are discovered in relation to Council Information

Systems, data and services;

1.6 Scanning

IT Services will use industry leading software to carry out vulnerability scanning and audit reports. A number of tools will be used for vulnerability scanning and the tool set will be reviewed annually. This includes: OpenSource and commercial packages.

These tools will perform the following tasks:

· Host Discovery – identifying computers listening on the Council network; · Port Scanning

of 7

· Operating System Detection – remotely determine the OS (Windows, Apple Macintosh or Linux)

· Software Version Detection – Interrogating listening services to determine application names and versions

· Network based vulnerability scanning · Operating systems security patch audits (Windows, Linux) · Configuration audit · Web application vulnerability testing · SQL database vulnerability and configuration auditing · Password auditing, checking for default or blank passwords · Anti Virus audit, checking out-of-date virus signatures and configuration

errors. · Network and Communications equipment shall also be monitored and

scanned for vulnerabilities

1.7 Policy Principles

In an effort to reduce IT Security risks and supplement existing security practices, IT Services will perform periodic vulnerability audits on devices connected to the Council’s network. IT Services may also scan for vulnerabilities, which are currently being exploited in the wild.

· Vulnerability audits will consist of Council network scans for: ü Open communications ports ü Host operating system detection ü Host operating system patch levels ü Remote applications to identify known vulnerabilities or high-risk system

weaknesses

· Any new systems or services should have passed a vulnerability scan before being connected to the production network.

· Any systems or services which require off-site access are subject to a vulnerability scan before access is granted. This is to ensure that the machine posture is adequate.

· All systems or services which currently have off-site access enabled are subject to vulnerability scanning every six months.

· Any systems or services which require access via the VPN service or Remote Working Portal are subject to passing a vulnerability scan.

· Before IT Services carry out any vulnerability scans; server managers should be contacted to arrange a suitable time.

· Vulnerability scanning will not search the contents of personal electronic files located on the system.

· Scans should not cause disruption to the campus network or services hosted on systems being scanned. Device log files may reflect the scan that takes place.

· Servers hosted within IT Services data centres, will be subject to a monthly automated authenticated security scan. If a software firewall is installed, a hole will be required to the scanning server’s IP address.

· Information about technical vulnerabilities relating to ICT components being used by the Council should be obtained (as part of the threat intelligence gathering process, through IT Health Checks and vulnerability assessments). The Council's exposure to discovered vulnerabilities shall be evaluated and appropriate measures taken to address the associated risks

of 7

· Systems Owners shall co-ordinate remediation actions in conjunction with the Information Security team and IT Service teams.

· Remediation timescales are set out in Appendix A, these shall be adhered to at all times. In the event that remediation timescales cannot be met, an action plan will be drawn up by the System Owner and Information Security Officer.

· During the PSN Code of Connection renewal remediation timescales may be expedited to ensure the Council remains connected to PSN.

· The Councils Patch Management Policy and associated guidance should be referred to when remediation or preventative measures are required as a result of vulnerability scans.

· Remediation timescales will be adhered to where feasible and will be done in line with the Councils change management policy and process.

Appendix A CVSS Scoring and Remediation Timescales

CVSS Rating Priority Patch SLA

0 P5 Discretionary

1 – 4.4 P4 6 – 9 Months

4.5 – 6.7 P3 3 – 6 Months

6.8 – 7.9 P2 1 – 3 Months

8 – 10 P1 1 Month or under

Appendix B PSN CoCo Recommended Timescales

CVSS Rating Priority Patch SLA

0 P5 Discretionary

1 – 4.4 P4 60 Days

4.5 – 6.7 P3 60 Days

6.8 – 7.9 P2 30 Days

8 – 10 P1 14 Days

configuration management policy - blaenau gwent county...

Documents