Executive Summary

A JCAF agent represents a network agent with capabilities specialized for defending the cyber-assets of an organization.  Agents may receive and execute instructions, either in isolation or in collaboration with other agents, Web applications, or people. We need to ensure that an agent can correctly execute payloads (scripts or programs) that they receive or retrieve. The potential incompatibility of agents and payloads motivates the need for a mechanism to describe and reason about agents, payloads, and other related assets.

This article illustrates how 3 Sigma Research uses OWL-DL and Semantic Web technologies to develop a JCAF ontology to describe and reason about this domain. We show by example how the ontology supports the discovery of implicit relationships that pair payloads with agents based on known execution environment constraints and payload effects.

1    Introduction

3 Sigma Research developed the Java Cyber Agent Framework (JCAF) to implement a concrete domain model from which we could develop ontologies for reasoning about distributed agent capabilities. A JCAF agent represents a network agent with capabilities specialized for defending cyber-assets. Agents may receive and execute instructions, either in isolation or in collaboration with other agents, Web applications, or people. Agents share some similarities with agent platforms developed for other needs, such as the Java Agent Development (JADE) Framework [2], Cougaar Cognitive Agent Architecture [3], or the Pastry peer-to-peer framework 6.

We need to ensure that an agent can correctly execute payloads (scripts or programs) that they receive or retrieve. This problem exists because we must assume that agents operate within heterogeneous networks where agents differ in their ability to execute certain types of payloads. For example, a payload might assume particular programs or libraries exist on the host or that the host has network connectivity to some other host(s). Furthermore, even when the program to execute comes included in the payload, the program may not execute on the host operating system (e.g. a Linux program on Windows XP).

The potential incompatibility of agents and payloads motivates the need for a mechanism to describe and reason about agents, payloads, and other related assets. 3 Sigma Research’s work with agents includes development of a knowledge representation to describe and reason about entities in the Agent knowledge domain.

This article describes the fundamental ideas behind the 3 Sigma Research JCAF ontology and shows by example how the ontology supports the discovery of implicit relationships that pair payloads with mission-appropriate effects to agents with execution environments compatible with the payloads. The research presented here extends previous work in this area 6 666.

The significance of this work comes from the ability to capture domain knowledge in an ontological model, verify the consistency of the knowledge model, infer new knowledge not explicitly described in the domain model, and use this knowledge to pair payloads with compatible agents. This work has application to other distributed agent frameworks that require reasoning to coordinate agent activities.

2    JCAF Ontology

A JCAF agent represents any agent able to receive and execute a trusted program. Programs and scripts sent to agents constitute payloads, which may themselves contain many supporting programs, libraries, and configuration files. A payload may come as a binary, compiled for a particular operating system, and/or assume that certain programs or libraries already exist on the agent host. We call this the payload execution environment.

When planning an agent mission, it becomes critical to know that the payload can achieve the desired effect and can execute properly on a particular agent. For example, a payload with an application requiring a particular network driver will not run properly on host without some specific driver installed.

We express the JCAF ontology described in the next section with the OWL-DL ontology language 6 in order to achieve the most expressiveness while still supporting automated inferential reasoning. Figure 1 shows a subset of the JCAF ontology using the Protégé ontology editor [5]. Here we focus on the concepts of Agent, Payload, ExecEnv, and Effect, as well as their relations through the object properties hasEffect, hasExecEnv, and needsExecEnv.

The Agent class represents all kinds of agents. The ontology allows for the possibility that agents may have implementations in hardware or software (HardwareAgent or SoftwareAgent), and that implementations on mobile devices (MobileDeviceAgent) may have relevant conceptual differences from other platforms. We assert that all agents need an execution environment. Figure 2 show we make this assertion with an existential quantifier in Protégé. Recall that existential quantifier specifies that at least one such relation must exist and the universal quantifier provides a closure axiom indicating that only that relationship exists [6].

We model the concept of execution environment with the class ExecEnv. We include this concept in the ontology because of its importance for both describing what payload need to function and the kinds of payloads agents can execute. The subclasses Linux, MacOSX, Vista, and WindowsXP represent examples of possible execution environments. We define the subclass Windows as the intersection of things that support execution of both WindowsXP and Vista applications. We will describe this in more detail in the next section.

We intend for agents to perform actions to achieve intended effects. We represent these effects as subclasses of the Effect class. For the present discussion, we focus on the effects of ClosePort, StopApplication, and ShutdownHost. The ClosePort effect describes things that close one or more ports on a host. The StopApplication effect describes those things that stop one or more applications or services on a host. The ShutdownHost effect describes those things that shutdown a host.

 

 

