Action Summary

Security monitoring focuses on the activities and condition of network traffic and network hosts.  Activity monitoring is primarily performed to assess policy compliance, identify non-compliance with the institution’s policies, and identify intrusions and support an effective intrusion response.  Because activity monitoring is typically an operational procedure performed over time, it is capable of providing continual assurance.

Monitoring of condition is typically performed in periodic testing.  The assurance provided by condition monitoring can relate to the absence of an intrusion, the compliance with authorized configurations, and the overall resistance to intrusions.  Condition monitoring does not provide continual assurance, but relates to the point in time of the test.

Risk drives the degree of monitoring.  In general, risk increases with system accessibility and the sensitivity of data and processes.  For example, a high-risk system is one that is remotely accessible and allows direct access to funds, fund transfer mechanisms, or sensitive customer data.  Information-only Web sites that are not connected to any internal institution system or transaction-capable service are lower-risk systems.  Information systems that exhibit high risks should be subject to more rigorous monitoring than low-risk systems.

A financial institution’s security monitoring should, commensurate with the risk, be able to identify control failures before a security incident occurs, detect an intrusion or other security incident in sufficient time to enable an effective and timely response, and support post-event forensics activities.

Architecture Issues

Financial institution networks should be designed to support effective monitoring.  Design considerations include

• Network traffic policies that address the allowed communications between computers or groups of computers,
• Security domains that implement the policies,
• Sensor placement to identify policy violations and anomalous traffic,
• The nature and extent of logging,
• Log storage and protection, and
• Ability to implement additional sensors on an ad hoc basis.

Activity Monitoring

Activity monitoring consists of host and network data gathering, and analysis.  Host data is gathered and recorded in logs and includes performance and system events of security significance.  Host performance is important to identify anomalous behavior that may indicate an intrusion.  Security events are important both for the identification of anomalous behavior and for enforcing accountability. Examples of security events include operating system access, privileged access, creation of privileged accounts, configuration changes, and application access.  Privileged access may be subject to keystroke recording.  Sensitive applications should have their own logging of significant events.

Host activity recording is typically limited by the abilities of the operating system and application. 

Network data gathering is enabled by sensors that typically are placed at control points within the network.  For example, a sensor could record traffic that is allowed through a firewall into the DMZ, and another sensor could record traffic between the DMZ and the internal network.  As another example, a sensor could be placed on a switch that controls a subnet on the internal network and record all activity into and out of the subnet.

Network data gathering is governed by the nature of network traffic.  The activity recorded can range from parts of headers to full packet content.  Packet header information supports traffic analysis and provides such details as the endpoints, length, and nature of network communication.  Packet header recording is useful even when packet contents are encrypted.  Full packet content provides the exact communications traversing the network in addition to supporting traffic analysis.  Full packet content recording allows for a more complete analysis, but entails additional collection, storage, and retrieval costs.

Many types of network sensors exist.  Sensors built into some popular routers record activity from packet headers.  Host-based sniffer software can be used on a device that does not have an IP address. Some sensors are honeypots, or hosts configured to respond to network communications similar to other hosts, but exist only for the purpose of capturing communications.  Other sensors contain logic that performs part of the analysis task, alerting on the similarity between observed traffic and preconfigured rules or patterns.  Those sensors are known as “Intrusion Detection Systems.”

Network Intrusion Detection Systems

Network intrusion detection systems (nIDS) combine the detection and logging of potential attacks with pre-defined response actions.  These systems use one of two detection methodologies, signature and anomaly detection.   For response, the nIDS can perform one of several actions according to its configuration.  A passive nIDS could be configured to notify institution personnel, log the attack identification, and log packets related to the possible attack. A reactive IDS adds the capability to interact with the firewall to block communications from the user or IP address associated with the potential attack.  Conceptually, the reactive IDS is very similar to an intrusion prevention system (IPS), discussed in the “Access Control” section of this booklet. 

To use a nIDS effectively, an institution should have a sound understanding of the detection capability and the effect of placement, tuning, and other network defenses on the detection capability.

The signature-based detection methodology reads network packets and compares the content of the packets against signatures, or unique characteristics, of known attacks.  When a match is recognized between current readings and a signature, the nIDS generates an alert.

