Memorandum

Research and Development Initiatives Focused on
Preventing, Detecting, and Responding to Insider Misuse
of Critical Defense Information Systems

Results of a Three-Day Workshop

Executive Summary

Although the workshop's main purpose was to propose technical research initiatives, it was clear to all participants that enabling policies are required in order for the results of insider threat research to be effective. Policies and procedures needed to form an environment for mitigating the insider threat include: guidance and requirements for researchers from the legal and law enforcement communities regarding the attribution, collection, maintenance, processing, and storage of data in a manner that allows proper forensic analysis, and a trail of custody to permit later legal prosecution; clear definitions regarding what constitutes "critical assets" on a system to be protected against insider misuse; clarity about the definition of an "insider;" cost/benefit analysis to help determine whether the cost to personnel and organizations, as well as dollar cost, of new security procedures are worth the security benefits obtained; plans for technology transfer; and support of multiple, diverse, concurrent approaches.

Another theme pervading the workshop was that the insider threat is not unique unto itself; it is part of overall information system security. Many of the research initiatives proposed cross-cut with "traditional" information security measures. The insider threat particularly raises issues of personnel screening/testing procedures and other policies that were not the focus for this workshop. It was clear, however, that there are specific insider threat problems that can be addressed by information system initiatives and technologies. To the extent possible, participants tried to emphasize the insider-unique characteristics of the approaches that were discussed.

Workshop discussions and breakout groups used the following categories in describing possible research initiatives: those addressing threats and vulnerabilities, prevention, detection, and response. We summarize here the key recommendations in each of those categories.

Threats and vulnerabilities. A threat has as elements motivation, opportunity, vulnerability in the target system, and skill adequate to exploit the vulnerabilities. The primary research initiative aimed at countering threats and vulnerabilities was:

• Develop an insider trust model. The category "insider" includes, among many others, part-time employees, temporary employees, and occasional insiders. What degree of trust should be given to each such category? How can this level of trust be represented explicitly - perhaps even in machine-readable form - so that various processes within the system can take cognizance of those varying levels of trust?

• Create a set of authentication components. Such components must apply to a multi-tier transactional environment. They must bind keys and tokens to users. They must meet performance and operational standards such as exceeding 1000 transactions per second. They must include practical revocation and recovery. And they must integrate with the various applications in use within the system.

• Develop access control components, for both normal and privileged users. We need finer-grained access control to reduce vulnerability to the insider threat, but such granularity is expensive. Most existing controls are for single platforms only. We need inter-platform access-control management. A key research need is means of reducing the management cost of implementing and maintaining access controls. Privileged users are a special case: Whoever controls the access controls is the primary insider issue. The question is how to mitigate risks from malicious system or security administrators, and other privileged users. One aspect of access control is malicious code containment, so that access to important system components is limited for malicious code introduced to a system.

• Develop trusted paths to security systems. Even if system integrity is assured, there are alternative means by which a malicious user can gain system privileges - for example, by spoofing the graphic user interface by which a user is asked for his login and password. A potential solution is obtaining an assured trusted path to the security system. The availability of such a path is a fundamental component of a secure architecture.

• Develop profiling as a technique. A "user profile" contains information that characterizes users or agents, and may help to distinguish one user from another. (The term "user" here may refer to a process, command, function, etc.) The profile may contain such information as those files and processes normally accessed; periods of time that user is normally logged in; keystroke patterns; and a wide variety of other attributes. With such profiles available, it is then possible to develop anomaly detection for unauthorized results that have not been previously encountered.

• Detect misuse of applications. Persons concerned with the "insider problem" often focus on insiders' inappropriate access to data. However, another useful indicator of misuse is inappropriate use of processes and applications within the system. (A most obvious example is an attempt to use system processes to obtain root access.)

• Provide traceability for system-object usage. It would be highly desirable to develop audit trails of the path of usage of system objects such as files and programs. If misuse is suspected, these audit trails could be investigated to determine the set of users accessing an object, or passing a system object among them.

• Identify critical information automatically. Contemporary information systems contain a constantly shifting collection of gigabytes of data and information. It seems unlikely that static lists of critical files and processes will remain relevant. This research recommendation addresses the question: Can procedures be developed by which critical information within a system is identified automatically?

• Design systems for detectability. Detecting misuse by an insider is very difficult. It could be made easier if the inherent architecture and design of an information system was created with detectability of misuse in mind. This research task aims at creating system design principles that have detectability as one of their primary features. One important aspect of detectability is determining unauthorized changes due to physical access. A distinguishing characteristic of insiders is that they often have physical access (at varying levels) to system facilities. As such, they can make physical changes to the system -- such as installing temporarily another client or host computer on the network, rerouting a cable, or plugging in a modem -- that are precluded to outsiders. It is therefore important to monitor for and detect such physical changes to a system, preferably in real-time.

• Incorporate practical autonomic system response into production systems. Insiders can carry out destructive acts in seconds. Spontaneous system responses to detected incidents may at times be required in order to thwart or mitigate damage in similar time scales - which would imply use of automated response procedures. The question is: How can these be developed so that they can be effective while not causing more harm than good. In particular, if a malevolent insider knows such an autonomic system is in use, it could be used to harm the system itself. If system developers built capabilities relevant to response into system architectures, it would be much easier to initiate effective response, perhaps autonomically, within critical information systems.

• Develop data correlation tools, including data reduction for forensics, and visualization tools focused on internal misuse. In responding to a potential or actual misuse incident, data from multiple sources must be correlated and analyzed very quickly, data captured and stored for forensic analysis, and complex patterns visualized and analyzed to obtain understanding so that response can proceed. Such tools are currently lacking, especially when confronted with an insider threat - in which case many traditional sources, such as those associated with a firewall, may be unavailable or irrelevant.

• Develop a capability for surveillance of non-networked components. Not all information "system" components are on-line and capable of being queried for relevant data. Telephone logs, timecard data, various hardware settings, and so on may be relevant to determining a response, but be unavailable to correlation and fusion activities. To enable rapid and relevant response, it is highly desirable that all relevant data be collectable in real-time.

• Consider deception technologies specifically applicable to the insider threat. Deception has long played a vital role in military operations -- both offensive and defensive. It has tantalizing capabilities to aid in determining aspects of insider misuse that are otherwise hard to discover - in particular, the interests and intentions of a malicious insider, and that person's level of sophistication in understanding and using system facilities. Research should be conducted on the appropriate uses of deception to aid in understanding attributes of the malicious insider, and to divert him or her from critical system files and processes.

Background

On August 16-18, 1999, a three-day invited workshop (expected to be the first in a series) was held at the facilities of the RAND Corporation, Santa Monica CA, specifically to address and recommend technical research and development initiatives focused on mitigating the insider threat. The workshop was sponsored by NSA/R2 (Dick Brackney), DARPA/ISO (Sami Saydjari), and the Army Research Laboratory (Paul Walczak). A complete list of attendees is shown in Attachment 2. The agenda for the workshop is given in Attachment 3.

The IPT report's recommendations focus on near-term steps that can be taken, preferably at modest time and cost, to mitigate the insider problem. This workshop can be considered a supplement to that report, focusing instead on more significant, specific R&D initiatives that can be taken to address the insider problem at a more fundamental level.

This report summarizes the workshop's key findings and recommendations. Four categories of breakout sessions were used during the workshop: on the threat, prevention, detection, and response. We use those same categories here in describing the workshop's results.

Prologue: Policy and Precursors

PR1: The research community needs guidance and requirements from the legal and law enforcement community regarding the attribution, collection, maintenance, processing and storage of data. In the IPT report, there are frequent references to developing an untamperable audit trail, so that detected misuse by insiders can stand up to legal scrutiny in court. Before researchers can develop technical means of collecting and storing data indicating insider misuse, they need clear guidance from those who perform forensic analysis and later legal prosecution regarding the requirements to be met by such data, and by the trail of custody within which it is kept.

PR2: Clear definitions are needed regarding what constitutes "critical assets" on a system to be protected against insider misuse. It was clear to participants that it is difficult if not impossible to protect all data on a system against all forms of misuse. Therefore, each information system should be accompanied by a clear statement - available to users and system administrators alike - regarding what assets on the system are regarded as critical, and whose misuse will be treated as a punishable offense. Perhaps there might be several such categories or gradations. But without such clear guidance, it is difficult to focus preventative and detection measures on those assets that are deemed critical, and without such focus the efforts at data collection and analysis are likely to be overwhelmed by the "noise" of lesser offenses, mistakes, and the like. Once such guidance regarding what is critical information is available - preferably in machine-processable form - it might be possible to institute automatic or semi-automatic means of assessing the criticality of information as it is created, manipulated, and stored within an information system. (See recommendation D4, below.)

As a corollary to this requirement, it is necessary for DoD to provide explicit guidance regarding which information systems as a whole are deemed critical - again, so that limited R&D and operational resources can be focused on those whose operation and data are most valuable and that need to be most protected.[3]

PR3: Be clear about the definition of an "insider."

One difficulty in discussing the insider threat was lack of a common understanding and definition of the term "insider threat." It was clear from discussions in the workshop that the term was like a chameleon - its "color" can change depending upon both the insider and the insider's environment. It is likely that "insider threat" is too broad of a term to usefully consider specific problems and their potential solutions. However, a number of possible insider threat descriptors or metrics were captured at the workshop that might help narrow future discussions.

Defining the environment:

Cyber access - "logical perimeter" Does the particular problem include some type of cyber defense perimeter such as routers, firewalls, and protective applications?

Technical environment The technical details of the environment will likely have an effect on the insider threats that might present themselves and the way in which an insider operates.

Law enforcement environment Are there any restrictions or requirements about preparation for or response to an insider event that are important for law enforcement activity? An example is integrity of evidence and chain of custody. A particular concern is the conflicts this item may have with the technical environment.

Defining the insider:

Novice - Sophisticated What level of skill does the insider possess? This includes factors such as the amount of preparation taken, the adversity to detection, etc.

Knowledge of internal environment How much does the insider know about the workings of the system inside the spatial or logical perimeter? Various degrees of insider knowledge and understanding were discussed at the workshop.

Innate privileges What privileges does the insider have both physically and administratively? This is related in part to knowledge of the internal environment.

Degree of Affiliation. The relationships among insiders, their specific roles/privileges and the nature of their affiliation with the system's organization helps to provide greater understanding of the threat. Insider threat characterizations that differentiate permanent, part-time, temporary, outsource, former insiders, and system developers, help to identify unique opportunities, motivations, skills and vulnerabilities that might otherwise be overlooked.

Human - Code/Hardware Is the insider a person, software, firmware, or hardware? There was much discussion at the workshop that an insider did not have to be a person. For example, malicious code was viewed to be important and currently a poorly addressed insider threat.

The IPT report defines an insider as anyone who is or has been authorized access to a DoD information system whether a military member, a DoD civilian employee, or employee of another Federal agency or the private sector. It provides a table (in section 2.2) that includes within this definition contractors, network-connected users at colleges and universities, foreign partners, and vendors and suppliers. Although our workshop used the IPT report as source material, considerable discussion focused on other definitions, such as persons having a "trust" relationship with the organization in question. If insider definitions are so broad as to encompass 100,000 employees of Microsoft, Sun Microsystems, or Cisco (as vendors to DoD), those definitions lose most of their force and focus. If limited R&D resources are to be focused explicitly on the "insider," what definition should be used - at least by the research community - to focus their efforts on truly critical breaches of trust by "insiders"?

Among the statements made at the workshop regarding the definition of "insider" were these:

• "Insider" can be characterized based on technology management roles (and the trust relationship with which each role is accorded), as well as process accessibility inside the organizational domain of control (with respect to the degree of confidentiality, integrity, and availability accorded). For example, an insider who attempts to achieve an objective by violating confidentiality requirements is more likely to engage in covert activities, hoping to avoid detection by the enforcement/oversight mechanisms within the victim organization. By contrast, an insider whose objective is to interfere with corporate business processes may execute denial-of-service actions expecting that his/her acts will become readily apparent, but not attributable.

• Three aspects possibly differentiating an insider from an outsider are: (1) knowledge of the internal environment; (2) speed of attack, based on availability; (3) relative ease of accessibility.

• What constitutes an "insider" differs between law enforcement and technical personnel. For law enforcement, the Insider Threat involves use of internal knowledge by people authorized to use the system; the threat involves a violation of trust within the group of persons given that trust. For technologists, the Insider Threat is that which happens inside the security perimeter, i.e., behind the firewall, from the perspective of the operating system components. The "insider" is anyone influencing a process operating inside a group of trusted hosts or within system protection domains.

• Military personnel can be especially prone to negative motivations that lead to their becoming an insider threat, due to lifestyle restrictions imposed as part of their "service contract;" 7x24 service; attestation to a new set of "military values;" the sacrifice of some liberties; pressures toward conformity - social, moral, cultural; arduous work and living conditions; fatigue; boredom. Additionally, aspects of military culture that denigrate support and technical roles, especially within combat organizations, can exacerbate vulnerabilities to the insider threat. These cultural conditions can stimulate malicious insider activity by service members as well as the exodus from active duty of knowledgeable military personnel who may now bear hostilities as "former insiders." Several of these factors can lead to disillusion.

• The military's Total Force concept, using reserves and the National Guard, creates "part-time" insiders. Other "insiders" are created by Combined Warfare, comprising alliances, coalitions, and host-nation support .

• There is accelerated information technology infusion underway (e.g., the First Digitized Division; Army XXI; Navy IT 21). In addition, a torrent of Y2K "fixes" will introduce new bugs into an immature, unproven information technology environment. Software agent/mobile code technology may represent a non-human variant of the "insider threat," and outsourcing beyond existing manning to sustain operations creates "partnering insiders."

PR4: Cost/benefit analysis is vital. Implementation of many of the recommendations in the IPT report, and results likely to emerge from new R&D initiatives, almost invariably place additional constraints on users or systems. Such constraints may well negatively impact productivity. They may, in fact, "turn off" users and sysadmins to the point where they develop alternatives to the use of these protective/detective/reactive measures. A serious cost/benefit analysis must be done for the recommendations of the IPT report, weighing potential safety/security benefits against personal and organizational impacts on productivity and effectiveness. Similarly, this same analysis must be done before implementing outcomes from the R&D initiatives proposed in this document. We realize, however, that cost/benefit analysis is very difficult when the "benefit" of security is somewhat intangible, as is the "cost" to personnel and organizations (not to mention dollar cost) which is equally difficult to measure. Perhaps economists, organizational researchers and researchers in other such disciplines should be marshaled to address this difficult analysis problem explicitly.

PR5: Detection should include (but not be limited to) host-based information. Many information assurance measures have been tailored to preventing outsiders from obtaining access to systems. Such measures have therefore concentrated on "firewalls" placed on entrances to internal networks, or on network monitoring tools that examine network packets for abnormal patterns or for "signatures" of known attack techniques. However, the insider is not coming in through external portals; therefore, it is important to consider the "host" or "client" computer (e.g., desktop computer or workstation) used by an insider in monitoring and detection systems aimed at detecting insider misuse.

PR6: Facilitate and plan for technology transfer. It is a commonplace in the research community to lament that most of what is known about effective security practices in the design, implementation, and operation of information systems is not, in fact, being used in contemporary operating systems, application programs, and networks. In fact, much of the output of the computer security research community over the past several decades has not found its way into COTS products heavily used by DoD and others. There appears to be a gap between "research and early prototype development" and the next step - serious development for widespread test and evaluation. There are a number of approaches being investigated toward bridging this gap, such as DARPA's Technology Integration Center (TIC), but more needs to be done on this issue.

PR7: There are effective approaches to the insider threat that are not technology-based. It was noted by workshop participants that - although this workshop concentrated on technology R&D approaches - there are other means of combating the insider threat. (In particular, approaches involving training, education, responsible system administration, management initiatives, and so on, are mentioned in the IPT report.) An example stressed by one participant was greater use of polygraph tests for insiders on critical information systems. Such tests have been used to uncover patterns of misuse that would otherwise go undetected.

PR8: Develop a database of case studies of insider misuse. To guide research and other policy/procedural initiatives for mitigating insider misuse, we need better data on the aims, means, level of sophistication, and degree of success of insiders that have misused important DoD information systems. Only by analysis of such data can we be assured that initiatives to stem misuse are aimed in appropriate areas, and that important misuse methods have not been overlooked.

PR9: There is no silver bullet. We need multiple, diverse, concurrent approaches. It was clear to participants that "defense in depth" is vital. Multiple approaches must be used, and to the extent possible the findings and sensings from multiple probes and detectors, and multiple protection systems, must be coordinated and correlated to understand when a vulnerability exists and is being exploited. Especially in the case of insiders, there need be no explicit "vulnerability" at all; an insider may have valid access to critical, sensitive data, and in one download or e-mail attachment create a very significant security breach. In that sense, no one should expect the insider problem to be "solved" - at best, we can protect, detect and react in such a manner as to mitigate the problem to the extent possible.

In the explicit R&D recommendations that follow, we attempt where possible to state specific research objectives, success metrics, and open research problems. We also try to characterize factors that distinguish the unique insider-related problems and approaches from those of more general information security. However, there is considerable overlap between security approaches needed for general information security and those specifically tailored toward to the insider threat. It is often the case that general security awareness, training, education, protection, detection, and reaction measures will assist directly with the insider problem also.

Insider Threats and Vulnerabilities

The workshop breakout session on insider threats and vulnerabilities modified a JTF-CND (Joint Task Force - Computer Network Defense) vugraph to provide an overview of the distinctions among an incident, an attack, and a specific event (Figure 1). This figure also indicates the roles of an attacker's motivation combined with access (providing an opportunity), plus use of skills and tools, and shows the role of detection technology when an event has occurred. As indicated in the figure, a threat comprises four elements:

• Motivation

• Opportunity to pursue motives

• Vulnerability in the target information system, and

• Skills adequate to exploit the vulnerability.

The "threat" breakout group characterized the impact of an insider threat in three categories:

• The degree of "reach" (i.e., exposure, or risk), to critical components and to sensitive data, and the associated cost of restoration

• The frequency and intensity of occurrence, and the cost of detection

• Business and technical impacts of the threat.

The threat group highlighted four areas in which research activities should be conducted:

T1: Develop reactive configuration controls, in which an unauthorized result is mapped back to a specific type of threat. When the results of a misuse event is detected, there should be means for deciding the nature and severity of the threat represented by that event. Depending on the nature and severity of the threat, it may be possible to automatically reconfigure the system to react in such a manner that further threat is minimized.

Research objectives:

1. Characterize the insider threat.

1. Ability to distinguish a variety of threat conditions over a range of environments.

2. Demonstrate ability to respond to tune technology to achieve high-fidelity sensitivity to anomalous insider activity.

Certain routine insider activity might be interpreted as malicious behavior using the "outsider" perspective for information assurance

Open research problems:

1. Identify insider misuse characteristics with respect to various operating environments, topologies, applications and roles.

2. Compare and contrast insider vs. outsider ability to achieve adverse, unauthorized results.

3. Demonstrate that computer security events can be traced back to specific insiders, even when the insider attacks from "outside" the trusted domain.

Research objectives:

1. Develop a model of trust that envelops the full breadth of roles for which an organization authorizes degrees of technical configuration control privilege.

1. User/process classes, roles and use-cases are documented in some hierarchical, form, either as a data schema or a matrix of conditions, that clearly delineates the privileges authorized to a user for any system resource during any potential system state.

The degree of certain attributes of the trust relationship is the key distinguishing attribute separating a notion of insider from outsider.

Open research problems:

1. Develop a characterization schema describing representative user (insiders) roles and privileges in a DoD environment, that covers the full spectrum of military operations.

2. Differentiate between the various roles identified in (1) and develop parametric sensitivity criteria that can be used to recognize attempted unauthorized escalation of privilege within the timeframe between vulnerability exploitation and achievement of adverse objective ( potential security breaching event).

T4: Identify signatures of unauthorized results. What, in fact, are the indicators that a system has been misused? We cannot know the level of threat we face if we cannot identify unauthorized results when they are present. Developing "signatures" of unauthorized results (e.g., based on case studies and analysis of misuse possibilities) is one research approach.

Research objectives:

1. Focus insider misuse detection upon unique vulnerabilities presented by the insider threat (lead into detection recommendations).

2. Develop an understanding of insider patterns that can be detected by machines.

1. Identification of patterns of misuse unique to insider threat.

Self-explanatory; objective here is to find insider-distinguishing patterns of misuse.

Open research problems:

1. Prove that sensors can reliably alert to specific examples of signatures identified above (related to detection recommendations elsewhere in this report)

The prevention breakout group chose to identify components that are necessary for solving the insider threat: authentication, access control, system integrity, trusted path, and attribution. These components were each expanded upon and provided below as P1 through P5.

Discussions in this group identified no key "insider distinguishing factors" that were unique for the prevention view of the insider threat (especially in the component view provided in this section), or that were particularly different from other (vulnerabilities, detection, response) workshop discussion. Therefore, this characteristic is not identified individually for P1 through P5. However, several specific points were captured on this topic:

• Only the insider can abuse authority or trust (by definition), and knowledge is not equivalent to trust in this context

• Insiders have superior knowledge of asset value, thus increased vigilance is required on high-value assets

• One can arrest an insider, while arresting an outsider can be problematic. (In a prevention context, possibility of an "arrest" may deter inappropriate insider activity. Also, it can complicate the related preventative measures that are necessary, such as providing sufficient and verifiable evidence.)

P1: Develop authentication components. The ability to uniquely identify entities in a system and between systems with a high level of assurance provides a foundation for one class of solutions to the insider threat. If entities are identified with certainty, their activity can be tracked, analyzed, and controlled. In addition, without strong authentication systems, all methods of detection and response are more likely to be subverted and rendered ineffective.

Some authentication technologies are beginning to become available with a limited scope and are not intended to scale to complex systems or systems with complex interactions. The problem is further complicated in that a sophisticated insider may have the ability to subvert authentication components that might otherwise flag inappropriate activity.

Research objectives:

1. Extend technologies to work in multi-tier transactional environments.

2. Ability to bind keys and tokens to users.

3. Strong authentication that can scale for increasing transaction rates.

4. Ability to include practical revocation and recovery.

1. Systems that meet performance and operational standards as necessary for users, such as ability to exceed 1000 transactions per second.

2. Number of strong authentication tools widely available in COTS.

1. See research objectives.

Research objectives:

1. Development of finer-grained access control that is affordable.

2. Inter-platform access control management.

3. Reducing management cost of implementation and maintenance of access controls.

4. Developing new types of access control that reduce vulnerability to trusted insiders.

1. Granularity of access control.

2. Number (diversity) of access control methods.

1. See objectives.

2. Expert system based access control automation that is able to translate natural language policy statements into machine-level policy.

3. Meta-access control system for cross-platform access management.

4. Robust and secure mechanisms for providing access control in order to prevent it becoming a single point of failure.

5. Ability to prevent insider misuse from security administrators and other privileged users.

Research objectives:

1. Malicious code detection

2. Arbitrary corruption prevention

3. Develop boot sequence integrity

4. Total system configuration management (for both hardware and software).

1. Number of COTS systems that implement thorough integrity checking.

1. See research objectives.

Research objectives:

1. Develop cross-platform trusted paths, both ways

2. Develop two-way trusted paths in distributed systems

3. Find ways to make trusted path concepts and techniques widely available in security architectures

4. Find ways to instruct current-generation system developers in security techniques that are known, but not being applied.

1. Number of COTS systems implementing thorough trusted path procedures.

1. See research objectives.

Detection

D1: Develop profiling as a technique. A "user profile" contains information that characterizes users or agents, and may help to distinguish one user from another. (Note: the term "user" here may refer to a process, command, function, etc.) The profile may contain such information as those files and processes normally accessed; periods of time that user is normally logged in; keystroke patterns; and a wide variety of other attributes. With such profiles available, it is then possible to develop anomaly detection for unauthorized results that have not been previous encountered. Signature-based approaches only catch events that are previously recognized as malicious.

Research objectives:

1. To discriminate between normal and anomalous behavior for a given user

2. To be able to discriminate among users.

3. To create technology that can identify new insider-initiated misuse.

1. Minimize number of false positives compared with correct detections per experiment

2. Minimize performance overhead for obtaining and using user profile data.

3. Using red-teaming experiments to inject misuse signatures not accessible (not in assurance system dataset) by targeted victim, demonstrate ability to recognize anomalous insider behavior.

Ability to collect user profile data is unique to the insider problem.

Open research problems:

1. What are the best (sensor) sources of data?

2. Feature extraction problems

3. Best algorithms for detection

4. Fusion/correlation of diverse information collected

5. Scientific evaluation and comparison of techniques

6. Design of contrastive experiments.

Research objectives:

1. Detect insider misuse of given resources and privileges

2. Develop application-level sensors and detectors for misuse

3. Go beyond access controls in user monitoring

4. Generalize profiles to applications.

1. Minimize number of false positives compared with correct detections per experiment

2. Minimize performance overhead for obtaining and using application access data.

This is a higher layer of detection that is specifically applicable to insiders, since system applications and processes are widely available to them.

Open research problems:

1. Develop techniques for program profiling: What constitutes valid or invalid access to a program?

2. Attempt to apply this detection technique within commercial operating systems

3. Develop application-specific misuse detection

4. Examine cases of insider misuse and develop a weighted threat model or matrix; what pattern of program accesses are an indicator of potential misuse?

5. Develop auditability of object accesses; i.e., how to develop a tamperproof audit trail of access to such system objects as programs and processes.

Research objectives:

1. Be able to determine who uses what, when, and how

2. Detect suspicious exfiltration of data, programs, and intellectual property

3. Provide object-centric traceability (e.g., by embedding an audit trail into documents and objects themselves).

1. Develop the capability to trace non-graphic objects (ability to trace graphic and audiovisual objects is being developed for intellectual property protection purposes by the entertainment industry)

2. Minimize performance overhead for using such trace techniques.

This is quite specific to the insider problem, since the vast majority of uses of inside system resources is by insiders.

Open research problems:

1. Mandatory watermarking of objects

2. Embedding audit trails in objects

3. The capability of applying these techniques to all kinds of system objects, such as text, graphics, source and binary code

4. Retrofitting COTS software to enable the watermarking of intellectual property

5. Developing appropriate algorithms to implement these techniques

6. Developing appropriate infrastructure, such as RCS, compilers, and application wrapping.

Research objectives:

1. Machine recognition of critical, possibly classified information by its content

2. Development of machine processible classification guides (to be used by the automated recognition procedures).

1. Reliable detection of critical information within a system, based on classification guides, in evaluation studies.

The description and protection of critical information is a process done "inside" an enterprise, and is therefore tailored to the unique needs of insiders of that enterprise.

Open research problems:

1. Develop expert systems and/or rule-based approaches to the recognition of critical content

2. Investigate statistical modeling approaches

3. Develop means for the reliable detection of critical content

4. Identify ground truth in recognizing critical content.

Research objectives:

1. Develop system architectures that channel insider misuse into enclaves, by modularizing currently wide-open distributed systems into observable and controllable enclaves. Passage among enclaves would be regulated by "gates" at which could be placed instrumentation for observation and response.

1. Ability of a system to withstand "red team" attacks by insiders against it.

The proposed design methodology is explicitly aimed at insider use. The intent is to make an insider an "outsider" to enclaves within the larger system that he or she does not have direct, immediate need to access.

Open research problems:

1. Design of gateways internal to a system (but perhaps within a single host on that system) that partition it into enclaves that are separately controllable, but accessible with appropriate permissions

2. Resolution of the tension between system and data redundancy (for robustness) and the concentration of critical assets within specific enclaves

3. Strategic deployment of sensors or "tripwires" within a system whose design is based on separate (but perhaps nested) enclaves.

Research objectives:

1. Investigate and mitigate the risks of physical access afforded to insiders

2. Map physical network changes dynamically

3. Audit physical changes in order to detect unauthorized changes

4. Determine unauthorized changes to hardware, software, and the network configuration in real-time.

1. Ability to detect and interpret "red team" physical changes to a system by insiders against it.

Insiders are unique in having physical access to many aspects of a system. This recommendation specifically addresses this special attribute of insiders.

Open research problems:

1. Develop effective, automated techniques for network mapping

2. Real-time dynamic change detection

3. Automatic recognition and notification of changes

4. System profiling and modeling that can handle the dynamic conditions of systems

5. Scalability of any proposed solution to networks comprising thousands or tens of thousands of nodes and links.

• Develop standard reporting mechanisms for detection engines. If many of the recommendations in the IPT report and this document are implemented, there will be a number of sensors, detection mechanisms, and other devices reporting potential misuse of various system assets. We need a standard reporting format, or mechanism, by which these reports can be forwarded to various correlation centers. Some uniformity in reporting is vital so that the correlation and fusion functions need not deal with a growing number of disparate formats and reports.

• Determine the cumulative effect of negligent events. Individual incidents of misuse of information system assets may not be critical in themselves, but their cumulative effect might be. How can we measure and determine such cumulative effects? Negligence or accidental misuse may lead to insider misuse.

• Detect outbound copies of code and intellectual property. Perhaps the most obvious yet damaging activity an insider can engage in is simply downloading (e.g., onto a floppy or Zip^TM disk) or sending (e.g., as an e-mail attachment) a file of highly sensitive code, data, or graphical or textual information. How can these acts be detected and stopped, especially when they may occur within very short periods of time - e.g., seconds?

• Build prosecution requirements into systems. One of the effective means of countering the malicious insider is to quickly and effectively prosecute those malicious insiders that are caught. To do so, systems must contain effective measures for collecting and protecting information that can be used in a courtroom, including means to convince a jury that the data is valid and has not been tampered with. These are stringent requirements that should be built into the very design of information systems and networks.

• There are social, societal, moral, and privacy implications for the recommended research directions. Attention should be paid to these considerations before operational implementation of systems resulting from the proposed research.

• To aid in the transition from research results to tested, practical solutions, consider use of the Army Research Lab's internet testbed or the DARPA Technology Integration Center (TIC) for demonstration, testing, and evaluation.

• There is a need for aggregation, correlation, and fusion of detection data resulting from implementation of our recommendations. Such fusion can create information at higher levels of abstraction. This correlation may take place at a number of levels. There is also the need for standards and schema for reporting detection data so that such correlation can take place effectively. (DARPA is currently funding several efforts. This topic is particularly well-suited to a future workshop.)

A breakout session devoted to R&D on response measures was conducted on the third day of the workshop. Among the response activities it considered were:

• Recording, or logging: The need to correlate physical and electronic alarms, to correlated multiple event logs (such as telephone logs, attendance records, ...), and to tailor audit logs so that they focus on the insider threat.

• Render a damage assessment: determine what the reach of the insider misuse has been, strictly from a system-technology viewpoint (versus counter-intelligence/espionage)

• Reporting: the requirement to report incidents to a central collection facility (i.e. - ARCERT, AFCERT, FIWC, DISA ASSIST, FEDCIRT) for fusion and enterprise scale assessment.

• Repair (immediate actions): The ability to investigate an incident from offsite or offline; the ability to intensify auditing, and do it "out of band;" the capability for autonomic repair, although this may be problematic if the insider understands how you may respond. An auto response (since it can be abused by a malicious insider) should be reserved to preserve the objective functionality of extremely critical systems only. Another potential repair action is the institution of deception and diversion measures, such as honeypots, in order to minimize damage and learn more about the intentions and level of sophistication of the malicious user. It was noted that if autonomic response is used, it may harm audit trails and records that allow the tracking, identification, and conviction of a perpetrator; therefore the actions taken by the autonomic response should be judged to be more important than catching and convicting the perpetrator.

• Restoration of critical services and functionality as rapidly as possible. (This has vulnerability implications for the knowledgeable insider. Restoration may create a denial of service event in order to exploit vulnerabilities in the restoration process for which the insider is given unique opportunities.)

• Remedial systems security engineering to more permanently repair vulnerabilities and/or remove opportunities presented by flawed process constructions.

Figure 2: Defensive Information Operations Organizations and Activities
Source: U.S. Department of Defense

It was noted by the response group that a responsive investigation process may either be covert, or overt. Its scope may be enterprise-wide, or local. How those two attributes are used in a particular response affect the nature of the response, and may affect the type of research needed to achieve all possible combinations in those 2x2 resultant possibilities.