Bảo mật hệ thống mạng part 12 pot

Chapter 5: Policy
71
NOTE:
It is never a good idea to retaliate. This may be an illegal act and is not recommended in
any situation.
Authority
An important part of the IRP is defining who within the organization and the incident re
-
sponse team has the authority to take action. This part of the procedure should define
who has the authority to take a system offline and to contact customers, the press, and
law enforcement. It is appropriate to identify an officer of the organization to make these
decisions. This officer may be a part of the incident response team or may be available for
consultation. In either case, the officer should be identified during the development of
the IRP not during the incident.
Documentation
The IRP should define how the incident response team should document its actions. This
is important for two reasons, it helps to see what happened when the incident is over, and
it may help in prosecution if law enforcement is called in to assist. It is often helpful for
the incident response team to have a set of bound notebooks for use during an incident.
Testing of the Procedure
Incident response takes practice. Do not expect that the first time the IRP is used, everything
will go perfectly. Instead, once the IRP is written, hold several walk-throughs of the proce-
dure with the team sitting around a conference room table (see Appendix D for sample inci-
dent response scenarios). Identify a situation and have the team talk through the actions that
will be taken. Have each team member follow the procedure. This will identify obvious
holes in the procedure that can be corrected.
The IRP should also be tested in real-world situations. Have a member of the security
team simulate an attack against the organization and have the team respond. Such tests may
be announced or unannounced.
Configuration Management Procedure
The configuration management procedure defines the steps that will be taken to modify

the state of the organization’s computer systems. The purpose of this procedure is to iden
-
tify appropriate changes so that appropriate changes will not be misidentified as security
incidents and so the new configuration can be examined from a security perspective.
Initial System State
When a new system goes into production, its state should be well documented. This doc
-
umentation should include at a minimum:
▼
Operating system and version
■
Patch level
▲
Applications running and versions
In addition, it may be appropriate for cryptographic checksums to be created for all sys
-
tem binaries and any other files that should not change while the system is in production.
Change Control Procedure
When a change is to be made to a system, a configuration control procedure should be ex
-
ecuted. This procedure should provide for the testing of the proposed change before im
-
plementation. Additionally, the procedure for the change and the back-out procedure
should be documented in the change request. After the change is made, the system con
-
figuration should be updated to reflect the new state of the system.
Design Methodology
Organizations that have projects to create new systems or capabilities should have a de
-
sign methodology. This methodology lays out the steps that the organization will follow

to bring a new project into production. A design methodology includes many steps that
are not security-related and thus will not be covered in this discussion. However, the ear
-
lier Security becomes involved in a new project, the more likely it is that proper security
will be incorporated into the final system. For each of the design phases listed in the fol-
lowing sections, we will discuss the security issues that should be examined.
Requirements Definition
The methodology should specify that security requirements be included during the require-
ments definition phase of any project. The methodology should point to the organization’s
security and information policies for some requirements. In addition, the requirements docu-
ment should identify sensitive information and any key security requirements for the project.
Design
During the design phase of the project, the methodology should specify that Security be
represented to make sure that the project is properly secured. Security staff may partici
-
pate as members of the design team or as reviewers. Any security requirements that can
-
not be met by the design should be identified and, if necessary, the waiver process should
be started.
When the system is being coded, software developers should be taught about poten
-
tial coding problems like buffer overflows. In this case, security awareness training may
be appropriate as the coding of the project is started.
Test
When the project goes to test, the security requirements should be tested as well. It may
be appropriate for the Security staff to assist in the writing of the test plan. Keep in mind
that security requirements may be hard to test (it is hard to prove a negative—for exam
-
ple, that an intruder should not be able to see sensitive information).
72

Network Security: A Beginner’s Guide
Implementation
The implementation phase of the project also has security requirements. During this pro
-
cess, the implementation team should be using proper configuration management proce
-
dures. In addition, before a new system goes into production, the Security staff should
examine the system for vulnerabilities and proper security policy compliance.
Disaster Recovery Plans
Every organization should have a disaster recovery plan (DRP). However, many organi
-
zations do not have one because they see them as very expensive and they do not feel that
they can afford a hot site. DRPs do not necessarily require a hot site (an alternate location
for operations that has all the necessary equipment configured and ready to go). Rather, a
DRP is the plan that an organization will follow if the worst happens. It may be a very
simple document that tells key staff to meet at a local restaurant if the building burns.
Other documents may be much more complex and define how the organization will con
-
tinue to operate if some or all of the computer systems are unavailable.
A proper DRP should take into account various levels of failures: single systems, data
centers, and entire sites. The following sections give more detail as to what type of infor-
mation should be included in each section.
Single System or Device Failures
Single system or device failures are the most likely. This type of failure may include a
disk, motherboard, network interface card, or component failure. As part of the develop-
ment of this part of the DRP, the organization’s environment should be examined to iden-
tify the impact of any single system or device failure. For each failure, a plan should be
developed to allow operations to continue within a reasonable amount of time. What
“reasonable” means depends on the criticality of the system in question. For example, a
manufacturing site that relies upon one system to produce production schedules and to

order supplies may require this system to be up within four hours or production will be
impacted. This type of failure could be solved by having a spare system that could be
brought online or by a clustered system solution. The choice will depend upon the cost of
the solution.
Regardless of what solution is chosen, the DRP specifies what must be done to con
-
tinue operations without the failed system. The DRP should be written in conjunction
with operational departments of the organization so they understand what steps they
must take in order to continue operations.
Data Center Events
The DRP should also provide procedures for a major event within a data center. If a fire
should occur, for example, and the data center is not usable, what steps must be taken to
reconstitute the capabilities. One issue that must be addressed is the potential loss of
equipment. The plan should include some way to acquire additional equipment.
Chapter 5: Policy
73
74
Network Security: A Beginner’s Guide
If the data center is not usable but the rest of the facility is, the DRP should define
where the new equipment will go as well as how communication lines will be reconsti
-
tuted. A hot site is an option for this type of event but hot sites are costly. If a hot site is not
part of the plan, the organization should examine other potential locations within the fa
-
cility or at other facilities to rebuild the computer systems.
As with single system events, the DRP should identify how the organization will con
-
tinue operations while the systems are rebuilt.
Site Events
Site-destroying events are the types of events most often thought of when we speak of a

DRP. These types of events are the least likely to occur but also the most damaging to an or
-
ganization. For a DRP to plan for such events, every department of the organization must
participate in its creation. The first step is for the organization to identify the critical capa
-
bilities that must be re-established in order for the organization to survive. If the organiza
-
tion is an e-commerce site, the most critical systems may be the computer systems and the
network. On the other hand, if the organization manufactures some type of product, the
manufacturing operations may be much higher priority than the computer systems.
Testing the DRP
A DRP is a very complex document and it is unlikely that the first attempt at writing one
will result in immediate success. Therefore, the DRP should be tested. Testing is not only
necessary to make sure the DRP is currently correct but to make sure that it stays that way.
DRP tests can be very expensive and disruptive to an organization. With this in mind,
it may be appropriate for the organization to identify key employees and perform
walk-throughs of the plan periodically and full-scale tests on a yearly basis.
CREATING APPROPRIATE POLICY
Now that we have identified and discussed all of the policies that an organization might
have, let’s talk about creating a policy that is appropriate for your organization. Each or
-
ganization is different. Therefore, each organization will have different policies. This
does not mean to say that policy templates are useless. On the contrary, policy templates
are very useful for an organization to examine and to learn from. However, copying some
other organization’s policy word for word is not the best way to create your policies.
Defining What Is Important
The first step in creating organizational policy is to define which policies are important
for you. Not every policy will be needed by every organization. Also, depending on the
situation that your organization is in, there may be some policies that are needed more
than others. For example, an organization that delivers information over the Internet may

