This week’s blog is Part 5 of 5 parts of a series.

You may not have heard of the IT security team called ROSI; it stands for return on security investment.  It’s really the same as ROI but it helps to convey to executives that a business case is being build according to best security practices.

Determining if ROSI Objectives are Met

Tires meet the road when it is time to determine whether or not ROSI objectives for security / policy / compliance have been met.  Conveying this determination is essential to building (or destroying) credibility of the group who made the mitigation recommendations in the first place.

Determining ROSI is quite simple. The actual costs resulting from events are compared with the projected costs after mitigation.  If mitigation was successful, then the actual costs should be near or below the projected costs.  This information can be presented as an updated version of Exhibit 3, shown as

Exhibit 5 – Projected vs. Actual Cost of Losses.  For purposes of accuracy new trends that developed in the security environment over the period of study should be considered.  If new trends increased the cost of losses, and the effect can be quantified, then the results should be reported accordingly.

Exhibit 5 – Projected vs. Actual Cost of Losses  This exhibit can’t be shown in the blog but you can see it in a whitepaper on the ERE web site www.ere-security.ca

Summary

The task of getting approval for a sufficient budget for IT security, privacy compliance, and IT regulatory compliance is usually frustrating and arduous. The task can be made easier by presenting the IT Security Governance body with simple to understand graphics, rather than with complex business plans.  The graphs should depict the relationship between the cost of risk and the cost of mitigation.  The presentation process should occur both at budget request time to show the intended plan, and after the budget cycle to show the actual results.  Hopefully the results trump the plan.

Sources of Information

(1) ANZ 4360:2004 Risk Management Standard http://www.ncsi.com.au/as4360.html

(2) Calculations of ALE are based upon The Official CISSP CBK, 2009, published by ISC2 www.isc2.org

(3) NIST- 88 series http://csrc.nist.gov/publications/PubsSPs.html

(4) ISACA: CISM Review Manual 2010 www.isaca.org

(5) PCI Security Standards – PCI https://www.pcisecuritystandards.org/index.shtml

(6) NERC – CIP 02 – 09 www.nerc.com

(7) ROSI  Calculating Security Return on Investment, Don O’Neil Software Engineering Institute, 2007, CERT

https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/business/677-BSI.html

(8) Gartner whitepaper:“Incorporating Security into the Enterprise Architecture Process, Jan 2006 www.gartner.com

(9) EISA: http://en.wikipedia.org/wiki/Enterprise_information_security_architecture

(10) The U.S. Department of Defense (DoD) Architecture Framework (DoDAF) http://www.architectureframework.com/dodaf/

(11) Extended Enterprise Architecture Framework (E2AF) from the Institute For Enterprise Architecture Developments. http://www.enterprise-architecture.info/

(12) Federal Enterprise Architecture of the United States Government (FEA) http://www.whitehouse.gov/omb/e-gov/fea/

(13) Capgemini’s Integrated Architecture Framework

http://www.capgemini.com/services-and-solutions/technology/soa/overview/ent_architecture/iaf/

(14) NIH Enterprise Architecture Framework http://enterprisearchitecture.nih.gov/About/Approach/Framework.htm

(15) Open Security Architecture ]http://www.opensecurityarchitecture.org/cms/index.php

(16) The Open Group Architecture Framework (TOGAF) http://www.opengroup.org/architecture/togaf8-doc/arch/

(17) Zachman Framework http://www.zifa.com/

(18) Control points from the COBIT framework.  http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=7981

Have a secure week.

Regards, Ron Lepofsky, B.A. SC. (Mech Eng), CISSP

ERE Information Security and Privacy Compliance Auditor

www.ere-security.ca

This week’s blog is Part 4 of 5 parts of a series.

If you are in security no doubt you have been challenged by management about your security expenditures.  I have often heard executives say that they regret authorizing sufficiently large security budgets because they can’t tell if the expenses were worthwhile.  It’s a good point.  I’ll try to address it in this blog.

Measuring the Effectiveness of Mitigation

It is paramount to close the risk management loop by comparing planned and actual results of mitigation.

Goal is to clearly identify if risk level has changed and what consistent metrics will be used to base a conclusion. Once again, this may be difficult to accomplish directly, but there certainly are metrics for measuring and comparing the results of implementing mitigation. The metrics should always:

1. Produce repeatable, consistent results.
2. Be understandable.
3. Be reasonably simple to use over time.

The following is a good starting list of metrics that can be used for consistently measuring and reporting on risk:

1. Architectures for measuring risk – Enterprise Information Security Architecture (EISA) (8), (9)
   1. a. The U.S. Department of Defense (DoD) Architecture Framework (DoDAF). (10)
   2. Extended Enterprise Architecture Framework (E2AF) from the Institute For Enterprise Architecture Developments. (11)
   3. Federal Enterprise Architecture of the United States Government (FEA).  (12)
   4. Capgemini’s Integrated Architecture Framework. (13)
   5. NIH Enterprise Architecture Framework. (14)
   6. Open Security Architecture. (15)
   7. The Open Group Architecture Framework (TOGAF). (16)
   8. Zachman Framework.  (17)
   9. Control points from the COBIT framework.  (18)
   10. Vulnerability assessments.
   11. Penetration tests.
   12. Time trends in frequency of occurrence and the real costs of security events, privacy violations, and policy compliance violations.
   13. Time trends in cost to recover from events.
   14. Time trends in frequency of policy compliance violations that do not necessarily cause any financial losses, such as identifying Trojans, viruses, rootkits, unauthorized logins, attempted port scans, frequency of dropped packets, frequency of password lifecycle, breaches, and frequency of rescheduled / cancelled IT Security Governance meetings with business managers.

