information security standards - abu dhabi · pdf file12.6 information asset management ......

Information Security StandardsAbu Dhabi Government

Ve r s i o n 2 . 0

This document is developed by:

Information Security StandardsAbu Dhabi Government

Version 2.0

H.H. Sheikh Khalifa Bin Zayed Al NahyanPresident of the United Arab Emirates - Ruler of Abu Dhabi

H.H. General Sheikh Mohamed Bin Zayed Al NahyanCrown Prince of Abu Dhabi - Deputy Supreme Commander of the UAE Armed Forces

Chairman of Executive Council - Abu Dhabi

Document Control

Version Release Date Summary of Changes1 15 March 2009 Initial Publication Release

2 23 January 2013 Revisions as per Section 7 Summary of Key Changes

This document has been developed and is maintained by the Information Security Programme of the Abu Dhabi Systems and Information Centre.

Question and Comments should be directed to:

[email protected]

Contents

Document Control

1 Executive Summary

2 Introduction 2.1.1 Overview 2.1.2 Purpose 2.1.3 Scope 2.1.4 Applicability

3 Information Security Framework

4 Compliance and Enforcement

5 Application of this Version

6 Related Documents 6.1 Alignment with Related Government Standards 6.2 Supporting Documents 7 Summary of Key Changes to these Standards Since the Last Version 7.1 Changes to Control Standard Structure

8 Implementation Priorities - When & How to Apply Controls 8.1 When to Apply Controls 8.2 How to Apply Controls

2

44556

8

13

14

151515

1619

252527

Contents

9 Mandatory vs. Recommended vs. Suggested Controls 9.1 Areas Requring Entity Interpretation

10 Common vs Tailored Security Controls

11 Alignment to International Standards

12 Abu Dhabi Information Security Standards 12.1 Information Security Governance 12.2 Information Security Risk Management 12.3 Human Resources Security 12.4 Third Party Supplier Security 12.5 Information Security Training, Awareness & Communication 12.6 Information Asset Management 12.7 Physical And Environmental Security 12.8 Information Systems Design, Development & Testing 12.9 Identity & Access Management 12.10 Information Operations Management 12.11 Information Security Incident Management 12.12 Information Systems Continuity Management

Appendicies Appendix A – Acronyms Appendix B – Definitions Appendix C – Classification Matrix Appendix D – V1 to V2 Standards Mapping Appendix E – V2 to V1 Standards Mapping

28 31

31

33

3434628596104114132147193214280305

319321 323 329331347

2 Information Security Standards

Information Security is a real-word concern, not a theoretical construct. The discipline is not an end itself – it serves a much wider and more significant purpose. Implemented effectively, it can be instrumental in government delivering better quality, more robust and higher value services that citizens and residents can place their trust in.

This second version of the Abu Dhabi Information Security Standards is part of the Government’s on-going journey of learning and improvement. Since the launch of the Information Security Programme in June 2009, government Entities have made progress in making Information Security part of their management toolset.

On-the-ground insights have been gained by Abu Dhabi Government Entities (ADGEs) following deployment of the first version. This cycle of learning has been reflected in this substantially revised and updated version. The standards have been reengineered with the following ten principles in mind:

1. Executive level ownership and oversight of Entity Information Security programmes should drive success.

2. Ambitious but realistic goals should be set for Entity Information Security programmes. Ones that allow for discernible and lasting improvements in the management of government information assets.

3. Entity Information Security Programmes should be resourced in a manner, and to a level, that makes the achievement of programme objectives practical.

4. Information Owners should assume an informed position concerning the security of their information assets.

5. A holistic view of Information Security controls should be taken that reflects key inputs i.e. risks applicable to the Entity, its compliance obligations and its business requirements.

1 Executive Summary

3

6. Entities should be informed as to what they should tangibly be doing in implementing Information Security. They should be provided clear, real-world, practitioner-oriented inputs, ahead of abstract theories.

7. Control Standards should be given a suggested prioritisation that recognises that Entities have finite time and resources to expend on Information Security.

8. Entities should implement a range of control types (e.g. preventive and detective) to ensure that a balance and harmony is achieved in the Entity’s control set; and an accurate picture of the Entity’s security and risk profile is achieved.

9. Emphasis should be given by Entities to ‘designing in’ security, rather than retrofitting it after the fact.

10. The classification of information assets should shape the prioritisation and design for Information Security Controls.

The executive management teams of all Abu Dhabi Government Entities are asked to recognise that their vision, leadership and commitment will be the ultimate determinants in whether their organisations effectively embrace the aims of these Standards; and whether they achieves effective protection of assets given into their trust. The stewardship of government services is a significant and privileged responsibility. It is a responsibility that can be effectively realised by executives, staff and suppliers being committed to Information Security best practice.

These Standards function in support of the Abu Dhabi Information Security Policy. The Policy is approved by the General Secretariat of Abu Dhabi, confirming its sponsorship of the Abu Dhabi Information Security Programme.


2.1.1 Overview

Information Security provides protection to the information assets owned and managed by the government of Abu Dhabi. It seeks to support the government’s vision of delivering services that are effective, efficient and which add tangible value to the emirate. The application of Information Security allows the government to promote an environment of trust that supports the transaction of the government’s business. The achievement of effective Information Security requires active awareness and on-going participation on the part of government Entities, citizens, residents and business partners.

The modern world is one in which there is an ever growing use of information assets and an ever increasing dependency on the information systems on which those assets reside. The government of Abu Dhabi has actively embraced that reality via a continuing programme of e-Government initiatives. Such initiatives present a range of potential benefits but also bring with them new, complex risks that must be identified in a timely way and managed effectively.

The Control Standards contained within this document provide an expression of the Information Security expectations that the government has upon Entities and business partners handling classified government data. The Control Standards are expressed in twelve domains of Information Security that are interrelated and mutually supportive.

Entities have the responsibility of understanding the Control Standards defined within this document and applying them effectively in the protection of the confidentiality, integrity and availability of their information assets.

This version of the Abu Dhabi Information Security Standards contains Control Standards that are new or changed from the earlier version. Consequentially, each Entity is obligated to fully inform itself as to these changes and to make adjustments as appropriate to their Information Security programme.

2 Introduction

5

2.1.2 Purpose

The Abu Dhabi Information Security Standards document is intended to guide Entities and business partners in areas requiring focus for the application of Information Security controls. Adherence to the Control Standards supports Information Security controls being deployed consistently across Abu Dhabi Government Entities (ADGEs).

The Abu Dhabi Information Security Standards document is supported by accompanying guidance documentation (see Section 6 Related Documents for an overview of these items). The Standards should be read in conjunction with these supporting materials.

2.1.3 Scope

The Abu Dhabi Information Security Standards provide definition of both management and technically oriented control standards across twelve domains, these being as show below.

Figure 1: Abu Dhabi Information Security Domains

The functional scope of this document extends beyond Information Technology, to address the broader scope of Information Security. The disciplines shown above are assumed to be interrelated and interdependent.

Human Resources Security

Information Security Training, Awareness and Communication

Physical & Environmental

Security

Identity and Access Management

Information Security Incident

Management

Third Party Security

Information Asset Management

Information Systems Design, Development

& Testing

Information Systems Operations

Management

Information Systems Continuity

Management

Information Security Governance

Information Security Risk Management


2.1.4 Applicability

Control Standards defined within this document have applicability to Abu Dhabi government personnel, contractors and other third-party organisations with responsibility for the creation, handling, storage, transmission and destruction of Abu Dhabi government information assets, including information systems and other equipment.

Entities have the responsibility for ensuring that controls are deployed in sufficient depth and range to ensure Control Standards are achieved effectively, in relation to the information assets for which they (or their nominated suppliers) have a custodial responsibility. This shall include assets that are provided by, or managed for, the Entity by third-party organisations.

Government Entities are required to use security controls to meet Information Security requirements. Selecting, designing, implementing and managing an appropriate set of controls is critical in the effective management of risk.

Three levels of categorisation of information systems have been defined that have a bearing upon control applicability. The following definitions of categorisation are used when selecting a level of control to apply.

Low The information system is categorised as LOW if the loss of confidentiality, integrity, or availability is expected to have limited adverse effect on the Entity’s operations, assets, or personnel. Although the Entity would be able to perform its primary functions, it would do so in a noticeably reduced capacity. This degradation in mission capability could also result in minor loss of organisational assets and possible loss of personal privacy.

7

Medium The information system is categorised as MODERATE if the loss of confidentiality, integrity, or availability is expected to have a serious adverse effect on the Entity’s operations, assets, or personnel. This translates to a significant degradation in the organisation’s mission capability and ability to perform primary functions, and could result in significant financial loss and damage to organisational assets.

High The information system is categorised as HIGH if the loss of confidentiality, integrity, or availability is expected to have a severe or catastrophic adverse effect on the Entity’s operations, assets, or personnel. In the event of a security breach, the organisation would be unable to perform one or more of its primary functions, resulting in major financial loss or severe damage to organisational assets.


The Abu Dhabi Information Security Standards are intended to support government Entities in implementing and embedding an Information Security framework. The framework benefits Entities in achieving an integrated perspective on Information Security capabilities that need to be deployed and maintained.

The diagram below defines the key elements of such a framework.

A summarised definition of the concepts is given in the table below. The individual components are then expanded upon in more detail within relevant areas of the Control Standards section of this document.

Figure 2: Abu Dhabi Information Security Framework

3 Information Security Framework

Design & Implementation Methodology

Risk Management - Change Management - Continuous Monitoring

Pro

gram

me

Leve

l A

ctiv

itie

sSy

stem

Lev

el

Act

ivit

ies

Ong

oing

Act

ivit

ies

Entity Information

Security Programme

Plan

Key Security

Indicators

Entity Enterprise

Architecture

Enterprise Security

Architecture

Common Control

Catalogue

Abu Dhabi Information

Security Standards

Other External

Obligations

Entity Security

Policy

Information Asset

Inventory(System+Data)

Domain-Specific

Plans

System Security

Requirements

System Information

Security Design

System Security

Implementation

System Security Testing

Security Authorisation

10

15

9

14

6

8

13

18

5

12

17

3

11

16

4

9

Item No.

Framework Level

Component Description Primary Related Control

Standard(s)

1 Programme Abu Dhabi Information Security Standards

This document – it provides definition of Information Security Control Standards that an Abu Dhabi Government Entity (ADGE) is expected to follow.

All

2 Programme Other External Obligations

In addition to the Information Security Standards, Entities are obligated to consider other external authorities that will have a bearing upon their Information Security programmes i.e. laws and regulations of the U.A.E and the emirate of Abu Dhabi.

SG.5

3 Programme Entity Information Security Programme Plan

The Entity’s high-level plan outlining its long term (multi-year) approach for implementing and managing Information Security. The Plan will address both how the Entity will achieve its compliance obligations and also how it will address the risks and requirements that are unique to its own environment.

The Programme Plan should articulate specific, measurable goals and the key initiatives that will be resourced and undertaken to achieve them.

SG.1

4 Programme Key Security Indicators

Performance indicators that allow an Entity-level Information Security Governance Committee (ISGC) to determine how well the objectives set within the Information Security Programme Plan are being met.

SG.9


Item No.

Framework Level


Standard(s)

5 Programme Entity Information Security Policy

The documented expression of management intention and the communication of expected behaviours in support of the Entity’s Information Security Programme.

SG.8

6 Programme Information Asset Inventory

Information assets will encompass both information systems and data. Information assets may be housed on information systems and also held in other forms (e.g. on paper).

The asset inventory confirms key attributes of the information asset that aid its secure management.

AM.1/AM.6

7 Programme Enterprise Information Security Architecture

Where the Entity has implemented Enterprise Architecture, this will serve as a key input to the formulation of its design for Information Security controls.

SG.7

8 Programme Enterprise Information Security Architecture

A blueprint for the Information Security controls not specific to any individual information system.

SG.7

9 Programme Domain-Specific Imple-mentationPlans

Delivery-oriented plans that relate to building out control capabilities in specific disciplines. These plans will provide the specifics for how individual capability areas defined within the Enterprise Information Security Architecture will be implemented.

SG.1

11

Item No.

Framework Level


Standard(s)

9 Programme(Cont.)

Domain-Specific Imple-mentationPlans

Depending on the size of the Entity and the complexity of its Information Security programme, these plans may be rendered as either free-standing documents or as appendices to the Information Security programme plan.

SG.1

10 Programme Common Control Catalogue

A summary of the current implementation status of non-system specific Information Security Controls available within the Entity.

The Enterprise Information Security Architecture referred to above communicates the target state for the common controls; the Catalogue indicates their present status. (It is possible for both items to be rendered in a single document, so long as target vs. actual state are clearly delineated).

SG.11

11 System Security Requirements of Information Systems

The security expectations that apply that are specific to the target information system (e.g. specific business requirements for confidentiality of the data being hosted).

IS.1

12 System Information Security Design

The design confirms the Information Security controls that will be applied to meet the agreed requirements for the information system. The design will call upon elements from either the Common Control Catalogue or tailored controls that are unique to the target information system.

IS.2


Item No.

Framework Level


Standard(s)

13 System System Security Implementa-tion

Entities are required to implement information systems in a manner that it is consistent with the approved Information Security Design for that information system.

IS.3-IS.12

14 System System Security Testing

Security testing should confirm that the information system meets requirements (including compliance obligations) and that the deployed security controls cannot be by-passed or subverted. A test plan, prepared before implementation, should guide the testing activity to ensure that the information system’s functioning and security control set perform in a manner consistent with the approved Information Security design.

IS.13

15 System System Security Authorisation

Approval from the Entity’s Authorising Official that testing has confirmed that the information system’s security design adequately addresses requirements and relevant risks have been adequately responded to in order to permit the transition of the information system to ‘production’ status.

IS.13

16 Ongoing Risk Management

Identifying, analysing and responding to risk needs to occur throughout the information asset’s lifecycle to ensure the optimum configuration and placement of Information Security controls.

RM.1-RM.5

13

Item No.

Framework Level


Standard(s)

17 Ongoing Change Management

With its potential to introduce new risks, to alter control requirements or modify control specifications, change needs to be overseen effectively throughout the information lifecycle.

SG.4/OM.2

18 Ongoing Continuous Monitoring

Entities need to have in place mechanisms that verify that Information Security programme objectives are being met and that security controls continue to be fit for purpose. Where monitoring identifies unacceptable deviation, corrective action measures need to be applied.

SG.1/SG.9/OM.5

All Abu Dhabi Government Entities are expected to adhere with these Standards, in support of achieving compliance with the Abu Dhabi Information Security Policy. Conformance with Control Standards needs to be achieved on a prioritised basis, with the Entity making a determination of which Control Standards it will achieve compliance with first, on the basis of:

a) its own risk profile

and

b) its available resources.

A ‘Suggested Priority’ is offered for each Control Standard within this document. However, this is only offered as a suggestion – the Entity is still obligated to prioritise the application its controls, in the context of it understanding its own remit, business processes, risk profile, management decision making and capabilities.

4 Compliance and Enforcement


Once the Entity has reached the point of addressing a specific Control Standard, Control Specifications associated with that Control Standard are assigned one of three designations: Mandatory, Recommended or Suggested. These designations guide the Entity as to the expected level of compliance. They are explained in Section 7.1 of this document.

The Entity should maintain its own self-assessment capabilities to determine if compliance is being maintained. It is anticipated that this capability will be achieved via role of the Entity’s Chief Information Security Officer (CISO), with their work being overseen by the Entity’s Information Security Governance Committee (ISGC).

The Abu Dhabi Systems and Information Centre (ADSIC) has the primary and definitive responsibility for determining if compliance to these Standards has been achieved. Personnel and Entities found to be non-compliant with these standards may have their access to information systems and data revoked. They may also be subject to disciplinary and/or criminal actions, as determined by government policies, regulations and the laws of the United Arab Emirates.

Information systems (including network devices) found to be non-compliant with these Standards may be restricted from processing government data and from connecting to government networks.

Abu Dhabi Government Entities are responsible for ensuring that third-party suppliers engaged on their behalf are acquainted with, and contractually committed adhering to relevant elements of these Standards and the Entity’s Information Security programme.

5 Application of this Version

This is the second version of the Abu Dhabi Information Security Standards. A number of Entities have already embarked on their Information Security programme aligning to the first version of this document.

Appendix D of this document provides a mapping of content from version 1 of the standards to version 2 and Appendix E provides a mapping in the other direction. These resources should aid Entities in determining their level of compliance with the new version of the control standards.

Following release of this version of the Standards, future ‘point’ releases will occur to provide minor updates ahead of the next full version i.e. version 3. Updates to Control Standards will be shown within the ‘Control Version History’ field of the impacted Control Standard.

15

6.1 Alignment with Related Government Standards

The Abu Dhabi Information Security programme is one of a number of initiatives sponsored by the Executive Council of Abu Dhabi.

These Standards are intended to provide a coherent perspective on multiple disciplines relevant to the management of Information Security by Abu Dhabi Government Entities. The Standards do not have the intention of replacing or replicating other government standards.

Where government-wide Policies and Standards exist in related areas then these should be regard as the predominant reference and any contradictions should be resolved in their favour. Examples of potential government-wide Standards including:

• Enterprise Risk Management• Audit Management• Incident Management• Business Continuity Management

Absent government-wide Standards in any associated areas, then Entities may reasonably assume that these Information Security Standards serve as a predominant reference until such time as such other materials are approved and published.

6.2 Supporting Documents

The Information Security Standards are one component within the wider Abu Dhabi Information Security Programme. The Standards have an interface to, and dependencies upon, other key publications within the government-wide programme. The diagram illustrates the key publication types that have a relationship with the Information Security Standards. The publications supporting these Standards can be requested via the following email address:

6 Related Documents

Figure 3: Abu Dhabi Information Security Programme Publications

Abu Dhabi Information

Security Policy

Information Security Standards

Information Security Guides

Information Security Templates

& Checklists

[email protected]


7 Summary of Key Changes to these Standards since the Last Version

Since the publication of the first version in June 2009, the Abu Dhabi Information Security Standards have been adopted across a range of government Entities. The learning taken from these deployments, changes in Information Security best practice and assessment by subject matter experts has informed the design of this second version of the Abu Dhabi Information Security Standards.

The key changes in this version of the document are as summarised below.

Change Description

Greater Orientation Toward Tangible Control Definition

This version of the document has a stronger weighting toward specific, implementable, verifiable steps in support of an Entity’s Information Security programme.

New Information Security Domains

Two new domains have been added:

- Information Security Governance This is intended to provide the structural framework needed within Entities to ensure the effectiveness of their Information Security programmes.

The ‘Strategy and Planning’, ‘Policy and Standards’ and ‘Performance Management’ sections of version 1 have been subsumed into the new domain of Information Security Governance.

- Third Party Supplier SecurityGiven the range of ways in which Entities make use of third-party service and product providers, specific attention is paid to how these stakeholders should be integrated into Entity’s Information Security programme.

17

Change Description

Revised Information Security Domains

The following domains from version 1 have changed as follows:

- Information Systems Acquisition, Development and MaintenanceThe name of the domain has changed to: ‘Information Systems Design Development and Testing’ to give a clearer focus on upstream activities i.e. those which occur prior to information assets and systems moving to an operational/production state.

With a closer focus on just design, development and testing activities, the following movements have, as a consequence, been made:

• Acquisition elements of this section have moved to ‘Third Party Supplier Security’.

• Maintenance elements of this section have moved to ‘Operations Management’.

- Awareness and Training & Communications and OutreachThese domains have been combined into the new: ‘Training, Awareness and Communication’ due to their common focus on achieving the outcome of stakeholders being aware of Information Security responsibilities and key issues.

- Business Continuity Management The domain has been renamed to ‘Information Systems Continuity Management’. End-to-end Business Continuity Management, with its focus on the continuation of business processes, is beyond the scope of these Information Security Standards.

- Communications and Operations ManagementThe name of the domain has been changed to ‘Operations Management’. Communications as a technical discipline has both upstream (i.e. design and test) as well as downstream (i.e. support and maintenance) dimensions.


Change Description

Removal of Non Entity Related Content

Version 1 control standards content describing the responsibilities of ADSIC, ADAA and any other party beyond government Entities has been removed. This has been done with the intention of making the Standards more closely focused on the needs and priorities of government Entities themselves.

Removal of Security Objectives

The concept of Security Objectives has been removed from version 2 as it was not recognised as making a substantial contribution to the effectiveness of security deployments. Entities now have the requirement to set their own tangible and measurable objectives for their Information Security programme (please see the Information Security Governance section).

Movement of Content Between Security Domains

Some control standards have been moved between sections in order to achieve a more logical and mutually supportive set of controls in a given area of focus. Appendices D and E provide mappings of v1 control standards to their v2 counterparts, and vice versa.

Addition and Removal of Controls

Following review, some controls have been removed and some new controls added. This being with the intention of ensuring that the Standards provide a sufficiently broad and coherent expression of Information Security expectations.

Appendix D & E confirm if a control is new in version 2 or if a version 1 control has been retired (either completely or via substitution with a different control).

Clarified Definition of What Constitutes a Control Specification

As per v1, all Control Standards are mandatory in nature. This is consistent with the approach found in international standards and other best practice sources.

To address requirements that are specific and unique to Abu Dhabi, the decision has been taken to augment these Standards with Control Specifications that have a variable applicability, depending upon the categorisation of the information system at hand.

Point 8 in Section 7.1 below expands upon the concept of Control Specification applicability.

19

7.1 Changes to Control Standard Structure

In addition to the above changes, the structure and content of Control Standards has also been revamped, as illustrated. The key shown below provides guidance on the individual elements of the Control Standard’s new structure.

XX.4 Control Name Version 2.0Suggested Priority

P2

Control Standards

Control Standards definition

Control Type qDirective q Preventive qDetective q Corrective

Control Specification L M HXX.4.1 Control Specification Definition

XX.4.2 Control Specification Definition

XX.4.3 Control Specification Definition

Control Version HistoryV1.0 Control version history

Control Dependencies

List of Abu Dhabi Control that this control depends on

References List of related references that are used or/and related to this control

a

M M M

S R M

S R R

11

10

9

7

6

8

5

1 2 3

4


Key Change Description

1 Simplified Clause Numbering

The numbering of controls has been simplified, to aid ease of navigation and ease of referencing.

The new numbering format is:

DOMAIN.CONTROL STANDARD NUMBER

An example being:

AM.1This simply means that this is the first control in the Information Asset Management section of the Standards.

A Control Specification within a Control Standard inherits its numbering from its parent control standard. So:

AM.1.2Simply means that this is the second element of Control Specification applicable to the AM.1 Control Standard.

2 Control Name The title of the control standard.

3 Control Version The current iteration of the control. (Note: where a Control Standard from the previous version of the document had contained similar content, but a different name, the Control Standard will show in this version as version 1, rather than version 2).

4 Control Prioritisation

A suggested priority has been offered for determining the order in which control standards should be addressed. This exercise has been informed by best practice and practitioner experience.

21


4 Control Prioritisation(Cont.)

Three Priorities have been allocated:

PRIORITY 1 – The essential first steps that should be taken by any organisation to provide a base level of preventive and detective controls.

PRIORITY 2 – Intended for government Entities that have implemented their foundational controls and who wish to augment these with capabilities tailored to their environment. Priority 2 controls will likely be deployed by organisations that have stabilised their Information Security governance, risk management and security funding activities, allowing them to deploy controls in a discerning, targeted way.

PRIORITY 3 – Higher-level controls, likely deployed by Entities with mature and well-resourced Information Security Management Systems that are afforded significant executive priority and which are well integrated with other management disciplines. Sophisticated controls will be mutually supportive and deployed in manner where there is measurable business benefit.

The prioritisation model is not intended to be prescriptive. The actual implementation priority will be contingent upon the organisation’s remit, objectives, business processes and risk profile.

5 Control Standards The security outcomes needing to be realised in order to achieve Standards compliance and to ensure adequate security.



6 Control Types The concept of control types has been introduced to help Entities determine whether there is a balance in their control set.

DIRECTIVE CONTROLS - Express management expectations of behaviours and activities required for risk avoidance and risk mitigation, in support of the Information Security programme. (Example controls: Information Security policy, security-related schedules within third-party supplier contracts).

PREVENTIVE CONTROLS - Avoid security-related threats from being manifested, or limit their potential to achieve their fullest potential impact. (Example controls: network firewalls, segregation of duties, email spam filtering).

DETECTIVE CONTROLS - Identity vulnerabilities that are either being exploited, or potentially could be exploited, to realise a threat. (Example controls: system log analysis, network vulnerability scanning).

CORRECTIVE CONTROLS - Contribute to the return of an information asset to its last known good state, with the view to removing vulnerability, or reducing potential impact to an acceptable level. (Example controls: information system reimaging to an approved configuration baseline, lessons learned reporting).

23


7 Control Specification

One or more elements of control implementation specifying how a given control standard may be met.

Control specification content has been made modular in this version of the Standards. It has been separated into more digestible components, with each being given a unique identifier to aid referencing. It is anticipated that this approach will support Entities in determining the tangible steps they will need to take to achieve compliance with a given control standard.

8 Control Specification Applicability

The expected level of compliance is now communicated, alongside each Control Specification.

The three levels of applicability are:

MANDATORYThe specific element of Control Specification is expected to be addressed in full, at all times, by all Entities.

RECOMMENDEDThe Control Specification would typically be anticipated to apply to the majority of Entities, under normal circumstances. However, there may be specific, justifiable circumstances which make the Control Specification not applicable in the specific situation at all, or only partially. The Entity should be able to articulate a meaningful and informed rationale for why the Control Specification does not apply in the specific case concerned.



8 Control Specification Applicability(Cont.)

SUGGESTEDThe Control Specification is intended as supplementary support for those Entities that are in the process of maturing and consolidating their Information Security control set. The Control Specification is discretionary only – it is anticipated that Entities may wish to consider the specification, but are not obligated to do so.

Section 9 provides more information on these levels of applicability.

9 Control Version History

The Control Version History section is intended to serve as a place to record any changes to Control Specifications that have occurred since the last major release of the Standards. In version 2, this field is left empty. However, where there are any minor changes published between version 2 and version 3, this is where they will be recorded.

10 Control Dependences

Other Control Standards or process components which the given Control Standard has a direct reliance upon.

11 References External best practice references beyond the content of this document. Such references encompass supporting materials within the Abu Dhabi Information Security Programme, international standards and recommendations from professional bodies. The cited references provide Entities with the opportunity to read further in the area concerned.

Note: in version 1 of the Abu Dhabi Information Security Standards, Control Enhancements were intended to act as an additional level of control specification for information systems of ‘Medium’ and ‘High’ categorization. The concept has been removed from this version of the Standards. The right-hand columns of the Control Standard format above show that the Control Specification applicability now serves a similar purpose.

25

8 Implementation Priorities - When & How to Apply Controls

8.1 When to Apply Controls

Government Entities are expected to exercise discretion and good judgment in determining what Information Security controls to implement, where to implement them, how and when.

The decision-making process will be influenced by:

• The mandate and business objectives of the Entity.• The business processes that the Entity transacts.• The value and sensitivity of the government information asset’s within the

Entity’s custody.• The complexity of the Entity’s supply chain e.g. how much of its business process

is dependent upon third-parties.• The range, depth and potential impact of risks faced by the Entity.• The resources available to deploy in building, implementing and managing

security-related controls.• The knowledge, skills and experience of Entity personnel in relation to

Information Security.• The legacy of what controls have already been deployed.

Additionally, the Entity will be guided by two elements from these Standards that help determine an appropriate sequence of control implementation. These being:

Suggested Priority

Section 7.1 defines the suggested priorities that have been allocated to control standards.

These priorities are meant only to guide the Entity – they are not intended to be prescriptive. Due to its own unique circumstances, the Entity may rightly determine that a different sequence of priority is merited.

The priorities are meant to provide a logical sequencing of controls to help answer the questions: ‘where do we start?’ and ‘where should be go next?’


Suggested Priority (Cont.)

The highest priority controls have the underlying themes of:

1) Setting clear management direction for what is expected of the Entity’s Information Security capabilities.

2) Deploying basic preventive controls to stop very common threats from being manifested.

3) Implementing a foundational level of detective controls to help the Entity understand its true risk profile and to gain an appreciation of what’s really happening in relation to its information assets.

Control Specification Applicability

Section 7.1 defines the levels of Control Specification applicability relevant to a given control i.e. ‘Mandatory’, ‘Recommended’ or ‘Suggested’.

The interrelationship between control priority and control specification applicability may be summed up as:

Control specification Applicability confirms the expected level of control application i.e. what must, should and may be done. Control Prioritisation provides a prompt for how quickly a given control standard might be addressed.

It is preferable to have a balance in the Entity’s security control set and for controls to be mutually supportive. In this context, an Entity should not seek to implement all elements of Control Specification within a Priority 1 control (including ‘Suggested’ items) if this would be to the detriment of applying ‘Mandatory’ elements of other, lower priority, controls.

27

8.2 How to Apply Controls

These Standards impose compliance obligations upon Entities. However, discretion and good judgement are required as to what resources are applied, and in what configuration, in order to achieve those obligations and to implement the additional controls judged necessary by the Entity.

Entities need to determine what organisation structure best suits achievement of its own Information Security Programme Plan. Examples where decision making is required include:

• Whether the mandate of the Information Security Governance Committee should be addressed by a free-standing committee or incorporated into the functioning of an already existing committee.

• Whether the role of Chief Information Security Officer (CISO) should be full or part time.

• Whether the CISO role should be rendered at corporate-level or within an individual business unit (e.g. the IT department).

• Whether the level of risk, programme goals and level of activity provide justification for additional security-related resources, beyond the CISO.

• What weighting should be applied to Information Security roles i.e. technical vs. managerial.

• What minimum level of experience, competence and qualifications post-holders require in order to successfully achieve the goals of the Entity’s Information Security Programme.

A one-size-fits-all approach is not practical, given the diversity of Abu Dhabi Government Entities, in terms of their remit, structure, risk profile and resources.

In the above context, security domains described within these Standards should not be taken to be equivalent to specific organisational roles or units. For example, obligations applicable to Information Security Incident Management may be undertaken by a function that has responsibility for all types of incident across the Entity. Similarly, Asset Management obligations do not imply that separate and demarcated Asset Management provisions need to be created solely for the purpose of achieving alignment with the Asset Management expectations of these Standards.


9 Mandatory vs. Recommended vs. Suggested Controls

The Control Standards described within this document show three levels of expected applicability i.e. in relation to control specification:

• Mandatory• Recommended• Suggested

These terms are explained in section 7.1 of this document. They are intended to help Entities have a clear view as to what the minimum expectations are of them, in relation to Information Security.

The level of applicability correlates to one of the three categorisation levels defined in section 2.1.4 i.e. Low, Medium and High. As an example, an element of control specification may be Mandatory for a High categorisation system but only Recommended for Medium and Low categorisation systems.

The level of Control Specification application is expanded upon in the table below.

Applicability Level MandatoryDescription

‘Mandatory’ Control Specification elements are expected to be fully complied with by the Entity, in full, from the time that the given Control Standard is implemented.

Due the constraints of finite time and resources, it is recognised that an Entity will not be able to achieve compliance with all ‘Mandatory’ components from the outset of its Information Security programme. The Entity’s Information Security Programme Plan should demonstrate the prioritisation for control implementation, mapped to the relevant Control Standards within this document.

Suggested priorities have been proposed against each Control Standard within this document but Entities are expected to apply to management discretion, based upon their business priorities and unique risk profile.

For any Control Specification not designated as ‘Mandatory’ there is a degree of discretion and judgment which needs to be applied by the Entity’s management.

29

Impact Upon the Entity’s Risk Management Activities

Mandatory control elements need to be implemented, irrespective of the results of the Entity’s risk management activities. They represent core areas of capability in the given discipline of Information Security.

Applicability Level RecommendedDescription

Control Specification elements that ADSIC assessment teams would typically expect to see in place. However, there is the understanding that circumstances specific and unique to the Entity may mean that the given Control Specification is either not applied at all, or not applied in full. However, such exemptions would need to be on the basis of defined criteria that can be justified by the Entity. (It should not be interpreted that ‘Recommended’ Control Specification elements are merely advisable to implement).


Risk analysis will help determine if the Entity’s unique circumstances make the given control type applicable or not applicable in the specific setting being analysed. Risk management can provide the Entity with informed and coherent justification for the de-scoping of Recommend Control Specifications – where appropriate.

Applicability Level SuggestedDescription

Primarily oriented toward Entities which have established a robust foundation of core controls and which are now on a journey of continuous improvement. Just because they are not mandatory does not mean that Control Specifications of this type should be ignored. Entities should actively consider their suitability and relevance when deploying their Information Security controls. They have the potential to enhance the protection of the Entity’s information assets. However, for non-mandatory control elements the Entity is obligated to make an evaluation of the cost of control implementation against the anticipated protection benefit.


Risk analysis may provide a justification for whether suggested controls should be applied within a given Entity.


Entities should appreciate that the Abu Dhabi Information Security Standards provide a common base of security definition that allow minimum levels of protection to be achieved and to facilitate the secure sharing of information across areas of government.

The Standards are not an end in themselves. Achieving the minimum necessary compliance with them should not be regarded as a primary goal. The Standards – and assessments made against them – are merely instruments intended to support the broader and more significant goals of:

• Informed and responsible information ownership and usage

• Protection of government information assets to a level appropriate to their value and the risks posed to them

• Engendering and maintaining stakeholder confidence in the capability of government to deliver sufficiently secure and reliable services to the emirate of Abu Dhabi

• Protection and enhancement of the reputation of Abu Dhabi, at home and abroad

• Maximising the return on investment in information assets and systems, through the enhanced support afforded to their availability, confidentiality and integrity as part of a broader contribution to service quality

In the above context, government Entities have the primary responsibility for ensuring that they have the appropriate depth and range of Information Security controls deployed. In some circumstances, the Entity may determine that the control definition required exceeds what is found in these Standards.

31

9.1 Areas Requiring Entity Interpretation

Government Entities are required to engage with these Standards, and the best practice principles they convey, in a discerning manner. In some instances, this requires Entities to make a judgement about how management and technical controls should be implemented.

Within the Standards, terms such as “appropriate”, “timely”, “important” and “competent” have been used. These require a subjective decision to be made on the part of the Entity. An example being:

“Assigned auditors should be competent to undertake specialist Information Security audit”.

(From SG.10.4)

For such Control Specifications, the Entity is obligated to determine for itself what constitutes “competent” in the context of its own business processes, risks and deployed technologies. It is neither practical nor advisable for these Standards to specify absolutes across all areas of an Entity’s engagement with Information Security. For areas requiring subjective decision making, the Entity should be able to show, during assessment, that the judgement it applied was thoughtful and took advantage of all necessary inputs.

10 Common vs. Tailored Security Controls

Government Entities should take the opportunity to review how their obligations to these Standards can be met. As would be true in the implementation of any control set, there is the need to effectively balance time, cost and quality constraints. Entities should seek opportunities that allow them to implement the right Information Security controls, at the right time and in the right way.

One way to improve the speed and quality of Information Security control implementation is to build a common Enterprise Information Security Architecture that is then leveraged by multiple information assets and systems. This requires the Entity to take a holistic view of its Information Security requirements, rather than merely considering controls on a system-by-system or service-by-service basis.


Common security controls have the greatest potential to help the Entity balance expenditure on Information Security vs. effectiveness of the controls deployed. However, for common controls to be effective, their range of potential uses needs to be carefully evaluated. A control that is ideally suited for Service A may be much less optimised for Service B, when it is introduced a year from now.

Examples of common controls that multiple systems and services could potentially leverage include:

• Single Sign-On mechanisms for user authentication

• Password self-service mechanisms for user authentication

• Security Event and Incident Management tooling. (Possibly making use of a common platform that then has technology-specific add-ons)

• An eLearning platform hosting a range of Information Security-related content

• Unified processes and procedures e.g. one common Change Management process applied to all services and systems

The application of common controls will depend on the risk context and the business need of the Entity. There will be circumstances where a tailored security control (i.e. one that is specific to the individual service or system) is necessary, justified and preferable.

The Entity has the obligation to understand its Information Security needs, threats and vulnerabilities and to tailor its control set appropriately. The Abu Dhabi Information Security Standards are intended as a starting point for informed engagement within the Entity.

Tailored controls will be ones that are specific and unique to the target information asset. They will be utilised where there is no common control is available, or where the available common control is not fit for the specific purpose. ‘Tailored’ controls do not necessarily indicate that the control has been heavily customised. Such might be a standard, off-the-shelf control type from a vendor, but which has been acquired specifically in reference to a target information system. Equally, a version or copy of an existing common control may be adapted or configured in a way that makes it unique to the specific control requirement.

33

Examples of tailored controls would include:

• Authentication tokens specifically deployed for access to a highly sensitive systems

• A biometric access control infrastructure specifically implemented for access to a data centre environment

11 Alignment to International Standards

The development of these Standards has been informed by reference to, and use of, international best practice. The following references having served as the primary sources:

• ISO/IEC 27001: ‘Information technology — Security techniques — Information Security management systems —Requirements’.

• ISO/IEC 27002: ‘Information technology — Security techniques — Code of practice for Information Security management’.

• National Institute of Standards & Technology (NIST) Special Publication 800-53: ‘Recommended Security Controls For Federal Information Systems & Organizations’.

• Other NIST Special Publications applicable to specific domains of Information Security.

• SANS Institute best practice recommendations for control application.

The ADSIC publication: “Abu Dhabi Information Security Standards-ISO27001 Mapping” provides a confirmation of how ISO 27001 requirements correspond to control standards within this document. This will be of assistance to Entities preparing for initial certification against ISO 27001, or for those seeking to maintain an existing certification.

It should be noted that while the Standards have made reference to the above sources, this document does not intend to duplicate them. This version of the Abu Dhabi Information Security Standards is intended to be tailored to the specific priorities, culture and configuration of the government of Abu Dhabi.


12 Abu Dhabi Information SecurityStandards

12.1 Information Security Governance

SG.1 Information Security Programme Management

Version 1.0Suggested Priority

P1

Control Standards

The Entity shall develop and disseminate an organisation-wide Information Security programme plan.


Control Specification L M HSG.1.1 The Entity should agree and communicate

specific, measurable and scheduled goals for its Information Security programme. Goals should reflect the programme’s obligation to support:

• Business strategy and priorities

• The Entity’s management of its security-related risks

• Compliance obligations to these Standards and other relevant laws and regulations

• The promotion of a security-oriented organisational culture within the Entity

SG.1.2 The Programme Plan should provide an overview of the requirements for the Information Security programme in meeting agreed upon programme goals; and a description of the security programme management controls and common controls in place or planned for meeting those requirements.

aa

MMM

MMM

35

Control Specification L M HSG.1.3 The Programme Plan should define and allocate

roles and responsibilities, confirm management commitment, facilitate coordination among organisational Entities, and support compliance with these Standards.

SG.1.4 The Programme Plan should be approved by the Entity executive with responsibility and accountability for the risk being incurred to organisational operations.

SG.1.5 The Entity’s Information Security Programme Plan should be aligned to the annual objectives specified for the government-wide Abu Dhabi Information Security Programme.

SG.1.6 The Programme Plan should be reviewed regularly by the Entity’s senior management and revised as necessary to address organisational changes and problems identified during plan implementation or security control assessments.

SG.1.7 The Entity should monitor progress against its Information Security Programme Plan and take corrective action where milestones are not met or anticipated benefits are not realised as originally envisaged.

MMM

MMM

MMM

MMM

MMM


Control Specification L M HSG.1.8 In support of its Information Security Programme

Plan, the Entity should develop supporting plans to build out specific capabilities in defined areas. These subsidiary plans may include (but may not be limited to):

• Information Asset Management

• Identity and Access Management

• Risk Management

• Training and Communications

• Information Security Incident Management

• Information Systems Continuity Management

• Operational Readiness

• Physical and Environmental Management

The deliverables defined within these plans should be aligned with the Entity’s Security Architecture (see SG.7 Enterprise Information Security Architecture). After their implementation their status should be recorded in the Entity’s Common Control Catalogue (see SG.11 Common Control Catalogue).

Subsidiary plans may be rendered either as free-standing documents or as appendices to the Entity’s Information Security Programme plan.

SG.1.9 The Entity should make a determination of the inputs needed to deliver against agreed Information Security-related plans and should allocate the resources required to protect information assets.

The Entity should establish a discrete line item for Information Security in organisational programme management and budgeting documentation.

MMM

MMM

37

Control Specification L M HSG.1.10 The Entity should monitor expenditures on

Information Security, against the agreed budget, and evaluate the effectiveness of its investment in Information Security controls.

SG.1.11 The Entity should consider the categorisation of services when allocating its Information Security budget (with highest categorisation services meriting priority for budget allocation).

Control Version History


None

References • NIST Special Publication 800-53 Revision 3: o PM-1 Information Security Program Plan o SA-1 System And Services Acquisition Policy and Procedures o SA-3 Life Cycle Support

• Abu Dhabi Information Security Governance Guide

• Abu Dhabi Information Security Programme Plan Template

MMM

MMM


SG.2 Information Security Categorisation Version 2.0Suggested Priority

P1

Control Standards

The Entity shall categorise government services according to their risk profile.


Control Specification L M HSG.2.1 The Entity should define the purpose, scope and

boundaries of each service in terms of attributes that include: the business process(es) it supports and the list of information systems it is composed of.

SG.2.2 The Entity should categorise each Government service owned by the Entity in accordance with the approach defined within the Abu Dhabi Government Service Security Categorisation Guide.

SG.2.3 The Entity should document the security categorisation results, including supporting rationale, in the Information Security Design for any information system utilised by the service.



References • NIST Special Publication 800-53 Revision 3:o RA-2 Security Categorization

• Abu Dhabi Information Security Asset Management Guide

a

MMM

MMM

MMM

39

SG.3 Information Security Organisation Version 1.0Suggested Priority

P1

Control Standards

The Entity shall define resources and develop an organisation appropriate to its Information Security activities.


Control Specification L M HSG.3.1 The Entity should appoint a Chief Information

Security Officer (CISO) with the mission, resources and empowerment from the Entity’s executive management to coordinate, develop, implement, and maintain an organisation-wide Information Security program.

SG.3.2 The role of the CISO should be supported by additional Information Security-related roles, as required to achieve the deliverables and outcomes defined within the Information Security Programme Plan.

Dependent upon the size of the Entity, its service portfolio and its risk profile, the Information Security organisation may require one or more Information Security personnel, in addition to the CISO. The additional personnel may undertake a range of management, functional and technical duties that support the CISO in delivering against the Information Security Programme Plan.

SG.3.3 Information Security personnel should have skills, qualifications, experience and competencies commensurate with the requirements of their positions.

a a

MMM

MMM

MMM


Control Specification L M HSG.3.4 The Information Security organisation should

have adequate organisational positioning to ensure effective direction, accountability and empowerment for the programme. The reporting line for the Information Security organisation should allow for timely and direct communication of key security issues to senior management. Information Security personnel should not be prevented or discouraged from reporting threats, vulnerabilities and control status.

SG.3.5 A regularly meeting (i.e. at least quarterly) Infor-mation Security Governance Committee should be convened to provide independent oversight and support for the work of the Information Security organisation. The committee should be represented by senior representatives from across the Entity’s executive team.

The Chief Information Security Officer should serve as the Secretary of the Committee, assuming its delegated authority to undertake day-to-day liaison with other parties (including ADSIC) on matters relating to the Entity’s Information Security Programme.



References • NIST Special Publication 800-53 Revision 3:o PM-1 Information Security Program Plano PM-2 Senior Information Security Officer

• Abu Dhabi Entity Information Security Roles & Responsibilities



MMM

MMM

41

SG.4 Security Programme Change Management


P2

Control Standards

The Entity shall manage change within its Information Security programme to ensure continued compliance to regulations and on-going management of identified risks.


Control Specification L M HSG.4.1 The Entity’s Information Security Governance

Committee should approve all changes to the Information Security Programme Plan.

SG.4.2 The Entity should establish a baseline for its Information Security Programme Plan, with proposed changes to the plan being analysed for impact.

SG.4.3 Changes to the Information Security Programme Plan should be coordinated with the organisation-wide Change Management capabilities of the Entity to ensure on-going alignment between Information Security and other organisation initiatives.



None

References • Abu Dhabi Information Security Governance Guide

a a

MMM

MMM

RRR


SG.5 Legal and Regulatory Requirements Version 1.0Suggested Priority

P1

Control Standards

The Entity shall identify and implement appropriate controls to address legal and regulatory requirements applicable to Information Security.


Control Specification L M HSG.5.1 The Entity should review and align its Information

Security activities with the Abu Dhabi Information Security Programme, which in turn will ensure alignment to relevant emirate and federal-level laws and regulations.

SG.5.2 Where the Entity identifies a contradiction between the Abu Dhabi Information Security Programme and relevant laws or regulations, it should highlight the disparity to ADSIC.

SG.5.3 Important Entity records shall be protected from loss, destruction and falsification, in accordance with statutory, regulatory, contractual, and business requirements.

SG.5.4 The Entity should implement procedures that support the protection of Intellectual Property Rights (IPR) applicable to its own information assets and which respect legitimate ownership rights of other parties (e.g. third-party suppliers). Procedural definition for IPR should encompass multiple potential formats for information assets (e.g. software, information system designs, digital data, documentation).

a

MMM

MMM

MMM

MMM

43



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management:

o 15.1.2 Intellectual Property Rightso 15.1.3 Protection of organizational records



SG.6 Framework for Information Exchange Agreements


P3

Control Standards

The Entity shall establish a framework for determining what information it will exchange with other parties and how these exchanges will be managed.


Control Specification L M HSG.6.1 Agreements should be established for the

exchange of information and software between the Entity and external parties. These agreements should be formally documented and should confirm:

• The terms under which such information and software is sent, received, stored and used.

• How exchanges of sent and received information will be logged.

• How the terms of exchange agreements will be audited.

• How long records applicable to exchange agreements will be retained.

SG.6.2 Formal exchange policies, procedures, and controls should be in place to protect the exchange of information.

SG.6.3 Information exchange agreements between the Entity and other Abu Dhabi government organisations should confirm:

• The purpose for which the information type is being provided.

• The classification of the information being shared.

a

MMM

MMM

MMM

45

Control Specification L M HSG.6.3(Cont.)

• The parties within each organisation that are authorised to review, modify, augment or delete the information.

• The reporting obligations that will apply in the event that the information is disclosed to unauthorised parties beyond the parties to the agreement.

• The reporting obligations that will apply in the event that the information is disclosed to unauthorised parties beyond the parties to the agreement.

SG.6.4 Information exchange agreements between the Entity and third-parties that are not part of the government of Abu Dhabi (e.g. external vendors) should incorporate elements a) to d) in SG.6.3 above. In addition, information exchange agreements with non-Abu Dhabi government third-parties should additionally confirm:

• The penalties and consequences (e.g. contract termination) that will potentially apply in the event of unauthorised distribution of the exchanged information to non-authorised parties.

• The restrictions that will apply (e.g. the avoidance of information being shared with sub-contractors without the Entity’s prior written permission).

• The timeline for the shared information being retained by the third-party and the obligations to purge the information after a stated period.

MMM

MMM



• The intellectual property rights that will apply to the exchanged information.

Any information exchange agreement with a vendor should be included within the enforceable contractual terms defined between the Entity and the vendor.



AM.3 Classification of Information Assets


o 10.8 Exchange of informationo 10.8.1 Information exchange policies and procedureso 10.8.2 Exchange agreements


MMM

47

MMM

SG.7 Enterprise Information Security Architecture


P3

Control Standards

The Entity shall develop an Enterprise Information Security Architecture that provides a blueprint for a unified set of common controls, applicable to information assets.


Control Specification L M HSG.7.1 The Enterprise Information Security Architecture

should identify the principle areas of control application required by the Entity to:

• Achieve its compliance obligations.

• Address areas of most significant Information Security risk to the Entity.

• Achieve the goals defined within its Informa-tion Security Programme Plan (see SG.1 Information Security Programme Management).

The security architecture should encompass a balance of directive, preventive, detective and corrective technical controls that are mutually supportive in pursuit of the Information Security programme objectives.

The Enterprise Information Security Architecture should be supported by subsidiary designs, specific to individual information systems (see IS.2 Information Security Design).

The current status of common controls identified within the Enterprise Information Security Architecture should be confirmed within the Entity’s Common Control Catalogue (see SG.11 Common Control Catalogue). It is possible that the Security Architecture and Common Control Catalogue are rendered within a single document, so long as planned vs. actual status is clearly delineated.

a


Control Specification L M HSG.7.2 The Enterprise Information Security Architecture

should be approved by the Entity’s Information Security Governance Committee.

SG.7.3 Proposed changes to the Entity’s common Information Security controls should require a review of the Enterprise Information Security Architecture and any substantive change should require re-approval by the Information Security Governance Committee.

SG.7.4 The Enterprise Information Security Architecture should be integrated with the Entity’s Enterprise Architecture framework (where such is in place).




References • NIST Special Publication 800-53 Revision 3: o PM-7 Enterprise Architecture

• Abu Dhabi IT Architecture and Standards

• Abu Dhabi Enterprise Security Template

• Abu Dhabi Information Security Common Control Catalogue Template

MMM

MMM

RRR

49

SG.8 Information Security Policy Version 2.0Suggested Priority

P1

Control Standards

The Entity shall develop, distribute and maintain an organisation-specific Information Security policy.


Control Specification L M HSG.8.1 The Information Security policy should address

the scope of the Entity’s Information Security management system, roles and responsibilities, management commitment, coordination among organisational functions and compliance obligations.

SG.8.2 The policy document should be approved by the Entity’s executive management, and published and communicated to all employees and relevant external parties.

SG.8.3 The policy should contain a definition of Information Security, its overall objectives and scope and the importance of Information Security as an enabling mechanism for information sharing.

SG.8.4 The policy should contain a statement of management intent, supporting the principles of Information Security, in line with the business strategy and the goals defined within the Entity’s Information Security Programme Plan.

SG.8.5 The Information Security policy should have general applicability to all areas of the organisation and should be augmented by supporting instructions and guidance (e.g. contracts, procedures, work instructions, check-lists) as required in specific areas of activity.

a

MMM

MMM

MMM

MMM

MMM


Control Specification L M HSG.8.6 The policy should provide clear and succinct

expression of management expectations regarding what individuals and teams should and should not do in the handling of information assets and the use of information systems with the view to achieving a requisite level of security-oriented behaviours.

The policy should articulate security-related expectations in areas including (but not necessarily limited to):

• The governance of Information Security

• The management of Information Security-related risk

• Ownership of information assets

• Classification of information assets

• Acceptable usage of information systems

• Use of cryptography

• Use of remote access facilities

• Use of system administration privileges and software

• Protection of media and equipment (including its handling and disposal)

• Hardware, Software and Network Restrictions

• Avoidance of malicious code

• Access control to information systems (including protection of passwords and tokens)

• Adherence to clean workspace provisions

• The Entity’s right to monitor access to information systems and information processing facilities

• Obligations in relation to Information Security incidents

• Obligations in relation to engagement of third-party suppliers

MMM

51

Control Specification L M HSG.8.7 The expectations articulated in the Information

Security policy should be quantifiable and traceable back to the Controls Standards of the Abu Dhabi Information Security Standards (i.e. this document). The Entity should be able to demonstrate how one or more tangible controls can or will directly achieve a given policy expectation.

SG.8.8 The Information Security policy should be reviewed regularly (at least annually) by the Entity’s Information Security Governance Committee. The committee should ensure the policy’s continued relevance, adequacy and effectiveness. Policy review should occur more frequently if significant business or regulatory change occurs.

SG.8.9 Entity personnel and other users of its information systems should be required to confirm, in writing, that they have read, understood and will comply with the obligations articulated within the Entity’s Information Security policy. A record confirming the individual’s understanding and intended compliance should be retained by the Entity, for future reference.



None

References • ISO 27002 Information technology - Security techniques - Code of practice for Information Security management: o 5.1.1 Information Security policy document

• NIST Special Publication 800-53 Revision 3: o PL-1 SECURITY PLANNING POLICY AND PROCEDURES o 8.1.1 Roles and responsibilities


• Abu Dhabi Information Security Policy Template

MMM

MMM

MMM


SG.9 Information Security Performance Management


P1

Control Standards

The Entity shall develop, report against and analyse key performance indicators relating to its Information Security programme.


Control Specification L M HSG.9.1 Information Security performance reporting

should be against specific, measurable, achievable, realistic and timetabled goals articulated by the Entity’s executive management team and the ADSIC Information Security programme team. Goals should encompass the Entity’s business needs, as well as legal and regulatory obligations. (See SG.1.1 for more information on goal setting applicable to the Entity’s Information Security programme).

SG.9.2 The Entity should develop outcome-based performance metrics to measure the effectiveness and efficiency of its Information Security implementation and the security controls employed in support of the programme.

SG.9.3 The Information Security Governance Committee should serve as the authorising and overseeing body for Information Security performance metrics. The committee should:

• Oversee the setting of performance metrics aligned to the Entity’s Information Security Programme plan and its compliance obligations to the government-wide Information Security initiative.

• Receive and analyse performance data from information owners, information system owners and Information Security personnel.

a a

MMM

MMM

MMM

53


• Report performance of the Information Security programme to ADSIC and other relevant stakeholders at a frequency and in a format specified by those stakeholders.

In his/her capacity as the Committee Secretary, the Entity’s Chief Information Security Officer should serve as the facilitator for ensuring that necessary data inputs are received and reporting outputs are produced.

SG.9.4 The Entity’s Information Security performance metrics should be aligned to the performance indicators of the Abu Dhabi Information Security Programme and should support the Entity in reporting timely and accurate Information Security status to ADSIC and other relevant stakeholders.

SG.9.5 Security performance data should be verified by a competent and independent party that is not directly connected with the work that is the subject of measurement. (E.g. supplier security performance data should not be accepted without the Entity independently verifying its accuracy and completeness).

SG.9.6 The level of attention given to a specific dimension of Information Security performance should be correlated to the associated level of risk.

SG.9.7 Information Security performance indicators should allow for management by exception, with reporting being focused on security performance deviation from known and expected baselines.

MMM

MMM

MMM

RRR

RRS


Control Specification L M HSG.9.8 Information Security reporting should consider

multiple dimensions of security performance. These should include (but not be limited to):

• Security incident status and lessons learned

• Availability, confidentiality and integrity status of key information systems

• Achievement against security programme milestones

• Status of individual security-related projects

• Security testing results and status of corrective actions

• Expenditures on security controls and the value generated

• Security training delivery and outcomes

• Security audit results and status of associated corrective actions

• Status of security-related threats, vulnerabilities and issues

• System account usage and reported violations

SG.9.9 The design of Information Security metrics should consider multiple perspectives on performance, including:

• Achievement of Information Security programme goals

• Levels of control implementation

• The efficiency and effectiveness of Information Security processes and practices

• The business impact of Information Security initiatives

SSS

SSS

55

Control Specification L M HSG.9.10 Information Security performance reporting

should be integrated with the Entity’s enterprise performance management system, to support alignment of the Information Security programme with the Entity’s business strategy.

SG.9.11 The Entity’s management should promote a culture of transparency that allows, as appropriate, for the frank and timely communication of Information Security issues and vulnerabilities, with the view to stimulating dependable Information Security performance data and an accurate perspective on the security risks faced by the Entity.

SG.9.12 The Entity should implement continuous improvement mechanisms that are informed by the data and analysis associated with its Information Security metrics. The Entity’s Information Security Governance Committee should monitor the cost, benefit and status of proposed and implemented improvements.



None

References • NIST Special Publication 800-53 Revision 3: o PM-6 Information Security Measures Of Performance

• NIST Special Publication 800-55 Revision 1: o Section 3.3 Type of Measures

• Abu Dhabi Information Security Programme Level Key Performance Indicators


MMM

SSS

RRR


SG.10 Information Security Audit Framework


P1

Control Standards

The Entity shall develop, disseminate, review and update an Information Security audit framework.


Control Specification L M HSG.10.1 The Entity’s Information Security audit

framework should address the scope, roles, responsibilities, management commitment and coordination required among organisational units, in order for compliance to these Standards and the Entity’s Information Security policy to regularly be determined.

Information Security audit activities should be supportive of the Entity’s Internal Audit framework and alignment should be achieved with the Entity’s Internal Audit Plan.

SG.10.2 Formal, documented procedures to facilitate the implement-ation of Information Security audits should be developed and approved by an overseeing function independent of the Entity’s management (i.e. audit committee, chairman or board).

SG.10.3 The overseeing function should ratify an Information Security audit plan. (This may be a stand-alone document or a component of the fuller internal audit plan for the Entity). The plan should be reviewed regularly (at least annually) by the overseeing function. In determining the frequency and depth to which a given information asset/information system is to be security audited, the overseeing function should take into account:

- The business criticality of the information asset(s)/information system.

a a

MMM

MMM

MMM

57


- The classification of the information asset(s)/ information system.

- The threats and vulnerabilities applicable to it.

- Regulatory and other external obligations.

- Past experience of material relevance (e.g. previous Information Security incidents impacting upon this or similar information assets).

SG.10.4 Assigned auditors should be competent to undertake specialist Information Security audit, with an appropriate level of skills, experience and qualifications in the specific domain of Information Security being reviewed, as well as in audit best practice. The overseeing function should ensure that auditor profiles are specifically relevant to the audit target (e.g. relevant technical skills appropriate to the technology type under assessment).

SG.10.5 Information Security auditors should be indepen-dent of the function/processes being audited to ensure the opportunity for an objective assess-ment to be undertaken. The reporting line for Information Security auditors should be via the overseeing function referenced in SG.10.2 above.

SG.10.6 The Entity’s main directive Information Security controls (i.e. Information Security Programme Plan, Enterprise Information Security Architecture, Information Security Policy, Common Control Catalogue, service-specific Information Security Designs and Information Security-related procedures) should be updated to take account of relevant audit findings.

MMM

MMM

MMM

MMM


Control Specification L M HSG.10.7 Audit results should be evidence (not opinion

or impression) based and should be divided into ‘Findings’ (verified non-compliance with these Standards and/or the Entity’s own security policy and procedures) and ‘Recommendations’ (suggested areas for Information Security management enhancement). Findings should reference the specific clause(s) of the target publication where non-compliance has been identified.

SG.10.8 Audit results should confirm the potential risks that could be manifested due to an identified finding not being addressed.

SG.10.9 Audit results should be classified and protected to a level at least equivalent to the information system/information asset being audited.

SG.10.10 Information Security audit activities should be coordinated with other audit activities within the Entity, to ensure effective reporting on performance and compliance while also minimising the business impact of audit.

SG.10.11 Functions subjected to Information Security assessment should actively not prepare for audit but instead should give an accurate account of their normal, real-world working practices.

MMM

MMM

MMM

MMM

MMM

59

Control Specification L M HSG.10.12 The independent overseeing function should

ensure that Information Security audit findings are addressed by management with a priority appropriate to the identified risk. Audit results should be made available to the Entity’s Information Security Governance Committee for it to apply oversight to the application and effectiveness of corrective actions.

SG.10.13 The entity should ensure that a sufficient range and quality of records is maintained and protected, in order to facilitate effective audit.



None

References • NIST Special Publication 800-53 Revision 3:o AU-1 Audit and Accountability Policy and Procedures

• ISO 27001 Information technology — Security techniques — Information Security management — Requirements:

o 4.2.3 Monitor and review the ISMS


MMM

MMM


SG.11 Common Control Catalogue Version 1.0Suggested Priority

P1

Control Standards

The Entity shall develop and maintain a catalogue of its common Information Security controls.


Control Specification L M HSG.11.1 The Entity should develop and maintain a

catalogue of the common controls implemented in support of its Enterprise Information Security Architecture (see SG.7 Enterprise Information Security Architecture). Common controls will be those that have applicability to more than one information system or which are not system-related (e.g. management controls).

The control catalogue should confirm:

• The unique identifier of the common control.

• The name of the common control.

• The section of the Security Architecture that the control relates to.

• The location of the control’s full specification and design.

• The purpose served by the control.

• The information system(s) or other assets that the control is currently applied to.

• The status of the control (i.e. ‘design’, ‘development’, ‘test’, ‘production’, ‘retired’).

a

MMM

61

Control Specification L M HSG.11.2 The Common Control Catalogue should be

referenced when the Entity is designing new information systems (see IS.2 Information Security Design). The Entity should seek to determine whether an existing control will be sufficient to meet a given security need applicable to the new information system. Where its specification is appropriate to the need, an existing common control should be used in preference to developing a wholly new control, applied exclusively to the individual system.

When a common control is intended to be re-used, the impact upon the control should be evaluated (e.g. whether it will have sufficient capacity to accept the additional demand placed upon it).

SG.11.3 The Common Control Catalogue may be rendered in a single document with the Enterprise Information Security Architecture (see SG.7.1), subject to it being possible to clearly delineate target vs. actual status of the common controls.



SG.7 – Enterprise Information Security Architecture

References

MMM

SSS


12.2 Information Security Risk Management

RM.1 Information Security Risk Management Planning


P1

Control Standards

The Entity shall plan its interventions, and the allocation of its resources, in the management of Information Security-related risk.


Control Specification L M HRM.1.1 The Entity’s conducting of Information Security-

related risk management activities should be undertaken in accordance with the principles, workflow and templates defined within the Abu Dhabi Information Security Risk Management Guide.

Risk will be defined as: “an uncertain event or set of events which, should it occur, will have an adverse effect on the achievement or maintenance of the desired level of security for the information asset”.

RM.1.2 The Entity’s Information Security risk management planning should take into consideration the categorisation of information assets. Assets of a higher categorisation, and those co-located with such assets, will merit more extensive risk management interventions than other asset types.

RM.1.3 The Entity should develop an Information Security Risk Management Plan that addresses, as minimum, the following areas:

• Confirmation of the organisation’s level of risk tolerance in relation to Information Security risk. (In other words, what level of risk the Entity is prepared to accept in the transaction of its Information Security programme).

a

MMM

MMM

MMM

63

Control Specification L M HRM.1.3(Cont.)

• The methodology that will be used to undertake risk management activities. (Unless otherwise agreed with ADSIC in advance, the method used will conform to that defined within the Abu Dhabi Information Security Risk Management Guide).

• The risk reporting thresholds and reporting practices that the Entity has set (e.g. what severity of risk will be reported to whom, when and via what channels and in what manner).

• Priority areas for risk identification, analysis and response/treatment (i.e. which information assets, services and technologies merit the most substantial risk interventions). These priorities should be expressed in the plan as a series of distinct risk identification and assessment exercises that will take place during the life of the plan.

• The roles and responsibilities that will apply in the implementation and oversight of Information Security risk management within the Entity.

• Resources that will be deployed for the conducing of risk management activities.

• How segregation of duty conflicts will be avoided in the conduct of risk management.

• The budget allocated to risk management and how it will be spent.

• The schedule for the conducting the phases of the risk management lifecycle described in the other Control Standards within this section.

MMM



• How risk management will be integrated within other Information Security disciplines within the Entity.

• The frequency with which the changing risk profile of information assets will be re-assessed.

The Information Security Risk Management Plan should be subsidiary to, and supportive of, the Entity’s Information Security Programme Plan.

The Information Security Risk Management Plan should be authorised by the Entity’s Information Security Governance Committee. The plan should be maintained in alignment with changes within the organisation and should be re-approved by the Committee when major changes are proposed for the plan.

RM.1.4 The Entity should ensure that it puts in place the necessary procedures, checklists and templates in order to conduct its risk management activities.

RM.1.5 The Entity’s Information Security Governance Committee should assume principle responsibility for oversight of the Information Security Risk Management processes. The committee should ensure that effective integration and harmonisation is achieved with the Entity’s Enterprise Risk Management process (where such is in effect).

MMM

MMM

MMM

65

Control Specification L M HRM.1.6 The Entity’s Information Security Risk

Management process should be integrated with its Information Systems Design, Development and Testing capabilities and its Operational Management capabilities. This integration will be demonstrated through the clear expression of necessary inputs and outputs between the disciplines, as evidenced by relevant procedures and associated working practices.

The Entity should recognise that Risk Management will serve as only one of several inputs to the design, development and testing of Information Security controls. Other key inputs will include:

• Business requirements for information services and information systems

• Compliance obligations (to these Standards and other regulations and laws of the UAE)

• Entity strategy and objectives

• Organisation culture, capabilities and resources

• Market/external constraints

RM.1.7 The Entity’s planning should recognise the need for Risk Management to be an iterative, rather than one-time, process. Consequently, time and resources should be allocated as required for follow-up and repeated Risk Management interventions, throughout the end-to-end lifecycle of its information assets.

The Information Security Risk Management Plan should allow for the repeating of Risk Management activities, as required, following changes to:

• Organisational objectives

• Organisation design

MMM

MMM



• Compliance obligations

• Supporting technologies and infrastructure

• Supply chain configuration

• Service requirements

Additionally, Information Security Risk Management planning should recognise that new or changing risk has the potential to be manifested at key transition points during an information asset’s lifecycle, including at the stages of:

• Service requirements being defined

• Controls being designed and developed

• Controls being tested

• The information asset being moved to production status

• The information asset being substantially updated during production

• The information asset being retired or replaced

RM.1.8 The Information Security Risk Management Plan should clearly articulate the constraints and boundaries that will apply in the Entity’s undertaking of risk identification, analysis, response and monitoring.

The Entity should recognise that assessment should be undertaken in all main risk areas. However, realistically, not all Information Security risks can or should have a full risk response applied. Some identified risks will be so unlikely to occur, or be of such negligible impact, that they do no merit on-going risk treatment. The Entity has the obligation to deploy its finite resources in those areas where the most significant and substantial risks exist.

MMM

MMM

67

Control Specification L M HRM.1.9 The Entity’s Information Security Risk

Management planning activities should take into account relevant knowledge and capabilities that already exist. (For example leveraging already completed risks assessments that can serve as input to the activity of planning Risk Management activities for the future).

These Standards and other government regulations and laws prescribe minimum mandatory obligations that must be met, irrespective of the Entity’s specific risk landscape. Given such, a risk assessment to confirm the need for such control types would be redundant and would potentially expend limited resources in an ineffective manner.

The Entity should, instead, use Risk Management as a mechanism for determining whether its specific business circumstances, information assets etc. merit control definition and application above and beyond that which is already specified as a mandatory minimum.

Control Specification elements defined as ‘Mandatory’ within these Standards will not be influenced by the Entity’s risk management activities. The specific control capabilities will need to be implemented at a priority confirmed within the Entity’s Information Security Programme Plan, irrespective of its risk management interventions.

MMM



Control Specification elements defined as ‘Recommended’ within these Standards may potentially be influenced by the Entity’s Risk Management activities.

‘Recommended’ specification relates to capabilities that the government of Abu Dhabi would typically expect to see in place, within most Entities. It may be the case that the threat the Control Specification relates to does not have applicability to the Entity, but its Risk Management activities would need to formally validate this.

Control Specification elements defined as ‘Suggested’ within these Standards are discretionary. The Entity may choose to adhere to them, if its risk identification and analysis suggests a need and benefit in doing so.

RM.1.10 The Entity’s executive management should provide the inputs necessary for Information Security Risk Management to be effective.

Key determinants in whether the Entity will be able to limit its Information Security risk exposure to an acceptable level will include (but not be limited to) whether:

• Information Security awareness is actively promoted within the organisation.

• Information Security is demonstrated to be an on-going management priority.

• Sufficient funding is provided to design, implement and maintain a range of preventive, directive, detective and corrective Information Security controls.

MMM

MMM

69


• The organisation’s recruitment, training and performance management capabilities support the placement of competent practitioners with the necessary skills, motivation and experience to implement and manage security components.

• An organisational culture supportive of perfor-mance transparency, personal accountability and collective learning is encouraged.

• Known vulnerabilities are addressed, information assets are security hardened and the principle of least privilege is applied.

• Avoidance of unnecessary complexity in the design, integration and management of information assets is supported.

• Information Security controls demonstrate a clear and tangible correlation to one or more specific security services that they will serve.



None

References • Abu Dhabi Information Security Risk Management Guide

• OGC Management of Risk (M_o_R)

• NIST Special Publication 800-53 o PM-9 Risk Management Strategyo RA-1 Risk Assessment Policy and Procedureso RA-2 Security Categorization

• NIST Special Publication 800-37 ‘Guide for Applying the Risk Management Framework to Federal Information Systems’

MMM


RM.2 Risk Identification Version 1.0Suggested Priority

P1

Control Standards

The Entity shall identify a range of risks that have a potential bearing upon the security of its information assets.


Control Specification L M HRM.2.1 Before attempting to undertake a risk

identification exercise, the Entity should first define the intended scope for that activity.

In order to work within a defined and manageable boundary, the risk identification exercise should have a clear definition of which information asset, cluster of assets or supporting environment will be looked at for their potential to manifest risk.

The scope for the risk identification exercise should be confirmed within the Entity’s Information Security Risk Management Plan.

RM.2.2 The Entity should ensure that a sufficiently broad constituency of stakeholders is consulted in order to identify potential risks that may adversely affect the information asset(s) being reviewed.

Stakeholders should be capable of providing a range of informed perspectives on risk. (For example, asking five different representatives of the IT function – but no business representatives – may provide too narrow a perspective on potential risk). The Information Owner should be considered as a primary stakeholder from whom potential risks are solicited, given the potential of those risks to impact upon their business process.

Other stakeholders with relevant insights regarding potential risks should also be consulted, e.g. third-party suppliers.

a a

MMM

MMM

71


Risk identification should include input from one or more parties with direct, practitioner-level experience of potential risks within the given sphere of concern. Without such there is the risk that Risk Management interventions will be incorrectly calibrated, i.e. focusing only on superficial areas, or upon risk types that are not of most critical relevance to the Entity and its real-world risk profile.

RM.2.3 Risks will be composed of two foundational elements:

1) Threats – the potential for harm that could be manifested in many environments.Example: data theft achieved via malware.

2) Vulnerabilities – a weakness, or weaknesses, specific to the given environment that would allow a specified threat to be realised.Example: anti-virus signatures are not being updated regularly within this specific organisation.

When identifying risks, the Entity should seek to confirm:

i. Does the threat category have applicability in the first place? (For example, destruction of data processing facilities by tornadoes may be a realistic threat in Kansas, but not in Abu Dhabi).

ii. If the threat type does have applicability, is there a known vulnerability, or a suspected vulnerability, that could cause the threat to be realised? (For example, no preventive or detective security controls relevant to the given threat have yet been deployed by the Entity).

MMM

MMM


Control Specification L M HRM.2.4 The Entity may wish to consider a range of

techniques in the identification of risks e.g.:

• One-to-one Interviews

• Questionnaires

• Workshops attended by multiple stakeholders

• Reference to third-party threat databases

• Use of vulnerability scanning tools

RM.2.5 The Entity should define threats in the context of the security service type that they can potentially impair e.g. ‘there is a threat to data integrity at rest’.

RM.2.6 The Entity should endeavour to identity a spectrum of risks that may have a meaningful potential to undermine or impair the required security of its information assets.

It should not be assumed that only technology-related risks can impact upon Information Security. Other relevant risk sources may include, but may not be limited to:

• Organisation objectives and leadership

• Governance mechanisms

• The degree of organisational change

• The level of supply chain maturity

• Limitations of current products and services

• Skills, training and competencies within the organisation

• Organisational culture

• Process definition and working practices

Risk identification should seek to clarify the potential for risk arising from a variety of sources.

SSS

RRR

RRR

73

Control Specification L M HRM.2.7 Any effort to scan the organisation for potential

Information Security-related risks should also take the opportunity to scan for opportunities too. During the identification exercise, examples of good practice could be uncovered that may have a broader potential applicability, beyond where they are currently in evidence (e.g. team A’s more robust access control procedures could be leveraged by team B). By identifying such opportunities, there is the potential to reduce the organisation’s overall risk footprint.

RM.2.8 It may not be realistic for the Entity to analyse all Information Security risks that it identifies. Consequently, the identified risks should be filtered before substantive analysis is attempted. Only those risks exhibiting a credible threat and a substantial (actual or potential) vulnerability should be taken forward for fuller risk analysis.

RM.2.9 Once identified risks have been filtered, risk owners and risk custodians should be confirmed, ahead of substantive risk analysis being under-taken. The respective roles are defined as follows:

Risk Owner – the individual with ultimate responsibility for ensuring an appropriate response is provided to the given risk. This will often be either the Information Owner or the Information System Owner (e.g. a representative of a business unit).

Risk Custodian – the individual or group responsible for applying a risk response on behalf of the risk owner (e.g. a member of the IT function).

SSS

MMM

MMM




None



• NIST Special Publication 800-53 o RA-5 Vulnerability Scanning

75

RM.3 Risk Analysis Version 2.0Suggested Priority

P1

Control Standards

The Entity shall analyse risks related to the security of its information assets to determine the criticality and priority of those risks for attention.


Control Specification L M HRM.3.1 In analysing its Information Security risks,

the Entity should apply one of the risk ratings described in the Abu Dhabi Information Security Risk Management Guide.

RM.3.2 Risks with the highest analysed scores should be prioritised for risk response and treatment (see RM.4 Risk Response and Treatment).

RM.3.3 For identified risks that have been filtered in the manner described in Control Standard RM.2 Risk Identification, the Entity should maintain a risk register that is conformant with the data fields described within the Abu Dhabi Information Security Risk Management Guide.

RM.3.4 The Entity should undertake qualitative analysis of filtered risks that it identified under the direction of Control Standard RM.2 Risk Identification. Qualitative analysis will seek to apply one or more subjective evaluations in coming up with scorings against each of the following attributes.

Probability – How likely is it that the risk will be manifested?

Impact – What will the consequences be if the risk is manifested?

a a

MMM

MMM

MMM

MMM



Proximity – If the risk were to be manifested, when would this be likely to occur?

The Entity should aim to describe the potential impact in both descriptive and, where possible, financial terms. Description in financial terms will greatly assist the determination of cost vs. benefit of control application (see RM.4 Risk Response and Treatment)

Proximity will be a determinant in prioritising risk response. For example, if the risk is of high probability and high impact but it won’t be manifested for another three years then the risk response can potentially be deferred until a later time.

Risk analysis should lead to the risk being awarded a risk scoring aligned to those provided within the Abu Dhabi Information Security Risk Management Guide. The scoring should be used to prioritise the allocation of finite time and resources within the subsequent phases of the Risk Management process.

RM.3.5 The Entity should refrain from undertaking quantitative analysis of Information Security risks (i.e. running statistical, multi-pass models of probability, impact and proximity) unless it has the skills, tools and business need to do so. In most cases, qualitative risk analysis will be adequate for analysing Entity Information Security risks.

SSS

MMM

77

Control Specification L M HRM.3.6 In analysing risks, the Entity should recognise

that a given vulnerability may have a different impact depending on where it might be manifested. The environment in which the risk could be manifested will be relevant to its evaluation. (For example, the same vulnerability may have greater potential impact if present on a boundary firewall than it would if it were present on an infrastructure element far back in the Entity’s core network).



None



• NIST Special Publication 800-53 o RA-3 Risk Assessment

RRR


RM.4 Risk Response and Treatment Version 2.0Suggested Priority

P1

Control Standards

The Entity shall appropriately address Information Security risks, providing a response appropriate to their analysed attributes.


Control Specification L M HRM.4.1 For prioritised risks it analysed under the direction

of Control Standard RM.3 Risk Analysis, the Entity should apply a risk response. The primary risk responses available being:

Acceptance – the Entity may choose to accept the risk and not apply a control. This is a legitimate risk response approach so long as:

• Doing so would not contradict or subvert any mandatory obligations imposed by these Standards, other regulations or the laws of theUAE.

• The acceptance is made by the Risk Owner and they have done so on the basis of being sufficiently informed about the potential outcome.

• The Risk Owner’s acceptance of the risk is overt and formally documented. Acceptance should imply a willingness on the part of the risk owner to accept any consequences, in the event that the risk is manifested.

Mitigation – the Entity would apply one more detective and/or corrective controls, with the aim to lessen the risk’s impact, should it be manifested.

a a

MMM

79


Avoidance – the Entity may aim to avoid the risk by either a) eradicating the cause of the risk or b) applying preventive controls, to limit the potential for the risk to occur.

Transfer – the Entity may seek to transfer the risk to a third-party. However, it should be clear whether it is transferring risk ownership (and the attendant impact) or just risk custodianship. For example, outsourcing a data centre to a third-party does not transfer the business risk of there being a loss of data. The Entity’s contract with the third-party might provide legal redress for such an outcome but the impact may still be felt within the Entity.

In the majority of cases, a third-party supplier will be a risk custodian but risk ownership will remain with the Entity. (See RM.2 Risk Identification for the definition of these terms).

The risk response type preferred for a given risk and the date on which the risk owner decided upon it should be recorded within the risk register.

RM.4.2 Where the Entity aims to mitigate or avoid a risk, one or more controls will need to be applied in order to provide the required risk treatment.

The Design, Development and Testing section of these Standards should be followed in order to develop and deploy controls.

MMM

MMM


Control Specification L M HRM.4.2(Cont)

For a control developed in order to address a risk, it should be possible for the Entity to confirm:

• How will the control specifically achieve the desired risk response?

• Is the analysed impact of the risk of such a magnitude that compensating/secondary controls are necessary, in case the primary control fails, or is otherwise compromised?

• Is the cost of implementing the control the same as or greater than the potential financial impact if it were to be manifested? If it is then the business justification for applying the control should be evaluated by the Entity’s Information Security Governance Committee.



None



MMM

81

RM.5 Risk Monitoring and Corrective Action


P1

Control Standards

The Entity shall monitor the effectiveness of responses applied to Information Security risks; and identify new or changing risks applicable to its information assets.


Control Specification L M HRM.5.1 Following the application of a risk response, the

Entity should monitor the effectiveness of that response.

Its monitoring should have a particular focus on whether:

• The control continues to function in the manner designed.

• The control continues to effectively support the avoidance or mitigation of the risk.

• The deployment of the control has not caused the introduction of ‘secondary’ risks i.e. those that arise as a consequence of the control being implemented. (If this has occurred then that secondary risk would need to be subject to its own risk analysis and potential treatment).

• Any ‘residual’ risk that remains after the control has been applied i.e. elements of the original vulnerability that remain unaddressed. (If such does persist then the Entity may need to consider reworking the control or adding additional controls – depending on the potential impact of the residual risk).

Where control deficiencies are found, corrective action should be applied at a priority appropriate to the assessed scoring of the risk (see RM.2 Risk Analysis in this section).

a a

MMM


Control Specification L M HRM.5.2 For the purpose of monitoring technical risks,

the Entity may wish to consider deploying automated vulnerability scanning tools (see OM.7 Technical Vulnerability and Patch Management within these Standards).

RM.5.3 The Entity should not assume that the risks applicable to an information asset will remain static and unchanging throughout its lifecycle. Original risks may change in nature, new risks may present themselves and old risks may cease to be of concern. Potential triggers for such may include (but not be limited to) to:

• Modification of the information classification

• Adjustments in the profile of the asset’s usage or management

• Change in the physical and or logical location of the asset

• Modification of the asset’s configuration

• Adjustments in the supply chain related to the asset

• Reconfiguration of the organisation’s design

• Changes in external obligations (e.g. regulations and laws)

Provision should be made for regularly analysing the risk profile of the information asset to determine if it has changed, or is likely to change. In such an eventually, the Entity should determine whether the number, type and specification of controls remains appropriate to the revised risk profile.

MMM

SSS

83


The Entity should ensure that its Change Management process is mandated to consider the potential for new or changing risk when changes to information assets are proposed, built, tested or implemented. Reporting between the Change Management process and the Risk Management process should be aligned to ensure both disciplines are fed with relevant and timely data.

RM.5.4 The Entity should evaluate all security incidents – but particularly Priority 1 and Priority 2 incidents – for their risk context. The Security Incident Management process (see the Information Security Incident Management section of these Standards) should be able to provide the necessary base data for risk monitoring activities to take place.

Risk monitoring in relation to incident investigation should seek to address the following questions:

• Was this incident avoidable?

• Did the incident occur because one or more risks were not identified at the appropriate time?

• Did the incident occur because one or more risks were incorrectly analysed? (E.g. the decision was made to accept the risk rather than treat it).

• Did the incident occur because one or more controls were incorrectly designed and/or applied to treat an analysed risk?

MMM

RRR



The Entity’s Information Security Governance Committee should promote the notion that risks and incidents have a causal relationship. In other words, the Committee should promote the understanding that security incidents are not an inevitable by-product of day-to-day operations but are, instead, caused by incorrectly processed risks. The Committee should take the opportunity to promote this correlation with the aim of improving understanding of the Entity’s risk profile and to enhance its future risk identification, analysis and treatment interventions.

RM.5.5 As a consequence of learning derived from security incidents and changes that have occurred to the risk profile of the information asset, the Information Security Risk Management Plan should be updated accordingly.



None



• NIST Special Publication 800-53 o RA-5 Vulnerability Scanning

MMM

RRR

85

12.3 Human Resources Security

HR.1 Information Security Roles and Responsibilities


P1

Control Standards

The Entity shall identify Information Security responsibilities applicable to employees and address them in the job descriptions, and terms and conditions of employment.


Control Specification L M HHR.1.1 Information Security responsibilities should be

defined prior to employment. For roles that have substantial involvement with the Information Security programme and/or involve the handling of data at classification ‘Confidential’ or above, specific security-related responsibilities should be defined within job descriptions and in the terms and conditions of employment. Those terms and conditions should include the employee’s obligations to observe non-disclosure provisions relevant to their access to the government’s information security assets.

HR.1.2 The Entity should assign a risk designation to all positions, and should establish screening criteria for the individuals filling those positions. The Entity should review and revise the risk designations at an Entity-defined frequency.



HR.4 – Segregation of Duties

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 8.1 Prior to employmento 8.1.1 Roles and responsibilitieso 8.2.1 Management responsibilities

• NIST Special Publication 800-53 Revision 3: o PS-2 Position Categorization

a

MMM

MMM


HR.2 Security Screening Version 2.0Suggested Priority

P1

Control Standards

The Entity shall screen all employees prior to and during their employment.


Control Specification L M HHR.2.1 All candidates for employment and existing

employees, should be screened (and as required, re-screened) by appropriate authorities, with priority being given to roles that involve the handling of data at classification ‘Confidential’ or above.

HR.2.2 The Entity should carry out background checks with regards to the accuracy of statements concerning job history and the validity of formal educational and professional qualifications.



None

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 8.1 Prior to employmento 8.1.2 Screening

• NIST Special Publication 800-53 Revision 3: o PS-3 Personnel Screening

a a

MMM

MMM

87

HR.3 Terms and Conditions of Employment


P1

Control Standards

The Entity shall establish terms and conditions of employment for all employees.


Control Specification L M HHR.3.1 Employees should sign terms and conditions

of employment that include an outline of their Information Security roles and responsibilities. The level to which these roles and responsibili-ties will need to be detailed will depend upon:

• the level of privileged information access position requires

• the risks associated with the information access

• the level of involvement the post-holder will have in the design and implementation of the Information Security process

Terms and conditions should seek to ensure that conflicts of interest do not arise and must be reported where they are suspected.

HR.3.2 The Entity should establish and make readily available to all information system users a set of acceptable usage rules that describe their responsibilities and expected behaviours and acceptable usage with regard to information system usage.

The Entity should receive signed acknowledge-ments from users indicating that they have read, understood, and agree to abide by these rules of acceptable usage, before authorising their access to the given information system. The completed acknowledgement should be retained on file by the Information Owner or Information System Owner.

a

MMM

MMM


Control Specification L M HHR.3.3 The organisation should apply different sets

of information service and information system rules based on user roles and responsibilities. (For example, differentiating between the rules that apply to privileged users and rules that apply to general users).



None

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 8.1.3 Terms and conditions of employment

• NIST Special Publication 800-53 Revision 3:o PL-4 Rules Of Behavior

RSS

89

HR.4 Segregation of Duties Version 2.0Suggested Priority

P1

Control Standards

Duties and areas of responsibility shall be segregated by the Entity to reduce opportunities for unauthorised or unintentional modification or misuse of the organisation’s information assets.


Control Specification L M HHR.4.1 The Entity should carefully consider the

appropriateness of a single individual per-forming multiple critical roles. The Entity should undertake organisational and work design in manner that provides for appropriate separation of duties. Duties should be separated to avoid potential abuse of position, conflicts of interest or collusion between parties, with the possible outcome of information assets being compromised.

Where such a clustering of critical roles in a single position may be unavoidable (e.g. limited resource availability requires one individual to fill multiple roles) compensating controls should be deployed to limit risk. Compensating controls may include (but not be limited to): monitoring of activities, audit trails and an increased level of management supervision.

HR.4.2 When designing information systems the Entity should ensure that no single person can access, modify or use assets without authorisation or detection.

a

MMM

MMM


Control Specification L M HHR.4.3 When designing for separation of duties, the

Entity should seek to weigh the benefit of such segregation against the potential impact of not having staff trained across multiple disciplines. (For example, too much segregation may mean that a service is not administered effectively during times when the individual is on leave, on training etc.) The Entity should evaluate the risk applicable to both scenarios. Highly segmented roles, undertaken by only one individual, may impact upon the availability of the information service due to necessary support coverage not being available.



None

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.1.3 Segregation of duties

• NIST Special Publication 800-53 Revision 3:o AC-5 Separation Of Duties

MRS

91

HR.5 Disciplinary Process Version 2.0Suggested Priority

P2

Control Standards

The Entity shall establish a disciplinary process for handling violations of Information Security policy and procedures.


Control Specification L M HHR.5.1 The Entity should employ a formal sanctions

process for personnel failing to comply with approved Information Security policies and procedures. The sanctions process should be consistent with applicable Government laws, directives, policies, regulations, standards, and guidance, and may be included as part of the general personnel policies and procedures for the Entity.

HR.5.2 The disciplinary process should be invoked fairly, consistently and on the basis of reliable evidence.

HR.5.3 Disciplinary actions should be handled with sensitivity as regards the potential for information leakage. Only those parties with a confirmed need to know should be involved with the disciplinary process.

HR.5.4 Opportunity should be taken to identify lessons learned when conducting security-related disciplinary action. This may include the proposing of new or revised preventive and detective controls that would limit the possibility of such action occurring again in future, or lessening its potential impact.

a

MMM

MMM

MMM

RRR




None

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 8.2.3 Disciplinary process

• NIST Special Publication 800-53 Revision 3:o PS-8 Personnel Sanctions

93

HR.6 End of Employment Security Version 2.0Suggested Priority

P2

Control Standards

The Entity shall assign responsibilities within the involved departments (e.g. Human Resources, IT Department) to ensure that employment termination is managed in a secure manner.


Control Specification L M HHR.6.1 An inventory of relevant equipment and access

granted to the employee/contractor should be maintained to aid transaction of the termination process.

HR.6.2 An exit interview should be conducted, where assigned equipment, access control cards, keys and access tokens are recovered from the employee/contractor.

Employees should be obligated to notify the exit interviewer of any Entity-owned equipment or information assets not on the inventory that are in their possession.

A record of the exit interview should be retained by the Entity. This should confirm:

• Which parties were in attendance

• The date and time that the interview was held

• Which items were confirmed, by reference to the inventory, as being in the employee/contractor’s possession

• Which additional Entity-owned items the employee/contractor confirmed as being in their possession

a a

MMM

MMM


Control Specification L M HHR.6.2(Cont)

• The status of the items identified (i.e. return or not returned)

• The signature of the employee and the Entity representative conducting that interview that the record is complete and accurate

The record should not be finalised until such time as all listed items have been returned to the Entity.

HR.6.3 Access to information systems should be revoked no later than the formal contract termination point. In exceptional circumstances (e.g. where the individual’s employment has been terminated by the Entity for cause) access should be revoked immediately upon implementation of the termination. The terminating party should notify the IT department of the need to undertake such activity without delay. Under such circumstances account revocation should take priority over day-to-day access and account management activities.

HR.6.4 Accounts relating to terminated employees/contractors should be suspended immediately at the end of employment/engagement period. The account should be retained for an Entity-defined period of time in case there is the need to subsequently access data held within it.

In the event that legacy data would need to be accessed after the termination (e.g. electronic mail archives), steps should be taken to migrate the data to active information repositories for future reference. Accounts relating to terminated employees/contractors should not, as a matter of general practice, be used by other parties, after the termination.

MMM

MMM

MMM

95

Control Specification L M HHR.6.4(Cont)

At the end of the Entity-defined retention period, the account should be purged from the information system. There may be exceptional circumstances (e.g. evidential requirements relating to a criminal investigation) where an account will need to be retained for a period in excess of the standard retention period.



None

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 8.3.1 Termination responsibilities

• NIST Special Publication 800-53 Revision 3:o PS-4 Personnel Termination

MMM


12.4 Third Party Supplier Security

TP.1 Security-Oriented Supplier Selection


P2

Control Standards

The Entity shall ensure that its Information Security requirements and obligations are reflected in its engagement of third-party suppliers.


Control Specification L M HTP.1.1 The Entity should ensure that Information

Security-related requirements applicable to third-party products and services are fully captured and communicated in Requests For Proposal (RFPs) and Requests For Quotation (RFQs).

The requirements should:

• Be clearly identifiable as being Information Security-related

• Carry a unique identifier, per requirement

• Be directly traceable back to original requirements defined within the Service Design or Information Security Design

TP.1.2 RFPs and RFQs that contain information describing either the current Information Security capabilities of the Entity, or its future Information Security requirements, should not be released without the receiving party first committing their organisation, employees and any relevant sub-contractors to an Entity-provided Non-Disclosure Agreement.

a a

MMM

MMM

97

Control Specification L M HTP.1.3 The Entity should ensure that supplier responses

to RFPs and RFQs confirm the specific, tangible control(s) that will be put in place by the supplier to address a given Information Security requirement. (It should be readily possible to correlate the proposed control or controls to the uniquely identified requirement).

TP.1.4 The Entity should define weighting and evaluation criteria for reviewing supplier proposals that take sufficient account of Information Security-related requirements. The Entity should specify within its procurement procedures the specific percentage weighting that will be applied to Information Security in its evaluation of suppliers. The weighting should show a correlation to the classification of the information assets to which the service or product offering relates.

TP.1.5 When evaluating a supplier’s capability to provide secure products and/or services, the Entity should:

• Take into consideration past performance of the supplier (e.g. involvement with previous Information Security-related incidents).

• Solicit Information Security-oriented references from other clients of the supplier.

• Review media sources for public domain insights regarding the supplier’s strengths and weaknesses in the area of Information Security.

MMM

RRR

RRR


Control Specification L M HTP.1.6 Where evaluation of a prospective supplier

highlights serious Information Security-related concerns, the Entity should not proceed with contract award unless and until the supplier has adequately addressed those concerns in a specific and verified manner; and has provided an acceptable account of why those concerns arose in the first place.

TP.1.7 The Entity should consider pre-qualifying suppliers/supplier facilities capable of handling, transmitting or storing information of certain classifications.

Such suppliers may be entered into a Preferred Supplier List for products or services relating to data of a given classification level.

TP.1.8 With specific reference to the hosting of information systems, the Entity should ensure that government information classified as ‘Restricted’ or above is not hosted outside of an Abu Dhabi government data centre. If, exceptional circumstances require a consideration of other hosting alternatives, a business case should be presented to ADSIC.



None

References • Abu Dhabi Information Security Third Party Supplier Guide

MMM

RRR

SSS

99

TP.2 Security-Oriented Contract Definition


P2

Control Standards

The Entity shall ensure that third-party supplier commitments and obligations to Information Security are supported by robust contractual definition.


Control Specification L M HTP.2.1 The Entity should ensure that supplier

commitments to, and assertions about, Information Security control implementation and management – made via RFP/RFQ – are carried forward into relevant security-oriented contract schedules with the selected supplier.

TP.2.2 The Entity should consider including within its third party supplier contracts behaviour-shaping penalties that will apply in the event of security-related controls:

• Not being implemented at all

• Not being implemented as per agreed specifications

• Being found to be deficient

The impact of such penalties should be greater than the cost of implementing and maintaining the given control, so as to ensure compliance with contractual commitments.

TP.2.3 The Entity’s contract with a supplier should require the supplier to proactively give notification of any material weakness or vulnerability that may give rise to a potential an Information Security incident in relation to the Entity’s information assets. Such a weaknesses may possibly stem from any of the following supplier elements:

• Processes

• Personnel

aa

MMM

RRR

SSS


Control Specification L M HTP.2.3(Cont.)

• Relationships with sub-contractors

• Technology

• Business culture

• Premises

TP.2.4 The Entity’s contract with a third party supplier should ensure that the Entity retains the right to audit the Information Security controls that the supplier has committed to maintaining.

TP.2.5 Entity contracts with third-party suppliers should require the supplier to actively avoid conflicts of interest and to ensure appropriate access restrictions within their organisation, to avoid Entity information assets being compromised. This requirement will have specific applicability to consultancies and outsourcers, working with multiple client organisations on the same engagement type, or working with the same Entity on different types of engagement.

TP.2.6 Contracts with third-party suppliers of software and hardware should require the supplier to warrant that their product is free of errors and known vulnerabilities. The Entity should require the supplier to demonstrate that relevant security-oriented testing has been undertaken on the hardware or software in question.



None


MRR

RRR

RRR

RRR

101

TP.3 Security Monitoring and Review of Third Party Services


P2

Control Standards

The Entity shall ensure that third-party suppliers are managed in accordance with Information Security requirements and associated contracts.


Control Specification L M HTP.3.1 The Entity should put in place monitoring and

performance review mechanisms to verify that third-party products and services are being delivered in a manner consistent with agreed Information Security-related contract schedules.

TP.3.2 The Entity should ensure that supplier personnel with access to Entity information assets and information systems should satisfy the control standards defined within the Human Resource Security section of these Standards. Specifically those relating to:

• Background screening

• Previous employment verification

• Educational/professional qualifications and competency verification

• Non-disclosure of Entity information

The necessary verification may be undertaken by the Entity itself. Alternatively, the Entity may require the supplier to undertake such activities and to confirm the results in a timely manner to the Entity.

TP.3.3 With specific reference to IT, telecoms and business process outsourcers, the Entity should require the service provider to:

• Provide regular (e.g. monthly) reports confirming activity and performance against agreed Key Security Indicators (KSIs).

a

MMM

MMM

RRR


Control Specification L M HTP.3.3(Cont.)

• Regularly submit a self-assessment of the status of the Information Security controls in place to protect Entity information assets. The self-assessment should be provided on a six monthly basis, or more frequently in the event of a) major change to the agreed services supported by the outsourcer and b) major business or organisational changes within the outsourcer that may have a bearing upon its delivery of service to the Entity.

• Require the service provider to proactively notify the Entity in the event of the outsourcer becoming aware of any vulnerability that could materially affect the security of Entity information assets.

TP.3.4 The Entity should undertake structured assess-ment of the outsource providers’ Information Security capabilities on a regular (i.e. at least annual) basis. The assessment should take as input:

• The service provider’s Key Security Indicator reporting data.

• Any security incidents relating to Entity information assets that the outsourcer was involved in.

• The service provider’s self-assessment submissions.

The Entity should undertake this assessment itself and not merely reply on the supplier’s own self-assessment. The findings from the assessment should be reviewed by the Entity’s Information Security Governance Committee.



None


RRR

RRS

103

TP.4 Security-Oriented Contract Termination and Renegotiation


P3

Control Standards

The Entity shall consider Information Security needs when terminating or renegotiating third party supplier contracts.


TP.4.1 In the event of a major or repeated breach of Information Security-related contractual clauses, the Entity should consider termination of its contractual relationship with a third-party supplier.

TP.4.2 The Entity should consider the effectiveness of a supplier’s Information Security capabilities and control maturity when considering the re-awarding/extension of a product or service supply contract. Where those capabilities are found to be deficient, the Entity should either:

a) Require a tangible and timetabled corrective action plan from the supplier that will address the shortcomings in advance of the contract being re-awarded or

b) Initiate a new procurement exercise to replace the incumbent supplier.

TP.4.3 The Entity should ensure that its information assets are returned or destroyed (as appropriate) by the supplier, at the end of the contractual period. Destruction may include purging of information systems and digital media, as well as destruction of paper outputs.



None


aa

RRR

RRR

RRR


12.5 Information Security Training, Awareness & Communication

TA.1 Security Induction Version 1.0Suggested Priority

P2

Control Standards

The Entity shall implement a formal Information Security induction process designed to introduce the organisation’s security expectations.


Control Specification L M HTA.1.1 The Entity should arrange for all users of

information assets and information systems to be inducted into the Information Security process. Induction should be relevant to the level and scope of information access that the individual will be granted.

For information creators and substantive users of information assets, induction should include (but not be limited to) introducing:

• The Abu Dhabi Information Security Programme.

• The role and benefit of these Standards.

• The commitment of the Entity’s executive management to effective Information Security.

• The Abu Dhabi Information Classification framework.

• The purpose of the Entity’s Information Security Policy and supporting documentation.

a

MMM

105

Control Specification L M HTA.1.1(Cont.)

• Key roles and responsibilities for Information Security within the Entity, with contact information provided for relevant post-holders.

• The terms of acceptable usage of information systems.

• The mechanism for reporting Information Security vulnerabilities and incidents.

• The portfolio of Information Security-related training available to the inductee.

• Key user responsibilities (e.g. password protection, destruction of paper waste).

TA.1.2 Information Security induction should be provided prior to access being granted to information systems.

TA.1.3 The Entity should ensure that records are kept as to which individuals have attended security induction, when this occurred and whether any information systems access was granted prior to attending induction.



None

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 8.2.2 Information Security awareness, education, and

training

MMM

MMR

MMM


TA.2 General Awareness MessageDelivery


P1

Control Standards

The Entity shall deliver general Information Security awareness training to all information users.


Control Specification L M HTA.2.1 The Entity shall complement its security induction

activities with regularly (i.e. at least annually) provided general security awareness training for all information users. This training should reinforce the need for vigilance concerning common security threats and make users aware of emerging threats.

TA.2.2 General awareness training should additionally make users aware of any changes to the definition of the Information Security process, Information Security policy and the Entity’s Information Security organisation that have relevance to their information usage.



None

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements: o 5.2.2 Training, awareness and competence

• NIST Special Publication 800-53 Revision 3: o AT-2 Security Awareness

a

MMM

MMM

107

TA.3 Tailored Awareness Security Training


P2

Control Standards

The Entity shall provide role-based security-related training that fits Entity needs.


Control Specification L M HTA.3.1 All personnel with defined responsibilities in the

usage and/or management of information assets should be provided with security training tailored to their role type.

TA.3.2 Tailored training should be repeated at an Entity-defined interval to ensure that role-holders remain aware of their security responsibilities.

TA.3.3 Role-based security-related training should be provided before access to a relevant information system is granted and before the role-holder performs assigned duties.



None


• NIST Special Publication 800-53 Revision 3: o AT-3 Security Training

a

MMM

RRR

RRR


TA.4 Security Training Development and Delivery


P1

Control Standards

The Entity shall oversee the development and delivery of Information Security training to ensure achievement of agreed learning objectives.


Control Specification L M HTA.4.1 The Entity should determine in advance the

learning outcomes and required capabilities applicable to information users and other stakeholders within its Information Security programme.

TA.4.2 The Entity should structure Information Security training curricula to directly address the learning outcomes identified.

TA.4.3 Training curricula should be tailored to the specific needs, interests and responsibilities of defined categories of stakeholders within the Information Security programme e.g.:

• Information users

• Information Owners

• Control providers

• Information Security Governance Committee members

TA.4.4 For training to be delivered in-house, the Entity should develop distinct security training modules that directly address the agreed curricula. The modules (including presentation materials, hand-outs, quizzes etc.) should follow the defined curricula and achieve the defined learning outcomes.

a a

MMM

MMM

MMM

MMM

109

Control Specification L M HTA.4.5 The Entity’s Information Security Governance

Committee should verify that Information Security training is being delivered in a manner consistent with the training section of the Information Security Programme Plan. The verification should seek to confirm:

• Is training being delivered with sufficient frequency?

• Are defined learning outcomes being achieved?

• Are requisite levels of verifiable competence being demonstrated at the end of training?

• Are suggestions for improvement being solicited from training attendees?

• Are training curricula being updated in light of: attendee feedback, lessons learned from security incidents and changing trends in security threats and vulnerabilities?

• Has any information systems or facilities access or permissions been granted without requisite training having been provided?

Verification should apply whether the training is delivered in-house or via a third-party provider.

TA.4.6 The Entity should keep detailed training records for each employee and non-employee with access to its information systems. The records should confirm:

• What security training was attended, when and where

• What curriculum and version of that curriculum was covered

MMM

MMM


Control Specification L M HTA.4.6(Cont.)

• Who the trainer was

• Quiz and/or test results

• Attendee confirmation of their attendance

• Recommendations for further training

TA.4.7 The Entity should determine the frequency at which security training should be repeated, in order to ensure that the knowledge and awareness of stakeholders remains active and current.



• SG.1 – Security Programme Plan

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements: o 5.2.2 Training, awareness and competence: I

• NIST Special Publication 800-53 Revision 3: o AT-1 Security Awareness and Training Policy

and Procedureso AT-3 Security Trainingo AT-4 Security Training Records

MMM

MMM

111

TA.5 Contact With Special InterestGroups


P3

Control Standards

The Entity shall require its Information Security personnel to solicit relationships and establish contacts with relevant external forums and professional associations.


Control Specification L M HTA.5.1 The Entity should establish and institutionalise

contact with selected groups and associations within the Information Security community. This being with the view to:

• Facilitating on-going security education and training for Entity personnel.

• Staying up-to-date with the latest recom-mended security practices, techniques, and technologies.

• Sharing current security-related information including threats, vulnerabilities, and incidents.

• Staying up-to-date with applicable laws, directives, policies, regulations, standards and guidance.



None

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements: o 6.1.7 Contact with special interest groups

• NIST Special Publication 800-53 Revision 3: o AT-5 Contacts with Security Groups and Associations

a

SSS


TA.6 Information Security Communications


P2

Control Standards

The Entity shall determine, and plan for, the communication requirements of Information Security stakeholders.


Control Specification L M HTA.6.1 The Entity should develop a communications

approach as part of its Information Security Programme Plan. Communications planning should complement the Entity’s security training activities.

TA.6.2 Information Security communications planning should confirm:

• Key stakeholder audiences and their anticipated communication needs.

• Key messages to be communicated to those audiences.

• Channels for communication (e.g. intranet, newsletter).

• Anticipated frequency of communication (e.g. monthly, quarterly, annually).

TA.6.3 The Entity should develop and release Information Security-related communications deliverables in a manner consistent with its Information Security Programme Plan.

a

RRR

RRR

RRR

113

Control Specification L M HTA.6.4 The Entity’s Information Security Governance

Committee should monitor the effectiveness of communications-related initiatives and deliverables to ensure on-going awareness of the Information Security programme’s objectives and key activities.



None


RRR


12.6 Information Asset Management

AM.1 Inventory of Information Assets Version 1.0Suggested Priority

P2

Control Standards

The Entity shall maintain a current, documented inventory of assets.


Control Specification L M HAM.1.1 The Entity’s information asset inventory should

record the minimum mandatory data for each of its principle information assets:

• Name of the information asset

• Business purpose of the information

• Principle user group(s) of the information and their access levels (e.g. Read, Write, Executive, Modify, Delete)

• Definitive location of the information (e.g. which information system holds the primary copy of the data)

• Other locations of the information (e.g. off-site data stores)

• Name of the Information Owner

• Relationship with and dependency upon other information assets

• Classification label of the information

• Current stage within the information lifecycle (see AM.5 – Information Management and Retention)

• Date of next review of the asset inventory’s accuracy and completeness.

For the purpose of inventory tracking, information assets may include both information types and information systems.

AM.1.2 Changes to the information asset inventory should be managed in accordance with the Entity’s Change Management process.

a a

MMM

MMM

115

Control Specification L M HAM.1.3 The Entity should consider rendering its

information asset inventory in a database that enables:

• Reporting on asset status

• Relationships definition between information assets

AM.1.4 The Entity should consider implementing automated configura-tion auditing tooling that allows for prompt confirmation of significant deviations between the actual information estate and the associated records within the inventory.

AM.1.5 On a regular basis (at least every six months) the Entity should audit its information asset estate to ensure that the data contained within its inventory remains accurate and current.

AM.1.6 The Entity should consider complementing its information asset inventory with a Configuration Management Database (CMDB). The CMDB may define the configuration parameters for its information systems. The Entity may wish to consolidate its information asset inventory and CMDB in a single data repository.



AM.5 – Information Management and Retention

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 7.1.1 Inventory of assets

• NIST Special Publication 800-53 Revision 3:o CM-8 Information System Component Inventory


MMR

RRS

SSS

SSS


AM.2 Information Asset Ownership Version 2.0Suggested Priority

P1

Control Standards

The Entity shall assign owners to all of its information assets.


Control Specification L M HAM.2.1 Information Owners should be defined for all

information assets, with their responsibilities documented and accepted by them. Information Owners should be senior representatives of the Entity departments with the primary responsibility for a given information asset. The Information Owner should retain ultimate accountability for the protection of an information asset, whether or not certain responsibilities have been delegated to other parties.

AM.2.2 Information Owner responsibilities should include:

• Approving access to the information asset. (Depending on the circumstance this approval may be on a per-request basis or a more general approval for a certain level of usage e.g. ‘all members of Department A are approved for write access to this network share’).

• Defining the lifecycle of the information asset, including when it should move to archived status and how long the information should be retained after its active usage.

• Approving and reviewing security measures applied to the information asset.

a

MMM

MMM

117

Control Specification L M HAM.2.2(Cont.)

• Ensuring all regulatory and legal obligations applied to the information asset are met.



References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 7.1.2 Ownership of Assets

• NIST Special Publication 800-53 Revision 3:o CM-9 Configuration Management Plan


MMM


AM.3 Classification of Information Assets Version 2.0Suggested Priority

P2

Control Standards

The Entity shall classify information in accordance with Abu Dhabi information classification guidelines.


Control Specification L M HAM.3.1 All Abu Dhabi information assets must be

classified based upon the sensitivity of their potential disclosure.

All Entity information assets should carry one of the following classification labels, as applied by the designated Information Owner:

Public Information specifically intended for dissemi-nation in the public domain. Such information is defined as having no local, national or international restrictions on access and usage. Public information is intended for the general betterment of society, promoting the interests of the country in the public realm, equipping citizens and other stakeholders with necessary information and the helping to promote the country’s vision and values at home and abroad.

RestrictedInformation that must be afforded limited confidentiality protection due its use in the day-to-day operations of government. Disclosure of such information could have limited adverse impact on the functioning or reputation of the government. Such information relates to the internal functioning of government and will not have general relevance and applicability to a wider audience. Although individual items of information are not sensitive, taken in aggregate they may reveal more information than is prudent, if they were to be revealed.

a

MMM

119


ConfidentialInformation that requires robust protection due to its critical support to decision-making within government.

Information that could disclose designs, configurations or vulnerabilities exploitable by those with malicious intent.

Information that the government has a duty of care to others to hold in safe custody (e.g. critical personal information, government financial information etc.).

SecretInformation that requires substantial and multi-level protection due to its highly sensitive nature.

Disclosure of such information could have a serious and sustained impact upon the national security, social cohesion, economic viability and health of the country.

Information disclosure could potentially threaten life or seriously prejudice public order.

Default classification levels are specified for certain main types of information asset (see AM.3.10 – AM.3.11 below). The Entity is at liberty to modify the classification of these information types, as used within its own environment. However, where the Entity intends to use a lower classification level than identified within these Standards, the Information Owner should be able to demonstrate an informed and risk-oriented rationale for why this is appropriate.

MMM


Control Specification L M HAM.3.2 The current, and any previous, classification of

an information asset should be recorded within the Information Asset Inventory. Any changes to a classification level should be approved by the Entity’s Information Security Governance Committee, with an impact assessment on the associated security control requirements being conducted.

AM.3.3 Where the Entity identifies information assets that are potential candidates for designation as ‘Secret’, this should be communicated to ADSIC. Assets confirmed as requiring such a classification will require specific attention, in terms of control definition and security assessment.

AM.3.4 Where the Information Owner has not defined it, and where it is not subject to the application of a default classification level (see AM.3.10 – AM.3.11 below) the information asset’s classification will default to ‘Confidential’ unless and until the Information Owner completes the exercise of classification.

AM.3.5 When seeking to classify its information assets, the Entity should make reference to the Classification Matrix shown in Appendix C of this document. The matrix should be used to validate that the classification level proposed is appropriate to the potential impact. Classification levels should be determined by the value of the information asset and the potential harm were it to be disclosed.

MMM

MMM

MMM

MMM

121


The impact of information being compromised will vary based upon:

• The classification level

• The area of potential impact (e.g. economic, reputation)

Classification levels should not be decided upon based on the resources available for the application of controls. (e.g. a budgetary constraint should not be a trigger for the asset’s classification being downgraded).

AM.3.6 The Information Owners should ensure that classification levels for information assets under their stewardship are reviewed regularly during the information asset’s life (at least annually, or more frequently following major business change).

Information may undergo change during its lifetime. There may be changes to:

• The content of the information

• The use the information is put to

• Who will be accessing the information

• Its location

• Its ownership

• The perceived value of the information

• The legal and regulatory obligations that impact on the information

• The interrelationship between this information and other information

Given such potential for change during the information asset’s lifecycle, the Entity should not consider the classifying of its information assets as a one-time activity that leads to a static and enduring classification level.

MMM

MMM


Control Specification L M HAM.3.7 Where an information asset is proposed for

reclassification during its life, the Information Owner is obligated to undertake an impact analysis ahead of the reclassification taking place. This analysis should seek to establish what Information Security controls should be added, removed or modified in support of the revised classification level.

Proposed changes to the classification level of information assets should be subject to multi-disciplinary analysis and approval via the Entity’s Change Management process.

AM.3.8 The Information Owner should ensure that internal and external stakeholders involved in the creation, usage, storage, transmission, management or disposal of an information asset are made aware of its classification level and the obligations imposed by that classification. Any changes to the classification level should be communicated to the stakeholder group in a timely fashion.

AM.3.9 The classification of an information system or network will be determined by the highest classification of data resident on that information system, or transiting via that network. E.g. a server hosting ‘Public’ and ‘Restricted’ data should itself be designated as ‘Restricted’.

AM.3.10 The following information asset types should be classified by the Entity as being ‘Restricted’ or higher:

• Entity policies and procedures

• Entity performance reports

• Entity daily correspondence, memos and electronic mail

MMM

MMM

MMM

MMM

123

Control Specification L M HAM.3.11 The following information asset types should

be classified by the Entity as being ‘Confidential’ or higher:

• Customer/service user private data

• Entity strategy documentation

• Personnel and payroll records

• Financial records

• Procurement records

• Entity Requests for Proposals and contracts with third-party suppliers

• Information systems architecture, design, test and configuration documentation



AM.1-Inventory of Information AssetsAppendix C – Classification Matrix

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 7.2 Information classification

• NIST Special Publication 800-53 Revision 3:o RA-2 Security Categorization


MMM


AM.4 Information Labelling and Handling Version 2.0Suggested Priority

P2

Control Standards

The Entity shall label and handle information assets based on their information classification.


Control Specification L M HAM.4.1 Entity documentation should carry a multi-

part classification label corresponding to the following format:

Classification Level/Organisation/Role(s)

Examples being as follows:

a) Restricted/DoT and Approved Outsourcers Only/All Grades

b) Confidential/Executive Council and ADTA Only/UAE Nationals Only (Director or Above)

Documentation of classification ‘public’ should carry a label showing this classification level but Organisation and Role(s) do not need to be defined, due to the inherent nature of the data.

AM.4.2 Entity documentation templates should support the application of classification labels via the provision of information classification fields in the cover sheet and header/footer of the template.

AM.4.3 For documentation not generated from Entity templates (e.g. outputs from the Entity’s enterprise resource planning (ERP) system), the information system should automatically apply a watermark showing the relevant classification.

a

MMM

RRR

SSS

125

Control Specification L M HAM.4.4 The Entity should consider applying a colour

coding to classified documents, to provide visual reinforcement of the classification and, consequently, the handling expectations for the material.

Standard colours for expressing classification within the government of Abu Dhabi being:

Red = Secret

Orange = Confidential

Blue = Restricted

Green = Public

Where classification colouring is applied, the above convention should be adhered to, to avoid potential confusion for documentation passing between government Entities.

AM.4.5 The Entity should determine, document and train its personnel in the restrictions that will be applied to the handing of information of a given classification. It should ensure the application of these restrictions via policy, procedures and other security controls.

Examples of possible handling restrictions being:Secret – no access to information outside of the designated office suite. No connection of the information system to any transmission medium other than a secure, closed network.

Confidential – no copying of data from the information system to external media (e.g. USB drive). Only printing to a secure printer, making use of uniquely numbered copies. Printed outputs (other than master copies) shredded after use.

SSS

RRR



Restricted – no transmission of data via public email. Printed outputs (other than master copies) to be shredded after use.



AM.3-Classification of Information Assets

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 7.2.2 Information Labelling and Handling

• NIST Special Publication 800-53 Revision 3:o MP-2 Media Accesso MP-3 Media Markingo AC-16 Security Attributes


RRR

127

AM.5 Information Management and Retention


P3

Control Standards

The Entity shall determine the lifecycle of its information assets and apply appropriate Information Security controls during that lifecycle.


Control Specification L M HAM.5.1 The Entity should determine the anticipated life-

cycle of its information, from production through to destruction. This should be informed by:

• The Entity’s business needs

• Regulatory and legal obligations applicable to its business processes

AM.5.2 The Entity should determine how long information should to be retained, beyond its active usage. Once a retention period has been determined, the Entity should ensure that the information remains accessible during this period (e.g. it is maintained on media that can be read by current information systems).

AM.5.3 The information asset inventory should show information’s current lifecycle stage and the date that this will next be reviewed. The information lifecycle may be distinguished by the following phases:

• Development

• Production

• Archive

• Replaced

• Destroyed

a

MMM

MMM

MMM


Control Specification L M HAM.5.4 The Entity should evaluate how the scope and

depth of Information Security controls will change during the information lifecycle. For example, determining if less stringent controls are necessary once the information is no longer current and is stored within an archive. On-going maintenance of the Information Security Design for the associated information system can ensure that controls are adapted appropriately to the lifecycle stage.

AM.5.5 The Information Owner should approve any change of lifecycle phase and any upgrade or downgrade of Information Security controls on the basis of that transition.



AM.1 Inventory of Information Assets

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 15.1.3 Protection of Organizational Records

• NIST Special Publication 800-53 Revision 3:o AU-11 Audit Record Retentiono MP-1 Media Protection Policy and Procedureso MP-4 Media Storageo SA-5 Information System Documentation


RRR

RRR

129

AM.6 Physical Asset Management Version 1.0Suggested Priority

P2

Control Standards

The Entity shall identify and manage the physical assets used in support of its information assets.


Control Specification L M HAM.6.1 The Entity should develop and maintain a

plan for the management of its information systems and other physical assets (e.g. supporting infrastructure) deployed in support of its information assets. The plan should seek to determine where specific categories of physical assets may be sited, what purpose they will serve and which of these assets can be removed from the specified locations.

AM.6.2 The Entity should implement and maintain an inventory of its physical assets (with a particular focus on information systems and network devices). The inventory should, as a minimum, confirm:

• The asset’s unique asset inventory number

• The category of asset it belongs to (e.g. ‘desktop’, ‘laptop’ ‘printer’ etc.)

• The make and model of the asset

• Its date of purchase

• Its anticipated date of retirement

• The purpose of the asset - what is it intended to do and in relation to what information asset(s)?

• The identity of the information system/asset owner

a a

MMM

MMM



• Its serial number

• The highest classification of information that the asset stores, transmits or otherwise directly interacts with

• The specific location of the asset (i.e. not simply ‘Data Centre’ but also the specific rack position within that data centre)

Changes to the physical asset inventory should be managed under the direction of the Entity’s Change Management process.

AM.6.3 The Entity should consider managing its physical inventory within a configuration management database that confirms:

• The data defined in AM.6.2 above

• The baseline configuration of the asset

• The relationships between physical assets (e.g. ‘is a child of’, ‘is a parent of’, ‘is a sibling of’). Relationship mapping can help assist in undertaking impact analysis when changes to a given asset are proposed.

AM.6.4 Physical assets should carry a label displaying:

a) which party owns the asset e.g. the Entity

b) the unique asset inventory number referenced in AM.6.2 above.

Labels should be sufficiently robust to avoid the label being removed during the asset’s life, or the data displayed on it becoming unreadable (either through normal wear and tear or intentional defacement). Where physical labels are no longer legible they should be replaced.

MMM

MMM

SSS

131

Control Specification L M HAM.6.5 For physical assets that are at significant risk

of theft, the Entity should consider applying indelible marking to the equipment, to limit its potential for resale by unauthorised parties.

AM.6.6 The Entity should regularly audit its physical asset estate (at least annually) to:

• Verify the accuracy and completeness of entries within its physical asset inventory

• Determine if assets are suitably labelled

• Conform compliance with asset movement restrictions defined within the Physical Asset Plan (see AM.6.1 above)

AM.6.7 Physical assets should be disposed of in a manner conformant with the requirements of these Standards (see OM.22 Secure Disposal and Reuse of Equipment).



References • NIST Special Publication 800-53 Revision 3:o A.7 Asset Management

MMM

MMM

SSS


12.7 Physical & Environmental Security

PE.1 Physical and Environmental Security Planning


P2

Control Standards

The Entity shall evaluate the physical environments in which it processes or stores information and shall apply suitable controls.


Control Specification L M HPE.1.1 The Entity should undertake a structured review

of any proposed information processing or storage facility to determine its suitability. The evaluation should include assessment of:

• Adequacy of environmental controls (heating, lighting, ventilation)

• Adequacy of smoke and fire detection and suppression capabilities

• Access to the facility, including perimeter restrictions and internal access restrictions

• Power, including capacity, quality and predictability of the electrical feed from the electrical grid

• Loading and unloading capabilities forequipment

• Assessment of the most significant risks applicable to the facility’s location, its con-figuration, its facilities and its profile of usage

• Other activities taking place at the location that may have a bearing upon the processing of the Entity’s information (e.g. a shared space used by other organisations).

• Proximity to emergency services (e.g. fire department)

Information processing and storage facilities will include data centre/computer suite environments, as well as offices, other workspaces and archive/storage facilities.

a a

MMM

133

Control Specification L M HPE.1.2 Based upon the findings from its review, the

Entity should develop a plan of new, augmented or improved physical and environmental controls for the target facility. The level of control application should be influenced by:

• The value and classification of the information being handled at the facility.

• The type of facility it is. The Entity’s information assets will likely be created, used, modified and destroy in one of three main physical domains:

a) Offices and other workspaces

b) Data centres/computer rooms

c) Archive/storage locations

Control standards applicable to each of these environments are provided in this section of the Information Security Standards.

PE.1.3 Where a review of a proposed facility shows significant and/or wide-ranging physical or environmental vulnerabilities, the Entity should consider the viability of its information being processed there. Serious physical and environmental risks that cannot be avoided or effectively mitigated should cause the Entity to review its options for possible alternative facilities.



References • NIST Special Publication 800-53 Revision 3:o PE-1 Physical and Environmental Protection Policy and

Procedures

MMM

RRR


PE.2 Common Physical and Environmental Security Controls


P1

Control Standards

The Entity shall ensure that appropriate physical and environmental controls are deployed in all facilities where its information assets are created, handled, modified, stored or destroyed.


Control Specification L M HPE.2.1 On the basis of its review and planning

activities, the Entity should deploy physical and environmental controls to each of its main physical domains. Certain control types will have general applicability to each of its three main physical domains (i.e. offices and other workspaces, data centres and archive/storage facilities).

PE.2.2 The Entity should ensure that the external perimeter of its facility is protected via the deployment of physical access controls. These will include:

• Lockable doors

• Lockable windows

• Designated entry/exit points (e.g. receptions)

• Automated access control mechanisms (e.g. barriers)

• Security guards (static and patrolling)

PE.2.3 The Entity should develop and maintain current lists of personnel with authorisation to access the facility. Appropriate authorisation credentials (e.g. badges, identification cards, smart cards) should be distributed to approved parties. Access lists should be reviewed regularly (at least every six months) to ensure that individuals with access still have a legitimate and approved need for access to the facility.

a a

MMM

MMM

MMM

135

Control Specification L M HPE.2.4 Access credentials to the facility should be

revoked and collected once access is no longer required (e.g. at the end of the individual’s employment).

PE.2.5 Physical access should be monitored and access logs reviewed periodically for anomalies. Apparent access violations should be investi-gated and remedial action taken.

PE.2.6 For those facilities other than those designated as publicly accessible, the Entity should maintain a visitor access log that includes:

• Visitor’s name and organisation

• Date of access

• Time of arrival and departure

• Signature of visitor

• Purpose of visit

• Form of identification presented and verified

• Name and organisation of person being visited

Visitors should be escorted by Entity personnel during their time at the facility.

PE.2.7 The Entity should consider deploying and monitoring real-time intrusion alarm and surveillance systems.

MMM

MMM

MMM

RRR


Control Specification L M HPE.2.8 The Entity should require authorisation prior

to any property (including information assets and information systems) being removed from the facility. For certain assets types (e.g. laptop computers that are regularly taken home by employees to work) pre-approval may be granted to a range of individuals needing to have such a dispensation, depending on the classification of the data being handled on these devices.



HR.6 End of Employment Security

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 9.1.1 Physical security perimetero 9.1.2 Physical entry controlso 9.1.3 Securing offices, rooms, and facilitieso 9.1.4 Protecting against external and environmental

threatso 9.1.6 Public access, delivery, and loading areaso 9.2.1 Equipment siting and protectiono 9.2.2 Supporting utilitieso 9.2.5 Security of equipment off-premises

• NIST Special Publication 800-53 Revision 3:o PE-2 Physical Access Authorizationso PE-3 Physical Access Controlo PE-4 Access Control for Transmission Mediumo PE-6 Monitoring Physical Accesso PE-7 Visitor Controlo PE-8 Access Records

RRR

137

PE.3 Workspace Security Version 2.0Suggested Priority

P1

Control Standards

The Entity shall ensure that the design and use of workspaces supports its Information Security objectives and obligations.


Control Specification L M HPE.3.1 The Entity should define procedures and

implement enforcement mechanisms to support the ‘clear workspace’ provisions of its Information Security policy. Such may include the Entity’s Information Security personnel:

• Conducting periodic walk-throughs of working areas to identify:

- Paper materials and removable digital media left unattended and unprotected.

- Workstations that have been left without a screen lock being applied while unattended.

- Laptops and mobile devices that have been left unsecured outside of working hours.

- Desk pedestals and cupboards that have been left unsecured outside of working hours.

• Removing and quarantining materials of classification of ‘Restricted’ or above discovered on desks, at printers, in meeting rooms, on flip charts, in waste paper baskets etc.

• Identifying, photographing and removing information of classification of ‘Restricted’ or above left on meeting room whiteboards after meetings have been concluded.

• Reporting of clear workspace violations to the senior management of the department concerned.

a a

RRR


Control Specification L M HPE.3.1(Cont.)

• Monitoring the implementation of corrective actions by the department concerned, to ensure future avoidance of clear workspace security violations.

• Recommending disciplinary action where there is evidence of serious and/or repeated violation.

Such enforcement activities should be: a) oriented toward education and continuous improvement b) focused on material of classification ‘Restricted’ or above and c) should not be arbitrarily applied to all information outputs.

PE.3.2 The Entity should seek to ensure that sound-proofing is put in place to protect the confidentiality of discussions taking place in meeting rooms and offices.

PE.3.3 The Entity should consider moving the handling of information of classification ‘Confidential’ or above to demarcated workspaces, with physical access controls separating these environments from common areas of the Entity’s office space.

Where such information must be handled in ‘open plan’ areas, the Entity should make provision to limit the potential for information confidentiality to be compromised (e.g. computer screen filters to limit the potential angle of view).

PE.3.4 For functions handing data of classification ‘Confidential’ or above, the Entity should require access control and event logging capability on printers, scanners and fax machines. Individuals should be required to enter their access credentials at the printer before such materials are output.

RRR

SSS

SSS

RSS

139

Control Specification L M HPE.3.5 Where the Entity already does receive, or

anticipates receiving, data of classification ‘Confidential’ or above via fax, it should consider deploying a fax server, integrated with its electronic mail server and its access control mechanisms (in preference to using traditional fax machines where inbound faxes may remain uncollected).

PE.3.6 Entity personnel should be educated as to the potential information leakage risks associated with work activity and work-related conversations held outside of Entity premises. Where such work and conversations are necessary, the environment should be treated as an Entity workspace and the above Control Specifications should be considered.

PE.3.7 Entity personnel should be encouraged to report any suspicious activity or unaccompanied visitors within Entity premises, to security personnel.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 11.3.3 Clear Desk and Clear Screen Policy

• NIST Special Publication 800-53 Revision 3:o AC-11 Session Lock

• ENISA Secure Printing Guide (http://bit.ly/ustxmL)

RRR

SSS

SSS


PE.4 Data Centre Security Version 1.0Suggested Priority

P2

Control Standards

The Entity shall ensure that data centre facilities provide an adequate level of protection for the information assets stored and processed within them.


Control Specification L M HPE.4.1 In addition to the other controls described

in this section, the Entity should determine what specific, unique or enhanced controls are required to secure its data centre locations. Where the Entity has outsourced information system, application or file hosting to an external, third-party provider, it should ensure that:

• Its contractual terms specify the security controls that will be deployed in the data centre environment and the purpose they will serve.

• The Entity retains the right of audit to validate the continued presence and effectiveness of the contractually agreed controls.

PE.4.2 Sensitive information systems should be sited in dedicated (isolated) physical computing environment, demarcated from other computing environments. The level of access control to this area should be restricted to only those personnel with a verified need for access.

PE.4.3 The Entity should site its data centre in a location where the risk of natural disasters (e.g. flood, fire) is at an acceptable level.

a a

MMM

MSS

RRR

141

Control Specification L M HPE.4.4 The Entity should site its data centre in a location

where the risk of man-made disaster (e.g. plane crashes, riots, explosions, chemical spills) is low.

PE.4.5 Data centres should ideally not be housed in the same building as other offices, especially offices used by other, non-governmental organisations.

PE.4.6 Digital Closed Circuit Television (CCTV) should provide continuous monitoring of parking areas, access points to the data centre and the interior of computer rooms. Recordings should be retained for at least six months from the date of recording.

PE.4.7 The computer rooms of data centre facilities should be placed in the interior of the building, away from perimeter walls. Computer rooms should not have windows.

PE.4.8 The Entity should have fire, power, weather, temperature and humidity monitoring systems in place. The data centre should be subject to continuous monitoring, with automated alerting to relevant personnel in the event of defined reporting thresholds being reached.

PE.4.9 An automatic authentication method (e.g. badge reader) should be deployed for access to the data centre perimeter. The Entity should consider supplementing this with a second form of authentication (e.g. biometric, key pad PIN) for access to computer rooms.

RRR

RRR

SSS

SSS

SSS

SSS


Control Specification L M HPE.4.10 Visitors should be required to sign in and sign

out of the data centre facility, after having their identity verified by reference to primary ID (e.g. passport, Emirates ID or UAE driving license). Visitors should be escorted at all times while in the data centre.

PE.4.11 There should be a Halon or other total flooding fire suppressant agent in place in each computer room. Water-based suppressant agents (e.g. wet pipe sprinkler systems) should not be used due to the potential for damaged to information processing equipment. Fire extinguishers should be placed within computer rooms and other areas of the data centre building. Emergency power-off buttons switches should be installed in computer rooms.

PE.4.12 Battery backup power should be available, with sufficient duration to allow for a switch over to diesel power generation. Diesel generators should have sufficient capacity and fuel to provide power to key information systems and critical data centre infrastructure for at least 24 hours following an outage.

PE.4.13 Security guards and cleaning staff should be subject to criminal background checks. Guards should be trained to follow and enforce the physical security requirements of the facility. Cleaning crews should work in groups of at least two.

SSS

SSS

SSS

SSS

143



References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 9.1.1 Physical security perimetero 9.1.2 Physical entry controlso 9.1.3 Securing offices, rooms, and facilitieso 9.1.4 Protecting against external and environmental threatso 9.1.6 Public access, delivery, and loading areaso 9.2.1 Equipment siting and protectiono 9.2.2 Supporting utilities

• NIST Special Publication 800-53 Revision 3:o PE-2 Physical Access Authorizationso PE-3 Physical Access Controlo PE-11 Emergency Powero PE-12 Emergency Lightingo PE-13 Fire Protectiono PE-14 Temperature and Humidity Controlso PE-15 Water Damage Protection


PE.5 Archive and Storage Facility Security Version 1.0Suggested Priority

P3

Control Standards

The Entity shall protect information held in archive and long-term storage facilities until its disposal.


Control Specification L M HPE.5.1 The Entity should apply Information Security

controls to archive facilities appropriate to the classification of the data being stored.

Information may be reclassified during its lifetime, especially if its sensitivity is time dependent. As consequence, the level of Information Security controls may also need change over time, as the information ages.

PE.5.2 In order to apply appropriate controls to archive facilities, the Entity should be able to confirm:

• What information is being stored

• Who needs to have access to it

• Who is authorised to approve access

• How soon after request must information be retrievable from the archive

• How long the information is to be stored for (see AM.5 Information Management and Retention)

• In what format the information will be stored

• What risks apply to the security of the archive facility

a a

MMM

MMM

145

Control Specification L M HPE.5.3 The Information Owner should formally confirm

how long information should be retained within the archive. On a regular basis (at least annually) the Information Owner should reconfirm that the information still needs to be held and the now anticipated date for the end of its storage. Archived information should not be defaulted to an ‘indefinite’ storage period.

PE.5.4 The Entity should ensure that information held within the archive/storage facility remains accessible during the information’s defined lifecycle. If held on digital media, the Entity should ensure that the media can continue to be accessed as technologies are updated.

PE.5.5 Paper and digital media held in the archive should be uniquely identified and catalogued. A record should be kept of what items were moved in and out of the archive, when, by whom and for what purpose. The record should also show who approved this movement.

PE.5.6 Higher classification materials should be subject to a more stringent level of physical controls e.g. locked storage cages, Closed Circuit Television (CCTV) monitoring of access.

PE.5.7 The Entity should ensure that fire suppressant technologies used within the storage are designed to limit potential damage to archived media (e.g. a sprinkler system only activating in an affected area, not throughout the facility).

SSS

MMM

MMM

MMM

MMM




• AM.5 – Information Management and Retention

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 9.1.1 Physical security perimetero 9.1.2 Physical entry controlso 9.1.3 Securing offices, rooms, and facilitieso 9.1.4 Protecting against external and environmental threatso 9.1.6 Public access, delivery, and loading areaso 9.2.1 Equipment siting and protectiono 9.2.2 Supporting utilities

• NIST Special Publication 800-53 Revision 3:o PE-2 Physical Access Authorizationso PE-3 Physical Access Controlo PE-11 Emergency Powero PE-12 Emergency Lightingo PE-13 Fire Protectiono PE-14 Temperature and Humidity Controlso PE-15 Water Damage Protection

147

12.8 Information Systems Design, Development & Testing

IS.1 Security Requirements of Information Systems


P2

Control Standards

The Entity shall determine Information Security controls requirements for new information systems, or enhancements to existing information systems.


Control Specification L M HIS.1.1 Information Security requirements should be

canvassed from relevant stakeholders and should encompass:

• Legal and regulatory obligations

• Compliance with these Standards

• Compliance with the Entity’s Information Security policy

• Classification of the data at hand

• Business functional requirements

• Integration with existing infrastructure and controls

• Service and Security Management requirements (e.g. what supporting capabilities are needed to support the given information system)

Requirements should be prioritised on the basis of greatest need, with each of the above levels predominating over the ones below it.

IS.1.2 Security requirements should confirm the specific dimension of Information Security where requirements arise (e.g. confidentiality, integrity, availability, capacity, maintainability, non-repudiation).

a

MMM

MMM


Control Specification L M HIS.1.3 Information Security requirements should be

traceable throughout the full lifecycle of the information system. It should later be possible to correlate any Information Security control with the requirement that prompted its design and implementation.

A Requirements Traceability Matrix [see Dependencies below] should be used to ensure the effective capture, categorisation and management of Information Security requirements.

IS.1.4 Information Security requirements should not be bound to specific technologies, which may change over the life of the information system. (This does not prevent the specification of requirements that have a technical focus; the expectation is merely that specific technologies and vendor solutions are not be specified at the time of requirements capture in a way that would too prematurely narrow the range of potential solutions).

IS.1.5 Where an Information Security requirement will not endure for the full life of the information system, the time-dependent parameters of the requirement should be defined (e.g. the cover time needed for the protection of confidential information).

IS.1.6 Each Information Security requirement should be mapped to an individual requester and a unique identifier, to aid traceability throughout the systems development lifecycle.

MMM

MMM

MMM

MMM

149

Control Specification L M HIS.1.7 The Entity should evaluate the totality of

requirements to make sure they are compatible and mutually supportive e.g. Information Security (requirements for a high level of confidentiality) not contradicting Productivity (requirements for a high level of system responsiveness.

IS.1.8 Information Security requirements should be explicitly mapped to the security service type that that they correspond to. Security services types include:

• Authentication

• Access Control and Authorisation

• Availability

• Data Integrity At Rest

• Data Integrity In Motion

• Data Confidentiality At Rest

• Data Confidentiality In Motion

• Non Repudiation

• Recoverability

• Maintainability

Where the provider of the requirements does not have the experience necessary to make such a correlation, the Entity’s Chief Information Security Officer (CISO) should analyse the requirements and propose a workable mapping of requirements to target security services.

MMM

MMM


Control Specification L M HIS.1.9 The Entity should confirm the anticipated usage

of the information system during the capturing of requirements. The requirements capture should confirm the anticipated size of the information system’s user community, their projected demand on the information system and when this demand is likely to occur. Projections should be sought regarding the anticipated future growth in demand, during the life of the information system, for the purpose of undertaking capacity and availability management.



Information Security Requirements Traceability Matrix Template

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 12.1.1 Security requirements analysis and specification

• NIST Special Publication 800-53 Revision 3: o SA-1 System and Services Acquisition Policy and

Procedures o SA-3 Life Cycle Supporto SA-4 Acquisitions

• Abu Dhabi Information Security Design, Development and Testing Guide

MRR

151

IS.2 Information Security Design Version 1.0Suggested Priority

P2

Control Standards

Entity information systems shall adhere to a structured Information Security design that is integrated into the information system design.


Control Specification L M HIS.2.1 The Entity should develop an Information

Security Design for a specific information system that confirms:

• What the Information Classification and Categorisation of the information system will be.

• What specific Information Security controls will be implemented.

• How these controls map to specific, uniquely identified Information Security requirements (see IS.1 Security Requirements of Information Systems).

• How the controls map to Control Standards defined within this document.

• Whether a given control is tailored to the target information system, or if an existing common control will be leveraged. (See SG.7 Enterprise Information Security Architecture and SG.11 Common Control Catalogue). Where the control has potential applicability to other information systems, it should be added to the Common Control Catalogue.

• What anticipated demand will be placed on the control and how it will be sized and configured to ensure its continued availability and functionality under anticipated usage scenarios.

• How a given control will interact with other

controls (e.g. two controls working in harmony to provide defence-in-depth).

aa

MMM


Control Specification L M HIS.2.1(Cont.)

• What risks (including potential impact) would be manifested if the control were to fail or be compromised.

The Information Security Design should be reviewed and approved by the Entity’s Information Security Governance Committee before development, implementation and testing activities are commenced. The Committee shouldseek to satisfy itself that the design has, if implemented, the potential to provide a level of Information Security protection appropriate to:

• the confirmed requirements

• the information system’s classification & categorisation

• the Entity’s risk profile

IS.2.2 The Information Security Design should confirm the specific controls that will be applied in order to a) provide an agreed level of capacity and b) monitor usage against this defined level of capacity.

Where information system usage currently is exceeding, or is anticipated to exceed, the capacity thresholds defined within the Information Security Design, the Entity should make provisions for re-evaluating the usage and sizing of the information system. The information system may need to be resized for continued availability and performance.

Changes in the capacity profile of the primary information system should be reflected in any secondary information systems used for service continuity purposes.

MRR

MMM

153

Control Specification L M HIS.2.3 When designing information systems, Entities

(or their third-party providers) should adhere to a tiered (i.e. multi-level) architecture model. Such allows information system design to adopt a modular approach that helps manage complexity and dependencies.

An example three tier model is:

• Presentation/Client Tier

• Business Logic/Application Tier

• Database Tier

The specific number of tiers required will depend upon the Entity’s business needs and prevailing architectural standards. Individual tiers may be further elaborated into supporting sub tiers, as required.

The information system design should decide upon:

• The optimal tier for the placement of a given security control type

• Whether the same control type needs to be replicated within multiple tiers

• How the security of interfaces between the tiers can be protected and tier boundaries enforced

IS.2.4 The Entity should ensure that Information Security requirements (see IS.1 Security Require-ments of Information Systems) remain fully traceable throughout the design, development and testing process. A clear correlation between Information Security requirements and a specific, tangible set of management and technical controls targeted to meet those requirements should be fully evident.

MMM

MMM


Control Specification L M HIS.2.5 The Information Security Design should serve as

the primary record of how Information Security controls will be, and have been, deployed for a specific information system.

IS.2.6 When designing Information Security controls, the Entity should undertake a business impact analysis in relation to Control Standards shown as ‘Recommended’ or ‘Suggested’ within these Standards. This being in order to determine if the benefit of applying a given control outweighs its potential negative impact on the business process. (Information Security should be approached as an enabler of effective government activities, not impedance to them. Unduly restrictive or ill-conceived Information Security controls that don’t take account of Entity’s risk profile and business objectives may have unintended consequences e.g. decreasing productivity, user satisfaction and service availability).

IS.2.7 The Entity should consider the deployment of automated code analysis tools during the development and testing lifecycle, to evaluate code for common software vulnerabilities.

IS.2.8 The Entity should ensure that the design of information systems is aligned to best practice for the secure development of information systems (see References below). Such including the need for:

• Input Data Validation (restriction of the types of information that can be entered into an application)

MMM

MMM

RRS

SSS

155


• Output Data Validation (only confirmed information types can be output by the information system)

• Message Integrity, authenticity and confidentiality (messages within the information system and between information systems are protected from being compromised)

• Exception Management Control of Internal Processing (validation checks are made to detect and handle errors and exceptions in a secure manner)

Information systems should be designed and developed with an orientation toward achieving a known, good configuration that is provably secure against the agreed security requirements.

IS.2.9 Where an information system has been developed by a third-party supplier, the Entity should undertake an evaluation of the Information Security controls deployed by the supplier. This provision should apply whether the information system includes Commercial Off-The-Shelf (COTS) software or is a solution developed specifically for the Entity.

Where the Entity identifies control omissions within the third-party developed information system, it should implement compensating controls to address the identified shortfall.

The specification and management of the third-party controls should be handled in a manner consistent with the provisions within the Third Party Supplier Security section of these Standards.

MMM

MMM


Control Specification L M HIS.2.10 Design of information systems should consider

the infrastructure and computing environment into which the information system will be deployed. The information system should be designed to work in a hardened environment. The Entity should ensure that the infrastructure will be supportive of the security needs of the information system.

IS.2.11 Information systems should be designed to fail in a secure manner i.e. avoiding security vulnerabilities being presented at the time of failure.

IS.2.12 The Information System Owner and/or Information Owner (as applicable) should approve the Information Security Design prior to the development of the security controls commencing.

IS.2.13 When undertaking its design activities, the Entity should consider physically isolating information systems of higher classifications, to allow for the demarcation of physical controls, on the basis of the sensitivity of data held on those information systems.

MMM

MMM

MMM

SSS

157



SG.7 Enterprise Information Security ArchitectureSG.11 Common Control CatalogueIS.1 Security Requirements of Information Systems

References • NIST Special Publication 800-27 Rev A ‘Engineering Principles for Information Technology Security’

• SafeCode - Fundamental Practices For Secure Software Development http://www.safecode.org/publications/SAFECode_Dev_Practices0211.pdf

• DACS - Enhancing the Development Life Cycle to Produce Secure Software: A Reference Guidebook on Software Assurance

• Software Assurance Maturity Model (SAAM) http://www.opensamm.org/download/

• Open Web Application Security Projecthttps://www.owasp.org/index.php/OWASP_Guide_Project

• Build In Security Initiativehttps://buildsecurityin.us-cert.gov/bsi/home.html

• ISO 7498-2 Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture



IS.3 Information System and Network Device Hardening


P1

Control Standards

The Entity shall restrict information systems and networks to only those configurations required to achieve the agreed design objectives.


Control Specification L M HIS.3.1 The Entity should design information systems

and networks to function only with the least level of privilege necessary to complete the agreed task. Unnecessary functionality, processes, protocols and ports should be disabled. Hardened versions of application software, middleware, operating systems and hardware should form a baseline configuration for the computing device.

IS.3.2 The Entity should develop a checklist to ensure that information system and network hardening procedures have been followed during commissioning.

IS.3.3 Baseline configurations of hardended information systems should be held under change control in definitive software and hardware libraries (i.e. repositories that hold a master copy of the software images and documented hardware specifications that have been approved).

IS.3.4 Information Security testing and on-going monitoring should confirm that unnecessary functionality and capabilities are not active within information systems being commissioned or already within the production environment.

aa

MMM

MMM

MRS

MMM

159

Control Specification L M HIS.3.5 Operational changes to baselined, hardened

information systems should be assessed for their potential to deviate the system configuration away from the Entity’s hardening best practices.

IS.3.6 Hardware configurations should be limited to only those components required for the purpose stated in the network, information system or information security design. Unnecessary hard-ware components should ideally be removed or at least disable in software.

IS.3.7 Incidents should be analysed for potential learning regarding the further enhancement of the Entity information system and network hardening capabilities.

IS.3.8 Equipment subject to maintenance should be confirmed as being returned to the hardened configuration baseline, before being reintroduced to the production environment.



References • NIST Special Publication 800-53 Revision 3: o CM2- Baseline Configurationo CM-6 Configuration Settingso AC-19 Access Control for Mobile Devices


MMM

MMM

MMM

MMM


IS.4 Source Code Protection Version 2.0Suggested Priority

P2

Control Standards

The Entity should protect software source code carefully from unauthorised access and/or modifications.


Control Specification L M HIS.4.1 Program source libraries should not be stored in

operational information systems.

IS.4.2 Updating of program source libraries and issuing of programme sources to programmers should only be performed after appropriate authorisation.

IS.4.3 Maintenance and copying of programme source libraries should be subjected to strict change control procedures.

IS.4.4 Access to programme source code should be restricted. Access to programme source code and associated items (such as designs, specifications, verification plans, and validation plans) should be strictly controlled to prevent the introduction of unauthorised functionality and avoid unintentional change.

IS.4.5 Central storage of code in secure programme libraries should be considered.

a

MMR

MMM

MMM

MMM

RRR

161

Control Specification L M HIS.4.6 Where use is made of third-party code, the

source libraries should be validated for accuracy and avoidance of malicious code.

IS.4.7 The Entity should ensure that software code is independently verified for completeness, accuracy and the avoidance of common security vulnerabilities prior to it being complied. The verification should be done by an independent party with the knowledge, skills and experience to effectively verify the code.

Where the Entity is purchasing off-the-shelf/already compiled software, contractual terms with the third-party supplier should require that the third-party is adhering to safe coding practices (see References below).



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 12.4.3 Access Control to Program Source Code

• NIST Special Publication 800-53 Revision 3: o AC-3 Access Enforcemento AC-6 Least Privilegeo CM-5 Access Restrictions for Changeo CM-9 Configuration Management Plano MA-5 Maintenance Personnelo SA-1 System and Services Acquisition Policy and

Procedures


MMM

MRR


IS.5 Cryptographic Controls Version 2.0Suggested Priority

P2

Control Standards

The Entity shall deploy cryptographic controls in a manner commensurate with confirmed confidentiality, integrity and non-repudiation requirements and in a manner supportive of the organisation’s security policy.


Control Specification L M HIS.5.1 As applicable, an Information Security Design

should confirm how cryptographic controls will be deployed and for what business purpose.

IS.5.2 The Entity should endeavour to only select robust public-domain (non-proprietary) crypto-graphic algorithms for use within its information systems and networks.

Where requirements and/or market constraints present a strong case for the use of proprietary cryptographic algorithms, the proposed use should be discussed in advance with ADSIC.

IS.5.3 The selected cryptographic key length should be sufficient to provide adequate protection for the cover time defined within the Information Security Design.

For symmetric/secret key cryptography, key lengths of at least 256 bits should be used for information of classification ‘Confidential’ or above.

For asymmetric/public key cryptography, key lengths of at least 1024 bits should be used for information of classification ‘Confidential’ or above.

aa

MMS

MMS

MMM

163

Control Specification L M HIS.5.4 Hybrid cryptographic systems (i.e. ones making

use of both symmetric and asymmetric algorithms) should be considered in order to achieve a balance between cryptographic system manageability and system performance.

IS.5.5 The Entity should only solicit public key certificates from ADSIC-approved Certification Authorities.

IS.5.6 Users of information systems should be prohibited from using cryptographic controls that are not part of an approved Information Security Design.

IS.5.7 Cryptographic controls should be designed and implemented in a manner considerate of the Entity’s need to effectively monitor its information flow, retain oversight of information system usage and protect against malicious software.

IS.5.8 The Entity should have in place adequate provisions for key management of crypto-graphic systems including issuing, changing and revoking keys as necessary.

IS.5.9 For data hosted at Entity-owned facilities, cryptographic protection should be applied to data at rest.

MMS

MMM

MMM

MMM

MMS

RRS


Control Specification L M HIS.5.10 Data hosted at non Entity-owned facilities e.g.

third-party data centres should be subject to strong encryption protection at rest.

IS.5.11 Data transmitted to/from non-Entity-owned facilities (e.g. third-party data centres) should be subject to strong encryption to protect data in motion.

IS.5.12 Workflow approval within information systems should be supported via the use of digital signatures using public key cryptography.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 12.3.1 Policy on the Use of Cryptographic Controls

• NIST Special Publication 800-53 Revision 3: o SC-13 Use of Cryptography

• NIST Special Publication 800-78-3 ‘Cryptographic Algorithms and Key Sizes for Personal Identity Verification’

• RSA Laboratories – recommendations for public key system key sizes


MMM

MMR

SSS

165

IS.6 Information Leakage Prevention Version 2.0Suggested Priority

P2

Control Standards

The entity should design information systems to prevent unintentional information leakage.


Control Specification L M HIS.6.1 The entity should design information systems

with a focus on identifying the appropriate location(s) for the storage of information. Boundaries for information repositories should be adequately defined and suitable protections applied to their boundaries when the information system is being designed and developed.

The Information Security Design should provide a baseline for acceptable information storage and transmission parameters, against which extrusion monitoring can be conducted (see OM.11 Information Extrusion and Detection).

IS.6.2 When developing and testing information systems, the entity should ensure that the normal operations of the information system (e.g. the computation of cryptographic calculations) and exception states (e.g. the generation of error messages) do not unintentionally leak information of potential benefit to an attacker.

IS.6.3 The entity should apply shielding mechanisms to protect information systems and networks from information leakage due to electro-magnetic signals emanations.

a

MRR

MRR

SSS


Control Specification L M HIS.6.4 The entity should design and deploy end-point

protection to prevent the copying of information systems data to removable media (e.g. DVDs, USB sticks).



IS.2 Information Security Design

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 12.5.4 Information leakage

• NIST Special Publication 800-53 Revision 3: o PE-19 Information Leakage


RSS

167

IS.7 Mobile Code Protection Version 2.0Suggested Priority

P1

Control Standards

The Entity shall implement mobile code protection on all information systems.


Control Specification L M HIS.7.1 The Entity should implement procedures and

tooling that address mobile code. Appropriate controls should be introduced to restrict the use of mobile code not approved by the Entity.

IS.7.2 Users should be made aware of the dangers of mobile code.

IS.7.3 The Entity should receive information system security alerts/advisories regarding mobile code vulnerabilities on a regular basis, issue alerts/advisories to appropriate personnel, and take appropriate actions in response.

IS.7.4 Appropriate authorisation should be given for the use of mobile code on information systems. (Example technologies being: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript). Unless a given mobile code type is explicitly authorised, it should be restricted.

IS.7.5 Usage restrictions to limit the use of mobile code should be designed into information systems, with appropriate warnings being generated for users ahead of mobile code being invoked.

a a

MMM

MMM

RRS

RRR

RRR


Control Specification L M HIS.7.6 The Entity should consider prohibiting the

downloading and execution of mobile code on individual computing devices.

IS.7.7 Appropriate Entity officials should authorise the use of mobile code. Usage restrictions and implementation guidance should apply to both the selection and use of mobile code installed on Entity servers and mobile code downloaded and executed on individual workstations. Control procedures should prevent the unauthorised development, acquisition, or introduction of mobile code within the information system.



References • Abu Dhabi Information Security Design, Development and Testing Guide

RRR

SSS

169

IS.8 Security Appliance and Security Software Design


P1

Control Standards

The Entity shall design and deploy Information Security appliances and software to support its Information Security objectives.


Control Specification L M HIS.8.1 Information Security appliances and software

should be selected and deployed to tangibly support the Entity’s Information Security programme and to reduce its exposure to risk.

Security appliance/software may include: firewalls, intrusion detection and intrusion prevention devices, spam blocking, log analysers, security event monitors, vulnerability scanners, anti-virus software and other capabilities types deemed necessary in support of the Information Security programme.

IS.8.2 Information Security appliances and security software should only be implemented and managed by trained and authorised personnel, with a specifically defined role in Information Security.

IS.8.3 The Entity should specifically prohibit the possession and use of security software such as network sniffers and password crackers by non-authorised personnel; or use by authorised personnel in a non-authorised manner.

a a

MMM

MMM

MMM


Control Specification L M HIS.8.4 Testing of security appliances/software should

seek to confirm:

• Does the appliance/software function as envisaged in the agreed Information Security design? (For example, detecting anomalous events in the manner and time envisaged).

• Could the appliance/software be circumvented by a malicious attacker?

• Does the appliance fail in a secure state?

IS.8.5 The Entity should consider a defence-in-depth approach for its security appliances/software, to provide multiple levels of protection e.g. both exterior and interior firewall protection.




MMM

MMM

171

IS.9 Management of Development and Test Access


P3

Control Standards

The Entity shall ensure that developers’ and testers’ access to information systems is removed when no longer required.


Control Specification L M HIS.9.1 The Entity should implement procedures

that limit developers’ and testers’ access to information systems to only those areas of the system and those periods of the development and test lifecycle necessary for their work to be completed. Prior to being commissioned, developer and tester accounts should be removed.

IS.9.2 Where developers need to provide on-going support of the information system after its commissioning, or where testers require business-level access, standard user or super user accounts (as appropriate) should be created for this purpose.

IS.9.3 Information system commissioning checks should confirm that legacy user, administrator, developer and tester accounts do not remain on the information system after its move to production status. Accounts without a verified need during the production phase of the information system’s lifecycle should be purged prior to the move of the information system to production status.




a

RRR

RRR

RRR


IS.10 Network Segregation Version 2.0Suggested Priority

P2

Control Standards

The Entity shall segregate information services, users, and information systems in networks, based upon sensitivity and risk exposure.


Control Specification L M HIS.10.1 Any connections to public networks or

information systems should occur through controlled interfaces (e.g., proxies, gateways, routers, firewalls, encrypted tunnels).

IS.10.2 The operational failure of network boundary protection mechanisms should be detected and should not result in any unauthorised release of information outside the information system boundary.

IS.10.3 The Entity should employ Network Address Translation (NAT) to prevent the typology and configuration of its core network being discoverable by outside parties.

IS.10.4 The Entity should employ Virtual LANs (VLANs) within its core network to segregate user groups from a) each other and b) information services.

IS.10.5 The Entity should consider deploying multiple VLANs to delineate the differing levels of its IT architecture (i.e. web/application/database/storage area network).

a

RRR

RRR

RRR

MMM

MMM

173

Control Specification L M HIS.10.6 The Entity should consider segregating

individual application servers into their own VLAN segments.

IS.10.7 The Entity should consider the deployment of access control lists, internal firewalls and intrusion detection capabilities within its core network, to segregate and monitor particularly sensitive information assets and information systems.

IS.10.8 Boundary firewalls should be stateful, only permitting connections between networks where a well-formed network session can be confirmed.

IS.10.9 One or more ‘Demilitarized Zones’ (DMZs) should be created to segregate externally published/available services from the Entity’s information systems intended for internal use only. Individual DMZ network segments for each published service should be considered to prevent compromises propagating between services.

IS.10.10 Any information system holding data of classification ‘Restricted’ or above should reside on the Entity’s core network and never be directly accessible from a public network (e.g. the Internet). The establishment of a DMZ may be used to securely facilitate access to the data by approved users external to the organisation.

IS.10.11 Network devices and information systems within the core network (i.e. behind the boundary defences) should be configured to not respond to external requests for profile data (e.g. ping, traceroute).

MRS

MRS

MMM

MMR

MRR

MMM


Control Specification L M HIS.10.12 DMZ-based information systems should

communicate with information systems within the Entity’s core network via an application proxy.

IS.10.13 Networks should be categorised (see SG.2 Information Security Categorisation) at a level corresponding to the highest information system categorization present on that network.

IS.10.14 The network routing protocols deployed for communication with external networks should be different than those used on internal networks.

IS.10.15 Information systems and workstations should not be connected to any other network at the time of their connection to the Entity’s core network. Ad-hoc bridging of networks via a workstation should be prohibited.



SG.2 Information Security Categorisation


• ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 11.4.6 Network connection control

• NIST Special Publication 800-53 Revision 3: o AC-4 Information Flow Enforcement

• SANs Institute: ‘Design Secure Network Segmentation Approach’ http://bit.ly/tOjoW2

RRR

RRR

RRR

MMM

175

IS.11 Routing, Switching and Network Patching Security


P2

Control Standards

The Entity shall implement appropriate controls to secure its data networking infrastructure.


Control Specification L M HIS.11.1 The Entity should employ gateway-to-gateway

strong encryption to protect data traffic transiting between its physical locations, to limit the potential for eavesdropping.

IS.11.2 Routing and switching equipment should be housed in physically secure locations, to which only approved personnel have access.

IS.11.3 Network routers should be configured to permit exchange of routes only with trusted parties.

IS.11.4 Simple Network Management Protocol (SNMP) should be disabled on devices unless it is actively used for network management. Where SNMP is used for communication between network devices, the preferred version should be version 3.x. or later. Version 2.x should only be used by exception. Earlier versions of the protocol should be disabled on devices capable for running them. A strong community string should be used with SNMP.

IS.11.5 Network routers and switches should be hardened to limit the attack surface that they present. Hardening of network devices may include (but not be limited to):

• Disabling unused protocols and network services

• Disabling unused network interfaces and VTYs (Virtual Teletypes)

a

MRS

MRS

MMM

MMM

MMM



• Disabling unused ports

• Disabling unnecessary message types received on a network interface

• Enabling hashing of network device passwords

• Setting CPU and memory thresholds

• Reserving memory for console access

• Enabling detection of memory leaks and buffer overflows

• Filtering questionable packet types (e.g. ICMP packets, IP fragments, TTL value in packets)

• Control plane protection via port filtering and queue thresholds

• Configuring anti-spoofing protections

• Broadcast Storm control per interface to limit the broadcast from an infected machine.

IS.11.6 The Entity should protect itself against potential Denial of Service attacks on its network. Protections may include:

• Rate Limiting for certain data types e.g. SYN packets

• Unicast Reverse Path Forwarding (uRPF) checking

• Applying ingress and egress filtering using Access Control Lists

• Limiting ICMP packets

MMM

RRR

177

Control Specification L M HIS.11.7 Switches should be used in preference to network

hubs and Virtual Local Area Networks (VLANs) should be configured on switches to segregate different:

• User communities

• Information system categorisations

IS.11.8 Virtual Trunking Protocol (VTP) should be disabled on switches, unless specifically required. Where enabled, the following should be set for VTP: management domain, password and pruning. VTP should be set to Transparent Mode.

IS.11.9 The Entity should consider the deployment of a password management system for network devices that allows for the concurrent updating of passwords across the network infrastructure.

IS.11.10 Router and switch operating systems should be regularly patched and updated as indicated by the device vendor.

IS.11.11 The SSH protocol should be used in preference to

Telnet for communication with network devices.

IS.11.12 Routers and switches should be managed out-of-band where possible. Where this is not feasible, a separate VLAN should be created for in-band management.

IS.11.13 Port security should be enabled on switches to limit access based on MAC addresses. Auto-trunking should be disabled on ports. Trunk ports should be assigned a native VLAN number that is not used by another port.

SSS

SSS

MMM

RRR

RRR

RRR

RRR


Control Specification L M HIS.11.14 The Entity should consider deploying tooling to

detect potential and actual attacks on the TCP/IP Address Resolution Protocol (ARP) and to deploy Dynamic ARP inspection to avoid man-in-the-middle attacks.

IS.11.15 The Entity should restrict network broadcasts to only essential traffic required in support of an approved network design. Non-authorised broadcasts should not be forwarded by routers.

IS.11.16 Ingress and egress filtering should be deployed at boundary routers to limit the potential for IP address spoofing.



References • SANSo Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switcheso Critical Control 19: Secure Network Engineering


RRR

SSS

SSS

179

IS.12 Wireless Network Security Version 1.0Suggested Priority

P2

Control Standards

The Entity shall ensure that wireless networks and wireless-enabled devices are suitably protected.


Control Specification L M HIS.12.1 Prior to deploying wireless base stations, the

Entity should undertake and document a site survey to determine the optimal physical locations for their placement. The need to provide sufficient signal coverage to a defined area should be balanced against the need to avoid stray signal leaking too far outside of the Entity’s physical perimeter.

IS.12.2 The Service Set Identifiers (SSIDs) of wireless base stations should either not be broadcast or should be anonimised, so as to avoid the wireless network being associated with the Entity by non-approved network users.

IS.12.3 Authentication to a wireless base station should only be via strong encryption, with no authentication credentials being transmitted in the clear over the air.

IS.12.4 The Entity should prohibit and sanction the creation and use of ad-hoc wireless networks, including the connecting of unapproved wireless base-stations to the Entity’s core data network.

a a

MMM

MMM

MMM

SSS


Control Specification L M HIS.12.5 Workstations and mobile devices should be

restricted from accepting inbound wireless connections while their wireless cards are enabled.

IS.12.6 Data of classification ‘Confidential’ or above transiting over a wireless network should be subjected to strong encryption to protect its confidentiality.

IS.12.7 The Entity should put in place mechanisms that allow for the identification and isolation of rogue wireless access points.

IS.12.8 Connections to the Entity’s core network initiated from a wireless station should be subject to equivalent authentication and access control processing as would apply to a wired connection to the network. No connection to services on the core network should be permitted from generic accounts or anonymous users.

IS.12.9 The Entity should consider authenticating wireless stations to client devices, as well as authenticating clients to base stations, via use of 802.1x authentication.

RRR

RRR

SSS

MMM

MMM

181

Control Specification L M HIS.12.10 The use of ‘guest’ wireless networks should be

restricted to genuine short-term guests of the Entity and consultants without a verified need for connection to the Entity’s core network. Guest networks should only connect to the Internet and their data should not transit via the Entity’s core network. Traffic on wireless guest networks should not be terminated on the core network and should be tunnelled directly to the network perimeter.

A client device should not be permitted to connect to the core network and the guest network at the same time.

Traffic on guest networks should be monitored by the Entity to ensure conformance with its acceptable usage provisions. Temporary users of guest networks should be required to authenticate to the network, to avoid opportunistic use of the Entity’s network resources.

IS.12.11 When using public wireless base stations (e.g. ones in hotels, coffee shops, airports etc.), Entity staff should be required to establish a VPN tunnel before data of classification ‘Restricted’ or above is sent or received.

IS.12.12 Unless there is a verified business need and appropriate security controls have been deployed, the Entity should consider disabling short-range and near-field wireless functionality on computing devices e.g. Bluetooth.

RRR

SSS

SSS


Control Specification L M HIS.12.13 When designing its wireless networks, the Entity

should consider the number of base stations to be deployed, where they will be situated, what bandwidth limitations should apply to clients and what wired alternatives should exist, so as to limit the potential for wireless-based Denial of Service attacks.

IS.12.14 The Entity should consider restricting the time period during which connections to its wireless networks are permitted (e.g. restriction to working days and working hours).



References • NIST Special Publication 800-53 Revision 3: o AC-18 Wireless Access

• NIST Special Publication 800-153 ‘Guidelines for Securing Wireless Local Area Networks (WLANs)

• NIST Special Publication 800-97 ‘Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i’


SSS

SSS

183

IS.13 Information Systems and Network Security Testing


P2

Control Standards

The Entity shall conduct Information Security testing of information systems and networks.


Control Specification L M HIS.13.1 The Entity should develop an Information

Security Test Plan for all information systems and information networks.

For new information systems and networks, the test plan should be developed during the design phase of the information system’s lifecycle. For existing information systems and networks, the test plan should be developed at a time deemed appropriate by the Information Owner and the Information System Owner custodian.

The test plan should confirm:

• What specific, uniquely identified Information Security controls are in scope for testing.

• Whether any Information Security controls will be omitted from the testing exercise, the rationale for their exclusion and the associated risk.

• How the controls will be tested.

• Who will test them and what their competencies and qualifications are to undertake such tests.

• How test results will be documented and communicated to relevant stakeholders. (With provision for how results will be secured from access by unauthorised parties).

a

MMM


Control Specification L M HIS.13.1(C0nt.)

• What minimum acceptable outcomes are required for the test to be deemed successful i.e.

- the acceptance criteria articulated by relevant key stakeholders including the Information Owner and the Information System Owner.

- the compliance requirements imposed by these Standards.

(The Information Security Test Plan should support full traceability, from requirements definition to the design and implementation of controls, through to testing of those controls to verify their ability to meet requirements).

IS.13.2 Information Security testing should seek to confirm whether:• The control is configured in a manner consistent

with the target configuration defined for it within the Information Security Design.

• The control performs in a manner consistent with the performance baseline defined for it within the Information Security Design.

• The control cannot be bypassed, compromised, fed erroneous data or otherwise compromised.

• The alerting associated with detective controls is timely and accurate.

• The control is capable of supporting the anticipated loading defined within the Information Security Design (e.g. x number of concurrent transactions per second through the Internet proxy).

RRR

MMM

185


• The generation of false negative and false positive results is within acceptable thresholds defined within the Information Security Design.

• The control fails to a safe state when adverse conditions are simulated.

• The control’s deployment and usage avoids introducing secondary risks.

• Common vulnerabilities applicable to the technology type are not capable of being exploited.

• Management information generated by or in relation to the control is accurate, relevant to management of the control/information asset and is generate in a timely way.

• The administrative and management support required for the control are in place and are effective.

IS.13.3 The Information Security Test Plan should be developed in concert with the functional and non-functional test plans for the information system, to ensure a coherent and integrated approach is taken to testing.

IS.13.4 The Information Owner and System Owner should be informed signatories of both the Information Security Test Plan and the associated results report.

RRR

MMM

MMM


Control Specification L M HIS.13.5 The Information Security Design (see IS.2

Information Security Design) may make use of:

• Controls that are developed specifically for the information system concerned.

• Existing common controls that apply to multiple information systems.

• A combination of both of the above.

Where an existing common control (see SG.11 Common Control Catalogue) is to be applied to a new information system, it should be re-tested to ensure that:

• The confidentiality, integrity and availability baseline of the common control is not compromised by its application to the new information system.

• The additional anticipated demand on the control is within acceptable capacity parameters (e.g. the control is able to process the additional number of transactions that would be generated).

• New vulnerabilities are not introduced as a consequence of making this connection between the new information system and the common control.

IS.13.6 Upon request, the Entity should make available its test plans and test results to ADSIC. These will serve as a key input to information system accreditation activities.

MMM

MMM

187

Control Specification L M HIS.13.7 The Entity’s Change Management process

should consider the impact of proposed changes on a security control. Substantial change would require Information Security testing to be repeated during the control’s life.

IS.13.8 Information Security testing should seek to simulate common attacks and exploitations relevant to the target technology and information types.

IS.13.9 The Information Security test plan and Information Security test results should be retained in a secure manner but be made readily accessible to relevant, authorised parties in the event of them needing to be used by the Entity’s Information Security Incident Management process.

IS.13.10 During the information system or network’s production lifecycle, on-going vulnerability scanning should be used to determine if any new vulnerability has been introduced after the completion of original security test. (See OM.7 Technical Vulnerability and Patch Management).

IS.13.11 Software security testing should make use of code analysis tools to identify common programming flaws.

IS.13.12 In addition to information system or network-specific security testing, the environment in which the information system is deployed should also be subject to regular wide-ranging penetration testing that seeks to simulate the exploitation of vulnerabilities across multiple elements of the Entity’s information technology estate.

MMM

MMM

MMM

MMM

MMR

MRS


Control Specification L M HIS.13.13 A formal Information Security Test Report should

be produced confirming:

• What tests were conducted and when during the development lifecycle they occurred.

• Who the tests were conducted by

• What deviations from the approved Information Security Test Plan occurred, why and what consequences arise from the deviation

• What findings the tests produced

• What recommendations have been made by the tester regarding the information system’s security, relative to the agreed design and associated requirements

• What decisions have been taken in light of the findings and recommendations

• What risks remain unaddressed on completion of the testing

IS.13.14 The Information Security Test Report should be approved by the Chief Information Security Officer, the Information System Owner and the Information Owner. The report should serve as a key input into the ‘go/no go’ decision made regarding the move of the information system to production status. Where the CISO, Information System Owner and Information Owner cannot ratify the test report then the system should not assume production status. In such an event, options available to the decisions makers are:

• Rerun the same tests to validate the results

• Develop new test cases if the original ones were incorrectly scoped

MMR

MMR

189


• Redesign the information system’s control set to address shortcomings identified during testing

• Accept the attendant risk(s), either as-is or with the application of compensating controls. (Risk acceptance can only occur within the boundaries of the Entity’s decision-making powers. Entities cannot accept risks related to Control Specification elements shown as ‘Mandatory’ in these Standards, unless there is prior agreement on exemption with ADSIC.).

Note: ‘production status’ means that live business data is present on the information system. Avoiding the ‘production’ designation (e.g. by keeping an information system at test status indefinitely) is not permitted as a means to bypass the obligations imposed above. Where any information system is hosting or processing live business data, that information system’s Information Security Test Report must have been authorised in the manner described.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.3.2 System acceptanceo 12.5.5 Outsourced software development

• NIST Special Publication 800-53 Revision 3: o SA-11 Developer Security Testingo SI-6 Security Functionality Verificationo SI-7 Software and Information Integrity


MMR


IS.14 Domain Name Service Security Version 1.0Suggested Priority

P2

Control Standards

The Entity shall protect its Domain Name Service facilities to ensure the integrity and availability of its network address space.


Control Specification L M HIS.14.1 The Entity should deploy Domain Name Service

(DNS) in a hierarchical, structured fashion. All internal networks client machines should be configured to send requests to intranet-based DNS servers, not DNS services located outside of Entity’s core network.

IS.14.2 DNS servers should be hardened to restrict their configuration to only essential processes. DNS should not be co-located on servers running other application types.

IS.14.3 DNS zones should be signed using an asymmetric cryptographic key pair to provide data origin authentication.

IS.14.4 Name servers should be configured to turn on DNSSEC processing, in support of data origin authentication.

IS.14.5 Updates to DNS servers should require multi-factor authentication, to limit the potential for unauthorised updates to DNS records and zone files.

a

MMM

RRR

RRR

RRR

RRR

191

Control Specification L M HIS.14.6 DNS zone file(s) should regularly be reviewed (at

least quarterly) for any possible integrity errors.

IS.14.7 The Entity should consider designing its DNS capabilities to achieve network topological and geographic dispersion of authoritative name servers, in order to improve fault tolerance.

IS.14.8 DNS servers should be protected via network Quality of Service (QoS) and ingress filtering controls, to limit the potential for packet flooding attacks.

IS.14.9 BIND installations and the DNS server operating systems should be regularly patched to limit the potential for vulnerabilities within the Domain Name Service from being exploited.



References • NIST SP 800-81 ‘Secure Domain Name System (DNS) Deployment Guide’


SSS

SSS

SSS

RRR


IS.15 Protection of Information System Test Data


P3

Control Standards

The Entity should select information system test data carefully, and provide protection when sensitive data is involved.


Control Specification L M HIS.15.1 Information of classification ‘Restricted’ or

above, or information that is directly attributable to named individuals should be not be used for the purpose of information system test data, wherever possible. When this is not possible, the data should be randomised and anonimised before testing commences.

IS.15.2 All test data should be purged from the information system once testing has been completed.



References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 12.4.2 Protection of System Test Data

• NIST Special Publication 800-53 Revision 3:o AC3 Access Enforcemento AC4 Information Flow Enforcement


a

MMM

MMM

193

12.9 Identity & Access Management

IA.1 Identity Management Version 1.0Suggested Priority

P1

Control Standards

The Entity shall ensure that it verifies the identity of users and information systems intended to have access to its information assets.


Control Specification L M HIA.1.1 The Entity should ensure that the identity of all

information users is initially authenticated via reference to original primary source photo ID (passport, Emirates ID card, UAE driving license) as part of the enrolment process for access to Entity information systems, premises, processing facilities and data stores.

IA.1.2 Re-authentication of information users should take place when changes to their access is required and/or requested e.g.:

• Password reset

• Account re-enablement following lock-out

• Increase in privilege level

• Change of name

Such changes should not be made unless the Information System Owner (or their nominated delegate) has satisfied themselves that the person requiring or requesting the change has the identity associated with the given account. It should not be assumed that a requester is the person claimed, unless there is definitive recognition via facial recognition, vocal recognition or re-checking against primary source ID.

a a

MMM

MMM


Control Specification L M HIA.1.3 Identity verification via primary source ID

checking should be undertaken for all visitors to the Entity’s principle data processing (e.g. data centre) and data archiving facilities. The verification should occur on each occasion of a visit, unless and until the party has been approved for regular, unescorted access to the facility. The visitor’s name, the ID type reviewed and the ID number should be recorded in a facility access log.

IA.1.4 Information systems and network devices requesting access on behalf of themselves or as proxies on behalf of users should be authenticated via trust mechanisms such as secure directories and public key certificates.

IA.1.5 Foreign identity documents that the Information System Owner cannot readily confirm the voracity of (e.g. overseas driving licenses, student cards) should not be accepted for the purpose of primary source ID.

IA.1.6 Foreign passports should not be accepted as a source of primary ID unless and until the individual concerned has been confirmed as screened by the relevant UAE authorities.

IA.1.7 Where the use of Public Key Infrastructure (PKI) capabilities applies, the Entity should apply particular vigilance to verifying an identity before it is bound to a public key certificate. Given the sensitivity of the process and the one-time nature of the association, multiple individuals should check that the identity is the correct one.

SSS

SSS

RRR

RRR

RRR

195

Control Specification L M HIA.1.8 Where a Public Key Infrastructure is used, the

information system should:

• Validate user and information system certificates by constructing a certification path to a known and trusted Certification Authority.

• Ensure that the user’s private key is protected from potential usage by another party.



HR.2-Screening

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 11.2.1 User registration

• NIST Special Publication 800-63-1 ‘Electronic Authentication Guide’

RRR


IA.2 Account Management Version 2.0Suggested Priority

P1

Control Standards

The Entity shall ensure that accounts on information systems are managed and monitored.


Control Specification L M HIA.2.1 The Entity should ensure that a formal

registration and de-registration process is in place for granting and revoking accounts on information systems.

IA.2.2 Information system users should be provided with unique account IDs to allow for confirmation that all activities undertaken via that account can reliably be associated with the specific user. Generic accounts should never be permitted on any Abu Dhabi government information system.

IA.2.3 Obsolete accounts should not be re-issued to other users.

IA.2.4 Accounts should be revoked in accordance with the Human Resources provisions of these standards (see HR.6 End of Employment Security).

IA.2.5 On a regular basis (at least quarterly) the Entity should formally review the accounts on its information systems and ensure that all accounts remain valid and in active use. Dormant accounts should be backed up and then purged from the production system.

Dormancy will be determined on the basis that:

a) The account holder has left the organisation

or

b) They remain with the organisation but have not accessed the account recently (e.g. within the previous three months).

a a

MMM

MMM

MMM

MMM

MMM

197

Control Specification L M HIA.2.5(Cont.)

The only exception to the purging of dormant accounts should occur when the account has been confirmed as being part of the evidence set related to an Entity or police-led investigation.

The Entity should additionally consider automatically disabling inactive accounts after an Entity-defined period of inactivity.

IA.2.6 Root accounts should never be directly used on information systems. Any activities requiring such access should be conducted via the administrator’s individual account, with elevated privileges assumed (e.g. sudo access in Linux/Unix environments).

IA.2.7 Default accounts provided by suppliers on a new systems or device should be removed as part of the equipment’s commissioning and prior to its connection to the Entity’s network.

IA.2.8 Account access should be disabled if there are multiple unsuccessful log-in accounts made:

a) Consecutively (e.g. three successive attempts)

and

b) Within an a given time period (e.g. six unsuccessful attempts within a twenty-four period)

(The thresholds for these restrictions should be defined by the Entity, on the basis of the sensitivity of its data, the maturity of its information security architecture and its own assessment of risk).

MMM

MMM

MMM

MMM


Control Specification L M HIA.2.9 Unsuccessful account access attempts should be

analysed and root cause analysis undertaken. A substantial number of unsuccessful attempts (either as a long-term trend or as a peak) may be indicative of:

• Unauthorised access attempts/an attempted attack.

• An unrealistically complex password policy that users struggle to comply with.

• The need for improved and additional IT and Information Security training.

IA.2.10 The Entity should consider the deployment of a Single Sign-On (SSO) architecture, to limit the need for users to remember access credentials for a range of different accounts.



HR.6 – End of Employment Security

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 11.2 User access management

• NIST Special Publication 800-53 Revision 3:o AC-2 Account Management

MMM

SSS

199

IA.3 Information System Authentication Version 1.0Suggested Priority

P1

Control Standards

The Entity shall ensure that passwords and tokens granting access to information systems and network devices are protected.


Control Specification L M HIA.3.1 Passwords and/or tokens associated with

information system accounts should not be made available to the user until:

• Their identity has been verified (see IA.1 Identity Management).

• The user has signed a statement confirming (as applicable) that they commit to:

- Keeping the password confidential (including not sharing the password with others and not keeping it in unsecured written form)

- Keeping the token in safe keeping and not sharing it with others

- Abiding by the ‘Acceptable Usage’ provisions contained within the Entity’s Information Security policy and in their Terms & Conditions of Employment (see HR.3 Terms and Conditions of Employment).

a a

MMM


Control Specification L M HIA.3.2 The account ID and the account password should

be communicated via separate channels to the user. (E.g. the account ID being sent by mail, with the password being sent via SMS text message).

To avoid potential interception, passwords should not be sent to users via:

• Electronic mail (especially where the mail will be sent beyond the Entity’s local mail server)

• Communication to another person, such as the user’s colleague

• Fax

• Internal post

IA.3.3 The Entity should define within the Information Security Design the parameters of passwords used on its information systems. This should take into account the sensitivity of the data being manipulated or stored on the information system. However, as a minimum, the Entity’s information systems should enforce a password policy that requires passwords to be:

• At least eight characters long.

• A mixture of letters, numbers and special characters.

• Changed at a frequency determined by the Entity to be appropriate to the sensitivity of the data being accessed.

MMM

MMM

201


(This password change frequency should be defined within a range i.e. the password change being required no more than once every 30 calendar days and not less than every 90 days).

• Not re-used frequently over the life of the user’s information system access. (For example, with the information system mandating that the password not be reused within twelve iterations of the password being changed).

• The Information Owner and individuals users should retain the right, and be afforded the permissions, to change their password more frequently and to apply a greater level of password complexity, than the information system-mandate minimum, if they so choose.

IA.3.4 New and re-enabled accounts should be set with a temporary password that the user is forced to change on the first/next log on to the information system. The temporary password should be unique (i.e. the same temporary password should not be issued to more than one user; and should only be issued to the same user on one occasion) and should not guessable (e.g. passwords such as ‘LetMeIn’, ‘ChangeMe’, ‘Guest1234’ should not be issued to users).

IA.3.5 Passwords must not be stored in plaintext anywhere on information systems and network devices. Any stored password or password database should be held in hashed form.

MMM

MMM

MMM


Control Specification L M HIA.3.6 Information systems should prevent entered

passwords from being displayed on screen to avoid the potential for the password to be seen by non-authorised parties.

IA.3.7 Information systems should require user access to operating systems to be controlled via a secure log-on procedure/secure attention sequence (e.g. Control-Alt-Delete in Windows) to provide for a trusted path between the information system user and the authentication manager within the operation system.

IA.3.8 The Entity should consider the deployment of a password self-service capability, allowing information system users to create and reset passwords themselves on the basis of their ability to verify their identity against previously provided shared secret data.

IA.3.9 The Entity may consider the deployment of biometric authentication mechanisms (e.g. laptops fitted with fingerprint scanners), as an alternative to passwords, where there is a business justification for such.



References • ISO 27002 Information technology — Security techniques — Information Security management systems— Requirements:o 11.2.3 User password management

SSS

SSS

MMM

MMM

203

IA.4 Privilege and Access Management Version 1.0Suggested Priority

P1

Control Standards

The Entity shall ensure that information access and information system privileges are only granted to those with suitable approval.


Control Specification L M HIA.4.1 The Information Owner should approve, in

advance, any requirements for access to information assets. Access should be granted on the basis of a verified need to know. Records of approval should be retained for verification purposes.

IA.4.2 Approval for information access should explicitly state:

• What information is in scope

• What level of access to this information is being granted (i.e. read, write, deleted, execute).

• To whom the access is being granted

• Whether any restrictions apply to the access approval (e.g. it is only for a defined time period)

The level of access granted should not exceed that required to undertake the defined activity.

IA.4.3 Upon a change of roles within the Entity, the user’s level of information access should be reviewed to determine if it remains appropriate. Access types no longer required within the new role should be revoked.

a a

MMM

MMM

MMM


Control Specification L M HIA.4.4 Elevated information system privileges (e.g.

account creation, deletion) should only be granted to nominated information system and network administrators with a defined role and relevant skills, experience and qualifications applicable to the use of those privileges.

IA.4.5 Elevated information system privileges should be considered as a potential source of risk for the Entity. The use of such privileges should be monitored to ensure their use is confined to the original purpose intended and that they are being exercised responsibly.

IA.4.6 All access to Entity information systems should be recorded (see OM.20 System and Network Log Management and Analysis).

IA.4.7 Information systems should display an approved system use notification before granting access. This should inform the user that:

• He or she is accessing an Abu Dhabi information system

• Information system usage may be monitored, recorded and possibly subject to audit

• Access may be revoked at any time, where this is deemed necessary by the Entity

• Access to the information system indicates consent to monitoring and recording

IA.4.8 On a regular basis (at least semi-annually) the Entity should formally review access granted to its information systems and the system privileges allocated, to ensure that they remain relevant to business need. Where changes in business circumstances mean that access or privileges are no longer required, these should be revoked.

MMM

MMM

MMM

MMM

MMM

205

Control Specification L M HIA.4.9 Entity information systems should implement

technical access control policies (that may be identity, role or attribute-based policies) and mechanisms to enforce those policies (e.g. access control lists, access control matrices, cryptography).

The policies and enforcement mechanisms should be employed by the Entity to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the information system.

IA.4.10 The Entity should implement role based access control that defines the level of access required based upon the work to be undertaken by the information system user. This provides greater flexibility in user provisioning and system administration while maintaining a defined level of security.

IA.4.11 Entity network devices should have AAA (Authentication, Authorisation and Accounting) enabled. Configuration of AAA should be made via use of a TACAS + or RADIUS server. Method lists should be defined for the purpose of authentication to the network device and method lists should be applied per network interface.


OM.20 – System and Network Log Management and Analysis


• NIST Special Publication 800-53 Revision 3:o AC-3 Access Enforcement

RRR

RRR

MMM


IA.5 Remote Access Version 1.0Suggested Priority

P2

Control Standards

The Entity shall ensure that remote access to its information systems and networks is controlled.


Control Specification L M HIA.5.1 The Entity should procedurally define which

forms of remote access it permits, which types of devices are permitted to use each form of remote access, the type of access each type of remote access user is granted, and how user account provisioning should be handled. Procedures should also cover how the Entity’s remote access gateways are administered and how policies in those gateways are updated.

IA.5.2 Information Security aspects of the remote access solution design should be documented in an Information Security Design for the remote access service component.

IA.5.3 Before being activated as a production service component, a remote access solution should be tested. The testing should encompass: connectivity, traffic protection, authentication, management, logging, performance, implementation security, and interference with applications.

IA.5.4 Remote access privileges should be formally approved, on the basis of verified business need. Remote access should not be provided by default to all holders of accounts on the Entity’s core network.

IA.5.5 Remote access users should be made aware of, and should be required to document, their understanding of, and intended compliance with, the acceptable usage obligations specific to this service type.

a a

MMM

MMM

MMM

MMM

MMM

207

Control Specification L M HIA.5.6 All remote connections to the Entity’s core

network should be terminated at an Entity-managed remote access gateway, unless the connection is to:

• a publicly available service

• an extranet service for which alternative authentication mechanisms are provided.

No direct remote access connections should be permitted to other parts of the core network.

IA.5.7 All remote access connections should occur via a Virtual Private Network (VPN). The VPN connection should be established using either IPSec or SSL-based capabilities. VPN client software/configurations should only be ones approved and provided by Entity’s IT function.

IA.5.8 Remote access activity logs should be analysed regularly (at least weekly) to identify any potential anomalies or suspicious activities. Particular attention should be paid to time and duration of access, as well as frequency of connection.

IA.5.9 Remote access gateways should only accept one connection per approved user account at any one time.

IA.5.10 Two factor authentication (for example lever-aging elements that include challenge-response security tokens or biometric-based systems) should be used to improve authentication mechanisms for remote access connections. (Security tokens may be hardware or software-based).

MMM

MMM

MMM

MMM

MRR


Control Specification L M HIA.5.11 While connected to the Entity’s core network

via VPN, remote access users should not be authorised to connect to other networks, to avoid the potential for bridging between the networks.

IA.5.12 Remote access provided to third-party suppliers for the purpose of ad-hoc remote support should be monitored and only enabled for the period during which support is being provided. The access should be disabled outside of these periods. Any remote access credentials made available to such suppliers should be provided on the basis that the activities on a remote access account can always be correlated to a named individual within the supplier’s organisation.

IA.5.13 Scheduled maintenance activities on remote access solutions should include: deploying soft-ware updates, verifying clock synchronization, reconfiguring access control features as needed, and detecting and documenting anomalies within the remote access infrastructure.



OM.20 – System and Network Log Management and Analysis

References • ISO/IEC 18028-4 Information technology — Security techniques — IT network security : Part 4: Securing remote access

• NIST Special Publication 800-53 Revision 3:o AC-17 Remote Access

• Special Publication 800-46 Revision 1 ‘Guide To Enterprise Telework and Remote Access Security’

• NIST Special Publication 800-77 ‘Guide to IPsec VPNs’

• NIST Special Publication 800-113 ‘Guide to SSL VPNs’

RRR

MMM

MMM

209

IA.6 Directory Management Version 1.0Suggested Priority

P2

Control Standards

The Entity shall maintain a secure directory of its network assets and users to facilitate access to information assets.


Control Specification L M HIA.6.1 The Entity should deploy and maintain a centrally

managed directory (e.g. Active Directory) for the management of user accounts, the granting of permissions and the moderating of information system access.

IA.6.2 The Entity’s directory should be designed and implemented in a manner that provides flexi-bility to accommodate potential organisational changes. The directory design should seek to ensure that access permissions are not impaired when changes to the directory are necessitated by changes in the organisation (e.g. the breaking of trust relationships between domains and between trees within an Active Directory forest).

IA.6.3 Directory servers should be housed in physically secure data centre locations, conformant with the requirements described in Control Standard PE.4 Data Centre Security of these Standards.

IA.6.4 The Entity should define access and permissions policies on its directory service. Access to data objects should be made only after reference to the relevant directory policy.

IA.6.5 The Entity should monitor activity on its directory servers, with a particular emphasis on ensuring that they have not been compromised and that they are replicating data between themselves in format and at a frequency consistent with their approved design.

a a

MMM

MMM

MMM

MMM

RRR


Control Specification L M HIA.6.6 The Entity’s directory service should inherit the

classification of highest classified information system to which the directory controls access. E.g. if the directory service handles access to ‘Confidential’ information then the directory itself should also be classified as ‘Confidential’.

IA.6.7 Candidate servers requesting permission to join a directory server group should be authenticated, to ensure that it is appropriate for data to be shared with them.

IA.6.8 All communications that involve the trans-mission of authentication credentials or information system access permissions should be subject to strong encryption, end-to-end, from the client device through to the directory database. [See IS.5 Cryptographic Controls]. (Examples of protocols capable of supporting secure communication within directory message exchanges are Secure LDAP and LDAP over SSL).

There should be no communication in plain text of directory-related details applying to subjects, objects and permissions. Communication between directory server peers should also be subject to strong encryption.

IA.6.9 Before directory management responsibilities are delegated (e.g. granting an Information Owner the right to assign access permissions) the Entity should ensure that the party receiving the delegated authority has the resources, skills and work instructions necessary to exercise the delegation responsibly.

MMM

MMM

MMM

RRR

211

Control Specification L M HIA.6.10 Cross domain relationships – both within the

directory and from the directory to other directories – should be documented and validated. Linkage of the directory with other directories should be approved in advance by the Entity’s Information Security Governance Committee.

IA.6.11 The directory should record the classification of data objects and the authorisation level of subjects (i.e. what classification level they are approved to access). The directory should invigilate access requests and approval should be withheld where a subject attempts access of an object at a classification level higher than their approval.

IA.6.12 Access to data concerning the directory service’s design and configuration should be restricted to parties with a legitimate, verified need for such information.



IS.5 Cryptographic Controls


• NIST Special Publication 800-53 Revision 3:o PM-1 INFORMATION SECURITY PROGRAM PLANo SA-1 SYSTEM AND SERVICES ACQUISITION POLICY AND PROCEDURESo SA-3 LIFE CYCLE SUPPORT



SSS

MMM

RRR


IA.7 Connection Management Version 1.0Suggested Priority

P2

Control Standards

The Entity shall monitor connections to its information systems and networks and apply relevant restrictions to those connections.


Control Specification L M HIA.7.1 The Entity should authorise connections from its

information system to other information systems outside of its core network, through the use of Interconnection Security Agreements.

The agreement should, as a minimum, include:

• Which representatives of the involved organisations is approving interconnection of information systems and networks.

• How long the agreement is anticipated to be in place and the mechanism for its review

• Which specific information systems are within the scope of the interconnection and which elements of the participants’ network and information system estate will be visible to each other.

• What communications paths/channels/routes are authorised for the exchange of data between the organisations.

• What protections will be put in place to ensure the confidentiality and integrity of data in transit via the interconnection. (This potentially being described at a high level, with reference made to a detailed supporting Information Security Design).

• How the parties will coordinate changes to their respective infrastructure in a way that will maintain the ability to interconnect.

a a

MMM

213


• What protections the parties will put in place to ensure that they only pass to each other reliable digital content.

IA.7.2 The Entity’s information systems should terminate or lock inactive sessions after a pre-defined period of inactivity.

The amount of time for this should be defined in the Information Security Design. Session time limitations should be informed by a risk assessment. High-risk applications should allow only limited inactivity times, whereas low-risk applications may generally tolerate longer periods of inactivity.

IA.7.3 The Entity shall limit the permitted number of concurrent sessions to information systems and applications.

The limitation on concurrent sessions should be based upon the performance and security baseline defined within the Information Security Design.

IA.7.4 Information systems should only accept one connection per network account at any one time. Where a user logs in from another network location/device, the original connection should automatically be terminated.



References • NIST Special Publication 800-53 Revision 3:o CA-3 Information System Connections

MMM

MMR

RRR

RRR


RRR

12.10 Information Systems Operations Management

OM.1 Operational Procedures and Responsibilities


P1

Control Standards

The Entity shall document and maintain procedures to ensure the correct definition and transaction of its Information Security-related processes.


Control Specification L M HOM.1.1 Procedures should be developed to allow

for the consistent and secure development, introduction, management and retirement of information assets and information systems.

OM.1.2 Procedures should form part on an integrated management system, aligned to Quality Management best practice. Procedures should function in support of agreed policies and should conform to agreed documentation standards active within the Entity.

OM.1.3 Procedures should be aligned with, and conformant to, relevant laws, directives, regulations and government standards. Such external references should be treated as having priority over the procedures; and contradictions should be resolved in favour of the external reference.

OM.1.4 Procedures should be reviewed regularly, to ensure continued relevance and accuracy to the work being undertaken. Review should occur at least annually, or more frequently in the event of major business change.

a

MMM

MMM

MMM

215

Control Specification L M HOM.1.5 Procedures should confirm the minimum

mandatory activities that must be undertaken to achieve a defined outcome.

OM.1.6 The Entity should define the roles required to transact its procedures. Procedures should show which role has primary responsibility for undertaking a given procedural activity.

OM.1.7 Relevant staff and supplier personnel should be made aware of procedures relevant to their Information Security responsibilities and should be trained in their usage.

OM.1.8 The Entity should ensure that responsibilities defined within procedures are suitably allocated between roles, to avoid segregation of duties conflicts.



• TA.4 – Security Training Development and Delivery• HR.4 – Segregation of Duties

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.1.1 Documented operating procedures

MMM

MMM

MMM

MMM


OM.2 Operational Change and Configuration Management


P1

Control Standards

The Entity shall control and document changes to the configuration and status of information assets and information systems.


Control Specification L M HOM.2.1 A multi-disciplinary Change Approval Board

should review and approve proposed changes to information systems. The board’s mandate should be formally defined and sponsored by the Entity’s executive management. The board’s quorum for decision making should be defined by the Entity and the criteria for approval determined in advance. The Entity’s Chief Information Security Officer (CISO) should be a mandatory member of the board and the quorum for approving changes with a potential Information Security impact should include the CISO.

OM.2.2 Changes occurring during the development and operations of information systems should be analysed by the Entity’s CISO for their potential impact on the Information Security Programme Plan.

OM.2.3 The Entity’s CISO should evaluate any Informa-tion Security-related change for its potential impact upon an existing authorisation granted to an information system. Where the change will have a material bearing upon an existing Authority To Operate (ATO) or Interim Authority To Operate (IATO) then the CISO should clarify the scope, benefit, implementation approach and testing method with ADSIC, before giving their approval.

aa a a

RSS

MMR

MMM

217

Control Specification L M HOM.2.4 Changes to information systems should only

be undertaken in accordance with a defined Change Management process and only if subjected to a change impact assessment, with the change being implemented only if approved in advance of the change being implemented. All requirements for change should be documented within a Request For Change (RFC) document.

The RFC should confirm:

• Which party is requesting the change

• What configuration items will be affected by the change

• The nature of the change that will occur

• The anticipated business benefit/driver for the change

• When the change is proposed to occur

• The urgency of the change

• Who will test and who will implement the change

• Who will verify the success of the change

• What impact the change will have upon existing references (e.g. the information system design, relevant policies, contracts)

• Which parties are anticipated to be mandatory approvers of the change

MMM


Control Specification L M HOM.2.5 The approvers of a change should be identified

in advance and their involvement should reflect their role in relation to the target of the change. The Information Owner and/or Information System Owner should be a mandatory approver of any change that has the potential to affect the availability, integrity or confidentiality of their data.

OM.2.6 Changes should be tested before being implemented on production information systems.

OM.2.7 The Entity should maintain Configuration Item Records (CIRs) relating to its information assets and information systems. The CIR should define the asset’s/system’s attributes, including its Information Security categorisation and configuration.

OM.2.8 The Entity should consider holding CIRs in a relational Configuration Management Database (CMDB). The relationship between CIRs should be shown (e.g. parent-child/sibling-sibling) with the view to supporting change impact assessment).

OM.2.9 The Entity should consider the application of pre-approved change types, for changes to information assets and information systems that are regularly transacted, of low risk and which are supported by procedural definition (e.g. user account creation).

Candidates for pre-approval change status should be ratified by the Entity’s Change Approval Board prior to their usage and should only be accepted from approved channels for change request.

MMM

MMM

MMM

SSS

SSS

219

Control Specification L M HOM.2.9(Cont.)

The pre-approval should be of the procedural steps that will be undertaken when the given change type is transacted. ‘Pre-approval’ should not be interpreted as default approval for matters such as authorising access to information systems. The procedural definition of a pre-approved change may include seeking the explicit approval of the Information Owners, as required. Pre-approved change types should have thresholds defined for the number of times that they may be transacted before additional approval is required (e.g. a maximum of fifty new accounts may be added to this information system before additional approval is required).

Where there is desire or need to deviate from the parameters of a pre-approved change type, the modifications should be subjected to review and approval.

OM.2.10 The Entity’s Change Management process should make provision for the application of emergency changes, where justified.

Emergency changes will be ones requiring implementation outside of the normal para-meters of standard operational changes (e.g. to facilitate the fast implementation of a critical security patch). Emergency change provisions should not be invoked for standard changes that could and should have been scheduled, built and tested in advance but were not, due to oversight.

MMM

SSS



The process should make clear what criteria differentiate normal changes from emergency changes. Emergency changes may require streamlined approval or testing, with the view to the rapid implementation of the change. Emergency changes should only be applied on an exceptional basis and the rationale for their use should be fully justified to the Change Approval Board at the earliest available opportunity before or after (but preferably before) the change has been applied.

OM.2.11 Wherever prudent and possible, changes should be grouped and implemented within defined time periods set aside for the implementation of changes (‘change windows’). This should be done with the view to minimising disruption to the availability of production information systems.

OM.2.12 Changes to information systems should be monitored for effectiveness (including on-going compliance to the Entity Information Security Policy and these Standards) at a defined period after the change has been applied.

OM.2.13 The Entity should consider deploying an information system to automate the recording Requests For Change. Entity management should consider the performance metrics required from such an information system.

OM.2.14 The Entity should consider deploying automated mechanisms to detect, and potentially correct, unauthorised changes to information systems.

MMM

SSS

SSS

RRS

MMM

221

Control Specification L M HOM.2.15 The Entity’s Change Management process

should be appropriately integrated with the equivalent processes within third-party supplier organisations, most especially where the Entity’s information system is hosted by the third-party supplier.

OM.2.16 Changes occurring during the development and operations of information systems should be analysed for their potential impact on the Information Security Programme Plan. Reference should be made to ADSIC’s ‘Security Authorisation Terms and Conditions’ document to determine the degree of change that would require the information system to be re-authorised.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.1.2 Change management

• NIST Special Publication 800-53 Revision 3: o CM-1 Configuration Management Policy and Procedureso CM-3 Configuration Change Controlo CM-4 Security Impact Analysiso CM-5 Access Restrictions for Changeo CM-9 Configuration Management Plan

• ADSIC Security Authorisation Terms and Conditions

MMM

MMR


OM.3 Management of Development, Test and Production Facilities


P2

Control Standards

The Entity shall define and manage the boundaries between its development, test and production environments for information systems.


Control Specification L M HOM.3.1 The Entity should define the minimum, distinct

levels of Information Security controls necessary for its development, test and production environments for information systems. Mechanisms should exist to prevent Information Security vulnerabilities from one environment carrying forward to the next. Such mechanisms may include:

• Robust Change Management (see OM.3.2 below)

• Network Access Control Lists (ACLs) restricting information flow between the environments

• Isolating environments from each other where a security incident has occurred within one of them

• Account segregation (where an individual needing access to more than one environment has a different account and different credentials for each environment)

OM.3.2 The movement of information assets and information systems from one environment to another should be controlled by the Entity’s Change Management process. No movement between environments should occur without an approved Request For Change.

a

MMM

MMM

223

Control Specification L M HOM.3.3 Access to information systems should be confined

to the specific duties for which the individual has been authorised. Developers, testers, systems administrators and end users should not have access to information system types that are not required to undertake their specific duties e.g. developers should not typically have access to production information systems.

OM.3.4 Data from one environment should not transit from that environment to another without specific and informed approval from the Information Owner (e.g. test data should typically not be migrated to production information systems).

OM.3.5 The configuration of test information systems should be in alignment with their production information system counterparts, to ensure that test results can be quantified against a known configuration baseline.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.1.4 Separation of development, test, and

operational facilities

• NIST Special Publication 800-53 Revision 3: o CM-2 Baseline Configuration

MMM

MMM

RRR


OM.4 Commissioning of Information Systems and Networks


P2

Control Standards

The Entity shall commission information systems and networks in a manner supportive of their secure operation and management during production.


Control Specification L M HOM.4.1 The Entity should establish procedures and

checklists for the transition of information systems and networks from test to production status. These should define the minimum mandatory requirements the system/network must meet on making the transition to pro-duction status, including Information Security controls, performance requirements and business continuity arrangements.

OM.4.2 Information system and network commissioning activities should be conducted in a manner conformant with, and subsidiary to, the Entity’s Change Management process.

OM.4.3 Information system/network commissioning criteria should be more stringent the higher the information system/network categorisation is.

a

MMM

MMM

MMM

225

Control Specification L M HOM.4.4 The Information System Owner and/or

Information Owner (as applicable) should formally accept the information system/network into production, on the basis of minimum acceptable test outcomes having been achieved, the performance baselines having been established, service readiness having been confirmed, a service level agreement having been negotiated and residual risks having been assessed. The Information System Owner and/or Information Owner (as applicable) should withhold approval unless and until they are satisfied that the information system/network is capable of being operated and managed in a suitably secure manner, consistent with the agreed Information Security Design.



IS.2 Information Security DesignIS.13 Information Systems and Network Security Testing

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.3.2 System acceptance

• NIST Special Publication 800-53 Revision 3: o CA-1 Security Assessment and Authorisation Policies and Procedureso CA-6 Security Authorization

MMM


OM.5 Monitoring of Information System and Network Performance and Usage


P1

Control Standards

The Entity shall establish procedures and tools for monitoring the performance and use of information systems and processing facilities.


Control Specification L M HOM.5.1 The Entity should ensure that information

systems and networks are subject to on-going monitoring. Monitoring attributes may include (but not be confined to) confirming:

• Deviation from an information system performance baseline defined within the Information Security Design.

• Loading on the information system/network (in the context of available capacity).

• Status of Information Security controls.

• Usage of information services by users.

• User and administrator account status (e.g. times of access, locations of access, dormant vs. active accounts).

• Anomalous and suspicious events (including data access outside of the normal pattern of use).

• Potential and actual attacks.

• Potential and actual malicious code distribution.

• Presence of known vulnerabilities.

• Status of security patches within the Entity’s infrastructure.

• Configuration deviation from agreed baselines.

a

MMM

227

Control Specification L M HOM.5.2 The Entity should ensure that its monitoring

data is protected from accidental or intentional corruption or deletion.

OM.5.3 The Entity should ensure that its monitoring data is regularly analysed by qualified personnel, with prioritised and costed recommendations for corrective action and improvement being presented to the organisation’s Information Security Governance Committee.

OM.5.4 The Entity should classify its monitoring data and provide protections appropriate to that level of classification. Sensitive elements of monitoring data should only be made available to those parties with a verified and approved need for access to it.

OM.5.5 The Entity should integrate its monitoring activities with its Information Security Incident Management capabilities, to ensure that appropriately and timely interventions are made on the basis of observed deviations from acceptable information system/network performance and/or usage.

OM.5.6 The Entity should consider automating its monitoring activities and setting alert thresholds for Information Security reporting.

OM.5.7 The use of monitoring data by information system, network and security administrators should be overseen by Entity management to ensure that abuses of access do not occur.

MMM

MMM

MMM

MMM

MMR

RRS


Control Specification L M HOM.5.8 Risk analysis findings should be regularly

reviewed and updated, in light of actual status confirmed via monitoring data.

OM.5.9 Where reliance is placed on monitoring data provided by third-party suppliers, the Entity should independently verify the accuracy of the data on a regular basis. The Entity should also seek to satisfy itself that the data collection method is appropriate to its requirements.



References • NIST Special Publication 800-53 Revision 1 ‘Guide for Applying the Risk Management Framework to Federal Information Systems’

• NIST Special Publication 800-137 ‘Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations’

• NIST Special Publication 800-53 Revision 3:o CA-7 Continuous Monitoring

SSS

MMR

229

OM.6 Anti-Malware Protection Version 2.0Suggested Priority

P1

Control Standards

The Entity shall implement protections against malicious software on its information systems and network devices.


Control Specification L M HOM.6.1 The Entity should implement procedures and

tools for real-time prevention, detection, quarantining and removal of infection caused by malicious software (malware) from its information systems. (Malicious software may include but not be limited to: viruses, spyware, email spam, trojan horses, worms, root kits and adware).

OM.6.2 Anti-malware protections should be deployed on devices at the boundary of the Entity’s network, as well as on internal sensitive network segments (e.g. Data Centre boundary) to limit the potential for infection within the Entity’s core network.

OM.6.3 Anti-malware protections should be deployed on both servers and end-user workstations & laptops inside the Entity’s core network.

OM.6.4 Electronic mail (email) attachments should be automatically scanned and files suspected of malware infection should automatically be quarantined.

OM.6.5 The Entity’s Information Security education and awareness programme should make users aware of the dangers and attack vectors associated with malware and the behaviours supportive of preventing malware infection.

aa

MMM

MMM

MMM

MMM

MMM


Control Specification L M HOM.6.6 The Entity’s service desk function(s) should be

trained to recognise and respond to the attributes of a potential malware infection. Priority should be given to containing the events and avoiding further dissemination of the malware to other network hosts.

OM.6.7 The Entity’s boundary defences should be configured to prevent hosts on the core network from disseminating malware to hosts outside of the core network.

OM.6.8 Information systems should be configured to automatically poll the relevant trusted anti-virus source for updated signature files on a frequent basis. (The Entity may wish to provide a trusted internal server from which signature files are pushed to devices on the core network).

OM.6.9 The Entity should consider sourcing anti malware protection technology from multiple vendors, to support early identification of a malware signature that may not immediately be known to all virus scanning software. Different vendor offerings may be deployed on different information system types (e.g. one product being used for boundary devices and servers, while an alternative is used for workstations).

OM.6.10 If removable media (e.g. DVDs, USB pen drives) is permitted to connect to Entity information systems, the media should be scanned for malware on each occasion that it is connected to the information system.

OM.6.11 The Entity’s IT and security personnel should regularly review anti malware bulletins to ensure their knowledge of actual and potential malware infections remains current.

MMM

MMM

MMM

SSS

RRR

RRR

231

Control Specification L M HOM.6.12 Mobile computing devices connecting to, or

transacting data with, the Entity’s core network should have anti malware protections installed.

OM.6.13 The Entity may consider automatically isolating information systems, devices or network segments that are known to be infected with malware, with the view to prevent further infection.

OM.6.14 The Entity is required to immediately notify ADSIC of any malware infection, with the aim of aiding cross-governmental information sharing and with the view to preventing its further dissemination to other government Entities.

OM.6.15 The Entity’s security metrics and associated reporting should confirm relevant dimensions of anti-malware performance, including:

• Number of malware instances detected, quarantined and destroyed.

• The average age of anti-malware signature files across the information systems estate.

• The number of incidents logged relating to malware and the time taken to resolve them.

• The information systems performance impact of any malware infection (e.g. % increase in round trip delay).

OM.6.16 In the event of a confirmed malware infection that cannot be resolved by anti-virus software’s eradication capabilities (e.g. rootkit detection) the information system should be restored from a gold master system image from the Entity’s definitive software library.

MMM

SSS

SSS

RRR

RRR


Control Specification L M HOM.6.17 The Entity’s information system backup process

should provide for the scanning of backup media and the scanning of files being transferred to the backup media, to avoid malware infections spreading to the Entity’s backups.

OM.6.18 Application, utility and operating system software received from third-parties, whether downloaded via public network, or received via transferrable media (e.g. DVD, USB stick), should be scanned by the Entity for malware. Supply contracts for provision of software and software maintenance (whether off-the-shelf or custom development) should require the supplier to warrant that the software will be malware-free at the point of delivery.

OM.6.19 Supply contracts for the provision of hardware and hardware maintenance services should require the supplier to warrant that the equipment involved and any secondary storage associated with it will be malware-free at the point of delivery/return.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.4.1 Controls against malicious code

• NIST Special Publication 800-53 Revision 3: o SI-3 Malicious Code Protection

RRR

RRR

SSS

233

OM.7 Technical Vulnerability and Patch Management


P1

Control Standards

Timely information about the technical vulnerabilities of information systems and networks shall be obtained, the Entity’s exposure to such vulnerabilities evaluated, and appropriate measures taken to address the associated risk.


Control Specification L M HOM.7.1 The Entity shall maintain a current and complete

inventory of assets (see AM.1 Inventory of Information Assets and AM.6 Physical Asset Management), as a prerequisite of technical vulnerability management. (Specific information needed to support vulnerability management includes: software vendor, version numbers, current state of deployment [e.g. what software is installed on which information systems] and the persons within the Entity responsible for the software).

OM.7.2 The Entity should define the roles and responsibilities associated with technical vulnerability management, including: vulnerability monitoring, vulnerability risk assessment, information system/network device patching, asset tracking and any coordination activities required. The Entity should ensure that resource planning allows for vulnerability assessment and patch management to be prioritised.

OM.7.3 The Entity should develop and resource a plan that addresses its vulnerability and patch management activities. The plan should ensure that a timeline is defined for reacting to notifications of potentially relevant technical vulnerabilities (i.e. how soon after a vendor release of a certain patch type will the Entity implement it?).

aa

MMM

MMM

MMM



The plan should ensure that adequate budget and personnel are available for vulnerability and patch management to be transacted as a foundational capability within the Entity’s Information Security control set.

OM.7.4 Once a potential technical vulnerability has been identified, the Entity should assess the associated risk and the actions to be taken. Such action could involve patching of vulnerable information systems and/or applying other controls.

OM.7.5 If a patch is available, the risks associated with installing the patch should be assessed (the risks posed by the vulnerability should be compared with the risk of installing the patch).

OM.7.6 A patch should be tested and evaluated on a test information system, before it is installed on production information systems – to ensure that it is effective and does not result in side effects that cannot be tolerated.

OM.7.7 If no patch is available, other controls should be considered such as:

• Turning off services or capabilities related to the vulnerability

• Adapting or adding access controls

• Strengthening boundary defences

• Increasing monitoring to detect or prevent actual attacks

• Raising awareness of vulnerabilities

MMM

MMM

MMM

MMM

MMM

235

Control Specification L M HOM.7.8 Security performance metrics and associated

reporting should confirm the average delta between when patches are released and when they are applied.

OM.7.9 Development and test information systems should be patched, as well as production information systems.

OM.7.10 The sources of patches and service packs should be verified and should only be downloaded from known, trusted sources.

OM.7.11 Non-critical patches should be batched and applied during scheduled maintenance windows, to avoid ad-hoc disruption to production information systems.

OM.7.12 The Entity should consider deploying automated vulnerability scanning software relevant to its supported information systems.



AM.1 Inventory of Information AssetsAM.6 Physical Asset Management

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 12.6.1 Control of technical vulnerabilities

• NIST Special Publication 800-53 Revision 3: o RA-5 Vulnerability Scanning

RRS

SSS

SSS

MMM

MMM


OM.8 Information Backup andRestoration


P1

Control Standards

The Entity shall back up information system data and shall have the capabilities necessary for its recovery.


Control Specification L M HOM.8.1 The Information Owner should define their

information backup and restoration requirements prior to the design and implementation of an information system. The agreed attributes for backup and restoration capabilities should be confirmed within the service level agreement applicable to the information system.

OM.8.2 The Entity should conduct backups of user data and information system-level information (e.g. information system configuration files, software images, software licenses, system configuration graphics) in a manner consistent with the Information Security Design.

OM.8.3 Backup media should only be sourced from known, trusted sources and should be confirmed as being free of deficiencies and malware prior to being added to the backup cycle.

OM.8.4 The Entity should consider a 3-2-1 approach to design its backup regime:

• x3 copies of data (1 primary and 2 backups)

• Files should held on at least x2 different types of media (e.g. hard disk and optical drive)

• At least x1 copy of the data should be held off-site

a

MMM

RRR

RRR

RSS

237

Control Specification L M HOM.8.5 Backup media should be uniquely identified

with indelible physical marking to aid effective management of the backup and restoration process.

OM.8.6 The Entity should develop an information systems backup plan confirming:

• When information systems will be backed up

• What data items will be included and excluded within the backup

• What backup type will be used (e.g. full, incremental, differential) on the data concerned

• The anticipated time the backup will take to complete

• What specific, uniquely identified media will be used to complete the backup

• When the media will be taken off-site

• How long the back-up will remain available and when the backup will be destroyed

OM.8.7 The Entity should maintain a backup log confirming the degree to which its backup plan has been met. Where there have been any deviations from the plan (e.g. the backup failed to complete on a given night) the log should confirm the reason for the deviation and the corrective action that will be applied to avoid such a deviation occurring again in future.

MMM

MMM

RRR


Control Specification L M HOM.8.8 The Entity should identify an alternative storage

site for the storage of backup media. The storage site should be geographically separated from the primary storage facility, so as to not be susceptible to the physical and environmental same hazards.

OM.8.9 Whether at the primary data processing facility or the alternate storage site, physical security and environmental controls should be in place which allow for the backup media’s confidentiality, integrity and availability to be maintained (e.g. fire-resistant safes, physical access control).

OM.8.10 The Entity should regularly test its backups to verify media reliability, confirm information integrity and to quantify the likely restoration time required.

OM.8.11 Restoration of data should be coordinated with the Entity Information Systems Continuity Management provisions (see IC.1 Information Systems Continuity Planning Framework).

OM.8.12 The Entity should apply cryptographic mechanisms to protect the confidentiality of backup media.

OM.8.13 The Entity should make use of mechanisms such cryptographic hashes or digital signatures to protect the integrity of backup data.

OM.8.14 Where data is only available in hard/paper copy and not electronically, the Entity should ensure that suitable copies are made and retained in that format.

MRR

MRR

MRS

MMR

MMM

RRR

RRR

239

Control Specification L M HOM.8.15 Whenever possible, information system backup

cycles should be run outside of core hours, to limit impact upon the performance of the information system.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.5.1 Information back-up

• NIST Special Publication 800-34 Revision 1 ‘Contingency Planning Guide for Federal Information Systems,

• NIST Special Publication 800-53 Revision 3: o CP-9 Information System Backupo CP-10 Information System Recovery and Reconstitution

SSS


OM.9 Network Boundary Defence Version 1.0Suggested Priority

P1

Control Standards

The Entity shall define and defend the perimeter(s) of its information networks, with the view to preventing unauthorised acc ess.


Control Specification L M HOM.9.1 The Entity should define a network architecture

that clearly separates internal systems on its core network from Demilitarized Zone (DMZ) and extranet systems.

[DMZ Systems need to communicate with both the core network and public networks. Extranet Systems are those primarily in communication with other information systems at a business partner’s facility].

OM.9.2 Firewalls should be deployed to control the flow of network traffic between the perimeter of the Entity’s core network and any external networks that it connects to.

OM.9.3 Firewalls and/or router Access Control Lists (ACLs) should be deployed to control the flow of network traffic internally within the Entity’s core network, to distinguish between network segments and information systems of different security postures.

OM.9.4 When designing its network architecture, the Entity should consider the type of firewalls (e.g. stateful, application, proxy) necessary for the specific network location, the network traffic type being transmitted and the security requirements of the Information Owner.

a

MMM

MMM

MMM

MMM

241

Control Specification L M HOM.9.5 The Entity should deploy ingress and egress

filtering and Unicast Reverse Path Forwarding on its boundary routers to limit the potential for IP address spoofing.

OM.9.6 The Entity should consider the deployment of anomaly detection and multiverification process (MVP) technologies to detect and limit the impact of Distributed Denial of Service (DDoS) attacks.

OM.9.7 Firewall rule sets should be defaulted to disallowing all access unless and until specifically authorised by the Entity’s Chief Information Security Officer (CISO) on the basis of documented business justification. Services and ports not used by the Entity should not be enabled on the firewall. All changes to firewall configurations, placement and rule sets must be approved via the Entity’s Change Management process.

OM.9.8 All outbound connections to public networks should be via proxy firewalls, with session activity logged and analysed for potential Information Security breaches.

OM.9.9 All inbound connections initiated from public networks, wireless hotspots and mobile devices should arrive to the core network via a firewall.

OM.9.10 Firewalls should be monitored by the Entity’s Intrusion Detection and Prevention Services (IDPS), with the view to identifying if/when a firewall has been compromised.

OM.9.11 The Entity should consider the deployment of multiple firewalls and boundary routers to provide defence-in-depth for the connection between its core network and public networks.

MMM

MMM

MMM

MMM

RRR

RRR

SSS


Control Specification L M HOM.9.12 Where software-based firewalls are used for

boundary protection, the computing devices’ operating system should be hardened and the firewall should be the only application permitted to run on the computing device.

OM.9.13 The Entity should consider blocking all encrypted traffic at the firewall unless the source and destination have been approved for secure communication. The Entity may consider an approach where data is de-encrypted at the firewall and then re-encrypted for onward transmission to the destination.

OM.9.14 The Entity should periodically scan for back channel connections to public networks that seek to bypass boundary defences, including unauthorised VPN connections and dual-homed hosts (connected to both the Entity’s core network and other networks).

OM.9.15 Firewalls, routers and other boundary devices should be prioritised for the application of patches and other vendor software updates, due to their exposure to public networks.



References • SANSo Critical Control 5: Boundary Defence

• NIST Special Publication 800-41 Revision 1: o ES-1 Executive Summary

RRR

RRR

RRR

SSS

243

OM.10 Intrusion Detection and Prevention Version 1.0Suggested Priority

P1

Control Standards

The Entity shall monitor information systems and networks, analysing them for signs of possible violation of computer security policies, acceptable use policies, or standard security practices.


Control Specification L M HOM.10.1 The Entity should deploy an Intrusion Detection

and Prevention System (IDPS) to identify possible security incidents, log information about them, attempt to stop them, and report them to security administrators.

OM.10.2 When designing its security architecture, the Entity should select one or more IDPS solutions that meet the specific needs of its environment and which are relevant to its information asset base and its risk profile.

Main IDPS types include:

Network-Based - monitor network traffic of particular segments or devices and analyse the network and application protocol activity to identify suspicious activity.

Wireless - monitor wireless network traffic and analyse it to identify suspicious activity.

Network Behaviour Analysis (NBA) - examine network traffic to identify threats that generate unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain forms of malware, and policy violations (e.g. a client system providing network services to other systems).

a a

MRR

RRS



Host-Based - monitor the characteristics of a single host and the events occurring within that host for suspicious activity.

Application-Based - monitor the characteristics of specific applications (e.g. Oracle, SQL, MS Exchange).

The Entity should consider the fundamentally different information gathering, logging, detection, and prevention capabilities of each IDPS type and the benefits they offer.

OM.10.3 The components of the IDPS (e.g. sensors/agents, management servers, database servers, user and administrator consoles, and management networks) should have their operating systems and applications kept fully up-to-date, and all software-based IDPS components should be hardened against threats.

OM.10.4 The security of IDPS components should be reviewed on an on-going basis, including verifying that the components are functioning as desired, monitoring the components for security issues, performing regular vulnerability assessments, responding appropriately to vulnerabilities in the IDPS components, and testing and deploying IDPS software updates.

OM.10.5 The response techniques of IDPS technologies (e.g. stopping the attack itself, changing the security environment, changing the attack’s content) should be tested, to ensure that responses do not generate negative or unanticipated consequences.

MRR

MRR

MRR

RRS

245

Control Specification L M HOM.10.6 Where the Entity plans to use multiple types

of IDPS technology, or multiple products of the same IDPS technology type, consideration should be given as to whether or not the IDPS instances should be integrated.

Integration may possibly be achieved through the deployment of a Security Information and Event Management (SIEM) solution.



References • NIST Special Publication 800-94: Guide to Intrusion Detection and Prevention Systems (IDPS)o ES-1 Executive Summary

SSS


OM.11 Information Extrusion Detection and Prevention


P3

Control Standards

The entity shall protect its information assets from leaving its information networks and information systems without approval.


Control Specification L M HOM.11.1 The entity should monitor all outbound network

traffic at egress points (e.g. Internet proxies, email gateways) to:

• Detect anomalies (e.g. large file transfers, long/persistent connections, unusual protocols and ports).

• Identify if information of classification of ‘Confidential’ or above is leaving the organisation without permission.

OM.11.2 The entity should consider deploying an automated tool on its network boundary (i.e. a network-based Data Loss Prevention solution) and on its workstations (i.e. a host-based Data Loss Prevention solution) that monitors for information types defined by the entity e.g.:

• personally identifiable information

• keywords

• other document characteristics

to discover unauthorised attempts to exfiltrate data across network boundaries and block such transfers, while alerting Information Security personnel.

SSS

a a

RRS

247

Control Specification L M HOM.11.3 The entity should consider blocking data of

classification ‘Confidential’ or above from leaving the organisation (via the use of data extrusion prevention technology), unless its transmission has been overtly approved.

OM.11.4 The entity should conduct periodic scans of its servers to determine whether data types of specific interest to the entity (e.g. personal identity, health, credit card, and classified information) are present on the information systems in clear text. (Tools which search for patterns that indicate the presence of such information can help identify if a business or technical process is leaving behind or otherwise leaking such information).

OM.11.5 The entity should identify and isolate any network traffic that has been subjected to cryptographic processing without authorisation.



• IS.6 Information Leakage Prevention

• OM.9 Network Boundary Defence

• IS.10 Network Segregation

• OM.16 Control of Removable Digital Media

References • SANSo Critical Control 15: Data Loss Prevention

• NIST Special Publication 800-53 Revision 3: o SC-7 Boundary Protectiono AC-4 Information Flow Enforcement

SSS

SSS

RSS


OM.12 Network Port, Protocol and Service Protection


P2

Control Standards

The Entity shall control access to network ports, protocols and services.


Control Specification L M HOM.12.1 The Entity should limit network devices to

activating only those ports, protocols and services required to support agreed information services. Unnecessary capabilities of the network device should not be enabled.

OM.12.2 Any changes that enable or disable ports, protocols or services on network devices should be managed under the direction of the Entity’s Change Management process.

OM.12.3 Automated scans of network ports should be conducted by the Entity’s Information Security personnel or approved third party and compared to a known, agreed configuration baseline.If a new port is found open an alert should be generated and reviewed.

OM.12.4 Network services should be reviewed (at least every six months) via the Entity’s Change Management process, to ensure they continue to have business justification. Where network services are enabled for short-term needs (e.g. to support project work) they should be disabled when no longer required.

a a

RRR

MMM

MMM

MMM

249

Control Specification L M HOM.12.5 All in-band (i.e. over the network) or out-of-band

(direct) connections to network device diagnostic ports should be logged and the Entity’s Information Security personnel should review the audit logs for anomalies and/or suspicious activity.



References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 11.4.4 Remote Diagnostic and Configuration Port Protection

• NIST Special Publication 800-53 Revision 3:o AC-3 Access Enforcemento AC-6 Least Privilegeo AC-17 Remote Accesso AC-18 Wireless Accesso PE-3 Physical Access Controlo MA-3 Maintenance Toolso MA-4 Non-Local Maintenance

RRR


OM.13 Secure Software Management Version 1.0Suggested Priority

P3

Control Standards

The Entity shall manage its software assets in a manner supportive of effective security.


Control Specification L M HOM.13.1 The Entity should develop and maintain a

catalogue of approved and supported software (with the catalogue potentially being in the form of a database). It should also maintain details of previously approved software that is now retired. The catalogue should confirm:

• The name of the software

• Its business purpose

• Its version

• The unique identifier applied to the software version

• The software’s system requirements

• Its licensing terms

• Date of security testing

• Approver of security testing

• The status of the software version(s) within the Entity e.g.

- Under development

- Under testing

- In production

- Retired or Replaced

a a

RRR

251


• The date that the software version(s) achieved the given status

• The departments or user communities authorised to use the software

• The device type the software relates to

• The parties responsible for providing first, second and third-level support of the software

• The unique identifiers of previous, related versions of the software

The software types recorded in the catalogue should include:

• Operating Systems

• Middleware

• Applications

• Utilities

The software types may have potential applicability to a variety devices including:

• Mobile devices

• Workstations and laptops

• Servers

• Peripherals (e.g. printers, scanners)

• Network attached storage

• Network devices (e.g. switches, routers, wireless access points)

OM.13.2 The Entity should maintain a Definitive Software Library (DSL) for all entries within its software catalogue. A direct one-to-one correlation should be maintained at all times between the entries in the software catalogue and the entries in the DSL.

RRR

RRR


Control Specification L M HOM.13.3 The DSL should contain security-tested master

images of current and previously approved versions of the software, which may serve as a definitive reference of known and trusted software assets.

OM.13.4 Software images in the DSL should only come from known, trusted sources – either internally developed software that has been subject to security testing, or from verified third-party software developers.

OM.13.5 Software images within the DSL should be write-protected and have their integrity protected via digital signature or cryptographic hashing algorithm.

OM.13.6 Access to the DSL should be logged and the logs analysed by the Entity’s Information Security function.

OM.13.7 Any changes to the software catalogue and the DSL should be approved via the Entities Change Management process. As a minimum, the approver group for such changes should include the Entity’s Information Security Governance Committee and/or the Entity’s Chief Information Security Officer (CISO).

OM.13.8 Access to the DSL should be subject to access control, with only approved network and system administrators having access to add/delete content or to download image copies for installation on information systems and network devices.

RRR

RRR

RRR

RRR

RRR

RRR

253

Control Specification L M HOM.13.9 The Entity should regularly scan (at least

quarterly) its production information systems estate to identify any software that is not shown as having ‘production’ status within its software catalogue. Where deviations are identified, the Entity should investigate the cause with the view to the software being removed or records corrected.

OM.13.10 Where a workstation or Entity-managed mobile device deviates from its agreed software image, the Entity should consider deploying tooling that automatically restores the device to its approved software image when the information system/device initiates a connection to the Entity network.

OM.13.11 The use of software that has the capability of overriding information system and application controls, or bypassing other Information Security controls, shall be restricted and tightly controlled. The use of such software must be approved by the Entity’s Information Security Governance Committee and/or CISO.

OM.13.12 All third-party software should be subject to security testing. The Entity should pay particular attention to the security of open source, freeware and shareware software offerings.

OM.13.13 The Entity should consider restricting work-stations and mobile devices to running without administrative privileges and preventing the downloading/installing of software executables by end users.

RRR

RRR

RRR

RRR

SSS


Control Specification L M HOM.13.14 A back-up of the DSL should be available at the

Entity’s recovery site, to allow for the secure reinstallation of software in the event of a major incident.

OM.13.15 The contents of the DSL should be effectively structured and segregated to avoid potential confusion as regards the target software being accessed and to avoid software images of different types being collocated (i.e. utilities not being stored alongside applications in the storage hierarchy).

OM.13.16 Retired software versions should only be removed from the software catalogue, and correspondingly the DSL, once it has been fully verified that there is no likely further need for access to the software. The Entity should be mindful of its data retention obligations and the potential need to access archived data via legacy software.



• SG.5 Legal and Regulatory Requirements

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 12.5.3 Restrictions on changes to software packages

• NIST Special Publication 800-53 Revision 3: o SA-6 Software Usage Restrictionso SA-7 User-Installed Software

SSS

SSS

SSS

255

OM.14 Electronic Mail Security Version 1.0Suggested Priority

P2

Control Standards

The Entity shall ensure that electronic mail systems and associated messages are protected in a manner appropriate to the information being stored and transmitted.


Control Specification L M HOM.14.1 The Entity should size its electronic mail systems

to provide adequate processing and storage capacity to address current and anticipated future demand.

OM.14.2 The Entity should prohibit the use of electronic mail for the transfer of information of classification ‘Confidential’ or above, unless secure email controls have been implemented (e.g. S/MIME, PGP or AES encryption through tools such as WinZip). Where email encryption is proposed for secure communication, the Entity should ensure that the receiving party has the capability to participate in the secure transaction.

OM.14.3 The Entity should scan inbound and outbound email traffic for:

• Viruses

• Malware

• Spam

• Inappropriate content (as determined by the Entity’s Acceptable Usage provisions)

• Executable code

• Potential data extrusion

The Entity should consider blocking the above traffic types when identified.

a a

RRR

MMM

MMM


Control Specification L M HOM.14.4 All email messages sent by the Entity to outside

parties should contain a footer that confirms the terms under which the message is sent.

OM.14.5 The Entity’s email systems should be backed up and the associated data archived in a manner consistent with:

a) The Service Level Agreement defined for the electronic mail service.

b) The Entity’s data retention obligations.

OM.14.6 Generic email addresses should only be created if a legitimate business need for such has been demonstrated. Generic addresses should be retired once the need is no longer applicable (e.g. the related project or campaign has finished). Mail sent to generic email addresses should always route to one or more accounts that directly correspond to a named user. The use of generic email accounts should be prohibited.

OM.14.7 Users of electronic mail should be educated as to the secure use of such information systems, including:

• Appropriate and inappropriate usage of electronic mail.

• The dangers of mobile code, attached executable files and compressed file attachments.

• The legal consequences of statements made via electronic mail.

RRR

RRR

MMM

MMM

257


• The avoidance of using accounts other than those specifically assigned to the named user.

• The use of secure email provisions (where available) e.g. how to apply encryption to messages.

• The avoidance of forwarding chain messages.

• The avoidance of spam messages.

OM.14.8 The Entity should consider the enhancing of email client software security by disabling:

• Automatic message preview

• Automatic opening of messages

• Automatic loading of pictures in messages

• Downloading and processing of active content

OM.14.9 Email accounts and associated data should not be retained after the named user has left the Entity (other than in the form of a backup of the account and its data being captured). If there is an anticipated need for future access to the data, it should be migrated to an active data source (e.g. forwarded to a current email user, saved as text files etc.)

OM.14.10 Plug-ins intended to augment the functionality of email client software should only be installed by authorised system administrators and should only be sourced from known, trusted sources.

OM.14.11 Web-based access to Entity-provided email services should be only via SSL/TLS encrypted sessions, with a minimum key length of 256 bits.

RRR

RRR

MMM

MMM

SSS




• OM.7-Technical Vulnerability and Patch Management

• IS 3-System and Network Device Hardening

• OM.5 Monitoring of System and Network Performance and Usage

• TA.1-Security Induction

• TA.4-Security Training Development and Delivery

References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 10.8.4 Electronic messaging

• NIST Special Publication 800-45: Guidelines On Electronic Mail Security

259

OM.15 Detection of Authorised and Unauthorised Equipment


P2

Control Standards

The Entity shall restrict access to its core network to only those devices approved for connection.


Control Specification L M HOM.15.1 The Entity should maintain an inventory of

devices and equipment types authorised for connection to its core network.

OM.15.2 The Entity should confirm to information system users which types of equipment are acceptable for connection to its core network and confirm the sanctions that will apply for unauthorised connection.

OM.15.3 Access to network services (e.g. printers, file servers) should only be granted to devices after the user and/or information system has been authenticated.

OM.15.4 The Entity should apply physical address (MAC) filtering on network switches to prevent unauthorised devices from establishing a connection to its core network. Where such a preventive control is not in place, the Entity should consider isolating unauthorised devices from the rest of the network, once discovered.

a a

RRR

MMM

MMM

MMM


Control Specification L M HOM.15.5 The Entity should monitor connections to its

core network. Attempts by unauthorised devices to establish a connection should be identified and investigated. The Entity should consider the deployment of an automated asset inventory discovery tool to confirm the presence of authorised and unauthorised devices.

OM.15.6 Parties wishing to connect currently non-approved devices to the core network should first seek permission of the Entity’s Chief Information Security Officer.

OM.15.7 The Entity should undertake a regular (at least annual) physical audit of its IT equipment, to identify any unauthorised devices.



References • ISO 27002 Information technology — Security techniques — Code of practice for Information Security management: o 11.4.1 Policy on use of network services

RRR

RRR

RRR

261

OM.16 Management of Removable Digital Media


P1

Control Standards

The Entity shall manage and control the use of removable media.


Control Specification L M HOM.16.1 The Entity should have in place procedures that

address the handling of information systems digital removable media. (Digital removable media includes disks, tapes, removable hard drives, USB/flash drives, compact disks and digital video).

Physical and technical security measures for the protection of digital media should be commensurate with the classification or sensitivity of the information residing on the media.

OM.16.2 The Entity should undertake risk assessment to determine the appropriate selection of media for the information type to be contained on that media. The Entity should document and communicate what media and information types require restricted access (e.g. information of a certain classification cannot be stored/ distributed on a given media type).

OM.16.3 The Entity should consider restricting the ability of information systems to write data to removable digital media, where the information type is of classification ‘Confidential’ or above.

OM.16.4 The Entity should consider the use of cryptographic mechanisms to protect and restrict access to information on removable digital media.

a

RRR

RRS

RRS

MMM


Control Specification L M HOM.16.5 The Entity should consider the physical marking

of media (both digital and paper-based) to indicate the information classification of the contents and the restrictions that apply to its usage and its distribution.

OM.16.6 The Entity should control physical access to information systems media to ensure that it can only be accessed by authorised personnel.

OM.16.7 The Entity should ensure that removable media is protected during its transportation. This protection seeking to prevent:

• The media itself from being stolen

• The information held on the media from being accessed/copied/stolen

• The integrity of the data being compromised

OM.16.8 The Entity should maintain a log of removable media which is of specific interest to the Entity (e.g. media used for systems backup) to confirm:

• Its purpose

• The classification of information held on the media

• The media custodian (i.e. the person/team with primary responsibility for its safe keeping)

• Its location

• Its unique identifier (to help distinguish this media from others of the same type)

MRS

MRS

MRS

MRS

263

Control Specification L M HOM.16.9 The Entity should sanitise digital media prior

to disposal, release out of organisational control, or release for reuse. The sanitisation mechanisms should be of a strength and integrity commensurate with the classification or sensitivity of the information.

The Entity should document and verify media sanitisation actions, and periodically test sanitisation equipment/procedures to ensure correct performance. Sanitisation should include:

• Removing all labels, markings, and activity logs

• Degaussing and overwriting memory locations




o 11.4.1 Policy on use of network services

• NIST Special Publication 800-53 Revision 3: o MP-1 Media Protection Policy and Procedureso MP-2 Media Accesso MP-3 Media Markingo MP-4 Media Storageo MP-5 Media Transporto MP-6 Media Sanitizationo PE-16 Delivery and Removal

• NIST Special Publication 800-88: Guidelines For Media Sanitization

MMS


OM.17 Management of Paper Media Version 2.0Suggested Priority

P1

Control Standards

The Entity shall manage and control the use of paper media and the method of its disposal.


Control Specification L M HOM.17.1 The Entity should have in place procedures that

address the handling of paper media applicable to the Entity’s information assets. (Paper media encompasses hand-written information, as well as output from information systems, such as contracts, memos, financial data, reports etc.)

Physical and technical security measures for the protection of paper media should be commensurate with the classification or sensitivity of the information recorded on the paper.

OM.17.2 The Entity should undertake risk assessment to determine the information types that may be recorded on paper media. The Entity should document and communicate what information types can/cannot be recorded on paper and what restrictions should apply to their access and distribution.

OM.17.3 All paper outputs from the Entity’s information systems should carry an information classification label within the document header or footer. The classification should correspond to one of those shown in AM.3 Information Classification.

Where a paper output is missing its information classification label, management and Information Security personnel should assess the content and mark it with what is deemed to be the appropriate classification label.

a a

RRR

RRR

MMM

265


If they are unable to identify the content then they should regard its classification as being ‘Confidential’ unless and until the Information Owner applies an updated classification label.

OM.17.4 Paper materials of classification ‘Confidential’ or above should be disposed of securely. Secure disposal should be achieved via ‘cross-cut’ or ‘crypto-cut’ shredding, with a maximum paper strip width of 2mm (DIN3) or less. [See References].

OM.17.5 Where the Entity has a high volume of paper waste of classification ‘Confidential’ or above, it should consider engaging a specialist third-party provider to remove and shred these materials. To aid compliance with any secure disposal of provisions, the Entity should consider deploying demarcated waste bins for the disposal of such materials.



AM.3 Information Classification

References • DIN 32757-1 Standard

• NIST Special Publication 800-53 Revision 3: o MP-1 Media Protection Policy and Procedureso MP-2 Media Accesso MP-3 Media Markingo MP-4 Media Storageo MP-5 Media Transporto MP-6 Media Sanitization

• Abu Dhabi Government Service Security Categorisation

RRR

MMM

SSS


OM.18 Technical Configuration DefinitionEnforcement


P3

Control Standards

The Entity shall define configuration parameters for its information systems and networks and ensure compliance to them.


Control Specification L M HOM.18.1 The Entity should define technical policies that

information systems and network devices must adhere to in order to support a requisite level of performance and security.

OM.18.2 The Entity should deploy a Network Access Protection (NAP)/Network Admission Control (NAC) capability to detect any deviations from approved information system configurations and to apply automatic remediation.



References

a a

RRR

MMM

267

OM.19 Physical Media in Transit and Off-Site Storage


P2

Control Standards

The Entity shall protect physical media in transit and in off-site storage against unauthorised access, misuse, or corruption when the media is beyond the Entity’s physical boundaries.


Control Specification L M HOM.19.1 The Entity should control information system

media (paper and digital) and restrict the pickup, receipt, transfer, and delivery of such media to only authorised personnel.

OM.19.2 For information of classification ‘Confidential’ or above that is in transit, the Entity should consider deploying cryptographic mechanisms to protect the information’s confidentiality and integrity. Where cryptographic controls cannot be deployed in support of media this classification, compensating controls should be deployed to protect the media in transit e.g.

• Entity staff or trusted couriers should be engaged for the purpose of transporting media.

• Locked containers and tamper-proof seals should limit the potential for access to media and aid detection of unauthorised access.

• Delivery to the recipient should be confirmed within an acceptable time frame from the date and time of dispatch.

OM.19.3 Access to physical media at off-site storage facilities should be restricted to authorised personnel. An inventory of media held at the facility should be kept and a log recording which media was accessed, when, by whom and for what purpose should be maintained.

a a

MMM

MMM

MRS


Control Specification L M HOM.19.4 Environmental controls at off-store facilities

should ensure the continued integrity and availability of physical media. Operating temperatures should be within a range supportive of the media’s preservation in an accessible form.

OM.19.5 On a regular basis (at least annually) the Information Owner should determine if physical media held at off-site storage facilities is still required. The review should take into consideration the Entity’s business needs and its data retention obligations.



References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 9.2.5 Security of Equipment Off-Premiseso 10.8.3 Physical Media in Transit

• NIST Special Publication 800-53 Revision 3:o MP-5 Media Transporto PE-17 Alternate Work Site

MRS

RRS

269

OM.20 Information System and Network Log Management and Analysis


P1

Control Standards

The Entity shall capture log data relating to its information systems. The data shall be analysed for security-related trends and anomalies.


Control Specification L M HOM.20.1 The Information Security Design for the

information system or network device should confirm:

• What attributes of information system activity and access will be logged e.g.:

- User activity (actual and attempted)

- Administrator/super user activity (actual and attempted)

- System utilisation

- System performance

- System error states

• How frequently logs will be updated

• How long log data will be retained for

• Where log data will be stored

• The anticipated storage needed for log data throughout the information system’s lifecycle

OM.20.2 The Entity should consider the potential benefit of a given level of system logging and balance this against the potential impact upon system performance. The Entity may consider applying summarised logging for day-to-day operational purposes but have the ability to move to verbose logging when required to support incident investigations.

a

MMM

RRR



The log should capture sufficient information to, as a minimum, confirm:

• Date and time of the event

• The component of the information system to which the event relates

• The type of the event (e.g. access request, error etc.)

• The identity of the subject involved (e.g. the user requesting access)

• The identity of the object involved (e.g. the

file to which they are requesting access)

• The before and after value of modified data

OM.20.3 The retention period defined for information system logs should be influenced by the Entity’s broader data retention obligations and the possible need to conduct investigations of potential information system attacks and access violations. As a minimum, log data should be retained for at least one month on the live information system, after the date and time of the given system event. It should be available for at least another five months within the log management archive, for potential retrieval.

OM.20.4 Information system logs should be protected from accidental or intentional modification. The Entity should consider writing log data to WORM (Write Once, Read Many) media and/or using cryptographic hashes or digital signatures to provide assurance of log integrity.

RRR

MRS

RRS

271

Control Specification L M HOM.20.5 The confidentiality of information system

logs should be protected via access control mechanisms. Only authorised IT and Information Security personnel should have access to system logs. The access given to such personnel should be ‘read only’. (Information systems alone should be able to create and purge log records).

OM.20.6 The Entity should consider centralising the storage of logs, to aid their protection and analysis.

OM.20.7 The Entity should consider retaining a back-up of system log data at an off-site location, with consideration to the potential for the primary logs to be erased or compromised intentionally or unintentionally.

OM.20.8 On a regular basis (at least annually) the accuracy of log data should be verified by comparison of known, timed events with their corresponding log entries.

OM.20.9 The Entity should ensure that the internal clocks of information systems are synchronised with a common, independent time source to ensure that chronological information within log data can be relied upon.

RRS

RRS

MMM

SSS

RSS


Control Specification L M HOM.20.10 The Entity should regard its information system

log data as a primary source for determining activities relevant to its security posture. Log data should be analysed regularly (at least monthly) to identify:

• System utilisation and performance trends

• Policy and procedure violations

• Access control anomalies

• Signs of potential attack on information systems (whether internally or externally initiated)

OM.20.11 The Entity should consider the deployment of log analysis tooling, to automate the process of reviewing system logs and filtering data of specific relevance and interest.

OM.20.12 The Entity should consider the deployment a Security Information and Event Management (SIEM) tool to provide an aggregated perspective on the security profile of its information systems. The SIEM should be configured to receive information system log data as a primary input and report on attributes of most interest and relevance to the Entity’s Information Security programme.

OM.20.13 On an on-going basis, the Entity should monitor the storage available for information system log data. This should be evaluated against a capacity threshold defined within the information system’s Information Security Design.

RSS

RRS

RRS

MRR

273

Control Specification L M HOM.20.13 (Cont.)

In the event of the log storage capacity being reached, the information system should alert the appropriate Entity officials (e.g. IT department and CISO) and relevant action should be taken e.g.

- Increasing storage capacity

- Over-writing older log entries

- Temporarily suspending logging

When considering such steps, the Entity should consider the risks associated with deviating from its standard log management approach for the system concerned. The suspension of logging should not be undertaken lightly.

OM.20.14 The Entity should integrate its information system monitoring and logging activities with its Incident Management process. The Entity should define, in advance, what activities and thresholds will trigger an alert, to whom and when.

At the start of a major incident’s management lifecycle, the Entity should consider if:

• Adequate monitoring data is available to manage the incident. (If not, it should consider whether additional short-term measures can be taken to improve visibility of the incident).

• The level of information system logging is currently sufficient to support the analysis and management of the incident. (If not, the level of verbosity in the log data should be increased for the duration of the incident management lifecycle).

RSS

RRS



• If logs have been afforded a sufficient level of protection from modification and/or deletion. This being particularly important where an attack is suspected as the potential root cause of the incident. (If logs have not previously been protected, steps should be taken to make write-once copies, while the incident is being contained).



References • ISO 27001 A.10.10.1

• NIST SP 800-53 o AU-1 Audit and Accountability Policy ando Procedureso AU-2 Auditable Eventso AU-3 Content of Audit Recordso AU-4 Audit Storage Capacityo AU-5 Response to Audit Processing Failureso AU-8 Time Stampso AU-11 Audit Record Retentiono AU-12 Audit Generation

• NIST SP 800-92 ‘Guide to Computer Security Log Management’

• NIST SP 800-137 ‘Information Security Continuous Monitoring For Federal Systems’

RSS

275

OM.21 Secure Information Systems Maintenance


P2

Control Standards

Information systems shall be correctly maintained to ensure their continued security.


Control Specification L M HOM.21.1 The Entity should schedule, perform, document,

and review records of maintenance and repairs on information system components, conducted in accordance with manufacturer or vendor specifications and/or organisational requirements.

OM.21.2 Maintenance activities should only occur under the direction and approval of the Entity’s Change Management process.

OM.21.3 The Entity should retain control and oversight of all maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location.

OM.21.4 Removal of an information system or system components from Entity facilities for off-site maintenance or repairs should be explicitly approved by a designated Entity official.

OM.21.5 The Entity should ensure that equipment is sanitised to securely remove all information from associated media, prior to removal from Entity facilities for off-site maintenance or repairs.

a

MMM

MMM

MMM

MMS

MMR


Control Specification L M HOM.21.6 The Entity should check all potentially impacted

security controls to verify that the controls are still functioning properly following maintenance or repair actions.

OM.21.7 The Information Security obligations applicable to third-party maintenance providers should be defined in the Entity’s contract with the supplier and should be monitored for compliance.

OM.21.8 The Entity should establish a process for maintenance personnel authorisation and should manage a current list of authorised maintenance organisations and personnel.

OM.21.9 The Entity should ensure that personnel performing maintenance on the information system have required access authorisations to access its facilities and equipment. Alternatively, it may choose to designate organisational personnel with required authorisations and technical competence to supervise information system maintenance when maintenance personnel do not possess the required access authorisations.

OM.21.10 The Entity should retain the maintenance coverage and/or spare parts necessary for the defined level of information system availability to be maintained, as defined within the relevant Service Level Agreement.

MMM

MRR

MMR

MMR

RRS

277

Control Specification L M HOM.21.11 The Entity should develop and maintain a

plan for undertaking proactive and preventive maintenance, with the view to enhancing information system availability and lessening the need for reactive maintenance.



• OM.16- Control of Removable Media

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 9.2.4

• NIST Special Publication 800-53 Revision 3:o MA-1 System Maintenance Policy and Procedureso MA-5 Media Transport

• NIST Special Publication 800-88 ‘Guidelines For Media Sanitization’

SSS


RRS

OM.22 Secure Disposal and Re-use of Equipment


P2

Control Standards

The Entity shall ensure that the disposal or re-use of equipment is handled in a secure manner.


Control Specification L M HOM.22.1 Equipment shall have all Entity information

cleared/purged from its storage, prior to the equipment’s disposal or re-use. (Equipment requiring such action may not be confined to information systems but may also encompass items such as peripherals).

Re-use may encompass both re-deployment within the Entity as well as its sale or donation to an external party.

Data may be cleared by:

• Overwriting the storage space with data of classification ‘Public’. (This may include overwriting not only the logical storage location of the files(s) but may include all addressable locations).

• For ATA disk drives, the overwriting may be achieved via the firmware ‘Secure Erase’ command.

• Degaussing (i.e. exposing the magnetic media to a strong magnetic field in order to disrupt the recorded magnetic domains. A degausser is a device that generates a magnetic field used to sanitise magnetic media).

OM.21.2 The effectiveness of information clearance/purging activities should be verified to confirm that Entity data does not remain in an accessible form on the equipment.

a a

MMM

279

Control Specification L M HOM.22.3 For information systems hosting information

of classification ‘Confidential’ or above, the Entity may additionally consider subjecting its storage media to secure destruction as part of the information system disposal process. Secure destruction methods include:

• Disintegration

• Incineration

• Pulverization

• Melting

These sanitisation methods are designed to completely destroy the media. They are typically carried out at an outsourced metal destruction or incineration facility with the specific capabilities to perform these activities effectively, securely, and safely.

OM.22.4 Prior to its disposal, any asset tags or other visual references that would allow the equipment to be associated with the Entity should be removed.

OM.22.5 The Entity’s asset records should be updated to confirm:

• The date of the equipment’s disposal or re-allocation.

• Who approved the disposal or re-allocation.

• How it was prepared for reallocation or disposal.

• Where it was disposed of or re-allocated to.



References • NIST Special Publication 800-88 ‘Guidelines For Media Sanitization’

MMM

MMM

MSS


12.11 Information Security Incident Management

IM.1 Information Security Incident Modelling


P2

Control Standards

The Entity shall evaluate the potential types of Information Security incidents that may arise in relation to its information assets.


Control Specification L M HIM.1.1 Prior to the introduction of information assets

and the commissioning of associated information systems, the Entity should seek to model the potential Information Security incidents that may arise in relation to those assets.

Modelling should take as input:

• Entity risk assessment data.

• Information classification and information system and/or service categorisation.

• Vendor data on common incident types.

• Procedures applicable to the information asset’s creation, usage and disposal.

• Procedures applicable to the information system’s design, testing, commissioning and management.

• Configuration diagrams and documentation applicable to the information system.

• The information system’s Information Security Design (including the definition of use cases and the Information Security controls intended to address them).

a

MMM

281

Control Specification L M HIM.1.1(Cont.)

• The Service Level Agreement that applies to the given information system or service and any associated Operating Level Agreements and Third Party Supplier Contracts.

• Records of past changes and incidents applicable to predecessor information system types.

IM.1.2 Modelling should seek to confirm:

• The category of incident that may occur (e.g. virus outbreak, defacement of web site, distributed denial of service).

• The triggers that would give rise to the categories of incident occurring (i.e. what exploit would need to apply to what vulnerability).

• The symptoms that could be anticipated to be associated with the attack (e.g. specific error messages, degradation of information system performance, increased number of information system account lock-outs).

• The factors that might be anticipated to amplify or perpetuate the incident (e.g. lack of network segmentation, lack of information system patching, lack of user awareness of social engineering techniques).

• The key skills that would be needed to identify, diagnose, contain and eradicate the given incident type (e.g. Unix system administration, network architecture, security engineering, incident management).

• The key inputs that would be needed to contain and manage the given incident type (e.g. configuration graphics, Information Security Design, intrusion detection reports).

MMM

MMM


Control Specification L M HIM.1.3 After modelling, incident types should be

ranked using the Abu Dhabi Information Security Risk Management Guide. Potential incidents of highest probability and highest impact should be prioritised for further attention.

IM.1.4 Information Security incident modelling should be repeated whenever there is significant change in:

• The information asset or information system

• The business process and/or organisation it relates to

• The configuration of the information system

• The security control set applied

• The Service Level Agreement associated with the asset or information system



References • NIST Special Publication 800-53 Revision 3:o IR-3 Incident Response Testing and Exercises

• NIST Special Publication 800-61 Revision 1 ‘Computer Security Incident Handling Guide’

• Abu Dhabi Information Security Risk Management Guide

MMM

RRR

283

IM.2 Information Security Incident Management Roles and Responsibilities


P1

Control Standards

The Entity shall define and allocate roles and responsibilities for the management of Information Security incidents.


Control Specification L M HIM.2.1 On the basis of its incident modelling data (see

IM.1 Information Security Incident Modelling), the Entity should define and allocate the roles and responsibilities necessary to manage the most significant Information Security incident types it potentially faces.

The specific configuration of roles and responsibilities may potentially vary, based upon the type of incident, the area of business affected, the technology concerned, the geographical location of assets etc.

IM.2.2 The Entity should ensure that individuals involved in the management of Information Security incidents have the necessary skills, experience, competencies and training to undertake their defined roles.

IM.2.3 The Entity should ensure that the range of Information Security Incident Management roles and responsibilities address, as a minimum:

• Planning and resourcing of Incident Management capabilities.

• Definition of Incident Management policy and procedural content.

• Training of personnel involved in Incident Management.

a

MMM

MMM

MMM



• Testing and verification of Incident Manage-ment capabilities in advance of incidents occurring.

• End-to-end management of the incident response lifecycle.

• Containment of the incident (to limit its potential to increase in impact).

• Technical investigation and analysis of the incident’s symptoms and root cause.

• Communication with key stakeholders.

• Restoration of the information service to pre-incident parameters.

• Recording of key decisions and activities during the incident lifecycle.

• Post incident analysis.

• Application of agreed corrective actions and improvements.

Depending on the size of the organisation a single individual may undertake one or a number of the roles outlined above.

MMM

285

Control Specification L M HIM.2.4 When designing security roles and responsibilities

the Entity should seek to ensure sufficient breadth and depth of skills, while avoiding incident response teams being over-manned. Involvement in incident response should be confined to individuals with a defined, value-adding role that is clearly demarcated from others roles. Involvement of peripheral parties without a key role to play may increase the communication burden and slow down decision-making during critical phases of an incident response.




References • NIST Special Publication 800-53 Revision 3:o IR-2 Incident Response Trainingo IR-3 Incident Response Testing and Exercises


RRR


IM.3 Information Security Incident Management Planning


P2

Control Standards

The Entity shall develop plans and define procedures to ensure a prompt, effective response to Information Security incidents.


Control Specification L M HIM.3.1 The Entity should have a primary orientation

toward the avoidance of Information Security incidents through:

• The effective exercising of information ownership responsibilities

• Prudent administration and stewardship of information systems and networks

• Awareness of the Entity’s risk profile and the application of appropriate controls to avoid, mitigate, transfer or accept those risks

• Regular analysis of and eradication of known vulnerabilities

• Training and awareness of information users

• Design of information systems and networks that are resilient and robust

However much this proactive orientation is embraced, the Entity should anticipate that security incidents can and will arise. It should plan effectively for them to ensure:

• They are promptly recognised when they occur

• Their impact is limited as much as is possible through timely, targeted and effective intervention

a

MMM

287

Control Specification L M HIM.3.2 Based upon its incident modelling data (see IM.1

Information Security Incident Modelling), the Entity should develop an Information Security Incident Management Plan, subsidiary to its Information Security Programme Plan (see SG.1 Information Security Programme Management) that:

• Provides the organisation with a roadmap for implementing its Incident Management capabilities.

• Describes the structure and organisation of the incident response capability.

• Provides a high-level approach for how the Incident Management responsibility fits into the overall organisation.

• Meets the unique requirements of the organisation, which relate to mission, size, structure and functions.

• Defines reportable incidents.

• Provides metrics for measuring the incident response capability, within the Entity.

• Defines the resources and management support needed to effectively maintain and mature the Entity’s incident response capability.

• Is reviewed and approved by the Entity’s Information Security Governance Committee.

IM.3.3 The Entity should coordinate its planning efforts with relevant external parties (e.g. ADSIC, aeCERT) to ensure that proposed Incident Management capabilities are effectively integrated with applicable activities and services in those other organisations.

MMM

MMM



Whenever reviewing its Incident Management plans, the Entity should consider the Incident Management interfaces and notification obligations between itself and such external stakeholders.

IM.3.4 The Entity should develop procedures and incident handling checklists for the incident categories it defined during its incident modelling (see IM.1 Information Security Incident Modelling). The checklists should outline the key activities and responsibilities that should be taken in responding to, containing and eradicating the specific incident type concerned.

For scenarios where a given incident would not map to any other category, a generic incident handling checklist should be provided.

(Checklist-based documentation should be preferred over longer form documentation, to ensure that quick reference can be made to key activities needing to be undertaken during an incident response)

IM.3.5 The Entity should implement mechanisms that would allow both internal information users and also outside parties to report Information Security-related incidents. The Entity should publish telephone and email contact details to allow such incident notifications to be received.

IM.3.6 Access to Incident Management plans, procedures and checklists should be restricted, due to the potentially sensitive nature of an incident. However, plans, procedures and check-lists should be readily available to the Incident Management team from any location where they may reasonably anticipate undertaking incident response activities, including contingency sites.

MMM

MMM

MMM

RRR

289

MMM

Control Specification L M HIM.3.7 The Entity should apply the following

prioritisation framework for determining how finite resources should be deployed to support the management of potentially multiple concurrent Information security incidents.

Priority 1 – Major IncidentSubstantial, possibly wide-ranging, actual or potential damage to the confidentiality, integrity or availability of the Entity’s critical information assets and information systems. (This criticality may be indicated through the business value or the classification of the information/information system). Such incidents will have serious and sustained impact on the organisation’s capability to operate and/or its reputation.

Example: Sustained distributed Denial of Service attack against an Entity with public-facing services.

Priority 2 – Significant IncidentContained actual or potential damage to the confidentiality, integrity or availability of the Entity’s information assets and information systems. Example: unauthorised extrusion of data by a limited number of employees.

Invocation of the Entity’s Information Systems Continuity Management Plan may be a necessary consideration when addressing a Priority 1 or Priority 2 incident.

Priority 3 – Minor IncidentLimited actual or potential damage to the confidentiality, integrity or availability of the Entity’s information assets and information systems. Example: virus or trojan detection on a single work station.



The Entity should anticipate that the priority of an Information Security incident may change during its lifecycle, as more information becomes available, or as the effects of the incident change.

IM.3.8 The Entity should baseline the normal behaviours and performance parameters of information networks, information systems, applications and users and these should be communicated to support staff and incident responders. Familiarity with the expected baseline can help determine a) if an incident is occurring, b) its level of impact and c) the effectiveness of corrective interventions applied.

IM.3.9 The Entity should consider developing and maintaining a central knowledgebase of information. Such can provide a consistent and up-to-date source of relevant information for incident diagnosis and response. The knowledge base may include general information, such as commonly used network port numbers, links to malware information etc., as well as records from previous incidents.

IM.3.10 The Entity should consider developing an incident diagnosis matrix for first responders (e.g. help desk staff, system administrators) and incident response team members. Such a diagnosis matrix can assist personnel in determining what type of incident may be occurring. The matrix may list incident categories and the symptoms associated with each, providing advice as regards what type of incident is occurring, how the diagnosis can be validated and what next steps should be taken.

RRR

SSS

SSS

MMM

291

Control Specification L M HIM.3.11 The Entity should establish and maintain

cooperative relationships between its incident response capability and external providers of information system protection (e.g. Computer Emergency Response Teams). Such relationships may help the Entity remain current with Information Security incident trends and best practice on how to manage incident response.

IM.3.12 The Entity’s executive management should consider giving informed, prior approval to the special permissions and rights that may be required by incident response teams in order to contain or eradicate an incident e.g. reallocation of resources, suspension of services, revoking of access rights.

The incident planning process should ensure that these requests are anticipated and discussed in advance of them being required.




References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 13.2.1 Responsibilities and Procedures

• NIST Special Publication 800-53 Revision 3:o IR-1 Incident Response Policy and Procedures


SSS

SSS


IM.4 Information Security Incident Training and Simulation


P2

Control Standards

The Entity shall train personnel in their incident response roles and responsibilities to ensure response plans can be invoked effectively.


Control Specification L M HIM.4.1 The Entity should train personnel in the scope

and application of their incident response duties. This should include regular simulation of incident response scenarios, as part of an on-going cycle of Information Security Incident Management training.

The Entity should not assume that Information Security incident response plans can be invoked smoothly and without issue. The speed of events, the sometimes contradictory or partial data and the pressures involved during a live incident may contribute to poor decision making and poor plan execution.

IM.4.2 Incident simulations should seek to provide a realistic replication of the attributes of common Information Security incident types in order to prepare incident response capabilities for future events.

IM.4.3 A coordinator independent of the incident response team should be tasked with preparing the necessary scenario data and facilitating incident simulation. The coordinator should also facilitate the capturing, analysis and reporting of lessons learned from the training.

a a

MRR

RRR

RRR

293

Control Specification L M HIM.4.4 Findings and associated improvements from

incident response training and simulations should be fed back into revised Incident Management plans, procedures, training and security appliance configuration.

IM.4.5 The coordinator of the incident simulation should consider substituting members of the incident response team without prior notice, to determine if response capabilities can still be managed effectively if the primary role holder would not to be available.

IM.4.6 Refresher training should be provided regularly (at least annually) to incident response personnel to ensure they remain aware of their responsibilities and that their knowledge of incident management techniques stays current.



IM.3 Information Security Incident Management PlanningTA.4 Security Training Development and Delivery

References • NIST Special Publication 800-53 Revision 3:o IR-2 Incident Response Training

SSS

RRR

RRR


IM.5 Reporting Information Security Weaknesses and Events


P2

Control Standards

The Entity shall require information users and system administrators to report Information Security events and weaknesses.


Control Specification L M HIM.5.1 The Entity should obligate all information

users and information systems administrators (whether employees, contractors or other third parties) to report any observed or suspected Information Security weaknesses or events.

IM.5.2 Information Security awareness campaigns should support the objectives of information users being:

• Able to recognize the attributes of a given type of Information Security weakness or event.

• Informed as to the expected reporting channel for their communication of the weakness or event.

• Aware of the consequences for failing to report relevant weaknesses or security events.



HR.5 Security InductionTA.2 General Awareness Message DeliveryTA.3 Security Training Development

References • NIST Special Publication 800-53 Revision 3:o IR-2 Incident Response Training

a a

MMM

MMM

295

IM.6 Management of Security Incident Response


P2

Control Standards

The Entity shall ensure that Information Security incidents are managed effectively and with an orientation toward learning.


Control Specification L M HIM.6.1 The Entity should ensure that Information

Security incidents are managed by an incident response team that has the requisite empowerment and management support to fully investigate and resolve the matter at hand.

IM.6.2 The incident response team should be protected from time and organisational pressures that could prevent or impede it from conducting an independent and thorough investigation.

IM.6.3 The Information Security incident response should be managed throughout its full lifecycle i.e.:

• Detection

• Analysis

• Containment

• Eradication

• Recovery

• Improvement

IM.6.4 For major Information Security incidents, a single incident manager should be allocated to assume end-to-end responsibility for the incident response. The incident manager should be empowered to direct and re-allocate Entity resources as required to ensure the maximum effectiveness of the incident response capabilities.

a a

MMM

MMM

MMM

RRR


Control Specification L M HIM.6.5 The Entity should align and integrate its

Information Security Incident Management capabilities with its:

a) Information System Continuity Management capabilities

b) Incident Management capabilities applicable to other management disciplines

To ensure that:

• The disciplines are mutually supportive.

• Efforts are not duplicated across the disciplines within the Entity.

• There is a consistent and well understood interface to ensure a clean hand-off between the processes.

IM.6.6 The Entity should coordinate its incident response capabilities with ADSIC and aeCERT (as applicable) when Priority 1 and Priority 2 incidents occur (see IM.3 Information Security Incident Management Planning).

Priority 1 and Priority 2 incidents should be reported immediately to ADSIC upon the Entity recognising them as having this designation.

The Entity should ensure that relevant external stakeholders receive timely and accurate communications on the cause and status of the incident, with the view to limiting potential exposure in other areas of government and to promote cross-functional learning arising from incident occurrence.

MMM

MMM

297

Control Specification L M HIM.6.7 Information Security Incident Managers should

ensure that Information Security incidents are managed in accordance with the Abu Dhabi Information Security Incident Response Checklist.




References • NIST Special Publication 800-53 Revision 3:o IR-4 Incident Handling


• Abu Dhabi Information Security Incident Response Checklist.

MMM


IM.7 Management of Security Evidence Version 2.0Suggested Priority

P2

Control Standards

The Entity shall manage the collection and preservation of Information Security-related evidence conforming to the rules for evidence laid down in the relevant jurisdiction(s).


Control Specification L M HIM.7.1 The Entity should develop internal procedures

to direct the collection, preservation and presentation of Information Security-related evidence. Such evidence having the potential to serve as input to one or more of the following outcomes:

• An internal disciplinary action handled within the Entity

• A criminal investigation undertaken by the police

• A civil action pursued through the courts

IM.7.2 The Entity’s evidence management procedures and practices should demonstrate alignment to the following four distinct phases:

1) Collection. Data is identified and the evidence is labelled in a format that confirms its source, its purpose and its intended storage location. Collection procedures should preserve the integrity of the data. Data should be collected in a timely manner to avoid the loss of dynamic data, such as a list of current network connections, and the data held in mobile devices (e.g. cell phones, smart phones, tablets, PDAs, and other battery-powered devices).

a a

MMM

MMM

299


2) Examination. The data that is collected should be examined using a combination of automated and manual methods to assess and extract data of particular interest for the specific situation, while preserving the integrity of the data.

3) Analysis. The results of the examination should be analysed, using well-documented methods and techniques, to derive useful information that addresses the questions that were the impetus for the collection and examination.

4) Reporting. The results of the analysis should be reported to relevant senior stakeholders. Items to be reported may include: a description of the actions employed; an explanation of how tools and procedures were selected; a determination of any other actions that should be performed, such as forensic examination of additional data sources, securing identified vulnerabilities and recommendations for improvements to policies, guidelines, procedures, tools, and other aspects of the forensic process.

IM.7.3 Personnel involved in the collection, analysis and management of Information Security-related evidence should be trained in the specific skill areas necessary to achieve accurate capture and custodianship of that evidence.

IM.7.4 The integrity of all evidential material should be protected. Any forensics work should only be performed on copies of the evidential material.

No action taken in the collection of evidence should change data held on an information system, or other media, which may subsequently be relied upon in Court.

MMM

MMM

MMM



Copying of evidential material should be supervised by trustworthy personnel and the following data relating to the evidence should be logged:

• What evidence was copied

• When and where the copying process was executed

• Who performed the copying activities

• Which collection methods, tools and programs were utilised

IM.7.5 An audit trail or other record of all processes applied to computer based evidence should be created and preserved. An independent party should be able to examine those processes, assess an exhibit, and achieve the same result.

IM.7.6 Where an Information Security incident investigation identifies the potential need for evidence collection and retention, the Entity should involve a lawyer or the police early in the incident lifecycle and take advice on the evidence required.

IM.7.7 Copies of digital evidence taken from computer disks should be extracted with write blocking capabilities enabled on the target device. Such being to avoid potential modification of the data during the copying process. Captured disk images should be made to sanitised, write-protected or write-once media.

IM.7.8 In exceptional circumstances, where it is necessary to access original data held on an information system that is a target of investigation, the person undertaking the access must be competent to do so and should be able to give evidence explaining the relevance and the implications of their actions.

MMM

MMM

MMM

MMM

MMM

301

Control Specification L M HIM.7.9 Collected evidence should be catalogued and

stored in a secure area. Any movements of evidence into and out of the secure area should be documented and approved by senior Entity personnel.

IM.7.10 Information system and network logs will frequently serve as a primary source of digital evidence. They should be protected in accordance with the guidance described in OM. 20 System and Network Log Management and Analysis.



OM.20 System and Network Log Management and Analysis


References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 13.2.3 Collection of evidence

• NIST Special Publication 800-53 Revision 3:o AU-9 Protection of Audit Informationo IR-4 Incident Handling

• NIST Special Publication 800-86 ‘Guide To Integrating Forensic Techniques Into Incident Response’

• ISO/IEC 27037 — IT Security — Security techniques — Guidelines for identification, collection, acquisition, and preservation of digital evidence (DIS)

• Association of Chief Police Officer (ACPO) ‘Good Practice Guide For Computer-Based Electronic Evidence’

MMM

MMM


IM.8 Post-Incident Analysis, Reporting and Corrective Action


P2

Control Standards

The Entity shall monitor the effectiveness of its Information Security Incident Management capabilities and apply corrective actions as required.


Control Specification L M HIM.8.1 Following Priority 1 and 2 Information Security

incidents, the Entity should undertake formal post-incident review to establish:

• The type of incident that occurred.

• The priority that was assigned to the incident.

• The symptoms of the incident.

• The business impact (financial, reputational and productivity-related) of the incident.

• The cause(s) of the incident.

• The key milestones within the incident lifecycle and when they were reached.

• Whether the incident cause can be correlated to one or more vulnerability that was, or could have been, known by the Entity.

• The key interventions made to contain, diagnose and eradicate the incident and their level of effectiveness.

• The performance of the incident management process and the incident response team.

• The timeliness and quality of data and tools utilised by the incident response team.

a a a

MMM

303


• The cost of the incident response activities.

• The lessons learned and the prioritised corrective action steps and improvements that will be implemented. Corrective actions should be overtly accepted by the control owner and a timeline for when these will be implemented should be agreed.

IM.8.2 Post-incident review should involve those with a direct involvement with the incident – both members of the incident response team and parties impacted by the incident (e.g. business unit representatives).

IM.8.3 The key findings from post-incident reviews should be documented and reported to key stakeholders. Due to the sensitive nature of some Information Security incidents, careful consideration should be given to the appropriate distribution of post-incident reports.

IM.8.4 The Entity’s Information Security Governance Committee should be a mandatory approver of any draft post incident report, before its official release.

IM.8.5 Corrective actions arising from incident reviews should have an orientation toward:

• Improving the Entity’s ability to recognise and treat Information Security-related threats and vulnerabilities, with the view to avoiding such incidents occurring again, in future.

• Implementing process and control improve-ments that would lessen the probability and impact of such an incident.

MMM

MMM

MMM

SSS

RRR



• Improving the quality and transaction speed of the Entity’s Information Security Incident Management process.

• Determining if additional or improved information and tooling would be required to manage such an incident type in future.

• Improving the training and skills of incident responders.

• Determining if existing controls are sufficiently robust, mutually supportive and if sufficient defence-in-depth is demonstrated in the security control set.



References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 13.2.2 Learning from Information Security incidents


SSS

305

12.12 Information Systems Continuity Management

IC.1 Information Systems Continuity Planning Framework


P2

Control Standards

The Entity shall maintain a single framework for information systems continuity planning to ensure consistency in continuity planning and testing.


Control Specification L M HIC.1.1 The Entity should document procedures defining

how information systems continuity activities will be undertaken and by which roles within the organisation. A common method for planning and testing continuity capabilities should apply to all information systems.

IC.1.2 The Entity should develop checklists for:

• The development of continuity plans

• The testing of continuity plans

• The management of continuity-related incidents

(Given the demands that arise when continuity provisions need to be invoked, checklists may provide an effective mechanism for quickly accessing key data).

IC.1.3 The Entity’s Information Systems Continuity Management framework should be integrated with its Information Security Incident Management capabilities, to ensure that continuity provisions can be evoked in an effective and timely manner.

Integration should include consideration of:

• The criteria that would need to be met in order for the Information Systems Continuity Management plan to be invoked.

aa

MMM

SSS

RRR


Control Specification L M HIC.1.3(Cont.)

• Avoiding duplication of effort and roles in Information Systems Continuity Management and Information Security Incident Management.

• The alerting mechanisms required within Information Security Incident Management in order to make relevant stakeholders aware of an actual or potential continuity scenario.

IC.1.4 The Entity’s Information Systems Continuity Management framework should seek to provide for service continuity beyond just addressing disaster recovery scenarios. Preventive controls that would limit the need for a disaster recovery capability needing to be invoked may include:

• Disk mirroring

• Server clustering

• Load balancing

• Parallel processing

IC.1.5 The Entity’s Information Systems Continuity Management framework should be integrated with its Business Continuity capabilities, where such are in effect within the Entity.



References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 14.1.1 Including Information Security in the business

continuity management process

• NIST Special Publication 800-34 Revision 1 ‘Contingency Planning Guide for Federal Information Systems’

RRS

RRR

MMM

307

IC.2 Information Systems Continuity Requirements


P2

Control Standards

The Entity shall capture and analyse requirements for continuity management provisions in support of required and agreed levels of information systems availability.


Control Specification L M HIC.2.1 The Entity should solicit the Information System

Owner’s and Information Owner’s inputs to determine the level of service availability required. This should be confirmed within a Service Level Require-ments document that serves as the primary input to a Service Level Agreement.

Availability requirements should be expressed in terms of:

• Core operating hours during which the information system should be fully available.

• Extended operating hours during which the information system should be either fully or partially available.

• Maximum tolerable planned maintenance outage times in a given period (both in terms of single total outage and cumulative maintenance for the given period).

To address exceptional circumstances (i.e. events that take the service outside of its normal operating parameters), availability requirements should additionally address:

• The Recovery Time Objective (i.e. how quickly the service must be recovered in the event of an exceptional outage).

• The Recovery Point Objective (i.e. the maximum tolerable amount of data that can be lost following an exceptional outage).

a

MMS


Control Specification L M HIC.2.2 Continuity requirements should be validated via

the conducting of a Business Impact Analysis (BIA) that seeks to confirm the anticipated harm that would be caused in the event of the information system being unavailable. (However the ability to conduct such an exercise may be contingent upon the presence and maturity of Business Continuity Management within the Entity).

IC.2.3 Requirements for information systems continuity should be pragmatic (rather than aspirational) and should be mindful of the genuine availability needs for the information being hosted on the information system. Stakeholders should be prompted to consider the cost vs. benefit of continuity provisions when expressing their requirements.

IC.2.4 Information system continuity requirements should be considered in the broader context of the Entity Business Continuity Management framework, where such is in effect.

IC.2.5 Requirements for information systems continuity should be responded to with a set of costed options from which the Information System Owner may chose an optimal solution, on the basis of their business need, the risks presented and the available resources.

RRR

RRR

RRR

RRR

309



IS.1 – Security Requirements

References • ISO 27002 Information technology — Security techniques — Information Security management systems — Requirements:o 14.1.1 Including Information Security in the business

continuity management process

• NIST Special Publication 800-34 Revision 1 ‘Contingency Planning Guide for Federal Information Systems’


IC.3 Information Systems Continuity Plan


P2

Control Standards

The Entity shall develop and maintain information systems continuity plans that define how continuity provisions will be delivered to achieve agreed service recovery parameters.


Control Specification L M HIC.3.1 The Entity’s information system continuity plans

should confirm:

• The assets involved in the composition and support of the target information system.

• The anticipated impact of possible continuity scenarios (e.g. data centre fire, virus outbreak, loss of network connectivity).

• Recovery Point and Recovery Time Objectives for the information system.

• The projected costs to recover the information system vs. the financial impact of its being unavailable.

• The key roles and responsibilities in executing the continuity plan, including which parties may authorise key activities (e.g. deciding to move data processing from the primary facility to the recovery facility).

• The infrastructure and preventive, detective & corrective controls that will be/have been deployed to provide for continuity at the requisite level of information system availability and performance and the current status of these controls.

a a

MRS

311


• How key post-holders will be trained in the Continuity Management responsibilities.

• The essential steps to be taken in relation to information system recovery including:

- Management of the event (via the Incident Management process)

- Containment of the issue

- Recovery of the service (how and where)

- Communication of status to key stakeholders

- Maintenance of data confidentiality and integrity during recovery activities

• The location of essential documentation e.g.

- Information system designs and blueprints

- Third Party Supplier contracts

- Contact lists

• How and when tests against the continuity plan will be conducted.

• How test results will be documented and communicated.

• How invocations of the continuity plan will be recorded, analysed and reported upon.

IC.3.2 The Entity should hold up-to-date copies of its continuity plans at both primary and back-up locations (especially at any designated recovery location).

MRS

MRS


Control Specification L M HIC.3.3 If continuity plans are maintained on a per service

basis, the Entity should consider developing a master continuity plan that has precedence over each of these plans. The master plan will confirm the priority in which information systems should be recovered, in the event that multiple information systems fail at the same time (e.g. following the loss of a data centre).

IC.3.4 Continuity plans should be maintained and should remain current with information system enhancements and organisational changes. Changes to production information systems should evaluated for their potential impact on the continuity plan.

IC.3.5 The continuity plan should be approved prior to the information system moving to production status. Where this does not occur, the Information System Owner should formally document their acceptance of quantified risks associated with there not being continuity provisions in place.



References • NIST Special Publication 800-34 Revision 1 ‘Contingency Planning Guide for Federal Information Systems’

MRS

MRS

SSS

313

IC.4 Testing of Information System Continuity Plans


P2

Control Standards

The Entity shall regularly test and update information system continuity plans to ensure their continued accuracy and effectiveness.


Control Specification L M HIC.4.1 The Entity should conduct tests of its information

systems continuity plans to determine if the recovery targets can be met and if the documented approach to recovery is followed in practice.

Testing should seek to address questions including:

• Can the Recovery Time Objective be met?

• Can the Recovery Point Objective be met?

• Are parties clear on their roles and respon-sibilities and the demarcation between them?

• Do parties exhibit the necessary competencies and aptitudes required to undertake those roles and responsibilities?

• Does the process of recovery contain the minimum number of workflow steps required in order to be effective? (Unnecessary process definition may impede the potential for recovery).

• Are key inputs required by the continuity process (e.g. back-up media, standby equipment, personnel, and documentation) available when required to efficiently implement an information system recovery?

a a

MRS



• Do preventive controls work as anticipated to lessen the potential for information system interruption?

• Do detective controls work as anticipated to identify conditions under which continuity provisions would need to be invoked?

• Do corrective controls work as anticipated to return the information system to a known and required operating state?

• Can the information system be reconstituted in a configuration consistent with it’s a) approved information system & security design and b) its last known approved state, as approved via the Entity’s Change Manage-ment process?

• Is there an effective approach to communica-tion with key stakeholders?

• Is a requisite level of data confidentiality and data integrity maintained during recovery activities?

• Can information systems be recovered in a prioritised way that reflects agreed business criticality?

• Do environmental and telecommunications facilities at recovery sites function as anticipated?

• Can effective supply chain management in support of continuity be demonstrated (e.g. replacement equipment can be delivered within time to compatible recovery targets)

MRS

315

Control Specification L M HIC.4.2 Depending on the criticality of the information

system, continuity tests should be conducted in one of several ways, including:

Tabletop ExercisesDiscussion-based exercises where personnel meet in a classroom setting or in breakout groups to review a) their roles during an emergency and b) their responses to a particular emergency situation.

A facilitator should present a scenario and ask the exercise participants questions related to the scenario, initiating a discussion among the participants regarding roles, responsibilities, coordination, and decision making.

Functional ExercisesAllow personnel to validate their operational readiness for emergencies by performing their continuity-related duties in a simulated operational environment.

Functional exercises are designed to practice the roles and responsibilities of specific team members, procedures, and application of the assets involved in one or more functional aspects of the continuity plan (e.g., communications, emergency notifications, equipment setup).

Functional exercises may vary in complexity and scope, from validating specific aspects of a plan to full-scale exercises that address all plan elements.

MRS


Control Specification L M HIC.4.3 When testing its continuity management

provisions, the Entity should consider substituting key personnel during testing exercises to determine if recovery objectives can still be met in the event of those individuals not being available to undertake their roles.

IC.4.4 Results of continuity testing activities should be documented, analysed and recommendations for improvement should be approved and tracked by the Entity’s Information Security Governance Committee.




References • NIST Special Publication 800-34 Revision 1 ‘Contingency Planning Guide for Federal Information Systems’

SSS

SSS

Appendices

320 Information Security Policies

Appendix A

321

Acronyms ADGE

ADSIC

AVS

CISO

DMZ

DNS

HR

IDS/IPS

IS

ISGC

ISMS

ISO/IEC

IT

NIST

PDCA

SQL

SMTP

SNMP

TCP/IP

UTM

UAE

uRPF

Abu Dhabi Government Entity

Abu Dhabi Systems and Information Centre

Anti-Virus Software

Chief Information Security Officer

Demilitarised Zone

Domain Name System

Human Resources

Intrusion Detection System/Intrusion Prevention System

Information Security

Information Security Governance Committee

Information Security Management Systems

International Organisation for Standardisation/International Electrotechnical Commission

Information Technology

National Institute of Standards & Technology

Plan-Do-Check-Act

Structured Query Language

Simple Mail Transfer Protocol

Simple Network Management Protocol

Transmission Control Protocol/Internet Protocol

Unified Threat Management

United Arab Emirates

Unicast Reverse Path Forwarding

Appendices


Appendix B

323

Definitions Accreditation

Adequate Security

Audit

Availability

Baseline

Confidentiality

Control

Control Specification

Control Standard

Corrective Controls

Cost-Effective Control

Detective Controls

Directive Controls

The official management decision given by a senior Entity official (e.g. chairman) to authorise the operation of a government service and to explicitly accept the risk to Entity operations, assets or individuals based on the implementation of an agreed-upon set of security controls.

Security commensurate with the risk and the magnitude of harm resulting from the loss, misuse or unauthorised access to modification of information.

A formal (independent) review of a project, business process or information system to assess compliance with policy and standards and to determine control adequacy.

Ensuring timely and reliable access to, and use of, information.

The default state for an information system or a control that aligns to it designed and expected operating parameters.

The act of preserving authorised restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

The application of people, process and/or technology in support of transacting business and managing risk. Controls can be technical or managerial in nature.

One or more elements of control implementation specifying how a given control standard may be met.

The security outcome needing to be realised in order to achieve standards compliance and to ensure adequate security.

Contribute to the return of an information asset to its last known good state, with the view to removing a vulnerability, or reducing its potential impact to an acceptable level. (Example controls: information system reimaging to an approved configuration baseline, lessons learned reporting).

A control is judged to be cost effective when the cost of implementing and maintaining it is economical in comparison to the potential impact of the associated risk.

Identity vulnerabilities that either are being exploited, or potentially could be exploited, to realise a threat. (Example controls: system log analysis, network vulnerability scanning).

Express management expectations of behaviours and activities required for risk avoidance and risk mitigation, in support of the Information Security programme. (Example controls: Information Security policy, security-related schedules within third-party supplier contracts).

Appendices


Functional Controls

General User

Information

Information Asset

Information Owner

Information Security

Information Security Design

Information System

The security controls for an information system that are primarily implemented and executed by people (as opposed to technology).

An individual with a standard level of access to an information system (compared to the ‘Privileged User’ defined below). General users will typically be allowed access to information assets in a manner appropriate to the approval given but will not be allowed to substantially reconfigure the information system.

Any communication or representation of knowledge such as facts, data or opinions in any medium or form; including textual, numerical, graphic, cartographic, narrative or audio visual forms.

Any knowledge or data, whether tangible or intangible, that has a value to the organisation, such as information or information systems.

The party (individual or function) with responsibility for the custodianship of a given information asset, on behalf of the Entity. The Information Owner should have clear understanding of what the information asset is, where it is located (physically and/or logically), what business purpose it serves, what risks apply to the information asset, who is authorised to have access to it and what they are permitted to do with it. The Information Owner role will typically be assigned within the business unit holding the primary responsibility for the given category of information assets (e.g. the Financial Department for financial records).

Protection of information and information systems from unauthorised access, use, disclosure, disruption, modification or destruction in order to provide confidentiality, integrity, availability, authentication and non-repudiation.

Formal document that provides an overview of planned security controls for a specific service, correlated to the security services those controls are intended to provide and the requirements they will address.

A discrete set of information resources organised for the collection, processing, maintenance, use, sharing, dissemination or disposal of information, including manual processes or automated processes. This includes information systems used by an entity either directly or used by another entity, or a contractor under a contractor with the entity that: (i) requires the use of such information systems; or (ii) requires the use, to significant extent, of such information systems in the performance of a service or the furnishing of a product. Information systems may generate outputs that are electronic and/or paper-based.

325

Information System Owner

Information Security Event

Information Security Incident

Information Technology

Integrity

IT Assets

Key Security Indicator

Malicious Code

Management Controls

Mitigation

The party (individual or function) with responsibility for the custodianship of a given information system, on behalf of the Entity. The Information System Owner should have clear understanding of the information system’s component elements, what purpose the information system serves, what information assets are resident on the information system, where it is located (physically and/or logically), what risks apply to the information system, who the Information Owner has authorised to access information assets held on it and how it is secured. The Information System Owner responsibility may frequently (but not always) be allocated within the Entity’s IT department.

An identified occurrence of an information system, service or network state indicating possible breach of an Information Security policy, breach of standards, failure of safeguards and/or the introduction of a new vulnerability.

A single or series of unwanted or unexpected Information Security events that have a significant probability of compromising business operations or threatening Information Security.

Any equipment or interconnected information system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data.

The act of guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

Computer equipment and devices (such as servers, workstations, routers etc.) and software.

The most important security metrics that the organisation uses to determine the performance and activity within its Information Security programme.

Software or firmware intended to perform an unauthorised process that will have an adverse impact upon the security of an information system (e.g. virus, worm, Trojan horse or other software code that infects a host).

Security controls that focus on the management of risk and the deployment of finite resources to address the organisation’s security objectives.

One of the main actions that can be taken in relation to risk. Mitigation does not lessen the likelihood of a risk occurring but is intended to lessen its impact when it does.

Appendices


Personally Identifiable Information

Policy

Potential Impact

Preventive Controls

Privacy

Privileged User

‘Production’ Information System

Residual Risk

Risk

Risk Management Interventions

Information that readily identifies an individual (e.g. name, address or other identifying number or code, telephone number, email address etc.)

Expression of management’s intention, direction and expectations in relation to the required posture for a given discipline (in this case Information Security).

The outcome that could occur in the event of a risk being realised. Impact may be felt in a number of ways e.g. financial, reputational, breach of confidentiality, breach of integrity etc. The degree of impact may vary from moderate to high.

Avoid security-related threats from being manifested, or limit their potential to achieve their fullest potential impact. (Example controls: network firewall, segregation of duties, email spam filtering).

The protection of personal data that are being processed and/or stored by the Abu Dhabi government entities.

An individual with an enhanced level of access to an information system, relative to the majority of the user population for that information system e.g. IT system and network administrators who utilise ‘root’ or ‘super user’ privileges in order to manage the information system and makes changes to its configuration.

Information systems transition through a lifecycle of: i) ‘Design’ ii) ‘Development’ iii) ‘Testing’ iv) ‘Production’ and v) ‘Retirement/Replacement’.

Information systems will have ‘Production’ status when being used to access, modify, transmit or store the entity’s business records.

Risk that remains after the implementation of enhancement of a control.

Exposure to danger, harm or loss that may be encountered when a vulnerability is exploited by a threat.

The level of impact on entity services, information assets, or individuals resulting from the potential consequences of a threat and the likelihood of that threat occurring.

The steps taken by an entity in identifying, analysing, responding to and/or monitoring a risk.

327

Recovery Point Objective (RPO)

Recovery Time Objective (RTO)

Security Domain

Spyware

System

Third Party

Third Party Supplier Contract

Threat

Vulnerability

The maximum tolerable period in which data might be lost.

The maximum tolerable outage that can be accepted on an information system.

A collection of associated control standards. Within these Standards the twelve domains of Information Security are those described in section 2.1.3 of the document.

Software that is secretly or surreptitiously installed on an information system.

Interchangeable with ‘Information System’ unless otherwise indicated.

An individual or organisation that is recognised as being independent of the parties involved. In the context of these Standards, the term ‘third party’ will normally refer to third-party (i.e. external) suppliers, unless otherwise stated.

A Contract between an IT Service Provider (i.e. ADGE’s IT function) and a Third Party. The Third Party provides goods or Services that support delivery of an IT Service to a Customer. The Third Party Supplier Contract defines targets and responsibilities that are required to meet the business requirements.

A potential cause of an unwanted incident, which may result in harm to an information system or organisation.

A weakness within an asset, or group of assets, that can be exploited by one or more threats to manifest a risk.

Appendices


Appendix C

329

Classification Matrix

The table below provides examples of the types of impact that a breach of classification would manifest, were data of a given classification level to be compromised.

Appendices

Impact Domain

Secret Confidential Restricted Public

Safety and Security Impact

Major and sustained disruption to the delivery of critical government services. Break down of social cohesion and loss of critical national assets. Risk to human life and personal safety.

Exposure of key government plans and capabilities to respond to national and pan-national threats. Localised or intermittent disruption to government services.

Exposure of minor vulnerabilities in government premises, services, information systems and infrastructure.

Not Applicable

Economic Impact

Government-wide financial loss that has a substantial effect on financial reserves.

Significant financial loss experienced within a single Entity.

Limited financial loss occurring within a single Entity (e.g. within a single department/contract/project)

Not Applicable

Reputation and Confidence Impact

Major harm to the reputation of the government. Profound loss of confidence in the credibility, integrity or competency of government, by the citizenry and international partners.

Limited or intermittent loss of confidence by citizens and other stakeholders in the design and execution of government services.

Minor embarrassment due to limited publication of information concerning the functioning of government.

Not Applicable

Privacy Breach Leakage of sensitive VIP personal data (e.g. properties, travel, health, financial and security protection data).

Compromise of critical personal data relating to citizens, residents and other stakeholders (e.g. financial records, health records).

Compromise of non-critical personal data relating to citizens, residents and other stakeholders (e.g. profile of government service usage).

Not Applicable


Appendix D

331

V1 to V2 Standards Mapping Note: where it is indicated below that there has been no change of control intent from v1 to v2, this should not be taken to mean that there has been no change in the wording of specific clauses. Abu Dhabi Government Entities should take the opportunity to review all elements of the v2 Control Standards. Due to changes made to v1 Control Standards and the addition of new Controls Standards in v2, an Entity compliant with v1 Control Standards should not assume compliance with the v2 counterparts.

Appendices

V1Control ID

V1 Control Name

V2ControlID

V2 Control Name

Description of Change Between the Versions

SP-1.1.101 Strategic Articulation

N/A N/A All Control Standards for which ADSIC had the primary responsibility have been removed in v2.

SP-1.1.201 Information Security Strategy


SP-1.1.301 Information Security Road Map


SP-1.2.101 Information Security Interaction Model


SP-1.2.201 Information Security Processes


SP-1.2.303 Chief Information Security Officer

SG.3 Information Security Organisation

Further elaboration of the security organisation beyond the Chief Information Security Officer is provided in v2.

SP-1.3.103 Security Categorisation


Control focus in v2 is toward reviewing the supporting guide for full details on Categorisation.

SP-1.3.303 Legal Requirements

SG.5 Legal and Regulatory Requirements

No substantial change in the control intent.

SP-1.3.403 Information Security Plan


The primary focus of the v1 control i.e. requirements capture is addressed in the IS.1 Control Standard of v2. However, elements are also addressed in the IS.2 Control Standard.

PS-2.1.101 Government Information Security Policy


PS-2.1.203 Entity Information Security Policy

SG.8 Information Security Policy

More detail has been provided in v2 on areas of expected content in the policy.


V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


PS-2.2.101 Information Security Control Objectives


PS-2.2.201 Information Security Control Standards


PS-2.3.101 Information Security Process Guidance


PS-2.3.201 Information Security Implementation Guidance


RM-3.1.103 Risk Assessment RM.3 Risk Analysis v2 provides more direction on the attributes of risk analysis that needs to be considered.

RM-3.1.203 Risk Treatments RM.4 Risk Response and Treatment

v2 distinguishes been providing a response to a risk and treating it. Not all risks will require treatment (e.g. those that are knowingly accepted).

RM-3.2.104 Security Testing and Evaluation


v2 Control Standard expanded and made more tangible.

RM-3.3.104 Certification and Accreditation


V2 Control Standard focuses on informed acceptance of an Information Security Test Plan as a precursor to information systems authorisation by the designed Entity-level Authorising Official.

RM-3.4.103 On-going Monitoring


Renamed but no substantial change in control intent.

AT-4.1.104 General Awareness Message Delivery

TA.2 General Awareness Message Delivery


AT-4.1.203 Tailored Awareness Messages


Control intent modified from tailored awareness delivery based upon information system/service, to tailored delivery based on responsibilities.

AT-4.2.103 Security Training Curriculum


Training Development and Delivery-related clauses have been combined into a unified v2 Control Standard. A broader scoping has been provided for planning and development of training, beyond just developing curricula.

333

V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


AT-4.2.203 Security Training Delivery



AT-4.2.303 Security Training Records


Requirements for training record keeping subsumed into a broader scoped control relating to the full Information Security Development and Delivery lifecycle.

CO-5.1.104 Tailored Information for Stakeholders


Change of focus from shared ADSIC/Entity responsibility to Entity only.

CO-5.1.204 Message Communication


CO-5.2.104 Communication Requirements

TA.6 Information Security Communications

Control intent has changed to focus exclusively on responsibilities of the Entity in developing its Information Security-related communications approach. The v1 Control Standard focused on collaboration between ADSIC and the Entity in this area.

CO-5.2.204 Communication Facilitation


PM-6.1.101 Pan-Governmental Strategic Metrics and Tools


PM-6.1.201 Strategic Performance Monitoring


PM-6.1.301 Strategic Performance Analysis and Reporting


PM-6.2.104 Entity Programme Metrics and Tools


All Control Standards for which ADSIC had the primary responsibility have been removed in v2.


V1Control ID

V1 Control Name

V2ControlID

V2 ControlName


PM-6.2.203 Entity Programme Performance Monitoring


Specificity has been provided on the process of collecting and managing performance data by Entities.

PM-6.2.304 Entity Programme Performance Analysis and Reporting



PM-6.3.102 Audit Measures and Tools


v1 Control Standard had an orientation towards ADAA responsibilities. v2 provides definitions of the planning and competency expectations applicable in relation to Entity’s own security audit practices.

PM-6.3.202 Audit Execution SG.10 Information Security Audit Framework


PM-6.3.302 Audit Analysis and Reporting



AM-7.1.103 Inventory of Information Assets


More specificity in the v2 Control Standard as to what inventory records should contain and how it should be managed.

AM-7.1.203 Ownership of Information Assets

AM.2 Information Asset Ownership

No substantial change in control intent.

AM-7.1.303 Acceptable Use Policy



AM-7.2.103 Classification of Information


Change in the definition of classification levels to make them more practically applicable.Change in the name of Classification “For Official Use Only” in v1 to “Restricted” in v2.

AM-7.2.203 Information Labelling and Handling

AM.4 Information Labelling and Handling

More specify provided on how assets should be labelled and handled e.g. via the application of multi-part labels.

HR-8.1.103 Roles and Responsibilities



335

V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


HR-8.1.203 Pre-Employment Screening

HR.2 Security Screening


HR-8.1.303 Terms and Conditions of Employment


Control intent extended to address need for different terms and conditions, based upon roles and responsibilities.

HR-8.2.103 Management Roles and Responsibilities


Control intent subsumed into a single Roles and Responsibilities Control Standard (HR.1 Information Security Roles and Responsibilities).

HR-8.2.203 Disciplinary Process

HR.5 Disciplinary Process

The v2 Control Standard gives greater focus to the fair application of the disciplinary process and the learning of lessons from its application.

HR-8.2.303 Screening During Employment

HR.2 Security Screening


HR-8.3.103 Termination Responsibilities


More specificity is provided in the v2 Control Standard on the activities required at the end of the employment period.

HR-8.3.203 Return of Assets HR.6 End of Employment Security


HR-8.3.303 Removal of Access Rights



PE-9.1.103 Physical Security Perimeter

PE.2 Common Physical & Environmental Security Controls

Physical and Environmental Control Standards have been reengineered in v2 in recognition that different types of control will need to be applied in different environments. Three principle divisions have been defined: i) Common Physical and Environmental Controls (that apply to all environments), ii) Workspaces iii) Data Centres and iv) Archive and Storage Facilities.

PE-9.1.203 Physical Entry Controls




V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


PE-9.1.303 Physical Security Monitoring



PE-9.1.403 Secure Offices, Rooms, and Facilities



PE-9.1.503 External and Environmental Threat Protection



PE-9.1.603 Working Area Security

PE.3 Workspace Security


PE-9.1.703 Public Access, Delivery, and Loading Areas Security



337

V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


PE-9.2.103 Equipment Placement and Protection



PE-9.2.203 Supporting Utilities



PE-9.2.303 Cabling Security N/A N/A Control intent is addressed within Physical and Environmental Control Standards

PE-9.2.403 Equipment Maintenance

OM.21 Secure Systems Maintenance

Control intent retained but more detail added to the v2 Control Standard.

PE-9.2.503 Off-Premise Equipment Security



PE-9.2.603 Secure Disposal and Re-Use of Equipment


Information regarding specific methods for secure disposal have been included in the v2 Control Standard.

PE-9.2.703 Removal of Property




V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


CM-10.1.103 Operating Procedures


v2 Control Standard has been made more specific and expanded to encompass control definition applicable to operational responsibilities.



No substantial change in control intent. More specific information provided on the development and management of procedures.

CM-10.1.203 Change Management


v2 Control Standard has been made more specific and practitioner-oriented.

CM-10.1.303 Segregation of Duties

HR.4 Segregation of Duties

The v2 Control Standard requires Entities to weigh the benefits vs. disbenefits of duty segregation, in a specific context.

CM-10.1.403 Separation of Development, Test, and Operational Facilities


v2 Control Standard provides specificity on example mechanisms for segregation of the environments.

CM-10.2.103 Service Delivery TP.3 Security Monitoring and Review of Third Party Services

New Control Standard – v1 had a narrow perspective on third-party supplier security, looked at only in the context of information system acquisition. V2 provides an end-to-end lifecycle orientation to the secure engagement, management and release of products and services from third-party suppliers.

CM-10.2.203 Monitoring and Review of Third Party Services


New Control Standard – v1 had a narrow perspective on third-party supplier security, looked at only in the the context of information system acquisition. V2 provides an end-to-end lifecycle orientation to the secure engagement, management and release of products and services from third-party suppliers.

CM-10.3.103 Capacity Management

IS.2 Security Design Capacity Management have been subsumed into Security Design.

CM-10.3.203 Information System Acceptance

OM.4 Commissioning of Information Systems and Networks

v2 Control Standard focused on the process of commissioning, rather than just acceptance.

339

V1Control ID

V1 Control Name

V2ControlID

V2 ControlName


CM-10.4.103 Malicious Code Protection

OM.6 Anti-Malware Protection

Greater detail and specificity provided in the v2 Control Standard.

CM-10.4.203 Mobile Code Protection

IS.7 Mobile Code Protection


CM-10.5.103 Information Backup

OM.8 Information Backup and Restoration

More specificity provided in v2 Control Standards on backup and restoration.

CM-10.6.103 Network Controls IS.11 Routing, Switching and Network Patching Security

More specific details provided on network security controls.

CM-10.6.203 Security of Network Services



CM-10.7.103 Management of Removable Media


v2 Control Standard provides more specificity on the secure management of removable media.

CM-10.7.203 Disposal of Media OM.16 Management of Removable Digital Media

v2 Control Standard provides more specificity on the secure management of media disposal.

CM-10.7.303 Information Handling Procedures



CM-10.7.403 Security of Information System Documentation


v2 Control Standard provides more specificity on the secure management of information system documentation.

CM-10.8.103 Information Exchange Policies and Procedures


Control intent has been subsumed into the SG.6 Control Standard.

CM-10.8.203 Exchange Agreements


More specificity on the expected content of exchange agreements has been provided in v2.

CM-10.8.303 Physical Media in Transit


v2 control extends the scope of control intent, to cover off-site storage, as well as protecting media in transit.

CM-10.8.403 Electronic Messaging

OM.14 Electronic Mail Security

v2 Control Standard provides greater specificity on the secure management of electronic mail.

CM-10.8.503 Business Information Systems

N/A N/A v1 Control Standards have been retired due to the lack of specify.

CM-10.9.103 Electronic Commerce


CM-10.9.203 Online Transactions



V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


CM-10.9.303 Publicly Available Information


CM-10.10.103 Monitoring Policy and Procedures

OM.5 Monitoring of Information System and Network Performance and Usage

Control Intent is addressed within OM.5 Monitoring of Information System and Network Performance and Usage.

CM-10.10.203 Audit Logging OM.20 Information System and Network Log Management and Analysis

The v2 Control Standard is intended to give a broader and more integrated of view of log management and analysis, in comparison the multi Control Standard approach evident in v1.

CM-10.10.303 Monitoring System Use



CM-10.10.403 Protection of Log Information



CM-10.10.503 Logging of Administrator and Operator Use



CM-10.10.603 Fault Logging OM.20 Information System and Network Log Management and Analysis


CM-10.10.703 Clock Synchronisation



IA-11.1.103 Access Control Policy

IA.4 Privilege and Access Management

Control Intent is addressed with in IA.4 Privilege and Access Management

IA-11.2.103 User Account Management

IA.2 Account Management

v2 Control Standard has a closer focus on account management, with matters relating to access rights and privileges being dealt with within Control Standard IA.3.

IA-11.2.203 User Privilege Management


User Privilege Management have been subsumed into privilege and access management.

341

V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


IA-11.2.303 User Password Management



IA-11.2.403 Review of User Access Rights


Review of User Access Rights have been subsumed into privilege and access management.

IA-11.3.103 Password Use Policy

IA.3 Information System Authentication

Control Intent is addressed with in IA.3 Information System Authentication

IA-11.3.203 Unattended User Equipment



IA-11.3.303 Clear Desk/Clear Screen Policy



IA-11.4.103 Authorised Use of Network Services



IA-11.4.203 User Authentication for External Connections

IA.5 Remote Access Focus of v2 Control Standard expanded to the management of remote access, not simply the authentication of external connections.

IA-11.4.303 Equipment Identification in Networks


v2 Control Standard has a broader focus than its v1 counterpart, seeking to address all unauthorised connections, rather than just those via remote access.

IA-11.4.403 Remote Diagnostic and Configuration Port Protection


The v2 Control Standard provides a sharper focus on port protection, in comparison to the hybrid content of the v1 Control Standard.

IA-11.4.503 Segregation in Networks

IS.10 Network Segregation

More specificity on Network Segregation has been provided in v2.


V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


IA-11.4.603 Network Connection Control


The control intent expressed in the v1 Control Standard has been rendered into more modular and tangible form in v2.

IA-11.4.703 Network Routing Control


More specificity on Routing & Switching Security has been provided in v2.

IA-11.5.103 Secure Logon Procedures



IA-11.5.203 User Identification and Authentication

IA.1 Identity Management

V2 Control Standard has been rewritten for clarity and to provide additional control definition.

IA-11.5.303 Password Management System

IA.3 Information System Authentication

Password management provisions have been subsumed into Information system authentication.

IA-11.5.403 Use of System Utilities

OM.13 Secure Software Management

Scope of the V2 Control Standard broadened, in comparison to itsv1 counterpart. The original Control Standard had a focus just on information system utilities. In contrast, the v2 Control Standard seeks to address the secure management of multiple software types.

IA-11.5.503 Connection/Session Time Restrictions

IA.7 Connection Management

v2 Control Standard provides specificity on areas of expected coverage within connection agreements.

IA-11.5.603 Limitation on Concurrent Sessions



IA-11.6.103 Information Access Restrictions


Access restrictions have been subsumed into privilege and access management.

IA-11.7.103 Mobile Computing and Telecommunications

IS.12 Wireless Network Security

v2 Control Standard focused to wireless security and requirements made more tangible.

IA-11.7.203 Telecommuting IA.5 Remote Access The control intent expressed in the v1 Control Standard has been rendered into more modular and tangible form in v2.

IS-12.1.103 Security Requirements Analysis and Specification


The v2 Control Standard has been focused to specifically address control expectations applicable to Requirements Management.

IS-12.1.201 Configuration Settings Guidelines

IS.3 Information System and Network Device Hardening

v1 Control Standard expressed the expectation of ADSIC defining configuration guidelines. Change of control intent in v2 toward Entities taking the necessary initiative to harden their own information systems.

343

V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


IS-12.1.303 Secure Configuration Settings

IS.3 Information System & Network Device Hardening


IS-12.2.103 Input Data Validation

IS.2 Security Design Input Data Validation have been subsumed into Security Design.

IS-12.2.203 Control of Internal Processing

IS.2 Security Design Control of Internal Processing have been subsumed into Security Design.

IS-12.2.303 Message Integrity IS.2 Security Design Message Integrity have been subsumed into Security Design.

IS-12.2.403 Output Data Validation

IS.2 Security Design Output Data Validation have been subsumed into Security Design.

IS-12.3.103 Cryptographic Controls Policy


Change of control focus in v2 away from the v1 expectation of a Cryptographic Controls policy. Instead, attention is given to

IS-12.4.103 Control of Operational Software

OM.1 Operational Procedures & Responsibilities


IS-12.4.203 Protection of System Test Data


V2 Control Standard has been given a tighter focus on protection of test date, with access control related matters being addressed in Control Standard IS.9.

IS-12.4.303 Source Code Protection

IS.4 Source Code Protection


IS-12.5.103 Change Control Procedures

OM.2 Operational Change & Configuration Management


IS-12.5.203 Technical Review of Applications After Operating System Changes



IS-12.5.303 Restrictions on Changes to Software Packages



IS-12.5.403 Information Leakage

IS.6 Information Leakage Prevention


IS-12.5.503 Outsourced Software Development




V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


IM-13.1.104 Reporting Information Security Events


The v1 Control Standard was oriented toward the Entity reporting incident events to ADSIC. The v2 Control Standard is oriented toward users reporting the attributes of actual and potential incidents to the Entity.

IM-13.1.203 Reporting Information Security Weaknesses



IM-13.2.104 Responsibilities and Procedures


More specificity is provided in the v2 Control Standard regarding the type of Incident Management roles that need to be considered by the Entity.



New Control Standard – The v2 Control Standard has a much broader scope, addressing multiple dimensions of planning the Entity’s Information Security Incident Management capabilities, beyond just the production of procedures.

IM-13.2.203 Contact with Special Interest Groups

TA.5 Contact With Special Interest Groups

Control Standard moved from the ‘Information Security Incident Management’ section in v1 to the ‘Awareness and Training section of v2. This reflects the need for Entities to engage with external interests groups for areas of shared interest beyond just incident management.

IM-13.2.303 Learn from Information Security Incidents


The v2 Control Standard provides specificity regarding the type of incident data that should be captured and reported upon.




IM-13.2.403 Evidence Collection

IM.7 Management of Security Evidence

The v1 Control Standard provided a general statement regarding the need for evidence collection and retention. The v2 Control Standard provides more specific and detailed information on Evidence Management.

345

V1Control ID

V1 Control Name

V2ControlID

V2 Control Name


BC-14.1.103 Information Security in Business Continuity


The control intent expressed in the v1 Control Standard has been rendered into more modular focusing on the information system continuity and tangible form in v2.

BC-14.1.203 Business Continuity Planning and Risk Assessment


The v2 Control Standard provides specificity regarding the information expected to be confirmed within a continuity plan.

BC-14.1.303 Business Continuity Plans



BC-14.1.403 Business Continuity Planning Framework


Continuity Management in v2 has been re-scoped from Business Continuity Management to Information Security Continuity Management.

BC-14.1.503 Testing and Re-assessing Business Continuity Planning

IC.4 Testing of Information System Continuity Plans

The v2 Control Standard provides specificity regarding a) the type of testing that may be conducted and b) the key questions that testing should seek to provide answers to.


Appendix E

347

V2 to V1 Standards Mapping Note: where it is indicated below that there has been no change of control intent from v1 to v2, this should not be taken to mean that there has been no change in the wording of specific clauses. Abu Dhabi Government Entities should take the opportunity to review all elements of the v2 Control Standards. Due to changes made to v1 Control Standards and the addition of new Controls Standards in v2, an Entity compliant with v1 Control Standards should not assume compliance with the v2 counterparts.

V2Control ID

V2 Control Name

V1ControlID

V1 Control Name



N/A N/A New Control Standard - This version of the Standards gives greater attention to the Entity having a programmatic structure for Information Security.


SP-1.3.103 Security Categorisation

Control focus in v2 is toward reviewing the supporting guide for full details on Categorisation.

SG.3 Information Security Organisation

SP-1.2.303 Chief Information Security Officer

Further elaboration of the security organisation beyond the Chief Information Security Officer is provided in v2.

SG.4 Security Programme Change Management

N/A N/A v1 controls relating to change management had an exclusive focus on operational change. This control is concerned with changes to Entity’s Information Security Programme.

SG.5 Legal and Regulatory Requirements

SP-1.3.303 Legal Requirements



CM-10.8.203 Exchange Agreements

More specificity on the expected content of exchange agreements has been provided in v2.


CM-10.8.103 Information Exchange Policies and Procedures

Control intent has been subsumed into the SG.6 Control Standard.

SG.7 Enterprise Architecture

N/A N/A New Control Standard - This version of the Standards expresses the need to integrate Information Security with the Enterprise Architecture, where the latter is active within the Entity.

SG.8 Information Security Policy

PS-2.1.203 Entity Information Security Policy

More detail has been provided in v2 on areas of expected content in the policy.


PM-6.2.104 Entity Programme Metrics and Tools



V2Control ID

V2 Control Name

V1ControlID

V1 Control Name



PM-6.2.203 Entity Programme Performance Monitoring

Specificity has been provided on the process of collecting and managing performance data by Entities.


PM-6.2.304 Entity Programme Performance Analysis and Reporting



PM-6.3.102 Audit Measures and Tools



PM-6.3.202 Audit Execution v1 Control Standard had an orientation towards ADAA responsibilities. v2 provides definitions of the planning and competency expectations applicable in relation to Entity’s own security audit practices.


PM-6.3.302 Audit Analysis and Reporting


SG.11 Common Control Catalogue

N/A N/A New Control Standard – v2 requires Entities to identify and manage controls that applies to multiple information systems, in a holistic way.

RM.1 Risk Management Planning

N/A N/A New Control Standard – A life cycle orientation has been given to the Risk Management section of v2. This Control Standard recognises the need for planning at the outset of the Risk Management process.

RM.2 Risk Identification N/A N/A New Control Standard – A life cycle orientation has been given to the Risk Management section of v2. In v1 Risk Identification was not sufficiently delineated from Risk Assessment.

RM.3 Risk Analysis RM-3.1.103 Risk Assessment v2 provides more direction on the attributes of risk analysis that needs to be considered.

RM.4 Risk Response and Treatment

RM-3.1.203 Risk Treatments v2 distinguishes been providing a response to a risk and treating it. Not all risks will require treatment (e.g. those that are knowingly accepted).

349

V2Control ID

V2Control Name

V1ControlID

V1 Control Name



RM-3.4.103 On-going Monitoring

Renamed but no substantial change in control intent.


HR-8.1.103 Roles and Responsibilities



HR-8.2.103 Management Roles and Responsibilities

Control intent subsumed into a single Roles and Responsibilities Control Standard (HR.1 Information Security Roles and Responsibilities).

HR.2 Security Screening HR-8.1.203 Pre-Employment Screening

Control intent extended to address the potential need for re-screening during the period of employment.

HR.2 Security Screening HR-8.2.303 Screening During Employment



HR-8.1.303 Terms and Conditions of Employment

Control intent extended to address need for different terms and conditions, based upon roles and responsibilities.


AM-7.1.303 Acceptable Use Policy


HR.4 Segregation of Duties

CM-10.1.303 Segregation of Duties

The v2 Control Standard requires Entities to weigh the benefits vs. disbenefits of duty segregation, in a specific context.

HR.5 Disciplinary Process

HR-8.2.203 Disciplinary Process

The v2 Control Standard gives greater focus to the fair application of the disciplinary process and the learning of lessons from its application.


HR-8.3.103 Termination Responsibilities



HR-8.3.203 Return of Assets More specificity is provided in the v2 Control Standard on the activities required at the end of the employment period.


HR-8.3.303 Removal of Access Rights


TP.1 Security-Oriented Supplier Selection

N/A N/A New Control Standard – v1 had a narrow perspective on third-party supplier security, looked at only in the context of information system acquisition. V2 provides an end-to-end lifecycle orientation to the secure engagement, management and release of products and services from third-party suppliers.


V2Control ID

V2 Control Name

V1ControlID

V1 Control Name



IS-12.5.503 Outsourced Software Development



CM-10.2.103 Service Delivery New Control Standard – v1 had a narrow perspective on third-party supplier security, looked at only in the context of information system acquisition. V2 provides an end-to-end lifecycle orientation to the secure engagement, management and release of products and services from third-party suppliers.


CM-10.2.203 Monitoring and Review of Third Party Services


TP.4 Security-Oriented Contract Termination and Renegotiation

N/A N/A New Control Standard – v1 had a narrow perspective on third-party supplier security, looked at only in the context of information system acquisition. V2 provides an end-to-end lifecycle orientation to the secure engagement, management and release of products and services from third-party suppliers.

TA.1 Security Induction N/A N/A New Control Standard – a requirement for information users to be inducted into the Information Security process at the start of their engagement with the Entity was not a feature of the v1 ‘Awareness and Training’ section.

TA.2 General Awareness Message Delivery

AT-4.1.104 General Awareness Message Delivery



AT-4.1.203 Tailored Awareness Messages

Control intent modified from tailored awareness delivery based upon information system/service, to tailored delivery based on responsibilities.


CO-5.1.104 Tailored Information for Stakeholders

Change of focus from shared ADSIC/Entity responsibility to Entity only.

351

V2Control ID

V2 Control Name

V1ControlID

V1 Control Name



AT-4.2.103 Security Training Curriculum



AT-4.2.203 Security Training Delivery



AT-4.2.303 Security Training Records

Requirements for training record keeping subsumed into a broader scoped control relating to the full Information Security Development and Delivery lifecycle.

TA.5 Contact With Special Interest Groups

IM-13.2.203 Contact with Special Interest Groups

Control Standard moved from the ‘Information Security Incident Management’ section in v1 to the ‘Awareness and Training section of v2. This reflects the need for Entities to engage with external interests groups for areas of shared interest beyond just incident management.

TA.6

Information Security Communications

CO-5.2.104 Communication Requirements

Control intent has changed to focus exclusively on responsibilities of the Entity in developing its Information Security-related communications approach. The v1 Control Standard focused on collaboration between ADSIC and the Entity in this area.


AM-7.1.103 Inventory of Information Assets

More specificity in the v2 Control Standard as to what inventory records should contain and how it should be managed.

AM.2 Information Asset Ownership

AM-7.1.203 Ownership of Information Assets



AM-7.2.103 Classification of Information

Change in the definition of classification levels to make them more practically applicable.

Change in the name of Classification “For Official Use Only” in v1 to “Restricted” in v2.


CM-10.7.403 Security of Information System Documentation

v2 Control Standard provides more specificity on the secure management of information system documentation.


V2Control ID

V2Control Name

V1ControlID

V1Control Name


AM.4 Information Labelling and Handling

AM-7.2.203 Information Labelling and Handling

More specify provided on how assets should be labelled and handled e.g. via the application of multi-part labels.

AM.5 Information Management and Retention

N/A N/A Retention and information lifecycle management not addressed in a specific v1 control.

AM.6 Physical Asset Management

N/A N/A New Control Standard – v2 provides delineation between the inventory management of information assets (AM.1) and the same for physical assets (AM.6).

PE.1 Physical and Environmental Security Planning

N/A N/A New Control Standard – the need to plan for the deployment of physical and environmental controls was not included in v1.


PE-9.2.203 Supporting Utilities



PE-9.1.303 Physical Security Monitoring



PE-9.2.503 Off-Premise Equipment Security


353

V2Control ID

V2ControlName

V1ControlID

V1Control Name



PE-9.1.103 Physical Security Perimeter



PE-9.1.203 Physical Entry Controls



PE-9.1.403 Secure Offices, Rooms, and Facilities



PE-9.1.503 External and Environmental Threat Protection



PE-9.1.703 Public Access, Delivery, and Loading Areas Security



V2Control ID

V2 Control Name

V1ControlID

V1 Control Name



PE-9.2.103 Equipment Placement and Protection



PE-9.2.703 Removal of Property



IA-11.3.203 Unattended User Equipment



IA-11.3.303 Clear Desk/Clear Screen Policy



PE-9.1.603 Working Area Security


355

V2Control ID

V2ControlName

V1ControlID

V1Control Name


PE.4 Data Centre Security

N/A N/A Physical and Environmental Control Standards have been reengineered in v2 in recognition that different types of control will need to be applied in different environments. Three principle divisions have been defined: i) Common Physical and Environmental Controls (that apply to all environments), ii) Workspaces iii) Data Centres and iv) Archive and Storage Facilities.

PE.5 Archive and Storage Facility Security

N/A N/A Physical and Environmental Control Standards have been reengineered in v2 in recognition that different types of control will need to be applied in different environments. Three principle divisions have been defined: i) Common Physical and Environmental Controls (that apply to all environments), ii) Workspaces iii) Data Centres and iv) Archive and Storage Facilities.


IS-12.1.103 Security Requirements Analysis and Specification

The v2 Control Standard has been focused to specifically address control expectations applicable to Requirements Management.


SP-1.3.403 Information Security Plan

The primary focus of the v1 control i.e. requirements capture is addressed in the IS.1 Control Standard of v2. However, elements are also addressed in the IS.2 Control Standard.


N/A N/A New Control Standard – v2 places an emphasis upon a clear expression of Information Security requirements (Control Standard IS.1), complemented by a structured design to address those requirements (Control Standard IS.2). The Information Security Design replaces the v1 concept of an ‘Information Security Plan’ as the definitive reference for the security controls applicable to a given information system.


V2Control ID

V2ControlName

V1ControlID

V1Control Name



IS-12.2.103 Input Data Validation

Input Data Validation have been subsumed into Security Design.


IS-12.2.203 Control of Internal Processing

Control of Internal Processing have been subsumed into Security Design.


IS-12.2.303 Message Integrity

Message Integrity have been subsumed into Security Design.


IS-12.2.403 Output Data Validation

Output Data Validation have been subsumed into Security Design.


CM-10.3.103 Capacity Management

Capacity Management have been subsumed into Security Design.

IS.3 System and Network Device Hardening

IS-12.1.201 Configuration Settings Guidelines

v1 Control Standard expressed the expectation of ADSIC defining configuration guidelines. Change of control intent in v2 toward Entities taking the necessary initiative to harden their own information systems.

IS.3 System and Network Device Hardening

IS-12.1.303 Secure Configuration Settings


IS.4 Source Code Protection

IS-12.4.303 Source Code Protection



IS-12.3.103 Cryptographic Controls Policy

Change of control focus in v2 away from the v1 expectation of a Cryptographic Controls policy. Instead, attention is given to

IS.6 Information Leakage Prevention

IS-12.5.403 Information Leakage


IS.7 Mobile Code Protection

CM-10.4.203 Mobile Code Protection


IS.8 Security Appliance and Security Software Design

N/A N/A New Control Standard – due to their profile of usage and sensitivity, control expectations specific to the implementation and testing of security appliances and software have been provided in v2.

IS.9 Management of Development and Test Access

N/A N/A New Control Standard – the attributes specific and different to managing access during information system development (as opposed to on-going, production-status access) were not addressed in a clearly delineated control in v1.


IA-11.4.603 Network Connection Control


357

V2Control ID

V2 Control Name

V1ControlID

V1Control Name



IA-11.4.503 Segregation in Networks

More specificity on Network Segregation has been provided in v2.

IS.11

Routing, Switching and Network Patching Security

CM-10.6.103 Network Controls



CM-10.6.203 Security of Network Services



IA-11.4.703 Network Routing Control

More specificity on Routing & Switching Security has been provided in v2.

IS.12 Wireless Network Security

IA-11.7.103 Mobile Computing and Telecommunications

v2 Control Standard focused to wireless security and requirements made more tangible.


RM-3.2.104 Security Testing and Evaluation

v2 Control Standard expanded and made more tangible.


RM-3.3.104 Certification and Accreditation

V2 Control Standard focuses on informed acceptance of an Information Security Test Plan as a precursor to information systems authorisation by the designed Entity-level Authorising Official.

IS.14 Domain Name Service Security

N/A N/A New Control Standard – no v1 Control Standard addressed securing the Entity’s DNS infrastructure.


IS-12.4.203 Protection of Information System Test Data

V2 Control Standard has been given a tighter focus on protection of test date, with access control related matters being addressed in Control Standard IS.9.

IA.1 Identity Management

IA-11.5.203 User Identification and Authentication

V2 Control Standard has been rewritten for clarity and to provide additional control definition.


IA-11.2.103 User Account Management

v2 Control Standard has a closer focus on account management, with matters relating to access rights and privileges being dealt with within Control Standard IA.3.


IA-11.2.303 User Password Management



IA-11.5.103 Secure Logon Procedures



V2Control ID

V2 Control Name

V1ControlID

V1 Control Name


IA.3 System Authentication

IA-11.5.303 Password Management System

Password management provisions have been subsumed into information system authentication.

IA.3 System Authentication

IA-11.3.103 Password Use Policy

Control Intent is addressed with in IA.3 Information System Authentication


IA-11.6.103 Information Access Restrictions

Access restrictions have been subsumed into privilege and access management.


IA-11.1.103 Access Control Policy

Control Intent is addressed with in IA.4 Privilege and Access Management.


IA-11.2.203 User Privilege Management

User Privilege Management have been subsumed into privilege and access management.


IA-11.2.403 Review of User Access Rights

Review of User Access Rights have been subsumed into privilege and access management.


IA-11.4.103 Authorised Use of Network Services

Control Intent is addressed with in IA.4 Privilege and Access Management.

IA.5 Remote Access IA-11.4.203 User Authentication for External Connections

Focus of v2 Control Standard expanded to the management of remote access, not simply the authentication of external connections.

IA.5 Remote Access IA-11.7.203 Telecommuting The control intent expressed in the v1 Control Standard has been rendered into more modular and tangible form in v2.

IA.6 Directory Management

N/A N/A New Control Standard – the security of directory services was not addressed in v1.


IA-11.5.503 Connection/Session Time Restrictions



IA-11.5.603 Limitation on Concurrent Sessions




v2 Control Standard has been made more specific and expanded to encompass control definition applicable to operational responsibilities.



No substantial change in control intent. More specific information provided on the development and management of procedures.


IS-12.4.103 Control of Operational Software


359

V2Control ID

V2Control Name

V1ControlID

V1 Control Name



CM-10.1.203 Change Management

v2 Control Standard has been made more specific and practitioner-oriented.


IS-12.5.103 Change Control Procedures



IS-12.5.203 Technical Review of Applications After Operating System Changes



IS-12.5.303 Restrictions on Changes to Software Packages



CM-10.1.403 Separation of Development, Test, and Operational Facilities

v2 Control Standard provides specificity on example mechanisms for segregation of the environments.

OM.4 Commissioning of Systems and Networks

CM-10.3.203 Information System Acceptance

v2 Control Standard focused on the process of commissioning, rather than just acceptance.

OM.5 Monitoring of System and Network Performance and Usage

N/A N/A New Control Standard – In v1 operational monitoring was spread across multiple controls, rather than there being a consolidated perspective on information system and network monitoring.

OM.5 Monitoring of System and Network Performance and Usage

CM-10.10.103 Monitoring Policy and Procedures

Control Intent is addressed within OM.5 Monitoring of System and Network Performance and Usage.

OM.6 Anti-Malware Protection

CM-10.4.103 Malicious Code Protection

Greater detail and specificity provided in the v2 Control Standard.

OM.7 Technical Vulnerability and Patch Management

N/A N/A New Control Standard – Patch management and vulnerability management were referenced in passing in several v1 control areas but no specific Control Standard for these disciplines was provided before v2.

OM.8 Information Backup and Restoration

CM-10.5.103 Information Backup

More specificity provided in v2 Control Standards on backup and restoration.

OM.9 Network Boundary Defence

N/A N/A New Control Standard – no specific Control Standard provided in v1 application to boundary/perimeter protection.

OM.10 Intrusion Detection and Prevention

N/A N/A New Control Standard – the terms “IDS” and “IPS” were given definition in v1 but a specific Control Standard applicable to this area did not exist.


V2Control ID

V2 Control Name

V1ControlID

V1 Control Name


OM.11 Information Extrusion Detection and Prevention

N/A N/A New Control Standard – Not addressed within a targeted control in v1


IA-11.4.403 Remote Diagnostic and Configuration Port Protection

The v2 Control Standard provides a sharper focus on port protection, in comparison to the hybrid content of the v1 Control Standard.

OM.13 Secure Software Management

IA-11.5.403 Use of Information System Utilities

Scope of the V2 Control Standard broadened, in comparison to its v1 counterpart. The original Control Standard had a focus just on information system utilities. In contrast, the v2 Control Standard seeks to address the secure management of multiple software types.

OM.14 Electronic Mail Security

CM-10.8.403 Electronic Messaging

v2 Control Standard provides greater specificity on the secure management of electronic mail.


IA-11.4.303 Equipment Identification in Networks

v2 Control Standard has a broader focus than its v1 counterpart, seeking to address all unauthorised connections, rather than just those via remote access.


CM-10.7.103 Management of Removable Media

v2 Control Standard provides more specificity on the secure management of removable media.


CM-10.7.203 Disposal of Media

v2 Control Standard provides more specificity on the secure management of media disposal.


CM-10.7.303 Information Handling Procedures


OM.17 Management of Paper Media

N/A N/A New Control Standard – References to the management of paper-based information assets were spread across multiple Control Standards in v1.

OM.18 Technical Configuration Definition Enforcement

N/A N/A New Control Standard – the detection of deviations from a known good baseline and the automatic remediation of such deviations did not have Control Standard definition within v1.


CM-10.8.303 Physical Media in Transit

v2 control extends the scope of control intent, to cover off-site storage, as well as protectingmedia in transit.

361

V2Control ID

V2 Control Name

V1ControlID

V1 Control Name



CM-10.10.203 Audit Logging The v2 Control Standard is intended to give a broader and more integrated of view of log management and analysis, in comparison the multi Control Standard approach evident in v1.


CM-10.10.403

Protection of Log Information



CM-10.10.303 Monitoring Information System Use



CM-10.10.503 Logging of Administrator and Operator Use



CM-10.10.703 Clock Synchronisation



CM-10.10.603

Fault Logging The v2 Control Standard is intended to give a broader and more integrated of view of log management and analysis, in comparison the multi Control Standard approach evident in v1.

OM.21 Secure Systems Maintenance

PE-9.2.403 Equipment Maintenance

Control intent retained but more detail added to the v2 Control Standard.


PE-9.2.603 Secure Disposal and Re-Use of Equipment

Information regarding specific methods for secure disposal have been included in the v2 Control Standard.


N/A N/A New Control Standard – The full Incident Management lifecycle was not addressed in v1. Modelling of potential incidents before their occurrence was not covered.



More specificity is provided in the v2 Control Standard regarding the type of Incident Management roles that need to be considered by the Entity.


V2Control ID

V2 Control Name

V1ControlID

V1 Control Name




New Control Standard – The v2 Control Standard has a much broader scope, addressing multiple dimensions of planning the Entity’s Information Security Incident Management capabilities, beyond just the production of procedures.

IM.4 Information Security Incident Training and Simulation

N/A N/A New Control Standard – the need for incident simulation as mechanism for response preparation and learning was not included within v1.


IM-13.1.104 Reporting Information Security Events

The v1 Control Standard was oriented toward the Entity reporting incident events to ADSIC. The v2 Control Standard is oriented toward users reporting the attributes of actual and potential incidents to the Entity.


IM-13.1.203 Reporting Information Security Weaknesses


IM.6 Management of Security Incident Response

N/A N/A New Control Standard – a specific control relating to incident management/handling was not included within v1.

IM.7 Management of Security Evidence

IM-13.2.403 Evidence Collection

The v1 Control Standard provided a genera statement regarding the need for evidence collection and retention. The v2 Control Standard provides more specific and detailed information on Evidence Management.





BC-14.1.403 Business Continuity Planning Framework

Continuity Management in v2 has been re-scoped from Business Continuity Management to Information Security Continuity Management.


BC-14.1.103 Information Security in Business Continuity

The control intent expressed in the v1 Control Standard has been rendered into more modular focusing on the information system continuity and tangible form in v2.

IC.2 Information Systems Continuity Requirements

N/A N/A New Control Standard – The need to capture and analyse service continuity requirements was not overtly addressed within in v1.

363

V2Control ID

V2 Control Name

V1ControlID

V1 Control Name



BC-14.1.203 Business Continuity Planning and Risk Assessment



BC-14.1.303 Business Continuity Plans


IC.4 Testing of System Continuity Plans

BC-14.1.503 Testing and Re-assessing Business Continuity Planning

The v2 Control Standard provides specificity regarding a) the type of testing that may be conducted and b) the key questions that testing should seek to provide answers to.