ww.sciencedirect.com

i n f o rm a t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e8

Available online at w

www.compseconl ine.com/publ icat ions/prodinf .htm

Practical application of information security models

Vladimir Jirasek*

United Kingdom

* Tel.: þ44 07538790302.E-mail address: vladimir@jirasek.eu.

1 John Boyd, a father of hornets, ooda-loop1363-4127/$ e see front matter ª 2011 Elsevdoi:10.1016/j.istr.2011.12.004

a b s t r a c t

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.

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.

ª 2011 Elsevier Ltd. All rights reserved.

1. Introduction introduces the topic of information security to business

I am passionate about information risk security management.

It is an area that is like shifting sands, constantly moving with

new threats, standards and technologies. I remember my first

entry to the works of IT security in 2000 when I configuredmy

first firewall. Then it was all about technology for me. Looking

back I can see how wrong I was. The information security is

a part of information risk management, which in turn has

a place in the business risk management. This shift in

approach enables clever information security professionals

talk similar language as business people; those who actually

bring money to the company.

Unless security professionals understand that technology

is not a holy grail of their jobs they will be left standing aside

and always struggle to promote the need for additional

investment. As someone clever1 said: “It is all about People,

Process, ., Technology”. I will cover the security model that

support business needs and how security professionals can

change their attitude to stay in their jobs.

2. Introduction to the security GRC model

As part of the security architecture work I have put together

the following information security model. The model

said “people, processesier Ltd. All rights reserved

managers and CIOs (Fig. 1).

In the model there are three main areas:

� Security drivers

� Security management (the main part)

� Stakeholders

3. Security drivers

Clearly, If there were no drivers then we would not need to do

any security. There are three major drivers for security work:

1. Laws & regulationse These are something than a company

must complywith or face legal action or a fine. For example,

complying with the Data protection law or the Company

Act law is an example of the legal drivers. Complying with

PCI DSS is an example of regulation drivers.

2. Business objectives e The company typically wants to

generate profit and defines a set of business objectives.

Security supports these business objectives by protecting

systems and information that is used in the business

processes. Think of protecting Microsoft Windows source

code: If the source code was not protected I could have

and technology e and in that order!”.

Fig. 1

i n f o rma t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e82

complied my own operating system without paying

Microsoft any license fee. Hence Microsoft business

objecting “Sell software” is supported by “Protect source

code” security objective. Amazon’s business objective is to

sell products in their on-line shop. The business objective is

to have on-line shop up 24/7. Security objective is to keep

systems up and running, be it by keeping them free of

malware that could disrupt or slow IT systems, or keeping

attackers at bay.

3. Security threats e a tricky one in this context. Security

threats work against laws & regulations and business

objectives. However, they are driving information security

aswell and company needs to respond to threats in order to

satisfy first 2 drivers.

4. Security management

In this areawe have three frameworks that enable company to

achieve objectives defined in the drivers section.

4.1. Policy framework

This is a set of policies, standards and guidelines that describe

how the company addresses information security drivers. All

together these define security controls that are available for

a company to implement. There are also International stan-

dards which can be source of information and controls for the

Policy framework.

a. Policies e describe high level to detail policy statements,

aka Security Control Objectives (typically using words

should and must). The key objective of the security policy

document is the alignment with the business objectives

and drivers. I have seen security policy being a simple copy

of ISO27001 Annex A document, without actually

describing why individual control objectives have been

selected. It is then very difficult to justify investment into

something which “is compliant with a policy” but does not

support business objectives.

b. Standards e detailed Security controls that should be

implemented to support individual policy statements. I

see the relationship and 1:N here, I.e. One policy state-

ment can be supported by multiple security controls.

Again, without a link to a policy, the security profes-

sionals will hardly justify why the password needs to be

12 characters and change every 45 days. The controls

should be selected from an internationally accepted

catalogue of controls (see chapter on International

standards).

c. Artefacts e It is all very well to have statements like “must

be authenticated” but how is that done in practice by an

