However, if you're like most information security professionals, you don't operate in that perfect world. Chances are you're either an information security specialist who reports to the management within a business unit or a member of a centralized security team without direct control over security matters. If that's the case, you probably find yourself charged with implementing vague, and sometimes conflicting, security strategies and policies -- a difficult, but not impossible, undertaking.
So, how does a decentralized team or one with multiple lines of reporting responsibility build a coherent information security strategy? The four-stage process outlined below, which includes development, approval, implementation and review strategies, can help you achieve that interdepartmental goal. Another important point is that while final approval comes after the strategy is written, it's a prudent idea to determine the approval process before developing the strategy.
Before you get started, put together the right group of people to build the strategy. The team's composition will vary widely from organization to
Stage one: Strategy development
An adequately formed team can work out an effective interdepartmental strategy. Their team's first task is to determine the scope of the higher-level strategy. This is the most critical step of the process because it clarifies what the team is willing to agree on. For example, the team's policy might be restricted by organizational (department, business unit or other political division) or geographic boundaries (state, region, country or continent). If there are areas of security strategy where departments have dramatically different needs (such as one department requiring external access for employees and partners and another forbidding external access completely), it's probably best to leave those out of the higher-level strategy or make a notation in the strategy document that those specific areas are the responsibility of individual departments.
Once the team has outlined the scope of the policy, it's time to write! When possible, it's best to create a general strategy governing a topic and leave the implementation details to individual departments. For example, your policy might require the use of an "appropriate encryption algorithm" and leave the specific choice of cryptography up to the implementing department. This will give everyone the feeling that they're on the same page but will still leave the nuts and bolts at the discretion of organizational units.
Stage two: Strategy approval
After the team has finalized the higher-level security strategy, it's time to gain official approval from management. The specific individuals who need to sign off on the policy will vary depending upon your organization's politics, but each member of the team will need to work within his or her sphere of influence to drum up support. Obtain senior-level support for the strategy within your organization prior to initiating the effort and you'll have a much easier time with approval after you've written the strategic plan.
Stage three: Strategy implementation
When the strategy is written and approved, the team should oversee the implementation process. Some portions of the strategy will be left to different organizational units, but the team as a whole should monitor progress and make suggestions where appropriate. For example, if it becomes necessary to allow different organizational units to determine their own external access policies, you might delegate this task to a subteam for each unit. The subteams should report back to the centralized team to ensure that the policy-writing process remains on track. Furthermore, it's a great idea to share these results with other departments to avoid duplication of effort. Directing implementation is another political minefield, so team members will need to walk the fence between providing advisory support and giving direction. This will vary from organization to organization, depending upon the amount of authority given to the team. Information security professionals in a military organization most likely have more directional authority than a similar group in an academic setting.
Stage four: Strategy review
The development of an information security strategy is a continuous process. The team should meet on a recurring basis, perhaps quarterly, to review the strategy in light of the changing organizational environment. If changes are necessary, they should be developed, approved and implemented using the process outlined above in stages one through three. For example, if a major corporate restructuring takes place, the team will need to reconvene to assess the impact of the new structure on current security policy. Another example would be if the organization begins outsourcing to a large number of third-party partners who need access to internal resources but current policy forbids these types of network relationships. In that case, the team needs to reevaluate policy and find a compromise that preserves security while meeting business needs. Don't allow "shortcuts" to this process to alter your strategic direction. It's far too easy to simply let the team leader make a "few minor edits" to the policy without calling a formal meeting of the team. Those edits quickly add up and lead to an easy way to get off course and lose team consensus.
Clearly, organizations -- and even departments within organizations -- take different approaches to developing information security strategy. A basic framework such as this can help security pros build coherent interdepartmental strategy to address various information security structures and power hierarchies.
About the author This was first published in January 2005
Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the author of the
This was first published in January 2005