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

Adequately Identifying the Security Environment The assessment team must gain an understanding of the operational environmentand mode of operation of each system that processes, stores,

Understanding the

Cultural and Security Environment

Understanding the cultural and security environment involves more than standing the location of the room that contains the components that process,store, or transmit an organization’s critical information As the INFOSEC

under-assessor, you need to understand the operational culture and security ment that houses the critical information

environ-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 theenvironment It includes customer perceptions of their requirements and howthose 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 ments and official and unofficial policy

require-Defining the customer’s perceived environment depends on the applicablelaws, regulations, and architecture Few laws or regulations apply to all organiza-tions.You as the assessor must understand the appropriate regulations to facilitatethe definition of the security environment

The Importance of Organizational Culture

The organization’s culture is important Recommendations that you make shouldfit the organization’s operational requirements We are all aware that security is

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 thatpromotes (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

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…

Adequately Identifying

the Security Environment

The assessment team must gain an understanding of the operational environmentand mode of operation of each system that processes, stores, or transmits theorganization’s critical information.This information can be drawn from systemarchitecture and configuration documents, functional and security concept ofoperations (CONOP), and diagrams and schematics.These documents providethe written facts detailing how the organization should be operating But don’tforget the senior management interviews that you have already completed.Theyare very useful in identifying the environment.There are some unofficial ways toassist in determining the environment, such as observation During interviewsand system demonstrations you will find that users are doing things for whichthey can cite no reason All they really understand is that these “things” are arequirement

To understand how the system works, the assessment team needs to reviewavailable 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 asthe Internet CONOPS or SECONOPS are documents that are readily found inthe federal government but that rarely exist in the commercial world.They aresupposed to document how and why security controls are used From experience

we have found that usually the CONOPS are quite a bit more extensive thanjust the “how and why.” CONOPS tend to be expanded to become procedureguidelines and even SOPs

Draw information about the system from accurate system diagrams Withoutdiagrams, boundaries will never be defined Without boundaries, the assessmentwill 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.

If diagrams don’t exist, you have two options.You can have the customercreate 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 thesystem(s) of information utilization and data flow

■ Physical diagrams Depict the system(s) from the physical componentperspective of connectivity and interfaces

The logical diagrams are useful in dealing with upper management In ourexperience, 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

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…

If the organization is a federal classified system, you will also need to mine mode of operation (for example, system high, multilevel, dedicated, or thelike) Mode of operation is well defined in DoD 5200.28-STD, Department ofDefense Trusted Computer System Evaluation Criteria.The most common mode

deter-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 musthave a security clearance equal to the highest level of classification of any infor-mation that is processed, stored, or transmitted by that system.This requirementapplies to anybody, even if they do not have specific access to that classifiedinformation.There are various other levels of mode of operation; if you are notsure what the system definition means, read DoD 5200.28-STD, Department ofDefense 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 nectivity to other systems, and generally describe the system configuration inwriting.This is important for your assessment team.This information will beused later in the pre-assessment plan and in the final report Often it is also veryuseful 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 figuration in narrative form.The IAM is not an analysis of physical security;however, physical security will affect vulnerability analysis and recommendations

con-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.

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

The Never-Ending Assessment

Without well-defined boundaries, the customer will easily add 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

compo-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 nization There was no physical network diagram The organization was verbally defined as consisting of three floors, all located in one building.

orga-When the assessment team arrived on site, they discovered that the work extended out of the building The customer expected that the assessment would include their perimeter devices located across town.

net-The assessment team had no problem with including the devices net-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

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 forthe onsite or even right after the project has been scoped and bounded, mostcustomers usually want to add to the assessment.This isn’t a bad thing; it showsthat the pre-assessment was highly successful in increasing the security awarenessand security concerns of senior management Unfortunately, though, this can lead

to the team being unprepared to handle the extras that are requested.This is mally the time you’ll need to do a contract modification One way to handle thisissue before it becomes a problem is to adequately define the boundaries, bothphysical and logical Hopefully you will make the two meet to allow everybody

nor-to understand the limits of the system(s) under assessment

Physical Boundaries

Although we already discussed the physical boundaries in Chapter 4, “SystemInformation Criticality,” we review the concept here to see the effect of theboundaries on the scope of the assessment.The physical boundaries are fairly easyfor 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 assimple things such as a wall jack, router, and/or perimeter device.You alreadyidentified 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 specificcomponent and a specific address on the component.This will mean that youneed 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 isconnected to a shared router, are you going to define the assessment boundary as

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.

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.

Never the Twain Shall Meet—Or Should They?

One of the key issues to boundaries is ensuring that everybody involved stands and agrees to them As we have discussed, you can see that it would not beunusual for the customer to define two different boundaries.This will make yourassessment difficult.The issue is whether or not you do the customer any service

under-in under-includunder-ing components that they have no control over Consider the case under-inwhich 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 andlogical control of another organization.The other organization can be of equalstatus 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 byanother 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 thecustomer has a physical boundary of the firewall and a logical boundary of therouter within their own organization

The simplest method in approaching this situation is to merge the twoboundaries.This way there are no conflicts or issues with external organizations.But merging can be an issue in and of itself Political motivations are usuallyinvolved when the customer wants to include components that they have nocontrol over Being a good listener and asking open-ended questions will usuallyhelp you reveal why the customer wants to include the external organizations

We don’t recommend that you become involved in the organization’s internalpolitics 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 theirside, since they would be responsible for coordinating and providing access to theexternal organizations and components.The customer must clearly understandthat 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 agreethat security is important.Typically, this agreement tends to mean that security isimportant until it becomes an inconvenience We are aware that security affects

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 thecustomer 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

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.

Types of Resource Constraints

During interviews, observation of normal operations, and observation of systemdemonstrations, the assessment team will potentially identify numerous resourceconstraints What organization ever has enough money or people to implementsecurity to the fullest extent? We have never seen one Management may let youknow about budgetary constraints as well.This is good information that will def-initely affect the recommendations your team provides in the final report.Youdon’t want to make a recommendation for the immediate implementation of asecurity solution that the organization doesn’t have the money implement Butyou might want to make the recommendation for a long-term solution that willrequire 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 resourcesare available An example could be implementing a segmented network with fire-walls to separate business lines.The organization may not be able to implementseveral 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 toallow for the implementation

Users and administrators will tell you about the lack of staffing and quate equipment or training to do their jobs as well as they want or need to.This

inade-is also good information; just don’t take it as fact Many users and admininade-istrators

do not have the big picture of the goals and objectives for the organization Usetheir 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 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 groundsaround the facility are protected marshlands, you will probably need to look at analternative recommendation, since it might not be possible to get the appropriatepermits for a fuel storage tank installation

con-The same idea can apply to the manmade conditions Occupational Safetyand 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.Thereare 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 appliappli-cation 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 tion about OS390 can be found at www-1.ibm.com/servers/s390/os390.

informa-Determining Customer Concerns

Constraints are one thing, but what are the customer’s concerns? Often theassessment team will not be made aware of these concerns when the assessmentbegins.You, as the assessor, need to figure out the customer concerns from yourinterviews 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 thatthere are no issues to be dealt with than improving the security posture

Doing an assessment of an organization that is being acquired by anothercompany is another good example On the surface, the primary goal is to identifyand mitigate vulnerabilities that might be inherited by the parent organizationbefore allowing a direct connection to the customer organization But givenmost business models, the reality is to identify the current posture and then letthem connect Unless you find issues that are business stoppers, the connectionwill proceed

Sometimes INFOSEC assessments are conducted following a security dent to identify and resolve the issues that led to the security incident Be careful

inci-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 organizationalsecurity posture However, the customer may have in mind that you are there forspecific areas and that is all that they are concerned with In our class, we teachthe 18 topics that should be covered in every assessment.The 18 topics aregrouped into three areas; managerial, technical, and operational In some assess-ments the customer will not want to have some of these topics covered Onegood 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

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 assurancebeyond 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 inclass 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 ping those concerns to the baseline INFOSEC classes and categories that are dis-

map-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

the team Wait till you know what you are going to assess and the assessmentboundaries prior to requesting the documentation.

Documentation is nearly always an issue Does the customer have tation? Can you have or review the documentation? How do you track the doc-umentation? What happens to the documentation after the assessment? Theassessment team should obtain and review all relevant INFOSEC documents toprepare 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 easierhandling If it isn’t available in softcopy, the requested documentation can either

documen-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 youronsite 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 theIAM We understand that many technicians do not like to do documentationreview, but it is an important step Each member of the team has a differentbackground.This allows each to identify certain things in the documentation thatthey feel could be an issue or a finding during the onsite Just keep in mind thatthey are not findings at this point because they are not proved.The onsite iswhere potential findings will be proved or disproved

Tracking the documentation is an issue of document management.The exactmeans for tracking documentation is a business process, but the fundamental

requirements are the same in any business process In this process we use the ment plan as the tracking device Figure 5.1 shows the basic layout that we use totrack what was requested, when it was delivered, who has the document, and whatwas done at the end to return it or destroy it.The key issue here is to ensure thatall documents are accounted for In most cases, we usually give a copy of this layout

assess-to the cusassess-tomer-appointed primary point of contact (PPOC) (The assessment plan

is described and discussed in Chapter 6 It is sufficient to say here that the ment plan is a living document that we will use throughout the assessment.)

assess-Figure 5.1 Basic Layout of a Document Tracking Device

Title Date

Requested ReceivedDate Custodian

Date Destroyed or Returned

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:

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

to a specific system.There should only be one plan for a given system Plans are anormal 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 ties in sufficient detail that a competent operator can accomplish the work SOPsare normally required for systems administration activities such as audit reviewsand account management SOPs should also cover any privileged user activitythat is beyond normal user activity.Think of SOPs as mitigation for the Mactruck theory.You only have one person who does a specific task or activity, such

activi-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 thesystem and information security aspects of each job.There should be guidanceand procedures for the user on specific subjects such as password generation andprotection, defining session controls such as unattended terminals, and any othertopic that is relevant for users to do their jobs securely

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, youwill 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

Determining Documentation Location

Now that you know what documentation to look for, where do you find it andhow 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 notprovide softcopies of things such as proprietary documents or other documentsthat are considered sensitive Sensitive documentation can also include classifieddocumentation Sensitive documents are usually only in hardcopy form to allowfor individual accountability of custody If the documents are considered verysensitive, 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 areavailable only in hardcopy but not sensitive, you should still track the custody ofthe documents through the assessment plan

What If No Documentation Exists?

Now that you know what kind of documentation to look for and how to getthat documentation, let’s look at the types of documentation that do exist Bythis we mean the validity of the documentation We have found that documentsfall 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 categorieseach document belongs

Valid documentation is current and has been reviewed for applicability

within the last year It probably has some tracking mechanism such as versioncontrol built into it If you are dealing with a large corporation or a governmentagency, 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 becausethe system is operating differently than the documentation identified One goodclue during the pre-assessment is the identification of components or personnelthat the customer has already identified as no longer in use Again, verify thisinformation when you get your team on site

Draft documentation is not a bad thing We work with organizations thathave 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 securitywithin 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

Case Study: Higher Education

We had just completed the Organizational and System Information CriticalityMatrices for the Information Services Technology (ITS) division of this highereducation institute Now it’s time to define the goals, objectives, and boundariesand obtain the documentation

The first part of this process seemed easy.The culture was a little differentthan we had expected, however ITS had this mentality: How do we control theusers without them knowing it? For this higher education institute, the board ofgovernors 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, butthey had no say as to the operations of the dorm network or the colleges.Thismade their life, from their perspective, very difficult Although the only regula-tory input that ITS followed was for compliance with the Family EducationalRights and Privacy Act (FERPA), they were very worried about how to controlthe 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 stepwas 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 Iworked 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 theentire Class B would encompass all the organizations outside ITS When weasked 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

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 howeach 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 logphys-ical 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 identifythe 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

Now that we had the boundaries, we needed to know for sure what the tomer was concerned about and what limitations were in place We already knewthat 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 unofficialreason 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

cus-on a political hunt to prove that he should have more say in the network tion.This is a political battle We didn’t want to be part of that and now knewthat we would have to work a little harder to stay neutral

utiliza-So the discussion about concerns centered on determining what areas were

of most interest to the ITS We discussed the different classes and categories ofthe IAM to see if we could persuade the ITS director to do all of them At firstthe only class that he was interested in was technical controls We then explainedthe need to do more classes due to the interdependencies and how, without themanagement and operational controls in place, there could exist an ad hoc secu-rity environment.The ITS director felt that he had good management of hisorganization 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 reaffirmand 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 notwant 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

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…