Information Security Framework

- 14 mins read

Series: ISMP notes

Information Security Framework (ISF)

The purpose of the ISF is to ensure appropriate controls are in place to effectively manage IA across the enterprise. To achieve this it’s important that the assurance requirements are clearly understood and that accountabilities are clearly defined.

IS Roles

Assurance activities will need to coordinated at a high level. IA functions as regulatory roles should be formally placed within the organizational structure to facilitate full management and coordination of assurance matters.

The Information Security Manager

The security manager is a nominated resource within the organization providing advisory and senior management functions for IA at an enterprise level. The main activities of the security manager include:

  • coordinating enterprise-scoped IA activities

  • coordinating production of security policies

  • communicating IA responsibilities to users

  • understanding the evolution of the enterprise’s risk appetite

  • monitoring effectiveness of IA arrangements

  • reporting effectiveness of IA arrangements and suggesting improvements

  • providing advice on IA matters

  • creating a culture of good IA practice and information exchange

Board responsibility

An individual should have overall responsibility and formal accountability for protecting assurance of assets. This should normally be senior management such as a board member to leverage sufficient authority. Their main responsibilities:

  • single point of accountability

  • ensure appropriate assurance goals are identified

  • ensure adequate resources for assurance functions

  • assign specific assurance roles

  • provide clear direction, commitment, and visible support for initiatives at a high level

  • establish and chair a regularly convening ‘steering committee’

Steering Committee (Security Forum)

The security forum is a regularly convening high-level working group coordinating assurance activities across the enterprise. It should consist of a cross-section of individuals that are either stakeholders (such as departmental heads or HR representatives) or have IA responsibilities. The security forum is responsible for ensuring effective information risk management:

  • ensuring assurance is included in the organization’s overall planning activities

  • ensuring statutory/regulatory requirements are effectively met

  • approving and prioritising assurance improvements

  • reviewing assurance performance and changes in threats/risk profile

  • approving IA related policies, standards, and procedures

  • evangelising good IA practice in the organization

Across the organization

All those involved should have an understanding of their accountabilities; their responsibilities to IA must be clearly defined. Their job descriptions/terms of reference should include:

  • scope of responsibilities and level of authority

  • mandated processes supporting responsibilities

  • procedures for managing IA failures

  • understanding confidentiality constraints

  • requirements for regular reporting

  • anticipated IA actions on leaving the organization

  • consequences for breaches of terms

These responsibilities and associated IA practices should be included in formal objectives to ensure there is a mandate to enact them. They must be supported by sufficient documentation and training along with clear direction from senior management. A record of assurance awareness training should be kept if possible. Additionally, local security coordinators may be installed to ensure security policy at a low level and identify/report breaches and vulnerabilities. Coordinators can assist the security manager with feedback and advice.

The Threat Intelligence (TI) function

The primary purpose of the TI function is to ensure the organization is informed of current risks and advised on countermeasures. TI and Cyber Threat Intelligence (CTI) assesses and validates information on current and potential threats relevant to the organization as well as identifying vulnerabilities and threat agents to act as inputs to the risk management process.

The primary TI function operates to gather and collate relevant information from a range of sources including:

  • intelligence/security agencies

  • commercial TI services

  • open source intelligence (OSI) and social media

  • the internet and dark web

That data must be assessed for:

  • correctness

  • timeliness

  • credibility

  • relevance

Where this information is shared via a secondary TI function with partner organizations this is referred to as Co-operative Threat Intelligence. This agreement to share can be informal or through a formal Cyber Security Information Sharing Partnership (CiSP) programme.

The TI provides context to the organization to facilitate informed decisions in the risk management process. The deliverable of the TI to the organization is primarily a report detailing threat actors and their:

  • motivations

  • intent

  • capabilities

  • tactics, techniques, and procedures (TTPs)

  • access to intended targets

The report should also provide predictions, threat prioritization, and attack methods.

Creating a Culture of Good IS Practice

This must be management driven (from the top of the organization) and supported by a system of positive reinforcement. A critical factor is ensuring all persons are aware of their responsibilities and what actions are expected. This must be clearly communicated and the information readily accessible. Policies and procedures rely on individuals being aware of and understanding them as well as gaining their agreement to comply.

