Perspectives on Application Security and Risk Management
In my last blog post I discussed information security risk management and why the financial services sector aggressively adopted the practice. My recommendation was that the healthcare industry segment needs to follow suit to increase the effectiveness and efficiency of their information security programs. It is refreshing to see evidence that this is taking place. Last week at OWASP’s AppSec USA conference some leaders from the healthcare sector shared their perspectives on information security risk management.
The panel session, entitled “Characterizing Software Security as a Mainstream Business Risk,” represented application security and risk management experts and executives from both the commercial and public sectors, including: Tom Brennan, CEO for Proactive Risk and OWASP Board Member; Ed Pagett, CISO for Lender Processing Services; Richard Greenberg, ISO for the Los Angeles County Department of Public Health; and John Sapp, Director of Security, Risk and Compliance for McKesson.
Rather than focusing on technical issues associated with Wisconsin CISO, which you might expect at an OWASP conference, the panel focused on the discussion of risk and the build out of risk management programs. Much of the discussion centered on how the key drivers for risk management needed to be expressed in business terms such as patient care outcomes, customer satisfaction as well as revenue and profit.
Greenburg, from the public healthcare sector, said that for the Los Angeles County Department of Public Health, “It’s all about getting straight to patient care. The department doesn’t really care about IT nor understand what application security is. They can, however, understand risk in the context of their business; how an application security program can help or hinder them from providing the best care possible.”
Sapp from McKesson continued, “When working through the development of our risk management program, we looked at how our application security programs are helping us to achieve our business objectives. Of course, this doesn’t mean we turn a blind eye to technology and security such that we put the business in harm’s way; we certainly don’t want to facilitate a breach. But, a deep dive into the technology isn’t the discussion we were having during our risk management program planning; we left that discussion for the security operations team to engage in outside of the risk management program discussions.”
The panel offered some guidelines to help other organizations build their own application security and risk management programs:
- Speak in terms of the business. For example, focus on how to ensure secure banking transactions, how to guarantee private and highly resilient patient care, and how to deliver trusted services to employees, partners, and customers.
- The answer is never simply ‘buy a tool.’ Avoid blindly buying products in the hopes that they will solve your application security and risk management problems. It is important to first understand the objective of the risk management program and then select the right tool (s) for the job. As Sapp put it, “a fool with a tool is still a fool.”
- Gain a wide range of allies, both deep and wide – focus first on those that have revenue-generating responsibility, followed by those that have audit and compliance responsibility.
- Find in-field leaders and champions to establish some grassroots efforts. Leverage your project management team to achieve a quick win or two and then use them as case studies to progress the program further.
- Leverage frameworks such as ISO 27002 to establish a baseline level of guidance of how to build out your risk management program and your supporting application security program.
In terms of some guidance for those in the healthcare industry, Sapp from McKesson noted the some highlights from their risk management program.
The top four goals McKesson focused on were:
- Harmonizing processes and investments surrounding risk management
- Improving the overall risk management process
- Establishing application governance
- Delivering transparency and visibility through the risk management program
To achieve these goals, McKesson defined a complete set of risk management categories designed to help define, implement and measure progress. Some sample risk management categories include security, quality, privacy, legal and third-party components. Each of these categories play a role in managing risk, and by defining them up front, McKesson was able to establish a comprehensive, formalized risk management program for the entire enterprise. McKesson’s program is designed to encompass its own business risk as well as the risk associated with the products, services and solutions it offers to its clients.
Within each category, McKesson would look beyond the security risk and the business risk; it would do a deep dive into the risk/reward analysis and focus on how to gain the most reward while mitigating or avoiding the most risk. One example of this analysis would include how to lower the total cost of ownership of a system/application versus mitigating the risk to avoid increased operational cost. Another example would include how it could achieve high levels of application quality and resiliency as a reward while mitigating the risk associated with application failures and other critical errors. One final example would be how McKesson could increase the likelihood and close rate of its own sales efforts while reducing the cost of customer acquisition versus mitigating the risk of having competitive disadvantages (such as poor security or poor application quality).
With its program framework in place, leveraging the OCEG (Open Compliance & Ethics Group) framework as a baseline, McKesson began to focus on implementing an integrated application security program. The order with which the company performed the application security analysis was:
- Applications that were seeking certification on HITECH (Health Information Technology for Economic and Clinical Health).
- New applications that were in development or on the roadmap for development.
- Legacy applications that possess the high revenue value for the company.