Level I Assessments

The heart of a level I assessment includes the policy review, interviews, and system demonstrations. The policy review should have been started during the scoping phase as that was the time at which you should have requested all of the various policies that control the security mechanisms developed by the organization. Before we move on to discussing interviews and system demonstrations we should first turn our attention to what reviewing the documentation should entail.

Reviewing the Documentation

As discussed at various points throughout this book, policies are of vital importance to an organization. It's important that the organization's existing policies be reviewed. This is one of the most important activities of a level I assessment. First, we will look at how NIST and the IAM break up the categories and classes of information. We will then take a look at some of the other standards that can be useful during an assessment.

NIST 800-26 Security Self-Assessment Guide for Information Technology Systems divides policies into three categories:

• Management
• Technical
• Operational

Within these three categories are a total of 17 classes. This is close to the NSA IAM, except that the IAM has 18; so it's a little more granular. By adding an additional category the IAM has provided use with a more specific list to work from. This list of the categories and classes was shown in Table 7.1.

Management

NIST 800-26 defines management controls as "controls that focus on the management of the IT security system and the management of risk for a system. They are techniques and concerns that are normally addressed by management."

INFOSEC Documentation

For security to be effective, it must start at the top of an organization. Decisions have to be made on what should be protected, how it should be protected, and to what extent it should be protected. These decisions should be crafted into written documents. These INFOSEC documents should clearly state what is expected from each employee and what the result of noncompliance will be. These documents can be divided into the following hierarchical levels and types:

• Policies Policies are the top tier of formalized security documents. These high-level documents offer a general statement about the organization's assets and what level of protection they should have. Well-written policies should spell out who is responsible for security, what needs to be protected, and what is an acceptable level of risk. They are much like a strategic plan in that they outline what should be done but don't specifically dictate how to accomplish the stated goals. Those decisions are left for guidelines and procedures. Security policies can be written to meet advisory, informative, and regulatory needs. Each has a unique role or function.
• Guidelines A guideline points to a statement in a policy or procedure by which to determine a course of action. It's a recommendation or suggestion of how things should be done. It is meant to be flexible so it can be customized for individual situations. Sometimes guidelines are referred to as best practices.
• Procedures This is the most specific of security documents. A procedure is a detailed, in-depth, step-by-step document that lays out exactly what is to be done. Because procedures are detailed documents, they are tied to specific technologies and devices. You should expect to see procedures change as equipment changes. For example, suppose your company has replaced its Cisco PIX with a Checkpoint firewall. Although the policies and standards dictating the firewall's role in your organization probably would not change, the procedure for configuration of the firewall would.

INFOSEC Roles and Responsibilities

It important to provide a clear division of roles and responsibilities. This will be a tremendous help when dealing with any security issues. Everyone should be subject to this policy, including employees, consultants, and vendors. Common roles include the data owner, data custodian, user, and security auditor.

• Data owner Usually a member of senior management, such as chief executive officer, chief information officer, chief security officer, or information owners. After all, senior management is responsible for the asset and if it is compromised, can be held responsible. The data owner can delegate some day-to-day duties, but cannot delegate total responsibility. Senior management is ultimately responsible. They are responsible for leading the security effort and for providing support and guidance to other levels to ensure that policies can be implemented.
• Data custodian This is usually someone in the IT department, such as systems administrators, security administrators, network security administrators, and the like. Although the data custodian does not decide what controls are needed, he does implement controls on behalf of the data owner. Other responsibilities include the day-to-day management of the asset, controlling access, adding and removing privileges for individual users, and ensuring that the proper controls have been implemented.
• User This is a role that most of us are familiar with because this is the end user in an organization. Users do have responsibilities; they must comply with the requirements laid out in policies and procedures. They must also practice due care.
• Security auditor This is the person who examines an organization's security procedures and mechanisms. How often this process is performed depends on the industry and its related regulations. For example, the health-care industry is governed by the Health Insurance Portability and Accountability Act (HIPAA) regulations, which state that audits must be performed yearly. Regardless of the industry, the audit process should be documented and approved by senior management.

Contingency Planning

