|
There are two camps when it comes to demonstrating ROI for security initiatives. One camp believes it is absolutely impossible, ridiculous and suggests you should not even try. The other camp believes it is not only possible but important and absolutely necessary. Somewhere in the middle is a plausible methodology for demonstrating ROI for many security initiatives, including penetration testing.
In part one of this series we discussed the necessity of understanding financial terms in relationship to justifying security expenditures. We also discussed the idea of aligning security initiatives with productivity enhancing and revenue generating initiatives. In particular, we used the example of a VPN (Virtual Private Network) initiative and the example of a Pen Test piggybacked on a Web-based project initiative. For the purpose of this series we are going to focus on demonstrating ROI specifically for penetration testing, however it is important to understand that the ROSI (return on security investment) discussion can apply to to a broader range of security services and products.
Security Risks vs. Business Risks
The skeptics believe that security risks and business risks are two different things. ROI applies to business risk where the business makes a voluntary choice on a particular initiative and expects the return to be positive, such as for the web-based ERP example discussed in the previous article. Security risk on the other hand is an unknown quantity where the business cannot make a voluntary choice, but hopes to reduce risk and guard against potential loss by implementing safeguards and following industry best practices. There is a many-to-one and one-to-many relationship between risks and safeguards, so it is seemingly difficult to compute the actual risk vs. cost of the safeguard. Additional factors that complicate our efforts are the speed at which technology changes, the increasing sophistication of hackers and their tools, and the increasing complexity of networks as we move towards an "always on" interconnected society. There is the common understanding that people knowingly or unknowingly circumvent security systems that are put in place. In short, there are many variables and uncertainties in calculating risk.
Are we barking up the wrong tree?
Suppose that trying to prove a return on investment for security initiatives is a flawed objective. Can we then make the case for adding value to a project or process, which has itself been calculated to provide a return on the investment? Of course. However for argument's sake, let's first assume we are not operating with a flawed objective. Can we value the business in terms of the sum of its parts, one part being Information Assets (IA)? Can we breakdown the value of each part by showing how each IA contributes to the support of a single revenue generating customer?
In the case of supporting a customer, there is engineering, marketing, sales, R&D, IT, general management, professional services, and yes, security, which all contribute to the revenue from customers who trust you and want to do business with you. Take the trust issue a bit further. Your customers do business with you not because they have to, generally speaking. They do business with you because they trust you for a variety of reasons. One of those reasons could be their belief that you have performed due diligence in regards to security issues. Securing the enterprise starts to look like a marketing effort, a reputation enhancer, a way to bring in new business?.. could it be connected to revenue generation? It's a stretch, but it's possible! You can break this down anyway you want, but if you do you will be surprised to find that some cost centers (IT, security, administration) can be directly correlated to revenue generation, cost savings, and productivity gains.
Popularity of Penetration Testing
Penetration testing is becoming an accepted practice for testing the security of web-based ERP implementations. Secure coding methods are becoming standardized. Building security into the project lifecycle is becoming more a forethought rather than an "uhoh!". The deployment of a secure system should be one of the project goals, in the same way that meeting system performance objectives or making use of a particular technology are. For example, say the organization takes a business risk based on ROI calculations for implementing the web-based project example from part one of this series. Penetration testing needs to be one of the project milestones in the same way that performance and system test is. If you have this opportunity, use it to your advantage, grab a portion of the funds and get the penetration test done.
But what if you are the security professional and you are trying to prove to management that a penetration test needs to be part of an already completed project? This is more difficult but still possible. You must use the language of business and think like the CxO.
In either example, security initiatives must align with the goals of the business and the bottom line of profitability in order to become part of return on investment scenarios. If security initiatives could be understood in terms of user productivity, revenue per employee, business cost reduction, cycle time improvements as well as risk reduction, we could move forward in our justification. First we need to define and understand penetration testing and its goals, how it relates to an overall security assessment, and common penetration testing techniques. It is also helpful to define and understand Risk Management concepts as they relate to Information Asset valuation.
Information Assets
Penetration testing is a subset of a security posture assessment. Its goal is to gain access to software systems that require authorized access. Access could be gained to operating systems, applications, or database servers which can be defined as Information Assets. Here's the critical shift that needs to occur in your thinking: If the penetration test succeeds, you gain unauthorized access to an Information Asset. What you do with that asset depends upon the goals of the penetration test. Are you going to steal the asset, corrupt the asset or make it otherwise useless, use the asset as a springboard to another more critical asset, or make the asset unavailable for use by the business? The goal of the test is to penetrate the security systems in place, exploit a weakness, document the exploit, clean up and get out. A Pen Test project scope should include a description of what Information Assets you are trying to gain access to including the value of those assets to the organization, what methods you are going to use, what the success criteria looks like, what you are going to do when you gain access to them, how you are going to do your work in a manner that does not jeopardize the assets, and how you are going to deliver results.
You must understand the value of the Information Assets to the organization in order to sell the value of the test. You must also be ready to "connect the dots" for the business so that they can understand, for instance, that an attack on a particular asset leads to an attack on another asset and so on.
Penetration Testing Techniques
There are many excellent articles and books written on how to conduct a Pen Test, so I'm not going to fill space here regurgitating that information. Suffice it to say that consulting companies all do it differently. Some companies have highly defined processes and a specific toolset that they use. Others use consultants who have a "hacker mentality" and vary their process and toolset dependent upon the type of test, type of target environment, level of difficulty, and their own experience. There are some basic steps involved: goal definition, information gathering, vulnerability detection, planning the actual test, exploiting the weaknesses found (attack and penetration), followed by results reporting and clean up.
Here is what penetration testing is not: vulnerability scanning, full security assessment, ethical hacking, or intrusion. A Pen Test is a highly defined test with specific parameters whose goal is to gain unauthorized access to Information Assets. A Pen Test can be part of a full security assessment, but is often performed as an independent function. If you don't already have a solid understanding on this topic, suggested books to read are: Hacking Exposed: Web Applications by Joel Scambray and Mike Shema (McGraw Hill), John Chirillo's books on Hacking (Wiley), and of course the entire Hacking Exposed series including Web Hacking Attacks and Defense by McClure, Shah and Shah (Addison Wesley). The thing to take from these is the idea that definitions, methods, and tools vary. It is more important to define the goals of the test, understand the value of the information assets, and associate your results to risk management, as well as the goals of the business.
Information Asset valuation
Information Asset valuation is part of a Business Impact Assessment (BIA). There are quantitative and qualitative measurements that allow an organization to assess the worth of an asset. As we have discussed, prior to conducting a Pen Test the value of the target asset needs to be known in order to present the value of the Pen Test. Asset valuation is performed during a cost/benefit analysis, is often necessary for insurance purposes, certainly affects the selection of safeguards, and is important for legal reasons to demonstrate "due care".
For organizations that have completed a BIA, the Pen Tester's job is facilitated. For organizations that have not completed such an assessment, here's a pitch for doing so. The basic components for determining an asset's value are: understanding the initial and ongoing cost of purchasing, licensing, developing, and supporting the asset; understanding the value to production, R&D, and business model viability; the estimated value of the asset in the external market including intellectual property, patents, or copyrights. If an organization is marketing the fact that they are the only company offering xyz via the web, that's a sure invitation to get hacked. Let me say it another way: if your business model is to provide information and services, such as payroll, benefits or insurance via the web in a way that has never been done before (through value added services), you had better be offering those services in a secured manner or you may wake up to an unhappy situation. Most companies don't advertise their security initiatives, keep a low security profile when possible, and hope to fall under the radar. It's the ostrich approach. However, folding security into everything you do secures your e-commerce future.
Risk Management concepts
The concept of demonstrating ROI begs to move away from risk management concepts, however it is important to understand what you are trying to move away from. Risk management is composed of understanding what the risks are by performing a risk analysis and then implementing, reviewing, and maintaining the appropriate safeguards based on the valuation of assets. One of the chief complaints against trying to demonstrate ROSI is that the goal of security objectives is to minimize risk, not provide revenue generation, cost reduction, or increase productivity. If a security breach were to occur which results in the loss of a particular Information Asset or a disruption of business, there will be reduced revenue generation, increased costs and loss of productivity. Risk management seeks to prevent loss. Later in this series we will more closely define standard risk management formulas and practices, but for now we are seeking a way to change our cost-center way of thinking. How can security initiatives, such as Pen Testing, have positive impact on revenue generation, productivity gains, and cost reduction?
Risk Management vs. ROSI
This is the crux of the problem. Are we going to view Pen Testing purely in terms of risk management or are we going to view it as having a return? Look at it this way: If an organization is successful in identifying Information Assets, assigning value as it relates to hard costs and intangible costs, and then analyzing the cost/benefit of every Information Asset, that becomes the halfway point. The next step is to determine what safeguards need to be put in place to protect the asset(s) and calculate the cost of purchase, installation, maintenance and support. In our example of the web-based project, a Pen Test is part of the process for determining what safeguards need to be in place. The results of the test provide data on what the Exposure Factor is. From those results, industry reports can be consulted to get some feeling for the level of risk that can be associated with the particular exposure(s) and how often such an exposure can result in financial loss. Finally, subtracting the total security investment cost from the damage likely to be prevented provides ROSI. The skeptics of course state that there is not enough recorded, accurate and reliable data to date from which an Annual Rate of Occurrence can be forecasted. However that situation is improving as more and more organizations become willing to report security incidences, and as the laws change that require the reporting of such.
Risk Analysis necessary to prove ROSI
The next article in this series will focus more in depth on risk analysis methods and formulas using our web-based project as an example. Also, taking into account that most organizations may not know how to value Information Assets, there will be an introduction to the Analytical Hierarchy Process (AHP). We will also discuss the data that is available, and how that can be applied to your organization.
|