Current challenges of the financial services sector aside, risk management has a long and venerable tradition of practical success in the world of insurance premiums and credit card interest rates. In the world of IT, however, the successful application of risk management techniques has been more elusive.
This problem has been no more apparent than in IT application and software development. Despite compelling industry statistics that enterprises lose billions of dollars annually and suffer loss of public confidence through application availability downtime or other security breaches, effective risk management techniques have yet to take hold.
This article examines some of the major challenges of software security risk management and introduces the concept of Software Security Total Risk Management (SSTRM), an innovative programmatic approach by which enterprises can apply software security development and assessment best practices in order to meet the twin goals of enhancing business revenues and protecting against business losses.
Why Software Security Risk Management Matters
In less than thirty years, IT has grown from a province of largely academic concern to a driving force in world commerce. This trend, which started with the advent of distributed computing architectures in the early 1980s, accelerated dramatically with the rise of Web-based computing in the 1990s. Today, doing business without a Web-based sales channel - even if only to supplement bricks-and-mortar operations - is virtually inconceivable.
With the rise of IT-enabled business has come an explosion of demand for IT products to support people, process and technology throughout the enterprise. These include: protocols, Web browsers, Web servers, application servers, database servers, virtualization servers, storage servers, storage attached networks, network devices, the myriad tools that support the management of these products and the hundreds of thousands of applications that automate the business processes of buying, selling and performing work.
The growth and importance of IT security has paralleled this rise in importance of IT as a business enabler and competitive differentiator such that today, the rubric "IT security" has come to represent all that guarantees IT will fulfill its promise to transform the way business is done. Along the way, the concept of "security" has grown from an initial guarantee of continuous IT availability to a set of much broader guarantees: data confidentiality and integrity, identity protection and even operational efficiency as it relates to business continuity.
What is often overlooked amid this phenomenal growth of IT and IT security is the software that lies at the heart of every IT product, every IT device and every IT application. Software code, written by software developers, is what ensures that every IT device and every software application does what it is supposed to do - including carrying out its security functions.
In other words, the whole edifice of enterprise IT is only as secure as the secure software development foundations on which it is built.
Why Software Security Risk Management Gets Overlooked
Software development has a long and storied history. Since the advent of the first programmable devices in the 1940s, software development was considered the exclusive province of mathematicians, musicians or magicians. Individual or group creators of programming languages, operating systems and even specialty algorithms joined a secret pantheon known only to the elect who subscribed to common principles of elegance and innovation.
Practitioners of software security were part of an even more select group, representing not only the perspective of the general software developer, but typically possessing an even stronger mathematical focus, as well as an added sense of mission around the guarantees of availability, confidentiality and integrity that are at the core of IT security.
The business mind - with its focus on the practicality of profit making - has not always been comfortable with the community of software developers. Thus, even as the alliance between business and IT has flourished, and especially in recent years as enterprises have grown and differentiated themselves into multiple lines of business with numerous layers of managerial hierarchy, responsibility for software development and software security has tended to be pushed deep into individual lines of business - far from the province of executive business decision makers.
In recent years, the requirements of regulatory compliance (e.g., Sarbanes-Oxley, PCI) have given new impetus to the drive for IT security in general, generating widespread interest in systematic IT Security Risk Management. But even with this push, the esoteric traditions of software development have tended to give this dimension of IT security less visibility than is merited by its critical role; and until today, there has been no systematic and effective framework for Software Security Risk Management.
To understand the broad requirements for such a framework, a brief digression into the foundations of IT Risk Management (ITRM) is in order.
Foundations of IT Risk Management
Many industry articles dealing with ITRM assume a grasp of foundational concepts and proceed to address the underlying mathematics of IT risk estimation. While rigorous methodology is certainly crucial to effective ITRM, delving into methodological details is not my purpose here; rather, I would like to suggest that ITRM is a particular perspective on the relationship between business and IT, and establish the broad outlines of that perspective.
Many people assume that every discussion of ITRM is really a discussion about IT security. This is a mistake. IT security risk management is one particular variant of ITRM, which brings numerous additional considerations and merits its own special treatment (there can even be numerous variants within IT security risk management, such as software security risk management - as this article has already suggested).
The true starting point for building effective ITRM programs lies with a clear understanding of the relationship between business and IT systems. Because at the end of the day, ITRM amounts to nothing more than the process of creating a strategy which manages the relationship between business and IT (at all three levels: people, process and technology) - and then executing on that strategy.
Everyone knows that business and IT have long enjoyed a love-hate relationship. They come from different places and represent different motivations. Business is as old as the market and is about buying and selling and coming out ahead. Information technology is as recent as the semiconductor and is about accelerating all sorts of processes - including business processes - through automation.
The desire to improve the science of automation is a key element driving IT - something IT does not share with business. But it is also what makes IT essential to business: business capitalizes on the process improvements made possible by IT, in order to drive market efficiencies and create competitive advantages that lead to greater profits.
Embracing the IT promise of process improvement does not come cheap, however. It requires capital investment in equipment and personnel, as well as long-term maintenance. IT also introduces something more - something much less tangible than cost - into the world of business process: the values essential to the successful pursuit of the science of automation, which are to a degree in competition with the values of business. Finally, and much more obviously, applying IT automation to enhance pre-existing business processes makes business dependent on IT in order to keep those processes running smoothly.
Operational Integration, Availability and Security Risk Management
The first stirrings of ITRM can be found in the need to balance the relationship between the goals of business profitability, on the one hand, and two new factors on the other: IT operational integration and IT system uptime, or availability. Each of these new factors accompanying the introduction of IT into business can seriously erode business profits and thus constitutes a major business risk.
As suggested above, security is a relative newcomer to the ITRM scene. Security is driven by the dramatically increased value of IT physical assets, other business assets (including intellectual property) and certain kinds of data pertaining to the privacy or confidentiality of business transactions involving customers, employees or business partners. With the addition of security risks, ITRM becomes IT Security Risk Management (ITSRM).
If ITSRM is a matter of creating a strategy that would somehow balance these risks against the promise of business profits, the next questions become: "How much risk should I worry about?" and "How do I actually put a risk management strategy together?"
Common and easy answers to these questions are "Whatever amount makes you worry" and "Any way you can." After all, most people get through the much more complicated balancing act of life with not much more of a profit strategy than meeting basic financial obligations (like your monthly mortgage payments) and trying to manage some important risks (like health problems). We let the rest take care of itself.
But in the same way that IT has made a science out of improving processes through automation, other sciences, designed to help create effective strategies in certain more limited arenas of life, like the business world, have emerged in recent years. These are the sciences of decision support (DS).
DS is too big to try to describe in this paper, but one small aspect of it is essential to the practice of risk management. Closely related to the actuarial science that has long been applied successfully in the insurance industry, DS provides guidance in the creation of all kinds of business strategies by looking at various types of risk and attempting to quantify them precisely in terms of costs. In addition to the cost of the risk itself, DS has also developed for estimating the cost to remediate the risk.
If the costs of those IT-introduced risks identified above, as well as the cost to remediate the risks, can be rolled up into IT investment costs, and these costs can then be compared against the profits that one expects to realize by entering into business in the first place, a simple DS formula emerges that can serve as the basis for an ITSRM strategy: