💡 Conference Transcript: Building an Information Security Policy Framework
Following my presentation on Building an Information Security Policy Framework at the "Implementing CPS 234" conference held in Sydney in May 2019, I received many requests to publish a transcript. Thank you all for your interest and for the large amount of feedback you shared with me. As promised, here is an augmented transcript of my presentation.
The Australian Prudential Regulation Authority (APRA) has published a new Prudential Standard CPS 234, enforceable by 1 July 2019. This prudential standard defines APRA expectations from Financial Institutions around Information Security.
“An APRA-regulated entity must maintain an information security policy framework commensurate with its exposures to vulnerabilities and threats” (CPS 234 #18)
Among the fundamental requirements covered by the prudential standard, APRA clearly set the expectations that regulated institution must have a defined and maintained Information Security Policy Framework.
While the Prudential Standard does not define the expected capabilities and controls the framework should cover, it insists on 3 aspects:
- Understanding the assets: a regulated institution is expected to identify and classify them by sensitivity and criticality.
- Understanding the threats they are exposed to: having identified its assets, the regulated institution is expected to identify what threats they are exposed to. Due to the constantly changing nature of the threat landscape, a review of the threat exposure should be performed on a regular basis.
- Ensuring the assets protection is commensurate with the threat: this means that the controls that composed the Security Framework need to be adapted to each case so the risks are adequately mitigated. It is a clear statement that generic controls (such as generic penetration testing) or single peripherical protections (such as firewall) are not considered as enough, and the overall framework need to cater for the complexity of the environment.
This presentation is designed to offer an understanding on how a regulated institution can fulfil these requirements, covering:
- an overview of what a Policy Framework is, and why it is an essential part of any Information Security program;
- the various existing frameworks used across the industry, their strengths and limitations;
- a methodology to create a flexible framework, supported by a risk assessment and a strong understanding of the assets owned by the institution and the threats they are exposed to;
- An approach to define an adequate control set and how to prioritise its implementation.
A Policy Framework
APRA offers a definition of the policy framework as “the totality of policies, standards, guidelines and procedures pertaining to information security”. This is a very functional definition of a framework and it makes much sense from a regulatory standard perspective.However, organisations seeking maturity in their information security usually see their policy framework as a cornerstone of their security practice. It is, of course, a set of practices, policies and procedures, but it is also a calculated approach to determine information security risks and to reduce these risks through adequate controls.
As such, the policy framework is really the fleshed-out details of the overall Information Security Strategy, offering a measurable and repeatable methodology to achieve the goals defined by the organisation in that area.
A robust Policy Framework should serve multiple purposes:
- Educate people and staff about information security;
- Define responsibility of all stakeholders
- Ensure processes are secured and auditable;
- Facilitate secure implementation and maintenance of technology;
- Create a common language around information security, ensuring efficient communication with leaders and with all users;
- Provide a reference for designing security mechanisms; and
- Ensure measurement and benchmarking of the security practices.
While it is now a regulatory requirement, there is also high value for any organisation to endorse and maintain such a framework. It of course offers a robust way to protect physical assets, digital assets and information. It is also a fundamental tool to demonstrate good corporate citizenship, as protecting information is now considered as a normal duty of every company and not an optional activity. Finally, it can also be used as a business differentiation, especially if aligned with some of the industry’s most recognised security frameworks, and can ensure certification to some of the industry standards, such as ISO 27001.
A standard policy framework is usually composed of 4 types of documents:
- Policies are the highest level of the framework. They provide the foundation of the security program and are approved at the highest level of the organisation (ideally, the board of directors). All employees are required to comply with them. Their content needs to be carefully crafted and worded, and, in nature, should not dig into the technicality required for their execution. For example, a good policy would stand that “all sensitive information requires to be encrypted at rest and in motion” but should not define what technical encryption is required as the technology might change. By doing so, the policies will withstand the test of time and should not require to be updated as technologies evolve;
- Standards provide the details of security controls expected within the organisation. They derive their authority from policies and should align with them. Their compliance is again mandatory for all employees. Standards are usually approved by executive managers or senior managers, such as the Chief Information Security Officer or the Head of Cyber Security. They contain some level of decision on the methodology and technology expected to enforce the controls. For example, a standard would define that AES-256 should be used for data encryption. Complex technology standards are often derived from industry standards, such as the Center for Internet Security (CIS) standards, that has provided detailed configuration settings for a large number of operating systems, network devices, applications and platforms;
- Guidelines provide security advice and direction to staff. They align with the industry good practices and are usually optional. A guideline would suggest for example the usage of an encrypted wireless network when available. In cases where no encrypted wireless network is available, employee can still use alternative solutions, such as VPN;
- Procedures are step-by-step instructions to perform a specific task. As an example, a forensic procedure will contain the step to investigate a system or device and clearly define how the information has to be isolated and which element to look at to ensure no tampering occurs during the investigation. Depending on the organisation and the type of procedure, compliance may be mandatory or optional.
While some organisations decide to amalgamate some of these documents, for example by combining policies and standards, or standards and guidelines, keep in mind that these documents serve very distinct roles, have different level of expected compliance and are designed for different audiences. When creating any document that will be part of your framework, it is usually recommended to first identify clearly its audience and their level of technological literacy.
Providing a “map” of the framework, that helps readers to navigate the various information available through a set of high-level categories, and easily identify which documents are of value for them, is also greatly beneficial. This can easily be done by offering a 2-line description of what the document is about, whether compliance is expected, and a simple rating of the level of technical details contained.
Creating a framework
Creating a policy framework can be a daunting task. Information Security is a very large topic that covers many aspects around people, processes and technology. Creating a framework from scratch is a colossal effort and anybody attempting it is at risk of missing critical areas or topics. There are a number of well-recognised frameworks that can be used either as offered or as a starting point to create a more tailored and efficient framework that will fit the specifics of an organisation.While selecting or creating an Information Security framework, an organisation must first have a clear understanding of what its requirements are, and what it is trying to achieve through this process. There are a few points to consider carefully prior to engaging in a selection or deciding what to include:
- What are the compliance and regulatory requirements that the organisation is subject to?
- What are the specific technical and non-technical areas that the framework is expected to cover? Depending on the organisation activities and infrastructure, not all aspects of a fully-scaled framework might be pertinent. An organisation not managing or accessing any Personally Identifiable Information (PII) will not require as many privacy controls as an organisation that stores and processes a large number of individual personal information. The standard around web development security might also vary if the organisation has a web portal allowing customers to perform straight-through financial transactions, or if the corporate website only displays publicly available information pertaining to company services.
- Is there any certification objective for the organisation? Information Security can be a key differentiator in certain industries. For an organisation targeting ISO 27001 certification, it will be easier to adopt or align closely to the ISO 27001 framework, as it will facilitate the compliance demonstration and the acquisition of the certification.
- What is the current maturity of security? Some frameworks facilitate adoption through a maturity cycle, while others are more monolithic. An organisation with low cyber-security maturity will struggle adapting a robust but inflexible framework, as it might represent too much of a step up. Adopting a framework that can be realistically implemented from the current maturity level will facilitate implementation.
Most commonly used Information Security frameworks. Source: Dimensional Research 2017
Most commonly used Information Security frameworks are the Payment Card Industry Data Security Standard (PCI-DSS), the International Organisation for Standardisation 27001 Information Security Management (ISO 27001), the Center for Internet Security Benchmarks and Controls (CIS) and the National Institute of Standards and Technology Special Publication 800-53. While all these standards are of high quality and cover a large common ground of controls, they do have some difference. They are also not exclusive to each other, and many institutions use a combination of controls out of multiple frameworks to create their own.
Main Information Security frameworks
When selecting a framework, either as the fully-fleshed standard for an organisation or as a starting point for a bespoke framework, understanding the specificities of each of these industry frameworks is critical.
It is also essential to have a clear view of which local, regional and global regulations and legislations the organisation must comply with. Some frameworks might not be fully compatible with specific requirements. It is also important to understand how specific these expectations are. For example, most of the frameworks that offer a broad coverage of cyber security will mostly satisfy compliance with APRA CPS 234. But some very specific items, such as the requirement to notify APRA of a material incident within 10 business day (#36), will not be part of any default standard or procedure and as such will need to be inserted as a part of the incident response process.
Main local and global regulations for financial institutions
A gap assessment to understand which requirements are already satisfied and which need to be developed or updated in the framework is then essential. The gap assessment is also a great tool to demonstrate future compliance in case of audit. For APRA CPS 234, I published in 2018 an article that can assist in performing the gap analysis process.
Creating a hybrid framework
Despite their high quality and robustness, the industry frameworks can very often prove challenging to implement as is. They are designed to cover and protect all aspects of information and technology, and cover many elements that are not necessarily pertinent for all organisations, especially small and medium size companies. A company with a fully cloud-based infrastructure will for example find very little value in the numerous controls that ensure physical protection of in-house data centres. Local specificities and regulatory compliance items might also require alteration or additional controls that the industry standards might not cover. As an example, regulatory requirements might impose additional controls for data stored abroad, when an industry standard might not necessarily consider the data location as a potential risk.In addition, while they are designed to be as generic and adaptable as possible, industry frameworks might not always easily embed within specific organisational structures and business strategies. As technology and threats evolve at a fast speed, some of the controls of these frameworks become less relevant, while new risks arise and lack available mitigations.
As such, creating a hybrid framework is very often an excellent way to ensure Information Security focus on what is important for the organisation, reduce waste and inefficiencies, and enable adaptation to a fast-changing technology and threat landscape.
The easiest and most efficient way to create a hybrid framework is still to rely on one of the industry frameworks as a starting point, using that framework’s area of focus (or families, or sections, depending on the framework’s naming convention) as a starting point. Once the overall structure is defined, the next step will be to select the adequate core set of controls to populate the content. The controls must be selected following a risk assessment process based on a good understanding of the organisation’s core activities, assets and threats.
Example of simplified hybrid framework using the NIST 5 functions as an overall structure
The risk assessment: understanding the assets and the threats
The risk assessment is an essential step in the process of creating and defining the Information Security framework. It assists evaluation of the potential risks that may be involved in an undertaking. It helps measure components in consistent way across many different subject areas.
Multiple tools exist to assist in performing a risk assessment, covering multiple domains including security, but also IT, privacy, data security, and business resiliency. Both the CIS and NIST frameworks provide such risk assessment methodology for free, as well as industry recognised methodologies and tools, such as the Standardized Information Gathering (SIG) questionnaire.
Most organisations agree that a risk can be calculated as the factor of the impact that an event would have on the organisation and the likelihood of that event occurring.
RISK = IMPACT x LIKELIHOOD
When it comes to information security, the impact can be measured through the understanding of the assets affected and how much the organisation is reliant on these assets.
For the likelihood, it is in direct correlation with the threats faced by the organisation. Having a clear view of the security threats that the organisation faces is key to understanding which of these threats are likely to occur.
Understanding the assets
Understanding the assets of an organisation and the associated impact if these assets were to be made unavailable, corrupted or inadequately disclosed is a long process that requires a good understanding of the organisation as a whole. Assets can be people, information, buildings and facilities, IT systems, finances and even partner organisations and suppliers. In order to clearly identify their value, assets need to be classified, be part of a lifecycle or management process, and have a defined owner.The asset identification process follows 4 specific steps:
- The identification of the product and services offered by the organisation.
- The identification of the critical functions needed to deliver the products and services
- The understanding of processes required within the critical functions
- The identification of assets (or resources) required to perform the processes
The asset identification process requires interaction with all departments and might require using various methods, including workshops, questionnaires and interviews. Strategic plans, annual reports, department plans, service level agreements (SLA) and previously performed risk assessments can also be a valuable source of information to assist in that exercise.
Once the assets have been identified and registered, the next step is to classify them. Classification helps users understand security requirements for different types of assets. The different security classifications used by an organisation determine what sort of storage, handling, and access are required for classified information. Asset classifications are assigned based on both the sensitivity of the information and the criticality of that information to the organisation. Classification categories vary from organisation to organisation, but most classification schemes have 3 to 5 levels used to segregate information:
- Confidential or private information could be of high impact if disclosed inadequately, such as customers’ personal information, plans for new undisclosed products and board papers.
- Sensitive information is not designed to be shared outside the organisation but would have limited to moderate impact if it was to make available to an unauthorised party. Example of sensitive information would be staff corporate email addresses or phone numbers, internal procedures or a list of suppliers; and
- Public information is designed to be accessible by everybody. Examples of public information include advertising documentation, public disclaimer, list of available products…;
Example of a classification scheme
An efficient classification standard would include a methodology to assist in consistently determining the classification of an asset. That could be achieved by providing rules defining how assets should be classified based on the resulting monetary loss, image loss or management impact if the assets were to be compromised. As an asset ranges higher in the classification scheme, the impact associated with its disclosure or unavailability also increases.
Understanding the threats
Understand the threats that are targeting or that could target an organisation is essential to prepare, prevent, and identify security incidents. By gaining knowledge pertaining to the threats faced and having an understanding of their likeliness, the organisation can build effective defence mechanisms and focus its security investment on what is important.Threat modelling can help in that exercise. The STRIDE model, developed by Microsoft, is a useful and simple starting point. It is derived from an acronym for the 6 following threat categories:
STRIDE threat model
Understanding the threats, including identifying how often these threats were realised in the past, allows their likelihood of future reoccurrence to be determined.
The risk matrix
With a better understanding of the impact that a compromised corporate asset would create, and the likelihood of the threats faced by the organisation, creating a risk matrix is a simple mechanism to increase visibility of risks and assist in the decision on what controls are required and need to be implemented as a priority.
A simplified risk matrix
Categorising the impact and likelihood can facilitate further the process, especially if one or both factors cannot be measured efficiently. As an example, the impact can be categorised as: ‘catastrophic’, ‘high’, ‘moderate’ and ‘low’, and the likelihood as 'certain', 'likely', 'possible', 'unlikely' and 'rare'.
Once the risks are classified, the priority and the importance of the controls that will mitigate them become very quickly evident.
- Significant risks have a high impact and a high likelihood. They are imminent threats to the organisation and as such should be remediated immediately. Controls associated with these risks are very important and need to be regularly reported, tested and measured for efficiency.
- Contingency risks and high incidence risks have respectively high impact but low likelihood and low impact but high likelihood. These risks are the next priority to remediate. While not necessarily imminent, they are real threats for the organisation. Associated controls need to be carefully monitored and tested on a regular basis.
- Minor risks have low impact and low likelihood and as such are less likely to be on the priority list. They should be addressed when possible, but their level of reporting and testing can remain limited.
The Core Security Control Set
Selecting an industry-recognised framework as a baseline and having a clear risk assessment are 2 major steps toward a fully fleshed Information Security policy framework. The final step is to select the set of controls that will compose the framework and will be described through the various documents comprising it.As mentioned previously, industry recognised frameworks such as PCI-DSS, ISO or NIST offer a large set of controls that can be reused as part of a hybrid framework more aligned with an organisation’s needs and priorities. To select which controls will comprise the final framework, the risk assessment becomes an essential tool. By linking the controls to the risks they are designed to mitigate, it becomes easy to identify which controls remediate significant risks, contingency risks or high incidence risks. These controls should be part of the final framework. Controls remediating minor risks might or might not proceed to the final framework, depending on the organisation appetite toward security risk.
Keeping a documented linkage between risks and controls could also prove very valuable for future evolution of the framework. As the organisation and its environment evolve, the assets it uses and the threats it faces might change, resulting in a shift of risks. Some risks might disappear over time while new ones will surface. Some risks will increase as other decrease. As the organisation refreshes its risk matrix, it becomes easy to update the framework accordingly by deciding if controls are still pertinent or if they only remediate risks that are not of importance anymore, and as such can be removed.
Some controls, known as common controls, support multiple systems efficiently and effectively as a common capability. Ensuring that these controls are included as a priority facilitates the operational execution of the framework.
To be efficient, controls need to be well documented. That includes defining responsibility for implementation and execution (the control owner), frequency of execution and clear methodology to execute. A good control is measurable (its results can be quantified in a certain and repetitive way), auditable (the results can be demonstrated at any time) and understood (the team responsible for control execution must have a clear understanding of the intent of the control and its importance for the organisation).
Finally, gathering feedback from stakeholders, especially the control owners, is essential. A policy framework is as robust as its execution. A strong set of controls has no value if, in practice, they are not performed because they are too onerous, too complex or simply not well understood.