require a disaster recovery plan more than a computer use policy. The organization’s
security staff should be able to identify which policies are most important. If not, a risk as
-
sessment should provide guidance in this area.
Security staff should also look for assistance from system administrators, Human Re
-
sources, and the general counsel’s office to determine which policies are most important.
Defining Acceptable Behavior
Some employee behavior will be acceptable and some will not. What is acceptable will dif
-
fer based on the culture of the organization. For example, some organizations may allow all
employees to surf the Internet without restriction. The culture of the organization is thus
relying on the employees and their managers to make sure work is being completed. Other
organizations may place restrictions on which employees are allowed access to the Internet
and even then load software that restricts access to certain “unacceptable” Web sites.
The policies for these two organizations may differ significantly. In fact, the first orga
-
nization may decide not to implement an Internet use policy at all. It is important for se
-
curity professionals to remember that not all policies fit all organizations. Before a
security professional begins drafting policy at a new organization, the security profes-
sional should take some time to learn the culture of the organization and the expectations
of the organization with regard to its employees.
Identifying Stakeholders
Policy that is created in a vacuum rarely succeeds. With this in mind, it is up to the secu-
rity professional to drive the development of policy with the help of other members of the
organization. Security should seek the advice of the organization’s general counsel and
Human Resources Department when developing any policies. Other groups that should
be included in the process may include system administrators, users of computer sys-
tems, and physical security.

Generally speaking, those who will be affected by the policy should be included in the
process of developing the policy so that they will gain an understanding of what is expected.
Defining Appropriate Outlines
The development of a policy starts with a good outline. One set of possible outlines has
been provided earlier in this chapter. There are many sources of good policy outlines
available. Some of these sources are in books but some are available on the Internet as
well. For example, RFC 2196, The Site Security Handbook, provides a number of outlines
for various policies.
Policy Development
Security should drive the development of security policies. This does not mean that secu
-
rity should write the policies without input from other departments but it does mean that
security should take ownership of the project and see that it gets done.
Chapter 5: Policy
75
Begin the process with your outline and a draft of each section of the policy. At the
same time contact your stakeholders and tell them of the project. Invite the stakeholders
to be part of the project. Those who agree should be sent a draft of the policy and invited
to a meeting where the draft will be discussed and comments made. Depending on the
size of the organization and which policy is being developed, there may be a single meet
-
ing or several.
At the meeting, Security should act as the chair. Work through the policy section by
section. Listen to all comments and allow discussion. Keep in mind, however, that some
comments may not be appropriate. In these cases, Security should provide the reasons
why a risk would be increased or not managed properly. Make sure that the rest of the at
-
tendees understand the reasoning behind the choices of the policy.
It may be appropriate to repeat this process for the final draft. When complete, take it
to management for approval and implement.

DEPLOYING POLICY
Policy creation is the easy part. In order to create it, you only had to get a small number
of people involved. To effectively deploy the policy, you need to work with the whole
organization.
Gaining Buy-In
Every department of the organization that is affected by the policy must buy into the
concept behind it. Getting this done is made somewhat easier because you involved
all the stake holders in the creation of the policy. You can show the department man-
agers that someone from their part of the organization was involved and voiced that
department’s concerns.
It also helps if management has agreed that policy is important and needs to be
implemented. A message from upper management saying that this policy is impor
-
tant and that it will be implemented will go a long way to helping gain department
management buy-in.
Education
Employees who will be affected by a new policy must be educated as to their responsibili
-
ties. This is Security’s responsibility. Human Resources or Training can help but it is up to
the Security department to educate employees. This is especially important when it
comes to changes that directly affect all users. Take, for example, a change to the pass
-
word policy. On Monday morning, all user passwords must be eight characters in length
and some mixture of letters and numbers and they will expire in 30 days. When you make
this type of change on a Windows domain, all passwords are expired immediately. This
will force every user to change passwords on Monday morning. Without education, they
will not choose good passwords and will probably call the Help Desk. Likewise, if they
76
Network Security: A Beginner’s Guide