security assessment case studies for implementing the nsa iam phần 5 potx

Understanding the
Cultural and Security Environment
Understanding the cultural and security environment involves more than under-
standing the location of the room that contains the components that process,
store, or transmit an organization’s critical information.As the INFOSEC
assessor, you need to understand the operational culture and security environ-
ment that houses the critical information.
TERMINOLOGY ALERT
The cultural environment is made up of the people who work in that
environment and their perceptions of how things are done or should be
done.
The culture of the organization can, and does, vary with the people in the
environment. It includes customer perceptions of their requirements and how
those requirements apply to the organization.This information leads to identifi-
cation of the security environment.
TERMINOLOGY ALERT
The security environment is made up of the documented requirements
for operations. The requirements can be in the form of legal require-
ments and official and unofficial policy.
Defining the customer’s perceived environment depends on the applicable
laws, regulations, and architecture. Few laws or regulations apply to all organiza-
tions.You as the assessor must understand the appropriate regulations to facilitate
the definition of the security environment.
The Importance of Organizational Culture
The organization’s culture is important. Recommendations that you make should
fit the organization’s operational requirements. We are all aware that security is
www.syngress.com
154 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 154
usually seen as a hindrance to work. Many people distrust any implementation
that is security related. Many aspects of the organization’s environment define the

culture and need to be identified.The organization’s culture depends on many
factors, including employees’ personal backgrounds (education, experience) and
unofficial or unwritten goals and objectives. Some organizations do not want to
share any information that is not required; others want to show that they are
sharing everything possible.
The cultural environment of a higher education institution is usually one that
promotes (and even advertises) its openness.To the users, this means that there
should be no restrictions on access to any information located within or outside
the institution.This is not the case in federal government agencies.They tend to
feel that any access should be controlled and limited to people who have a need.
Understanding these views is important; otherwise, the team could possibly make
recommendations that the customer is not likely to implement. What would be
the value of that? Recommendations should fit the organization and provide a
road map to improving its security posture.
www.syngress.com
The System Security Environment • Chapter 5 155
Users Hate Change
The recommendations that are made must fit the organization. If you
are dealing with an organization that has relied on a command-line
interface (CLI) for years, suddenly forcing employees to use a graphical
user interface (GUI) can cause serious contention. There was a time
when the security recommendation for a customer that was using
Tandem mainframes was to migrate all the users from the native
Guardian software interface, which was command line to BOSS software
that is GUI based. The users hated the idea. In this environment the users
tended to have long tenures within the organization. The idea that they
couldn’t have their CLI was unacceptable to them.
Due to the requirements for the security environment, the users lost
the argument and had to migrate. The users tended to try to break the
application in order to show that they should have stayed with their

favorite. This situation became a headache for the implementers and
managers. A good lesson learned from this situation was that there
should be an intermediate step in the migration process to allow the
users to adjust to the change without a radical cross-over.
From the Trenches…
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 155
Adequately Identifying
the Security Environment
The assessment team must gain an understanding of the operational environment
and mode of operation of each system that processes, stores, or transmits the
organization’s critical information.This information can be drawn from system
architecture and configuration documents, functional and security concept of
operations (CONOP), and diagrams and schematics.These documents provide
the written facts detailing how the organization should be operating. But don’t
forget the senior management interviews that you have already completed.They
are very useful in identifying the environment.There are some unofficial ways to
assist in determining the environment, such as observation. During interviews
and system demonstrations you will find that users are doing things for which
they can cite no reason. All they really understand is that these “things” are a
requirement.
To understand how the system works, the assessment team needs to review
available information, including customer-supplied documents such as architec-
tural documents, available functional and security concept of operations
(CONOPS, SECONOPS), and literature available through open sources such as
the Internet. CONOPS or SECONOPS are documents that are readily found in
the federal government but that rarely exist in the commercial world.They are
supposed to document how and why security controls are used. From experience
we have found that usually the CONOPS are quite a bit more extensive than
just the “how and why.” CONOPS tend to be expanded to become procedure
guidelines and even SOPs.

Draw information about the system from accurate system diagrams. Without
diagrams, boundaries will never be defined. Without boundaries, the assessment
will be very susceptible to scope creep.
TERMINOLOGY ALERT
Scope creep is the addition of work beyond what the assessment team
was originally prepared to do. Scope creep results when the customer
adds requirements or includes new components when the assessment
team does not have well-defined boundaries.
www.syngress.com
156 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 156
If diagrams don’t exist, you have two options.You can have the customer
create them or you can provide assistance to get it done. Keep in mind that there
are two types of system diagrams that you need:
■
Logical diagrams From the owner’s and user’s perspectives, depict the
system(s) of information utilization and data flow.
■
Physical diagrams Depict the system(s) from the physical component
perspective of connectivity and interfaces.
The logical diagrams are useful in dealing with upper management. In our
experience, using a physical diagram with upper management is a waste of time
while these people examine the diagram to determine where they are on it.
Logical diagram are the better way to go with upper management. Managers
tend to understand the logic information flow displayed and can quickly deter-
mine functional relationships. Physical diagrams are much more detailed and
show all the components that make up the physical plant.
www.syngress.com
The System Security Environment • Chapter 5 157
Network in Flux

Network diagrams allow you to map and scope the assessment to the
actual components within the organization. If you are dealing with a
high-tech startup company, the proposed network might be incomplete.
For one such company for which we completed an assessment, the
entire network was a work in progress. The company had been in oper-
ation for about a year, and when we asked to see the network diagram
we were shown the frosted glass windows of a conference room. All the
windows had been used to draw the proposed final network. When we
asked if this was the actual network, we were told no. At that point the
customer pointed to a spot on the glass and said, “We are about here.”
The result is that the customer really didn’t know of what their
actual network consisted. We chose the route of assisting them. Our net-
work engineer transcribed the drawings to paper and worked with the
customer to validate the network configuration. Without the network
diagram, no boundaries could be defined.
From the Trenches…
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 157
If the organization is a federal classified system, you will also need to deter-
mine mode of operation (for example, system high, multilevel, dedicated, or the
like). Mode of operation is well defined in DoD 5200.28-STD, Department of
Defense Trusted Computer System Evaluation Criteria.The most common mode
that assessors will see is system high. System high is simply explained as a system
in which all the personnel who have access to the system for any reason must
have a security clearance equal to the highest level of classification of any infor-
mation that is processed, stored, or transmitted by that system.This requirement
applies to anybody, even if they do not have specific access to that classified
information.There are various other levels of mode of operation; if you are not
sure what the system definition means, read DoD 5200.28-STD, Department of
Defense Trusted Computer System Evaluation Criteria
(www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html).

Determine system operations and functions, note external and internal con-
nectivity to other systems, and generally describe the system configuration in
writing.This is important for your assessment team.This information will be
used later in the pre-assessment plan and in the final report. Often it is also very
useful for all the players to agree on a description to augment the network dia-
grams. Identify the key components and primary operation operating systems. It
is usually a good idea to write one or two short paragraphs to describe the con-
figuration in narrative form.The IAM is not an analysis of physical security;
however, physical security will affect vulnerability analysis and recommendations.
WARNING
Be careful to keep your poker face in place. Identifying an issue that
could occur is a pre-judgment of findings and vulnerabilities. Trying to
deal with perceived vulnerabilities before they are proven will cause the
customer to distrust you. All identified issues should be listed and inves-
tigated during the onsite phase, not during the pre-assessment.
Remember, your team doesn’t necessarily have all the information yet
and shouldn’t pre-judge.
www.syngress.com
158 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 158
Defining the Boundaries
Defining the boundaries is paramount to defining the assessment’s scope and
controlling scope creep. Problems can occur and will occur when this step is not
adequately completed. Boundaries ensure that everybody knows where the
assessment team stops. As the pre-assessment continues, the customer will become
better educated on the process, and it is not unusual for the customer to begin to
add things to the assessment. Keep in mind that if you don’t have a good
boundary, the boundary can be shifted.These boundary shifts may each be
minor, but they will add up. As they add up, they will begin to stretch the
resources of your assessment team.You must keep in mind that doing the pre-

assessment in and of itself is a service to the customer.You are removing the
proverbial horse blinders from senior management. Often, as an organization
becomes set in its ways, management tends to become more fixated on business
accomplishment than the big picture. Little things begin to get lost in the weeds
of day-to-day operations.
www.syngress.com
The System Security Environment • Chapter 5 159
The Never-Ending Assessment
Without well-defined boundaries, the customer will easily add compo-
nents and other activities to the assessment. This is not to say the team
won’t do the work, but they may not have the resources to adequately
do the job if it expands much beyond the original plan. Take the example
of an ISP assessment we did. The boundaries were set to assess the orga-
nization. There was no physical network diagram. The organization was
verbally defined as consisting of three floors, all located in one building.
When the assessment team arrived on site, they discovered that the net-
work extended out of the building. The customer expected that the
assessment would include their perimeter devices located across town.
The assessment team had no problem with including the devices. Then
the customer wanted the interlinking devices to be included. The assess-
ment team was forced to spend two extra days to generate and gain
customer approval of what the network consisted of.
From the Trenches…
Continued
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 159
Now that you have reawakened the awareness of what everybody is doing,
why they are doing it, and what the interdependencies are, you will hear
thought-provoking discussions between management. When the team returns for
the onsite or even right after the project has been scoped and bounded, most
customers usually want to add to the assessment.This isn’t a bad thing; it shows

that the pre-assessment was highly successful in increasing the security awareness
and security concerns of senior management. Unfortunately, though, this can lead
to the team being unprepared to handle the extras that are requested.This is nor-
mally the time you’ll need to do a contract modification. One way to handle this
issue before it becomes a problem is to adequately define the boundaries, both
physical and logical. Hopefully you will make the two meet to allow everybody
to understand the limits of the system(s) under assessment.
Physical Boundaries
Although we already discussed the physical boundaries in Chapter 4, “System
Information Criticality,” we review the concept here to see the effect of the
boundaries on the scope of the assessment.The physical boundaries are fairly easy
for middle managers and managers below them to recognize and understand.
These are the points that they are used to dealing with.They can be identified as
simple things such as a wall jack, router, and/or perimeter device.You already
identified most of these items when you defined the System Information
Criticality Matrix (SICM) covered in the last chapter.
It is considered a good practice to tie the physical boundary to a specific
component and a specific address on the component.This will mean that you
need to consider at what part of the component to stop.This is setting the phys-
ical boundary for the assessment. For example, if you are assessing a system that is
connected to a shared router, are you going to define the assessment boundary as
www.syngress.com
160 Chapter 5 • The System Security Environment
The result was that the added components included a development
network and network operations center that were located in various
other buildings. With the contract already signed, this extension of the
boundaries resulted in exceptionally long days for the assessment team.
The assessment was completed, but it took extra effort on the part of
the assessment team to define the new boundaries and wasted valuable
resources during the onsite phase.