Policies, Standards, Procedures, Guidelines

The language in any regulatory documentation should be concise, simple, unambiguous, and consist of positive statements. They should address a well-defined subject area within its scope (eg. ‘all employees in the UK’). To be credible, they should be realistic and enforceable, have clear ownership, be endorsed by all interested parties, and be consistent with other corporate policies and with the law.

  • Policy: high-level statement of values, goals, and objectives in a specific area and the general approach to achieving them (compliance is mandatory)

  • Standard: quantifies the minimum acceptable criteria to achieve a policy in a specific area and provides consistency in controls that can be measured (supports policy, mandatory)

  • Procedure: a set of detailed working instructions which must be followed to ensure compliance with a specific standard (supports policies and standards, mandatory)

  • Guideline: provides advice on best practice (discretionary)

Security policy

Every organization should have a high-level security policy that states its commitment to IA and containing statements on:

  • how IA will be managed

  • protection of assets according to their criticality

  • compliance with statutory/regulatory obligations

  • how users will be informed of IA issues and the process to deal with breaches and suspected IA weaknesses

  • the endorsements of this policy

Acceptable Use policy

Development of the security policy should be consolidated by an acceptable use policy (end-user code of practice) which is published to all users. It should detail what is expected of users in order to protect assets and can also contain more general statements regarding behaviour (eg. that obscene statements in the workplace are unacceptable). To protect against vicarious liability the policy should also specify that the users must comply with appropriate legal and regulatory requirements placed upon the organization. The organization must obtain formal confirmation that users understand their obligations and accept responsibility to comply.

Consequences of policy violation

Appropriate processes for reporting and resolving policy violations must be established via documentation and endorsement. The consequences for policy violation must be clearly communicated to all users.

Provision of Advice and Expertise

Those involved in the security function should provide specialist IS advice to the enterprise. This requires maintaining a high degree of current knowledge. If this is not available within the organization it might be necessary to procure external security services. Policies, standards, and procedures should be extended to third parties where relevant (typically these requirements will be contained in the terms of the contract). In Addition, third party contracts typically provision:

  • management of changes to resources

  • the right to monitor and audit third party assurance arrangements

  • notification and investigation of assurance incidents

  • recruitment of personnel

  • resolution of disputes and jurisdictions

Information Security Governance

Assurance governance processes review and correct existing controls to ensure IA requirements are effectively met.

Policy review

Policy must be maintained via established management review process, either at regular intervals or following any significant change. The review schedule must identify who is involved and provide a formal record of justified changes. These changes are accepted with endorsement of senior management. The review should focus on factors that might influence possible amendments:

  • change to business risk appetite

  • change to requirements

  • change to technology, processes, resources, etc

  • change to threat profile and vulnerabilities

  • products of assurance reviews or audits

  • findings from previous incidents/breaches or evidence of non-compliance

Security audit

There should be regular or reactionary independent audits and reviews of assurance arrangements across the organization. The scope and delivery must be endorsed by management and developed via a scoping exercise; this will produce a checklist to measure efficacy of controls. Access of the auditor should be closely controlled (typically read-only on isolated copies of assets) monitored and logged. The product of the audit is a formal report to asset stakeholders and endorsement of corrective actions. Any new risks identified should be added to the risk register and all documentation should be securely filed for referral in the following planning cycle.

Compliance checks and monitoring

Regular checks must be performed to measure compliance with policies. Assurance is inevitably weakened as users become aware that regular monitoring is not performed. On discovery, actions should reflect the scale of the non-conformity. Corrective actions should serve to prevent future non-compliance and these actions are scoped for future review of efficacy. Compliance status should be reported to interested parties containing sufficient information to demonstrate compliance:

  • high-level RAs

  • risk register

  • set of security policies and review processes

  • register of dispensation from security policies

  • results of reviews (assurance, testing, compliance)

  • reports of incidents and actions

  • plans to address compliance weaknesses

Information Assurance Programme Implementation

Planning

