Building a Blueprint for Network Security

By Paul Rubens | Dec 17, 2003 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/3290411/Building-a-Blueprint-for-Network-Security.htm

Ever gone out and then spent the evening wondering whether you remembered to lock all the doors back at home?

If you’re responsible for a corporate network, you’ve probably had a similar feeling — is my network secure, or have I forgotten something that could leave my organization wide open to attack from the first hacker to probe my network for vulnerabilities?

It’s an important question, and one worth spending some time considering. How can you be sure you’ve done everything reasonable to secure your network?

If you’ve just assumed responsibility for a network and time is of the essence, the first thing to do is check the existing patch management policy. According to research from Gartner Group, around 30% of damage to networks stems from organizational failure to implement patches in a timely fashion. If you find unpatched systems, get them in order as quickly as possible.

The same research found that 65% of intrusions stem from misconfigured systems, with only 5% coming from problems that were not previously known. To go back to the house analogy, 95% of security problems are caused by casual walk-in burglars who find you don’t bother to shut all the windows and doors when you go out, while only 5% come from more devious and determined thieves.

At this stage you may want to examine the configuration of every device on your network. But if you’re really keen to get moving, then it’s probably wise to hire some penetration testers to check if there are any serious vulnerabilities in your network that are likely to be found by would-be intruders.

It’s also useful to test the security of your network from the inside — there are a wide range of statistics available that indicate a high proportion of network attacks come from employees. This can be achieved by giving penetration testers a realistic amount of inside knowledge and network access, and then discovering what kind of trouble they can get into.

Page 2: An Overall Security Architecture

An Overall Security Architecture

OK, so far these have all been stopgap measures, but what’s really needed (in fact required — but more on that later) is an overall security architecture rather than a series of ad-hoc measures. “A high-level security architecture is a set of guiding principals, an orderly arrangement of security components,” says Mark Bouchard, a senior program director at Stamford CT-based Meta Group.

A security architecture should define roles, responsibilities, and a policy framework all the way down to the finest detail in a hierarchy. And the buck must stop with a Head of Information Security, who takes ownership of – and responsibility for – the architecture.

A corporate security architecture will probably include a business process catalogue and a domain structure that divides the organization into manageable – and meaningful – portions with different security requirements. Clearly, valuable R&D data has a different value — and as a result needs a different level of protection — than customer contact details, so these would be in different domains.

Other domains could include an executive domain and a typical user domain. Using a series of tools, models, and templates, appropriate security measures should be defined right down to the level of firewalls and passwords.

The purpose of this division by domains is quite simple — it’s all about risk management. It’s not worth spending $100 on a fence to protect a $10 horse — in other words, the security measures you take should be proportionate to the value of the information you’re protecting.

The purpose of the architecture is to use this process of risk management and codify it into a set of rules with which you can engage business users, who are understandably more interested in doing their jobs than in protecting your company’s assets.

Ultimately, a security architecture is a blueprint for all your security efforts. “Without one to guide you, investments in security will be tactical, reactive. Instead of fixing things, you will probably fix one thing and introduce new vulnerabilities at the same time,” says Bouchard.

There’s one further point in favor of ensuring you have an effective security architecture in place — it’s obligatory. Regulatory and fiduciary responsibilities demand that you take security seriously and address it thoroughly, and the Federal Trade Commission says you need to have a plan. Your security architecture is this plan.

Page 3: Devising a Security Architecture

Devising a Security Architecture

So what’s the best way to come up with a security architecture? The most important question to consider is how much to rely on staff from within your company and how much to rely on outside consultants. Security, as we have seen, is all about risk management, and this entails sorting out what is mission critical, what is valuable, and what is merely important.

It’s clear that staff from within an organization are in the best position to understand how the business works and how the underlying processes affect each other, but it’s also important to understand that outside consultants may be more objective and are likely to have a greater specialist knowledge of security than existing IT resources. So while internal resources need to be involved at every level to ensure that the key components are being protected, consultants can be the best option for ensuring that the knowledge of risks and how to respond to them is up to date.

The U.S. Department of Defense-funded CERT (Computer Emergency Response Team) coordination center recommends the use of a methodology called OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), a risk-based strategic assessment and planning technique for security.

“OCTAVE is self-directed. A small team of people from the operational (or business) units and the IT department work together to address the security needs of the organization. The team draws on the knowledge of many employees to define the current state of security, identify risks to critical assets, and set a security strategy,” says CERT.

Self-direction of the security audit is key, believes Ted Wilke, CEO of Pittsburgh PA-based information security consultancy DMZ2. “Often companies get outsiders to take an audit and then don’t implement the results, as they just don’t buy into it,” he says. “If internal people carry out the audit, then it’s much more likely to get to the real issues, and it’s far more likely that the results will be implemented.”

Page 4: A Culture of Security

A Culture of Security

This points to the cultural aspect of security — too often users find security measures simply as impediments to their work, annoyances that are circumvented whenever possible. It’s only when a culture of security is instilled into an organization — so that every employee is aware of security measures and why they have been put in place — that security can be effective. “If you get employees involved, there is a far higher chance of succeeding in improving security, and getting employees to keep other employees in line,” Wilke says.

Outside consultants can certainly add value to a security exercise, but their greatest value comes only after it’s clearly understood what needs protecting and once all employees have been involved. “The types of attacks that companies are experiencing is changing constantly, and most companies can’t cope themselves, so it simply makes sense to get outside help,” says Mike Arnavutian, head of security strategy at BT Global Services.

“A security consultant like us can manage security for a company, removing risk and taking liability — and would charge on that basis.” It’s not only expertise that consultants can bring: security specialists can often offer considerable benefits of economies of scale. “If you look at the cost of monitoring and managing a system, it’s often cheaper for outside experts to do it for you,” he says.

Outside companies can also help by providing alternate facilities for use in a disaster, which may often be necessary from a risk management point of view, but which can also be prohibitively expensive to equip and have standing idle.

When is it safe to say “enough is enough,” and relax in the knowledge that the network is secure and all prudent measures have been put in place? Sadly, the answer is “never.”

Security is a process, not a task, and it needs to be reviewed critically and regularly. New threats appear all the time, and measures that are satisfactory one day may be woefully inadequate the next. The only way to be sure that you are doing enough is by understanding that when it comes to security, nothing is ever enough for long.

» See All Articles by Columnist Paul Rubens