This part of the series may be a little dry.  In fact it is very dry.  But if you ever want to have a process done “by the book” many of my references will come in handy.  If you can take another “dry” blog, the next blog will cover the same subject but from a return on investment perspective.  I hope it will be helpful!

Have a secure week.

Regards, Ron Lepofsky, B.A. SC. (Mech Eng), CISSP

ERE Information Security and Privacy Compliance Auditor

www.ere-security.ca

This week’s blog is Part 3 of 5 parts of a series.

I think that too often security people try to “fix” every security problem.  That is not realistic or required.  Many times, it is sufficient to just identify security risks and problems to management and get them to make a decision on how they want to deal with it.

But the operative phrase is “decision on how they want to deal with it.”

Calculating the Cost of Mitigation

Security professionals are well acquainted with determining the costs of mitigation.  Senior executives sometimes think they too are familiar with these costs, based upon ads they read about anti-virus and firewall technology.

The danger here is that it is too easy for all concerned to focus on technology as the primary mitigation for security and compliance.  It is well documented in standards published by industry experts such as NIST- 88 series (3), ISACA CoBIT (4),  PCI Security Standards – PCI (5),  and NERC – CIP 02 – 09 (6).

It is well advised to consider mitigation steps that include:

1. Re-engineering processes, both technological and people processes.

2. Policy – people and technology

3. Technical security.

4. Physical security.

5. People processes.

6. Training and awareness.

7. Third party auditing to verify the effectiveness of all the above.

From an IT Security Governance perspective the optimal cost point for mitigation is where the total costs of risk and mitigation are lowest.  This point can be graphically determined as in Exhibit 3 – Optimal Cost Point for Mitigation.

Exhibit 3 – Optimal Cost Point for Mitigation (3) This exhibit can’t be shown in the blog but you can see it in a whitepaper on the ERE web site www.ere-security.ca

Once mitigation costs are determined, it is important to express to the IT Security Governance committee that mitigation only goes so far, and that some residual risk remains even after spending on mitigation.  The residual risk can be expressed as the cost of risk that remains after mitigation is implemented.  As shown in Exhibit 4 – Mitigation Cost vs. Chance of Event Occurrence, expenditures on mitigation reduce the cost of exposure to risk.

Exhibit 4 – Mitigation Cost vs. % Chance of Event Occurrence This exhibit can’t be shown in the blog but you can see it in a whitepaper on the ERE web site www.ere-security.ca

The IT Security Governance Committee may decide to deal with residual risk by:

1. Accepting the risk.

2. Moving the risk (insurance).

3. Further mitigation.

Calculating Return on Security Investment (ROSI) (7)

Once the total cost of security mitigation is determined by including any costs for managing residual risk, then it is straightforward to calculate the return on security investment, as follows:

ROSI = cost of mitigation  /  cost of risk

When calculating ROSI it is important to allocate mitigation costs on a pro-rated basis across all costs of risk to which they apply.  In this way ROSI can be more accurately calculated and evaluated by each profit and loss manager and associated stakeholder.

The next blog will deal with figuring out if the cost of mitigation were worth it!

Have a secure week.

Regards, Ron Lepofsky, B.A. SC. (Mech Eng), CISSP

ERE Information Security and Privacy Compliance Auditor

www.ere-security.ca

This week’s blog is Part 2 of 5 parts of a series.

I know it is time consuming to do the analysis for building a business case.   I’ve seen the frustration on the faces of security types who present business cases for their budget and management gives them a rough time.

Hopefully these articles will be helpful.

The next logical step would be to associate an actual cost to each event. Various methods can be used either separately or together with the implementation of an averaging metric to estimate the cost per occurrence of an event.  These methods may include:

1. Soliciting expert advice from financial management, lawyers, and risk management consultants.

2. Conducting a straw poll of stakeholders, each estimating the downside cost of an event.

3. Participating in a fact gathering survey of similar businesses, each of which provides factual and straw poll estimates of the cost of an event.

4. Purchasing statistical information from industry experts regarding the cost of an event.

5. Obtaining statistical information from industry associations about the cost of an event experienced by their membership.

Using a similar methodology, the next step is to determine the likelihood of an event occurring.  The most useful ways of expressing likelihood is in % chance of an event occurring in any one year.

However, any likelihood estimate should also be adjusted to account for changes in security environment.  There are typically evolving waves of new threats that may affect likelihood of occurrence, such as these previous waves:

1. Viruses

2. Malware of all sorts

3. DDOS

4. Identity Theft

The likelihood estimate can then be used to:

1. Qualitatively express cost vs. likelihood as in Exhibit 1 – Potential Cost vs. % Probability of Occurrence.

2. Calculate the quantitative Annual Loss Expectancy.

Exhibit 1 – Potential Cost vs. Probability of Occurrence (1)

This exhibit can’t be shown in the blog but you can see it in a whitepaper on the ERE web site www.ere-security.ca

Obviously want to prioritize the mitigation steps to dealing with high risk / high cost situations first.

Annual Loss Expectancy (ALE) (2)

The step from qualitative to quantitative risk analysis logically occurs at this point, where the team evaluating risk triages the results of Exhibit 1 in order to decide upon those risks where they intend to focus.

The potential cost of those risks can be determined by calculating their Annual Loss Expectancy.  The annual loss expectancy is the annualized estimated cost for the occurrence of any type of event.  This number is useful for comparison with the annual cost of mitigation.  ALE for an event is calculated by multiplying the previously determined of the cost of the event and the chance of its occurrence.

Annual loss expectancy = cost of event x chance of occurrence

Next week I will discuss the ins and outs of calculating the cost of minimizing risk and how to present this to the executives.

Have a secure week.

Regards, Ron Lepofsky, B.A. SC. (Mech Eng), CISSP

ERE Information Security and Privacy Compliance Auditor

www.ere-security.ca