286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 160
the system input to the router or the entire router? Again, this decision should
have been made when you defined the SICM.This leads us to the logical part of
the boundary.
TERMINOLOGY
ALERT
Physical boundaries are defined by the locations (for instance a room, a
building, or a complex) of the system equipment and local procedures
regarding the handling and processing of particular types of information.
Logical Boundaries
Logical boundaries are something that is not so easy for upper management and
most middle management to understand and recognize. As discussed in Chapter
4, this is the point at which the customer has no physical control over the infor-
mation. Usually management does not realize that this an issue.They want to get
that warm and fuzzy feeling that their information is being protected as they feel
it should be.The problem is that senior management often does not understand
that they really don’t have any control over those components.This is where you
as the assessor must educate them.The customer must understand how the log-
ical boundary will affect the scoping of the assessment. Consider the issues of
having the logical boundary set at the perimeter router. Who owns the router?
In many organizations, the ISP or a parent organization owns the perimeter
router. If the ISP is one of the major providers such as Sprint, MCI, or AT&T,
they might not agree to allow any review of the router.The service-level agree-
ment (SLA) may even forbid review of the rule sets used.
TERMINOLOGY ALERT
Logical boundaries are defined by where responsibility for or authority
over information changes hands.
www.syngress.com
The System Security Environment • Chapter 5 161
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 161

Never the Twain Shall Meet—Or Should They?
One of the key issues to boundaries is ensuring that everybody involved under-
stands and agrees to them. As we have discussed, you can see that it would not be
unusual for the customer to define two different boundaries.This will make your
assessment difficult.The issue is whether or not you do the customer any service
in including components that they have no control over. Consider the case in
which the system for which you are doing the assessment has a physical
boundary of a firewall.The firewall is across the street and under the physical and
logical control of another organization.The other organization can be of equal
status to the organization that hired you, or it could be a parent organization.
Does it really matter? The other organization did not request the assessment, has
no buy-in to do the assessment, and may have other operational commitments.
Also consider the cabling that connects the two organizations. Is it controlled by
another separate entity? You might want to ask if your customer has ready access
to the cabling and firewall, or do they need to ask for access? In this situation the
customer has a physical boundary of the firewall and a logical boundary of the
router within their own organization.
The simplest method in approaching this situation is to merge the two
boundaries.This way there are no conflicts or issues with external organizations.
But merging can be an issue in and of itself. Political motivations are usually
involved when the customer wants to include components that they have no
control over. Being a good listener and asking open-ended questions will usually
help you reveal why the customer wants to include the external organizations.
We don’t recommend that you become involved in the organization’s internal
politics. We do recommend that you try to convince the customer of the value
of merging the two boundaries.This will ease the resource requirements on their
side, since they would be responsible for coordinating and providing access to the
external organizations and components.The customer must clearly understand
that lack of this access will affect the results of the assessment.
Identifying the Customer

Constraints and Concerns
Without a doubt you can be assured that senior management will always agree
that security is important.Typically, this agreement tends to mean that security is
important until it becomes an inconvenience. We are aware that security affects
www.syngress.com
162 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 162
production. Many technical security implementations cause network perfor-
mance degradation. Any component that is inserted into a network will slow it
down, even if only by nanoseconds.This is why it’s important for you to deter-
mine the customer’s pain threshold.
The pain threshold equates to the limitations the customer is under. If the
customer is already running above 85 percent network capacity, they might not
be able to implement any component implementations that will further reduce
available network bandwidth. Legacy applications may have adverse reactions to
some solutions. It makes no sense to recommend solutions to mitigate findings if
the customer is unable or unwilling to implement the solutions.You need to
work with the customer to determine the constraints and concerns that have to
be addressed.
Defining Customer Constraints
Why do you need to know the constraints? You need to know the constraints to
provide useful recommendations that fit the customer and their unique situa-
tions. Knowledge of constraints is helpful when you’re offering alternative rec-
ommendations. As we all know, security almost always affects performance. Using
the IAM process allows you as the assessor to identify both the benefits and
drawbacks of security. Knowing the positive and negative impacts is essential to
being able to speak to the customer about which countermeasures are most
appropriate for their organization.You need to be aware that operational con-
straints, resource constraints, environmental constraints, or even architectural con-
straints may be imposed on recommended countermeasures.

