● Best Practices in Network Security - 3 - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: Lg (创造人生的传奇), 信区: Linux
标题: Best Practices in Network Security - 3
发信站: BBS 荔园晨风站 (Sun Mar 19 14:56:00 2000), 转信

Best Practices in Network Security

March 20, 2000
Security Architecture Guidelines
The security architecture guidelines specify countermeasures to the threats
discovered in the risk assessment. This document dictates, for example, where
to place firewalls, when to use encryption, where to place Web servers and how
to allow communication with business partners and customers. It may identify
particular products and give instruction on how to deploy and manage them. The
security architecture guidelines specify the assurances that are in place, the
auditing and the controls.
This part requires expertise, which you may acquire through the services of an
outside consultant or in-house through education, including Web-based resources,
books, technical papers and conferences. Among other sources, The SANS
Institute (www.sans.org), The Internet Security Conference (tisc.corecom.com)
and Computer Security Institute (www.gocsi.com) provide training.

Incident Response Procedure
One of the management procedures in the root security policy is the incident
response procedure. What is considered an "incident" in the first place? What
happens when a security incident is discovered? What is done when the attacker
calls? Who gets called and when?

It's useful to test the procedure with a sort of incident-response procedure
drill. People to consider calling may include officers of the company, the
marketing manager (for press relations), system and network administrative
staff, and the police. When you call them, and in what order, must be part of
the procedure. Calling too many people too soon risks letting the cat out of
the bag, so to speak, or a crying wolf scenario. Calling too few people, too
late, risks lawsuits.

Although this process does not require any particular technical expertise, it
does require a lot of thought. Senior managers should carefully review this
document, after receiving a briefing based on the vulnerability assessment. The
goal is to scare them, but not too much.

Acceptable Use Policies
The root computer and network security policy will point to various acceptable
use policies. (Some call them acceptable use guides, but that makes them sound
negotiable.) The number and type of policies depend on the analysis of your
business requirements, risk assessment and corporate culture. The acceptable
use policies are meant for end users. They explain which actions are permitted
and which are prohibited. So there may be acceptable use policies for computers,
transfer of data, e-mail communications, notebook PCs and Web access.

Recall that these documents are part of (really, hung on the framework of) the
root security policy. You will not sit down one day and write five or 10
acceptable use policies. Rather, you'll put entries--"To Be Written" --into the
root policy to act as placeholders. As your committee assigns writers, you'll
enter their names next to the notation, and after they write it, the root
policy contains it or, more usually, points to it.

There is no special format for an acceptable use policy. It should name the
service, system or subsystem it is regulating (for example, computer use,
internal and Internet e-mail, notebook computers and password policy), and
state in the clearest terms behavior that is and is not permitted. The policy
should detail the consequences of breaking the rules.

System Policies and System Administration Procedures
With a proper understanding of the business requirements and the risks, and
with the security architecture guide in place, your organization can develop
platform-specific policies and related procedures. These often lead to
lock-down guides that address organization-specific steps for hardening
vendor-supplied systems. Lock-down guides are usually products of the system
administration staff, with information gleaned from experience, books and
reference guides. Also, specified here is what software must and must not be in
place, and how the systems are to be backed up and administered.

Other Management Procedures
Management procedures also spell out how information is marked and handled, and
how people can access that information. They establish a principle of "need to
know" and attempt to match access with need.

Management Buy-In
Unfortunately, if senior management is not committed to information security,
your best efforts are wasted. Senior management has to see the inseparable link
between computer and network use and computer and network security. Just as it
(probably) sees computer, network and telephone costs are part of the
investment for doing business, so must it see security costs. Tying security
and services together gives an honest picture of the cost while linking the
cost of security with the benefits of the service. Security costs can then be
seen as a profit enabler.

Someone from senior management should be involved in the process. Although a
corporate security officer is probably too much to ask for, you should be able
to settle for an information systems security manager who reports to senior
management. This manager should have the responsibilities and corresponding
authority for the job. This also signals to the organization the importance of
good security practices.

Senior management must ratify every policy, document or guideline. This does
not mean having the board of directors approve every change to every plan.
Rather, it means the senior staff is aware of the work being done, and supports
it by affirming changes. Security policies alone have no teeth. Corporate
management support supplies that. If senior management does not support parts
of the work, they are essentially dead.

Overwhelmed? Remember, this can't all be done at once. You will leave things
out and get things wrong. Address the known requirements and threats. This is
one of the benefits of a root policy as a framework. It tells us what has to be
done. Do what's possible today, tag residual risks and note tasks to be
accomplished. Will you get perfect security? No. Rather, you'll achieve timely,
usable and sufficient security in the midst of an increasingly dangerous, but
exciting networked world.

Frederick M. Avolio is a computer and network security consultant. Send your
comments on this article to him at fred@avolio.com.

--
☆ 来源:．BBS 荔园晨风站 bbs.szu.edu.cn．[FROM: bbs@210.39.3.97]

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店