Contingency planning is about preparing to deal with disasters before they occur. The two types of contingency planning include business continuity planning (BCP) and disaster recovery management (DRM). Business continuity planning is about planning ways to keep key organizational units operational while minimizing the impact of natural or manmade disruptions. The impact a disruption has on a business is usually measured in downtime. Critical systems are those that the organization cannot survive without for more than a short period of time. Downtime examples are shown in Table 7.2.

Table 7.2. Maximum Tolerable Downtime

Item	Required Recovery Time
Critical	Minutes to a few hours
Urgent	1 day
Important	3 days
Normal	1 week
Nonessential	One month

Disaster recovery management is focused on the steps that must be taken to restore business operations if a disaster occurs. Contingency planning documentation should include the following information:

• Identifies who is responsible for executing BCP or DRM plans.
• Identifies critical functions and priorities for restoration.
• Specifies the location of recovery facilities.
• Notes who will manage the restoration and testing process.
• Details how the organization will interface with external groups, such as customers, shareholders, the media, the community, and regional, provincial, and state emergency services groups.
• Communicates how the plan has been tested. Common methods include the following: checklist, table-top, walk through, functional, or full interruption.

Configuration Management

Configuration management is the process of controlling and documenting any changes made to networks, systems, or software. In 1962, the American Air Force responded to the control and communication problems in the design of its jet aircraft by authoring and publishing a standard for configuration management, AFSCM 375-1. This was the first standard on configuration management. Configuration management should be a documented, formalized process having the purpose to control modifications. Although it can be implemented many ways, it's generally a six-step process:

1.	Define change management process and practices.
2.	Receive change requests.
3.	Plan and document the implementation of changes.
4.	Implement and monitor the changes. Develop a means of backing out of proposed changes if necessary.
5.	Evaluate and report on implemented changes.
6.	Modify change management plan if necessary.

Many organizations have a change control board set up to handle this activity. A good reference document is NIST 800-14, "Generally Accepted Principles and Practices for Securing Information Technology Systems." You can find this document at http://csrc.nist.gov/publications/nistpubs. Configuration management is a big concern when moving from one version of software to another or moving from beta development to the final release of a product.

Beta Development

The term beta testing is thought to have originated at IBM during the 1960s. Alpha tests are the first round of tests performed by the programmers and quality engineers to look at how applications will function. Beta testing comes next. Beta testing is widely used throughout the software industry. This second round of product development has evolved to include testing that is performed internally and externally by prospective users.

Although the software is potentially unstable, it is much more user friendly than in its alpha stage and gives the programmers, quality engineers, and users a good look at how the end product will act and perform. After collecting feedback from these initial users, the application is typically run through another round of improvements before it is released in its final form.

 

Technical Controls

What are technical controls and how are they categorized as policy? NIST 800-26 defines technical controls as "controls that focus on security controls that the computer system executes. The controls can provide automated protection for unauthorized access or misuse, facilitate detection of security violations, and support security requirements for applications and data." There are nine primary technical controls discussed in the following sections.

Identification and Authentication

Identification and authentication are two big security controls. Identification is the process of identifying users. Authentication is the process verifying their identification. Together these two mechanisms are what are primarily used to control physical and logical access to an organization's assets. The following list describes three ways in which users are authenticated:

Something you know Passwords, pin numbers, secret handshakes, the combination to a door lock.

Something you have This could be your bank ATM card, your set of keys, or a token.

Something you are Usually a personal characteristic such as a fingerprint, voice pattern, retina scan, and so on.

Passwords are the most widely used form of authentication. If passwords are used, password policy should dictate the complexity and frequency in which passwords should be changed. The frequency with which passwords should be changed will depend on the sensitivity of the data. Password change times must be balanced because periodically changing passwords will reduce the damage done by stolen passwords, but too frequent changes will sometimes frustrate the users and can lead to security breaches such as users writing down passwords or using obvious ones in an attempt to keep track.

Account Management

Some surveys have found that as many as 60% of the access accounts in some organizations are no longer valid. If you find this to be true, you need to look closely at policy. Either the policy is not effective or it is not being followed. Account management is the process of handling access to the organization's logical assets. Account management policies should address the following:

• Account initialization
• Account change control
• Privilege access control
• Account termination
• Account lockout
• Password change policies

Account management systems must also address the following issues, which are closely related to session controls:

• Password request Allow users to register for access.
• Password synchronization Policies specifying how passwords are synchronized between multiple systems.
• Lost passwords Policies that specify how users who have forgotten passwords authenticate with some other means and reset them.
• Help desk Allow IT support staff to authenticate callers for password management.

Session Controls

Session controls are automatic features used to limit the amount of time a user's logon is held open; they are used to discourage attackers and misuse. Session controls can be used to prevent someone from attempting to log in at 3 a.m. and can set a limit on the number of attempted logins.

• Account lockouts Limits the number of failed attempts a user can make before an account is temporarily or permanently disabled.
• Screensaver locks Useful when people get up or move away from their terminal without logging out. Can be preconfigured to activate after a predetermined period of time.
• System timeouts An automated control that logs out individuals automatically after a preconfigured period of inactivity. Useful for people who forget to log out at lunch or before going home.
• Warning banners Used for legal notification. They identify acceptable and unacceptable use. Warning banners are useful in establishing legal precedence and informing would-be intruders or attempted security policy violators that their intended activities are restricted and additional activities will be audited and monitored. According to CERT.org, "failure to include a logon banner regarding acceptable use of a computer system can make it difficult to prosecute violations when they occur. Indeed, legal cases exist in which defendants have been acquitted of charges for tampering with computer systems because no explicit notice was given prohibiting unauthorized use of the computer systems involved." A real-life example of a warning banner can be seen in Figure 7.2.

  Figure 7.2. Warning banner.

  

Auditing

Auditing is the measurement of how well the other controls we are discussing actually work. Auditing is by nature a detective control. It's usually not looked at closely until something goes wrong. Many audit trails have alarm thresholds called clipping levels. A clipping level is the point at which an alarm threshold or trigger occurs. For example, setting an account lockout after three failed login attempts is an established clipping level. You can mistype your password once or twice, but on the third try, a mistyped attempt will trigger an alert and lock out your account. Well-written audit policies will specify the following details:

• Log review policy Detailed information about how the audit logs are reviewed.
• Process automation Transmit audit logs to a remote system and utilize tools that parse the data, which will free the operator from having to review hundreds of entries manually. By doing so, it will encourage administrators to use the logs in a preventive function rather than in a detective one, and they will be more likely to follow policy.
• Centralize logging Again, this eases and simplifies the burdens of the administrators by having all the information in one location.
• Exporting audit logs This makes it more difficult for individuals to tamper with the logs or cover their activities.
• Maintain manageable audit log size Limit auditing to useful information. Almost always, the tendency is to either not log anything or to log everything.

Malicious Code Protection

Hopefully, this will be one area of policy that has been responsibly addressed. Malicious code includes all types of malware, including viruses, worms, spyware, and Trojans. Protection mechanisms need to be in place for workstations and servers. Not only are software mechanisms important, but user training as well, because many types of viruses, phishing schemes, and other forms of malicious code initially function by tricking the end user into some type of interaction or response. All malware threatens either availability, integrity, or confidentiality.

Maintenance

Maintenance is another important security concern. Many times, you'll find inadequate policies for verifying maintenance personnel before allowing them into sensitive areas. Stories abound on the Internet about fake maintenance workers stealing company equipment.

System Assurance

System assurance addresses the need to validate systems and equipment. This formal process is used to validate the system. The two terms you'll hear most commonly used during this process are certification and accreditation. Certification is the process of validating that the systems that are implemented are configured and operating as expected. It also validates that the systems are connected to and communicate with other systems in a secure and controlled manner and that they handle data in a secure and approved manner. The certification process is a technical evaluation of the system that can be carried out by independent security teams or by the existing staff.

On completion of the certification process, the results are reported to the organization's management for mediation and approval. If management agrees with the findings of the certification, the report is formally approved. The formal approval of the certification is the accreditation process. This is typically accomplished by issuing a formal, written approval that the certified system is approved for use and specified in the certification documentation. If changes are made to the system, it is reconfigured; if there are other changes in the environment, a recertification and accreditation process must be repeated. Some examples of documents designed for system assurance follow:

• The Rainbow Series An aptly named series of books because each book in the series has a different colored label. This six-foot-tall stack of books was developed by the National Computer Security Center (NCSC). These guidelines were developed for the Trusted Product Evaluation Program (TPEP), which tests commercial products against a comprehensive set of security-related criteria.
• ITSEC A European standard that was developed in the 1980s to evaluate confidentiality, integrity, and availability of an entire system. ITSEC designates the target system as the Target of Evaluation (TOE). The evaluation is divided into two parts: One part evaluates functionality and the other evaluates assurance.
• Common Criteria (ISO 15408) An amalgamated version of TCSEC, ITSEC, and the CTCPEC. Common Criteria is designed around TCB entities. These entities include physical and logical controls, startup and recovery, reference mediation, and privileged states.
• ISO 17799 A comprehensive standard in its coverage of security issues that is divided into 10 sections, including security policy, security organization, asset control and classification, environmental and physical security, employee security, computer and network management, access controls, system development and maintenance, business continuity planning, and compliance.

Networking Connectivity

Policies addressing network connectivity must address all the ways in which users can connect to the network:

• Wireless
• LAN
• WAN
• VPN
• Internet
• Modem
• Third-party connectivity

Note

Protection mechanisms that can be used include ACLs, firewalls, mandatory access control techniques, VLANs, and by implementing "deny all" policies.

 

Communication Security

Communication security addresses the need to protect data while it is in transit. Before you think strictly about data communication, voice and fax communications should also be examined. Encryption is the most direct way to provide additional protection. IPSec, PGP, WPA, and VPNs are a few examples of how this can be accomplished.

Operational Control

NIST 800-26 defines operational controls as follows: "controls address security methods focusing on mechanisms primarily implemented and executed by people (as opposed to systems). These controls are put in place to improve the security of a particular system (or group of systems). They often require technical or specialized expertise and often rely upon management activities as well as technical controls." As you can see, operational controls deal with items such as media controls, document labeling, training, personal security, and physical security. This is of vital importance when you think of the number of people who carry cell phones with built in cameras, which could be used to move confidential information discreetly out of an organization. Other items such as USB thumb drives can hold 1 to 2 gigabytes of data or more and fit easily in a pocket or purse.

Media Controls

Media controls examine the ways in which paper documents, floppy disks, CDs, DVDs, hard drives, USB drivers, and other forms of media are handled throughout their life cycle. Sensitive media must be handled and destroyed in an approved manner.

Sensitive media should be handled with the same care that sensitive documents receive.

Caution

Anyone looking for a good example of how not to handle sensitive media needs to look no further than the June 2000 incident at Los Alamos in which hard drives containing nuclear secrets were discovered missing. Later, they were discovered behind a copier, but no one knew how they got there.

Media can be disposed of in many acceptable ways. Paper documents can be shredded, CDs can be destroyed, and magnetic media can be degaussed. Hard drives can be wiped. Wiping is the process of overwriting all addressable locations on the disk. The DOD (Department of Defense) drive wiping standard #5220-22M states: "all addressable locations must be overwritten with a character, its complement, then a random character and verify." By making several passes over the media, an organization can further decrease the possibility of data recovery. For organizations worried about proper disposal of used media, this provides clean, unrecoverable media.

Labeling

As discussed in Chapter 2, "Foundations and Principles of Security," labeling addresses the need to have a formal document classification system. The two most widely used are government classification and commercial.

Physical Environment

Physical security is another import control that should be documented in policy. Logical security does little good if someone can just walk in and remove a server's hard drive and leave. Physical security includes items such as

• Locks
• Guards
• CCTV
• Fences

Personal Security

Personal security addresses the administrative process of ensuring that personnel are not a risk to an organization. For governmental positions, this is usually accomplished by requiring a security clearance. A security clearance is a determination that an individual is able and willing to safeguard classified national security information. Typically, the first step in obtaining U.S. government security clearance is to complete a Standard Form 86, Questionnaire for National Security Positions. In private industry, personal security is usually accomplished by the following:

• Hiring practices Employees should have their personal backgrounds thoroughly checked. Organizations should comply with all federal, state, provincial, and local laws in regard to personal information.
• Preemployment Reference check, criminal check, educational history, and background investigation.
• Nondisclosure Agreements (NDAs) These should be provided to new employees and reviewed during the exit interview. The purpose of a nondisclosure agreement is to provide a limited amount of protection against nondisclosure, proprietary information to your competitors. This does not guarantee that an employee will not reveal proprietary information; however, it does assure you the right to sue and seek monetary damages.
• Termination Exit interview, reminder of NDA, account lockout, and password change.

Education Training and Awareness

Employees need to be trained in proper security. Awareness programs are effective in increasing employee understanding of security. Security awareness training policies should take into account the different groups that make up an organization. Training will be focused differently for each group. Not only will the training vary, but the topics and types of questions you'll receive from the participants will also vary. Well-written security awareness programs tailor the message to fit the audience. Following are three of the primary groups that security awareness training should be targeted to:

• Data owners Senior management is not going to want to hear an in-depth technical analysis from this group. Because they are mainly concerned with costs, benefits, and ramifications of good security practices, they should also be informed about how they can support the organization and promote good security practices.
• Data custodians This group of midmanagement requires a more structured presentation on how good security practices should be implemented, who is responsible, and what the individual and departmental costs are for noncompliance.
• Users End-user training should align with an employee's daily tasks and map to the user's specific job functions.

Besides security awareness training, you will also want to see what policies are in place to make sure employees are properly trained on specific security tasks. That new Checkpoint firewall is of little use to the organization if no one has been properly trained as to how to set it up and configure it. This might consist of in-house training programs that teach new employees needed security skills or the decision to send the security staff offsite for a more in-depth educational program. The most common types of training programs are

• Degreed programs
• Continuing education programs
• In-house training
• Web-based training
• Classroom training
• Vendor training
• On-the-job training

Common Policy Problems

While reviewing documentation, you need to be on the lookout for things such as missing policies, outdated policies, or poorly written ones. You may find a policy that goes into detail about how employees are not allowed to connect to unauthorized modems, but find nothing that mentions wireless devices.

Regardless of what you find, you're going to want to record the results and make some recommendations on how any problems can be fixed. Policy problems are usually indicative of underlying problems. You need to make sure that the organization has the necessary items in place to support your recommendations. A well-designed documentation system should have the following components:

• Policy development The development of good policy should take into consideration the organizational needs, requirements, and environment. Senior management must set the tone of what's required and work to motivate and educate the employees as to why these policies are required and their end result.
• Change management Change happens, and when it does, how will the organization deal with it? Maybe a major flaw in the security policy exposed a vulnerability that a hacker was able to exploit. How will this be dealt with? Controls should be in place to indicate how policy changes can be approved, how they are documented, and who is allowed to make changes.
• Acceptance All policies must have acceptance. If policies are routinely bypassed or ignored, they will be deemed ineffective; therefore, employee buy-in is important.
• Testing An important part of any policy is testing. There is no way to gauge effectiveness without testing policies to see if they are effective. For example, you may have a procedure that dictates what can and cannot pass through the firewall. A series of penetration tests would help confirm that the procedure works and allows only acceptable traffic.
• Implementing Policies must have a scheduled implementation. Once I heard, "Yeah, we have a strong password policy but it wasn't implemented because of hardware/software issues."
• Reviewing Have you ever gone to your boss's office and asked about a questionable policy only to have a dusty book pulled from the shelf in an attempt to research the answer? Static policies are bad policies! Policies are living documents. Times change, technologies change, laws change, and so should policies. They should change with the times and adapt to meet the organization's needs. Assessments and audits are useful at analyzing policies as well as the effectiveness of the policies.

Tip

If you end up being responsible for the development of policies, remember that their real purpose is to clear up confusion, not generate new problems. When creating policy, write the document for the specific audience to which it is targeted. It's not likely that you will be able to sit down with each reader and explain what each item means or how it benefits the organization. Individuals who have become proficient at writing policy usually remember the "Five Ws of Journalism 101":

• WhatWhat is to be protected (the topic)?
• WhoWho is responsible (responsibilities)?
• WhereWhere within the organization does the policy reach (scope)?
• HowHow will compliance be monitored (compliance)?
• WhenWhen does the policy take effect (timing)?
• WhyWhy was the policy developed (reason)?

Assessing the organization's documentation requires not only reading it, but also asking employees what it means to them. During the upcoming interview process, ask the interviewees how they interpret the policy.

Additional Organizational Guidelines and Controls

Depending on the nature and scope of the security assessment, different standards might be appropriate. Some of the most well known are described next.

ISO 17799

ISO 17799 is a good benchmark to reference during a vulnerability assessment because it represents industry-recognized best practices.

• Security Policy Discusses what policies should look like as well as how the policies should be reviewed.
• Organizational Security Addresses roles and responsibilities for all aspects of information security.
• Asset Classification and Control Deals with the ownership of assets and asset classification.
• Personnel Security Maps closely to NIST and IAM as it discusses all aspects of someone's employment with the organization.
• Physical and Environmental Security Specifies physical and environmental security controls that should be taken to prevent unauthorized physical access or damage to facilities.
• Communications and Operations Management These controls address secure communications and items such as change management and media handling.
• Access Control These controls are focused on the principle of least privilege.
• Systems Development and Maintenance Requirements in this section are to ensure that security is built in to information systems.
• Business Continuity Management Controls in this section deal with business continuity.
• Compliance This section defines certain legal and operational compliance. This includes regulatory, legislative, and contractual security-related requirements that are applicable to the organization.

RFC 2196

RFC 2196 is another good standard to reference during the vulnerability assessment. The basic approach it outlines is shown next:

1. Identify what you are trying to protect.
2. Determine what you are trying to protect it from.
3. Determine how likely threats are.
4. Implement control measures that will protect your assets in a manner that is cost effective.
5. Periodically review the process and make improvements each time a weakness is found.

Control Objectives for Information and Technology (COBIT)

Control Objectives for Information and Technology (COBIT) consists of 34 high-level IT control practices. Corresponding to each is an Audit Guideline to enable the review of IT processes against COBIT'S 318 recommended, detailed control objectives to provide management assurance and advice for improvement. COBIT helps its users develop good control policies and good practices for IT control. COBIT is a tool that allows users to bridge the gap between control requirements, technical issues, and business risks and communicate that level of control to stakeholders.

Interviewing Process Owners and Employees

At this step in the assessment, you'll want to get an idea about how day-to-day processes are carried out. You have data that was provided from the initial information request, and you have done a review of the organization's documentation. Armed with this data, you will want to learn more about how operations are actually carried out. The interview process will provide that information.

Interviews should be handled by individuals who have good people skills. You need people who can interact well with others and know when to probe for more in-depth answers. You don't want this to come off like a poorly written episode of Dragnet. Your goal here is to see how well policy actually matches up to reality. For example, you may find that a certain security policy states that the IT manager must personally clear all individuals who enter the server room. Because this is somewhat of an inconvenience, you may find that the IT manager just leaves the access key for the second- and third-shift managers in case they need access. Interviews help identify where policy and practice deviate. The other purpose of the interview is to hear from other employees how they feel about the security of the organization. Employees truly are an organization's greatest asset and will bring many good ideas to the table if asked. Interviews are the place to solicit this information.

Interview Candidates

You will want to interview a cross section of employees from your organization. The idea is to get a feel for what the individuals at the top all the way down to the end user feel about security. What are their attitudes and perceptions? Table 7.3 shows some potential interview candidates. This should give you some idea of the range of employees you'll want to talk to.

Table 7.3. Potential Interview Candidates

Data Owners	Data Custodians	End Users
Chief security officer	Network manager	Users
Chief executive officer	Security administrator	Privileged users
Chief technology officer	Department heads	Database admin
Executive staff	Facilities manager	Janitorial staff

 

Interview Techniques and Schedule

Unfortunately, Security Assessment Interviewing 101 is not a course offered in most colleges. As mentioned previously, you're going to need to use care in choosing the interviewer. The individual who conducts the interview needs to have good interpersonal skills. Individuals don't like feeling that they are being interrogated. Also, that is not the purpose of the interview. The goal here is to have a dialog with the employees as to what their thoughts and concerns are and how they carry out day-to-day activities. Three items must be considered when planning and performing the interviews:

During the interview, you want to make the person being interviewed is as comfortable as possible. Position yourself where there is no table or obstruction between you and the interviewee, move from behind your desk, and take a chair next to the candidate. Interviews should be held in a private location. You will want to keep supervisors and others out of the room at the time of the interview. The objective is to have an open, honest dialog. Schedule individuals from the same groups at different times to try and keep the atmosphere from becoming stilted, self-serving, and defensive. The presence of a microphone inhibits some employees, so it's best not to record interviews. Have a second person in the room take notes. It's important to remind the interviewee that this is not an audit, and nonattribution is the policy.

Nonattribution means that whatever is said in the interview will not be attributed to a specific person outside of the meeting. You will not report the results of the interview in such a way that would identify or expose the participant's identity. This is an issue because some participants will be concerned about what they say or how their participation in the assessment interview process may be viewed by colleagues and department heads. If individuals lie or attempt to misrepresent the truth during an interview, you can usually tell by their body language, tone of voice, or the words they use. Classic body language giveaways include individuals scratching their nose and not looking directly at the interviewer when they are speaking. Guaranteeing confidentiality is an important part of establishing trust and helps to remove the feeling that the interviewee should hide the facts from you. You're not doing this to find a guilty party or accuse someone of doing anything wrong; the purpose here is to learn what's right and wrong with the organization's security posture.

Tip

Another important consideration is the interview schedule. You will want to allow adequate time for each person you are going to talk to. You will also want to leave some time between interviews to gather your notes, record any findings, and keep the interviewees from stacking up in a queue while waiting for you. A general rule is to allow the following:

• Thirty minutes or so for each end user
• One hour for data custodians and data owners
• One and a half hours for technical interviews

 

Interview Topics

Topics discussed during the interview will vary based on which group of individuals you are interviewing. NIST 800-26 has a good list of potential questions tied to the specific categories, but there will also be some general questions you will want to ask most interview candidates. These may include

• Who is the employee and what is his or her relationship to the organization?
• How long has the employee worked for the organization?
• What data can the employee access, how is this accomplished, and what applications are made available to the employee?
• What does the employee perceive to be critical or sensitive data and resources?
• What knowledge does the employee have of where security policy and security practice deviate?
• What changes would the employee recommend to improve corporate security practices?
• What security vulnerabilities does the employee believe the organization is not addressing?

System Demonstrations

When you have an in-depth knowledge of the organization's policies and have completed a thorough set of interviews, it will be time to observe some system demonstrations. The purpose of system demonstrations is to clarify any disagreements between stated policy and interviews. For example, during an interview, you may have been told that there is no lockout policy in place. That is, users can enter one, two, three, four, or more incorrect passwords and still not have their account locked out or disabled. Because you know that policy dictates a lockout after three tries, a simple system demonstration can prove or disprove this problem. If a system demonstration shows that a lockout policy has not been implemented, you can then get more information from the individuals in charge and try to find out why. Is it a technical limitation, a failure to adhere to policy, or what?

Another example could be that the cleaning crew stated that they have seen restricted documents thrown in the trash and not disposed of by shredding as policy dictates. This can be verified by taking a walk around some of the work areas late at night or doing a little dumpster diving.

The importance of demonstrations is that they are used to prove facts that have thus far been uncovered and that when possible, you are having the employee perform the action or procedure stated in the policy. Remember, your goal is to determine where policy and actual practice deviate.

Although system demonstrations go a long way in demonstrating that policy and action agree, they are not perfect, nor can they solve or answer all problems. Suppose that you review the ACL policy and even observe the organization's firewall administrator enter it in. Does this demonstrate that the ACL works as policy dictates? Maybe, maybe not. Items of this nature are best verified by performing a level II assessment.