Application owners sometimes get confused when doing a follow-up audit after they have implemented all recommendations made in an original audit. Some owners think they can save money on a subsequent audit simply by having an auditor validate the mitigation recommendations were implemented correctly.

Which is 100% correct.
Unless the owner is actually concerned about new vulnerabilities, or land mines to continue with the analogy, that have been introduced into the environment since the last audit.

To put a fine point on this issue, it is possible two activities occurred within the same timeframe, which are:
• The remediation steps were implemented.
• New vulnerabilities or land mines were introduced.
This issue is obviously exacerbated in the case of web facing applications where the consequences of vulnerability can increase exponentially with access.

Calculating the Correct Audit Scope
The correct audit scope is one that has an appropriate return on investment. This is a decision usually made by the IT security steering committee or by an executive management committee.

Since technical IT security details are not relevant to senior management, it is incumbent upon the security analyst to convey the ROI case for the audit cost in terms of cost and risk. Risk, risk appetite and ROI can be evaluated in terms of:
• Estimated costs to the corporation for each instance of a vulnerability being compromised.
• The estimated number of compromises that might occur in a year, depending upon the degree of IT security due diligence performed by the corporation.
• The appetite of the executives for accepting risk.
• The cost of an initial audit and of subsequent audits.
• The ratio of annual estimated total potential downside costs : annual audit costs

Parameters to Scope an Application Audit
Just like all aspects of IT security, which is most effective when deployed in complementary layers, application audits are also performed in complementary layers. These layers are mutually exclusive and one layer does not replace another layer. They are simply different ways to evaluate the security health of an application.

Some of the key layers of a web facing application audit are:

External vulnerability assessment
Core issues are authorization and authentication, susceptibility to failure by overloading with large traffic volumes, application owner’s security reporting on suspect activity, and existence of known vulnerabilities.

Code Review
The goals are to identify the existence of known vulnerabilities, weaknesses in coding architecture, and adequate documentation / commenting in order for an auditor have sufficient understanding of intended logic in order to review the security quality of the code.

Code Lifecycle Review
Identify Critical security flaws which are often found in areas of not incorporating security into the coding architecture, poor or non-existent code change management, and lack of separation of duties between writing code / testing code / handing production code.

Physical Security
Determine the degree to which unauthorized and untraceable access to code is possible, throughout all lifecycle aspects, including storage / transportation (including electronic) and destruction.

Metaphoric land mines abound!

Have a secure week. Ron Lepofsky CISSP, CISM, B.A.SC. www.ere-security.ca

This is the third article in this series on the Methodology of Calculating ROI for IT security

There are three components to the ROI calculation:

1. Identifying actual security risks and translating them into quantifiable business risks.
2. Identifying how to mitigate the security risks, and determining the associated cost.
3. Calculating the ROI as the per cent of cost of mitigation divided by the cost of the risk.  This segment describes how to calculate ROI as the per cent of cost of mitigation divided by the cost of risk.

Calculating the ROI

The totals of the cost of risk and the mitigation costs are used in the following formula:
ROI = mitigation costs divided by the cost of potential risk divided by 100

Or

ROI = % (mitigation costs) / (the cost of potential risk)

Sample ROI business case

A company is implementing a new web based transaction system for their clients to place orders and to enquire about their account balance.  The incremental projected profit from the web site is estimated at $5,000 per day.

To minimize the complexity of the networking infrastructure required for the web site to communicate with a back-end database, the web site will be placed inside a DMZ within the corporate network.  However, the database server will reside on the corporate network.

The CISO wants to understand the total business impact of a security breach on the new web site actually translating into a security event.  She requests the governance committee identify what the potential costs would arise per occurrence of such an event, relating to four (4) specific subjects:

1. Lost profit.
2. Inability of other servers on the corporate network to continue operations.
3. Damage to corporate and brand reputation.
4. Legal consequences.

The governance committee provides the following averaged costs per occurrence of a security event, assuming a two day outage, for the four subjects:

1. Lost profit:     $10,000
2. Inability of other servers on the corporate network to continue operations:     $100,000
3. Damage to corporate and brand reputation:     $800,000
4. Legal consequences:     $200,000
5. Total potential costs. $1,110,000

The CISO then determines that the cost to protect the increase in scope and risk of the infrastructure, over a three years period is $50,000 per year.

The CISO then calculates, per occurrence:

ROI = $50,000 / ($1,110,000 x 100%)

=  5%

Creating an Ongoing ROI Cost Justification Process

Fundamental to ensuring an ongoing adequate security budget is keeping the executive committee fully engaged in the security process. It is incumbent upon the CIO and CISO to educate their executive peers on the principle that security is an ongoing process, and not a onetime event.

As such, as the CISO successfully implements security infrastructure, it is critical they report on the results in terms of the initial business case used to cost justify the process. This can be successfully accomplished by proving with a business case that the investment in security had the planned payback.

An evidentiary approach to providing factual proof to the governance committee is to accumulate statistical proof of potential breaches that were avoided.  These statistics should be collected from the logs of the security technology, which identify risks that were caught, vulnerabilities that were mitigated, and potential security events that were therefore avoided.

It is recommended to communicate this material in simple graph format, showing:

1. The number of incidents ranked by severity plotted against a timeline.
2. The resulting potential losses associated with possible incidents, plotted against time.

My final article in this series will cover outsourcing security monitoring as a cost savings option and a call to action for the entire series.

Have a secure week.

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

ERE Information Security Auditor

www.ere-security.ca