Signatures may take several forms.  The simplest form is the URL submitted to a Web server, where certain references, such as cmd.exe, are indicators of an attack.  The nature of traffic to and from a server can also serve as a signature.  An example is the length of a session and amount of traffic passed.

A weakness in the signature-based detection method is that a signature must exist for an alert to be generated.  Signatures are written to either capture known exploits, or access to suspected vulnerabilities.  Vulnerability-based detection is generally broader based, alerting on many exploits for the same vulnerability and potentially alerting on exploits that are not yet known.  Exploit-based signatures, however, are based on specific exploits and may not alert when a new or previously unknown exploit is attempted.

Attacks that generate different signatures from what the institution includes in its nIDS will not be detected.  This problem can be particularly acute if the institution does not continually update its signatures to reflect lessons learned from attacks on itself and others, as well as developments in attack tool technologies.  It can also pose problems when the signatures only address known attacks.  Another weakness is in the capacity of the nIDS to read traffic.  If the nIDS falls behind in reading network traffic, traffic may be allowed to bypass the nIDS.  That traffic may contain attacks that would otherwise cause the nIDS to issue an alert. 

The anomaly-based detection method generally detects deviations from a baseline.  The baseline can be either protocol-based, or behavior-based.    The protocol-based baseline detects differences between the detected packets for a given protocol and the Internet’s RFCs (Requests for Comment) pertaining to that protocol. For example, a header field could exceed the RFC-established expected size.

The behavior-based anomaly detection method creates a statistical profile of normal activity on the host or network.  Normal activity generally is measured based on the volume of traffic, protocols in use, and connection patterns between various devices.  Boundaries for activity are established based on that profile.  When current activity exceeds the boundaries, an alert is generated.  Weaknesses in this system involve the ability of the system to accurately model activity, the relationship between valid activity in the period being modeled and valid activity in future periods, and the potential for malicious activity to take place while the modeling is performed.  This method is best employed in environments with predictable, stable activity. 

Anomaly detection can be an effective supplement to signature-based methods by signaling attacks for which no signature yet exists.  Proper placement of nIDS sensors is a strategic decision determined by the information the institution is trying to obtain.  Placement outside the firewall will deliver IDS alarms related to all attacks, even those that are blocked by the firewall.  With this information, an institution can develop a picture of potential adversaries and their expertise based on the probes they issue against the network. 

Because the placement is meant to gain intelligence on attackers rather than to alert on attacks, tuning generally makes the nIDS less sensitive than if it is placed inside the firewall.  A nIDS outside the firewall will generally alert on the greatest number of unsuccessful attacks.  nIDS monitoring behind the firewall is meant to detect and alert on hostile intrusions.  Multiple nIDS units can be used, with placement determined by the expected attack paths to sensitive data.  Generally speaking, the closer the nIDS is to sensitive data, the more important the tuning, monitoring, and response to nIDS alerts. The National Institute of Standards and Technology (NIST) recommends network intrusion detection systems “at any location where network traffic from external entities is allowed to enter controlled or private networks.”

“Tuning” refers to the creation of signatures and alert filters that can distinguish between normal network traffic and potentially malicious traffic.  Tuning also involves creating and implementing different alerting and logging actions based on the severity of the perceived attack.  Proper tuning is essential to both reliable detection of attacks and the enabling of a priority-based response.  Tuning of some signature-based units for any particular network may take an extended period of time and involve extensive analysis of expected traffic. If a nIDS is not properly tuned, the volume of alerts it generates may degrade the intrusion identification and response capability.

Switched networks pose a problem for network IDS.  Switches ordinarily do not broadcast traffic to all ports, and a nIDS may need to see all traffic to be effective.  When switches do not have a port that receives all traffic, the financial institution may have to alter their network to include a hub or other device to allow the IDS to monitor traffic.

Encryption poses a potential limitation for a nIDS.  If traffic is encrypted, the nIDS’s effectiveness may be limited to anomaly detection based on unencrypted header information.  This limitation can by overcome by decrypting packets within the IDS at rates commensurate with the flow of traffic.  Decryption is a device-specific feature that is not incorporated into all nIDS units.

