 Information Resource Guide |
| Information Resource Guide |
2.1.0 What is a Security Policy and Why Have One?
The security-related decisions you make, or fail to make, as administrator largely determines how secure or insecure your network is, how much functionality your network offers, and how easy your network is to use. However, you cannot make good decisions about security without first determining what your security goals are. Until you determine what your security goals are, you cannot make effective use of any collection of security tools because you simply will not know what to check for and what restrictions to impose. For example, your goals will probably be very different from the goals of a product vendor. Vendors are trying to make configuration and operation of their products as simple as possible, which implies that the default configurations will often be as open (i.e., insecure) as possible. While this does make it easier to install new products, it also leaves access to those systems, and other systems through them, open to any user who wanders by.
Your goals will be largely determined by the following key tradeoffs:
Each service offered to users carries its own security risks.
For some services the risk outweighs the benefit of the service
and the administrator may choose to eliminate the service rather
than try to secure it.
The easiest system to use would allow access to any user and
require no passwords; that is, there would be no security.
Requiring passwords makes the system a little less convenient,
but more secure. Requiring device-generated one-time passwords
makes the system even more difficult to use, but much more
secure.
cost of purchasing security hardware and software like firewalls
and one-time password generators), performance (i.e., encryption
and decryption take time), and ease of use (as mentioned above).
There are also many levels of risk: loss of privacy (i.e., the
reading of information by unauthorized individuals), loss of
data (i.e., the corruption or erasure of information), and the
loss of service (e.g., the filling of data storage space, usage
of computational resources, and denial of network access). Each
type of cost must be weighed against each type of loss.
2.1.1 Definition of a Security Policy
A security policy is a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide.
2.1.2 Purposes of a Security Policy
The main purpose of a security policy is to inform users, staff and managers of their obligatory requirements for protecting technology and information assets. The policy should specify the mechanisms through which these requirements can be met. Another purpose is to provide a baseline from which to acquire, configure and audit computer systems and networks for compliance with the policy. Therefore, an attempt to use a set of security tools in the absence of at least an implied security policy is meaningless.
Another major use of an AUP is to spell out, exactly, the corporate position on privacy issues and intellectual property issues. In some countries, if the company does not explicitly state that e-mail is not secure, it is considered to be so and any breach could cause privacy and confidentiality liabilities. It is very important to spell out what is and is not acceptable in intellectual transfers and storage and what the corporate privacy policies are to prevent litigation about same.
An Appropriate Use Policy (AUP) may also be part of a security policy. It should spell out what users shall and shall not do on the various components of the system, including the type of traffic allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding. For example, an AUP might list any prohibited USENET newsgroups. (Note: Appropriate Use Policy is referred to as Acceptable Use Policy by some sites.)
2.1.3 Who Should be Involved When Forming Policy?
In order for a security policy to be appropriate and effective, it needs to have the acceptance and support of all levels of employees within the organization. It is especially important that corporate management fully support the security policy process otherwise there is little chance that they will have the intended impact. The following is a list of individuals who should be involved in the creation and review of security policy documents:
university, etc.)
is also relevant to mention that the role of legal counsel will also vary from country to country.
2.1.4 What Makes a Good Security Policy?
The characteristics of a good security policy are:
procedures, publishing of acceptable use guidelines, or other
appropriate methods.
and with sanctions, where actual prevention is not technically
feasible.
required, or preferred, security features. These should
supplement existing purchasing policies and guidelines.
privacy regarding such issues as monitoring of electronic mail,
logging of keystrokes, and access to users' files.
protect assets from loss or disclosure by specifying acceptable
use guidelines for users, operations staff, and management. It
should provide guidelines for external connections, data
communications, connecting devices to a network, and adding new
software to systems. It should also specify any required
notification messages (e.g., connect messages should provide
warnings about authorized usage and line monitoring, and not
simply say "Welcome").
users, operations staff, and management. It should specify an
audit capability, and provide incident handling guidelines
(i.e., what to do and who to contact if a possible intrusion is
detected).
effective password policy, and by setting guidelines for remote
location authentication and the use of authentication devices
(e.g., one-time passwords and the devices that generate them).
availability of resources. It should address redundancy and
recovery issues, as well as specify operating hours and
maintenance downtime periods. It should also include contact
information for reporting system and network failures.
which describes how both internal and external maintenance
people are allowed to handle and access technology. One
important topic to be addressed here is whether remote
maintenance is allowed and how such access is controlled.
Another area for consideration here is outsourcing and how it is
managed.
violations (e.g., privacy and security, internal and external)
must be reported and to whom the reports are made. A non-
threatening atmosphere and the possibility of anonymous
reporting will result in a greater probability that a violation
will be reported if it is detected.
violation; guidelines on how to handle outside queries about a
security incident, or information which may be considered
confidential or proprietary; and cross-references to security
procedures and related information, such as company policies and
governmental laws and regulations.
Once your security policy has been established it should be clearly communicated to users, staff, and management. Having all personnel sign a statement indicating that they have read, understood, and agreed to abide by the policy is an important part of the process. Finally, your policy should be reviewed on a regular basis to see if it is successfully supporting your security needs.
2.1.5 Keeping the Policy Flexible
In order for a security policy to be viable for the long term, it requires a lot of flexibility based upon an architectural security concept. A security policy should be (largely) independent from specific hardware and software situations (as specific systems tend to be replaced or moved overnight). The mechanisms for updating the policy should be clearly spelled out. This includes the process, the people involved, and the people who must sign-off on the changes. It is also important to recognize that there are exceptions to every rule. Whenever possible, the policy should spell out what exceptions to the general policy exist. For example, under what conditions is a system administrator allowed to go through a user's files. Also, there may be some cases when multiple users will have access to the same userid. For example, on systems with a "root" user, multiple system administrators may know the password and use the root account.
A threat can be any person, object, or event that, if realized, could potentially cause damage to the LAN. Threats can be malicious, such as the intentional modification of sensitive information, or can be accidental, such as an error in a calculation, or the accidental deletion of a file. Threats can also be acts of nature, i.e. flooding, wind, lightning, etc. The immediate damage caused by a threat is referred to as an impact.
Vulnerabilities are weaknesses in a LAN that can be exploited by a threat. For example, unauthorized access (the threat) to the LAN could occur by an outsider guessing an obvious password. The vulnerability exploited is the poor password choice made by a user. Reducing or eliminating the vulnerabilities of the LAN can reduce or eliminate the risk of threats to the LAN. For example, a tool that can help users choose robust passwords may reduce the chance that users will utilize poor passwords, and thus reduce the threat of unauthorized LAN access.
A security service is the collection of security mechanisms, supporting data files, and procedures that help protect the LAN from specific threats. For example, the identification and authentication service helps protect the LAN from unauthorized LAN access by requiring that a user identify himself, as well as verifying that identity. The security service is only as robust as the mechanisms, procedures, etc. that make up the service.
Security mechanisms are the controls implemented to provide the security services needed to protect the LAN. For example, a token based authentication system (which requires that the user be in possession of a required token) may be the mechanism implemented to provide the identification and authentication service. Other mechanisms that help maintain the confidentiality of the authentication information can also be considered as part of the identification and authentication service.
Threats and Vulnerabilities
Identifying threats requires one to look at the impact and consequence of the threat if it is realized. The impact of the threat, which usually points to the immediate near-term problems, results in disclosure, modification, destruction, or denial of service. The more significant long-term consequences of the threat being realized are the result of lost business, violation of privacy, civil law suits, fines, loss of human life or other long term effects. The approach taken here is to categorize the types of impacts that can occur on a LAN so that specific technical threats can be grouped by the impacts and examined in a meaningful manner. For example, the technical threats that can lead to the impact ‘LAN traffic compromise’ in general can be distinguished from those threats that can lead to the impact ‘disruption of LAN functionalities’. It should be recognized that many threats may result in more than one impact; however, for this discussion a particular threat will be discussed only in conjunction with one impact. The impacts that will be used to categorize and discuss the threats to a LAN environment are:
LANs provide file sharing, printer sharing, file storage sharing, etc. Because resources are shared and not used solely by one individual there is need for control of the resources and accountability for use of the resources. Unauthorized LAN access occurs when someone, who is not authorized to use the LAN, gains access to the LAN (usually by acting as a legitimate user of LAN). Three common methods used to gain unauthorized access are password sharing, general password guessing and password capturing. Password sharing allows an unauthorized user to have the LAN access and privileges of a legitimate user; with the legitimate user’s knowledge and acceptance. General password guessing is not a new means of unauthorized access. Password capturing is a process in which a legitimate user unknowingly reveals the user’s login ID and password. This may be done through the use of a trojan horse program that appears to the user as a legitimate login program; however, the trojan horse program is designed to capture passwords. Capturing a login ID and password as it is transmitted across the LAN unencrypted is another method used to ultimately gain access. The methods to capture cleartext LAN traffic, including passwords, is readily available today. Unauthorized LAN access can occur by exploiting the following types of vulnerabilities:
One of the benefits of using a LAN is that many resources are readily available to many users, rather than each user having limited dedicated resources. These resources may include file stores, applications, printers, data, etc. However, not all resources need to be made available to each user. To prevent compromising the security of the resource (i.e. corrupting the resource, or lessening the availability of the resource), only those who require the use of the resource should be permitted to utilize that resource. Unauthorized access occurs when a user, legitimate or unauthorized, accesses a resource that the user is not permitted to use. Unauthorized access may occur simply because the access rights assigned to the resource are not assigned properly. However, unauthorized access may also occur because the access control mechanism or the privilege mechanism is not granular enough. In these cases, the only way to grant the user the needed access rights or privileges to perform a specific function is to grant the user more access than is needed, or more privileges than are needed. Unauthorized access to LAN resources can occur by exploiting the following types of vulnerabilities:
As LANs are utilized throughout an agency or department, some of the data stored or processed on a LAN may require some level of confidentiality. The disclosure of LAN data or software occurs when the data or software is accessed, read and possibly released to an individual who is not authorized for the data. This can occur by someone gaining access to information that is not encrypted, or by viewing monitors or printouts of the information. The compromise of LAN
data can occur by exploiting the following types of vulnerabilities:
Because LAN users share data and applications, changes to those resources must be controlled. Unauthorized modification of data or software occurs when unauthorized changes (additions, deletions or modifications) are made to a file or program.
When undetected modifications to data are present for long periods of time, the modified data may be spread through the LAN, possibly corrupting databases, spreadsheet calculations, and other various application data. This can damage the integrity of most application information.
When undetected software changes are made, all system software can become suspect, warranting a thorough review (and perhaps reinstallation) of all related software and applications. These unauthorized changes can be made in simple command programs (for example in PC batch files), in utility programs used on multi-user systems, in major application programs, or any other type of software. They can be made by unauthorized outsiders, as well as those who are authorized to make software changes (although the changes they make are not authorized). These changes can divert information (or copies of the information) to other destinations, corrupt the data as it is processed, or harm the availability of system or LAN services.
PC viruses can be a nuisance to any organization that does not choose to provide LAN users the tools to effectively detect and prevent virus introduction to the LAN. Currently viruses have been limited to corrupting PCs, and generally do not corrupt LAN servers (although viruses can use the LAN to infect PCs). [WACK89] provides guidance on detecting and preventing viruses.
The unauthorized modification of data and software can occur by exploiting the following types of vulnerabilities:
The disclosure of LAN traffic occurs when someone who is unauthorized reads, or otherwise obtains, information as it is moved through the LAN. LAN traffic can be compromised by listening and capturing traffic transmitted over the LAN transport media (tapping into a network cable, listening to traffic transmitted over the air, misusing a provided network connection by attaching an analysis device, etc.). Many users realize the importance of confidential information when it is stored on their workstations or servers; however, it is also important to maintain that confidentiality as the information travels through the LAN. Information that can be compromised in this way includes system and user names, passwords, electronic mail messages, application data, etc. For example, even though passwords may be in an encrypted form when stored on a system, they can be captured in plaintext as they are sent from a workstation or PC to a file server. Electronic mail message files, which usually have very strict access rights when stored on a system, are often sent in plaintext across a wire, making them an easy target for capturing. The compromise of LAN traffic can occur by exploiting the following types of vulnerabilities:
Data that is transmitted over a LAN should not be altered in an unauthorized manner as a result of that transmission, either by the LAN itself, or by an intruder. LAN users should be able to have a reasonable expectation that the message sent, is received unmodified. A modification occurs when an intentional or unintentional change is made to any part of the message including the contents and addressing information.
Messages transmitted over the LAN need to contain some sort of addressing information that reports the sending address of the message and the receiving address of the message (along with other pieces of information). Spoofing of LAN traffic involves (1) the ability to receive a message by masquerading as the legitimate receiving destination, or (2) masquerading as the sending machine and sending a message to a destination. To masquerade as a receiving machine, the LAN must be persuaded into believing that the destination address is the legitimate address of the machine. (Receiving LAN traffic can also be done by listening to messages as they are broadcast to all nodes.) Masquerading as the sending machine to deceive a receiver into believing the message was legitimately sent can be done by masquerading the address, or by means of a playback. A playback involves capturing a session between a sender and receiver, and then retransmitting that message (either with the header only, and new message contents, or the whole message). The spoofing of LAN traffic or the modification of LAN traffic can occur by exploiting the following types of vulnerabilities:
A LAN is a tool, used by an organization, to share information and transmit it from one location to another. A disruption of functionality occurs when the LAN cannot provide the needed functionality in an acceptable, timely manner. A disruption can interrupt one type of functionality or many. A disruption of LAN functionalities can occur by exploiting the following types of vulnerabilities:
A variety of threats face today's computer systems and the information they process. In order to control the risks of operating an information system, managers and users must know the vulnerabilities of the system and the threats, which may exploit them. Knowledge of the threat environment allows the system manager to implement the most cost-effective security measures. In some cases, managers may find it most cost-effective to simply tolerate the expected losses.
The following threats and associated losses are based on their prevalence and significance in the current computing environment and their expected growth. The list is not exhaustive; some threats may combine elements from more than one area.
Users, data entry clerks, system operators, and programmers frequently make unintentional errors, which contribute to security problems, directly and indirectly. Sometimes the error is the threat, such as a data entry error or a programming error that crashes a system. In other cases, errors create vulnerabilities. Errors can occur in all phases of the system life cycle. Programming and development errors, often called bugs, range in severity from benign to catastrophic. In the past decade, software quality has improved measurably to reduce this threat, yet software "horror stories" still abound. Installation and maintenance errors also cause security problems. Errors and omissions are important threats to data integrity. Errors are caused not only by data entry clerks processing hundreds of transactions per day, but also by all users who create and edit data. Many programs, especially those designed by users for personal computers, lack quality control measures. However, even the most sophisticated programs cannot detect all types of input errors or omissions.
The computer age saying "garbage in, gospel out" contains a large measure of truth. People often assume that the information they receive from a computer system is more accurate than it really is. Many organizations address errors and omissions in their computer security, software quality, and data quality programs.
Information technology is increasingly used to commit fraud and theft. Computer systems are exploited in numerous ways, both by automating traditional methods of fraud and by using new methods. For example, individuals may use a computer to skim small amounts of money from a large number of financial accounts, thus generating a significant sum for their own use. In addition, deposits may be intentionally misdirected. Financial systems are not the only ones subject to fraud. Systems, which control access to any resource, are targets, such as time and attendance systems, inventory systems, school grading systems, or long-distance telephone systems.
Fraud can be committed by insiders or outsiders. The majority of fraud uncovered on computer systems is perpetrated by insiders who are authorized users of a system. Since insiders have both access to and familiarity with the victim computer system, including what resources it controls and where the flaws are, authorized system users are in a better position to commit crimes. An organization's former employees may also pose threats, particularly if their access is not terminated promptly.
Disgruntled employees can create both mischief and sabotage on a computer system. Employees are the group most familiar with their employer's computers and applications, including knowing what actions might cause the most damage. Organizational downsizing in both public and private sectors has created a group of individuals with organizational knowledge who may retain potential system access. System managers can limit this threat by invalidating passwords and deleting system accounts in a timely manner. However, disgruntled current employees actually cause more damage than former employees do.
Common examples of computer-related employee sabotage include:
The loss of supporting infrastructure includes power failures (including outages, spikes and brownouts), loss of communications, water outages and leaks, sewer problems, lack of transportation services, fire, flood, civil unrest, strikes, and so forth. These losses include dramatic events such as the explosion at the World Trade Center and the Chicago tunnel flood as well as more common events such as a broken water pipe. System owners must realize that more loss is associated with fires and floods than with viruses and other more widely publicized threats. A loss of infrastructure often results in system downtime, sometimes in unexpected ways. For example, employees may not be able to get to work during a winter storm, although the computer system may be functional.
Hackers, sometimes called crackers, are a real and present danger to most organizational computer systems linked by networks. From outside the organization, sometimes from another continent, hackers break into computer systems and compromise the privacy and integrity of data before the unauthorized access is even detected. Although insiders cause more damage than hackers do, the hacker problem remains serious and widespread.
The effect of hacker activity on the public switched telephone network has been studied in depth. Studies by the National Research Council and the National Security Telecommunications Advisory Committee show that hacker activity is not limited to toll fraud. It also includes the ability to break into telecommunications systems (such as switches) resulting in the degradation or disruption of system availability. While unable to reach a conclusion about the degree of threat or risk, these studies underscore the ability of hackers to cause serious damage.
The hacker threat often receives more attention than more common and dangerous threats. The U.S. Department of Justice's Computer Crime Unit suggests three reasons. First, the hacker threat is a more recently encountered threat. Organizations have always had to worry about the actions of their own employees and could use disciplinary measures to reduce that threat. However, these controls are ineffective against outsiders who are not subject to the rules and regulations of the employer.
Secondly, organizations do not know the purposes of a hacker; some hackers only browse, some steal, some damage. This inability to identify purposes can suggest that hacker attacks have no limitations. Finally, hacker attacks make people feel vulnerable because the perpetrators are unknown.
Industrial espionage involves collecting proprietary data from private corporations or government agencies for the benefit of another company or organization. Industrial espionage can be perpetrated either by companies seeking to improve their competitive advantage or by governments seeking to aid their domestic industries. Foreign industrial espionage carried out by a government is known as economic espionage.
Industrial espionage is on the rise. The most damaging types of stolen information include manufacturing and product development information. Other types of information stolen include sales and cost data, client lists, and research and planning information.
Within the area of economic espionage, the Central Intelligence Agency states that the main objective is obtaining information related to technology, but that information on U.S. government policy deliberations concerning foreign affairs and information on commodities, interest rates, and other economic factors is also a target. The Federal Bureau of Investigation concurs that technology-related information is the main target, but also cites corporate proprietary information such as negotiating positions and other contracting data as a target.
Malicious code refers to viruses, worms,
Trojan horses, logic bombs, and other "uninvited" software. Malicious code
is sometimes mistakenly associated only with personal computers, but can
also attack systems that are more sophisticated. However, actual costs
attributed to the presence of malicious code have resulted primarily from
system outages and staff time involved in repairing the systems. Nonetheless,
these costs can be significant.
2.2.4.7 Malicious Software: Terms
Virus: A code segment, which replicates by attaching copies of itself to existing executables. The new copy of the virus is executed when a user executes the new host program. The virus may include an additional "payload" that triggers when specific conditions are met. For example, some viruses display a text string on a particular date. There are many types of viruses including variants, overwriting, resident, stealth, and polymorphic.
Trojan Horse: A program that performs a desired task, but also includes unexpected (and undesirable) functions. Consider as an example an editing program for a multi-user system. This program could be modified to randomly delete one of the users' files each time they perform a useful function (editing) but the deletions are unexpected and definitely undesired!
Worm: A self-replicating program, which is self-contained and does not require a host program. The program creates a copy of itself and causes it to execute; no user intervention is required. Worms commonly utilize network services to propagate to other host systems.
The number of known viruses is increasing, and the rate of virus incidents is growing moderately. Most organizations use anti-virus software and other protective measures to limit the risk of virus infection.
2.2.4.8 Foreign Government Espionage
In some instances, threats posed by foreign government intelligence services may be present. In addition to possible economic espionage, foreign intelligence services may target unclassified systems to further their intelligence missions.
2.3 Security Services and Mechanisms Introduction
A security service is the collection of mechanisms, procedures and other controls that are implemented to help reduce the risk associated with threat. For example, the identification and authentication service helps reduce the risk of the unauthorized user threat. Some services provide protection from threats, while other services provide for detection of the threat occurrence. An example of this would be a logging or monitoring service. The following services will be discussed in this section:
Identification and authentication - is the security service that helps ensure that the LAN is accessed by only authorized individuals.
Access control - is the security service that helps ensure that LAN resources are being utilized in an authorized manner.
Data and message confidentiality - is the security service that helps ensure that LAN data, software and messages are not disclosed to unauthorized parties.
Data and message integrity - is the security service that helps ensure that LAN data, software and messages are not modified by unauthorized parties.
Non-repudiation - is the security service by which the entities involved in a communication cannot deny having participated. Specifically the sending entity cannot deny having sent a message (non-repudiation with proof of origin) and the receiving entity cannot deny having received a message (non-repudiation with proof of delivery).
Logging and Monitoring - is the security service by which uses of LAN resources can be traced throughout the LAN.
Determining the appropriate controls and procedures to use in any LAN environment is the responsibility of those in each organization charged with providing adequate LAN protection.
2.3.0 Identification and Authentication
The first step toward securing the resources of a LAN is the ability to verify the identities of users [BNOV91]. The process of verifying a user’s identity is referred to as authentication. Authentication provides the basis for the effectiveness of other controls used on the LAN. For example the logging mechanism provides usage information based on the userid. The access control mechanism permits access to LAN resources based on the userid. Both these controls are only effective under the assumption that the requestor of a LAN service is the valid user assigned to that specific userid.
Identification requires the user to be known by the LAN in some manner. This is usually based on an assigned userid. However the LAN cannot trust the validity that the user is in fact, who the user claims to be, without being authenticated. The authentication is done by having the user supply something that only the user has, such as a token, something that only the user knows, such as a password, or something that makes the user unique, such as a fingerprint. The more of these that the user has to supply, the less risk in someone masquerading as the legitimate user.
A requirement specifying the need for authentication should exist in most LAN policies. The requirement may be directed implicitly in a program level policy stressing the need to effectively control access to information and LAN resources, or may be explicitly stated in a LAN specific policy that states that all users must be uniquely identified and authenticated.
On most LANs, the identification and authentication mechanism is a userid/password scheme. [BNOV91] states that "password systems can be effective if managed properly [FIPS112], but seldom are. Authentication which relies solely on passwords has often failed to provide adequate protection for systems for a number of reasons. Users tend to create passwords that are easy to remember and hence easy to guess. On the other hand users that must use passwords generated from random characters, while difficult to guess, are also difficult to be remembered by users. This forces the user to write the password down, most likely in an area easy accessible in the work area". Research work such as [KLEIN] detail the ease at which passwords can be guessed. Proper password selection (striking a balance between being easy-to-remember for the user but difficult-to-guess for everyone else) has always been an issue. Password generators that produce passwords consisting of pronounceable syllables have more potential of being remembered than generators that produce purely random characters. [FIPS180] specifies an algorithm that can be used to produce random pronounceable passwords. Password checkers are programs that enable a user to determine whether a new passwords is considered easy-to-guess, and thus unacceptable.
Password-only mechanisms, especially those that transmit the password in the clear (in an unencrypted form) are susceptible to being monitored and captured. This can become a serious problem if the LAN has any uncontrolled connections to outside networks. Agencies that are considering connecting their LANs to outside networks, particularly the Internet, should examine [BJUL93] before doing so. If, after considering all authentication options, LAN policy determines that password-only systems are acceptable, the proper management of password creation, storage, expiration and destruction become all the more important. [FIPS 112] provides guidance on password management. [NCSC85] provides additional guidance that may be considered appropriate.
Because of the vulnerabilities that still exist with the use of password-only mechanisms, more robust mechanisms can be used. [BNOV91] discusses advances that have been made in the areas of token-based authentication and the use of biometrics. A smartcard based or token based mechanism requires that a user be in possession of the token and additionally may require the user to know a PIN or password. These devices then perform a challenge/response authentication scheme using realtime parameters. Using realtime parameters helps prevent an intruder from gaining unauthorized access through a login session playback. These devices may also encrypt the authentication session, preventing the compromise of the authentication information through monitoring and capturing.
Locking mechanisms for LAN devices, workstations, or PCs that require user authentication to unlock can be useful to users who must leave their work areas frequently. These locks allow users to remain logged into the LAN and leave their work areas (for an acceptable short period of time) without exposing an entry point into the LAN.
Modems that provide users with LAN access may require additional protection. An intruder that can access the modem may gain access by successfully guessing a user password. The availability of modem use to legitimate users may also become an issue if an intruder is allowed continual access to the modem.
Mechanisms that provide a user with his or her account usage information may alert the user that the account was used in an abnormal manner (e.g. multiple login failures). These mechanisms include notifications such as date, time, and location of last successful login, and number of previous login failures. The type of security mechanisms that could be implemented to provide the identification and authentication service are listed below.
This service protects against the unauthorized use of LAN resources, and can be provided by the use of access control mechanisms and privilege mechanisms. Most file servers and multi-user workstations provide this service to some extent. However, PCs which mount drives from the file servers usually do not. Users must recognize that files used locally from a mounted drive are under the access control of the PC. For this reason it may be important to incorporate access control, confidentiality and integrity services on PCs to whatever extent possible.
According to [NCSC87], access control can be achieved by using discretionary access control or mandatory access control. Discretionary access control is the most common type of access control used by LANs. The basis of this kind of security is that an individual user, or program operating on the user’s behalf is allowed to specify explicitly the types of access other users (or programs executing on their behalf) may have to information under the user’s control.
Discretionary security differs from mandatory security in that it implements the access control decisions of the user. Mandatory controls are driven by the results of a comparison between the user’s trust level or clearance and the sensitivity designation of the information.
Access control mechanisms exist that support access granularity for acknowledging an owner, a specified group of users, and the world (all other authorized users). This allows the owner of the file (or directory) to have different access rights than all other users, and allows the owner to specify different access rights for a specified group of people, and also for the world. Generally access rights allow read access, write access, and execute access. Some LAN operating systems provide additional access rights that allow updates, append only, etc.
A LAN operating system may implement user profiles, capability lists or access control lists to specify access rights for many individual users and many different groups. Using these mechanisms allows more flexibility in granting different access rights to different users, which may provide more stringent access control for the file (or directory). (These more flexible mechanisms prevent having to give a user more access than necessary, a common problem with the three level approach.) Access control lists assign the access rights of named users and named groups to a file or directory. Capability lists and user profiles assign the files and directories that can be accessed by a named user.
User access may exist at the directory level, or the file level. Access control at the directory level places the same access rights on all the files in the directory. For example, a user that has read access to the directory can read (and perhaps copy) any file in that directory. Directory access rights may also provide an explicit negative access that prevents the user from any access to the files in the directory.
Some LAN implementations control how a file can be accessed. (This is in addition to controlling who can access the file.) Implementations may provide a parameter that allows an owner to mark a file sharable, or locked. Sharable files accept multiple accesses to the file at the same time. A locked file will permit only one user to access it. If a file is a read only file, making it sharable allows many users to read it at the same time.
These access controls can also be used to restrict usage between servers on the LAN. Many LAN operating systems can restrict the type of traffic sent between servers. There may be no restrictions, which implies that all users may be able to access resources on all servers (depending on the users access rights on a particular server). Some restrictions may be in place that allow only certain types of traffic, for example only electronic mail messages, and further restrictions may allow no exchange of traffic from server to server. The LAN policy should determine what types of information need to be exchanged between servers. Information that is not necessary to be shared between servers should then be restricted.
Privilege mechanisms enable authorized users to override the access permissions, or in some manner legally bypass controls to perform a function, access a file, etc. A privilege mechanism should incorporate the concept of least privilege. [ROBA91] defines least privilege as "a principle where each subject in a system be granted the most restrictive set or privileges needed for the performance of an authorized task." For example, the principle of least privilege should be implemented to perform the backup function. A user who is authorized to perform the backup function needs to have read access to all files in order to copy them to the backup media. (However the user should not be given read access to all files through the access control mechanism.) The user is granted a ’privilege’ to override the read restrictions (enforced by the access control mechanism) on all files in order to perform the backup function. The more granular the privileges that can be granted, the more control there is not having to grant excessive privilege to perform an authorized function. For example, the user who has to perform the backup function does not need to have a write override privilege, but for privilege mechanisms that are less granular, this may occur. The types of security mechanisms that could be implemented to provide the access control service are listed below.
The data and message confidentiality service can be used when the secrecy of information is necessary. As a front line protection, this service may incorporate mechanisms associated with the access control service, but can also rely on encryption to provide further secrecy protection. Encrypting information converts it to an unintelligible form called ciphertext, decrypting converts the information back to its original form. Sensitive information can be stored in the encrypted, ciphertext, form. In this way if the access control service is circumvented, the file may be accessed but the information is still protected by being in encrypted form. (The use of encryption may be critical on PCs that do not provide an access control service as a front line protection.)
It is very difficult to control unauthorized access to LAN traffic as it is moved through the LAN. For most LAN users, this is a realized and accepted problem. The use of encryption reduces the risk of someone capturing and reading LAN messages in transit by making the message unreadable to those who may capture it. Only the authorized user who has the correct key can decrypt the message once it is received.
A strong policy statement should dictate to users the types of information that are deemed sensitive enough to warrant encryption. A program level policy may dictate the broad categories of information that need to be stringently protected, while a system level policy may detail the specific types of information and the specific environments that warrant encryption protection. At whatever level the policy is dictated, the decision to use encryption should be made by the authority within the organization charged with ensuring protection of sensitive information. If a strong policy does not exist that defines what information to encrypt, then the data owner should ultimately make this decision.
Cryptography can be categorized as either secret key or public key. Secret key cryptography is based on the use of a single cryptographic key shared between two parties . The same key is used to encrypt and decrypt data. This key is kept secret by the two parties. If encryption of sensitive but unclassified information (except Warner Amendment information) is needed, the use of the Data Encryption Standard (DES), FIPS 46-2, is required unless a waiver is granted by the head of the federal agency. The DES is a secret key algorithm used in a cryptographic system that can provide confidentiality. FIPS 46-2 provides for the implementation of the DES algorithm in hardware, software, firmware or some combination. This is a change from 46-1 which only provided for the use of hardware implementations. For an overview of DES, information addressing the applicability of DES, and waiver procedures see [NCSL90].
Public key cryptography is a form of cryptography which make use of two keys: a public key and a private key. The two keys are related but have the property that, given the public key, it is computationally infeasible to derive the private key [FIPS 140-1]. In a public key cryptosystem, each party has its own public/private key pair. The public key can be known by anyone; the private key is kept secret. An example for providing confidentiality is as follows: two users, Scott and Jeff, wish to exchange sensitive information, and maintain the confidentiality of that information. Scott can encrypt the information with Jeff’s public key. The confidentiality of the information is maintained since only Jeff can decrypt the information using his private key. There is currently no FIPS approved public-key encryption algorithm for confidentiality. Agencies must waive FIPS 46-2 to use a public-key encryption algorithm for confidentiality. Public key technology, in the form of digital signatures, can also provide integrity and non-repudiation.
FIPS 140-1, Security Requirements for Cryptographic Modules, should be used by agencies to specify the security requirements needed to protect the equipment that is used encryption. This standard specifies requirements such as authentication, physical controls and proper key management for all equipment that is used for encryption. Systems that implement encryption in software have additional requirements placed on them by FIPS 140-1. LAN servers, PCs, encryption boards, encryption modems, and all other LAN and data communication equipment that has an encryption capability should conform to the requirements of FIPS 140-1. The types of security mechanisms that could be implemented to provide the message and data confidentiality service are listed below.
2.3.3 Data and Message Integrity
The data and message integrity service helps to protect data and software on workstations, file servers, and other LAN components from unauthorized modification. The unauthorized modification can be intentional or accidental. This service can be provided by the use of cryptographic checksums, and very granular access control and privilege mechanisms. The more granular the access control or privilege mechanism, the less likely an unauthorized or accidental modification can occur.
The data and message integrity service also helps to ensure that a message is not altered, deleted or added to in any manner during transmission. (The inadvertent modification of a message packet is handled through the media access control implemented within the LAN protocol.) Most of the security techniques available today cannot prevent the modification of a message, but they can detect the modification of a message (unless the message is deleted altogether).
The use of checksums provide a modification detection capability. A Message Authentication Code (MAC), a type of cryptographic checksum, can protect against both accidental and intentional, but unauthorized, data modification. A MAC is initially calculated by applying a cryptographic algorithm and a secret value, called the key, to the data. The initial MAC is retained. The data is later verified by applying the cryptographic algorithm and the same secret key to the data to produce another MAC; this MAC is then compared to the initial MAC. If the two MACs are equal, then the data is considered authentic. Otherwise, an unauthorized modification is assumed. Any party trying to modify the data without knowing the key would not know how to calculate the appropriate MAC corresponding to the altered data. FIPS 113, Computer Data Authentication, defines the Data Authentication Algorithm, based on the DES, which is used to calculate the MAC. See [SMID88] for more information regarding the use of MACs.
The use of electronic signatures can also be used to detect the modification of data or messages. An electronic signature can be generated using public key or private key cryptography. Using a public key system, documents in a computer system are electronically signed by applying the originator’s private key to the document. The resulting digital signature and document can then be stored or transmitted. The signature can be verified using the public key of the originator.
If the signature verifies properly, the receiver has confidence that the document was signed using the private key of the originator and that the message had not been altered after it was signed. Because private keys are known only to their owner, it may also possible to verify the originator of the information to a third party. A digital signature, therefore, provides two distinct services: nonrepudiation and message integrity. FIPS PUB 186, Digital Signature Standard, specifies a digital signature algorithm that should be used when message and data integrity are required.
The message authentication code (MAC) described above can also be used to provide an electronic signature capability. The MAC is calculated based on the contents of the message. After transmission another MAC is calculated on the contents of the received message. If the MAC associated with the message that was sent is not the same as the MAC associated with the message that was received, then there is proof that the message received does not exactly match the message sent. A MAC can be used to identify the signer of the information to the receiver. However, the implementations of this technology do not inherently provide nonrepudiation because both the sender of the information and the receiver of the information share the same key. The types of security mechanisms that could be implemented to provide the data and message integrity service are listed below.
Non-repudiation helps ensure that the entities in a communication cannot deny having participated in all or part of the communication. When a major function of the LAN is electronic mail, this service becomes very important. Non-repudiation with proof of origin gives the receiver some confidence that the message indeed came from the named originator. The nonrepudiation service can be provided through the use of public key cryptographic techniques
using digital signatures. The security mechanism that could be implemented to provide the non-repudiation service is listed below.
This service performs two functions. The first is the detection of the occurrence of a threat. (However, the detection does not occur in real time unless some type of real-time monitoring capability is utilized.) Depending on the extensiveness of the logging, the detected event should be traceable throughout the system. For example, when an intruder breaks into the system, the log should indicate who was logged on to the system at the time, all sensitive files that had failed accesses, all programs that had attempted executions, etc. It should also indicate sensitive files and programs that were successfully accessed in this time period. It may be appropriate that some areas of the LAN (workstations, fileservers, etc.) have some type of logging service.
The second function of this service is to provide system and network managers with statistics that indicate that systems and the network as a whole are functioning properly. This can be done by an audit mechanism that uses the log file as input and processes the file into meaningful information regarding system usage and security. A monitoring capability can also be used to detect LAN availability problems as they develop. The types of security mechanisms that could be used to provide the logging and monitoring service are listed below.
There are many services which a site may wish to provide for its users, some of which may be external. There are a variety of security reasons to attempt to isolate services onto dedicated host computers. There are also performance reasons in most cases, but a detailed discussion is beyond to scope of this document.
The services which a site may provide will, in most cases, have different levels of access needs and models of trust. Services which are essential to the security or smooth operation of a site would be better off being placed on a dedicated machine with very limited access (see "deny all" model), rather than on a machine that provides a service (or services) which has traditionally been less secure, or requires greater accessibility by users who may accidentally suborn security.
It is also important to distinguish between hosts which operate within different models of trust (e.g., all the hosts inside of a firewall and any host on an exposed network).
Some of the services which should be examined for potential separation are outlined in the section on service protection. It is important to remember that security is only as strong as the weakest link in the chain. Several of the most publicized penetrations in recent years have been through the exploitation of vulnerabilities in electronic mail systems. The intruders were not trying to steal electronic mail, but they used the vulnerability in that service to gain access to other systems.
If possible, each service should be running on a different machine whose only duty is to provide a specific service. This helps to isolate intruders and limit potential harm.
There are two diametrically opposed underlying philosophies which can be adopted when defining a security plan. Both alternatives are legitimate models to adopt, and the choice between them will depend on the site and its needs for security.
The first option is to turn off all services and then selectively enable services on a case by case basis as they are needed. This can be done at the host or network level as appropriate. This model, which will here after be referred to as the "deny all" model, is generally more secure than the other model described in the next paragraph. More work is required to successfully implement a "deny all" configuration as well as a better understanding of services. Allowing only known services provides for a better analysis of a particular service/protocol and the design of a security mechanism suited to the security level of the site.
The other model, which will here after be referred to as the "allow all" model, is much easier to implement, but is generally less secure than the "deny all" model. Simply turn on all services, usually the default at the host level, and allow all protocols to travel across network boundaries, usually the default at the router level. As security holes become apparent, they are restricted or patched at either the host or network level.
Each of these models can be applied to different portions of the site, depending on functionality requirements, administrative control, site policy, etc. For example, the policy may be to use the "allow all" model when setting up workstations for general use, but adopt a "deny all" model when setting up information servers, like an email hub. Likewise, an "allow all" policy may be adopted for traffic between LAN's internal to the site, but a "deny all" policy can be adopted between the site and the Internet.
Be careful when mixing philosophies as in the examples above. Many sites adopt the theory of a hard "crunchy" shell and a soft "squishy" middle. They are willing to pay the cost of security for their external traffic and require strong security measures, but are unwilling or unable to provide similar protections internally. This works fine as long as the outer defenses are never breached and the internal users can be trusted. Once the outer shell (firewall) is breached, subverting the internal network is trivial.
2.4.1.0 Name Servers (DNS and NIS(+))
The Internet uses the Domain Name System (DNS) to perform address resolution for host and network names. The Network Information Service (NIS) and NIS+ are not used on the global Internet, but are subject to the same risks as a DNS server. Name-to-address resolution is critical to the secure operation of any network. An attacker who can successfully control or impersonate a DNS server can re-route traffic to subvert security protections. For example, routine traffic can be diverted to a compromised system to be monitored; or, users can be tricked into providing authentication secrets. An organization should create well known, protected sites to act as secondary name servers and protect their DNS masters from denial of service attacks using filtering routers.
Traditionally, DNS has had no security capabilities. In particular, the information returned from a query could not be checked for modification or verified that it had come from the name server in question. Work has been done to incorporate digital signatures into the protocol which, when deployed, will allow the integrity of the information to be cryptographically verified.
2.4.1.1 Password/Key Servers (NIS(+) and KDC)
Password and key servers generally protect their vital information (i.e., the passwords and keys) with encryption algorithms. However, even a one-way encrypted password can be determined by a dictionary attack (wherein common words are encrypted to see if they match the stored encryption). It is therefore necessary to ensure that these servers are not accessible by hosts which do not plan to use them for the service, and even those hosts should only be able to access the service (i.e., general services, such as Telnet and FTP, should not be allowed by anyone other than administrators).
2.4.1.2 Authentication/Proxy Servers (SOCKS, FWTK)
A proxy server provides a number of security enhancements. It allows sites to concentrate services through a specific host to allow monitoring, hiding of internal structure, etc. This funneling of services creates an attractive target for a potential intruder. The type of protection required for a proxy server depends greatly on the proxy protocol in use and the services being proxied. The general rule of limiting access only to those hosts which need the services, and limiting access by those hosts to only those services, is a good starting point.
Electronic mail (email) systems have long been a source for intruder break-ins because email protocols are among the oldest and most widely deployed services. Also, by it's very nature, an email server requires access to the outside world; most email servers accept input from any source. An email server generally consists of two parts: a receiving/sending agent and a processing agent. Since email is delivered to all users, and is usually private, the processing agent typically requires system (root) privileges to deliver the mail. Most email implementations perform both portions of the service, which means the receiving agent also has system privileges. This opens several security holes which this document will not describe. There are some implementations available which allow a separation of the two agents. Such implementations are generally considered more secure, but still require careful installation to avoid creating a security problem.
The Web is growing in popularity exponentially because of its ease of use and the powerful ability to concentrate information services. Most WWW servers accept some type of direction and action from the persons accessing their services. The most common example is taking a request from a remote user and passing the provided information to a program running on the server to process the request. Some of these programs are not written with security in mind and can create security holes. If a Web server is available to the Internet community, it is especially important that confidential information not be co-located on the same host as that server. In fact, it is recommended that the server have a dedicated host which is not "trusted" by other internal hosts.
Many sites may want to co-locate FTP service with their WWW service. But this should only occur for anon-ftp servers that only provide information (ftp-get). Anon-ftp puts, in combination with WWW, might be dangerous (e.g., they could result in modifications to the information your site is publishing to the web) and in themselves make the security considerations for each service different.
2.4.1.5 File Transfer (FTP, TFTP)
FTP and TFTP both allow users to receive and send electronic files in a point-to-point manner. However, FTP requires authentication while TFTP requires none. For this reason, TFTP should be avoided as much as possible.
Improperly configured FTP servers can allow intruders to copy, replace and delete files at will, anywhere on a host, so it is very important to configure this service correctly. Access to encrypted passwords and proprietary data, and the introduction of Trojan horses are just a few of the potential security holes that can occur when the service is configured incorrectly. FTP servers should reside on their own host. Some sites choose to co-locate FTP with a Web server, since the two protocols share common security considerations However, the practice isn't recommended, especially when the FTP service allows the deposit of files (see section on WWW above). Services offered internally to your site should not be co-located with services offered externally. Each should have its own host.
TFTP does not support the same range of functions as FTP, and has no security whatsoever. This service should only be considered for internal use, and then it should be configured in a restricted way so that the server only has access to a set of predetermined files (instead of every world-readable file on the system). Probably the most common usage of TFTP is for downloading router configuration files to a router. TFTP should reside on its own host, and should not be installed on hosts supporting external FTP or Web access.
The Network File Service allows hosts to share common disks. NFS is frequently used by diskless hosts who depend on a disk server for all of their storage needs. Unfortunately, NFS has no built-in security. It is therefore necessary that the NFS server be accessible only by those hosts which are using it for service. This is achieved by specifying which hosts the file system is being exported to and in what manner (e.g., read-only, read-write, etc.). Filesystems should not be exported to any hosts outside the local network since this will require that the NFS service be accessible externally. Ideally, external access to NFS service should be stopped by a firewall.
2.4.2 Protecting the Protection
It is amazing how often a site will overlook the most obvious weakness in its security by leaving the security server itself open to attack. Based on considerations previously discussed, it should be clear that: the security server should not be accessible from off-site; should offer minimum access, except for the authentication function, to users on-site; and should not be co-located with any other servers. Further, all access to the node, including access to the service itself, should be logged to provide a "paper trail" in the event of a security breach.
This section covers the procedures for collecting data generated by network activity, which may be useful in analyzing the security of a network and responding to security incidents.
Audit data should include any attempt to achieve a different security level by any person, process, or other entity in the network. This includes login and logout, super user access (or the non-UNIX equivalent), ticket generation (for Kerberos, for example), and any
other change of access or status. It is especially important to note "anonymous" or "guest" access to public servers.
The actual data to collect will differ for different sites and for different types of access changes within a site. In general, the information you want to collect includes: username and hostname, for login and logout; previous and new access rights, for a change of access rights; and a timestamp. Of course, there is much more information which might be gathered, depending on what the system makes available and how much space is available to store that information.
One very important note: do not gather passwords. This creates an enormous potential security breach if the audit records should be improperly accessed. Do not gather incorrect passwords either, as they often differ from valid passwords by only a single character or transposition.
The collection process should be enacted by the host or resource being accessed. Depending on the importance of the data and the need to have it local in instances in which services are being denied, data could be kept local to the resource until needed or be transmitted to storage after each event.
There are basically three ways to store audit records: in a read/write file on a host, on a write-once/read-many device (e.g., a CD-ROM or a specially configured tape drive), or on a write-only device (e.g., a line printer). Each method has advantages and disadvantages.
File system logging is the least resource intensive of the three methods and the easiest to configure. It allows instant access to the records for analysis, which may be important if an attack is in progress. File system logging is also the least reliable method. If the logging host has been compromised, the file system is usually the first thing to go; an intruder could easily cover up traces of the intrusion.
Collecting audit data on a write-once device is slightly more effort to configure than a simple file, but it has the significant advantage of greatly increased security because an intruder could not alter the data showing that an intrusion has occurred. The disadvantage of this method is the need to maintain a supply of storage media and the
cost of that media. Also, the data may not be instantly available.
Line printer logging is useful in system where permanent and immediate logs are required. A real time system is an example of this, where the exact point of a failure or attack must be recorded. A laser printer, or other device which buffers data (e.g., a print server), may suffer from lost data if buffers contain the needed data at a critical instant. The disadvantage of, literally, "paper trails" is the need to keep the printer fed and the need to scan records by hand. There is also the issue of where to store the, potentially, enormous volume of paper which may be generated.
Collecting audit data may result in a rapid accumulation of bytes so storage availability for this information must be considered in advance. There are a few ways to reduce the required storage space. First, data can be compressed, using one of many methods. Or, the required space can be minimized by keeping data for a shorter period of time with only summaries of that data kept in long-term archives. One major drawback to the latter method involves incident response. Often, an incident has been ongoing for some period of time when a site notices it and begins to investigate. At that point in time, it's very helpful to have detailed audit logs available. If these are just summaries, there may not be sufficient detail to fully handle the incident.
2.5.4 Handling and Preserving Audit Data
Audit data should be some of the most carefully secured data at the site and in the backups. If an intruder were to gain access to audit logs, the systems themselves, in addition to the data, would be at risk.
Audit data may also become key to the investigation, apprehension, and prosecution of the perpetrator of an incident. For this reason, it is advisable to seek the advice of legal council when deciding how audit data should be treated. This should happen before an incident occurs.
If a data handling plan is not adequately defined prior to an incident, it may mean that there is no recourse in the aftermath of an event, and it may create liability resulting from improper treatment of the data.
One area concerns the privacy of individuals. In certain instances, audit data may contain personal information. Searching through the data, even for a routine check of the system's security, could represent an invasion of privacy.
A second area of concern involves knowledge of intrusive behavior originating from your site. If an organization keeps audit data, is it responsible for examining it to search for incidents? If a host in one organization is used as a launching point for an attack against another organization, can the second organization use the audit data of the first organization to prove negligence on the part of that organization?
The above examples are meant to be comprehensive, but should motivate your organization to consider the legal issues involved with audit data.
The procedure of creating backups is a classic part of operating a computer system. Within the context of this document, backups are addressed as part of the overall security plan of a site. There are several aspects to backups that are important within this context:
storage site should be carefully
selected for both its security
and its availability.
of the information once it is off-site.
However, be aware that
you will need a good key management scheme so that you'll be
able to recover data at any point in the future. Also, make
sure you will have access to the necessary decryption programs
at such time in the future as you need to perform the
decryption.
many instances of computer security
incidents that have gone on
for long periods of time before a site has noticed the incident.
In such cases, backups of the affected systems are also tainted.
2.6.0 Preparing and Planning for Incident Handling
Part of handling an incident is being prepared to respond to an incident before the incident occurs in the first place. This includes establishing a suitable level of protections as explained in the preceding chapters. Doing this should help your site prevent incidents as well as limit potential damage resulting from them when they do occur. Protection also includes preparing incident handling guidelines as part of a contingency plan for your organization or site. Having written plans eliminates much of the ambiguity which occurs during an incident, and will lead to a more appropriate and thorough set of responses. It is vitally important to test the proposed plan before an incident occurs through "dry runs". A team might even consider hiring a tiger team to act in parallel with the dry run. (Note: a tiger team is a team of specialists that try to penetrate the security of a system.)
Learning to respond efficiently to an incident is important for a number of reasons:
profitably if an incident did not
require their services
vulnerability.
It is also important to prioritize the actions to be taken during an incident well in advance of the time an incident occurs. Sometimes an incident may be so complex that it is impossible to do everything at once to respond to it; priorities are essential. Although priorities will vary from institution to institution, the following suggested priorities may serve as a starting point for defining your organization's response:
safety; human life always has precedence
over all
other considerations.
data. Prevent exploitation of classified
and/or
sensitive systems, networks or sites. Inform affected
classified and/or sensitive systems, networks or sites
about already occurred penetrations.
(Be aware of regulations by your site or by government)
proprietary, scientific, managerial
and other data,
because loss of data is costly in terms of resources.
Prevent exploitations of other systems, networks or
sites and inform already affected systems, networks or
sites about successful penetrations.
or alteration of system files,
damage to disk drives,
etc.). Damage to systems can result in costly down
time and recovery.
cases to shut a system down or disconnect from a network
than to risk damage to data or systems. Sites will have
to evaluate the trade-offs between shutting down and
disconnecting, and staying up. There may be service
agreements in place that may require keeping systems
up even in light of further damage occurring. However,
the damage and scope of an incident may be so extensive
that service agreements may have to be over-ridden.
It is important to establish contacts with various personnel before a real incident occurs. Many times, incidents are not real emergencies. Indeed, often you will be able to handle the activities internally. However, there will also be many times when others outside your immediate department will need to be included in the incident handling. These additional contacts include local managers and system administrators, administrative contacts for other sites on the Internet, and various investigative organizations. Getting to know these contacts before incidents occurs will help to make your incident handling process more efficient.
For each type of communication contact, specific "Points of Contact" (POC) should be defined. These may be technical or administrative in nature and may include legal or investigative agencies as well as service providers and vendors. When establishing these contact, it is important to decide how much information will be shared with each class of contact. It is especially important to define, ahead of time, what information will be shared with the users at a site, with the public (including the press), and with other sites.
2.6.2 Law Enforcement and Investigative Agencies
In the event of an incident that has legal consequences, it is important to establish contact with investigative agencies (e.g, the FBI and Secret Service in the U.S. and the RCMP in Canada) as soon as possible. Local law enforcement, local security offices, and campus police departments should also be informed as appropriate. This section describes many
of the issues that will be confronted, but it is acknowledged that each organization will have its own local and governmental laws and regulations that will impact how they interact with law enforcement and investigative agencies. The most important point to make is that each site needs to work through these issues.
A primary reason for determining these point of contact well in advance of an incident is that once a major attack is in progress, there is little time to call these agencies to determine exactly who the correct point of contact is. Another reason is that it is important to cooperate with these agencies in a manner that will foster a good working relationship, and that will be in accordance with the working procedures of these agencies. Knowing the working procedures in advance, and the expectations of your point of contact is a big step in this direction. For example, it is important to gather evidence that will be admissible in any subsequent legal proceedings, and this will require prior knowledge of how to gather such evidence. A final reason for establishing contacts as soon as possible is that it is impossible to know the particular agency that will assume jurisdiction in any given incident. Making contacts and finding the proper channels early on will make responding to an incident go considerably more smoothly.
If your organization or site has a legal counsel, you need to notify this office soon after you learn that an incident is in progress. At a minimum, your legal counsel needs to be involved to protect the legal and financial interests of your site or organization. There are many legal and practical issues, a few of which are:
publicity or exposure to cooperate
with legal prosecution
efforts.
it can be monitored and another
computer is damaged because the
attack originated from your system, your site or organization
may be liable for damages incurred.
distributes information about an
attack in which another site or
organization may be involved or the vulnerability in a product
that may affect ability to market that product, your site or
organization may again be liable for any damages (including
damage of reputation).
is monitoring account activity without informing users.
On the other hand, an organization's legal council may advise extreme caution and suggest that tracing activities be halted and an intruder shut out of the system. This, in itself, may not provide protection from liability, and may prevent investigators from identifying the perpetrator.
The balance between supporting investigative activity and limiting liability is tricky. You'll need to consider the advice of your legal counsel and the damage the intruder is causing (if any) when making your decision about what to do during any particular incident.
Your legal counsel should also be involved in any decision to contact investigative agencies when an incident occurs at your site. The decision to coordinate efforts with investigative agencies is most properly that of your site or organization. Involving your legal counsel will also foster the multi-level coordination between your site and the particular investigative agency involved, which in turn results in an efficient division of labor. Another result is that you are likely to obtain guidance that will help you avoid future legal mistakes.
Finally, your legal counsel should evaluate your site's written procedures for responding to incidents. It is essential to obtain a "clean bill of health" from a legal perspective before you actually carry out these procedures.
It is vital, when dealing with investigative agencies, to verify that the person who calls asking for information is a legitimate representative from the agency in question. Unfortunately, many well intentioned people have unknowingly leaked sensitive details about incidents, allowed unauthorized people into their systems, etc., because a caller has masqueraded as a representative of a government agency. (Note: this word of caution actually applies to all external contacts.)
A similar consideration is using a secure means of communication. Because many network attackers can easily re-route electronic mail, avoid using electronic mail to communicate with other agencies (as well as others dealing with the incident at hand). Non-secured phone lines (the phones normally used in the business world) are also
frequent targets for tapping by network intruders, so be careful!
There is no one established set of rules for responding to an incident when the local government becomes involved. Normally (in the U.S.), except by legal order, no agency can force you to monitor, to disconnect from the network, to avoid telephone contact with the suspected attackers, etc. Each organization will have a set of local and national laws and regulations that must be adhered to when handling incidents. It is recommended that each site be familiar with those laws and regulations, and identify and get know the contacts for agencies with jurisdiction well in advance of handling an incident.
It is crucial during a major incident to communicate why certain actions are being taken, and how the users (or departments) are expected to behave. In particular, it should be made very clear to users what they are allowed to say (and not say) to the outside world (including other departments). For example, it wouldn't be good for an organization if users replied to customers with something like, "I'm sorry the systems are down, we've had an intruder and we are trying to clean things up." It would be much better if they were instructed to respond with a prepared statement like, "I'm sorry our systems are unavailable, they are being maintained for better service in the future."
Communications with customers and contract partners should be handled in a sensible, but sensitive way. One can prepare for the main issues by preparing a checklist. When an incident occurs, the checklist can be used with the addition of a sentence or two for the specific circumstances of the incident.
Public relations departments can be very helpful during incidents. They should be involved in all planning and can provide well constructed responses for use when contact with outside departments and organizations is necessary.
2.6.4 Public Relations - Press Releases
One of the most important issues to consider is when, who, and how much to release to the general public through the press. There are many issues to consider when deciding this particular issue. First and foremost, if a public relations office exists for the site, it is important to use this office as liaison to the press. The public relations office is trained in the type and wording of information released, and will help to assure that the image of the site is protected during and after the incident (if possible). A public relations office has the advantage that you can communicate candidly with them, and provide a buffer between the constant press attention and the need of the POC to maintain control over the incident.
If a public relations office is not available, the information released to the press must be carefully considered. If the information is sensitive, it may be advantageous to provide only minimal or overview information to the press. It is quite possible that any information provided to the press will be quickly reviewed by the perpetrator of the incident. Also note that misleading the press can often backfire and cause more damage than releasing sensitive information.
While it is difficult to determine in advance what level of detail to provide to the press, some guidelines to keep in mind are:
information about the incident
may provide enough
information for others to launch similar attacks on
other sites, or even damage the site's ability to
prosecute the guilty party once the event is over.
Speculation of who is causing the
incident or the
motives are very likely to be in error and may cause
an inflamed view of the incident.
evidence is protected. If prosecution
is involved,
assure that the evidence collected is not divulged to
the press.
prepared. The popular press is
famous for the "2 am"
interview, where the hope is to catch the interviewee off
guard and obtain information otherwise not available.
closure of an incident is of primary importance.
This stage involves determining if a problem really exists. Of course many if not most signs often associated with virus infection, system intrusions, malicious users, etc., are simply anomalies such as hardware failures or suspicious system/user behavior. To assist in identifying whether there really is an incident, it is usually helpful to obtain and use any detection software which may be available. Audit information is also extremely useful, especially in determining whether there is a network attack. It is extremely important to obtain a system snapshot as soon as one suspects that something is wrong. Many incidents cause a dynamic chain of events to occur, and an initial system snapshot may be the most valuable tool for identifying the problem and any source of attack. Finally, it is important to start a log book. Recording system events, telephone conversations, time stamps, etc., can lead to a more rapid and systematic identification of the problem, and is the basis for subsequent stages of incident handling.
There are certain indications or "symptoms" of an incident that deserve special attention:
unexpectedly created), or high
activity on a previously
low usage account.
such as data.xx or k or .xx ).
notice the shrinking of an accounting
file called
/usr/admin/lastlog, something that should make you very
suspicious that there may be an intruder).
suspicious if .EXE files in an
MS DOS computer have
unexplainedly grown by over 1800 bytes).
that a privileged user in a VMS
system is attempting to
alter RIGHTSLIST.DAT).
become locked out of a UNIX system,
now in single user mode).
are frequent unexplained "beeps").
attempts from another node).
system and accesses file after
file on many user accounts.)
2.6.6 Types and Scope of Incidents
Along with the identification of the incident is the evaluation of the scope and impact of the problem. It is important to correctly identify the boundaries of the incident in order to effectively deal with it and prioritize responses.
In order to identify the scope and impact a set of criteria should be defined which is appropriate to the site and to the type of connections available. Some of the issues include:
phone line, local terminal, etc.)?
The analysis of the damage and extent of the incident can be quite time consuming, but should lead to some insight into the nature of the incident, and aid investigation and prosecution. As soon as the breach has occurred, the entire system and all of its components should be considered suspect. System software is the most probable target. Preparation is key to be able to detect all changes for a possibly tainted system. This includes checksumming all media from the vendor using a algorithm which is resistant to tampering.
Assuming original vendor distribution media are available, an analysis of all system files should commence, and any irregularities should be noted and referred to all parties involved in handling the incident. It can be very difficult, in some cases, to decide which backup media are showing a correct system status. Consider, for example, that the incident may have continued for months or years before discovery, and the suspect may be an employee of the site, or otherwise have intimate knowledge or access to the systems. In all cases, the pre-incident preparation will determine what recovery is
possible.
If the system supports centralized logging (most do), go back over the logs and look for abnormalities. If process accounting and connect time accounting is enabled, look for patterns of system usage. To a lesser extent, disk usage may shed light on the incident. Accounting can provide much helpful information in an analysis of an incident and subsequent prosecution. Your ability to address all aspects of a specific incident strongly depends on the success of this analysis.
Certain steps are necessary to take during the handling of an incident. In all security related activities, the most important point to be made is that all sites should have policies in place. Without defined policies and goals, activities undertaken will remain without focus. The goals should be defined by management and legal counsel in advance.
One of the most fundamental objectives is to restore control of the affected systems and to limit the impact and damage. In the worst case scenario, shutting down the system, or disconnecting the system from the network, may the only practical solution.
As the activities involved are complex, try to get as much help as necessary. While trying to solve the problem alone, real damage might occur due to delays or missing information. Most administrators take the discovery of an intruder as a personal challenge. By proceeding this way, other objectives as outlined in the local policies may not always be considered. Trying to catch intruders may be a very low priority, compared to system integrity, for example. Monitoring a hacker's activity is useful, but it might not be considered worth the risk to allow the continued access.
2.6.9 Protecting Evidence and Activity Logs
When you respond to an incident, document all details related to the incident. This will provide valuable information to yourself and others as you try to unravel the course of events. Documenting all details will ultimately save you time. If you don't document every relevant phone call, for example, you are likely to forget a significant portion of information you obtain, requiring you to contact the source of information again. At the same time, recording details will provide evidence for prosecution efforts, providing the case moves in that direction. Documenting an incident will also help you perform a final assessment of damage (something your management, as well as law enforcement officers, will want to know), and will provide the basis for later phases of the handling process: eradication, recovery, and follow-up "lessons learned."
During the initial stages of an incident, it is often infeasible to determine whether prosecution is viable, so you should document as if you are gathering evidence for a court case. At a minimum, you should record:
conversation)
system events) to a document custodian.
custodian.
The purpose of containment is to limit the extent of an attack. An essential part of containment is decision making (e.g., determining whether to shut a system down, disconnect from a network, monitor system or network activity, set traps, disable functions such as remote file transfer, etc.).
Sometimes this decision is trivial; shut the system down if the information is classified, sensitive, or proprietary. Bear in mind that removing all access while an incident is in progress obviously notifies all users, including the alleged problem users, that the administrators are aware of a problem; this may have a deleterious effect on an investigation. In some cases, it is prudent to remove all access or functionality as soon as possible, then restore normal operation in limited stages. In other cases, it is worthwhile to risk some damage to the system if keeping the system up might enable you to identify an intruder.
This stage should involve carrying out predetermined procedures. Your organization or site should, for example, define acceptable risks in dealing with an incident, and should prescribe specific actions and strategies accordingly. This is especially important when a quick decision is necessary and it is not possible to first contact all involved parties to discuss the decision. In the absence of predefined procedures, the person in charge of the incident will often not have the power to make difficult management decisions (like to lose the results of a costly experiment by shutting down a system). A final activity that should occur during this stage of incident handling is the notification of appropriate authorities.
Once the incident has been contained, it is time to eradicate the cause. But before eradicating the cause, great care should be taken to collect all necessary information about the compromised system(s) and the cause of the incident as they will likely be lost when cleaning up the system.
Software may be available to help you in the eradication process, such as anti-virus software. If any bogus files have been created, archive them before deleting them. In the case of virus infections, it is important to clean and reformat any media containing infected files. Finally, ensure that all backups are clean. Many systems infected with viruses become periodically re-infected simply because people do not systematically eradicate the virus from backups. After eradication, a new backup should be taken.
Removing all vulnerabilities once an incident has occurred is difficult. The key to removing vulnerabilities is knowledge and understanding of the breach.
It may be necessary to go back to the original distribution media and re-customize the system. To facilitate this worst case scenario, a record of the original system setup and each customization change should be maintained. In the case of a network-based attack, it is important to install patches for each operating system vulnerability which was exploited.
If a particular vulnerability is isolated as having been exploited, the next step is to find a mechanism to protect your system. The security mailing lists and bulletins would be a good place to search for this information, and you can get advice from incident response
teams.
Once the cause of an incident has been eradicated, the recovery phase defines the next stage of action. The goal of recovery is to return the system to normal. In general, bringing up services in the order of demand to allow a minimum of user inconvenience is the best practice. Understand that the proper recovery procedures for the system are extremely important and should be specific to the site.
Once you believe that a system has been restored to a "safe" state, it is still possible that holes, and even traps, could be lurking in the system. One of the most important stages of responding to incidents is also the most often omitted, the follow-up stage. In
the follow-up stage, the system should be monitored for items that may have been missed during the cleanup stage. It would be prudent to utilize some of the tools mentioned in chapter 7 as a start. Remember, these tools don't replace continual system monitoring and good systems administration practices.
The most important element of the follow-up stage is performing a postmortem analysis. Exactly what happened, and at what times? How well did the staff involved with the incident perform? What kind of information did the staff need quickly, and how could they have gotten that information as soon as possible? What would the staff do differently next time?
After an incident, it is prudent to write a report describing the exact sequence of events: the method of discovery, correction procedure, monitoring procedure, and a summary of lesson learned. This will aid in the clear understanding of the problem. Creating a formal chronology of events (including time stamps) is also important for legal reasons.
2.6.14 Aftermath of an Incident
In the wake of an incident, several actions should take place. These actions can be summarized as follows:
(i.e., a careful examination should
determine how the
system was affected by the incident).
should be included in revised security
plan to
prevent the incident from re-occurring.
incident.
deemed desirable.
The whole purpose of this post mortem process is to improve all security measures to protect the site against future attacks. As a result of an incident, a site or organization should gain practical knowledge from the experience. A concrete goal of the post mortem is to develop new proactive methods. Another important facet of the aftermath may be end user and administrator education to prevent are occurrence of the security problem.
2.7 Intrusion Management Summary
Intrusion management is a four-step process. The steps are avoidance, assurance, detection and investigation. Intrusion management has as its objective:
The first step in the Intrusion Management process is Avoidance. Avoidance includes all of those underlying processes that seek to create a secure environment. Some examples of Avoidance are:
The second step is Assurance. Assurance includes everything we do to ensure that policies, standards and practices are being followed. These processes include:
In broad terms, we may consider that type of monitoring to be an audit function. Thus, we see that auditing is an important part of the intrusion management process. However, many organizations have subdivided the monitoring function between Information Security and IT Auditing. The security personnel monitor on a full time basis, while audits occur periodically to ensure that monitoring is effective. How your organization splits these tasks, or if they split them at all, is probably a function of organization size and resources.
The third step is Detection. This is somewhat different from the detective controls present during the avoidance and testing steps. In this case we are talking about detecting an intrusion attempt in real time. The real time aspect of detection is important. Knowing that an attack is in progress and being able to take immediate action greatly improves the odds of successfully terminating the intrusion and apprehending the perpetrator.
Real time detection depends upon having a "watch dog" system that sits in the background and watches all activities involving the device under surveillance. The watch dog also must be able to interpret what constitutes an attack.
Finally, intrusion management defaults to Investigation when all other measures have failed to prevent an attack. However, investigation, as you may have already gathered, may be futile unless luck and circumstances are with you. By integrating your investigation process into the intrusion management process you improve your odds markedly because you have gathered significant important information and make critical preparations along the way.
Attacks often are not discovered until well after the fact. That problem constitutes strike one in the intrusion management ball game. Strike two comes when the attacker has been clever enough to cover his or her tracks effectively. If the logs are not complete, protected from tampering and retained long enough, it's strike three and your investigation never gets to first base.
Investigations of security incidents, whether they are successful or simply strong attempts, should be undertaken by the organization's Computer Incident Response Team (CIRT). The CIRT should be trained and prepared to initiate a formal investigation, present results to management, support litigation or criminal prosecution if necessary, and ensure that lessons learned are fed back into the Intrusion Management process.
Good intrusion management mitigates against all of the problems surrounding an investigation and ensures you a chance to start around the bases. Whether you get an eventual home run, of course, depends upon many other factors. If you think of the Intrusion Management process as a circle, the results of investigations feed back into the start of the process: Avoidance. By taking advantage of "lessons learned" we help improve the odds against additional successful attacks.
2.8.0 Modem Lines Must Be Managed
Although they provide convenient access to a site for its users, they can also provide an effective detour around the site's firewalls. For this reason it is essential to maintain proper control of modems.
Don't allow users to install a modem line without proper authorization. This includes temporary installations (e.g., plugging a modem into a facsimile or telephone line overnight). Maintain a register of all your modem lines and keep your register up to date. Conduct regular (ideally automated) site checks for unauthorized modems.
The reality at most companies is that there are more and more laptop computers being used on desktops. Practically every one of them has a MODEM either built-in or in a PCCARD slot. This means the number of actual MODEMs in corporate networks is growing dramatically without the care and security require of such installations. It is ludicrous to think that they can be eliminated, but it is also important to set policies and technology in place to ensure that the desktop MODEM installed on a laptop does not become the back-door entry point into a corporate network.
2.8.1 Dial-in Users Must Be Authenticated
A username and password check should be completed before a user can access anything on your network. Normal password security considerations are particularly important.
Remember that telephone lines can be tapped, and that it is quite easy to intercept messages to cellular phones. Modern high-speed modems use more sophisticated modulation techniques, which makes them somewhat more difficult to monitor, but it is prudent to assume that hackers know how to eavesdrop on your lines. For this reason, you should use one-time passwords if at all possible.
It is helpful to have a single dial-in point (e.g., a single large modem pool) so that all users are authenticated in the same way.
Users will occasionally mis-type a password. Set a short delay – say two seconds - after the first and second failed logins, and force a disconnect after the third. This will slow down automated password attacks. Don't tell the user whether the username, the password, or both, were incorrect.
Remember that MODEMs on inside computers
can be accessed from outside. Often, users will install remote access software
on the office system that allows the user to remotely connect to the desktop
system from a remote site. Packages like Rapid Remote, PC Anywhere, Carbon
Copy and many others allow this capability. These packages, while capable
of implementing passwords, typically do NOT as users find them irritating.
Programs such as war dialers allow the hacker to find these active systems
and attempt connection with compatible programs and take over the internal
system. With this method, it’s not difficult to infitrate a network and
gain access to valuable corporate computing assets.
Some dial-in servers offer call-back facilities (i.e., the user dials in and is authenticated, then the system disconnects the call and calls back on a specified number). Call-back is useful since if someone were to guess a username and password, they are disconnected, and the system then calls back the actual user whose password was cracked; random calls from a server are suspicious, at best. This does mean users may only log in from one location (where the server is configured to dial them back), and of course there may be phone charges associated with there call-back location.
This feature should be used with caution; it can easily be bypassed. At a minimum, make sure that the return call is never made from the same modem as the incoming one. Overall, although call-back can improve modem security, you should not depend on it alone.
2.8.3 All Logins Should Be Logged
All logins, whether successful or unsuccessful should be logged. However, do not keep correct passwords in the log. Rather, log them simply as a successful login attempt. Since most bad passwords are mistyped by authorized users, they only vary by a single character
from the actual password. Therefore if you can't keep such a log secure, don't log it at all.
If Calling Line Identification is available, take advantage of it by recording the calling number for each login attempt. Be sensitive to the privacy issues raised by Calling Line Identification. Also be aware that Calling Line Identification is not to be trusted (since intruders have been known to break into phone switches and forward phone numbers or make other changes); use the data for informational purposes only, not for authentication.
2.8.4 Choose Your Opening Banner Carefully
Many sites use a system default contained in a message of the day file for their opening banner. Unfortunately, this often includes the type of host hardware or operating system present on the host. This can provide valuable information to a would-be intruder. Instead, each site should create its own specific login banner, taking care to only include necessary information.
Display a short banner, but don't offer an "inviting" name (e.g., University of XYZ, Student Records System). Instead, give your site name, a short warning that sessions may be monitored, and a username/password prompt. Verify possible legal issues related to
the text you put into the banner.
For high-security applications, consider using a "blind" password (i.e., give no response to an incoming call until the user has typed in a password). This effectively simulates a dead modem.
Dial-out users should also be authenticated, particularly since your site will have to pay their telephone charges.
Never allow dial-out from an unauthenticated dial-in call, and consider whether you will allow it from an authenticated one. The goal here is to prevent callers using your modem pool as part of a chain of logins. This can be hard to detect, particularly if a hacker sets up a path through several hosts on your site.
At a minimum, don't allow the same modems and phone lines to be used for both dial-in and dial-out. This can be implemented easily if you run separate dial-in and dial-out modem pools.
2.8.6 Make Your Modem Programming as "Bullet-proof" as Possible
Be sure modems can't be reprogrammed while they're in service. At a minimum, make sure that three plus signs won't put your dial-in modems into command mode!
Program your modems to reset to your standard configuration at the start of each new call. Failing this, make them reset at the end of each call. This precaution will protect you against accidental reprogramming of your modems. Resetting at both the end and the beginning of each call will assure an even higher level of confidence that a new caller will not inherit a previous caller's session.
Check that your modems terminate calls cleanly. When a user logs out from an access server, verify that the server hangs up the phone line properly. It is equally important that the server forces logouts from whatever sessions were active if the user hangs up unexpectedly.
Customer organizations require that scientists, management, sales and other personnel be able to remotely access systems on the customer network. This is frequently done via dial-up phone lines through MODEMs and via X.25 public data network (PDN) terminal connection from other locations in the U.S. and around the world.
Because of the common use of MODEMs and the relatively low expense, it is simple for anyone to acquire and use MODEM technology to dial-up and connect to any system that supports MODEM connectivity. This supports the ability for criminals and competitive elements to acquire technology to infiltrate computer and network systems and engage in illegal or, at a minimum, highly annoying activities centered around the ability to disrupt operations, steal information , etc.
2.9.0 Classes of Security Access Packaged for MODEM Access
In the security access business, there are the following types of systems available for providing differing levels of security facilities for dial-up MODEM access:
2.9.1 Tactical and Strategic Issues in Selecting a MODEM Connection Solution
In most sites considering dial-up facilities, the need is real and is not going away. Many companies are becoming more mobile and the need for remote dial-up access is becming critical. It is estimated in 1999 that over 60% of all computers that will be sold will be notebook sized or smaller. This, coupled with the trend towards docking-station systems that can be moved at will, provides a market for remote access that is growing dramatically and does not show any signs of diminishing. Further, practically all consumer-level computers come equipped with a 56kbps V.90 MODEM.
Where most sites fail in their tactical and strategic planning for such facilities is in the expectation that they can contain the requirement for dial-up and that they can dictate the user's options. What happens in many situations is the users will implement their own solutions and not provide any feedback to IT facilities until it has become firmly entrenched in the deliverable solutions for management. As a result, the opportunity to control the unauthorized facilities is reduced to nil and the IT groups must deal with a myriad of dial-up options based upon what was planned and what happened "on its own."
From a tactical perspective, it is better to provide the solution in a manner that is acceptable to the users before they have the opportunity to circumvent the dial-up solution with a substandard solution that will be incorporated due to default access. If dial-up solutions are in place, it is tactically wise to implement substitute solutions that provide the following features:
From a strategic perspective, companies need to consider what dial-up protocols will be required, speed of access to remote facilities and eventual hardware facilities that will be used on internal and external networks. Many companies will start off with LAN technologies such as Ethernet/802.3 and token ring/802.5 networks and eventually implement 100mbps LAN/MAN technologies such as FDDI. This eventually leads to the inevitable implementation of ISDN-B, ATM and SONET access. Any remote access facility needs to be upgradeable to these environments as the company requirement grow.
Of importance in the selection of any solution is the realization that MODEMs are, technologically, on the way out as digital communications replace analog facilities in the phone systems of the world. Some telecommunications providers already provide direct ISDN and ISDN-B facilities which allow a technology called unbundled ISDN services. In this offering, the local equipment company (the LEC), provides a T1 connection to the customer site, divided into 24 separate 56kbps digital channels. At the LEC, MODEM emulation is provided to a dial-up user which is converted to a digital channel access to one of the channels to the customer. The effect is that the customer does not need to purchase any MODEMs, the user population can use existing MODEM technologies and when the phone system goes pure digital in the future, there are no corporate MODEM banks to replace. Since the trend is to go digital, the need to support ISDN, ISDN-B and ATM is crucial for long term user satisfaction and in the support of alternate connection technologies in the future.
2.9.2 Background on User Access Methods and Security
To access any system via terminal, a user is expected to enter, as a minimum, some type of user identification (such as as user ID, username, or some other identifier), a password, and other optional login information as may be required by the systems or network manager. In some situations, an additional "system" password is used before the user ID to allow the system to automatically detect access baud rate as well as provide the user the opportunity to enter a general access password in order to gain entry in to the system or front-end being used. To enhance system security for dial-up access, other methods may also be added such as digital ID cards, dial-back MODEMs that reconnect the user to the system after the system dials the user back, and other types of electronic equipment security denial or restricted access methods.
Some of the security flaws with this level of access in the general systems area are:
With the rise of computer crime via dial-up access, there is a natural paranoia that systems professionals are required to recognize: dial-up access makes system access possible for non-authorized individuals and this exposure must be minimized. The reasons for keeping non-authorized individuals out of customer systems include:
Some customers have used dial-back MODEMs and hardware security cards for user terminal access.
The dial-back MODEMs, while previously useful, are now easier to violate due to new phone system facilities offered by regional telephone companies. Facilities such as call forwarding, call conferencing and other facilities that will be offered via Signaling System 7 (SS7) and Integrated Services Digital Network (ISDN) connectivity facilities make the general functionality of dial-back MODEMs easier to violate (dial-back facilities could be re-routed via the phone system to other locations other than the phone number expected and desired) and a total lack of security on the phone network itself helps to propagate this effort.
In recent months, the hackers magazine 2600 has published articles on how to provide remote call-forwarding and how to "hack" public phone switching systems and access a variety of information including call routing tables. With this type of information, potential disruptors of corporate dial-up methods can forward calls to any desired location.
A recent example is that of Kevin Poulsen in California, who successfully "hacked" the local phone switch over a period of two years. The result was interesting. He successfully made his personal phone line the only one able to gain access to radio station lines and busy-ed out all other lines to make himself the winner of numerous phone offers. His winnings included two Porches, two trips to Hawaii and over $22,000.00 in cash. Investigation by the FBI showed that Poulsen accessed much, much more than the stated "hacks" and was charged with a long list of crimes including computer fraud, interception of wire communications, mail fraud, money laundering, obstruction of justice, telecommunications fraud and others. His primary vehicle was access to the telephone switching system, which effectively defeats any type of dial-back facility which depends on the phone system to be "untouched."
Devices such as security identification cards, approximately the size of a credit card and possessing verification algorithms that allow exact identification of a user, are very secure provided that they are not shared between users. They are also somewhat expensive (est. $60.00 per user) and are easily destroyed (sat upon, placed in washing machines, etc.) or lost. Because of accounting problems and the size of the dial-up population, some former employees have left customer’s employ and taken their cards with them making recovery virtually impossible. There are also some terminal connection facilities in which security identification cards will not work and this requires another approach to the problem.
Such cards work by the user entering a number when prompted by the destination system, in a specified amount of time, that is visible in an LCD window in the card. This number is synchronized with the destination system and, algorithmically, the number should decypher to a valid combination the system will accept.
Another type of security access method, called a token card, works on the concept that the card cannot possibly be in any one else's possession. This is accomplished by installation of token hardware and software in notebook computers and, in some cases, in the inclusion in operating system ROMs on the motherboard of the remote system. While secure and the loss levels are low, the costs are serious and severely restrict the types of remote systems that may access a centralized dial-up method as well as the type of dial-up or remote access method available.
In many circumstances there is the problem of identifying who has left the firm (and when) so that their security card information may be removed from the access database. At present, there are former customer employees that have left their firms some time ago and are still identified as being active users in the security card database. While this is mostly an accounting and tracking problem, there is no automated "user X has not logged in via dial-up in Y amount of time" facilities to allow tracking of user activity levels.
Even with proper accounting and user tracking, there is a recurring expense required for the use of security identification cards (replacements, failed units, damaged units, etc.) and this is growing due to the number of people desiring access to the system resources at customer sites.
A major problem with security cards and token cards is the problem of user accounting and session tracking. Many products provide a method by which users may be accounted for in terms of access time and line identification, but that is about it. There are no investigative tracking facilities, session tracking facilities, session capture (for the extreme cases), user profiling and many other required features for proper investigation of penetrations or improper activities.
What consumers require is an easy-to-use secure dial-up access method that allows different types of terminal connection platforms (dial-up async, sync, X.29 dynamic PAD access, etc.) to customer system resources. Further, the system must use off-the-shelf hardware to keep the short and long term costs of dial-up low and support multiple terminal protocol facilities. Finally, the interface must have logging and auditing facilities useful in user tracking and user access abnormality detection by monitoring user activity profiles and reporting such information to systems personnel for action.
2.9.3 Session Tracking and User Accounting Issues
In any dial-up solution, there is the need to provide reports on user access, where the user connected and rudimentary reporting of times, activity levels and dates of access for accounting facilities.
Where many companies find problems after implementation are the issues of tracking down breaches of security or monitoring specific user activities for users performing activities that are considered counterproductive to corporate goals or illegal. Even if the system is successful in keeping out unwanted intruders, many company security breaches are from employees or contractors working within the company facilities. Tracking of activities is important when attempting to isolate internal breaches, the most common type, and when trying to isolate illegal activities.
Tracking may be done in a variety of manners. The easiest is when the system is set up to detect deviations from established access and activity patterns and reports alarms on deviations. Unfortunately, setting up such facilities is non-trivial in larger dial-up environments where there may be hundreds or thousands of accounts. What is needed is software facilities that will establish a normalization baseline on a user-by-user basis and then provide a method to report anomalies and deviations from established operations.
Once the dial-up system has detected deviations, reporting and session management/capture facilities need to be activated to properly identify user actions and track activities to the keystroke level. This provides a chain of evidence of malfeasance and can be used to procecute a malicious user or to prove the innocence of falsely accused users. Evidence is essential in any security breach or suspected misuse of system and network resources. Keeping people off of systems is not terribly difficult and there are well established manners in which this is done. Tracking them, developing a reliable trail of activity patterns and evidence that may be used for procecution is difficult and the system has to be designed from the start to provide this level of information.
Reporting for user access needs to be very dynamic for the production of accounting report for chargeback and also
2.9.4 Description of Proposed Solution to Dial-Up Problem
The author, has implemented various types of secure access systems for various types of customers requiring dial-up network access without using dial-back MODEMs. The most productive and flexible method to do this is to use an intermediate network connection to provide connectivity and access services. This may be accomplished through the use of a local Ethernet, terminal servers, and a small 32-bit or 64-bit system to provide dial-up connection authorization. Graphically, the connection path would appear as follows:
Figure 1: Architectural Drawing of Secure Front-End Simple Configuration
In a typical usage scenario, users dial up to a customer specified phone number pool with V.32bis, V.34, V.90 or similar MODEMs (this allows 300 through 56Kbps async dial-up). The number pool, due to the nature of the software, could be a toll-free access number (800-type in the U.S. and Canada) or a connection number and ID on a public data network (X.25/X.29). The security access server(s) would then automatically connect the user to special login security software that would ask for a username, password, and any other type of required information. In this manner, should it be necessary, a terminal emulation request, an asynchronous protocol connection (such as PPP, SLIP or async AppleTalk) could be authorized or other type of connection protocol. Following authorization and authentication of the user over the dial-up connection, the security system software would connect the dialed-up user to a system on the main Ethernet backbone at the customer’s site. This would allow the secure access server system to provide very specific connection facilities on a user-by-user basis and at the system and network manager’s discretion. Based upon previous implementations at other facilities, this type of connectivity would prove useful to customers where security is a serious concern and yet remote access to the network and systems thereon is essential to fulfilling corporate needs and goals.
Positive-acknowledgement systems, also sometimes called extended user authorization systems (EUAS), are those that require user action to initiate connection to or from a system. In the case of most customer sites, the system will require the user to provide positive identification via the following methods:
As a side issue, a successful network break-in in France’s PTT Minitel videotex system was accomplished by using a PC to emulate card key access. The PC was a portable laptop and the program was written in Turbo C, a common and inexpensive compiler. This has caused proponents of card and digital signature access to re-think how the formats of data are provided from the card access method.
2.9.5 Dissimilar Connection Protocols Support
One feature of remote access facilities are their ability to connect to remote systems via network or async connection(s). The user may log in to the remote access system and then be connected to a networked system on the corporate network in a variety of ways.
Because of the manner in which terminal session management is done, some remote access systems are capable of acting similar to a terminal "gateway" between protocol types. This means that a user may connect via dial-up to the remote access system and then request an SNA terminal connection to a mainframe. A user from a remote UNIX system may connect with Telnet via the network to the remote access system and then be re-connected by the system to an Alpha AXP system using DECnet’s CTERM protocol.
2.9.6 Encryption/Decryption Facilities
Some remote access systems use the ANSI Data Encryption Standard (DES) for encryption and decryption of files in U.S. installations and an exportable hashing algorithm for installations outside the U.S. This is due to exportation of encryption technologies laws in the U.S. and is not a reflection on the vendor's desire for customers in the international marketplace to have less secure installations than those in the U.S. The vendors in the U.S. have no control over this law and must comply.
Some remote access products do not store sensitive files on disk in an unencrypted manner. All screen captures, user information and other files that are sensitive in nature are encrypted in real-time and stored on disk in an encrypted form. Should files be backed-up and moved to another system, the files will be unintelligible when printed or sent to a terminal screen.
Remote access products with session and information capturing facilities have the ability for a system manager to store captured data for a user in a file. When stored, the file buffers are encrypted prior to being written to disk. If the system manager wishes to view the file, the file is retrieved from disk and decrypted "on-the-fly" and viewed with a special encrypt/decrypt editor.
2.9.7 Asynchronous Protocol Facilities
Secure remote access servers often provide the ability for the system manager to set up specific user accounts for asynchronous DECnet access, TCP/IP's SLIP protocol, asynchronous AppleTalk and others. The user must go through the standard security login dialog and, when the user has been authenticated, the line is automatically modified and converted to an asynchronous protocol port. Some systems allow multiple protocol access and a user menu may be provided for access to various protocol services.
2.9.8 Report Item Prioritization
One of the more aggravating items in generation of reports is having to wade through the amount of paper generated to find truly significant events and take appropriate action.
Some remote access servers allow the system manager to set priorities (critical, urgent and routine) on various data items in the system. In this manner, as security exception reports are generated they may be printed in priority order. When a security exception report is read by the systems or security manager, the report may be organized such that high-priority items are at the beginning of the report, precluding a search operation to find what is truly important in the report.
2.9.9 User Profile "Learning" Facility
When designing secure remote access servers, the author found that one of the worst situations was the lack of knowledge of who logged in to systems "when." While some operating system environments could allow the system manager the flexibility to specify login times to be at specific times of the day, these facilities are very rarely used as it was deemed too difficult to set up and figure out what times of the day the user is active.
Some systems now have an autoprofiling feature, which may be enabled for the entire system or on a user-by-user basis. This allows the secure access server to "learn" how a user interacts with systems on the network. The secure access server collects activity levels and time of day parameters, stores them and sets up, automatically, an activity profile for the user. If the user attempts to log in to the secure access system at times not specified by the profile, access is denied. Further, if operating parameters during a login session exceed the learned "norm," the user may be disconnected. Obviously, there are user-by-user overrides available to the system manager that may be set-up to allow individual user flexibility. For large user count sites, this feature has proven to be very valuable and allows establishment of activity patterns and detection of abnormalities (this is the first step to detecting illicit connectivity).
What security measures can you implement today? and further down the road?
*Always re-examine your network security policy to see if your objectives and network circumstances have changed. (every 6 months is ideal.)
NIST Checklist for functions to consider when developing a security system The National Institute for Standards and Technology (NIST) has developed a list for what they refer to as Minimal Security Functional Requirements for Multi-User Operational Systems. The major functions are listed below.
Making sure your security measures work is imperative to successfully securing your data and users. You have to make sure you know who is doing what on the network. Components of a good audit will include;
1. A log of all attempts to gain access to the system.
2. A chronological log of all network activity.
3. Flags to identify unusual activity
and variations from established procedures.
2.10.2 Evaluating your security policy
1. Does your policy comply with law and with duties to third parties?
2. Does your policy compromise the interest of your employees, your company or third parties?
3. Is your policy practical, workable and likely to be enforced?
4. Does your policy address all of the different forms of communication and record keeping within your organization?
5. Has your policy been properly presented and agreed to by all concerned parties?
With adequate policies, passwords, and precautions in place, the next step is to insist that every vender, supplier, and consultants with access to your system secure their computers as adequately as you secure yours. Also, work with your legal department or legal advisors to draft a document that upon signing it would recognize that the data they are in contact with is yours.
One of the most critical security issues, one that has been compounded by the micro and LAN/WAN revolution, is a lack of awareness, by executives and users, to the vulnerability of their critical and sensitive information. Microcomputers have unique security problems that must be understood for effective implementation of security measures. These problems include;
Several approaches need implementing in order to provide the necessary security for microcomputers.
An increasing problem in most organizations is microcomputer and/or component theft involving personnel within the company as well as outsiders. Some of these components are easy to carry away in a purse, briefcase, or coat pocket. Organizations that lack accurate or current inventories of their PC equipment, components and peripherals are the most vulnerable.
A situation similar to automobile "chop shops" has become prevalent in the PC industry. Black market sales of "hot" PC parts are costing corporate America over $8 billion a year.
Things to consider in regards to system security
Viruses have left a number of corporations sadder but all the wiser. A virus can change data within a file, erase a disk, or direct a computer to perform system-slowing calculations. Viruses may be spread by downloading programs off of a bulletin board, sharing floppy diskettes, or communicating with an infected computer through a network, by telephone or through the Internet. Anti-virus products are a necessity for the detection, eradication and prevention of viruses. In addition, micro security policy should define permissible software sources, bulletin board use, and the types of applications that can be run on company computers. The policy should also provide standards for testing unknown applications and limit diskette sharing.
Data Residue is data that is stored on erased media. Such data can often be read by subsequent users of that media. This presents a danger in sharing files on diskettes that once contained sensitive or confidential data. This problem also exists for hard drives. One solution available to companies is the use of degausser products. Primarily used by the US government, corporate America is now finding these effective tools for preventing the disclosure of sensitive information.
Restrict physical access to hosts, allowing access only to those people who are supposed to use the hosts. Hosts include "trusted" terminals (i.e., terminals which allow unauthenticated use such as system consoles, operator terminals and terminals dedicated to special tasks), and individual microcomputers and workstations, especially those connected to your network. Make sure people's work areas mesh well with access restrictions; otherwise they will find ways to circumvent your physical security (e.g., jamming doors open).
Keep original and backup copies of data and programs safe. Apart from keeping them in good condition for backup purposes, they must be protected from theft. It is important to keep backups in a separate location from the originals, not only for damage considerations, but also to guard against thefts.
Portable hosts are a particular risk. Make sure it won't cause problems if one of your staff's portable computer is stolen. Consider developing guidelines for the kinds of data that should be allowed to reside on the disks of portable computers as well as how the data should be protected (e.g., encryption) when it is on a portable computer.
Other areas where physical access should be restricted is the wiring closets and important network elements like file servers, name server hosts, and routers.
2.12.1 Walk-up Network Connections
By "walk-up" connections, we mean network connection points located to provide a convenient way for users to connect a portable host to your network.
Consider whether you need to provide this service, bearing in mind that it allows any user to attach an unauthorized host to your network. This increases the risk of attacks via techniques such as IP address spoofing, packet sniffing, etc. Users and site management must appreciate the risks involved. If you decide to provide walk-up connections, plan the service carefully and define precisely where you will provide it so that you can ensure the necessary physical access security.
A walk-up host should be authenticated before its user is permitted to access resources on your network. As an alternative, it may be possible to control physical access. For example, if the service is to be used by students, you might only provide walk-up connection sockets in student laboratories.
If you are providing walk-up access for visitors to connect back to their home networks (e.g., to read e-mail, etc.) in your facility, consider using a separate subnet that has no connectivity to the internal network.
Keep an eye on any area that contains unmonitored access to the network, such as vacant offices. It may be sensible to disconnect such areas at the wiring closet, and consider using secure hubs and monitoring attempts to connect unauthorized hosts.
2.13 RCMP Guide to Minimizing Computer Theft
Increasingly, media reports bring to light incidents of thefts occurring in offices at any time of the day or night. Victims include government departments, the private sector and universities in Canada and in the United States. The targets: computers and computer components. Perpetrators include opportunists, petty thieves, career criminals, organized gangs, people legally in contact with the products, e.g. transportation and warehouse workers, as well as individuals working in the targeted environment.
While incidents of this nature have increased dramatically in the last few years, the number of reported incidents reflect only a portion of the total number of occurrences. One reason for this is that government institutions, the private sector and universities alike are often reluctant to report such incidents, for fear they’ll be ridiculed or that their operations will be negatively affected.
Advances in electronics and the miniaturization of components have provided thieves with ideal targets — expensive items that are easily concealable, readily marketable and hard to trace. Components can be transferred from thief to middleman to a distributor without anyone knowing they are stolen. Items such as cellular phones, laptops, integrated circuits, electronic cards, disk drives and CD-ROMs have become the target of choice of both novice thieves and career criminals.
This publication identifies the primary
areas of vulnerability that may lead to loss of assets (computer components)
and proposes safeguards designed to minimize the risks of losing these
components. Samples of physical security devices are described, and strategies
are offered for minimizing computer and component theft.
2.13.1 Areas of Vulnerability and Safeguards.
Minimizing Perimeter Security Vulnerabilities
Examining the perimeter security of a building is the first step and involves establishing appropriate safeguards, through target hardening. Target hardening is the process of setting up a series of physical barriers (protection) to discourage an adversary’s progress. The objective is to have an adversary either give up the idea of an attack, give up during the attack, or take enough time for a response force to react to the attack before its completion. A building’s entrances exits and trade entrances are vulnerable areas that should be the focal point for enhanced perimeter security.
The following checklist can help determine the security posture of the perimeter:
Minimizing Vulnerabilities Inside the Facility
Once the building perimeter has been secured, the next important
step is controlling personnel, visitors and equipment entering and exiting
the building. One effective method to maximize the control and usefulness
of security staff is to have all employees and visitors enter the facility
through one entry point, with material entering at another identified entry
point. It is recognized that with high-occupancy or multi-tenant buildings
it may not be practical to have a single entry point. Departments providing
services to the public should be located on the main floor, to limit access
to working areas. Only authorized employees and supervised visitors should
have access to operational areas. All service vehicles should enter the
site through a single vehicle control point. Canteens, lunch rooms and
stores should be designed and situated such that deliveries to and from
such areas do not have to enter the secure perimeter. Every facility should
have a reception zone, accessed directly from the public-access zone, where
visitors, if necessary, wait for service or for permission to proceed to
an operational or secure zone. If this process cannot be accommodated then
each floor must be secured. Other security vulnerabilities include the
improper use of a guard force and granting unlimited access to all areas
of the building’s working or technical areas, e.g, electrical and telephone
rooms.
Examples of Enhanced Safeguards Inside a Facility
Minimizing Vulnerabilities Using Physical Security Devices
Physical security devices are another method of preventing unauthorized use, intentional damage or destruction, or theft of computer equipment and components.
Many different devices are available on the market, including alarms, locks, cabinets, cable kits, lock-down plates and special security screws. One company has marketed theft retrieval software that notifies police of a stolen PC’s whereabouts. The use of security seals tamper-evident labels and ultraviolet detection lamps is also being implemented.
The RCMP has not endorsed these products, other than containers, because the majority have not been tested to evaluate their effectiveness. Some of the products may be useful, but may not be cost-effective. In many instances, it is more cost-effective to protect the working area than it is to tie down or alarm each PC.
Labelling, engraving and ultraviolet detection is time-consuming to implement; and inventory has to be kept up-to-date. In addition, there is little to indicate that these methods will reduce thefts. Laptops and portable computers are usually stolen for personal use or for resale. The buyer knows the item has been stolen but is willing to take the chance of receiving stolen goods because of the low price and the improbability of being caught.
2.13.2.0 Examples of Safeguards
Cabinets enclose the
entire computer, including the monitor, keyboard, printer and CPU. Cabinets
are usually metal or composite materials, making them difficult to break
into. Information on approved cabinets is available from Public Works and
Government Services Canada.
Alarms are installed either inside or outside each CPU unit. The alarms do not prevent the theft of computer equipment but they usually act as a deterrent. In addition, people in the vicinity or at a central location are alerted by a loud piercing sound if the equipment is moved or if the alarm is tampered with.
Anchoring pads and cables are used to anchor devices to desks and tabletops, using high-strength adhesive pads or cables. Once the pad is installed on the table or desk, it is very difficult to remove, and the adhesive usually ruins the finish. Cables are probably the most common physical securing devices, and the least expensive. Steel cables are passed through metal rings that are attached to the equipment and a desk or table. Although cables prevent anyone from quickly walking away with a piece of equipment, they can be cut. Another anchoring method is the use of steel locking plates and cables to secure a variety of computer components and office equipment to desks or tables. The bottom plate is either bolted to the desk or fastened with adhesive. The top and bottom plates slide together and are secured with a high-security lock.
Secure lid locks help prevent intrusion into PC servers and routers and protect microprocessors and memory chips. The metal construction is crushproof, with no adhesive or cables to damage the equipment.
Secure drive locks prevent the introduction of external viruses to PCs and networks, avert the removal of sensitive corporate files by unauthorized individuals, deter the introduction of unauthorized software to PCs and networks and prevent booting from the floppy drive.
Security software uses anti-theft retrieval encryption stealth technology to locate stolen computers. Upon a customer’s report of computer theft, the company initiates its tracking feature. As soon as the stolen computer is connected to a telephone line, the software turns off the modem’s speaker and silently dials the company’s tracking line, giving the PC’s current location. The company then informs law enforcement officials, who can obtain a search warrant and retrieve the computer.
2.13.3 Strategies to Minimize Computer Theft
Computer theft cannot be eliminated, but can be reduced by implementing a few simple strategies.
2.13.3.0 APPOINTMENT OF SECURITY PERSONNEL
Departments must appoint a departmental security officer (DSO). The DSO should have direct access to the deputy head to report probable security breaches and illegal acts, as warranted and in accordance with the DSO’s mandate. The DSO is responsible for developing, implementing, maintaining, coordinating and monitoring a departmental security program.
An appropriate master key system must be developed, and comply with the following guidelines:
Minimizing Vulnerabilities Through Target Hardening
Target hardening creates an environment, which makes it difficult for the aggressor to reach a target. The goal of target hardening is to prevent a successful attack through the use of barriers to reduce the adversary’s speed of progress, leading to the adversary either giving up the idea of an attack, or taking enough time that a response force can react.
Examples of Enhanced Target Hardening Safeguards
2.13.4.0 Minimizing Vulnerabilities Through Personnel Recognition
A personnel recognition system is based on the visual identification of individuals known to authorized personnel or control staff. This system depends solely on personal knowledge of the individuals having access to a particular facility or zone. For this system to be effective, it is necessary to comply with the following guidelines:
Departments using ID cards or authorization badges must develop procedures for their use, including:
The Security Policy of the Government of Canada (GSP) requires that departments implement a security awareness program for all personnel, to define their security responsibilities. Security awareness training is an essential element of a comprehensive and effective security program. Such training is a continuing series of activities, with two overall objectives:
2.13.5.1 Security Awareness Safeguards
Computer theft cannot be eliminated, but departments can greatly reduce it by following these simple rules:
2.14 Physical and Environmental Security
The term physical and environmental security, as used in this chapter, refers to measures taken to protect systems, buildings, and related supporting infrastructure against threats associated with their physical environment. Physical and environmental security controls include the following three broad areas:
Physical access controls restrict the entry and exit of personnel (and often equipment and media) from an area, such as an office building, suite, data center, or room containing a LAN server.
The controls over physical access to the elements of a system can include controlled areas, barriers that isolate each area, entry points in the barriers, and screening measures at each of the entry points. In addition, staff members who work in a restricted area serve an important role in providing physical security, as they can be trained to challenge people they do not recognize.
Physical access controls should address not only the area containing system hardware, but also locations of wiring used to connect elements of the system, the electric power service, the air conditioning and heating plant, telephone and data lines, backup media and source documents, and any other elements required system's operation. This means that all the areas in the building(s) that contain system elements must be identified.
It is also important to review the effectiveness of physical access controls in each area, both during normal business hours, and at other times particularly when an area may be unoccupied. Effectiveness depends on both the characteristics of the control devices used (e.g., keycard-controlled doors) and the implementation and operation. Statements to the effect that "only authorized persons may enter this area" are not particularly effective. Organizations should determine whether intruders can easily defeat the controls, the extent to which strangers are challenged, and the effectiveness of other control procedures. Factors like these modify the effectiveness of physical controls.
The feasibility of surreptitious entry also needs to be considered. For example, it may be possible to go over the top of a partition that stops at the underside of a suspended ceiling or to cut a hole in a plasterboard partition in a location hidden by furniture. If a door is controlled by a combination lock, it may be possible to observe an authorized person entering the lock combination. If keycards are not carefully controlled, an intruder may be able to steal a card left on a desk or use a card passed back by an accomplice.
Corrective actions can address any of the factors listed above. Adding an additional barrier reduces the risk to the areas behind the barrier. Enhancing the screening at an entry point can reduce the number of penetrations. For example, a guard may provide a higher level of screening than a keycard-controlled door, or an anti-passback feature can be added. Reorganizing traffic patterns, work flow, and work areas may reduce the number of people who need access to a restricted area. Physical modifications to barriers can reduce the vulnerability to surreptitious entry. Intrusion detectors, such as closed-circuit television cameras, motion detectors, and other devices, can detect intruders in unoccupied spaces.
Building fires are a particularly important security threat because of the potential for complete destruction of both hardware and data, the risk to human life, and the pervasiveness of the damage. Smoke, corrosive gases, and high humidity from a localized fire can damage systems throughout an entire building. Consequently, it is important to evaluate the fire safety of buildings that house systems. Following are important factors in determining the risks from fire.
Each of these factors is important when estimating the occurrence rate of fires and the amount of damage that will result. The objective of a fire-safety program is to optimize these factors to minimize the risk of fire.
2.14.2 Failure of Supporting Utilities
Systems and the people who operate them need to have a reasonably well controlled operating environment. Consequently, failures of heating and air-conditioning systems will usually cause a service interruption and may damage hardware. These utilities are composed of many elements, each of which must function properly.
For example, the typical air-conditioning system consists of:
This same line of reasoning applies to electric power distribution, heating plants, water, sewage, and other utilities required for system operation or staff comfort. By identifying the failure modes of each utility and estimating the MTBF and MTTR, necessary failure threat parameters can be developed to calculate the resulting risk. The risk of utility failure can be reduced by substituting units with lower MTBF values. MTTR can be reduced by stocking spare parts on site and training maintenance personnel. And the outages resulting from a given MTBF can be reduced by installing redundant units under the assumption that failures are distributed randomly in time. Each of these strategies can be evaluated by comparing the reduction in risk with the cost to achieve it.
A building may be subjected to a load greater than it can support. Most commonly this is a result of an earthquake, a snow load on the roof beyond design criteria, an explosion that displaces or cuts structural members, or a fire that weakens structural members. Even if the structure is not completely demolished, the authorities may decide to ban its further use, sometimes even banning entry to remove materials. This threat applies primarily to high-rise buildings and those with large interior spaces without supporting columns.
While plumbing leaks do not occur every day, they can be seriously disruptive. The building's plumbing drawings can help locate plumbing lines that might endanger system hardware. These lines include hot and cold water, chilled water supply and return lines, steam lines, automatic sprinkler lines, fire hose standpipes, and drains. If a building includes a laboratory or manufacturing spaces, there may be other lines that conduct water, corrosive or toxic chemicals, or gases.
As a rule, analysis often shows that the cost to relocate threatening lines is difficult to justify. However, the location of shutoff valves and procedures that should be followed in the event of a failure must be specified. Operating and security personnel should have this information immediately available for use in an emergency. In some cases, it may be possible to relocate system hardware, particularly distributed LAN hardware.
Depending on the type of data a system processes, there may be a significant risk if the data is intercepted. There are three routes of data interception: direct observation, interception of data transmission, and electromagnetic interception.
The analysis and management of risk usually has to be modified if a system is installed in a vehicle or is portable, such as a laptop computer. The system in a vehicle will share the risks of the vehicle, including accidents and theft, as well as regional and local risks.
Portable and mobile systems share an increased risk of theft and physical damage. In addition, portable systems can be "misplaced" or left unattended by careless users. Secure storage of laptop computers is often required when they are not in use. If a mobile or portable system uses particularly valuable or important data, it may be appropriate to either store its data on a medium that can be removed from the system when it is unattended or to encrypt the data. In any case, the issue of how custody of mobile and portable computers are to be controlled should be addressed. Depending on the sensitivity of the system and its application, it may be appropriate to require briefings of users and signed briefing acknowledgments.
2.14.7 Approach to Implementation
Like other security measures, physical and environmental security controls are selected because they are cost-beneficial. This does not mean that a user must conduct a detailed cost-benefit analysis for the selection of every control. There are four general ways to justify the selection of controls:
Furthermore, a number of different security measures are available to address electric power failures. These measures differ in both cost and performance. For example, the cost of an uninterruptible power supply (UPS) depends on the size of the electric load it can support, the number of minutes it can support the load, and the speed with which it assumes the load when the primary power source fails. An on-site power generator could also be installed either in place of a UPS (accepting the fact that a power failure will cause a brief service interruption) or in order to provide long-term backup to a UPS system. Design decisions include the magnitude of the load the generator will support, the size of the on-site fuel supply, and the details of the facilities to switch the load from the primary source or the UPS to the on-site generator.
This example shows systems with a wide range of risks and a wide range of available security measures (including, of course, no action), each with its own cost factors and performance parameters.
Physical and environmental security measures rely on and support the proper functioning of many of the other areas discussed in this handbook. Among the most important are the following:
Costs associated with physical security measures range greatly. Useful generalizations about costs, therefore, are difficult make. Some measures, such as keeping a door locked, may be a trivial expense. Other features, such as fire-detection and -suppression systems, can be far more costly. Cost considerations should include operation. For example, adding controlled-entry doors requires persons using the door to stop and unlock it. Locks also require physical key management and accounting (and rekeying when keys are lost or stolen). Often these effects will be inconsequential, but they should be fully considered. As with other security measures, the objective is to select those that are cost-beneficial.
2.15 Class C2: Controlled Access Protection –An Introduction
There has been a fair amount of confusion about what is meant by "C2 compatibility". Windows NT has, for example, been tested and rated C2 compliant, but only under a very specific set of circumstances. However, simply because a system or system component is "C2 compliant" doesn't mean that it may be considered completely secure under all conditions. Unfortunately, the "C2" label has come to be a catch-all designation appearing to encompass many security features which, in fact, it does not.
Using the above example as a starting point, Windows NT workstations are only C2 compliant when they are not connected to a multi-user system (network) of any kind and when they have their A: drives disconnected at the hardware level. There are a few other restrictions that, if violated, negate the C2 compliance.
The below discussion describes what is meant by C2 compliance. This is paraphrased from the Department of Defense "Orange Book", which is the authoritative document, and the National Computer Security Center's "Red Book" which is the official network interpretation of the Orange book. Systems in this class make 'users individually accountable for their actions through login procedures, auditing of security-relevant events and resource isolation.' There are only four top level criteria for C2 systems:
Security Policy: Discretionary Access Control - The system defines and controls access between named users and named objects. The enforcement mechanism (self/group/public controls, access control lists, etc.) allows users to specify and control sharing of these objects by named individuals, groups or both and provides controls to limit propagation of access rights. Objects must be protected from unauthorized access either by explicit user action or default. The controls are capable of including or excluding access to the granularity of a single user.
Security Policy: Object Reuse - All authorizations to a storage object must be revoked prior to initial assignment, allocation or reallocation. No information including encrypted representations of information is available to any user that obtains access to an object that has been released back to the system.
Accountability: Identification and Authentication - All users must identify themselves before performing any other actions that the system is expected to mediate. Some protected mechanism such as passwords must be used to authenticate the user's identity. The system must protect authentication data so that it cannot be accessed by any unauthorized user. The system must be able to enforce individual accountability by uniquely identifying each user and providing the capability of associating the identity with all auditable actions taken by the individual.
Accountability: Audit - The system must be able to create, maintain and protect from modification or unauthorized access or destruction an audit trail of access to the objects it protects. It must record the following types of events: use of identification and authentication mechanism, introduction of objects into a user's address space, deletions of objects, actions taken by system administrators and security officers, and other security-relevant events. For each recorded event the system must record the date and time, user, type of event and success or failure of the event. If the event is the introduction of an object into the user's address space (such as file open or program execution) the name of the object must be included.
Operational Assurance: System Architecture - The system must maintain a domain for its own execution that protects it from external interference or tampering such as modification of its code or data structures. The system resources to be protected must be isolated and subject to access control and auditing requirements.
Operational Assurance: System Integrity - Hardware and/or software features must be provided to validate the correct operation of the system resources.
Life Cycle Assurance: Security Testing - The security mechanisms of the system must be tested and found to work as presented in system documentation. Testing must insure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the system. This must include a search for obvious flaws that would allow a violation of resource isolation or that would permit unauthorized access to the audit or authentication data.
Documentation: Security Features User's Guide - The protection mechanisms provided by the system, their use and how they interact with each other must be provided.
Documentation: Trusted Facility Manual - A manual addressed to the system administrator must present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining audit files as well as the detailed audit record structure for each type of audit event must be given.
Documentation: Test Documentation -The system developer must provide a document that describes the test plan and procedures that shows how the security mechanisms were tested and the results of the testing.
Documentation: Design Documentation - A document must be provided that describes the developer's philosophy of protection and how the philosophy was implemented in the system. If the system is modular, the interfaces between the modules must be described.
By extension, the Red Book applies the C2 standard criteria to the network environment. The Red Book's purpose is to interpret the Orange Book's standalone standards as the may be applied to a network. The Red Book places responsibility for the security of the network not on a manufacturer, but on the network's sponsor. This differentiation acknowledges that a device, regardless of its Orange Book rating as delivered from the manufacturer, becomes a component of the multivendor network when it is interconnected. As such, it takes on some of the characteristics of the network, interacts with other components of the network and may have its own characteristics altered by these interactions. The manufacturer no longer
controls the security mechanisms of the device for these reasons. The Red Book places the system-wide responsibility with the network sponsor.
Policy - The Red Book defines two types of policy within the network environment: Secrecy and Data Integrity. The document defines them as follows:
Secrecy Policy: The network sponsor shall define the form of the discretionary secrecy policy that is enforced in the network to prevent unauthorized users from reading the sensitive information entrusted to the network.
Data Integrity Policy: The network sponsor shall define the discretionary integrity policy to prevent unauthorized users from modifying, viz., writing, sensitive information. The definition of data integrity presented by the network sponsor refers to the requirement that the information has not been subjected to unauthorized modification in the
network.
Accountability: Identification and Authentication - The requirement for identification and authentication of users is the same for a network system as for an ADP system. The identification and authentication may be done by the component to which the user is directly connected or some other component, such as an identification and authentication server.
Accountability: Audit - This criterion applies as stated in the Orange Book.
Assurance: Architecture -The system architecture criterion must be met individually by all NTCB (Network Trusted Computing Base) partitions. Implementation of the requirement that the NTCB maintain a domain for its own execution is achieved by having each NTCB partition maintain a domain for its own execution.
Assurance: Integrity - Implementation of the requirement is partly achieved by having hardware and/or software features that can be used to periodically validate the correct operation of the hardware and firmware elements of each component's NTCB partition. Features shall also be provided to validate the identity and correct operation of a component prior to its incorporation in the network system and throughout system operation.
Assurance: Security Testing - The testing of a security mechanism of the network system for meeting this criterion shall be an integrated testing procedure involving all components containing an NTCB partition that implement the given mechanism. This integrated testing is additional to any individual component tests involved in the evaluation of the network system. The sponsor should identify the allowable set of configurations including the sizes of the networks.
Documentation - This user documentation describes user visible protection mechanisms at the global (network system) level and at the user interface of each component, and the interaction among these. The Trusted Facility Manual contains specifications and procedures to assist the system administrator(s) maintain cognizance of
the network configuration. These specifications and procedures address the following:
The application of C2 standards in both the standalone and network environment has specific implications. However, to extend those implications, either beyond the standard or into an altered environment requires some form of supporting guidelines. It is not enough to say, for example, that a device is "C2 certified" and assume that, however it is employed, it will continue to meet C2 (or, even, its own published) specifications.
Finally, vendors often represent products as "C2 compliant" implying that the product has undergone and passed the rigid C2 testing process employed by the NCSC. In most cases this is misleading. Very few PC-based systems have undergone and completed such testing. In fact, there are no current (July, 1996) network systems that are officially rated C2.
When a vendor represents a device as C2 compliant, it usually means that the device was designed to C2 standards, not that it has been tested and certified. While this may certainly be adequate for many implementations, it is important to understand that 1) C2 certification probably does not exist for that product, and 2) the ability of the product to maintain its C2-type architecture may change materially as its network environment changes.
C2 compliance, per se, is usually not a requirement for commercial systems. In fact, there are a number of "standards" that purport to be taking the place of C2 for the commercial world. These new criteria, such as "Extended C2" and "Commercial C2" are, generally, simply extensions of the original C2 standard. We do not recommend slavish adherence to C2 as a method of securing today's commercial networks. Rather, we believe that the principles upon which the C2 standard is built offer an excellent measuring stick for the over-all security of the corporate computing environment.
However, as many security and audit professionals point out, the architecture of the system is only the beginning. It is at least as important to ensure that the policies, standards and practices which the C2 environment enforces are current and appropriate. The system administrators must be well-trained and empowered to do their jobs properly. There must be periodic risk assessments and formal audits to ensure compliance with policies. Finally, there must be a firm system of enforcement, both at the system and administrative levels.
Good security is not a single layer of protection. It consists of proper policies, standards and practices, adequate architecture, compliance testing and auditing, and appropriate administration. Most important, good information security requires awareness at all levels of the organization and solid, visible support from the highest management. Only when these other criteria are met will the application of C2 principles to the computing system be effective.
Section References
2.1 Fraser, B. ed. RFC 2196. Site Security Handbook. Network Working Group, September 1997.
Chapter 2.
2.2 Guideline for the Analysis Local Area Network Security., Federal Information Processing Standards Publication 191, November 1994. Chapter 2.
2.3 NIST. An Introduction to Security: The NIST Handbook, Special Publication 800-12. US Dept. of Commerce. Chapter 5.
Fites, P., and M. Kratz. "Policy Development." Information Systems Security: A Practitioner's Reference. New York, NY: Van Nostrand Reinhold, 1993. pp. 411-427.
Lobel, J. "Establishing a System Security Policy." Foiling the System Breakers. New York, NY:McGraw-Hill, 1986. pp. 57-95.
Menkus, B. "Concerns in Computer Security." Computers and Security. 11(3), 1992. pp.211-215.
Office of Technology Assessment. "Federal Policy Issues and Options." Defending Secrets, Sharing Data: New Locks for Electronic Information. Washington, DC: U.S Congress, Office of Technology Assessment, 1987. pp. 151-160.
Office of Technology Assessment. "Major Trends in Policy Development." Defending Secrets, Sharing Data: New Locks and Keys for Electronic Information. Washington, DC: U.S. Congress,
Office of Technology Assessment, 1987. p. 131-148.
O'Neill, M., and F. Henninge, Jr. "Understanding ADP System and Network Security Considerations and Risk Analysis." ISSA Access. 5(4), 1992. pp. 14-17.
Peltier, Thomas. "Designing Information Security Policies That Get Results." Infosecurity News.4(2), 1993. pp. 30-31.
President's Council on Management Improvement and the President's Council on Integrity and Efficiency. Model Framework for Management Control Over Automated Information System.
Washington, DC: President's Council on Management Improvement, January 1988. Smith, J. "Privacy Policies and Practices: Inside the Organizational Maze." Communications of the ACM. 36(12), 1993. pp. 104-120.
Sterne, D. F. "On the Buzzword `Computer Security Policy.'" In Proceedings of the 1991 IEEE Symposium on Security and Privacy, Oakland, CA: May 1991. pp. 219-230.
Wood, Charles Cresson. "Designing Corporate
Information Security Policies." DATAPRO Reports on Information Security,
April 1992.
Area Networks, Architectures and Implementations, Prentice Hall,
1989.
[BARK89] Barkley, John F., and K. Olsen; Introduction to Heterogenous
Computing Environments, NIST Special Publication 500-176,
November, 1989.
[NCSC87] A Guide to Understanding Discretionary Access Control in Trusted
Systems, NCSC-TG-003, Version 1, September 30, 1987
[NCSL90] National Computer Systems Laboratory (NCSL) Bulletin, Data
Encryption Standard, June, 1990.
[SMID88] Smid, Miles, E. Barker, D. Balenson, and M. Haykin; Message
Authentication Code (MAC) Validation System: Requirements and
Procedures, NIST Special Publication 500-156, May, 1988.
[OLDE92] Oldehoeft, Arthur E.; Foundations of a Security Policy for Use of
the National Research and Educational Network, NIST Interagency
Report, NISTIR 4734, February 1992.
[COMM91] U.S. Department of Commerce Information Technology
Management Handbook, Attachment 13-D: Malicious Software
Policy and Guidelines, November 8, 1991.
[WACK89] Wack, John P., and L. Carnahan; Computer Viruses and Related
Threats: A Management Guide, NIST Special Publication 500-166,
August 1989.
[X9F292] Information Security Guideline for Financial Institutions, X9/TG-5,
Accredited Committee X9F2, March 1992.
[BJUL93] National Computer Systems Laboratory (NCSL) Bulletin, Connecting to the
Internet: Security Considerations, July 1993.
[BNOV91] National Computer Systems Laboratory (NCSL) Bulletin, Advanced
Authentication Technology, November 1991.
[KLEIN] Daniel V. Klein, "Foiling the Cracker: A Survey of, and Improvements to,
Password Security", Software Engineering Institute. (This work was sponsored in
part by the Department of Defense.)
[GILB89] Gilbert, Irene; Guide for Selecting Automated Risk Analysis Tools,
NIST Special Publication 500-174, October, 1989.
[KATZ92] Katzke, Stuart W. ,Phd., "A Framework for Computer Security Risk
Management", NIST, October, 1992.
[NCSC85] Department of Defense Password Management Guideline, National Computer Security Center, April, 1985.
[NIST85] Federal Information Processing Standard (FIPS PUB) 112, Password Usage, May, 1985.
[ROBA91] Roback Edward, NIST Coordinator, Glossary of Computer Security Terminology, NISTIR 4659, September, 1991.
[TODD89] Todd, Mary Anne and Constance Guitian, Computer Security Training Guidelines,NIST Special Publication 500-172, November, 1989.
[STIE85] Steinauer, Dennis D.; Security of Personal Computer Systems: A
Management Guide, NBS Special Publication 500-120, January,
1985.
[WACK91] Wack, John P.; Establishing a Computer Security Incident
Response Capability (CSIRC), NIST Special Publication 800-3,
November, 1991.
[NIST74] Federal Information Processing Standard (FIPS PUB) 31,
Guidelines for Automatic Data Processing Physical Security and
Risk Management, June, 1974.
2.6. Fraser, B. ed. RFC 2196. Site Security Handbook. Network Working Group, September 1997. Chapter 4.6.
2.7 Fraser, B. ed. RFC 2196. Site Security Handbook. Network Working Group, September 1997. Chapter 5.
2.8 Fraser, B. ed. RFC 2196. Site Security Handbook. Network Working Group, September 1997. Chapter 4.5.4
2.9 Hancock, William M. Dial-Up MODEM Protection Schemes: A Case Study in Secure Dial-Up Implementation. Network-1 Software and Technology, Inc.1995.
2.10 Innovative Security Products. Security White Paper Series: Securing Your Companies Network. Prairie Village, KS, 1998.
2.11 Innovative Security Products. Security White Paper Series: Microcomputer Security. Prairie Village, KS, 1998.
2.12 Fraser, B. ed. RFC 2196. Site Security Handbook. Network Working Group, September 1997. Chapter 4.5.
2.13 Royal Canadian Mounted Police Technical Operations Directorate. Information Technology Security Branch. Guide to Minimizing Computer Theft. Security Information Publications June 1997
2.14 NIST. An Introduction to Security: The NIST Handbook, Special Publication 800-12. US Dept. of Commerce. Chapter 15.
Archer, R. "Testing: Following Strict Criteria." Security Dealer. 15(5), 1993. pp. 32-35.
Breese, H., ed. The Handbook of Property Conservation. Norwood, MA: Factory Mutual Engineering Corp.
Chanaud, R. "Keeping Conversations Confidential." Security Management. 37(3), 1993.pp. 43-48.
Miehl, F. "The Ins and Outs of Door Locks." Security Management. 37(2), 1993. pp. 48-53.
National Bureau of Standards. Guidelines for ADP Physical Security and Risk Management.
Federal Information Processing Standard Publication 31. June 1974.
Peterson, P. "Infosecurity and Shrinking Media." ISSA Access. 5(2), 1992. pp. 19-22.
Roenne, G. "Devising a Strategy Keyed to Locks." Security Management. 38(4), 1994.pp. 55-56.
Zimmerman, J. "Using Smart Cards -
A Smart Move." Security Management. 36(1), 1992. pp. 32-36.