Figure 2. Agent class assertions in Protégé.

The Payload class defines sets of things that agents can execute to achieve one or more effects. We require that all payloads have a relation with at least one Effect and one ExecEnv, which we make explicit with existential quantifiers. We use the necessary object property hasEffect to define subclasses of payloads that do not have particular effects. We will explain this decision in the next section. For illustrative purposes we define four subclasses of payloads: Payload_ClosePort Payload_NotShutdown, Payload_Shutdown, and Payload_Widget_Inc. The class names convey the universal quantifiers used to define the classes, except for the last, which represents a class of payloads created by a hypothetical third party vendor. Figures 3-6 shows the definition for the payload subclasses of, respectively,  Payload_ClosePort., Payload_NotShutdown, Payload_Shutdown, and Payload_Widget_Inc.

 

Figure 3. Payload_ClosePort assertions in Protégé.

 

Figure 4. Payload_NotShutdown assertions in Protégé.

 

Figure 5. Payload_Shutdown assertions in Protégé.

 

Figure 6. Payload_Widget_Inc assertions in Protégé.

3    Ontology Competency Questions

In this section we identify several competency questions and describe how they affected our ontology design decisions.
We began with a straightforward taxonomy for execution environments with subclasses as more specific kinds of a class. For example, operating systems such as Linux and Windows have many versions that represent subclasses.
However, we realized this way of structuring knowledge in the ontology, while accurately describing how many people think about versions of operating systems, does not work well for making some kinds of inferences. For example, consider the statement

If the payload runs on Windows then it runs on Vista.

OWL-DL reasoners cannot (easily, at least) infer this with the given taxonomy and SPARQL does not seem to have the expressivity to formulate a query that returns the desired results.

Statements like the one above seem too important to ignore in our domain, but we do not want to force making explicit statements of all operating system compatibilities for every payload.

We can solve this problem one way by changing the semantic interpretation of the classes for the execution environments. For example, instead of defining the class Windows as the set of things with some kind of Windows execution environment (operating system), we define the class Windows as the set of things that support all Windows-based applications. In the present example, this means we define the Windows class as the intersection of Vista and Windows XP.

To answer the questions

What effects does a payload have?
Which payloads have effect X?

we can query the ontology for alls instances of payloads and obtain their effects through the object property “hasEffect”.

The ontology must allow us to answer the question

What effects will the payload not have?

Open world reasoning in OWL-DL means we have negation as contradiction 6. Thus, we can say a payload does not have an effect only when we have explicitly stated it or make inference to an explicit statement. Otherwise, the payload might have the effect.

Therefore, to reason about effects payloads do not have, each type of payload needs its own definition and that each payload instance must instantiate a defined payload class. We define subclasses of payloads by the effects they do not have using universal quantifies. See Figures 3-6 f for an examples of such a definitions.
Had we chosen to instantiate payload instances as members of the Payload class, we could not infer which effects a particular payload instance did not have because payloads can have any effects.

4    Application

We present a scenario to demonstrate how we use the JCAF ontology and automated reasoning to match payloads with mission-appropriate effects to agents with compatible execution environments.

Consider a situation where we want to enforce a policy that requires agents to keep a port closed on computers they defend without shutting down the host. We need to find payloads that can close ports and match them with agents able to execute the payloads. Table 1 and Table 2 show, respectively, the payloads available from a payload repository and the agents existing in the network.

Table 1. Available payloads obtained from a SPARQL query.

Payload	needsExecEnv	hasEffect
P_ClosePort_WindowsXP_1	WindowsXP_2	ClosePort_1
P_Vista_ClosePort_1	Vista_7	ClosePort_1
Payload_Shutdown_Windows_1	Windows_8	ShutdownHost_2
P_Stop_Close_Windows_1	Windows_8	StopApplication_3
		ClosePort_1

Table 2. Available agents obtained from a SPARQL query.

Agent	hasExecEnv
Agent_Windows_1	Windows_8
Agent_Vista_1	Vista_7
Agent_WindowsXP_1	WindowsXP_2
Agent_Linux_1	Linux_2
Agent_MacOS_1	MacOSX_4

We must select from the set of payloads (Table 1) those payloads that we can configure to close ports but that will not shutdown the host and then pair each payload with an agent (Table 2) having an execution environment compatible with the payload. Table 3 shows the pairings of payloads to agents obtained from a SPARQL query using the Pellet OWL-DL reasoner [7].