Types of Operational Constraints
Operational constraints come from the users or the type of work being done.
This is something that can be drawn from the determination of the operational
environment.This means that you need to understand the normal work opera-
tions. If the operational environment requires batch processing, there are win-
dows of time in which the assessment could potentially interfere with operations.
This type of operational constraint is normally called peak processing periods.
Normal work hours are something to consider. Many organizations do not
operate 24 hours a day, 365 days a year.Time constraints affect the availability of
personnel for interviews and demonstrations.This is another operational con-
straint normally called normal work hours.
www.syngress.com
The System Security Environment • Chapter 5 163
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 163
Types of Resource Constraints
During interviews, observation of normal operations, and observation of system
demonstrations, the assessment team will potentially identify numerous resource
constraints. What organization ever has enough money or people to implement
security to the fullest extent? We have never seen one. Management may let you
know about budgetary constraints as well.This is good information that will def-
initely affect the recommendations your team provides in the final report.You
don’t want to make a recommendation for the immediate implementation of a
security solution that the organization doesn’t have the money implement. But
you might want to make the recommendation for a long-term solution that will
require budgetary increases in out-years to implement recommendations.
This is part of making the road map for improving the security posture.
Many organizations don’t have the resources to implement “Cadillac solutions”
immediately.This doesn’t mean that you cannot give them that recommendation.
You should give them an option to implement at a later date when the resources
are available. An example could be implementing a segmented network with fire-

walls to separate business lines.The organization may not be able to implement
several new firewalls due to resources such as budget for training and procure-
ment, but they would be able to increase the budget in the next fiscal year to
allow for the implementation.
Users and administrators will tell you about the lack of staffing and inade-
quate equipment or training to do their jobs as well as they want or need to.This
is also good information; just don’t take it as fact. Many users and administrators
do not have the big picture of the goals and objectives for the organization. Use
their information as additional clues to the current security posture of the orga-
nization and what is needed to make it better.
Environmental Constraints
Environmental constraints usually come from two places.The environment con-
sists of the natural and manmade conditions around the system being assessed.
Some environmental laws can provide some constraints. For example, if the rec-
ommendation is to install a diesel generator backup system, and the grounds
around the facility are protected marshlands, you will probably need to look at an
alternative recommendation, since it might not be possible to get the appropriate
permits for a fuel storage tank installation.
www.syngress.com
164 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 164
The same idea can apply to the manmade conditions. Occupational Safety
and Health Administration (OSHA) regulations often limit the installation of cer-
tain types of locked doors in a facility. Additional things to consider are the orga-
nizational culture and local customs. In certain areas, local celebrations can
severely influence the availability of people. For example, consider doing an
assessment in New Orleans during the month of February; doing an assessment
during Mardi Gras would be fun but probably not very effective. Some local cus-
toms, such as the first day of deer-hunting season in some states, could also affect
the availability of key personnel.

Architectural Constraints
Some constraints are imposed based on the architectural implementations of a
system.The users and administrators can also impose these constraints as a level
of acceptable performance degradation within the system. Some examples of
architectural constraints are operating systems such as Novell Directory
Information Services (NDIS) and Windows NT and current Internet connec-
tivity such as Fiber Distributed Data Interface (FDDI). With each of these sys-
tems come special considerations that you need to take into account when
making recommendations. Most of these would require a significant change to
the network that the customer may not be willing or cannot afford to change.
Architectural constraints can and usually do include legacy applications.There
are still a lot of old applications running that have no replacement available or are
proprietary in nature.These usually have hardcoded interfaces that do not work
well with newer technology.Take the case of using a proprietary database appli-
cation running on OS390.The application was probably written in the early
1970s, and the customer probably doesn’t want to change it.The interface or
front end for the users was developed and hardcoded to use Windows NT 3.51.
This would be an architectural constraint.The customer needs to keep the
unsupported operating system (Windows 3.51). Recommendations to improve
the security posture that are based on upgrading the operating system are of no
use to this customer.
TERMINOLOGY ALERT
OS390 is a mainframe operating system developed by IBM. More informa-
tion about OS390 can be found at www-1.ibm.com/servers/s390/os390.
www.syngress.com
The System Security Environment • Chapter 5 165
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 165
Determining Customer Concerns
Constraints are one thing, but what are the customer’s concerns? Often the
assessment team will not be made aware of these concerns when the assessment

begins.You, as the assessor, need to figure out the customer concerns from your
interviews with senior management.The best way to do this is to identify why
the customer really wants the assessment done and whether there are any specific
areas that the customer wants covered.
Why Are You There in the First Place?
Many of us have done these assessments because the customer has a requirement
to have an assessment done. But is that always the only reason that you are there?
Not usually.There are normally hidden agendas that you would be wise to iden-
tify, if possible. Many assessments that are done for compliance with due dili-
gence efforts such as for cyber insurance are more concerned with showing that
there are no issues to be dealt with than improving the security posture.
Doing an assessment of an organization that is being acquired by another
company is another good example. On the surface, the primary goal is to identify
and mitigate vulnerabilities that might be inherited by the parent organization
before allowing a direct connection to the customer organization. But given
most business models, the reality is to identify the current posture and then let
them connect. Unless you find issues that are business stoppers, the connection
will proceed.
Sometimes INFOSEC assessments are conducted following a security inci-
dent to identify and resolve the issues that led to the security incident. Be careful
of this situation. Many times we have seen that the real reason for the assessment
is usually to provide enough proof to ruin somebody’s career.
Specific Criteria to Assess
It is hoped that the reason you are there is to help improve the organizational
security posture. However, the customer may have in mind that you are there for
specific areas and that is all that they are concerned with. In our class, we teach
the 18 topics that should be covered in every assessment.The 18 topics are
grouped into three areas; managerial, technical, and operational. In some assess-
ments the customer will not want to have some of these topics covered. One
good example of this situation was a customer that was in the middle of modi-

