Best Practices Resources

Secure Computing
Decentralized IT: New Security Strategies

Gene Kim

Over the last twenty years, IT organizations seem to grow ever more overworked as the demands put upon them keep growing. However, this pain is probably dwarfed by pain felt by information security professionals, who get busier each day as software vulnerabilities are found, and vendors frantically issue critical patches that need to be deployed. While recent events have escalated the visibility of infosec, there still remains the challenge of translating security objectives into tangible and sustainable improvements in the organizational defensive posture. In other words, infosec may have succeeded in creating secure business processes that accessible via the Internet, however, despite best efforts, business units continue to do things that jeopardize not only their infrastructure, but potentially the entire enterprise.

The trend towards decentralization of IT, away from the centralized MIS computing environment of the 1970s, is continuing ever more rapidly. To see how far this trend has gone, look at how difficult it is to determine total organizational IT costs at the CFO level. Because the budgeting and costing has moved away from MIS into the business units, IT can grow and deploy infrastructure as the businesses see fit, without centralized control, for better or for worse. Infosec practitioners must keep one unsettling fact in mind as they plan: they cannot grow resources or staff as fast as IT groups or the business units they support. Therefore, a fundamentally different management and control model must be employed. Decentralizing IT also creates organizational accountability issues. Instead of having a centralized infosec group with accountability, responsibility, and authority, we have infosec groups matrixed into line IT groups, most often with little authority or resources. Furthermore, when security implementation is always buried in the business units, it becomes too easy for business priorities to always take precedence over security. Afterall, time to market is far more visible than the potential 100x increase in operational costs and remediation of security issues - after all, the total lifecycle costs are rarely seen at the beginning of projects, and it is easy to believe that "IT projects are inexpensive, just like a puppy is free."

Strategies

Making IT security a peer of IT
Moving infosec out from under the CIO is a common strategy for creating the organizational impetus toward more security-oriented decision making behavior. The argument for this strategy says, because the priorities of line IT managers are often diametrically opposite those of line security managers, they should be peers. While the CISO role has been refined over the last twenty years in regulated industries, such as financial services and healthcare, security organizational roles are still developing in other industries. A good example to use may be Howard Schmidt, formerly of Microsoft. In 2000, he was promoted from Director of IT Security to Chief Security Officer, becoming responsible for all security issues, physical security, executive protection, etc. Perhaps lessons can be learned from his experiences, but I believe whether the "G3D" (gates, guns, guards, dogs) is separate from infosec is still being decided.

Franchise model of security
Consider that well over 50% of the hundred billion dollar plus Y2K remediation effort was inventorying the computing infrastructure. IT procurement, deployment and operations were so decentralized that in order to remediate Y2K issues, organizations first had to find all the infrastructure at risk, inventory what critical business processes were running on them (if any at all), and find the IT organizations and business units responsible for their operation. The first immediate and monumental challenge for infosec professionals is very similar - in order to improve an organization's defensive posture, you first need to it even exists. Which business units are deploying and operating IT infrastructure, and who is responsible and accountable for it? The goal is to create relationships with all of these groups, in order to measure and influence their decisions that affect security.

Avoid low leverage audits -- vulnerability assessment
Assessing infosec policy compliance of business and IT groups is critical. Concentrate on integrating security needs into the application development and IT operations processes, before infrastructure gets deployed - interacting with these groups for the first time only after they are compromised is the most expensive way to effect change. Here is where speaking the language of executives can help. To quote Stephen Katz, one of the most well known infosec executives, "When dealing with executives, stick with small numbers and primary colors."

What should you measure, using only small numbers and primary colors? Consider the following criteria:

• Integration of security into application development and deployment: Are security requirements generated by business units, with infosec involvement? Is infosec involved in the approval process and critical milestone checkpoints? Are security requirements given for each phase of the engineering and operations process, from design, requirements definition, testing, and deployment? (Notice how most vulnerability assessment audits only cover the last phase, where remediation costs are highest.)

• Integration of change control and trouble tracking into operations: Is IT operations aware of changes taking place in their operational environment? Are all changes being documented? Are all changes traceable to the person who made them? Can all changes be traced back to a business-driven reason or change request?

• Ability to remediate from outages and security breaches: Can operations list all the critical business processes running on their infrastructure? Can they inventory the assets that run them? Can they repeatably build them? Can they detect all changes in the production environment? Can they get early warnings and indicators of threats? (This is the IT Safety Index I wrote about in the November 2001 issue.)

Public shame as behavior modifier
Now that you have some simple metrics that use only small numbers and primary colors, what do you do with them? Label each IT organization and business unit with them, and use the mechanism of public shame to reinforce good behaviors and shame bad behaviors. It is critical to provide executive visibility to these metrics. It is also imperative to map your efforts and recommendations back to why these things are necessary. Make sure the executives understand how this translates to the company's success, and create a compelling case for why and how they should invest the company's resources to solve infosec-related problems. Help them connect the dots back to the bottom line.

A large number of forces have led to the current day that makes the life of infosec professionals so difficult. It is important to realize how differently infosec must be managed, in light of the way IT responsibility has been diffused throughout the organization. In the absence of new strategies such as the ones I describe here, infosec executives are left fighting a battle they cannot win.

Back to Resources page