engineer that actually needs to configure the system? I

have learnt that architecture standardisation is the key to

the success of any company. Same applies to security. If I

find a solution to implement a security control from the

“Standard” I will put it into a “Security Architecture

Repository”. That way, someone else can benefit from my

experience, and more importantly, achieve consistent

security. Far too many security professionals do not

i n f o rm a t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e8 3

document these into a shared library, which results in

problems when they leave the company.

4.2. Processes framework

This section in the Security management implements what is

stated in the Policy framework. Any security control in a policy

or standard is a process, no exceptions. This is where people

and technology come into play. Each process is supported by

people andmost are supported by technology. However, there

needs to be link between any technology the company has, its

process, corresponding control in the Policy framework up to

the business objective. This enables traceability of the security

investments and allows security professionals to justify the

security budgets.

4.3. Security metrics framework

This is rather, in my view, still developing area of information

security management. A proliferated statement “What you

cannot measure, you cannot manage.” can be applied in

security as well. Security professionals should be able to

measure the status of security controls, compliance with own

policies and effectiveness of security processes. My key

metrics here is to take a security policy statements and

measure each team against them; this turns into a nice

balanced scorecard for security.

The metrics framework provides feedback to the process

framework with the necessary metrics information to run the

security processes as designed.

5. Stakeholders

Stakeholders, for example classified using TOGAF method-

ology, 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

professional need to show the value of security to business.

This is the area where security professionals need to enhance

their skills. Talk to your stakeholders, ask them what their

concerns are and show them how you are addressing the

concerns. Then send a report to them that relates to their area

and concerns. Get them on your side!

Let’s now look into the model in more detail.

2 http://en.wikipedia.org/wiki/Parkerian_Hexad.

6. Security drivers

6.1. Business objectives

We, security professionals, exist to support the business. The

companies are driven by its vision and mission statements,

translated to business strategies that describe how to achieve

that vision. The business objectives define how the organisa-

tion want 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 customers.

This clear link between business and security objectives is

sometimes missing.

Let’s look at practical example.

A telecommunication company sells mobile phones and

call plans to its customers. One of its objectives is to “Deliver

outstanding customer service, measured by customer satis-

faction”. This objective is supported by a business process

“Customer service”. In this process customer service repre-

sentatives, in shops, call centres and on-line, talk to

customers and solve their problems and answer questions.

The customer satisfaction is dependent on a) speed to initial

contact, b) completeness of the response.

The information security risks identified are: 1) Infor-

mation systems unavailable or slow so the initial response

time is affected, 2) the information in the knowledge base

system is inaccurate, and 3) the customer data in the CRM

system becomes compromised resulting in a fine and PR

impact.

From this quick risk analysis it is easy to understandwhere

the information security policy needs to focus and what the

security objectives should be.

6.2. Legal and regulatory requirements

Additionally, the businesses need to comply with legal, regu-

latory and contractual requirements listed in the defending

order of impact). The legal requirements are typically related

to the way the company is governed, how it prepares its

accounts and how it protects the personal data. In the UK, the

Company Act 2006, “part 15 Accounts and reports”, states

clearly the requirements how accounts are created and

reported. It also includes penalties for untrue and misleading

accounts. In the USA, the Sox legislation was created after

major financial scandals. The Data protection directive, Prin-

ciple 7, states that access to the data must be limited to the

authorised persons. And although the Data protection direc-

tive does not state which security controls should be imple-

mented, the guidance states that there are internationally

accepted standards to build information security system in

a company.

As a result of the aforementioned legislation the informa-

tion security system implementation needs to protect data

and information systems so they are:

a) accurate (in security terminology “Integrity” is used),

b) available,

c) and access to the content is assured (“Confidentiality” is

used in the security terminology).

Such a view is using CIA (Confidentiality, Integrity, Avail-

ability). A more granular and modern view on security prop-

erties is Parkerian Hexad.2 It talks about six security

properties:

a) Confidentiality e same as in the CIA model,

