FDIC July 9, 1999
RISK ASSESSMENT TOOLS AND PRACTICES
OR INFORMATION SYSTEM SECURITY
INTRODUCTION
The purpose of this paper is to provide financial institutions and
examiners with background information and guidance on various risk
assessment tools and practices related to information security.
Institutions using the Internet or other computer networks are exposed to
various categories of risk that could result in the possibility of
financial loss and reputational harm. Given the rapid growth of the
Internet and networking technology, the available risk assessment tools
and practices are becoming more important for information security.
This paper provides a summary of critical points, discusses components
of a sound information security program, and describes the risk assessment
and risk management processes for information security. The appendix
provides specific information on certain risk assessment tools and
practices that may be part of an institution's information security
program. The paper and appendix are intended to provide useful information
and guidance, not to create new examination standards, impose new
regulatory requirements, or represent an exclusive description of the
various ways financial institutions can implement effective information
security programs.
Whether financial institutions contract with third-party providers(1)
for computer services such as Internet banking, or maintain computer
services in-house, bank management is responsible for ensuring that
systems and data are protected against risks associated with emerging
technologies and computer networks. If a bank is relying on a third-party
provider, management must generally understand the provider's information
security program to effectively evaluate the security system's ability to
protect bank and customer data.
The FDIC has previously issued guidance on information security
concerns such as data privacy and confidentiality, data integrity,
authentication, non-repudiation, and access control/system design. This
paper is designed to supplement Financial Institution Letter 131-97,
"Security Risks Associated With the Internet," dated December
18, 1997, and to complement the FDIC's safety and soundness electronic
banking examination procedures. Related guidance can be found in the FFIEC
Information Systems Examination Handbook.
--------------------------------------------------------------------------------
(1) For the purposes of this paper, "third-party provider" is
broadly defined. Third-party providers include entities that may provide
the following services or products to institutions: system design,
development, administration, and maintenance services; data processing
services; and hardware and/or software solutions.
SUMMARY OF CRITICAL POINTS
To ensure the security of information systems and data, financial
institutions should have a sound information security program that
identifies, measures, monitors, and manages potential risk exposure.
Fundamental to an effective information security program is ongoing risk
assessment of threats and vulnerabilities surrounding networked and/or
Internet systems. Institutions should consider the various measures
available to support and enhance information security programs. The
appendix to this paper describes certain vulnerability assessment tools
and intrusion detection methods that can be useful in preventing and
identifying attempted external break-ins or internal misuse of information
systems. Institutions should also consider plans for responding to an
information security incident.
INFORMATION SECURITY PROGRAM
A financial institution's board of directors and senior management
should be aware of information security issues and be involved in
developing an appropriate information security program. A comprehensive
information security policy should outline a proactive and ongoing program
incorporating three components:
Prevention
Detection
Response
Prevention measures include sound security policies,
well-designed system architecture, properly configured firewalls, and
strong authentication programs. This paper discusses two additional
prevention measures: vulnerability assessment tools and penetration
analyses. Vulnerability assessment tools generally involve running scans
on a system to proactively detect known vulnerabilities such as security
flaws and bugs in software and hardware. These tools can also detect holes
allowing unauthorized access to a network, or insiders to misuse the
system. Penetration analysis involves an independent party (internal or
external) testing an institution's information system security to identify
(and possibly exploit) vulnerabilities in the system and surrounding
processes. Using vulnerability assessment tools and performing regular
penetration analyses will assist an institution in determining what
security weaknesses exist in its information systems.
Detection measures involve analyzing available information to
determine if an information system has been compromised, misused, or
accessed by unauthorized individuals. Detection measures may be enhanced
by the use of intrusion detection systems (IDSs) that act as a burglar
alarm, alerting the bank or service provider to potential external
break-ins or internal misuse of the system(s) being monitored.
Another key area involves preparing a response program to handle
suspected intrusions and system misuse once they are detected.
Institutions should have an effective incident response program outlined
in a security policy that prioritizes incidents, discusses appropriate
responses to incidents, and establishes reporting requirements.
The appendix provides a detailed discussion on prevention
(vulnerability assessment tools and penetration analyses), detection (IDS
tools), and response measures. Before implementing some or all of these
measures, an institution should perform an information security risk
assessment. Depending on the risk assessment, certain risk assessment
tools and practices discussed in this paper may be appropriate. However,
use of these measures should not result in decreased emphasis on
information security or the need for human expertise.
RISK ASSESSMENT/MANAGEMENT
A thorough and proactive risk assessment is the first step in
establishing a sound security program. This is the ongoing process of
evaluating threats and vulnerabilities, and establishing an appropriate
risk management program to mitigate potential monetary losses and harm to
an institution's reputation. Threats have the potential to harm an
institution, while vulnerabilities are weaknesses that can be exploited.
The extent of the information security program should be commensurate
with the degree of risk associated with the institution's systems,
networks, and information assets. For example, compared to an
information-only Web site, institutions offering transactional Internet
banking activities are exposed to greater risks. Further, real-time funds
transfers generally pose greater risks than delayed or batch-processed
transactions because the items are processed immediately. The extent to
which an institution contracts with third-party vendors will also affect
the nature of the risk assessment program.
Performing the Risk Assessment and Determining Vulnerabilities
Performing a sound risk assessment is critical to establishing an
effective information security program. The risk assessment provides a
framework for establishing policy guidelines and identifying the risk
assessment tools and practices that may be appropriate for an institution.
Banks still should have a written information security policy, sound
security policy guidelines, and well-designed system architecture, as well
as provide for physical security, employee education, and testing, as part
of an effective program.
When institutions contract with third-party providers for information
system services, they should have a sound oversight program. At a minimum,
the security-related clauses of a written contract should define the
responsibilities of both parties with respect to data confidentiality,
system security, and notification procedures in the event of data or
system compromise. The institution needs to conduct a sufficient analysis
of the provider's security program, including how the provider uses
available risk assessment tools and practices. Institutions also should
obtain copies of independent penetration tests run against the provider's
system.
When assessing information security products, management should be
aware that many products offer a combination of risk assessment features,
and can cover single or multiple operating systems. Several organizations
provide independent assessments and certifications of the adequacy of
computer security products (e.g., firewalls). While the underlying product
may be certified, banks should realize that the manner in which the
products are configured and ultimately used is an integral part of the
products' effectiveness. If relying on the certification, banks should
understand the certification process used by the organization certifying
the security product. Other examples of items to consider in the risk
assessment process include:
Identifying mission-critical information systems, and determining the
effectiveness of current information security programs. For example, a
vulnerability might involve critical systems that are not reasonably
isolated from the Internet and external access via modem. Having
up-to-date inventory listings of hardware and software, as well as system
topologies, is important in this process.
Assessing the importance and sensitivity of information, and the
likelihood of outside break-ins (e.g., by hackers) and insider misuse of
information. For example, if a large depositor list were made public, that
disclosure could expose the bank to reputational risk and the potential
loss of deposits. Further, the institution could be harmed if human
resource data (e.g., salaries and personnel files) were made public. The
assessment should identify systems that allow the transfer of funds, other
assets, or sensitive data/confidential information, and review the
appropriateness of access controls and other security policy settings.
Assessing the risks posed by electronic connections with business
partners. The other entity may have poor access controls that could
potentially lead to an indirect compromise of the bank's system. Another
example involves vendors that may be allowed to access the bank's system
without proper security safeguards, such as firewalls. This could result
in open access to critical information that the vendor may have "no
need to know."
Determining legal implications and contingent liability concerns
associated with any of the above. For example, if hackers successfully
access a bank's system and use it to subsequently attack others, the bank
may be liable for damages incurred by the party that is attacked.
Potential Threats To Consider
Serious hackers, interested computer novices, dishonest vendors or
competitors, disgruntled current or former employees, organized crime, or
even agents of espionage pose a potential threat to an institution's
computer security. The Internet provides a wealth of information to banks
and hackers alike on known security flaws in hardware and software. Using
almost any search engine, average Internet users can quickly find
information describing how to break into various systems by exploiting
known security flaws and software bugs. Hackers also may breach security
by misusing vulnerability assessment tools to probe network systems, then
exploiting any identified weaknesses to gain unauthorized access to a
system. Internal misuse of information systems remains an ever-present
security threat.
Many break-ins or insider misuses of information occur due to poor
security programs. Hackers often exploit well-known weaknesses and
security defects in operating systems that have not been appropriately
addressed by the institution. Inadequate maintenance and improper system
design may also allow hackers to exploit a security system. New security
risks arise from evolving attack methods or newly detected holes and bugs
in existing software and hardware. Also, new risks may be introduced as
systems are altered or upgraded, or through the improper setup of
available security-related tools. An institution needs to stay abreast of
new security threats and vulnerabilities. It is equally important to keep
up to date on the latest security patches and version upgrades that are
available to fix security flaws and bugs. Information security and
relevant vendor Web sites contain much of this information.
Systems can be vulnerable to a variety of threats, including the misuse
or theft of passwords. Hackers may use password cracking programs to
figure out poorly selected passwords. The passwords may then be used to
access other parts of the system. By monitoring network traffic,
unauthorized users can easily steal unencrypted passwords. The theft of
passwords is more difficult if they are encrypted. Employees or hackers
may also attempt to compromise system administrator access (root access),
tamper with critical files, read confidential e-mail, or initiate
unauthorized e-mails or transactions.
Hackers may use "social engineering," a scheme using social
techniques to obtain technical information required to access a system. A
hacker may claim to be someone authorized to access the system such as an
employee or a certain vendor or contractor. The hacker may then attempt to
get a real employee to reveal user names or passwords, or even set up new
computer accounts. Another threat involves the practice of "war
dialing," in which hackers use a program that automatically dials
telephone numbers and searches for modem lines that bypass network
firewalls and other security measures. A few other common forms of system
attack include:
Denial of service (system failure), which is any action preventing a
system from operating as intended. It may be the unauthorized destruction,
modification, or delay of service. For example, in a "SYN Flood"
attack, a system can be flooded with requests to establish a connection,
leaving the system with more open connections than it can support. Then,
legitimate users of the system being attacked are not allowed to connect
until the open connections are closed or can time out.
Internet Protocol (IP) spoofing, which allows an intruder via the
Internet to effectively impersonate a local system's IP address in an
attempt to gain access to that system. If other local systems perform
session authentication based on a connection's IP address, those systems
may misinterpret incoming connections from the intruder as originating
from a local trusted host and not require a password.
Trojan horses, which are programs that contain additional (hidden)
functions that usually allow malicious or unintended activities. A Trojan
horse program generally performs unintended functions that may include
replacing programs, or collecting, falsifying, or destroying data. Trojan
horses can be attached to e-mails and may create a "back door"
that allows unrestricted access to a system. The programs may
automatically exclude logging and other information that would allow the
intruder to be traced.
Viruses, which are computer programs that may be embedded in other code
and can self-replicate. Once active, they may take unwanted and unexpected
actions that can result in either nondestructive or destructive outcomes
in the host computer programs. The virus program may also move into
multiple platforms, data files, or devices on a system and spread through
multiple systems in a network. Virus programs may be contained in an
e-mail attachment and become active when the attachment is opened.
CONCLUSION
It is important for financial institutions to develop and implement
appropriate information security programs. Whether systems are maintained
in-house or by third-party vendors, appropriate security controls and risk
management techniques must be employed. A security program includes
effective security policies and system architecture, which may be
supported by the risk assessment tools and practices discussed in this
guidance paper and appendix. Information security threats and
vulnerabilities, as well as their countermeasures, will continue to
evolve. As such, institutions should have a proactive risk assessment
process that identifies emerging threats and vulnerabilities to
information systems.
A sound information security policy identifies prevention, detection,
and response measures. The appendix provides more details on risk
assessment tools and practices that may be used to improve information
security programs. Preventive measures may include regularly using
vulnerability assessment tools and conducting periodic penetration
analyses. Intrusion detection tools can be effective in detecting
potential intrusions or system misuse. Institutions should also develop a
response program to effectively handle any information security breaches
that may occur.
APPENDIX
PART ONE - PREVENTION: Discusses the use of vulnerability
assessment tools and penetration analyses. When used regularly, both
techniques can be integral components of an institution's information
security program.
VULNERABILITY ASSESSMENT TOOLS
Vulnerability assessment tools, also called security scanning tools,
assess the security of network or host systems and report system
vulnerabilities. These tools can scan networks, servers, firewalls,
routers, and applications for vulnerabilities. Generally, the tools can
detect known security flaws or bugs in software and hardware, determine if
the systems are susceptible to known attacks and exploits, and search for
system vulnerabilities such as settings contrary to established security
policies.
In evaluating a vulnerability assessment tool, management should
consider how frequently the tool is updated to include the detection of
any new weaknesses such as security flaws and bugs. If there is a time
delay before a system patch is made available to correct an identified
weakness, mitigating controls may be needed until the system patch is
issued.
Generally, vulnerability assessment tools are not run in real-time, but
they are commonly run on a periodic basis. When using the tools, it is
important to ensure that the results from the scan are secure and only
provided to authorized parties. The tools can generate both technical and
management reports, including text, charts, and graphs. The vulnerability
assessment reports can tell a user what weaknesses exist and how to fix
them. Some tools can automatically fix vulnerabilities after detection.
Host- Versus Network-Based Vulnerability Assessment Tools
As in intrusion detection systems, which are discussed later in this
appendix, there are generally two types of vulnerability assessment tools:
host-based and network-based. Another category is sometimes used for
products that assess vulnerabilities of specific applications
(application-based) on a host. A host is generally a single computer or
workstation that can be connected to a computer network. Host-based tools
assess the vulnerabilities of specific hosts. They usually reside on
servers, but can be placed on specific desktop computers, routers, or even
firewalls. Network-based vulnerability assessment tools generally reside
on the network, specifically analyzing the network to determine if it is
vulnerable to known attacks. Both host- and network-based products offer
valuable features, and the risk assessment process should help an
institution determine which is best for its needs. Information systems
personnel should understand the types of tools available, how they
operate, where they are located, and the output generated from the tools.
Host-based vulnerability assessment tools are effective at identifying
security risks that result from internal misuse or hackers using a
compromised system. They can detect
holes that would allow access to a system such as unauthorized modems,
easily guessed passwords, and unchanged vendor default passwords. The
tools can detect system vulnerabilities such as poor virus protection
capabilities; identify hosts that are configured improperly; and provide
basic information such as user log-on hours, password/account expiration
settings, and users with dial-in access. The tools may also provide a
periodic check to confirm that various security policies are being
followed. For instance, they can check user permissions to access files
and directories, and identify files and directories without ownership.
Network-based vulnerability assessment tools are more effective than
host-based at detecting network attacks such as denial of service and
Internet Protocol (IP) spoofing. Network tools can detect unauthorized
systems on a network or insecure connections to business partners. Running
a host-based scan does not consume network overhead, but can consume
processing time and available storage on the host. Conversely, frequently
running a network-based scan as part of daily operations increases network
traffic during the scan. This may cause inadvertent network problems such
as router crashes.
PENETRATION ANALYSIS
After the initial risk assessment is completed, management may
determine that a penetration analysis (test) should be conducted. For the
purpose of this paper, "penetration analysis" is broadly
defined. Bank management should determine the scope and objectives of the
analysis. The scope can range from a specific test of a particular
information system's security or a review of multiple information security
processes in an institution.
A penetration analysis usually involves a team of experts who identify
an information system's vulnerability to a series of attacks. The
evaluators may attempt to circumvent the security features of a system by
exploiting the identified vulnerabilities. Similar to running
vulnerability scanning tools, the objective of a penetration analysis is
to locate system vulnerabilities so that appropriate corrective steps can
be taken.
The analysis can apply to any institution with a network, but becomes
more important if system access is allowed via an external connection such
as the Internet. The analysis should be independent and may be conducted
by a trusted third party, qualified internal audit team, or a combination
of both. The information security policy should address the frequency and
scope of the analysis. In determining the scope of the analysis, items to
consider include internal vs. external threats, systems to include in the
test, testing methods, and system architectures.
A penetration analysis is a snapshot of the security at a point in time
and does not provide a complete guaranty that the system(s) being tested
is secure. It can test the effectiveness of security controls and
preparedness measures. Depending on the scope of the analysis, the
evaluators may work under the same constraints applied to ordinary
internal or external users. Conversely, the evaluators may use all system
design and implementation documentation. It is common for the evaluators
to be given just the IP address of the institution and any other public
information, such as a listing of officers that is normally available to
outside hackers. The evaluators may use vulnerability assessment tools,
and employ some of the attack methods discussed in this paper such as
social engineering and war dialing. After completing the agreed-upon
analysis, the evaluators should provide the institution a detailed written
report. The report should identify vulnerabilities, prioritize weaknesses,
and provide recommendations for corrective action.
A penetration analysis itself can introduce new risks to an
institution; therefore, several items should be considered before having
an analysis completed, including the following:
If using outside testers, the reputation of the firm or consultants
hired. The evaluators will assess the weaknesses in the bank's information
security system. As such, the confidentiality of results and bank data is
crucial. Just like screening potential employees prior to their hire,
banks should carefully screen firms, consultants, and subcontractors who
are entrusted with access to sensitive data. A bank may want to require
security clearance checks on the evaluators. An institution should ask if
the evaluators have liability insurance in case something goes wrong
during the test. The bank should enter into a written contact with the
evaluators, which at a minimum should address the above items.
If using internal testers, the independence of the testers from system
administrators.
The secrecy of the test. Some senior executives may order an analysis
without the knowledge of information systems personnel. This can create
unwanted results, including the notification of law enforcement personnel
and wasted resources responding to an attack. To prevent excessive
responses to the attacks, bank management may consider informing certain
individuals in the organization of the penetration analysis.
The importance of the systems to be tested. Some systems may be too
critical to be exposed to some of the methods used by the evaluators such
as a critical database that could be damaged during the test.
PART TWO - DETECTION: Discusses intrusion detection systems, and
using these tools as the detection component of an institution's
information security program.
INTRUSION DETECTION SYSTEMS
Vulnerability assessments and penetration analyses help ensure that
appropriate security precautions have been implemented and that system
security configurations are appropriate. The next step is to monitor the
system for intrusions and unusual activities. Intrusion detection systems
(IDSs) may be useful because they act as a burglar alarm, reporting
potential intrusions to appropriate personnel. By analyzing the
information generated by the systems being guarded, IDSs help determine if
necessary safeguards are in place and are protecting the system as
intended. In addition, they can be configured to automatically respond to
intrusions.
Computer system components or applications can generate detailed,
lengthy logs or audit trails that system administrators can manually
review for unusual events. IDSs automate the review of logs and audit
data, which increases the review's overall efficiency by reducing costs
and the time and level of skill necessary to review the logs.
Typically, there are three components to an IDS. First is an agent,
which is the component that actually collects the information. Second is a
manager, which processes the information collected by the agents. Third is
a console, which allows authorized information systems personnel to
remotely install and upgrade agents, define intrusion detection scenarios
across agents, and track intrusions as they occur. Depending on the
complexity of the IDS, there can be multiple agent and manager components.
Generally, IDS products use three different methods to detect
intrusions. First, they can look for identified attack signatures, which
are streams or patterns of data previously identified as an attack.
Second, they can look for system misuse such as unauthorized attempts to
access files or disallowed traffic inside the firewall. Third, they can
look for activities that are different from the user's or system's normal
pattern. These "anomaly-based" products (which use artificial
intelligence) are designed to detect subtle changes or new attack
patterns, and then notify appropriate personnel that an intrusion may be
occurring. Some anomaly-based products are created to update normal use
patterns on a regular basis. Poorly designed anomaly-based products can
trigger frequent false-positive responses.
Although IDSs may be an integral part of an institution's overall
system security, they will not protect a system from previously unknown
threats or vulnerabilities. They are not self-sufficient and do not
compensate for weak authentication procedures (e.g., when an intruder
already knows a password to access the system). Also, IDSs often have
overlapping features with other security products, such as firewalls. IDSs
provide additional protections by helping to determine if the firewall
programs are working properly and by helping to detect internal abuses.
Both firewalls and IDSs need to be properly configured and updated to
combat new types of attacks. In addition, management should be aware that
the state of these products is highly dynamic and IDS capabilities are
evolving.
IDS tools can generate both technical and management reports, including
text, charts, and graphs. The IDS reports can provide background
information on the type of attack and recommend courses of action. When an
intrusion is detected, the IDS can automatically begin to collect
additional information on the attacker, which may be needed later for
documentation purposes.
Host- Versus Network-Based IDS Tools
As with vulnerability assessment tools, there are generally two types
of IDS products: host-based and network-based. A third product category is
sometimes used for IDSs that look for unusual application events
(application-based) on a host. Both network- and host-based tools offer
valuable features, and the risk assessment process should help
institutions determine if either, or a combination of both, is best for
their needs.
Host-Based IDSs
Host-based IDSs are also known as audit trail analysis tools or
server-based IDSs (often placed on servers). A host-based IDS will look
for potential intrusions or patterns of misuse by monitoring host event
activities, audit logs, and other security-related activities. The tools
will track audit trails from operating systems, applications, Web servers,
routers, and firewalls, as well as monitor critical files for Trojan
horses and unauthorized changes. This can provide valuable evidence of a
break-in and can assist in assessing damage because the intruder's actions
are logged on the specific hosts. If done in real-time, the IDS can
promptly notify the bank of unauthorized attempts to gain system
administrator (root) controls, access or change critical files, or replace
log-in programs.
An important benefit of host-based IDSs is that they are effective in
detecting insider misuse because they monitor activities on the specific
hosts. For example, they can monitor a user's attempt to access a
restricted file, or an attempt to execute a system administrator's
command. In addition, they can monitor encrypted transmissions as the data
is generally decrypted before it is logged at the host.
A problem with host-based systems is that notification of the attack is
delayed if an agent does not examine the audit trail in real-time. This
problem relates to the relatively large consumption of computer processing
speed and disk space that is required to run these programs in real-time.
If not run in real-time, they still allow a bank to identify larger trends
and problems with system security.
Network-Based IDSs
With network-based IDSs, software or sniffers are placed on one or
multiple points across the network. The sniffer agent analyzes packets of
information moving across the network for potential intrusions. Network
packets contain data, including the message and headers that identify the
sending and receiving parties. Network-based IDSs look for patterns of
misuse, specific types of attacks, and unusual activity such as unexpected
volume and types of network traffic. Compared to host-based IDSs, certain
types of network-orientated attacks such as IP spoofing, packet floods,
and denial of service, are best detected through packet examination.
Network-based IDSs can detect potential intrusions in real-time, and
offer concurrent notification and response capabilities to potential
intrusions. The software does not need to be put on the various hosts
throughout the network, thus it is generally easier to monitor and may be
less expensive than host-based IDSs.
Network-based IDSs sometimes mistakenly identify normal traffic as an
intrusion ("false positives") and vice versa ("false
negatives"). They can have difficulties detecting slow attacks and
experience problems with busy networks. Network-based IDSs cannot monitor
encrypted transmissions (only detect that data is being transferred across
the network), and are less effective at detecting insider misuse because
network packet analysis does not monitor the activities on specific hosts.
Factors to Consider in Evaluating IDSs
Once it is determined that an IDS is necessary to detect possible
security breaches, several factors should be considered in evaluating
IDSs, including:
The comprehensiveness of the attack signature database, including the
frequency of updates that incorporate newly identified concerns. Most
products rely on vendor updates, so banks need to assess the timeliness of
the IDS vendor's updates. Products can be updated through Internet
downloads, CD-ROM or floppy disk updates, or even manually if the user has
a sufficient degree of technical knowledge.
The effectiveness of the IDS in protecting an institution from both
internal and external threats to a computer system. The IDS should limit
the number of false positives (incorrectly identifying an attack when none
has occurred) and false negatives (not identifying an attack when one has
occurred).
The impact on performance of the network and/or host(s). Generally,
IDSs work on a real-time basis. Real-time analysis provides quicker
notification of potential intrusions; however, it can reduce system
performance due to the additional memory and processing requirements.
Non-real-time analysis generally consumes fewer resources, but has the
disadvantage that the potential intrusion has already occurred.
Knowledgeable intruders, moreover, can manipulate audit trails, making the
after-the-fact analysis useless in detecting these particular intruders.
The security of the IDS itself and how secure the update process is,
especially if updated remotely.
The reporting and automated response capabilities. IDSs will sometimes
generate more information than can be reviewed by present qualified staff.
Also, for privacy reasons, management should consider informing all
affected system users about the scope and type of monitoring being
conducted.
Other things to consider include training and support from the vendor,
cost of hardware, software, and maintenance agreements, integration with
vulnerability assessment tools, and configuration capabilities.
Determining Which is Best for an Institution
An institution's risk assessment process should first determine whether
an IDS is necessary. Next, the type or placement of an IDS depends on the
priority of identified threats or vulnerabilities. If one or a few hosts
contain information that management views as critical, a host-based IDS
may be warranted. If the information is less essential, other controls
such as a firewall and/or filtering routers may be sufficient to protect
the information. If an institution is primarily concerned with attacks
from the outside or views the entire network system as critical, a
network-based product may be appropriate. A combination of host- and
network-based IDSs may also be appropriate for effective system security.
Management should be aware that even after an IDS is in place, there may
be other access points to the bank's systems that are not being monitored.
Management should determine what types of security precautions are needed
for the other access points.
The placement of the IDS within the institution's system architecture
should be carefully considered. The primary benefit of placing an IDS
inside a firewall is the detection of attacks that penetrate the firewall
as well as insider abuses. The primary benefit of placing an IDS outside
of a firewall is the ability to detect such activities as sweeping, which
can be the first sign of attack; repeated failed log-in attempts; and
attempted denial of service and spoofing attacks. Placing an IDS outside
the firewall will also allow the monitoring of traffic that the firewall
stops.
PART THREE - RESPONSE: Discusses implementing an incident
response strategy for the response component of an institution's
information security program.
INCIDENT RESPONSE
After implementing a defense strategy and monitoring for new attacks,
hacker activities, and unauthorized insider access, management should
develop a response strategy. The sophistication of an incident response
plan will vary depending on the risks inherent in each system deployed and
the resources available to an institution. In developing a response
strategy or plan, management should consider the following:
The plan should provide a platform from which an institution can
prepare for, address, and respond to intrusions or unauthorized activity.
The beginning point is to assess the systems at risk, as identified in the
overall risk assessment, and consider the potential types of security
incidents.
The plan should identify what constitutes a break-in or system misuse,
and incidents should be prioritized by the seriousness of the attack or
system misuse.
Individuals should be appointed and empowered with the latitude and
authority to respond to an incident. The plan should include what the
appropriate responses may be for potential intrusions or system misuses.
A recovery plan should be established, and in some cases, an incident
response team should be identified.
The plan should include procedures to officially report the incidents
to senior management, the board of directors, legal counsel, and law
enforcement agents as appropriate.
Today's products not only can detect intrusions in real-time, but can
automatically respond to intrusions. Depending on the software,
information systems personnel can be notified on a real-time basis during
an attack, rather than detect the attack afterward during a manual log
review. Methods of notification can include e-mail, pager, fax, audio
alarm, or message displays on a computer monitor. Responses can include
shutting down the system, logging additional information, and disabling a
user's account (e.g., by disallowing a particular user account or Internet
address). Access can be disabled for a period sufficient for information
systems personnel to review the attack information or verify the user.
Also, an institution can add warning banners to protected systems,
notifying users that they are accessing a protected computer system.
When determining an appropriate response, a distinction should be made
between incidents in which actual changes to a system are suspected (e.g.,
changing audit logs) versus incidents in which system misuse is suspected
(e.g., unauthorized system access). Attempts to actually change the system
or data may warrant notifying a security officer, who could reconfigure
the identified weaknesses and/or communication paths. An appropriate
response to system misuse may include automatic log-off, warning messages,
or notifying the appropriate personnel.
Not only are attacks often undetected, in many cases identified attacks
are not reported. Institutions should develop a plan to respond to
unauthorized activities and involve law enforcement when appropriate.
Institutions should report suspected computer crimes and computer
intrusions on Suspicious Activity Reports (SARs) in accordance with the
guidelines outlined in Financial Institution Letter 124-97,
"Suspicious Activity Reporting," dated December 5, 1997. |