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

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

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

Best Practices in Network Security

March 20, 2000
Planning: The Team Determines the Needs
The security planning team should include people involved in different aspects
of IT from different areas of the enterprise. Creating the policy will be a
group effort, and responsible representatives from different departments should
be involved to keep communication flowing. Knowledgeable people, savvy in
business requirements, technology and security, are necessary. Few will be up
to speed in all these areas, which is one reason for the group effort. IT staff
members--systems and network administrators--must be involved.
Once the team is created, the first step is an analysis of business
requirements. What services are required for business, and how might those
requirements be met securely? The hardest part is distinguishing wants from
needs.

The team, with all its members' viewpoints, determines the business needs for
computer and network services. How much do employees depend on Internet access,
use of e-mail and availability of intranet services? Drill deeper and look at
particular computer and network services. Do they rely on remote access to the
internal network? Is there a requirement for access to the Web? Do customers
access technical support data via the Internet?

For every service, it takes discipline to ask repeatedly, "Is there a business
requirement?" But that's the most important question.

Threats, Vulnerabilities and Risks
The planning phase involves development of what can be called vulnerability
analysis, risk analysis or threat assessment. Although the terms have slightly
different definitions, the end results are similar. This phase encompasses
asset identification and evaluation; postulation and analysis of threats;
vulnerability assessment; appraisal of existing countermeasures, and
cost/benefit analysis. Numerous factors are considered, including how
information is used and managed, and how good and relevant existing security
measures are. Assets (including information) as well as threats are classified.
The goal is to consider the things indicated as business requirements.

This is another reason to create the team of people from different areas of the
company. While some of the team members' opinions may be off-base, the
cross-section of disciplines provides a more complete picture than one gotten
by interviewing people in marketing, sales or development. This is the time to
ask questions such as these:

What are we trying to protect? Corporate image? Future product plans? Employees
from recruiters? Personal information? Client information? Computer resources?
All are possible and all could be valid.

Which attacks are possible? Which are probable?

Where are we vulnerable? Vulnerability-assessment tools can help pinpoint those
areas (see "Resources," page 68). Don't forget to consider people as a source
of vulnerability. Employees who answer telephones, business partners with
access to proprietary information, and customers who access the support
database all are potential threats.

What are we concerned about keeping? What would we hate to lose? What are these
items worth? How much would it cost to replace them? What would it cost to lose
them? (Another benefit of a group: Some will see the material costs while
others will think of intangibles, such as costs to reputation and investor
confidence. Both opinions are useful.)

How valuable would the following be to an attacker (possibly a competitor): our
company losing data, our hurt reputation or a competitor acquiring data?

How much would it cost an attacker to attack us?

How much would it cost to counter?

What security measures are in place? Are they working? Are they relevant?
It's possible to classify threats on a scale of 1 to 5, or to put them into
categories, such as: "Fix immediately," "Uncertain--needs more study," "Watch
closely, but don't take immediate action," "Don't care." In this way threats
are classified, vulnerabilities are assessed and residual risks are cataloged.

Root Security Policy
With this preliminary work done, it's time to develop the root security policy.
This is where the risk assessment and business requirements come together and
where differences are worked out. The root security policy addresses how an
organization handles information, who may access it and how. It also specifies
allowed and denied behavior. And it lists controls that are in place.

This high-level document provides the framework upon which all required
information and subpolicies hang. The root policy's top-down approach makes it
possible to adhere to the guidelines and produce meaningful and useful work,
without the pressure of having to get it 100 percent correct and complete from
the start. This framework lets anyone look at the document anytime, and see
where the holes are. There are resources on the Internet and in books to assist
in this step. There are even samples of policies and related documents.

The root security policy typically includes the following items:

Root security policy overview

Security architecture guide

Incident-response procedures

Acceptable use policies

System admin procedures

Other management procedures

There is no magic here. You may have more sections. You may have fewer (see
"Developing the Plan," above).
The overview explains the purpose of the policy document, describes its makeup,
details who is responsible for what and states the procedures and expected time
frames for making changes. Remember, the ground rules say some things are bound
to go wrong, and requirements and threats will change over time. Stating up
front how to get things changed helps people more easily accept the policy and
related documents. Doing so also calms the concerns of policy-shy management.

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

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