fying their contingency plan.The current plan addressed physical issues but did
www.syngress.com
166 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 166
not adequately address information system restoration.The customer already
knew this and had a committee actively addressing the issues. In this case, contin-
gency planning was not part of the assessment.The final assessment report noted
that by customer request, contingency planning was not covered.
In another assessment the customer did not require was system assurance
beyond the basic security analysis.They were not submitting for any certification
and accreditation (C&A), the customer did not need any formal security test and
evaluation (ST&E), and the customer did not need to have the independent veri-
fication and validation (IV&V) completed. In this case as in the previous one,
those areas were dropped from the assessment, and the final report noted that
they were not covered due to customer request. Does this mean that you should
ignore these areas? No. Most of the time it is fairly easy to identify issues that
were not specifically identified by the customer.
Here’s a good example, one that we use in teaching this methodology in
class. Many organizations enable all the network wall jacks to allow guests and
workers to move from one location to another and continue working.This is
good for ease of use but exposes the customer to unauthorized access to the net-
work.The assessment team may not be looking for this issue, but it will become
aware of and should report the issue to the customer. It usually does not take any
extra effort to identify and report something like this. So there is no loss of
resources and you are providing a value-added service in you assessment.
The goal here is determining what the customer is concerned with and map-
ping those concerns to the baseline INFOSEC classes and categories that are dis-
cussed later in this book. With a little discussion and thought, you will be able to
show the customer the value of having the assessment look at all the IAM classes
and categories.

Handling the Documentation
Identification and Collection
Now that you have the defined the boundaries of the assessment and understand
all the concerns and constraints, it’s time to get the documentation. Some people
would start asking for the documentation as soon as they arrive for the pre-
assessment visit or even request that the documentation be gathered prior to
their arrival. We don’t recommend that. Requesting the documentation prior to
arrival for the pre-assessment site visit or even defining the scope and boundaries
of the assessment can result in a flood of documentation that is of no value to
www.syngress.com
The System Security Environment • Chapter 5 167
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 167
the team. Wait till you know what you are going to assess and the assessment
boundaries prior to requesting the documentation.
Documentation is nearly always an issue. Does the customer have documen-
tation? Can you have or review the documentation? How do you track the doc-
umentation? What happens to the documentation after the assessment? The
assessment team should obtain and review all relevant INFOSEC documents to
prepare for the onsite visit.You need to request the documentation from the cus-
tomer; we always try to get the documentation in softcopy to allow for easier
handling. If it isn’t available in softcopy, the requested documentation can either
be brought back from the pre-assessment visit or mailed to you. If you are going
to have it mailed, ensure that you receive it with sufficient time prior to your
onsite visit to allow the entire team to review it.
We recommend that you have your entire team review any documentation
relevant to their experience and knowledge set prior to the onsite phase of the
IAM. We understand that many technicians do not like to do documentation
review, but it is an important step. Each member of the team has a different
background.This allows each to identify certain things in the documentation that
they feel could be an issue or a finding during the onsite. Just keep in mind that

they are not findings at this point because they are not proved.The onsite is
where potential findings will be proved or disproved.
Tracking the documentation is an issue of document management.The exact
means for tracking documentation is a business process, but the fundamental
requirements are the same in any business process. In this process we use the assess-
ment plan as the tracking device. Figure 5.1 shows the basic layout that we use to
track what was requested, when it was delivered, who has the document, and what
was done at the end to return it or destroy it.The key issue here is to ensure that
all documents are accounted for. In most cases, we usually give a copy of this layout
to the customer-appointed primary point of contact (PPOC). (The assessment plan
is described and discussed in Chapter 6. It is sufficient to say here that the assess-
ment plan is a living document that we will use throughout the assessment.)
www.syngress.com
168 Chapter 5 • The System Security Environment
Figure 5.1 Basic Layout of a Document Tracking Device
Title
Date
Requested
Date
Received
Custodian
Date
Destroyed or
Returned
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 168
What Documentation Is Necessary?
What documentation should you be looking for? That’s pretty easy: any docu-
mentation of the system being assessed that deals with the security posture of
that system. Knowing the titles of such documents is the hard part. Different
organizations use similar or even different names to identify their documents. In