b) Possession or Control e the possession of the information

is lost (for example someone steels the encrypted USB

stick) but the data is not revealed,

i n f o rma t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e84

c) Integritye the data has not been tamperedwith. This does

not validate the data correctness,

d) Authenticity e verifying the origin of the data is that of the

claimed. For example, using digital signatures to validate

the creator of the information,

e) Availability e having timely access to the information;

same as in the CIA model,

f) Utility e is the data useful for what I need it for?

6.3. Security threats

On its own the Security threat are not a security driver.

However, in the context of the above, the security threats

affect the level of protection, i.e. Controls, is needed. The

threats come from attackers who want to either acquire the

information, limit business opportunities by affecting busi-

ness processes or simply cause embarrassment of the

company. If there were no security threat, we not need to

implement any security controls! Unfortunately, that is not

the case. Microsoft has created very good methodology

(STRIDE) for assessing threats and designing the security

controls to disrupt the threats harming the business

processes. The role of security model is to capture the security

threats and design security objectives and controls so the

Fig. 2

threats do not harm the business. The Security intelligence is

a capability to analyse the security threats and advise what

security controls should be included in the policy framework.

7. The policy framework

This is the first part 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.

Let’s look at Security policy structure in the Fig. 2 below.

7.1. Information security policy

At the top level there is Information Security Policy. This is

a high level document. The primary objective of this docu-

ment 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 of

the company. The board approval is key as the board approves

the business strategy and objectives, hence the protection of

the business objectives is in the board interest.

i n f o rm a t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e8 5

7.2. Data classification policy

The top level policy should also make provision for data

classification scheme, which can then be detailed in the Data

classification policy. The data classes depend on the business

nature but should at least include:

1. “Public” e data that are in the public domain. The mistake

people make here is to assume that public data do not need

any protection. Take example of a company homepage.

This is typically information that company want to share

with the world. Hence it is classed as Public. But what

happens in the information on thewebsite changes without

authorisation? The examples can range fromdefacing of the

websites, unintentional mistakes by employees, mixing the

product description, changes in the prices of the products.

The Public information usually needs to be “Accurate” and

“Available”. By definition there is no requirement to keep

the information secret (Confidential).

2. “Company wide” e This type of the information can be

shared between employees and persons that signed the

NDA. This is by far the largest category of information in

most organisations. It is also called “Semi-Public” and the

bigger the organisation the bigger probability of leak from

the employees or partners.

3. “Restricted access” e Some information should be acces-

sible on need-to-know basis. This completely depends on

the business nature. Business plans, strategy, research

data, new product details are just some examples of the

information that should be well protected.

The data classification should reflect business need. The

modern implementations of the data classification should

include claim based rules. For example, if I create a document

classed “Restricted access for the teammembers of the project

X”, then I expect the system to simply check that the use is

avalidandcurrentmemberof theprojectX team.TheFacebook

uses similar systems in the recently updated privacy settings.

7.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 thorn at

them. The objective of this document is to show employees

what is critical and where to find more information.

7.4. Information technology security policy

Most companies rely on information technology to run the

business processes. The role of CIOs has become to supporting

business, understanding where the company want to expand

and suggesting how to become more agile and costs effective.

The Information technology can be saviour or nightmare, all

depends on ability of CIO.

The security policy on the CIO level is targeted at the CIO’s

organisation. It needs to translate business objectives into

Security objectives and controls, as showed on the Fig. 3 below.

The Fig. 3 shows how Business objectives on the left

influence Security objectives. Each Security objective than has

several Security controls (C1 to C11) and these are imple-

mented by Security processes. Lastly, the business processes

are protected by the security processes. Such amodel answers

two critical questions:

A) Do we have all business risks covered?

B) Why are we spending money on the security controls?

Examples of Security objectives are:

� Establish Security governance

� Provide security training

� Manage access to information

� Keep systems resistant to malware

� Establish secure systems/applications process

� 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 docu-

ments, such as IT Security standard and security Artefacts.

Examples of security controls are:

