While some members of the IT community complained bitterly that Microsoft hadn’t sufficiently promoted its Internet Information Services (IIS) server patch before the Code Red worm attack, most network administrators have to admit that they themselves are responsible for keeping their network hardware and software secure and up to date. It’s likely in this case that some admins may have known about the Code Red patch but simply hadn’t taken the time to apply it.
The reality is that patches and fixes are not always the highest priorities on the long to-do lists that most network administrators constantly prioritize and reprioritize. The solution for better security is not to micromanage net admins or set rigid work structures for them but to make sure that a company’s general security policies are comprehensive enough to meet the organization’s needs. In addition to a big-picture strategic approach, a company should also include a tactical, detailed plan for addressing security problems as they arise.
For CIOs, this means making sure that the organization’s network security policy is designed to prevent the lapses associated with worms, such as Code Red, or other similar problems in the future.
This article offers two perspectives for building preventative network security policies and plans from two IT analysts at Gartner and a network security manager in the field.
In theory: Creating an ideal policy
Gartner security analyst John Pescatore believes that the mechanisms to prevent network security breaches should be formalized in the organization’s network security policies and plans.
Pescatore points to a recommendation from Gartner security consultant Rich Mogul that organizations develop two documents—one that covers policies, and one that maps out specific security plans. Mogul defines the difference between policies and plans and discusses how the combination ensures network security. Mogul described the two documents as follows:
- Security policies define security governance. They must originate from, or have the total support of, executive management. Policies should be clear, concise, understandable, and enforceable. Specific business units may need additional security policies, which should comply with enterprisewide policies.
- Security plans define the specific actions needed to comply with security policies. They are the means to achieve the ends. Security plans need to be updated constantly to account for changes in the environment. Like policies, plans should be clear, concise, easily understandable, enforceable, and achievable.
Mogul provided an example of how to address software updates in both a policy and a plan. A security policy might read: “The information technology department will ensure all computer systems will be constantly updated with the latest patches and updates.”
The plan that is derived from this policy would read: “All systems administrators responsible for servers must subscribe to the appropriate vendor patch/update and general vulnerability distribution lists for their systems. Patches for ‘high risk’ vulnerabilities must be installed immediately upon release. All other patches must be installed within 24 hours of release.”
Of course, every policy and plan will not be identical. The needs, size, and expertise of the organization will determine how policies and plans should be written and implemented. What makes sense in a smaller organization using off-the-shelf software with little customization may not make sense for a larger organization that has customized applications and more complicated transactions.
A successful security policy will accurately reflect the day-to-day operations and specific application usage of an organization’s network.
In reality: Making policies and plans work
Gordon Zacrep, manager of information security at Vanguard Group, has found in his day-to-day work that “Patch first and ask questions later” is not the best approach. His company—a mutual funds firm whose 11,000 employees did more than $1.6 billion in business in 2000—takes security seriously, he said.
“People don’t want to think that you’re having security problems when they are investing money. That’s a critical thing that I think management is always looking at here,” he said.
Even as the economy soured in 2001, Zacrep said his budget continued to grow, although the company is cutting costs elsewhere.
“The security budget keeps growing because the threat keeps growing and the vulnerabilities keep growing and getting more complex,” he said. “Our whole technical infrastructure is getting more complicated, and our relationships with vendors are getting more complicated—all of which complicates security. So there’s always a need for upgrading and improving, and management has recognized that.”
With so much riding on the security of Vanguard’s network, you might think the IT department would install patches the instant they became available. But Zacrep said past experience has shown that that isn’t the best approach.
“The policy that we follow is, you want to install patches as quickly as is feasible and desirable. From an operational standpoint, just because a patch comes out doesn’t mean we automatically install it,” he said. “One of the things we have found in the real world is a lot of times, a patch will come in to fix a problem and you install it, and you find out that it causes another problem. Not necessarily with that product but with the way you operate.”
Zacrep said that his team prefers to test each patch before applying it, but sometimes, there isn’t time for testing. He said that his team has to decide which risk is greater: leaving the network open to a potential threat while testing the patch or risking other potential problems by applying a patch before testing it.
He said he would never advocate a security policy that required every patch to be installed right away.
At Vanguard, the responsibility for applying patches and updates is divided between the operations and security departments, Zacrep explained.
“Within our technical operations area, they do patches on all their different platforms. They get all the latest releases for all their different products—some are security-related and some are not—and they have regular schedules for applying patches.”
Zacrep says his team gets involved only when there is a specific threat or vulnerability. When this threat has been identified, his team works with operations to decide when to apply the patch that addresses the threat.
Zacrep’s team also monitors e-mail viruses and their effects on the company. During that period of time when a virus has been identified but a definition file is still being developed to recognize the virus, Zacrep said his security group monitors the company’s mail systems for the telltale symptoms of the virus. If the attack is severe enough, the security group shuts down e-mail until the definition file is deployed.
“I don’t know if you want to call them policies, but we have procedures for how we deal with those scenarios, what steps we walk through when we see something coming,” Zacrep said.
He said the team members also do an assessment after each incident to see if they need to change their procedures or network environment.
Preparing pertinent prevention policies
Just as Zacrep’s security group is constantly refining its plans to react to the newest threats, the perfect network security policy may be one that explains the importance of prevention without dictating in great detail how that will be achieved in the plan. Gartner analysts agree that both security policies and plans need to be updated on a continuing basis and be tailored to fit the needs of each individual organization.
Do your security plans conflict with your security policies?
Defining a security policy that safeguards your organization’s intellectual property and computing networks is not a simple matter. Developing a plan from that policy that doesn’t conflict with it seems equally difficult. How has your organization achieved a balance between policy and plan? Send us a note or post a comment in the discussion below.