Appendix A we include a list of the titles that we have seen in more than one
organization. However, the function of each document type is the same without
regard to the title.These documents are:
■
Policy
■
Guidelines/requirements
■
Plans
■
SOPs
■
User documentation
Policy
Policies provide the overall upper management protection philosophy for the
system or organization. Policy documentation should specifically identify the
mission of the organization, information criticality, INFOSEC management
structure, enforcement of least privilege through individual accountability, and
configuration control. Policy can be very broad and can cover an entire organiza-
tion or multiple systems—but there should always be policy. Without policy
there is no guidance for the management or maintenance of the security posture.
Guidelines/Requirements
The guidelines and/or requirements should further explain the policy from a
middle management or senior technical implementation aspect.These documents
should explain how the guidelines or requirements help meet the policy.
Implementation of individual accountability should be explained, and the min-
imum system documentation that is required and the review cycle for that docu-
mentation should be identified. Guidelines and requirements should address
specific issues such as identification and authentication, but they can cover the
entire organization or multiple systems.

www.syngress.com
The System Security Environment • Chapter 5 169
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 169
TERMINOLOGY ALERT
Individual accountability is the ability to track and trace system activity
to specific users.
Plans
Plans are just that: How are we going to do it? Plans should be the road map for
how the technical requirements will be implemented into the system. Plans
should address the implementation of all guidelines and requirements that apply
to a specific system.There should only be one plan for a given system. Plans are a
normal part of any certification package and are required for any interim
authority to operate (IATO) for federal agencies.
Standard Operating Procedures
SOPs are for day-to-day use. SOPs should explain any required recurring activi-
ties in sufficient detail that a competent operator can accomplish the work. SOPs
are normally required for systems administration activities such as audit reviews
and account management. SOPs should also cover any privileged user activity
that is beyond normal user activity.Think of SOPs as mitigation for the Mac
truck theory.You only have one person who does a specific task or activity, such
as audit log reviews. What happens if a Mac truck hits that person during lunch?
Who will pick up that person’s workload and ensure that all the minimum activ-
ities are accomplished? The SOP is the guide that allows a competent individual
to fill in and accomplish the job.
User Documentation
User documentation provides users with the security information they need to
do their jobs. It should include information for awareness and training of the
system and information security aspects of each job.There should be guidance
and procedures for the user on specific subjects such as password generation and
protection, defining session controls such as unattended terminals, and any other

topic that is relevant for users to do their jobs securely.
www.syngress.com
170 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 170
Obtaining the Documentation
Now that you know what documentation you would like to get from the cus-
tomer, how do you obtain it? We really don’t recommend that you simply start
walking around and picking up documents from desks and folders. Customers
really wouldn’t like that.The customer always wants to know what you have or
don’t have.They want to be able to track this material in case it is sensitive or
proprietary.
Through the interviews and discussions that you have with the customer, you
will learn (if you don’t already know) the actual titles of documents that you
want. We recommend that you utilize the customer team member or the PPOC
to obtain these documents.You can request the documents through them to
allow the customer to track all materials provided to the assessment team.
Use the Customer Team Member
This is one of the prime places in which the customer team member is a valu-
able resource for your assessment team. Instead of you the assessor going through
all the various people to obtain a document, let the customer team member do
it.That individual probably already knows where the documents are and can get
them with a lot less explanation than you would have to provide.This person
should also be the one to officially tell you if the documentation does not exist.
Never make the assumption that the documentation does not exist.
Tracking the Documents
In the assessment plan, you should list all the documentation that you have
requested and received. We recommend that you list the documentation by type,
title, date received, custodian(s), and the date returned or destroyed.This allows
you to track the documentation throughout the assessment and find or obtain
the document quickly without having to chase it down.

All customer documentation should be tracked for the life of the assessment.
There should be no doubt as to the status of each piece of documentation. If you
have not received a document, the date received should state “Not Received.” If
the customer team member or PPOC tells you that the document does not
exist, the date received should state “Does Not Exist.” Be careful to ensure that
you have something in writing (a note or e-mail) that states that a document
does not exist.
www.syngress.com
The System Security Environment • Chapter 5 171
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 171
Determining Documentation Location
Now that you know what documentation to look for, where do you find it and
how do you get it? Our preference is to get all documentation in softcopy form.
Receiving softcopy of documentation allows for rapid transfer of the documents
to other team members for review and comment. At times the customer will not
provide softcopies of things such as proprietary documents or other documents
that are considered sensitive. Sensitive documentation can also include classified
documentation. Sensitive documents are usually only in hardcopy form to allow
for individual accountability of custody. If the documents are considered very
sensitive, it is common for the documentation to be viewable only in the cus-
tomer space, such as a technical library. When that is the case, the team will have
to allow extra time on site to do the documentation review. If the documents are
available only in hardcopy but not sensitive, you should still track the custody of
the documents through the assessment plan.
What If No Documentation Exists?
Now that you know what kind of documentation to look for and how to get
that documentation, let’s look at the types of documentation that do exist. By
this we mean the validity of the documentation. We have found that documents
fall into four categories: valid, out of date, draft, and nonexistent. During the pre-
analysis you and your team will have to determine in which of the categories