� Create the training material; Monitor attendance of security

trainings; Review the feedback from security trainings

� Manage accounts in the IT systems e create accounts for

newusers,modifywhen the role changes and delete/disable

when the account is not longer needed

� Install anti-malware software; establish and implement

secure configuration for each operating system that is in

use; Update the configurations on systems as per changing

threat landscape; Patch systemswith vendor patcheswithin

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. Each process must have its owner and must be

measured.

Finally, each security process contributes to security of

a number of business processes. For example, security process

“Security configuration & patch management” makes sure

that IT systems used in the business process “Take order from

customers” run smoothly and as expected.

7.5. International standards for security policy andcontrols

The Figure shows Business objectives. These are very much

specific to each company. However, the Security objectives,

while support the Business objectives, should be selected

from a catalogue of Internationally recognised ones. This is

where international standards play an important role. Why

would an organisation reinvent the wheel and design their

own objectives, controls and security processes when the

clever people have done it for them. However, 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 needs controls that are not included in the international

Fig. 3

i n f o rma t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e86

standards. Standardisation is needed but should not be

blindly applied! The standards need to adapted by the

companies to fit their mode of operation.

In my professional life I have used standards such as

ISO27001 & 27005, COBIT4,3 ISF Standard of Good Practice

(both 2007 and 2011 editions).

7.6. Information technology standards

This document (set of documents) contains a list of security

controls related to technology used in a company. As

mentioned above these controls are of the sufficient detail to

describe what is required. The further implementation infor-

mation is usually included in the Guidelines or Security

Artefacts.

The level of detail included in the Technology standards

will vary from high level such as “Implement account creation

process to create account within 2 days of the request” to

more detailed such as “Use Windows 2008 R2 server with

configuration W2k_DMZ for servers located in the DMZ”.

7.7. Security architecture repository

Consistency is key in the business processes and the same

applies for information security. I have been using TOGAF 9

3 http://www.isaca.org/cobit.

for some time now and I like its approach to standardisation

and reusability. Same approach is exercised by following

SABSA security framework. Standardisation and reusability

are key to higher maturity in information security. For this

reason, having a library of re-usable security architecture

components (artefacts) is rather important.

TOGAF 9 defines artefact as

“An architectural work product that describes an 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 catalogs (lists of things), matrices (showing

relationships between things), and diagrams (pictures of things).”

In the context of information security model, the artefacts

are something that is re-usable for creation of information

security architecture. This can be either a Technology (such as

“We use Cisco firewalls and this is how it is configured”) and