Table 3. Payloads matched to compatible agents.

Payload	Agent
P_ClosePort_WindowsXP_1	Agent_WindowsXP_1
	Agent_Windows_1
P_Stop_Close_Windows_1	Agent_Vista_1
	Agent_WindowsXP_1
	Agent_Windows_1
P_Vista_ClosePort_1	Agent_Vista_1
	Agent_Windows_1

The query results in Table 3 show, for example, that we can deploy the payload P_Stop_Close_Windows_1 to the three agents: Agent_Vista_1, Agent_WindowsXP_1, and Agent_Windows_1 because the payload needs a Windows execution environment and each of these agents have some kind of Windows execution environment.

Table 3 also shows that no Windows payload gets paired to either Agent_Linux_1 or Agent_MacOS_1, since neither has an appropriate execution environment for those Windows payloads. In addition, we see that the payload Payload_Shutdown_Windows_1 does not get selected, even though shutting down the host does have the effect of closing ports.

5    Conclusions

This article presented an ontology for describing and reasoning about distributed agent capabilities. We demonstrated in the context of JCAF agents how this ontology makes it possible to match compatible payloads and agents.

We saw how expressing the JCAF ontology with the OWL-DL ontology language allows us to find implicit relationships between entities. This has the advantage of allowing us to provide greater autonomy between agents and payload developers, whereby each develops their respective applications without needing to know about the availability or capabilities of the other’s products. The structure of the ontology allows us to infer compatibilities between agents and payloads so that all possible compatibilities do not require explicit declaration.

We showed that the JCAF ontology allows us to capture knowledge about agents and payloads. We showed how to reason over this knowledge model to discover implicit relationships that we can use to control the actions of agents. This research has direct application to reasoning about capabilities of other distributed agent frameworks.
 

6    References

Pastry: A Substrate for Peer-to-Peer Applications. http://freepastry.org/ (Accessed January 9, 2009).

Java Agent Development (JADE) Framework. http://jade.cselt.it/ (Accessed January 9, 2009).

Cougaar Cognitive Agent Architecture. http://cougaar.org/ (Accessed January 9, 2009).

“OWL Web Ontology Language Guide”. Ed. by M.K. Smith, C. Welty, and D.L. McGuinness. W3C Recommendation, February 10, 2004. http://www.w3.org/TR/owl-guide/ (Accessed January 9, 2009).

Protégé Ontology Editor. http://protege.stanford.edu/ (Accessed January 9, 2009).

M. Horridge, H. Knublauch, A. Rector, R. Stevens, and C. Wroe. “A Practical Guide To Building OWL Ontologies Using The Protégé-OWL Plugin and CO-ODE Tools”; The University of Manchester, August 27, 2004. http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf (Accessed January 9, 2009).

Pellet: The Open Source OWL-DL Reasoner. Version 2.0.0-rc4. http://clarkparsia.com/pellet (Accessed January 9, 2009).

A. Wheeler, M. Wallace, and M. Winburn. The Cybercraft Ontology: Unifying Policy, Payloads, and the Environment Store. Information Assurance Science & Technology Series, Fall 2008 Agents Workshop, 12-14 November 2008. Southwest Research Institute, San Antonio, TX.

A. Wheeler, M. Wallace, M. Winburn, J. Dike, and J. Maxey. The Cybercraft System Ontology: An Ontology for Reasoning about Distributed Agent Capabilities. The 2008 International Conference on Artificial Intelligence (ICAI’08), 14-17 July 2008, Las Vegas, NV.

M. Wallace, A. Wheeler, M. Winburn, J. Dike, and J. Maxey. Leveraging OWL-DL, SPARQL, and XSLT to Automate Cybercraft Configuration. The 2008 International Conference on Artificial Intelligence (ICAI’08), 14-17 July 2008, Las Vegas, NV.

A. Wheeler, M. Wallace, M. Winburn, and J. Dike. The Cybercraft System Ontology: An Ontology for Reasoning about Distributed Agent Capabilities. Cyber-Defense Conference, 12-14 May 2008, Griffiss Institute, Rome, NY.

SemTechBiz is Less Than 2 Weeks Away

The Semantic Tech & Business Conference (SemTechBiz) is coming to San Francisco on June 3-7! Join us for case studies, innovative panels, tutorials, and keynotes that will provide you with practical advice, hands-on guidance, and breakthrough approaches to solving business problems with semantic technology. Passes go up $200 at the door. Sign up now and save !