each document belongs.
Valid documentation is current and has been reviewed for applicability
within the last year. It probably has some tracking mechanism such as version
control built into it. If you are dealing with a large corporation or a government
agency, it’s not unusual to find that they have documentation but that it is old—
usually well over a year since the last update.Yes, that is a finding if it is not appli-
cable to the current system configuration. Remember, at this point in the
pre-assessment, we are only identifying possible findings. When you get on site
you will verify if the documentation is actually valid.
Out-of-date documentation is easy to identify when you get on site because
the system is operating differently than the documentation identified. One good
clue during the pre-assessment is the identification of components or personnel
that the customer has already identified as no longer in use. Again, verify this
information when you get your team on site.
www.syngress.com
172 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 172
Draft documentation is not a bad thing. We work with organizations that
have documentation in draft all the time.They call this documentation “living
documents” that change as needed to fit the system changes. Draft documenta-
tion is a bad thing when it is “fresh” off the printer. By this we mean that the
document has not been approved by senior management and distributed to the
appropriate personnel within the organization. In this case we are usually being
asked to review the document and provide feedback prior to publication. We
normally tell the customer that such documentation is not applicable to the
assessment since it has not been implemented but that we will provide comment
as time allows.
The last category of documentation is nonexistent.This is just what it says—
the document has never been generated for the organization. Often in commer-
cial assessments this is the normal situation rather than the exception. Lacking

documentation is a bad thing and is a finding. Without good documentation
there can be no consistent and long-term acceptable security posture.
Lack of documentation in no way means that there is a lack of security
within the organization or system being assessed, however. It merely means that
the organization is relying on the efforts and practices of individuals who have
no guidance as to the policy or guidelines for the organization or system. Does
this mean that a lack of documentation should be on the top 10 list of significant
findings? We believe that if you have a lack of documentation, you will find
more immediate issues that need to be dealt with in the near term than docu-
mentation. Documentation takes time to create. If you have a lack of documenta-
tion, you will always find technical controls that are inconsistently applied and
vulnerabilities to the organization that need to be addressed immediately.
Ad Hoc Security
The prime result of a lack of documentation is ad hoc security. By this we mean
that there are pockets of good security practices within the organization, but
security is not consistently applied. Security within an organization that does not
have good documentation will be lacking.The reliance on individual efforts and
expertise will lead to an eventual failure of security controls without anyone
within the organization noticing until there is a security incident. Such security
incidents or breaches can go unnoticed for an uncomfortably long time and
could result in significant damage to the organization.
www.syngress.com
The System Security Environment • Chapter 5 173
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 173
Case Study: Higher Education
We had just completed the Organizational and System Information Criticality
Matrices for the Information Services Technology (ITS) division of this higher
education institute. Now it’s time to define the goals, objectives, and boundaries
and obtain the documentation.
The first part of this process seemed easy.The culture was a little different

than we had expected, however. ITS had this mentality: How do we control the
users without them knowing it? For this higher education institute, the board of
governors and college of deans both had stated that an open learning environ-
ment was essential for operations. ITS was responsible for all backbone opera-
tions, Internet connectivity, labs, help desk, and administrative networking, but
they had no say as to the operations of the dorm network or the colleges.This
made their life, from their perspective, very difficult. Although the only regula-
tory input that ITS followed was for compliance with the Family Educational
Rights and Privacy Act (FERPA), they were very worried about how to control
the dorm network.
TERMINOLOGY ALERT
FERPA is a federal law that protects the privacy of student education
records. The law applies to all schools that receive funds under an appli-
cable program of the U.S. Department of Education. The intent of the
law was to extend the Privacy Act of 1974 to cover higher educational
student records. More information on FERPA can be obtained from the
U.S. Department of Education.
Since there were no specific requirements for technical controls, the next step
was to define the boundaries. For ITS, an up-to-date physical and logical dia-
gram had been prepared just for this assessment.The technical lead for the assess-
ment went with the ITS senior network engineer to validate the diagram while I
worked with the ITS director and his assistant to define the logical boundaries.
The first cut by the ITS director was to include the entire Class B network.
Looking at the logical diagram for the institute, we determined that using the
entire Class B would encompass all the organizations outside ITS. When we
asked if there would be any problem with getting the medical center or colleges
to participate, it was identified that they would not. We discussed the fact that if
www.syngress.com
174 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 174

the external organizations did not participate, the assessment report would be
lacking.There would be significant holes due to the lack of data for the nine col-
leges and one medical center.The ITS director wanted to know what specifically
would be lacking. I answered that we would have no idea what their security was
and wouldn’t be able to provide any reasonable recommendation to improve
what we didn’t know exists.
The ITS director wasn’t happy with that. He wanted to be able to show how
each of the colleges, the medical center, and the dorm network were wide open,
exposing information and introducing vulnerabilities to the entire institute. We
discussed at length the resultant report and what the lack of input would result
in.The ITS director finally decided that he would have to limit the logical
boundary to that over which they had physical control. By this time, the team
technical leader had returned, and we then worked with the ITS director and the
ITS senior network engineer to define what the ITS division actually had phys-
ical control of. Based on the logical diagram, we defined three routers. Router 1
provided the connectivity for the T1 from the Internet. Router 2 provided the
connectivity for the medical center and colleges. Router 3 provided the connec-
tivity for the dorm network.Translating that information to the physical diagram
identified the IP addresses.To simplify this for the customer, we chose the address
that was external to the ITS backbone. For any technical work such as simple
scans or console reviews, this address was selected to give a true picture of what
the routers were doing.
From this point it was a simple matter to use the physical diagram to identify
the major components and operating systems. One significant observation was
that no firewall or IDS was installed anywhere. No comment was made at this
point, but we did make note of that information later in our team discussion.
www.syngress.com
The System Security Environment • Chapter 5 175
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 175
Now that we had the boundaries, we needed to know for sure what the cus-

