Tough Love: When IT Security Hurts Your Business

Abstract

As the pace of IT commoditization accelerates in response to laws like Sarbanes-Oxley, some security departments find themselves at odds with IT and the business. One solution that seems to work is to engage more with the business and devolve some security functions into day-to-day operations. Service Management concepts, like ITIL and Business Service Management best practices, can help mend the unraveling relationship. This ITIL and IT security white paper explores the challenges IT departments and their businesses are facing today, and provides examples of what these problems look like in real life.

Sample

Introduction

As IT commoditization continues to increase audit and control activities, IT gets better at identifying and documenting the causes of significant outages. IT organizations are using ITSM (IT service management based on ITIL) to make the source of many IT failures clear, and they use Business Service Management (BSM) to understand what the customer impact might be for any changes proposed.

ITIL, and even more so BSM, is all about taking one's cue from the business and what is best for the enterprise, and creating processes that confirm business impacts before making any changes. Aligning with business means understanding the business and helping understand the ramifications of decisions.

In an increasing number of cases, these ITIL efforts show the source of the outage to be action from the security department, and the BSM processes show the impact to be devastating in some cases. Unfortunately, it seems as if, in many companies, security staffs do not take advantage of existing IT processes, nor do they understand the impact on the business of the systems they police.

It appears that ITIL and BSM concepts can help security departments make better decisions, too.

Generally, companies need security oversight for their information technology investments, services, and corporate systems. However, some security departments today are stand-alone groups of dedicated workers who "know what's best" and then go do it - with increasingly disastrous consequences for the business. Sometimes this is due to a corporate policy of separation - specifically keeping IT and security at a distance from each other.

One possible cause of the growing friction between IT and security is that many security departments are separate and unequal groups operating outside of IT that "do security to IT." This can distance security from day-to-day IT operations and precludes many interactions with ordinary IT staff, customers, users, and existing IT processes.

At best, the distance between the two entities can make security seem elitist; at worst, this results in major cost, quality, and regulatory liabilities for the business.

Based on my personal experience working with some of the leading information technology organizations in the United States to implement ITIL and BSM, here are three real-world examples to illustrate this burgeoning problem. Also presented are possible solutions for those now facing this serious, sensitive, and hard-to-address issue - an issue that needs to be addressed, however uncomfortable it may be.

The Best of Intentions

At a hospital in New Hampshire, a well-meaning IT security practitioner decided that the passwords in use by healthcare workers were "weak" after he visited Microsoft's website and used their free password "strength" checker.

He had the best of intentions - data privacy laws are tough. One of the regulations to which the hospital is subject is the Health Insurance Portability And Accountability Act Of 1996, or HIPAA. The maximum fine for a HIPAA breach is $100 per violation and up to $25,000 for all violations of an identical requirement or prohibition during a calendar year. But don't think that the penalty is limited to this. Oregon's Providence Health System agreed to pay more than $95,000 in state fines and $7 million to $9 million in victim credit protection services relating to loss of patient information. And there can be jail time as well - an employee of a Seattle cancer center, Richard W. Gibson, earned the dubious distinction of being the first person sentenced to jail time for HIPAA violations.

To improve security and avoid such potential HIPAA violations, our erstwhile security practitioner decided to change all passwords to a "stronger" scheme of his own design. While he had the best of intentions, the problem was that the password scheme he came up with produced passwords "stronger" than required; so strong, in fact, that users could not remember them. Instead, users wrote them down on yellow sticky notes and stuck them to their computer monitors.

This single act by a security practitioner in order to prevent HIPAA violations set the stage for more potential HIPAA violations than the previous "weak" passwords allowed!

This could have been prevented if he had worked with business customers to establish any security requirements beyond the baseline required (in this case) of HIPAA. Then, after establishing a baseline of security per HIPAA regulations, he should have taken his cue for any additional appetite for security from the business - the customers and users of the systems. This story had a more or less happy ending as this is just what he did.