Processes (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 (for

example Windows 7 laptop local security policy object)

� Hardening configuration of Web servers, DB servers and

other servers

4 https://common-assurance.com.5 McNeil, Alexander; Frey, Rudiger; Embrechts, Paul (2005).

Quantitative Risk Management: Concepts Techniques and Tools.Princeton University Press. ISBN 978-0691122557 (http://www.amazon.com/Risk-Analysis-Quantitative-David-Vose/dp/047199765X).

i n f o rm a t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e8 7

The process section of the repository should contain

standard process descriptions for security processes, in

a detail need to replicate the process in another part of the

organisation, subsidiary or when acquiring another company.

From the experience, the documenting things is not a

strong part ofmany IT and information security professionals.

7.8. Security guidelines

This section of the policy framework is options. This should be

developed for specific audience for example “How to operate

the firewall systems”. The title guidelines suggest these are

option, non-mandatory statements.

7.9. Process framework

As stated earlier in the document and shown on the Figs. 1 and

3, the security processes are an integral part of the security

model. For example ISACA, the organisation behind COBIT,

believes this so the default view in the COBIT is based on

processes. Each process in COBIT is defined by the objective,

stakeholders, maturity levels and controls.

Another international standards, now adopted by Open-

Group, ISM3 also sees security process as key to having

mature security systems.

Processes in general have had sometimes bad reputation

due to rigidness and over complex setups. It is important to

understand that a process can bemade as complex as you like

very easily, but it takes skills to create processes to be lean and

adaptive.

Examples of security processes that an organisation should

most likely operate:

� Security training e though this could be part of general IT

and company wide training.

� Security monitoring e monitor events in systems and look

for anomalies and security incidents.

� IncidentmanagementeManaging security incidents in calm

and organised way. Should also include forensic capability.

� System hardening e includes configuration and patching of

systems. Should be part of company change management

process.

� Secure development/acquisition e following best practises

when developing information systems, either internally or

acquiring fromexternal party. Thisneeds tobepart of project

management process and considered as quality issue.

� Reporting e collecting various data and presenting it to

stakeholders in a format and detail they need and

understand.

� Account and Access management e Managing active users

account in systems and their access to the systems and data.

7.10. Security metrics framework

Measuring of processes in any company is one of the key

techniques to make sure that the inefficiencies are discovered

and corrected. Measurement is a product of the industrial

revolution. For example Frederick Taylor, who published

Scientific management in 1911, emphasised observation and

measurement in order to improve productivity.

By the same token, the security processes must be

observed, monitored and measured to improve them.

The 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 Common Assurance Maturity

Model (CAMM),4 which brings information security maturity

levels into the supply chain.

There is a lot of research by Gartner about 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 security controls (or lackof) haveon thebusiness

processes and the bottom line.” Security professionals have for

long time used FUD (Fear, Uncertainty and Doubt) approach

and are now finding this does not make their audience tick.

It is also accepted that maturity of security controls and

processes inversely affect the risks to the organisation. The

problem many security professionals have how to justify the

additional cost tomove frommaturity level 2e repeatable to 3

e Defined and beyond.

Hence I suggest that each organisations measures:

1. Basic operational metrics to keep an eye on processes e do

they operate as expected

2. Each security process for its maturity

3. Value at Risk, expressed in £, a business process is exposed

to due to low maturity of security controls (or lack of them

as defined by COBIT or CAMM level 0)

The first two metrics are fairly straight forward and well

defined. The last one is a somehow new to information

security, though used in financial space and general risk

management,5 so let’s have a look at it in more detail.

7.11. Value at risk

Themain problem the Value at Risk is trying to solve is how to

quantify the exposure that an organisation is subject to. The

research into VaR use in information security is needed to

make the concept practical and re-usable.

The input elements into the calculations should be:

� Business asset value e this can be information asset on its

own or the value of a business process. Public relation image

is a tricky business asset and in this case it should be

assigned a value by consensus rather then measurement.

� Security processmaturityemeasure thematurity of process

(and included controls) that protect the business asset

� Threat landscape e threats are chugging over time and with

the motivation. For example, Sony changed the threat

landscape greatly by prosecuting George Hotz for breaching

the Playstation T&C. In combinationwith the vulnerabilities

in their systems, it cost them dearly.

i n f o rma t i o n s e c u r i t y t e c hn i c a l r e p o r t 1 7 ( 2 0 1 2 ) 1e88

The high level calculation of the VaR is:

1. Measure the maturity of the controls. Assume that the

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 control may work together to provide higher

protection.

3. Analyse the threat landscape and derive likelihood that the

threat agents will attempt to attack. This is mostly the

guesswork as you need to analyse different actors and their

abilities and motivation.

4. Use the above and the asset value to come up with a prob-

ability distribution of monetary exposure

The monetary value for each asset can be collected and

summarised in order to calculated the total exposure proba-

bility distribution. This would give CIOs and CISO very good

tool to show the risks to the executive management and

justify the spending.

The detailed calculations of the Value at Risk for infor-

mation security have not been developed yet and need further

research.

The value at Risk could be also used to justify security

investments, i.e. the reduction in VaR should be higher than

the cost spent.

8. Conclusions

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. It also supports justifications for that “rather

expensive” piece of technology that we all want to play with;

or does it? Well, it depends on the point of view, security

policy and business appetite to the risk. Main message to

security professionals from me is: “Adapt or find new job”.