Information Risk Security model and metrics
1 like1,471 views
This document presents a security governance, risk, and compliance (GRC) model for information risk security management. The model describes three main components: security drivers like laws and regulations, business objectives, and security threats. It then outlines the security management framework, including policies, standards, processes, and metrics. Finally, it discusses the relevant stakeholders in information security. The goal of the model and this document is to help security professionals ensure the future of their jobs by aligning information security practices with business needs.
![Section
3:
Security
Management
3.1
The
Policy
framework
This
is
the
first
element
of
the
‘Security
Management’
part
of
the
model.
The
Security
Policy
is
usually
not
a
single
document,
and
rightly
so.
The
documents
in
the
Security
Policy
library
have
different
audiences
and
levels
of
detail;
see
Figure
2
below.
Figure
2:
Information
Security
Policy
framework
CISO Business
and
Information
security
policy security
objectives
Data
classification
Employee
acceptable
policy use
policy
CIO
Information
technology
security
policy Security
objectives
IT
Security
IT
security
standards
[reuse
Architecture
internationally
accepted
controls] Controls
Technology
and
Security
Technical
teams processes
architecture
repository Processes
Security
guidelines
3.1.1
Information
security
policy
The
primary
objective
of
the
Information
security
policy
is
to
state
business
objectives
and
high
level
security
objectives.
The
document
also
sets
accountabilities
for
ensuring
the
security
objectives
are
met.
The
document
should
be
owned
by
CISO
or
CSO
but
approved
by
the
Board;
as
the
Board
is
responsible
for
approval
of
business
strategy
and
objectives,
the
protection
of
these
are
obviously
in
the
Board’s
interest.
3.1.2
Data
classification
policy
The
top
level
policy
should
also
make
provision
for
a
data
classification
scheme,
which
can
then
be
detailed
in
the
Data
classification
policy.
Data
classes
depend
on
the
nature
of
the
business
but
at
the
minimum
should
include:
(i)
Public
data
that
are
in
the
public
domain.
It
is
a
mistake
to
assume
that
public
data
do
not
need
any
protection.
For
example,
take
a
company
homepage;
typically
this
is
information
that
a
company
wants
to
share
with
the
world,
i.e.
it
is
‘Public’.
But
what
happens
if
the
information
on
the
website
changes
without
authorisation?
Examples
can
range
from
defacing
of
the
website,
to
unintentional
mistakes
by
employees,
mixing
the
product
description,
changes
in
prices
of
the
products
etc.
The
public
information
usually
needs
to
be
‘accurate’
and
‘available’,
but
obviously
there
is
no
requirement
to
keep
the
information
‘confidential’.
(ii)
Company-‐wide
data:
this
type
of
information
can
be
shared
between
employees
and
people
who
have
signed
an
NDA.
This
is
by
far
the
largest
category
of
information
in
most
organisations.
It
is
also](https://image.slidesharecdn.com/irsmmodelandmetrics-120104163504-phpapp01/85/Information-Risk-Security-model-and-metrics-5-320.jpg)
Information Risk Security model and metrics
- 1. INFORMATION RISK SECURITY MANAGEMENT: A Model and Metrics By Vladimir Jirasek, Information Risk Management Evangelist Contents Page Section 1: Introduction 2 1.1 The Security Governance, Risk and Compliance (GRC) model 2 1.1.2 Security Drivers 2 (i) Laws and regulations 2 (ii) Business objectives 2 (iii) Security threats 3 1.1.3 Security Management 3 (i) Policy framework 3 a. Policies 3 b. Standards 3 c. Artefacts 3 (ii) Processes framework 3 (iii) Security metrics framework 3 1.1.4 Stakeholders 4 Section 2: Security Drivers 4 2.1 Business objectives 4 2.2 Legal and regulatory requirements 4 2.3 Security threats 4 Section 3: Security Management 5 3.1 The Policy framework 5 3.1.1 Information security policy 5 3.1.2 Data classification policy 5 (i) Public data 5 (ii) Company-‐wide data 6 (iii) Restricted access data 6 3.1.3 Employee acceptable policy 6 3.1.4 Information technology security policy 6 3.2. Security standards 7 3.2.1 International standards for security policy and controls 7 3.2.2 Information technology standards 7 3.3 Security architecture repository 8 3.4 Process frameworks and metrics 8 3.4.1 Security processes 8 3.4.2 Security metrics 8 (i) Value at Risk 9 Conclusion 10 About the Author 10
- 2. Section 1: Introduction Information risk security management is an area that is constantly moving to respond to new threats, standards and technologies. Security is now a part of information risk management, which in turn has a place in the overall business risk management strategy. This document explains a security model that supports business needs, and explores how security professionals could change their mindsets to help ensure future job security. 1.1 The Security Governance, Risk and Compliance (GRC) model Figure 1 below describes a security model that introduces the topic of security to business managers and CIOs. Figure 1: Security GRC model Feedback: update business requirements SECURITY MANAGEMENT DRIVERS STAKEHOLDERS Correction of security processes CEO & Board International Policy framework Process framework Metrics framework Governance security standards Information Information Information Line Security Security Security management policies processes metrics Laws & objectives regulations Information Product Drivers Security Rules Measure Inform management Technology standards Security People Define metrics portal Program Information management Compliance security requirements architecture Risk & DEFINE security EXECUTE security MEASURE security compliance Business controls controls controls maturity objectives Auditors Security Security threats intelligence Security External professionals security metrics The model describes three main areas: (1) Security drivers; (2) Security management; (3) and Stakeholders. 1.1.5 Security Drivers The three major drivers for security are: (i) Laws and regulations: A company must comply with these or face legal action or a fine. For example, the Data Protection Act and the Company Act are examples of the legal drivers; PCI DSS is an example of a regulation driver. (ii) Business objectives: Companies typically want to generate profit and define a set of business objectives. Security supports these business objectives by protecting systems and information used in the business processes. Think of protecting Microsoft Windows source code: if the source code was not protected anyone could compile their own operating system without paying Microsoft any license fee. Hence, Microsoft’s business objective to ‘Sell software’ is supported by the security objective ‘Protect source code’. Similarly, Amazon’s business
- 3. objective is to sell products in their online shop; their business objective is to have an online shop up 24/7; the security objective is to keep systems free of malware that could disrupt or slow down IT systems. (iii) Security threats: Security threats work against laws and regulations and business objectives. However, they also drive information security, and companies need to respond to threats in order to satisfy first two drivers. 1.1.6 Security Management Within this area there are three frameworks that enable a company to achieve the objectives defined in the ‘drivers’ section: (i) Policy framework This is a set of policies, standards and guidelines that describe how a company addresses information security drivers, and define the security controls available for a company to implement. There are also international standards that can be source of information and control for the Policy framework. a. Policies – also known as Security Control Objectives, these typically use words such as ‘should’ and ‘must’. The key objective of the security policy document is alignment with the business objectives and drivers. b. Standards – detailed Security controls that should be implemented to support individual policy statements; one policy statement can be supported by multiple security controls. These should be linked to a policy, otherwise the security professional will be unable to justify why a password needs to be 12 characters and change every 45 days, for instance. The controls should be selected from an internationally accepted catalogue of controls (see section below on ‘International Standards’). c. Artefacts – Architecture standardisation is the key to the success of any company, and the same applies to security. If a solution to implement a security control is found in the ‘Standard’, it should be put it into a ‘Security Architecture Repository’. That way, others can benefit and, more importantly, consistent security is achieved. Many security professionals do not document artefacts into a shared library, which can often result in problems when they leave the company. (ii) Processes framework This section in Security Management implements what is stated in the Policy framework. Any security control in a policy or standard is a process, no exceptions. Each process is supported by people and most are supported by technology. However, there needs to be a link between any technology the company has, its process, and the corresponding control in the Policy framework up to the business objective. This enables traceability of the security investment and allows security professionals to justify security budgets. (iii) Security metrics framework This is a developing area of information security management. The common adage – ‘what cannot be measured, cannot be managed’ – can be applied equally well to security. Security professionals should be able to measure the status of security controls, the compliance with their own policies, and the effectiveness of security processes. The key metric is to take a security policy statement and measure each team against it; this will provide a balanced scorecard for security. The metrics framework provides feedback to the Process framework, to assist with security processes design. 1.1.7 Stakeholders Stakeholders are the recipients of the security metrics framework results. The stakeholders need to know that what has been promised is being delivered. More importantly, the security professionals need to show the value of security to the business. This is an area where security professionals need to enhance their skills; they need to talk to stakeholders, uncover their concerns, and show them
- 4. that they are being addressed. This should be followed by a report that relates to their specific area and concerns; they need to see that security personnel are on their side! Section 2: Security Drivers 2.1 Business objectives Security professionals exist to support the business. Companies are driven by their vision and mission statements, translated into business strategies that describe how to achieve that vision. The business objectives define how the organisation wants to achieve its targets. If a business objective is to ‘Supply customers with the goods’, the security objectives should be to protect the process of supplying the customer. This clear link between business and security objectives can sometimes be missing. 2.2 Legal and regulatory requirements Businesses need to comply with legal, regulatory and contractual requirements (listed in order of impact). Legal requirements are typically related A practical example to the way the company is governed, how it A telecommunication company sells mobile phones prepares its accounts and how it protects the and call plans to its customers. One of its objectives is personal data. In the UK, the Company Act 2006, to ‘Deliver outstanding customer service, measured by ‘part 15 Accounts and reports’, states clearly the customer satisfaction’. This objective is supported by a requirements relating to how accounts are business process ‘Customer service’, whereby customer created and reported. It also includes penalties service representatives in shops, call centres and online talk to customers to solve their problems and answer for untrue and misleading accounts. In the USA, questions. the Sox legislation was created after major financial scandals. The Data Protection Directive, Customer satisfaction is dependent on a) speed to Principle 7, states that access to data must be initial contact, and b) completeness of response. The limited to the authorised persons. And although information security risks identified are: 1) information the Data Protection Directive does not state systems unavailable or slow so the initial response time is affected; 2) information in the knowledge base which security controls should be implemented, system is inaccurate; and 3) the customer data in the the guidance states that there are CRM system becomes compromised, resulting in a fine internationally accepted standards relating to and bad PR. building information security systems in a company. From this quick risk analysis, it is easy to understand where the information security policy needs to focus and what the security objectives should be. As a result of this legislation, any information security system implementation must protect data and information systems so that they are: a) accurate (in security terminology the word ‘Integrity’ is used) b) available, and c) access to the content is assured (‘Confidentiality’ in security terminology). 2.3 Security threats Security threats affect the level of protection (i.e. control) that is needed. Threats come from attackers who want to either acquire information or limit business opportunities by affecting business processes. Microsoft has created a very good methodology (STRIDE) for assessing threats and designing security controls to prevent threats from harming business processes. The role of the security model is to capture security threats and design security objectives and controls to protect the business. Security intelligence is the capability to analyse security threats and advise what controls should be included in the policy framework.
- 5. Section 3: Security Management 3.1 The Policy framework This is the first element of the ‘Security Management’ part of the model. The Security Policy is usually not a single document, and rightly so. The documents in the Security Policy library have different audiences and levels of detail; see Figure 2 below. Figure 2: Information Security Policy framework CISO Business and Information security policy security objectives Data classification Employee acceptable policy use policy CIO Information technology security policy Security objectives IT Security IT security standards [reuse Architecture internationally accepted controls] Controls Technology and Security Technical teams processes architecture repository Processes Security guidelines 3.1.1 Information security policy The primary objective of the Information security policy is to state business objectives and high level security objectives. The document also sets accountabilities for ensuring the security objectives are met. The document should be owned by CISO or CSO but approved by the Board; as the Board is responsible for approval of business strategy and objectives, the protection of these are obviously in the Board’s interest. 3.1.2 Data classification policy The top level policy should also make provision for a data classification scheme, which can then be detailed in the Data classification policy. Data classes depend on the nature of the business but at the minimum should include: (i) Public data that are in the public domain. It is a mistake to assume that public data do not need any protection. For example, take a company homepage; typically this is information that a company wants to share with the world, i.e. it is ‘Public’. But what happens if the information on the website changes without authorisation? Examples can range from defacing of the website, to unintentional mistakes by employees, mixing the product description, changes in prices of the products etc. The public information usually needs to be ‘accurate’ and ‘available’, but obviously there is no requirement to keep the information ‘confidential’. (ii) Company-‐wide data: this type of information can be shared between employees and people who have signed an NDA. This is by far the largest category of information in most organisations. It is also
- 6. referred to as ‘semi-‐public’, and the bigger the organisation the greater the probability of leakage from employees or partners. (iii) Restricted access data: some information will be accessible on a need-‐to-‐know basis, depending on the type of business. Business plans, strategy, research data, and new product details are just some examples of the information that should be well protected. 3.1.3 Employee acceptable policy This policy document should spell out the most important policies for employees. Good security and HR professionals do not expect users to remember all policy documents. The objective of this document is to show employees what is critical and where to find more information. 3.1.4 Information technology security policy Most companies rely on information technology to run the business processes. The role of CIOs has become to support business, understand where the company wants to expand, and suggest how to become more agile and cost effective. IT can be a saviour or a nightmare, depending on the abilities of the CIO. The security policy for the CIO team needs to translate business objectives into security objectives and controls, as shown in Figure 3 below. Figure 3: Relationship between business objectives and security processes Provides response to ‘Do we have all business risks covered?’ International standards Control C1 Control C2 Security Security objective SO1 Control C3 process P1 Business Control C4 objective BO1 Security objective SO2 Control C5 Security Business process B3 Business process B1 Business process B2 Business process P2 Control C6 objective BO2 Security objective SO3 Control C7 Business Security Control C8 objective BO3 objective SO4 Security Control C9 process P3 Control C10 Security Security objective SO5 Control C11 process P4 Provides response to ‘Why are we doing this?’ The figure shows how business objectives on the left influence security objectives. Each security objective then has several security controls (C1 to C11) and these are implemented by security processes. Lastly, the business processes are protected by the security processes. Such a model answers two critical questions: a) Do we have all business risks covered? b) Why are we spending money on the security controls?
- 7. Examples of security objectives are: § Establish security governance § Provide security training § Manage access to information § Keep systems resistant to malware § Establish secure systems/applications processes § Monitor systems for security events § Manage security incidents § Monitor security compliance Each security objective then contains a number of security controls. These are typically included in more detailed documents, such as IT Security standards and security artefacts. Examples of security controls are: § Create the training material; monitor attendance of security trainings § Review feedback from security trainings § Manage accounts in the IT systems – create accounts for new users, modify when role changes and delete/disable when account is not longer needed § Install anti-‐malware software; establish and implement secure configuration for each operating system in use; update configurations on systems as per changing threat landscape; patch systems with vendor patches within X days Each control needs to be linked to one or more security objectives. A number of security controls is part of a security process, and each process must have its owner and must be measured. Finally, each security process contributes to the security of a number of business processes. For example, the security process ‘Security configuration & patch management’ ensures that IT systems used in the business process ‘Take order from customers’ runs smoothly and as expected. 3.2. Security standards 3.2.1 International standards for security policy and controls Figure 3 shows business objectives, which will be specific to each company. However, security objectives, whilst supporting the Business objectives, should be selected from a catalogue of internationally recognised ones, and international standards can play an important role. It is important to understand which objectives, controls and processes to take ‘as is’ and where a customisation is needed. Moreover, there might be business objectives and business processes that need controls that are not included in the international standards. Standardisation is needed but should not be applied blindly. Standards such as ISO27001 & 27005, COBIT 4, ISF Standard of Good Practice (both 2007 and 2011 editions) are generally extremely useful. 3.2.2 Information technology standards This document, or set of documents, contains a list of security controls related to the technology used in a company. As mentioned above, these controls are of sufficient detail to describe what is required. Further implementation information is usually included in ‘Guidelines’ or ‘Security Artefacts’. The level of detail included in technology standards will range from high level, such as ‘Implement account creation process to create account within two days of request’, to more detailed, such as ‘Use Windows 2008 R2 server with configuration W2k_DMZ for servers located in the DMZ’.
- 8. 3.3 Security architecture repository Consistency is key in information security. TOGAF 9 has a good approach to standardisation and reusability, as does the SABSA security framework. Standardisation and reusability ensure higher maturity in information security. For this reason, having a library of reusable security architecture components (artefacts) is extremely important. TOGAF 9 defines artefact as: “A product that describes architecture from a specific viewpoint. Examples include a network diagram, a server specification, a use-‐case specification, a list of architectural requirements, and a business interaction matrix. Artefacts are generally classified as catalogues (lists of things), matrices (showing relationships between things), and diagrams (pictures of things) … ” In the context of an information security model, artefacts are re-‐usable for the creation of information security architecture, either a technology (such as ‘We use Cisco firewall and this is how it is configured’) or a process (such as ‘We have standardised our incident response process and this is how it is done’). The technology section of the repository should contain, for example: § Standard set of technologies used in the company (related to security) § Configuration standards for the technologies above (e.g. Windows 7 laptop local security policy object) § Hardening configuration of Web servers, DB servers and other servers. The process section of the repository should contain standard descriptions for security processes, in a detail needed to replicate the process in another part of the organisation, subsidiary or when acquiring another company. From experience, the documenting of processes is not a strong skill base of many IT and information security professionals. 3.4 Process frameworks and metrics 3.4.1 Security processes As stated earlier in this document, and shown in Figures 1 and 3, security processes are an integral part of the security model. For example, ISACA, the organisation behind COBIT, ensures that the default view in COBIT is based on processes, where each process is defined by the objective, stakeholders, maturity levels and controls. Another international standard, ISM3 – now adopted by the Open Group – also sees security processes as key to having mature security systems. Processes in general often have a bad name due to their rigidity and over-‐complex set-‐ups; however, it is important to understand that a process can easily be made complex – it takes skill to create processes that are lean and adaptive. 3.4.2 Security metrics Measuring of processes in any company is one of the key techniques to ensure that inefficiencies are recognised and corrected. Measurement is a product of the industrial revolution; Frederick Taylor published Scientific Management in 1911, a revered work on the capacity of observation and measurement to improve productivity. By the same token, security processes must be observed, monitored and measured to improve them. Security and metrics is a largely neglected area in information security. There are some exceptions, such as COBIT, which brings maturity levels for CIOs and CISOs. Another promising candidate is the Common Assurance Maturity Model (CAMM), which brings information security maturity levels into the supply chain.
- 9. Gartner has researched IT and security metrics, and the relationship between KPI and KRI (Key Risk Indicators). Furthermore, what the business leaders are interested in is: ‘What impact do security controls (or lack of) have on the business processes and the bottom line?’ Security professionals have, for long time, used the FUD (fear, uncertainty and doubt) approach and are now finding this does not resound with their audiences. It is also accepted that maturity of security controls and processes inversely affects risks to the organisation. The problem many security professionals face is in having to justify additional costs to move from maturity level 2 (repeatable) to 3 (defined) and beyond. With this in mind, it would be prudent for organisations to measure: § Basic operational metrics to keep an eye on processes (i.e. do they operate as expected?) § Each security process for its maturity § Value at risk, expressed in £s; a business process is exposed due to low maturity of security controls (or lack of them, as defined by COBIT level 0) The first two metrics are fairly straightforward and well defined. The last one is somewhat new to information security, though used in the financial arena and general risk management1. For the purpose of this paper, it is worth having a look at it in more detail. (i) Value at Risk The main problem that Value at Risk is trying to solve is how to quantify the exposure that an organisation is subject to. Further research into VaR use in information security is needed to make the concept practical and reusable. However, the input elements into the calculations should be: § Business asset value – information assets alone or the value of a business process. A company’s PR image is a business asset and in this case should be assigned a value by consensus rather than measurement § Security process maturity – measure the maturity of process (and included controls) that protect the business asset § Threat landscape – threats change over time; for example, Sony changed the threat landscape greatly by prosecuting George Hotz for breaching the PlayStation T&Cs. In combination with the vulnerabilities in their systems, it cost them dearly. The high level calculation of the VaR is: 1. Measure the maturity of the controls. Assume that maturity level 5 provides 99% (or lower) protection; lower maturity levels provide less protection. 2. Analyse the control to find compensating controls; two low maturity controls may work together to provide higher protection. 3. Analyse the threat landscape and derive the likelihood that the threat agents will attempt to attack. 4. Use the above and the asset value to come up with a probability distribution of monetary exposure The pound value for each asset can be collected and summarised in order to calculate the total exposure probability distribution. This will give CIOs and CISOs a very useful tool to demonstrate the risks to the executive management and thus justify the spending. Detailed calculations of Value at Risk for information security have not yet been developed and need further research. Value at Risk could also be used to justify security investments, i.e. the reduction in VaR should be higher than the cost spent.
- 10. Conclusion Information Security Risk Management must support the business objectives. Security professionals should have open dialogue with business leaders and managers, listen to their concerns, and frequently educate them about risks. The security model can help with explaining why security is important, and can support justifications for that ‘rather expensive’ piece of technology, depending on the point of view, security policy and business appetite for risk. 1 McNeil, Alexander; Frey, Rüdiger; Embrechts, Paul (2005). Quantitative Risk Management: Concepts Techniques and Tools. Princeton University Press. ISBN 978-‐0691122557. About the author Vladimir Jirasek is a passionate information risk professional with more than 16 years of IT industry practise and over 11 years in Information Security and IT Security, Risk and Compliance disciplines. He has both led and managed global teams in Security, Risk and Compliance for multinational corporations such as Nokia, Tesco, and DTAG. In his own time he tries to give something back to the security community by participating in a variety of key industry initiatives, such as the Common Assurance Maturity Model (common-‐assurance.com), Cloud Security Alliance (cloud-‐security.org.uk); and the Open Group’s Jericho forum, working together with industry experts. He can be contacted at vladimir@jirasek.eu or on +44 (0) 7538 790302