An IA programme provides a high-level model for addressing IA needs. It must have a senior owner (the sponsor) and endorsement from main stakeholders. A steering committee should be established to track the programme. To be credible the programme must:

  • be realistic and achievable

  • accurately address enterprise needs (including fulfilling agreed objectives on agreed time-scales)

  • demonstrate quality and value for money (ROI can be used to justify expenditure eg. commercial advantage)

The implementation programme and plan must detail:

  • how it will address risks and the benefits resulting from implementation

  • required controls/work streams

  • levels of effort and from whom

  • who will be accountable

  • costs and time-scales

  • metrics of progress

The plan should remain high-level but with key deliverables and main milestones clearly expressed. It should be regularly reviewed to monitor its progress, identify issues, and if necessary apply corrective actions. Typically a programme consists of multiple projects, each addressing a specific function or asset. These may be planned and tracked independently from each other.

Presentation to users

Including users in the planning process can help to gain their confidence and appreciation in the programme. It is important to present security policy as an enabler by emphasizing the benefits of the assurance programme and how it aligns with other organization goals in a concise and understandable format:

  • risks facing the organization

  • causes of/potential impacts of risks

  • benefits from investment in the programme

  • where they may need to adjust working practices

  • how they can support/sponsor the programme

Security strategy

An IS strategy has the elements of an implementation programme but covers a longer time period and typically is at a higher level providing a roadmap for improvement and support of IA functions. It should remain a living document and should consider:

  • current state of assurance

  • how enterprise risk profile is likely to change

  • trends in threats/vulnerabilities

  • expected developments in software/hardware

  • legal/compliance/audit requirements and anticipated changes

  • potential cost savings

Security architecture

The IS architecture translates the requirements for assurance into a set of controls and provides a common framework for global assurance. The architecture works on a set of principles expressing types of controls to be implemented. Components within the enterprise with similar security requirements can be grouped into domains. Components within domains are protected by services (controls prescribed across a domain).

Incident Management

Incidents are managed by invocation of an incident response plan which must be established and tested prior to an incident. Management of an incident is normally broken into five phases:

  1. Reporting

  2. Investigation

  3. Assessment

  4. Corrective Action

  5. Review

The first priority is to ensure that all users can recognize an incident and know the reporting procedure. A standard report form should capture:

  • who is reporting

  • contact details

  • time identified

  • location identified

  • brief description of the incident

  • any danger to assets

  • any other potential impact to operations

  • description of any response

This forms the start of the incident log. The incident log captures relevant information, decisions, and consequences of actions and should be maintained throughout all phases of incident management until the incident is closed.

Incident Response Team (IRT)

An IRT must be appointed in advance and consist of an enterprise cross-section to leverage domain knowledge. It must be endowed with sufficient authority to make time-critical decisions and to call upon additional resources. Additionally there must be a documented escalation process for reaching senior members of the organization when necessary. Overall, the response needs to be prompt, appropriate, and valid.

When an investigation starts, the IRT consults senior management to decide whether a case for prosecution should be pursued. This will determine the level of effort required in collecting evidence, whether to involve the authorities, and whether it is acceptable to involve external specialists.

Evidence and forensic readiness

An additional responsibility of the IRT is ‘forensic readiness’, ensuring that, in event of an incident, evidence (eg. temporary files, digital and human fingerprints, etc) is secured and not altered (or destroyed). Any evidence must be controlled by the designated evidence custody officer. The evidence custody officer is responsible for collecting, securely storing, and documenting the evidence in order to maintain an unbroken ‘chain of evidence’ (a clear and indisputable record of all actions from the time of location of evidence to the time of its presentation). Additionally the rules for collecting and handling evidence under the relevant jurisdiction must be understood and adhered to. If there is any likelihood of criminal or deliberate action then the authorities should be informed.

Involvement of third-parties in investigations

Involvement of third-parties in the investigation raises additional issues which should be handled contractually. It is important that these contracts are negotiated and endorsed by senior management before an incident occurs to maintain a prompt response. This typically means a framework agreement detailing:

  • timeliness of evidence collection

  • non-disclosure

  • standards required in preserving evidence and documentation

  • transfer of evidence and assured destruction of obtained materials

  • participation in review at the end of the incident