tomer was concerned about and what limitations were in place. We already knew
that the official reason that we had been hired was to determine the actual secu-
rity posture of the ITS division and make recommendations to improve that pos-
ture. From previous discussions with the ITS director, we also knew an unofficial
reason was to show how the institute was being exposed to threats and vulnera-
bilities because there were no security controls in place. Basically, the director was
on a political hunt to prove that he should have more say in the network utiliza-
tion.This is a political battle. We didn’t want to be part of that and now knew
that we would have to work a little harder to stay neutral.
So the discussion about concerns centered on determining what areas were
of most interest to the ITS. We discussed the different classes and categories of
the IAM to see if we could persuade the ITS director to do all of them. At first
the only class that he was interested in was technical controls. We then explained
the need to do more classes due to the interdependencies and how, without the
management and operational controls in place, there could exist an ad hoc secu-
rity environment.The ITS director felt that he had good management of his
organization and still didn’t want to cover management.The last attempt to con-
vince him to include management was to point out that doing so could reaffirm
and document that management was doing a good job. If this tack did not work,
we were going to drop it. We did not want to alienate the ITS director, keeping
in mind the old axiom of “winning the battle to lose the war,” which we did not
want to do. But our final statement worked because of his political motivations,
and the ITS director agreed to cover all the classes and categories of the IAM.
www.syngress.com
176 Chapter 5 • The System Security Environment
There Could Be a Finding
Although the senior technical leader wanted to address the lack of IDS
or firewall immediately with the customer, it was decided to wait. The
team agreed that there was probably a finding based on this informa-
tion, but it was also noted that the environment was one that did not

want the information flow hindered in any way. We decided to wait to
see what information would present itself during analysis to see if there
really was a requirement for this customer to have any firewall or IDS.
Planning & Coordinating…
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 176
Now that we had the areas of concern covered, we needed to know the cus-
tomer’s constraints. We began by asking about the operational schedule and
whether there were any peak processing times that we needed to schedule
around. It was identified that the end of semester occurred in three weeks.That
would require minimal or no impact in network operations. When we asked
what was the biggest concern that the ITS director had, it was malicious code.
He wanted to know if there was any already in the network and what vulnera-
bilities existed because of it.The ITS director also emphasized that the College
of Deans would not allow anything to be installed or changed on the network
that would limit them or their students from doing Internet research.
Now we had concerns and constraints.Time to find and get the documenta-
tion and see if the customer wanted to provide a team member.At this point it
was a matter of asking what documentation existed within the institute or ITS
that provided security guidance. Of course, the first response was,“What do you
mean?” So we explained that we were first looking for any documentation that
provided the policy or philosophy of security protection.The ITS staff identified
that there was an institute document that was more a procedures document that
stated the goal “kind of ” weakly.The ITS director explained that policy docu-
ments were frowned on because they were hard to follow, with all the different
organizations. Once we had the names of the procedures documents, we anno-
tated the titles on what would be part of the assessment plan.
Second, we wanted to see if there were any guidelines or requirements that
had been documents for subjects like passwords or access rules. It was identified
that most of that subject was covered in the student handbook.That was good,
but it did not seem to be something that was used by the staff or professors. We

asked what the staff used as guidance. It was identified that staff went to two
places: the online Help menu and the new hire booklet.This brought up the
question of getting a download of the online Help menu.The ITS staff said that
would be very difficult since it was pretty large and spread out through various
servers. We annotated these for the assessment plan and noted that a team
member would have to sit down at an institute terminal and go through the
Help menu to evaluate it. Another constraint had just been identified.
Third, we wanted to know if the ITS network had a security plan.There was a
security plan, which had just been completed about three months earlier. We noted
the title and then asked about any SOPs that existed.There were only two SOPs
identified:” the Admin SOP, which covered any administrator position within the
institute, and the Human Resources SOP for any termination or new-hire proce-
www.syngress.com
The System Security Environment • Chapter 5 177
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 177
dures. When asked if there was any other user documentation other than the new
hire booklet or online Help menu, we were told there was not.
Now that the documentation was identified, we ask the ITS director and his
staff if they would like to provide a senior person to be a part of the team. We
explained that the person would be the primary point of contact between the
team and the institute for coordination, acquiring documentation, and resolving
issues and would participate in the interview process.The ITS director thought
that was a great idea and volunteered his assistant to be the team member.The
assistant thought that would be good also, since he wanted to learn more about
security and get firsthand knowledge of the security posture of the institute.
We then discussed getting the documentation in softcopy, except for the
online Help menu.The assistant said that there would be no problem and he
should have all the documents in softcopy by the end of the day. With this chore
out of the way, it is time to move on to putting together the assessment plan and
getting the customer to sign off on it.

www.syngress.com
178 Chapter 5 • The System Security Environment
286_NSA_IAM_05.qxd 12/11/03 3:28 PM Page 178