All nIDS detection methods result in false positives (alerts where no attack exists) and false negatives (no alert when an attack does take place).  While false negatives are obviously a concern, false positives can also hinder detection.  When security personnel are overwhelmed with the number of false positives, they may look at the nIDS reports with less vigor, allowing real attacks to be reported by the nIDS but not researched or acted upon.  Additionally, they may tune the nIDS to reduce the number of false positives, which may increase the number of false negatives.  Risk-based testing is necessary to ensure the detection capability is adequate.

Honeypots

A honeypot is a network device that the institution uses to attract attackers to a harmless and monitored area of the network.  Honeypots have three key advantages over network and host IDSs.  Since the honeypot’s only function is to be attacked, any network traffic to or from the honeypot potentially signals an intrusion.  Monitoring that traffic is simpler than monitoring all traffic passing a network IDS. Honeypots also collect very little data, and all of that data is highly relevant.  Network IDSs gather vast amounts of traffic which must be analyzed, sometimes manually, to generate a complete picture of an attack.  Finally, unlike an IDS, a honeypot does not pass packets without inspection when under a heavy traffic load.

Honeypots have two key disadvantages.  First, they are ineffective unless they are attacked.  Consequently, organizations that use honeypots for detection usually make the honeypot look attractive to an attacker.  Attractiveness may be in the name of the device, its apparent capabilities, or in its connectivity.  Since honeypots are ineffective unless they are attacked, they are typically used to supplement other intrusion detection capabilities.

The second key disadvantage is that honeypots introduce the risk of being compromised without triggering an alarm, thereby becoming staging grounds for attacks on other devices.  The level of risk is dependent on the degree of monitoring, capabilities of the honeypot, and its connectivity.  For instance, a honeypot that is not rigorously monitored, that has excellent connectivity to the rest of the institution’s network, and that has varied and easy-to-compromise services presents a high risk to the confidentiality, integrity, and availability of the institution’s systems and data.  On the other hand, a honeypot that is rigorously monitored and whose sole capability is to log connections and issue bogus responses to the attacker, while signaling outside the system to the administrator, demonstrates much lower risk.

Host Intrusion Detection Systems

Host intrusion detection systems (hIDS) also use signature-based and anomaly-based methods.  Popular hIDSs include anti-virus and anti-spyware programs (See the “Malicious Code Prevention” section of this booklet), as well as file integrity checkers.

A file integrity checker creates a hash of key binaries, and periodically compares a newly generated hash against the original hash.  Any mismatch signals a change to the binary, a change that could be the result of an intrusion.  Successful operation of this method involves protection of the original binaries from change or deletion and protection of the host that compares the hashes.  If attackers can substitute a new hash for the original, an attack may not be identified.  Similarly, if an attacker can alter the host performing the comparison so that it will report no change in the hash, an attack may not be identified.

An anomaly-based method monitors the application program calls to the operating system for unexpected or unwanted behavior, such as a Web server calling a command line interface, and alerts when unexpected calls are made.

Attackers can defeat host-based IDS systems using kernel modules.  A kernel module is software that attaches itself to the operating system kernel.  From there, it can redirect and alter communications and processing, hiding files, processes, registry keys, and other information.  With the proper kernel module, an attacker can force a comparison of hashes to always report a match and provide the same cryptographic fingerprint of a file, even after the source file was altered.  Kernel modules can also hide the use of the application program interfaces.  Detection of kernel modules can be extremely difficult.  Detection is typically performed through another kernel module or applications that look for anomalies left behind when the kernel module is installed.

Some host-based IDS units address the difficulty of performing intrusion detection on encrypted traffic.  Those units position their sensors between the decryption of the IP packet and the execution of any commands by the host.  This host-based intrusion detection method is particularly appropriate for Internet banking servers and other servers that communicate over an encrypted channel.  Kernel modules, however, can defeat these host-based IDS units.

Host-based intrusion detection systems are recommended by the NIST for all mission-critical systems, even those that should not allow external access.

Log Transmission, Normalization, Storage, and Protection

Network and host activities typically are recorded on the host and sent across the network to a central logging facility.  The data that arrives at the logging facility is in the format of the software that recorded the activity. The logging facility may process the logging data into a common format.  That process is called normalization.  Normalized data frequently enables timely and effective log analysis.

Log files are critical to the successful investigation and prosecution of security incidents and can potentially contain sensitive information.  Intruders will often attempt to conceal any unauthorized access by editing or deleting log files.   Therefore, institutions should strictly control and monitor access to log files whether on the host or in a centralized logging facility.  Some considerations for securing the integrity of log files include

• Encrypting log files that contain sensitive data or that are transmitting over the network;
• Ensuring adequate storage capacity to avoid gaps in data gathering;
• Securing back-up and disposal of log files;
• Logging the data to a separate, isolated computer;
• Logging the data to write-only media like a write-once/read-many (WORM) disk or drive; and
• Setting logging parameters to disallow any modification to previously written data.

Condition Monitoring

Condition monitoring tools include self-assessments, metrics, and independent tests.

Self Assessments

Self-assessments are useful in providing a warning flag to line management so problems can be addressed before they arise in testing reports.  Self-assessments may be performed by operations personnel or by vendors under the direction of those at the institution who are responsible for the systems being assessed.  Self-assessments may use tools and techniques similar to independently performed audits and penetration tests, and include:

• Assessing conformance to policies and procedures, including service provider oversight;
• Scanning for technical vulnerabilities;
• Verifying that device and network configurations are authorized and changes are properly processed;
• Verifying that information is stored only where authorized;
• Reviewing the adequacy of the risk assessment and monitoring plans; and
• Reviewing test results.

Metrics

Metrics can be used to measure security policy implementation, the effectiveness and efficiency of security services delivery, and the impact of security events on business processes.  The measurement of security characteristics can allow management to increase control and drive improvements to the security process.  

Metrics may not measure conformance to policy directly.  Policies frequently are general statements that lack the specificity necessary for measurement.  Metrics generally are formed to measure conformance to the standards and procedures that are used to implement policies.  Those standards may be developed by the institution, developed or recognized by the financial institution industry (e.g. BITS), or developed or recognized for business in general.  An example of the third is ISO 17799.

The adoption of standards, however, does not mean that a metrics system can or should be instituted.  Metrics are best used in mature security processes, when

• Information measures are quantifiable and readily obtainable, and
• Processes are repeatable.

The degree to which a security metrics program mitigates risk is a function of the comprehensiveness and accuracy of the measurements and the analysis and use of those measurements.  The measurements should be sufficient to justify security decisions that affect the institution’s security posture, allocate resources to security-related tasks, and provide a basis for security-related reports.

Independent Tests

Independent tests include penetration tests, audits, and assessments. Independence provides credibility to the test results. To be considered independent, testing personnel should not be responsible for the design, installation, maintenance, and operation of the tested system, or the policies and procedures that guide its operation.  The reports generated from the tests should be prepared by individuals who also are independent of the design, installation, maintenance, and operation of the tested system.

Penetration tests, audits, and assessments can use the same set of tools in their methodologies.  The nature of the tests, however, is decidedly different.  Additionally, the definitions of penetration test and assessment, in particular, are not universally held and have changed over time.

Penetration Tests.  A penetration test subjects a system to the real-world attacks selected and conducted by the testing personnel.  The benefit of a penetration test is that it identifies the extent to which a system can be compromised before the attack is identified and assesses the response mechanism’s effectiveness. Because a penetration test seldom is a comprehensive test of the system’s security, it should be combined with other monitoring to validate the effectiveness of the security process.

Audits.  Auditing compares current practices against a set of standards.  Industry groups or institution management may create those standards.  Institution management is responsible for demonstrating that the standards it adopts are appropriate for the institution.

Assessments.  An assessment is a study to locate security vulnerabilities and identify corrective actions.  An assessment differs from an audit by not having a set of standards to test against.  It differs from a penetration test by providing the tester with full access to the systems being tested.  Assessments may be focused on the security process or the information system.  They may also focus on different aspects of the information system, such as one or more hosts or networks.

Key Factors

Management is responsible for considering the following key factors in developing and implementing independent tests:

Personnel.  Technical testing is frequently only as good as the personnel performing and supervising the test.  Management is responsible for reviewing the qualifications of the testing personnel to satisfy itself that the capabilities of the testing personnel are adequate to support the test objectives.

Scope.  The tests and methods utilized should be sufficient to validate the effectiveness of the security process in identifying and appropriately controlling security risks.

Notifications.  Management is responsible for considering whom to inform within the institution about the timing and nature of the tests. The need for protection of institution systems and the potential for disruptive false alarms must be balanced against the need to test personnel reactions to unexpected activities.

Data Integrity, Confidentiality, and Availability.  Management is responsible for carefully controlling information security tests to limit the risks to data integrity, confidentiality, and system availability.  Because testing may uncover nonpublic customer information, appropriate safeguards to protect the information must be in place.  Contracts with third parties to provide testing services should require that the third parties implement appropriate measures to meet the objectives of the 501(b)  guidelines.  Management is responsible for ensuring that employee and contract personnel who perform the tests or have access to the test results have passed appropriate background checks, and that contract personnel are appropriately bonded.  Because certain tests may pose more risk to system availability than other tests, management is responsible for considering whether to require the personnel performing those tests to maintain logs of their testing actions.  Those logs can be helpful should the systems react in an unexpected manner.

Confidentiality of Test Plans and Data.  Since knowledge of test planning and results may facilitate a security breach, institutions should carefully limit the distribution of their testing information.  Management is responsible for clearly identifying the individuals responsible for protecting the data and providing guidance for that protection, while making the results available in a useable form to those who are responsible for following up on the tests. Management also should consider requiring contractors to sign nondisclosure agreements and to return to the institution information they obtained in their testing. 

Frequency.  The frequency of testing should be determined by the institution’s risk assessment.  High-risk systems should be subject to an independent test at least once a year.  Additionally, firewall policies and other policies addressing access control between the financial institution’s network and other networks should be audited and verified at least quarterly.  Factors that may increase the frequency of testing include the extent of changes to network configuration, significant changes in potential attacker profiles and techniques, and the results of other testing. 

Proxy Testing.  Independent testing of a proxy system is generally not effective in validating the effectiveness of a security process.  Proxy testing, by its nature, does not test the operational system’s policies and procedures, or its integration with other systems.  It also does not test the reaction of personnel to unusual events.  Proxy testing may be the best choice, however, when management is unable to test the operational system without creating excessive risk. 

Analysis and Response

The analysis and response to activity and condition monitoring is performed differently in financial institutions of different size and complexity.  Smaller and less complex institutions may assign operational personnel to the analysis and response function.  Larger and more complex institutions may maintain a security response center that receives and analyzes the data flows as activity occurs.  Additionally, institutions of all sizes may outsource various aspects of the analysis and response function, such as activity monitoring.  Outsourcing does not relieve the institution of the responsibility for ensuring that control failures are identified before a security incident occurs, an intrusion or other security incident is detected in sufficient time to enable an effective and timely response, and post-event forensics activities are supported.

Security Incidents

An internal security response center serves as a central location for the analysis and investigation of potential security incidents.  To serve in that role, the security response center should consider, evaluate, and respond to both external threats and internal vulnerabilities.  Sources of external threat information include industry information sharing and analysis centers (ISACs), Infraguard, mailing lists, and commercial reporting services. Internal vulnerability information is available from condition reporting and activity monitoring.  Security response centers should be able to access all relevant internal vulnerability information in a read-only manner.  That data may reside in centralized log repositories, on the devices that perform the logging, and in results of self-assessments and independent tests.   Security response centers also should have available tools to analyze the logs and to perform ad hoc activity monitoring.  Other additional and useful data sources are reports of anomalies in both network and host performance and the end-user experience.  The latter relates both to internal users as well as contractors and customers who use the institution’s systems.

Because the identification of incidents requires monitoring and management, response centers frequently use SIM (security information management) tools to assist in the data collection, analysis, classification, and reporting of activities related to security incidents.

The security response center should be governed by policies and procedures that address security incidents:  

• Monitoring policies should enable adequate continual and ad-hoc monitoring of communications and the use of the results of monitoring in subsequent legal procedures.  The responsibility and authority of security personnel and system administrators for monitoring should be established, and the tools used should be reviewed and approved by appropriate management with appropriate conditions for use.
• Classification policies should be sufficiently clear to enable timely classification of incidents into different levels of severity.  Response and reporting levels should be commensurate with the severity levels.
• Escalation policies should address when different personnel within the organization will be contacted about the incident, and the responsibility those personnel have in incident analysis and response.
• Reporting policies should address internal and external reporting, including coordination with service providers and reporting to industry ISACs.

Additionally, a policy should address who is empowered to declare an incident to be an intrusion.

The effectiveness of a security incident response center also is a function of the training and expertise of the security analysts.  A financial institution should ensure that its analysts are sufficiently trained to appropriately analyze network and host activity and to use the monitoring and analysis tools made available to them.

Intrusion Response

The goal of intrusion response is to minimize damage to the institution and its customers through containment of the intrusion, the restoration of systems, and providing assistance to customers.

The response primarily involves people rather than technologies. The quality of intrusion response is a function of the institution’s culture, policies and procedures, and training. 

Preparation determines the success of any intrusion response.  This involves defining the policies and procedures that guide the response, assigning responsibilities to individuals, providing appropriate training, formalizing information flows, and selecting, installing, and understanding the tools used in the response effort.  Key considerations that directly affect the institution’s policies and procedures include the following:

• How to balance concerns regarding availability, confidentiality, and integrity for devices and data of different sensitivities.  This consideration is a key driver for a containment strategy and may involve legal and liability considerations.  An institution may decide that some systems must be disconnected or shut down at the first sign of intrusion, while others must be left on line.
• When and under what circumstances to invoke the intrusion response activities, and how to ensure that the proper personnel are notified and available.
• How to control the frequently powerful intrusion identification and response tools.
• When to involve outside experts and how to ensure the proper expertise will be available when needed.  This consideration addresses both the containment and the restoration strategy.
• When and under what circumstances to notify and involve regulators, customers, and law enforcement.  This consideration drives certain monitoring decisions, decisions regarding evidence-gathering and preservation, and communications considerations.
• Which personnel have authority to perform what actions in containment of the intrusion and restoration of the systems.  This consideration affects the internal communications strategy, the commitment of personnel, and procedures that escalate involvement and decisions within the organization.
• How and what to communicate outside the organization, whether to law enforcement, supervisory agencies, customers, service providers, potential victims, and others.  This consideration drives the communication strategy and is a key component in mitigating reputation risk.
• How to document and maintain the evidence, decisions, and actions taken.
• What criteria must be met before compromised services, equipment, and software are returned to the network. 
• How to learn from the intrusion and use those lessons to improve the institution’s security.
• How and when to prepare and file a Suspicious Activities Report (SAR).

Successful implementation of any response policy and procedure requires the assignment of responsibilities and training.  Some organizations formalize the response program with the creation of a computer security incident response team (CSIRT).  The CSIRT is typically tasked with performing, coordinating, and supporting responses to security incidents.  Due to the wide range of technical and nontechnical issues that are posed by an intrusion, typical CSIRT membership includes individuals with a wide range of backgrounds and expertise, from many different areas within the institution.  Those areas include management, legal, public relations, as well as information technology.  Other organizations may outsource some of the CSIRT functions, such as forensic examinations.  When CSIRT functions are outsourced, institutions should ensure that the service provider follows the institution’s policies and maintains the confidentiality of data.

Institutions should assess the adequacy of their preparations through testing.

While containment strategies between institutions can vary, they typically contain the following broad elements:

• Isolation of compromised systems, or enhanced monitoring of intruder activities;
• Search for additional compromised systems;
• Collection and preservation of evidence; and
• Communication with effected parties, the primary regulator, and law enforcement.

Restoration strategies should address the following:

• Elimination of an intruder’s means of access;
• Restoration of systems, programs and data to known good state;
• Filing of a SAR (guidelines for filing are included in individual agency guidance), and
• Initiation of customer notification and assistance activities consistent with interagency guidance.

Outsourced Systems

Management is responsible for ensuring the protection of institution and customer data, even when that data is transmitted, processed, stored, or disposed of by a service provider.  Service providers should have appropriate security monitoring based on the risk to their organization, their customer institutions, and the institution’s customers.  Accordingly, management and auditors evaluating TSPs should use the guidance in this booklet in performing initial due diligence, constructing contracts, and exercising ongoing oversight or audit responsibilities.  Where indicated by the institution’s risk assessment, management is responsible for monitoring the service provider’s activities through review of timely audits and test results or other equivalent evaluations.