Senior management should also agree and detail in advance:

  • the method for procuring third-party support

  • how such work should be done

  • how third-party support should be invoked

The ISO/IEC 27000 series provides guidance on the following areas:

  • intellectual property rights (this includes copyright law, Common Law of Breach of Confidence, and patents)

  • protection of organizational records

  • data protection and privacy of personal information, the protection of personal information should consider:

    • assurance to protect from unlawful processing, loss or destruction, unauthorized disclosure

    • assurance of integrity, correctness, and destruction

    • restrictions on transit/rest in other jurisdictions

  • prevention of misuse of information processing facilities

  • regulation of cryptographic controls

Common concepts of Computer Misuse

The misuse of computers can include:

  • illegal access

  • illegal interception

  • interference

  • computer-related fraud and forgery (eg. phishing which constitutes ‘obtaining information by deception’, ‘passing off’ could also constitute fraud)

  • copyright infringement

  • access and possession of illegal material

  • trafficking (in passwords, keys, etc)

  • harassment

Requirements for retention of records

There must be an established record retention policy and schedule in compliance with appropriate requirements. For example an organization may be asked to provide records (or proof of secure destruction) on demand to comply with legal or regulatory requirements. (see ISO 15489-1:2001 - Record Management Standards)

Contractual safeguards

When developing contracts with third parties the priority is to ensure that controls are implemented to protect the organization’s information assets to an acceptable level. Contracts might include clauses providing arrangements to:

  • perform regular assurance review

  • apply security patches in a timely manner

  • protect information against malicious code

  • provide business continuity arrangements inline with agreed service levels

  • vet new staff appropriately

  • discipline against breaches

  • manage incidents

  • protect against disclosure

  • provide the right and ability to monitor and audit services

  • prevent unauthorized subcontracting

  • agree common statutory/regulatory requirements

Collection of admissible evidence

Organizations will need to demonstrate that evidence is authentic and has been gathered in an acceptable manner. In the UK, the Police and Criminal Evidence Act (PACE) details the legal requirements for handling evidence. The NPCC has published The Good Practice Guide for Digital Evidence which states four principles to adhere to when handling evidence:

  • data to be relied upon in court should not be altered by any action

  • persons accessing original data must be competent to do so and to give evidence explaining the relevance and implications of their actions

  • an audit trail of all processes applied should be created and preserved such that the data state would be recreatable

  • there should be a person retaining responsibility for the evidence and ensuring compliance with requirements

Restrictions on cryptographic technology

The ISO/IEC 27000 series advises considering the following:

  • restrictions on import/export of entities for performing cryptographic functions

  • restrictions on import/export of entities designed to be endowed with cryptographic functions

  • restrictions on the usage of encryption

  • mandatory or discretionary methods of access by authorities to encrypted information

  • other specific statutory/regulatory requirements

Security Standards and Procedures

Noteworthy standards/guidelines published in this domain:

  • information security management: ISO/IEC 27001, ISO/IEC 27002 (guideline)

  • product evaluation criteria for IT security: ISO/IEC 15408-1:2009 (incorporates the Common Criteria for Information Technology Security Evaluation Criteria - CC ITSEC - providing Evaluation Assurance Levels - EAL - 1 to 7)

  • risk management: ISO/IEC 27005

  • quality assurance: ISO/IEC 9001

  • retention of records: ISO 15489

  • implementation of business continuity: ISO/IEC 22301:2019, PAS 77

  • network security: ISO 27033

  • information security management in healthcare: ISO 27799 (guideline)

  • information security management for inter-sector and inter-organisational communications: ISO/IEC 27010

  • IT security management: ISO/IEC 13335 (guideline)

  • good practice in IA: ISF Standard of Good Practice for Information Assurance

  • project development: COBIT

  • management of IT services: ISO 2000ITIL

  • using cloud resources: ISO/IEC 27017

  • information technology: ISO/IEC 20000-1:2018

This is a post in the ISMP notes series.
Other posts in this series: