Healthcare powerhouse McKesson comments on AppSec in GRC

When asked what the greatest risks his company expects to face in 2010, the CEO of a major U.S. airline began to list items such as energy pricing, labor challenges and terrorism. IT security, let alone the application security subcategory, did not make the list. Is this a common theme across today's businesses? Or, is it that organizations just don't speak of IT and security risk using IT and security lingo?

According to a panel of experts at the recent AppSec US 2010 conference hosted by OWASP (Open Web Application Security Project), it is some of both. This particular CEO speaks of risk purely in terms of business, not in terms of technology or security.

Quiz: Do you know IT security?

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 Deparment of Public Health; and John Sapp, Director of Security, Risk and Compliance for McKesson. The panel, which had upwards of 100 attendees, was moderated by John Dickson, principal for the Denim Group.

The objective of the panel was to shed light on the need for executives, their IT/security personnel, and their risk-prone employees and partners to speak the same language when discussing risk and building out their risk management programs. After all, it's not about whether or not a business application contains vulnerabilities that can be exploited, it's about how a critical business system being compromised could result in failed banking transactions, life-threatening patient health and safety issues, or power grid failures. Therefore, the key drivers -- and therefore, the language -- behind risk management should be directly related to ensuring consumer safety, delivering customer satisfaction and ensuring successful business transactions.

Greenburg, representing the public healthcare field, noted 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 added, "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."

It is important to understand that risk management and application security are not about a return on investment (ROI). So, avoid the "What's the ROI going to be" discussions at all costs; this is the wrong tact to take. The discussion should revolve around how best to ensure the business objectives will be met, securely, with as little risk as appropriate for the business. Find ways to avoid and/or mitigate the risk at a cost that the organization can bear and, if left unresolved, could otherwise prevent the company from being successful in meeting these objectives.

According to Brennan of OWASP, organizations need to identify what the 'treasure' is; what's the most important thing in relation to their long-term business strategy. Once this is identified, the organization can begin to educate the stakeholders in order to gain support of their application security enabled risk management program. With the program plan in place, the organization can begin to assess the environment surrounding their 'treasure' in order to identify the business-oriented weaknesses and risks. With the assessment results, the organization can then begin to define and implement the necessary access controls and related security measures -- at which point, the right processes and tools can be deployed to help manage this ongoing activity of assessment, controls and reporting.

The panel offered some tips to help other organizations build their own application security enabled 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 (or being sold) 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 so eloquently 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 27001 or 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 a follow-up interview, Sapp offered some additional insight into the processes he used to set up their application security enabled 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; and 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 operations costs. 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:

1. Applications that were seeking certification on HITECH (Health Information Technology for Economic and Clinical Health).

2. New applications that were in development or on the roadmap for development.

3. Legacy applications that possess the high revenue value for the company.

This analysis and prioritization enables McKesson to make clear, calculated decisions on how to proceed with IT security and application security in relation to its overall risk management program. One such decision often revolves around which applications to focus on in terms of update vs. sunset and build/buy/partner. Without this analysis, McKesson could be making decisions based on poor or limited data, investing potentially millions in systems and applications that should have otherwise been rebuilt or replaced.

With the program in place and the prioritized analysis performed, McKesson was able to select a set of risk management products, code analysis tools and supporting risk analysis utilities to perform routine risk assessments, prescribe actionable risk mitigation tasks, implement secure application development best practices within its software development life cycle  and provide crystal clear executive-level visibility into the status of and progress toward a balanced risk management program that is application security enabled.

Regardless of the level of investment being made in building a risk management program, in order for any organization to properly incorporate the risk associated with its IT systems and applications, the IT/security professionals and their executive leaders need to speak the same language. Fortunately for the business executives, it is the IT/security professionals that will need to adjust and augment their vocabulary to match that of the business if we are to be successful in this movement. Leverage some standards to get started, follow the tips provided here by the panel of experts, focus on speaking the same language, and your organization can have a solid application security program that supports your overall risk management program.

Read more about wide area network in Network World's Wide Area Network section.

This story, "Healthcare powerhouse McKesson comments on AppSec in GRC" was originally published by Network World.

Copyright © 2010 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon