A Common Intrusion Specification Language (CISL) Rich Feiertag, TIS Cliff Kahn, Open Group Phil Porras, SRI Dan Schnackenberg, Boeing Stuart Staniford-Chen, UC Davis Brian Tung, ISI, editor last revised 6 May 1999 1. Abstract We describe a language that can be used to disseminate event records, analysis results, and countermeasure directives amongst intrusion detection and response components. We give an encoding that translates these messages into an efficient octet stream. Illustrative examples are included. 2. Introduction This document is part of a series produced by the Common Intrusion Detection Framework (CIDF) working group. The other documents provide: * An architectural framework that describes the environment in which intrusion detection and response components interact. * A messaging and directory specification that defines the way in which components can locate and authenticate each other, and encapsulate messages amongst themselves. We intend to give a working definition of each new term that appears in this document, but for a fuller discussion of many of them, the reader is asked to consult the architectural framework document. Increasingly, intrusions are taking on a grander scale. Many attacks can be orchestrated over a wide area network, and over a long period of time. In such an environment, the ability of intrusion detection systems and their components to share information about these attacks is especially important. Such sharing would allow systems to warn others about possible impending attacks. To satisfy this need, we need to define a common language to exchange this information. This document describes the requirements on that language, and proposes a specification that we believe meets them. The remainder of this document is organized as follows. Section 3 describes the requirements on this common language, and our rationale for our language design choices. Section 4 describes our proposed language, and is the bulk of this document. Section 5 describes an encoding that transforms messages in this language into an efficient representation. Section 6 describes a header that provides encapsulation information. While the language defined in the bulk of this document is designed to be used by a wide range of intrusion detection and response systems, it was originally constructed as part of CIDF. This section describes the manner in which expressions in the language are encapsulated to produce Generalized Intrusion Detection Objects (GIDOs for short). GIDOs are messages which can be exchanged by CIDF-compliant components, and provide features such as origin authentication, priority queueing, and threading. Finally, Section 7 defines GIDO addendums. Using addendums, one can add information to a GIDO to clarify or correct its contents, without destroying the original GIDO or disrupting any digital signature on it. 3. Requirements 3.1. Impact of the CIDF Architecture Under the CIDF model, components in general may receive an input stream, use this input to drive their internal analytical processing, and pass the results on to other components. In other words, the output of one component may be the input of another. Notice that the nature of these inputs and outputs may be quite different at various places and times in the system. Components that are in some sense close to the data sources are more likely to produce raw event descriptions; components that are further downstream may consume these event descriptions and produce analyses of them; and yet other components may consume these analyses and produce recommendations for responses. In spite of these widely varying types of information being exchanged, the fact that all of these components are interconnected and related makes it beneficial for us to find a common way to express them. This would allow intrusion detection components that conduct other activities such as state monitoring to participate as well. As an additional rationale, consider that responses may involve further reconnaisance or specialized event gathering, for instance, so that there is potentially an extensive feedback loop within the intrusion detection system at large. However, these commonalities should not obscure the fact that they are still different in important ways. Without going into the specific nature of events and their analyses, we note that event records simply represent observations made by a component on a system. Many of these records may involve ordinary computation or routine maintenance. As a result, these records are likely to be produced in high volume. Also, since many of these activities can be witnessed by anyone logged into the system, the security requirements for the event records may be relatively low. On the other hand, analysis results and countermeasure recommendations are strongly correlated with suspected attacks. They are therefore comparatively scarce. And because they may affect an intrusion system's reasoning about an attack, or its decision-making process on how to react, they will probably have stronger security requirements. These differences will affect what transport mechanisms are used to move them around; messages that are very common will likely use transports that are optimized for performance, whereas messages that are scarcer will use transports that provide reliability and assurance. The language used by the intrusion detection components should not place restrictions on the transport and security mechanism(s) used, and vice versa. 3.2. Language Goals List In light of the foregoing discussion, any language used to exchange information about attacks should have the following qualities: 1. Expressive. Components should be able to express a wide range of intrusion- and misuse-related phenomena and prescriptions. However, this same language should also be... 2. Unique in expression. Components should not be able to express a given sentiment in a nearly infinite number of ways; instead, there should be one or a small number of "natural" expressions. 3. Precise. The meaning of an utterance in the language should be well-defined. But this language should also be... 4. Layered. Specific senses should be expressed as cases of general senses, so that different receivers with different requirements can discern as much as they need from a message. 5. Self-defining. Consumers that receive a report should be able to interpret messages to the degree that they need to, without recourse to out-of-band negotiation. But the language should also be... 6. Efficient. Messages should consume as little of system resources as possible. Especially, it should be possible to omit contextual information in most of a sequence of similar messages. 7. Extensible. If a group of producers and consumers decide on additional information they wish to be able to express, they can define a way of doing so with a minimum of trouble and not lose any compatibility with other CIDF components that do not know their extension. These extensions may be arbitrarily complex. But the language should also be... 8. Simple. Producers should be able to encode information quickly; consumers should be able to extract the information they need without having to do excessive processing. 9. Portable. The language should support a variety of platforms and transport mechanisms---support meaning that the environment should not fundamentally limit what information is exchanged. However, it should also be... 10. Easy to implement. If the language is too difficult to implement, then it will not be used. As a very simple (and not terribly serious) example, English is an expressive and self-defining language (so far as English speakers are concerned, at least), but it is not unique in expression; a given thought can generally be expressed in many different ways. It has some measures for efficiency: ellipsis allows a speaker to omit various connectives in parallel expressions. It is certainly extensible--new words are added by the thousands each year--and it is portable by some measures, as it is used in speech and writing. On the other hand, its grammar is empirically not simple, its vocabulary is not precise (admitting of many definitions per word), and many non-native speakers complain that it is not easy to implement, either. However, a subset of English might suffice. If it were possible to define rules for producing English descriptions of events, etc., such that independently designed components would generate the same sentence from the same input, then many of these goals could be addressed. 3.3. Turning Goals into Requirements These are the stated goals of the language. However, the nature of goals is that they are aims rather than targets, and hence inherently not testable--one cannot determine whether a language *aimed* for an objective, after all! To be worthwhile, we need to process these goals into requirements: testable qualities that our language should possess. Let us therefore consider each of the above goals in turn, and generate from it a more precise, though probably less lofty sounding, requirement. 1. Expressive. To satisfy this, our language should have a wide enough vocabulary and sophisticated enough syntax to cover a broad range of expressions. To be more specific, this language should be able to express at least the following: * causal relationships among events * the roles of objects in events, such as initiator * properties of objects, such as name * relationships of objects to other objects, such as owner * response prescriptions calling for halting particular processes, sessions, or other activities * contingent response prescriptions 2. Unique in expression. It is probably not possible to have an expressive language that literally admits of exactly one formulation for each sentiment. Our requirement, therefore, is as follows: If a sender and a receiver can agree on the *objects* of interest, but not on the *way* they will express information about those objects, then they should still be able to understand each other. If they cannot, then the language is too arbitrary. 3. Precise. Two receivers reading the same message must not draw mutually contradictory conclusions from it. 4. Layered. There should be a mechanism in the language by which specific concepts are defined in terms of more general ones. 5. Self-defining. It should be self-evident from a message how each datum within it should be interpreted. For example, a sequence of four octets (i.e., bytes) is not merely four octets, but an IPv4 address; and not merely an IPv4 address, but the address of a host; and not merely the address of a host, but the address of a host from which an FTP command was issued; and so forth. 6. Efficient. In comparison with a hard-wired format, a format that can be understood by any compliant receiver should be no more than twice as long over the long run. (In other words, the marginal cost of using this language should be no more than a factor of two.) 7. Extensible. There should be a mechanism by which a sender can use its own vocabulary, and indicate that fact to receivers, in such a way that receivers can either recover the meaning of the new vocabulary, or decide whether and how to interpret the rest of a message in which it occurs. 8. Simple. So-called "dumb" components, such as routers, should be able to send and receive simple messages without "understanding" the language as a whole, simply by filling in blanks and/or extracting from them the required information. 9. Portable. The encoding for the language should not depend on the endian-ness of the host on which a message is encoded, or on the details of its networking. 10. Easy to implement. This is hardest to state an explicit requirement for; the proof of the pudding is in the tasting. The end requirement is that it be deployed. 3.4. The Proposed Approach We propose to take an approach similar to English. We will begin with a general language construct, called S-expressions [SExp]. S-expressions are simply recursive groupings of tags and data; typically, the grouping is done with parentheses, as in Lisp. Here is an simple S-expression: (HostName 'ten.ada.net') This S-expression simply groups two terms, HostName and 'ten.ada.net'. It does not, on its own, provide any semantic binding between the two. That is left up to the language definition. The advantage of S-expressions is that they provide an explicit association between terms, without limiting what those terms and their groupings might express. To achieve self-definition, we will add a feature to the S-expressions. Each S-expression will begin with a tag, such as HostName, that gives some semantic "clue" to the interpretation of the rest of the S-expression. For this reason, these tags will be called Semantic IDentifiers, or SIDs for short. As we shall see in Section 4, these tags can not only give descriptive information such as a hostname, but they can also tag actions taken by an entity, or specify whether an entity acted or was acted upon, and so forth. As a consequence, S-expressions, along with SIDs, allow a wide variety of sentiments to be expressed. Like English, however, they suffer from ambiguity in the sense that a single sentiment may be capable of many different expressions. To achieve self-conformance, we will describe rules and guidelines for constructing S-expressions, so that only a subset of all possible S-expressions will be produced. This will reduce the likelihood that two components will not be able to understand each other even when they are interested in the same kind of data. Another drawback of S-expressions and SIDs is that they do not on their own provide a compact representation. We shall encounter, for example, a SID called CloseApplicationSession; this SID is 23 letters long, and left as ASCII, would take a corresponding long space in a communication stream between two components. Therefore, in Section 5, we will define an encoding that is both compact and simple to parse. We will go into greater detail on how those goals are met at that time. In the next section, we will focus on describing S-expressions and SIDs, and how to put them together to construct "sentences" about attacks and related information. 4. S-Expressions and CISL In this section, we will describe how SIDs and S-expressions are used to express information about intrusions and anomalies and their related paraphernalia. 4.1. An Introductory Example We introduce CISL by means of an example. The reader is not expected to understand the organization of the example; nevertheless, part of the aim of the language is to make comprehension by non-CISL-educated readers at least plausible. (And (OpenApplicationSession (When (Time 14:57:36 24 Feb 1998) ) (Initiator (HostName 'big.evil.com') ) (Account (UserName 'joe') (RealName 'Joe Cool') (HostName 'ten.ada.net') (ReferAs 0x12345678) ) (Session (StandardTCPPort 23) ) ) (Delete (World Unix) (When (Time 14:58:12 24 Feb 1998) ) (Initiator (ReferTo 0x12345678) ) (FileSource (HostName 'ten.ada.net') (FullFileName '/etc/passwd') ) ) (OpenApplicationSession (World Unix) (Outcome (CIDFReturnCode failed) (Comment '/etc/passwd missing') ) (When (Time 15:02:48 24 Feb 1998) ) (Initiator (HostName 'small.world.com') ) (Account (UserName 'mworth') (RealName 'Mary Worth') (HostName 'ten.ada.net') ) (Session (StandardTCPPort 23) ) ) ) A rough English translation would of this S-expression would be Three actions took place in sequence, at the times indicated. First, someone logged into the account named 'joe' (real name 'Joe Cool') at 'ten.ada.net', from a host named 'big.evil.com'. Then, about a half-minute later, this same person deleted the file '/etc/passwd' from 'ten.ada.net'. Finally, about four-and-a-half minutes later, a user attempted but failed to log in to the account 'mworth' at 'ten.ada.net'. The attempted login was initiated by a user at 'small.world.com'. (Did you get it right?) Notice that SIDs seem to take arguments, and that some SIDs take simple data as arguments, while other SIDs take other S-expressions as arguments. Furthermore, some SIDs denote actions, while others describe time and location, and still others describe or identify objects participating in the action. In the following subsections, we will describe each of these different kinds of SIDs (and related features): * Verb SIDs, such as Delete and OpenApplicationSession, will be described in Section 4.2.1. * Role SIDs, such as Initiator and FileDestination, will be described in Section 4.2.2. * The adverb SIDs, Outcome and When, will be described in Section 4.2.3. * Attribute SIDs, such as Owner, will be described in Section 4.2.4. * Atom SIDs, such as UserName and Time, will be described in Section 4.2.5. * The referent SIDs, ReferTo and ReferAs, will be described in Section 4.2.6. * Conjunction SIDs, such as And, will be described in Section 4.2.7. The list of all defined SIDs of each type are given in the corresponding section of Appendix A. For instance, verb SIDs are given in Section A.2.1. 4.2. SID Descriptions The following sections give brief descriptions of each type of SID. 4.2.1. Verb SIDs At the heart of a sentence is the verb. Normally, we think of verbs as denoting some action (which may sound somewhat event-centric), but they may also denote a recommendation, for instance, or description of state. An example of a verb SID is Delete. A sentence must contain at least one verb SID. If it contains exactly one verb, it must be at the top (i.e., beginning); such a sentence is called a *simple* sentence. Simple sentences may be joined by conjunction SIDs (q.v.), or they may be enclosed in other verbs (such as Do, in the case of a recommendation). The resulting sentences are called *compound* and *complex* sentences, respectively. Now, a verb on its own cannot tell much. If all we know is the verb Delete, we can appreciate that something was (presumably) deleted, but we don't know who deleted what, at what time, in what place. So a verb SID takes as argument a sequence of S-expressions that tell us these various aspects. Those S-expressions are headed by role SIDs, below. 4.2.2. Role SIDs A role SID governs information about the "players" associated with the verb. The role denotes what part an entity plays in a sentence. An example of a role SID is Initiator. Like verb SIDs, role SIDs take as argument a sequence of S-expressions. These S-expressions identify or describe the entity playing the indicated role. An S-expression headed by a role SID is called a *role clause*. 4.2.3. Adverb SIDs Adverb SIDs are similar to role SIDs but do not describe an object. Instead, they fix a verb SID in space and time or modify its meaning. The two currently defined are When and Outcome. 4.2.4. Attribute SIDs Like role SIDs, attribute SIDs denote objects, but unlike role SIDs, attribute SIDs only occur directly under role SIDs. They describe an entity that has a relation to the entity described by the containing role clause. For instance, the target file of a Delete sentence may have an owner, one with a number of attributes that can be given. In this case, one identifies the target file in a FileSource clause, and identifies the owner in an Owner clause that is placed directly within the FileSource clause, as follows: (FileSource (Owner ) ) 4.2.5. Atom SIDs Atom SIDs are the workhorses of S-expressions. Verb, adverb, attribute, and role SIDs are placeholders that organize the sentence, but the atom SIDs are required to instantiate those placeholders. Within an Initiator role SID, for instance, one will typically find atom SIDs that describe and identify that Initiator. Examples of atom SIDs are Username and IPv4Address. S-expression generators may often run into confusion when deciding where a particular atom SID (most often a locator, such as HostName) should go--whether it belongs in a adverb clause or a role clause. Generally speaking, if the SID locates an *object*, it belongs in the role clause; if it locates the *action*, it belongs in the adverb clause. More guidelines on how to organize sentences and clauses can be found in Sections 4.4 and 4.5. 4.2.6. Conjunction SIDs Conjunction SIDs, as their name implies, join sentences together. The most common case is simply And. For example, (And ) means only that Sentence1 and Sentence2 both hold. It says nothing about the order in which they occurred, or about any causal relation between the two. There are other conjunction SIDs which *do* express some of these relationships, however. An example is ByMeansOf. If one writes (ByMeansOf ) then one means that Sentence1 and Sentence2 and Sentence3 all occurred, and Sentence3 was a way of Sentence2 happening, and Sentence2 was a way of Sentence1 happening. For example, one might write (ByMeansOf (AcquireProxy ...) (Attack ...) (SendMessage ...) ) to indicate that someone gained access to root privileges (which is ) by means of an attack (described in ), which was carried out by means of sending a message (as described in ). Incidentally, ByMeansOf may take an arbitrary number of sentences; the notion of that SID applies sequentially down the sentences. One final conjunction SID is HelpedCause. It has a similar syntax to ByMeansOf. The distinction between them is that HelpedCause joins two or more separate occurrences with a specific chain of causality, whereas ByMeansOf joins two or more separate perspectives on the same occurrence. In the example above, the attack did not *cause* the attacker to obtain root privileges. Rather, the attack was the *way* in which the attacker obtained root privileges. 4.2.7. Referent SIDs Referent SIDs allow one to link together two or more parts of the same sentence. There are only two referent SIDs, ReferAs and ReferTo. They take a ulong as their argument, so they are in some sense atom SIDs. They differ from other atom SIDs, however, in that the actual ulong is opaque. Briefly, a ReferAs "catches" a reference made by a ReferTo when their argument ulongs match. An S-expression headed by a referent SID is called a *referent clause*. A referent clause may be placed within either a sentence (i.e., under a verb) or a role clause. Its interpretation varies depending on which case applies: * If a ReferAs clause is placed into a sentence, it can be said to *refer* to that sentence, *except* for any ReferAs clauses. (It is considered bad form to use more than one ReferAs clause in the same sentence at the top level.) Thereafter, a use of the corresponding ReferTo clause can be used in place of that sentence (although see warning below). * If a ReferAs clause is placed into a role clause, it is said to refer to the object described by the sequence of S-expressions following that role, *except* for any ReferAs clauses. (It is considered bad form to use more than one ReferAs clause in the same role clause.) Thereafter, a use of the corresponding ReferTo clause can be used in place of that object description (again, see warning below). * WARNING. The referent SIDs carry actual semantics, and are not simply macros. If a ReferAs clause is placed into a sentence, and that sentence refers to an event (say), then the ReferTo clause refers specifically to that specific event, and not simply to an event with the same attributes (which after all may not be uniquely identifying). Similarly, if a ReferAs clause is placed into a role clause, and that role clause describes an object (say) then the ReferTo clause refers specifically to the same object, and not simply to an object with the same attributes. Of course, if no specific item is denoted by the ReferAs clause, then this warning does not apply. For example, if ReferAs occurs in an assertion of state, then it can be interpreted as simply a macro, since there is no unique item being denoted. The scope rule applying to referent SIDs is as follows: The value of a referent clause is the verb or role within which it is found (roughly speaking), provided that that verb or role is in the same S-expression. A producer MUST NOT re-use a referent (such as 0x12345678) within the same thread, for perpetuity. 4.3. SID Worlds and the World SID It is not expected that any component will understand all SIDs. A component concerned with Unix notions will often not be worried about X.500-related SIDs. Nevertheless, many X.500-related SIDs have their complements in the Unix world, and the Unix component will want to capture this information, even if it isn't cognizant of the exact use of this information in the X.500 world. For instance, a user's real name is a user's real name, although in Unix it might be the name in /etc/passwd associated with the user's account, and in X.500 it may be a Common Name. If these two concepts were expressed with two completely distinct SIDs, then we would lose much of the benefits of data sharing. The World SID is designed to address this. This allows one to specify information in a relatively generic fashion, and then give more specialized receivers extra information about SIDs that specifies more precisely how they are to be used. For instance, an X.500 Common Name would be expressed as follows: (World X500) (RealName 'Joe Cool') Most components would be able to understand the RealName SID, and would be able to capture the fact that the a user with the real name 'Joe Cool' is in question here. Additionally, any component who understands X.500 would implement the X500 World, so that it knows that the RealName is in fact registered as a Common Name, along with any implications of that fact. Syntactically, exactly one World SID clause may appear in any S-expression except an Atom-SID clause. Their scope is the parent SID under which they appear, and all other clauses in that S-expression, except that World SIDS may appear in child clauses and these override the World SIDS in parent clauses. For example (Delete (World Unix Linux Redhat-5.1) (When (Time 123471298) ) (Initiator (UserName 'stanifor') (HostName 'wherefore.cs.ucdavis.edu') (FileSource (World SMB) (FileName '\\whatever\share1\ProgramFiles\SomeFile') (HostName 'wherefore.cs.ucdavis.edu') ) ) Here, the Initiator UserName ('stanifor') can be correctly interpreted as a Unix username, more specifically, a Linux username, and more specifically still, as a username on a Red Hat 5.1 Linux system. On th other hand, none of these worlds apply to the FileSource Filename, because they are overridden by the (World SMB) which appears in the FileSource clause. Thus the Linux user on a Linux system has deleted a file via the (Windows) SMB protocol (presumably using the Samba software which often is used on Linux to interact with Windows-based systems). Note that the World SID does not change the type of any SID, or the data that should appear there. It merely allows components with a more specific understanding of that world to divine more information about the data in question. The space of Worlds forms an (extensible) forest of interpretation domains. Thus, Linux is a specialization of Unix, but SMB is not a specialization of either of these. If multiple worlds follow the World SID, they must be specializations of one another, and the most general must appear first. The list of currently defined SIDs is given in the entry for the World SID in Appendix A, Section A.2.7. 4.4 Plural SIDS. 4.4.1. Distinct Child Rule Generally speaking, when we have multiple S-expressions together in a clause, as follows: (HeadSID (ChildSID1 ...) (ChildSID2 ...) ... (ChildSIDn ...) ) ChildSID1..ChildSIDn MUST all be distinct from one another. No SID can appear twice at a given level. There are two classes of exceptions to this Distinct Child Rule which are discussed next. 4.4.2. Conjunctions If HeadSID is any of the Conjunction SIDS defined in A.2.5, then the Distinct Child Rule is completely relaxed for the Verbs and Conjunctions that appear below this. Any Verb or any Conjunction may appear arbitrarily many times beneath a conjunction. 4.4.3. Subjects and Objects below Verbs For each verb SID, Appendix A denotes two special roles: one which is the subject of the verb, and one which is the object. The subject and object roles may appear multiple times beneath the verb. The interpretation of multiple subjects and/or objects is the association of each subject-object pair with the verb (but please refer to the "Note well" below). For example, the sentence "Joe executed (the commands named by) file1, file2, and file3" can be represented as (Execute (Initiator (UserName 'joe') ) (Process (FileName 'file1') ) (Process (FileName 'file2') ) (Process (FileName 'file3') ) ) Note that this has the same meaning as (And (Execute (Initiator (UserName 'joe') (ReferAs 0x12345678) ) (Process (FileName 'file1') ) ) (Execute (Initiator (ReferTo 0x12345678) ) (Process (FileName 'file2') ) ) (Execute (Initiator (ReferTo 0x12345678) ) (Process (FileName 'file3') ) ) ) Note well: Any subject or object which gets "multiplied" like this because the corresponding object or subject is plural, refers in all cases to the *same* object, and not merely to a different object which has syntactically the same description. Thus, for instance, it is *not* the case that one 'joe' executed 'file1', another 'joe' executed 'file2', and yet another 'joe' executed 'file3'. They are all the same 'joe'. As another example, the sentence "Mary and Joe executed (the commands named by) file1 and file2." can be represented as (Execute (Initiator (UserName 'mary') ) (Initiator (UserName 'joe') ) (Process (FileName 'file1') ) (Process (FileName 'file2') ) ) This has the same meaning as (And (Execute (Initiator (UserName 'joe') (ReferAs 0x12345679) ) (Process (FileName 'file1') (ReferAs 0x1234567a) ) ) (Execute (Initiator (ReferTo 0x12345679) ) (Process (FileName 'file2') (ReferAs 0x1234567b) ) (Execute (Initiator (UserName 'mary') (ReferAs 0x1234567c) ) (Process (ReferTo 0x1234567a) ) ) (Execute (Initiator (ReferTo 0x1234567c) ) (Process (ReferTo 0x1234567b) ) ) ) 4.5. The Multiplier SID In order to concisely express a combination of a great many events in one message, you use the Multiplier SID. In doing so, however, you may lose details about the individual events; you should use Multiplier only if these details are not important, or if they can be conveyed in another message. The Multiplier SID may reside in one of four places. Like referent SIDs and the World SID, it may reside directly under a verb. (To determine whether Multiplier may occur under any given verb, please consult the verb's entry in Appendix A, Section A.2.1.) The interpretation of this construct is as follows. The structure ( (Multiplier ) ) is equivalent to the compound sentence (And ( ---+ | ) | ( | | ) +-- times . | . | . | ( | | ) ---+ ) The other times it may appear are in role SIDs designated as pluralizable subjects, pluralizable direct objects, or pluralizable indirect objects. The interpretation of the structure ( ( (Multiplier ) ) ) is equivalent to the pluralized sentence ( ( ---+ | ) | ( | | ) | . +-- times . | . | ( | | ) ---+ ) In any of these cases, note that the roles or sentences so multiplied are not bound to each other by implicit ReferAs's and ReferTo's. In other words, if the subject role Initiator is multiplied 5 times, each of them does not refer to the same Initiator necessarily. They are also not necessarily distinct; they simply share the attributes given under that role SID. 4.6. Guidelines on Constructing Sentences and Clauses In this section, we describe how to use verb SIDs, role SIDs, conjunction SIDs, and other kinds of SIDs to construct sentences. 4.6.1. Basic Organization As noted above, a simple sentence is an S-expression containing exactly one verb SID. This verb SID is followed by a sequence of one or more S-expressions that describe the various entities that play parts in the sentence, or qualify the verb. Each of these S-expressions is headed by a role SID. This role SID is in turn followed by a sequence of one or more S-expressions. Each of these doubly nested S-expressions may describe or identify the entity playing the indicated role. Or it may be [not describe] a sentence that plays the indicated role within the outer sentence. 4.6.2. Understanding Sentences and the Principle of Connectedness The Principle of Connectedness simply states that when a component reading a GIDO encounters a SID it does not understand, the component must strictly ignore the S-expression that the SID heads. The component MUST NOT reject the GIDO solely on this basis. For instance, in the example below (InSequence (Delete (Initiator (RealName 'Joe Cool') ) (FileSource (Filename '/etc/passwd') ) ) (Execute (Initiator (UserName 'sysadmin') ) (Process (ProgramName 'SystemCheck') ) ) ) if a component does not understand the Delete verb SID, it may not make use of the Initiator and FileSource SIDs within that sentence, even if it understands those, because it will not understand what they are the Initiator and FileSource *of*. This is called the Principle of Connectedness because the portion of the GIDO which is understood must form a connected tree. If a parent is not understood, its children should not be interpreted, as its relation to the portion of the tree contain the parent is unknown. 4.6.3. Rules and Guidelines for Using SIDs Whenever a component puts a SID into a sentence, the SID MUST be used with the number of arguments (usually one) that the SID's definition calls for (see the definitions in Appendix A). The SID's argument(s) MUST have the syntax and meaning that the SID's definition calls for. Otherwise the component is OUT OF CONFORMANCE with the SID's definition. A component that generates sentences MUST generate them in conformance with all of the SID definitions in this specification. Whenever the above rule permits, a component generating a sentence SHOULD use a SID from this specification. If this is not possible, then the implementation MUST define a new SID; misusing an existing SID is not allowed. If a component generating sentences uses a SID from a particular specification, and if that specification defines two applicable SIDs, one of which is strictly more specific than another, then the component SHOULD use the more specific one. If CIDF component X creates a sentence and CIDF component Y later has a copy of the sentence and passes it verbatim to CIDF component Z, then Y MAY do so even if the sentence violates the above rules and guidelines. The sentence MUST be passed verbatim and SHOULD be clearly ascribed to its originator. This provision frees databases and such from having to thoroughly understand and validate every sentence they process. However, if the CIDF component modifies any part of the sentence, then it is responsible for the entire sentence's compliance with the above rules and guidelines. 4.7. CISL Paradigms In this section, we will more concretely discuss approaches to encoding various kinds of events and analysis results. We will present these approaches as paradigms--basic structures into which GIDOs of a broad class will fall. While these paradigms are not part of the "legal" specification of CISL, it is our hope that comprehension amongst participating components will increase if these paradigms are used. 4.7.1. Attack Paradigm Our first paradigm is the attack paradigm. We find it useful to think of attacks in a tripartite manner, consisting of * Outcome: What did the attacker achieve? For instance, the end result of an attack might be the acquisition of root privileges on a given host. * Attack class: What is the conventional form of attack? * Mechanism: What were the specific actions by which the attacker attempted the attack? Not all attacks will exhibit all three aspects. If an attack fails, for example, then there is no real "outcome": no significant system change has been effected, and the fact that the attack failed will be noted in the expression of the attack class. These three aspects of the attack as a whole are joined by a ByMeansOf conjunction SID. They are not joined instead by HelpedCause, because they are not three separate events; rather, they are three different views of the same event. (ByMeansOf ) Let's take a specific example. Suppose that an attacker mounts a fingerd (buffer overflow) attack. Suppose further that the attack succeeds and the attacker gains root on the host in question. The outcome can be expressed using the AcquireProxy verb. Since the system in question is a Unix machine, we will use the World SID with the Unix world: (AcquireProxy (World Unix) (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (HostName 'big.evil.com') ) (Proxy (HostName 'small.world.com') (UserName 'root') ) ) The attack class is specified using the Attack verb. The certainty, let's suppose, is absolute: we know the attacker has definitely gained root privileges on the machine. The seriousness, as expressed by the Severity SID, depends on the resources on that machine, as well as on any other machines accessible from there. Suppose that the analyzer reckons the Severity as halfway: 50 on a scale from 0 to 100. The basic class of attack is an illegal root transition: (Attack (Outcome (ReturnCode success) ) (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (HostName 'big.evil.com') ) (Target (HostName 'small.world.com') ) (AttackSpecifics (AttackID 0x0000000100000057) (Certainty 100) (Severity 50) ) ) The mechanism of the attack is a message to the finger port (79) with a too-long payload. This is expressed as a conjunction of two events: an opening of a TCP connection to port 79, and the sending of a too- long message to that port: (And (ConnectTCP (When (Time 15:34:05 27 Mar 1999 UTC) ) (Initiator (HostName 'big.evil.com') (ReferAs 0x01010101) ) (Receiver (HostName 'small.world.com') (ReferAs 0x02020202) ) (Session (StandardTCPPort 79) (ReferAs 0x03030303) ) ) (SendMessage (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (ReferTo 0x01010101) ) (Receiver (ReferTo 0x02020202) ) (Message (ByteSize 72348) ) (Session (ReferTo 0x03030303) ) ) ) These three aspects of the attack are combined as described above, using the ByMeansOf conjunction. We will also use further instances of the referent SIDs to bind together common references to the same object. In the end, we get (ByMeansOf (AcquireProxy (World Unix) (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (HostName 'big.evil.com') (ReferAs 0x01010101) ) (Proxy (HostName 'small.world.com') (UserName 'root') ) ) (Attack (Outcome (ReturnCode success) ) (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (ReferTo 0x01010101) ) (Target (HostName 'small.world.com') (ReferAs 0x02020202) ) (AttackSpecifics (AttackID 0x0000000100000057) (Certainty 100) (Severity 50) ) ) (And (ConnectTCP (When (Time 15:34:05 27 Mar 1999 UTC) ) (Initiator (ReferTo 0x01010101) ) (Receiver (ReferTo 0x02020202) ) (Session (StandardTCPPort 79) (ReferAs 0x03030303) ) ) (SendMessage (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (ReferTo 0x01010101) ) (Receiver (ReferTo 0x02020202) ) (Message (ByteSize 72348) ) (Session (ReferTo 0x03030303) ) ) ) ) 5. Octet Encoding In this section, we describe how sentences constructed along the guidelines above are to be encoded into a stream of octets. NOTE. For the sake of precision, we use the term "octet" to refer to an 8-bit byte, since there exist (or have existed) machines that use bytes of different length. 5.1. Encoding-Extended S-Expression Syntax Before encoding a sentence, the ordering of SIDs within the sentence must be canonicalized. Under any given SID, the S-expressions shall be sorted in lexicographical order by SID code (but see Exception, below). For example, consider the expression (Delete (Outcome ...) (Initiator ...) (FileSource ...) ) The SID codes for Delete, Outcome, Initiator, and FileSource are 0x08000013, 0x08005001, 0x08001001, and 0x08001021, respectively. Therefore, the sentence should be reordered as (Delete (Initiator ...) (FileSource ...) (Outcome ...) ) The SIDs under Initiator naturally remain under Initiator, and so forth. The SIDs under each of the role SIDs are likewise sorted, and this continues until the sentence is sorted down to its atom SIDs. If at any level, two or more SIDs are identical, these SID "ties" may be broken arbitrarily. EXCEPTION: The expressions beneath the conjunctions ByMeansOf and HelpedClause are not to be reordered, since their meaning changes according to the ordering of the clauses beneath them. However, the "grandchildren" of these conjunctions are to be sorted, except as according to this same Exception. After the ordering has been canonicalized as described above, the CISL expression may be encoded. The following is a BNF-style "grammar" for S-expressions in CISL, along with encoding rules. It is emphasized that this "grammar" does NOT produce only valid sentences (validity being subject to the list of allowed SIDs given in Appendix A). It should be the case, however, that valid sentences have only one derivation according to the rules below. ::= '(' ')' E[SExpression] = length_encode(sid_encode(SID) E[Data]) sid_encode(SID) E[Data] ::= E[Data] = simple_encode(SimpleAtom) ::= E[Data] = array_encode(ArrayAtom) ::= E[Data] = E[SExpressionList] ::= E[SExpressionList] = E[SExpression] ::= E[SExpressionList] = E[SExpression] E[SExpressionList] The reader's attention is directed toward the first five rules, where most of the action takes place. In the following subsections, we will describe the following auxiliary encoding functions: * sid_encode is described in Section 5.2.1 * length_encode is described in Section 5.2.2 * simple_encode and array_encode are described in Section 5.2.3 5.2. Encoding Functions 5.2.1. SID Codes In general, SID codes are four octets long. The first octet is a bitfield that contains information about the SID and its data type. The rationale for this is to allow components that don't recognize a SID to parse around that SID and its data. Recall that for compactness, a data is not preceded by its length, except when that data is an array (in which case the data is preceded by the number of elements in the array). The following is a description of the contents of the first octet: Bit Interpretation --- -------------- 0 (MSB) -- 2 [Reserved, must be 0 for this revision] 3 0 = defined in this specification 1 = vendor-defined SID [if == 1, SID code is followed immediately by 4-octet SID developer ID] 4 -- 5 [Interpreted as an integer from 0 to 2, inclusive:] 0 = simple data type (i.e., not an array) 1 = arrayed data type 2 = S-expression data type (e.g., verb SID) 6 -- 7 (LSB) [Interpreted as an integer from 0 to 3, inclusive:] 0 = element data type is 1 octet long 1 = element data type is 2 octets long 2 = element data type is 4 octets long 3 = element data type is 8 octets long If a SID is not predefined in this specification (as indicated by bit 3 (MSB) of the first octet), then the SID code is followed by a 32-bit unique SID developer ID. These IDs will be distributed by a numbers authority. 5.2.2. Encoding Length The length of a datum is counted in octets. This length is encoded in a four-byte sequence: length_encode(l) = [l in four octets, big-endian order] For instance, a length of 6258 (decimal) is encoded in hex as 00 00 18 72 because 6258 (decimal) is equal to 1872 (hex), and 1872 requires two octets to encode. Another example is 165872 (decimal), which is encoded in hex as 00 02 87 f0 Length encodings are used in encoding S-expressions, SID definitions, and in data encoding. 5.2.3. Encoding Data If a SID code (bits 4--5) indicates that it takes a simple data type-- that is, one of the data types listed in Appendix A, Section A.1--then the data simply follows the SID code, with a length also indicated by the SID code (bits 6--7). That is, simple_encode(data) = [data in big-endian octet order] If a SID code indicates that it takes an arrayed data type, then an array length (in number of elements) follows the SID code, followed in turn by the array data. That is, array_encode(data) = length_encode([array count]) [data in ascending order, individually in big-endian octet order] The actual length, in octets, of that data is then equal to the array count times the length of the associated simple data type. 5.3. Example As an example of a sentence to encode, consider part of the example from Section 4.1. We will reproduce it here for ease of reference: (Delete (World Unix) (When (Time 14:58:12 24 Feb 1998 UTC) ) (Initiator (ReferTo 0x12345678) ) (FileSource (HostName 'ten.ada.net') (FullFileName '/etc/passwd') ) ) Let us examine the first clause within the Delete sentence, the simple S-expression (World Unix) According to the encoding rules set forth in Section 5.1, we first encode the SID, then encode the data. These encodings are concatenated, and prefixed with an encoding of their combined length. In Appendix A, Section A.2.5.1, we see that World has a SID code of 0x0600007a, and that the 'Unix' world is encoded as 0x00000001. We simply concatenate these to produce 06 00 00 7a 00 00 00 01 This concatenation has a combined length of 8, and this is encoded as a sequence of 4 octets, prefixed to the above sequence, so that the entire encoding comes out as 00 00 00 08 06 00 00 7a 00 00 00 01 Now let's take a more complex clause: (HostName 'ten.ada.net') As before, we begin with the SID code for HostName--this is 0x0400000c. It takes a string, which is an array of char. The string has a length of 11 (decimal), so the encoding of the string is the encoding for 11 followed by the ASCII encoding of the string: 00 00 00 0b 74 65 6e 2e 61 64 61 2e 6e 65 74 We then tack the SID code onto the beginning: 04 00 00 0c 00 00 00 0b 74 65 6e 2e 61 64 61 2e 6e 65 74 This combination has a length of 19 (decimal), so the encoding for the entire clause is 00 00 00 13 04 00 00 0c 00 00 00 0b 74 65 6e 2e 61 64 61 2e 6e 65 74 Let's take an entire role clause: (Initiator (ReferTo 0x12345678) ) We do the enclosed referent clause as before; the SID code for ReferTo is 0x02000078, so that clause is encoded as 00 00 00 08 02 00 00 78 12 34 56 78 The Initiator SID has a code of 0x08001001. Section 5.1 explains that we simply concatenate the role SID and its arguments, and again prefix the encoding of the combined length: 00 00 00 10 08 00 10 01 00 00 00 08 02 00 00 78 12 34 56 78 Proceeding similarly, we can encode the entire Delete sentence as follows: 00 00 00 70 08 00 00 13 (Delete 00 00 00 08 06 00 00 7a (World 00 00 00 01 Unix) 00 00 00 10 08 00 50 02 (When 00 00 00 08 02 00 00 01 (Time yy yy yy yy '14:58:12 24 Feb 1998 UTC')) 00 00 00 10 08 00 10 01 (Initiator 00 00 00 08 02 00 00 78 (ReferTo 12 34 56 78 0x12345678)) 00 00 00 34 08 00 10 21 (FileSource 00 00 00 13 04 00 00 0c (HostName 00 00 00 0b 74 65 6e 2e 'ten.ada.net') 61 64 61 2e 6e 65 74 00 00 00 15 04 00 00 13 (FullFileName 00 00 00 0d 2f 65 74 63 '/etc/passwd'))) 2f 70 61 73 73 77 6f 72 64 yielding a sequence of 117 octets. The proper decoding of this block is left as an exercise to the reader. 6. GIDO Addendums This section describes the GIDO addendum mechanism, which is used by a CIDF component to append information to an existing GIDO. The purpose of this appended information is to (1) provide a translation for information in the GIDO, (2) provide some additional information related to the event described in the GIDO, or (3) describe what was done in response to the GIDO. The objective of the GIDO addendum is to provide these capabilities without altering the original GIDO. This enables components to preserve the signature attached to the original GIDO, which enables originator authentication. It also allows components to see how the GIDO has been modified as it passes through CIDF devices. GIDO Addendums are used to modify a previous GIDO. When one applies the GIDO Addendum to a GIDO, one creates a new GIDO reflecting the changes specified in the Addendum. If there are multiple Addendums, then the first Addendum is applied to the GIDO to create a modified GIDO. The second Addendum is then applied to the resulting GIDO to create a further modified GIDO, and so on. The rules for applying the Addendums to create the modified GIDO are described in section 6.2. WARNING: All GIDO Addendums are understood to apply to the GIDO in its *canonical order* as described in Section 5.1. The reader is asked to pay particular attention to the implications of this statement on using the Instance SID described in the subsections below. 6.1. Overview of Addendum Use The following sections describe the situations where these mechanisms seem useful. 6.1.1. Translation The translation mechanism is useful is several situations. A second example of translation is when a network connection passes through a network address translation (NAT) device. A NAT device can translate a "private" Intranet address to a "public" address that is exported to the external world. NAT devices can also translate port numbers. For example, consider the following figure. The NAT device translates A's private address to the public address X. +-------------+ +------------+ +-------------+ | Intranet | | NAT Device | | Internet | | TELNET from |---------| A<->X |---------| TELNET from | | A to B | | | | X to B | +-------------+ +------------+ +-------------+ | | +--------+ +--------+ | Host A | | Host B | +--------+ +--------+ Within the Intranet, network events, such as a TELNET connection from A to B, would be represented as- (SourceIPV4Address A) (DestinationIPV4Address B) (TCPDestinationPort 23) The rest of the world would represent this same TELNET connection from A to B as- (SourceIPV4Address X) (DestinationIPV4Address B) (TCPDestinationPort 23) The translation mechanism enable a CIDF device that knows the translation to append the translation from A to X so that the Intranet events can be correlated with the same events viewed on the Internet. Firewalls also can cause network addresses, port numbers, and user names to changes as a user connects through the firewall. 6.1.2. Annotation The annotation mechanism enables a CIDF component to attach additional information related to the original GIDO. For example, a user may TELNET to host A as user 'fred', and then TELNET to host B as user 'barney'. In describing events related to the user's activities on host B, a CIDF component would include (Account (UserName 'barney') ) in the GIDO. A CIDF component that knows that the TELNET connection used for barney's events was in fact performed on host A under fred's account, could attach the embellishment indicating that 'barney' on host B is really 'fred' on host A, which could prove useful in correlating other fred-related events on host A to those of barney on host B. This could be done by adding the following information to the GIDO. (Initiator (UserName 'fred') ) This would provide the link from barney to fred. A second example has a network-based analysis engine may detect an anomaly in a TCP connection, but may not know the user identity associated with the connection. The resulting GIDO would describe the event. Another CIDF component that monitors the host from which the anomaly was transmitted might be able to determine the identity of the user associated with the event. The annotation mechanism enables the CIDF component to add the user identity to the original GIDO. This could help analysis engines that correlate user events. As another example, consider an engine that computes 'thumbprints' for connections. When it receives a GIDO describing a connection, it could use the annotation mechanism to attach the 'thumbprint' to the GIDO. This could be used by a correlation engine that ties together what appear to be disjoint connections. 6.1.3. Response The response mechanism enables a component responding to a specific GIDO to attach a description of the response to the GIDO. This enables other components to know the responses taken, which enables those components to determine their responses relative to what has already been done. For example, a GIDO may request that intermediate CIDF firewalls block SMTP for the next hour. A specific CIDF firewall's policy may permit blocking of SMPT for only 10 minutes during business hours. The response mechanism enables the CIDF firewall to attach to the original GIDO the fact that SMTP was blocked for 10 minutes so that other components can compensate. 6.2. GIDO Addendum Body GIDO addendum bodies are comprised of CIDF S-expression sentences, like standard GIDO bodies. However, the sentence structure is constrained as follows- 1. The top-level conjunction (if any) is restricted to 'And'. 2. The top-level verbs are restricted to 'TranslateSID', 'Translate', 'Embellish', and 'Did'. The following sections describe how to use these verbs. To help the exposition, they use the following example. (OpenApplicationSession (When (Time 14:57:36 24 Feb 1998) ) (Initiator (IPV4Address 198.76.29.7) ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 10.33.32.15) ) (Session (StandardTCPPort 23) ) ) The Addendum verbs are essentially instructions to the CIDF decoder logic on how to create the modified GIDO body resulting from applying the Addendum. 'Translate' instructs the decoder to modify data values in the original GIDO. 'Embellish' instructs the decoder to add new SIDs and corresponding data to the original GIDO. 'Did' instructs the decoder to add a new sentence to the original S-expression connected with the 'And' conjuction. 6.2.1. Translation To understand translation, one must first understand the concept of a 'branch' of S-expression. One can think of an S-expression as a tree, rooted with the top-level conjunction or verb and with leaves being the atom SIDs. A 'branch' of the S-expression is the list of SIDs from the root to the leave. For example, in above example, (OpenApplicationSession (Account (UserName 'fred'))) represents one of the branches. Two forms of translation are supported: (1) translation of a 'branch' of an S-expression tree, and (2) translation of a particular SID value. In the former case, the verb 'Translate' is used and in the latter, the verb TranslateSID is used. Both take two arguments: the first argument locates what is to be changed, and the second argument provides the new data values. The two arguments are identical except for the data values (i.e., the arguments to the atom SIDs). Additionally, either may be followed by the 'Instance' atom SID, which indicates the instance of the S-expression branch to which the translation is to be applied. Translate takes as arguments two S-expressions. The first S-expression specifies the set of data values to be changed. To obtain the translated S-expression, if no 'Instance' SID is specified, one globally searches the original S-expression (or the S-expression resulting from previous GIDO addendums) for an exact match with each branch of the first argument, and if all branches match some sub-tree of the original S-expression, the new data values for the S-expression are given in the second Translate argument. For the above S-expression, (Translate (OpenApplicationSession (Initiator (IPV4Address 198.76.29.7) ) (Account (IPV4Address 10.33.32.15) ) ) (OpenApplicationSession (Initiator (IPV4Address 10.41.10.2) ) (Account (IPV4Address 198.76.160.240) ) ) ) yields the following translated S-expression (OpenApplicationSession (When (Time 14:57:36 24 Feb 1998) ) (Initiator (IPV4Address 10.41.10.2) ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 198.76.160.240) ) (Session (StandardTCPPort 23) ) ) Note that both branches must match to cause the translation to occur. If both branches matched multiple locations within the GIDO body, then each is replaced. If an 'Instance' SID is specified with data value n, then one only translates the nth match of the branch. For example, consider the following S-expression. (And (OpenApplicationSession (When (Time 14:57:36 24 Feb 1998) ) (Initiator (IPV4Address 198.76.29.7) ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 10.33.32.15) ) (Session (StandardTCPPort 23) ) ) (OpenApplicationSession (When (Time 14:57:50 24 Feb 1998) ) (Initiator (IPV4Address 198.76.29.7) ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 10.33.32.15) ) (Session (StandardTCPPort 23) ) ) ) For the above S-expression, (Translate (Instance 2) (OpenApplicationSession (Initiator (IPV4Address 198.76.29.7) ) (Account (IPV4Address 10.33.32.15) ) ) (OpenApplicationSession (Initiator (IPV4Address 10.41.10.2) ) (Account (IPV4Address 198.76.160.240) ) ) ) yields the following translated S-expression (And (OpenApplicationSession (When (Time 14:57:36 24 Feb 1998) ) (Initiator (IPV4Address 198.76.29.7) ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 10.33.32.15) ) (Session (StandardTCPPort 23) ) ) (OpenApplicationSession (When (Time 14:57:50 24 Feb 1998) ) (Initiator (IPV4Address 10.41.10.2) ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 198.76.160.240) ) (Session (StandardTCPPort 23) ) ) ) The second form of translation provides the capability to search and replace an atom SID's data value. The verb 'TranslateSID' takes two arguments: (1) the original SID-data pair, and (2) the replacement SID-data pair. If no 'Instance' SID is specified, the semantics of TranslateSID is to globally search the original GIDO body (or the GIDO body resulting from previous GIDO addendums) for an exact match of the first atom SID and data value, and replace each matched data value with the corresponding data value from the second argument of the Translate SID. For the above S-expression, (And (TranslateSID (IPV4Address 198.76.29.7) (IPV4Address 10.41.10.2) ) (TranslateSID (IPV4Address 10.33.32.15) (IPV4Address 198.76.160.240) ) ) yields the following translated S-expression (OpenApplicationSession (When (Time 14:57:36 24 Feb 1998) ) (Initiator (IPV4Address 10.41.10.2) ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 198.76.160.240) ) (Session (StandardTCPPort 23) ) ) Again, if an 'Instance' SID is specified with data value n, then one only translates the nth match of the branch. 6.2.2. Annotation Annotations attach additional information about the event described in the GIDO using the 'Embellish' verb. The Embellish verb has a single argument which is an S-expression branch that represents the additional information. In the above example, if the following sentence is used in a GIDO addendum, (Embellish (OpenApplicationSession (Initiator (UserName 'fred') (RealName 'Fred Flintstone') ) ) ) the result is the following S-expression (OpenApplicationSession (When (Time 14:57:36 24 Feb 1998) ) (Initiator (IPV4Address 198.76.29.7) (UserName 'fred') (RealName 'Fred Flintstone') ) (Account (UserName 'barney') (RealName 'Barney Rubble') (HostName 'bedrock.net') (IPV4Address 10.33.32.15) ) (Session (StandardTCPPort 23) ) ) As a second example, consider the following S-expression. (ByMeansOf (Attack (When (BeginTime Fri Jun 12 21:23:34 1998) (EndTime Fri Jun 12 21:24:04 1998) ) (AttackID 0000000200000002) (Certainty 100) (Severity 50) ) (SendMessage (When (BeginTime Fri Jun 12 21:23:34 1998) (EndTime Fri Jun 12 21:24:04 1998) ) (Message (Multiplier 10) (IPV4Protocol 6) (SourceIPV4Address 135.52.160.1) (TCPSourcePort 32760) (DestinationIPV4Address 134.52.160.11) (TCPDestinationPort 23) ) ) ) If a CIDF component knows that the user 'fred' was associated with this attack, then it would add the following to the GIDO addendum. (Embellish (ByMeansOf (Attack (Initiator (UserName 'fred') ) ) ) ) The GIDO body resulting from applying the embellishment to the GIDO would be (ByMeansOf (Attack (When (BeginTime Fri Jun 12 21:23:34 1998) (EndTime Fri Jun 12 21:24:04 1998) ) (Initiator (UserName 'fred') ) (AttackID 0000000200000002) (Certainty 100) (Severity 50) ) (SendMessage (When (BeginTime Fri Jun 12 21:23:34 1998) (EndTime Fri Jun 12 21:24:04 1998) ) (Message (Multiplier 10) (IPV4Protocol 6) (SourceIPV4Address 135.52.160.1) (TCPSourcePort 32760) (DestinationIPV4Address 134.52.160.11) (TCPDestinationPort 23) ) ) ) In the case where there are multiple locations within the GIDO body where the embellishment could be placed, the embellishment is placed in each location if no 'Instance' SID is specified. That is, the 'Embellish' verb is an instruction to globally insert the information at each matching location. For example, consider the following S-expression. (And (Delete (FileSource (FileName 'file1') ) ) (Delete (FileSource (FileName 'file2') ) ) ) Applying the following embellishment (Embellish (And (Delete (Initiator (UserName 'joe') ) ) ) ) yields the following S-expression. (And (Delete (Initiator (UserName 'joe') ) (FileSource (FileName 'file1') ) ) (Delete (Initiator (UserName 'joe') ) (FileSource (FileName 'file2') ) ) ) In cases where the embellishment must only be attached to a particular branch of the S-expression tree, the 'Instance' SID is used as described in Translation. (And (Delete (FileSource (FileName 'file1') ) ) (Delete (FileSource (FileName 'file2') ) ) ) Applying the following embellishment (Embellish (Instance 2) (And (Delete (Initiator (UserName 'joe') ) ) ) ) yields the following S-expression. (And (Delete (FileSource (FileName 'file1') ) ) (Delete (Initiator (UserName 'joe') ) (FileSource (FileName 'file2') ) ) ) 6.2.3. Response Response sentences in GIDO addendums are identical in form to response directives, except response sentences use the verb 'Did' rather than 'Do'. For example, a component may request that some component (Do (BlockMessage (When (StartTime 14:57:36 24 Feb 1998) (EndTime 15:57:36 24 Feb 1998) ) ... ) ) A response addendum could look like (Did (BlockMessage (When (StartTime 14:57:36 24 Feb 1998) (EndTime 15:27:36 24 Feb 1998) ) ... ) ) indicating blocking for half an hour rather than the requested hour. The resulting GIDO body from applying the above 'Did' response to the 'Do' directive would be (And (Do (BlockMessage (When (StartTime 14:57:36 24 Feb 1998) (EndTime 15:57:36 24 Feb 1998) ) ... ) ) (Did (BlockMessage (When (StartTime 14:57:36 24 Feb 1998) (EndTime 15:27:36 24 Feb 1998) ) ... ) ) ) To understand who requested the blocking to occur, the application would need to use the original GIDO's originator ID. To understand where the blocking did occur, the application would need to use the addendum's originator ID. 7. GIDO Header This section describes the GIDO header used to encapsulate a sentence. The purpose of this header is to allow CIDF-compliant components to perform priority queueing on the processing of messages, to group related messages together, and to correspond with the originator of a message. A CIDF message comprises one or more GIDOs and one or more GIDO addendums (described in section 7). Each of these is followed by an optional signature, as shown below. +-----------------------+ | GIDO Header | +-----------------------+ | GIDO Body | +-----------------------+ | Signature | | (Optional) | +-----------------------+ | GIDO Header | +-----------------------+ | GIDO Body | | or | | GIDO Addendum Body | +-----------------------+ | Signature | | (Optional) | +-----------------------+ ... +-----------------------+ | GIDO Header | +-----------------------+ | GIDO Body | | or | | GIDO Addendum Body | +-----------------------+ | Signature | | (Optional) | +-----------------------+ A GIDO addendum modifies the immediately preceding GIDO. If multiple GIDO addendums follow a GIDO, then they are applied in the order they appear within the message. The details of how addendums modify the message are described in section 7.3. The message layer provides a CIDF application with a total message length, which is used to determine whether there are multiple GIDOs or GIDO addendums in the message. The GIDO header locates the end of the GIDO body and also indicates whether there is a signature following the GIDO body. The signature (if one is present) includes a length field that locates the end of the GIDO. If the sum of the GIDO length and the signature length is less than the total message length, then the subsequent octets are treated as a second GIDO header. The class ID in this header specifies whether this is another GIDO or a GIDO addendum modifying the previous GIDO. 7.1. Overview The header definition, presented in this section, consists of a series of constant fields that GIDO consumers can reliably parse to read basic data common across all GIDOs. The GIDO header is used to convey information about the GIDO itself, rather than details of the event, analysis report, or response prescription (which are captured in the payload). Each CIDF-compliant GIDO generated by any component MUST contain these fields in this order (for this version). Consult Appendix A for details on type definition. 7.2. The Header Fields The following is a list of the header fields, with their encoding, and a description of their interpretation: 1. Version ID (2 octets). Indicates the format revision used to encode this GIDO. This field consists of a one-octet major revision number followed by a one-octet minor revision number. This will naturally remain constant through all revisions (or at least allow backward compatibility). This version specifies version 1.0 (encoded as 0x0100). Note that two GIDOs or GIDO addendums in the same CIDF message need not have the same Version ID. [Editor's Comment: This field suggests that CIDF revision identifiers will follow a major.minor format. The CIDF working group must decide if this is the proper revision format, and must then define the meaning of major and minor revision indicators.] 2. Class ID (2 octets). Indicates the category that the event, analysis, or response generator believes the GIDO falls under. Class IDs are defined in Section 7.3. This field is intended to allow receivers to process high-priority GIDOs in a given field of expertise before all others. Note that some codes are reserved for user-defined Class IDs; the receiver must check to see if prior agreement exists between sender and receiver on these codes. This field also indicates whether a the following body is for a GIDO or GIDO extension. 3. Length (4 octets, big-endian). Indicates the octet length of the entire GIDO, including this header but excluding any optional digital signature. This field may be used to cross- check GIDO completeness. Length shall be a multiple of 4. If the actual GIDO length is not a multiple of 4, the GIDO shall be 0-padded to become 4-byte aligned. 4. Timestamp (4 octets, big-endian). Indicates the seconds since Unix epoch 1970. This time refers to the end time of the last event or state report that contributed to this GIDO or for GIDO addendums, the time at which the GIDO addendum was generated. 5. Thread ID (4 octets). Used to identify GIDOs with some common thread; all GIDOs about a given event (e.g., first report followed by successive updates) would share the same Thread ID. 6. Originator ID (16 octets). This is a UUID representing the identity and the instance of the component generating the GIDO or GIDO addendum. The exact format of this field is described in the architecture document (q.v.). 7. Flags (1 octet). The bits of this flags octet are to be interpreted according to the following table: Bit Meaning --- ------- 0 (LSB) set = optional signature present (see below). clear = no optional signature 1--7 (MSB) reserved (MSB = most significant bit) The GIDO payload, plain or compressed, immediately follows the header. If bit 0 in Flags is cleared, indicating no optional signature, the GIDO ends with the payload (indicated by the GIDO Length header field). Otherwise, if bit 0 is set, indicating that a digital signature of the content is present, this signature is contained in a structure following the GIDO payload. Recall that the GIDO Length header field indicates the end of the GIDO payload, not including the signature structure. The signature structure has the following fields in it: 1. Signature algorithm (2 octets). Indicates the specific algorithm used (e.g., RSA or DSS). Specific assignment of algorithm identifiers are specified in Appendix B. 2. Signature length (2 octets). Indicates the length, including this field (signature length), of the signature structure, in octets. 3. Signature algorithm specific length (2 octets). Indicates the length, including this field (signature algorithm specific length), of the signature algorithm specific parameters, in octets. 4. Algorithm-specific parameters. These parameters depend on the algorithm, and are only present if the signature algorithm parameter length is greater than 0. Algorithm parameter formats for specific algorithms are described in Appendix B. 5. Signature data. This field contains the result of applying the signature algorithm to the entire GIDO, including GIDO header, up to the start of the signature structure. For GIDO addendums, the signature covers the GIDO and GIDO addendums that the current GIDO addendum modifies. 7.3. Class ID Codes The first bit of the Class ID indicates whether the body is a GIDO or GIDO addendum. If the bit is clear, then the body is a GIDO. If the bit is set, then the body is a GIDO addendum and the remaining bits in the Class ID are identical to the preceding GIDO. The following default Class ID codes are defined for events and analysis results. Under this scheme, class ids 0 thru 15 are reserved for CIDF event priorities, and 16 thru 31 are reserved for analysis report priorities. In addition, class ids 32 thru 127 are reserved for future CIDF extensions. IDS developers may use the remaining range (128 thru 255) for application-specific purposes. The terms E-box, A-box, etc. are defined in the architecture document (q.v.). (Default Event Class IDs) 00 - Complete Event 01 - Intermediate Event 02 - Incomplete Event 03 - E-box Internal Error Report 04 - E-box Internal Warning Report 05 - E-box Internal Status Message 06 - Reserved for E 07 - Reserved for E : 15 - Reserved for (Default Analysis Class IDs) 16 - Critical Security Violation 17 - Potential Security Violation 18 - Suspicious Report 19 - Warning Report 20 - Intermediate Result 21 - Informational Report 22 - A-box Internal Error Report 23 - A-box Internal Warning Report 24 - Reserved for A 25 - Reserved for A : 31 - Reserved for A (Default Response Class IDs) 32 - Reserved for R-boxes 33 - Reserved for R-boxes : 47 - Reserved for R-boxes 48 - Reserved for future use 49 - Reserved for future use : 127 - Reserved for future use (Undefined Priority Codes) 128 - Undefined : : (Undefined values may be employed for : application-specific purposes.) 255 - Undefined Appendix A A.1. Data Types The following data types are used in this draft: octet: an unsigned 8-bit byte char: a 7-bit compliant (ASCII) byte short: a 16-bit value, big-endian, signed ushort: same as short, but unsigned long: a 32-bit value, big-endian, signed ulong: same as long, but unsigned float: a 32-bit floating point value, IEEE compliant double: a 64-bit floating point value, IEEE compliant Each of these data types may be arrayed. The length and encoding of these arrays are explained in Section 5 of the draft. A string is equivalent to an array of char. A.2. SID Listing In the following sections, each predefined SID is given with a number of its attributes: * Its Name is the name by which it is referred to in the explanatory text and in any examples. * Its Code is the four-byte code by which it is encoded in the CISL encoding defined in Section 5. * Its Type is its "part of speech": this may be any of the types described in Section 4.2. * Its Description is an English language specification of the meaning of the SID. If the SID is a verb, it gives the general meaning of the sentence which the SID heads. If it is a role or an adverb, it gives the usage of the information in the SIDs contained under the role or adverb SID. (Similarly for a attribute SID, except that here specifically the *relation* between the described object and its SID "parent" is given.) For an atom SID, it gives the interpretation of the attribute which follows the SID name/code. * Under "May Contain" is a list of those SIDs, and those SIDs only, which are allowed under this SID. Many of the "containable" SIDs have descriptions which further delineate their use under this SID. They may also indicate whether the contained SIDs are treated as subjects or objects, and whether they are pluralizable (q.v.) or not. In the absence of these indications, the SIDs are neither subjects nor objects, and they are not pluralizable. A.2.1. Verb SIDs A.2.1.1. File Verb SIDs Name: Copy Code: 08000001 Type: verb Description: A file, or set of files, is copied from one location to another. May Contain: Outcome: The exit status of the copy. When: This contains the time at which the copy was completed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The user process responsible for copying the files. (Subject SID. Not pluralizable.) FileSource: The source of the copy. This may specify either a file or a directory; if a directory is indicated, then all files in the directory are copied. The host of the source files should be given here. When copying multiple files (which may be from different directories), use multiple FileSource roles. (Direct object SID. Pluralizable.) FileDestination: The destination of the copy. This may specify either a single directory or a single file. If a directory, then all the files in the FileSource(s) are copied to the named directory. If a file, then there may only be one FileSource, and it must name a single file. (Otherwise, the sentence is malformed.) The host of the destination should be specified here. (Indirect object SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Move Code: 08000002 Type: verb Description: A file, or set of files, is moved from one location to another. May Contain: Outcome: The exit status of the move. When: This contains the time at which the move was completed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The user process responsible for moving the files. (Subject SID. Not pluralizable.) FileSource: The source of the move. This may specify either a file or a directory; if a directory is indicated, then all files in the directory are moved. When moving multiple files (which may be from different directories), use multiple FileSource roles. The host of the source file(s) should be given here. (Direct object SID. Pluralizable.) FileDestination: The destination of the move. This may specify either a single directory or a single file. If a directory, then all the files in the FileSource(s) are moved to the named directory. If a file, then there may only be one FileSource, and it must name a single file. (Otherwise, the sentence is malformed.) The host of the destination should be given here. (Indirect object SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Delete Code: 08000003 Type: verb Description: A file, or set of files, is deleted. May Contain: Outcome: The exit status of the delete. When: This contains the time at which the delete was completed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The user process responsible for deleting the files. (Subject SID. Not pluralizable.) FileSource: The source of the deleted files. This may specify either a file or a directory; if a directory is indicated, then all files in the directory are deleted. When deleting multiple files (which may be from different directories), use multiple FileSource roles. The host of the deleted files should be given here. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.2. Process Verb SIDs Name: Execute Code: 08000011 Type: verb Description: A program is executed. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, refer to the success or failure of the action of executing the code, regardless of whether the program returns an error code or not. ActualReturnCode is used to return the program's actual return value. When: This contains the time at which the program was initiated. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity executing the program. (Subject SID. Not pluralizable.) Process: The program being executed. It can be indicated either by name or by value. The name of the program may be indicated either by ProgramName or by FileName. If by value, the actual code of the program is inserted, in one of two formats: ArchictectureName, OSName, and CodeSequence; or LanguageName and ProgramText In either case, a ProcessID may be indicated here, so that later GIDOs may refer to it. The host on which the process is running should also be given here. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Suspend Code: 08000012 Type: verb Description: A program is suspended. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, refer to the success or failure of the action of suspending the program. When: This contains the time at which the program was suspended. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity suspending the program. (Subject SID. Not pluralizable.) Process: The program or process being suspended, since strictly speaking the Initiator can only suspend specific instances of a program in execution. This means that ProcessID should be given; in addition, to aid the receiver, the program may be identified using the methods outlined in Execute. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Resume Code: 08000013 Type: verb Description: A program in suspension is resumed. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, refer to the success or failure of the action of resuming the program. When: This contains the time at which the program was resuming. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity resuming the program. (Subject SID. Not pluralizable.) Process: The program or process being suspended, since strictly speaking the Initiator can only resume specific instances of a program in suspension. This means that ProcessID should be given; in addition, to aid the receiver, the program may be identified using the methods outlined in Execute. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Terminate Code: 08000014 Type: verb Description: A program in execution (or in suspension) is terminated. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, refer to the success or failure of the action of terminating the program. When: This contains the time at which the program was terminated. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity terminating the program. (Subject SID. Not pluralizable.) Process: The program or process being terminated, since strictly speaking the Initiator can only terminate specific instances of a program in execution. This means that ProcessID should be given; in addition, to aid the receiver, the program may be identified using the methods outlined in Execute. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.3. Host Status Verb SIDs Name: Reboot Code: 08000091 Type: verb Description: A machine is rebooted, either deliberately or accidentally, either legitimately or illegitimately. May Contain: Outcome: This indicates the success or failure of the reboot. Location: This contains the host that was rebooted, as well as the time at which it was rebooted. (Direct object SID. Pluralizable.) Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity responsible for performing the reboot. (Subject SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Shutdown Code: 08000092 Type: verb Description: A machine is powered down, either deliberately or accidentally, either legitimately or illegitimately. May Contain: Outcome: This indicates the success or failure of the shutdown. Location: This contains the host that was shutdown, as well as the time at which it was shutdown. (Direct object SID. Pluralizable.) Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity responsible for performing the shutdown. (Subject SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Boot Code: 08000093 Type: verb Description: A machine is powered up. May Contain: Outcome: This indicates the success or failure of the bootup. Location: This contains the host that was booted up, as well as the time at which it was booted up. (Direct object SID. Pluralizable.) Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity responsible for performing the bootup. (Subject SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.4. Network Verb SIDs Name: SendMessage Code: 08000041 Type: verb Description: A message is transmitted from one location to another. This is intended for the transport layer and below. An application-level description (such as for mail) should use the appropriate application-specific SID. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, represent the success or failure of the attempt to send a message. The actual return code should not be placed here. Instead, the encoder should use ByMeansOf to indicate the command by which the message would be sent, and use ActualReturnCode there. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity sending the message. (Subject SID. Pluralizable.) Receiver: The entity receiving the message. (Indirect object SID. Pluralizable.) Session: The channel on which the message is being sent. The encoder may use the NetworkProtocol and TransportProtocol SIDs to identify the type of channel. Message: The message being sent. The actual content of the message is indicated using Content. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: ObserveMessage Code: 08000042 Type: verb Description: An entity observes a message on the network. WARNING: This SID has been DEPRECATED. You should use SendMessage and describe the Observer in the Observer role. May Contain: When: This contains the time at which the message was observed. Observer: The entity observing the message. The host on which the observer resides should also be given here. (Subject SID. Pluralizable.) Message: The message being observed. The actual content of the message can be indicated using Content. Otherwise, other attributes of the message may be placed here, such as NetworkProtocol and TransportProtocol, or the various message header SIDs. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: MessageStatistics Code: 08000043 Type: verb Description: An entity gathers statistics on messages observed on the network. WARNING: This SID has been DEPRECATED. You should use SendMessage with the appropriate use of the Multiplier SID. May Contain: When: This contains the time(s) at which the messages were observed (for instance, StartTime and EndTime can be used to indicate an interval of observation). Observer: The entity gathering the statistics. The host on which the observer resides should also be given here. (Subject SID. Not pluralizable.) MessagePattern: The patterns that the messages are supposed to match. (Direct object SID. Not pluralizable.) Statistics: The statistics based on observation. Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.5. TCP Connection Verb SIDs Name: OpenTCPConnection Code: 08000098 Type: verb Description: This verb indicates that, in the belief of the observer, the Initiator began a TCP connection to the Receiver (as defined in RFC 793). Note that this SID cannot presently be used to accurately describe a connection in which both entities attempt to connect simultaneously (though this may succeed and is part of the the TCP RFC). May Contain: Outcome: Contains the status of the connection which should usually be specified with TCPConnectionStatus. If a Time atom appears in the When role, the status is as of that time. Otherwise, the status reflects the most successful status the connection achieved before being ended. When: Contains the time. Appearance of BeginTime indicates the time of the first packet that initiated the connection. Appearance of EndTime indicated the time of a packet which was believed to end the connection. Appearance of Time implies any time at which the connection was believed to be in existence. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity opening the session--that is, the entity sending the packet with initial Syn. (Subject SID. Not pluralizable.) Receiver: The entity serving the session request. The *actual* port serving the session will be given here, as opposed to the standard port, which is given in Session, below. (Indirect object SID. Not pluralizable.) Session: Attributes of the session. This will include information on what type of session is being opened (login, FTP, etc). (Direct object SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.6. Application Session Verb SIDs Name: OpenApplicationSession Code: 08000099 Type: verb Description: An entity opens an application session with another entity. To distinguish this from OpenTCPConnection, success or failure of this open is not based on the status of underlying TCP connection, but on application-specific criteria. For instance, login requests are handled using this verb (OpenApplicationSession); the request succeeds or fails on, e.g., the user supplying the correct username-password pair. May Contain: Outcome: Contains the status of the request (success, failure, etc.) When: Contains the time. Hostnames and addresses--anything identifying the location of the Initiator or Receiver--should be placed with their respective roles and not here. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity opening the session--that is, the entity sending the open session request. (Subject SID. Not pluralizable.) Receiver: The entity serving the session request. The *actual* port serving the session will be given here, as opposed to the standard port, which is given in Session, below. Account: Information about the account being logged into, if applicable. (Indirect object SID. Not pluralizable.) Session: Attributes of the session. This will include information on what type of session is being opened (login, FTP, etc). (Direct object SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: CloseApplicationSession Code: 08000023 Type: verb Description: A user closes a session. This may be any of the sessions opened via OpenApplicationSession. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, represent the success or failure of the attempt to close the session. ActualReturnCode is used to indicate the return value actually returned by the session in question when it finishes. When: This contains the time at which the session was closed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity operating the session (the client). The host starting the session should be given here. (Subject SID. Not pluralizable.) Session: The session being closed. ProcessID should be used to identify the server session that was closed. The host serving the session should be given here. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Login Code: 08000021 Type: verb Description: A user logs in or attempts to log in to an account. Login should be used whenever a new shell is started. Therefore, for example, su should be expressed using Login. WARNING: This SID has been DEPRECATED. You should use OpenApplicationSession with the proper StandardTCPPort identifier (e.g., 23 for telnet) in the Session role. May Contain: Outcome: The exit status of the login attempt. When: This contains the time of the login attempt, and also the host *serving* the login session. Observer: The entity which observed and/or recorded this occurrence. Initiator: The user attempting to log in. The host starting the login attempt should be put here. (Subject SID. Not pluralizable.) Account: Information about the user account being logged into. The host of the account should be given here. (Indirect object SID. Not pluralizable.) Session: Information about the session. ProcessID should be used to identify the login session process. The host serving the login session should also be given here (even if same as preceding). (Direct object SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: OpenFTP Code: 08000022 Type: verb Description: A user opens or attempts to open an FTP session to an account. Any session using the FTP protocol should be expressed using OpenFTP. WARNING: This SID has been DEPRECATED. You should use OpenApplicationSession with the proper StandardTCPPort identifier (21 for tcp) in the Session role. May Contain: Outcome: The exit status of the FTP open attempt. When: This contains the time of the FTP open attempt. Observer: The entity which observed and/or recorded this occurrence. Initiator: The user attempting to log in. The host that the user is directly opening the session from should be placed here. (Subject SID. Not pluralizable.) Account: Information about the user account being logged into. If this is an anonymous FTP session, the AnonFTPEMailAddr SID should be used. The host of the FTP account should be given here. (Indirect object SID. Not pluralizable.) Session: Information about the session. ProcessID should be used to identify the ftpd session process. The host serving the session should be identified here (even if same as preceding). (Direct object SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: SendMail Code: 08000051 Type: verb Description: A user sends mail to others. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, represent the success or failure of the attempt to send the mail. The actual return code should not be placed here. Instead, the encoder should use ByMeansOf to indicate the command by which the mail would be sent, and use ActualReturnCode there. When: The time at which the mail was sent. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity sending the mail message. (Subject SID. Not pluralizable.) Receiver: An entity designated to receive the mail message. (Indirect object SID. Pluralizable.) MailMessage: Information about the e-mail message. The actual contents of the mail can be indicated using Content. A mail message can also be referred to with HostName and MailMessageID. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.7. State Assertion Verb SIDs Name: ObserveState Code: 08000061 Type: verb Description: This gives the current state of the system. May Contain: When: This contains the time for which "current state" has meaning. It also delineates the "system." Observer: The entity observing the system. (Subject SID. Not pluralizable.) CurrentState: The current state of the system. Any attributes of the system may be given here. The host or network defined as "the system" should be identified here. (Direct object SID. Not pluralizable.) --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: ChangeState Code: 08000062 Type: verb Description: This reports a state change in the system. May Contain: When: This contains the time at which the CurrentState is observed. Observer: The entity observing the system. (Subject SID. Not pluralizable.) OldState: The previous state of the system. If there is a time associated with the old state, it should be given here. Any old attributes of the system may be given here. The system (host or network) is also identified here. (Direct object SID. Not pluralizable.) CurrentState: The current state of the system. Any current attributes of the system may be given here. The encoder should, however, use the same attributes which were given in the OldState. The system (host or network) is also identified here, even if same as preceding. (Direct object SID. Not pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.8. Authorization and Policy Verb SIDs Name: AcquireProxy Code: 08000031 Type: verb Description: A user gains or tries to gain the ability to act as another. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, represent the success or failure of the attempt to obtain the proxy. The actual return code should not be placed here. Instead, the encoder should use ByMeansOf to indicate the command by which the proxy would be acquired, and use ActualReturnCode there. When: This contains the time at which the proxy was obtained (or the attempt was made). Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity gaining the proxy. The host where the user is acting should be placed here. (Subject SID. Not pluralizable.) Proxy: The entity or entities on whose behalf the Initiator may now act. For example, if a UserName of 'root' is specified here, the Initiator has the ability to act as root. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: ReleaseProxy Code: 08000032 Type: verb Description: A user loses or releases the ability to act as another. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, represent the success or failure of the attempt to release the proxy (!). The actual return code should not be placed here. Instead, the encoder should use ByMeansOf to indicate the command by which the proxy would be released, and use ActualReturnCode there. When: This contains the time at which the proxy was released (or the attempt was made). Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity releasing the proxy. The host where the user is acting should be placed here. (Subject SID. Not pluralizable.) Proxy: The entity or entities on whose behalf the Initiator could previously act. For example, if a UserName of 'root' is specified here, the Initiator releases the ability to act as root. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Request Code: 08000801 Type: verb Description: An entity makes a request of another entity. "Request" here is taken in its informal sense; requests as part of transactional protocols should use the SendMessage SID. Any directly included S-expression headed by a verb is construed as a sentence indicating what the Initiator requests of the Receiver. There may be multiple sentences; these are treated as pluralized objects (q.v.). This SID is used to express "third-party" observations about policy decisions imposed by one party on another. (Of course, the observing party may be either the policy maker or the policy receiver, complicating matters somewhat.) It is NOT used to express an action that the sender of the GIDO wants the receiver to perform; for that purpose, the Do SID should be used instead. May Contain: When: This contains the time that the request was made. Appropriate hostnames should be included with the Initiator and Receiver roles. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity making a request. (Subject SID. Not pluralizable.) Receiver: The entity receiving the request. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- An S-expression headed by any of the following SIDs may be --- used to represent the actual request: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage OpenTCPConnection SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage Name: Require Code: 08000803 Type: verb Description: An entity requires another entity to perform an action. Any included S-expression headed by a verb is construed as a sentence indicating what the Initiator requires of the Receiver. There may be multiple sentences; these are treated as pluralized objects (q.v.). This SID is used to express "third-party" observations about policy decisions imposed by one party on another. (Of course, the observing party may be either the policy maker or the policy receiver, complicating matters somewhat.) It is NOT used to express an action that the sender of the GIDO wants the receiver to perform; for that purpose, the Do SID should be used instead. May Contain: When: This contains the time that the requiring was made. Appropriate hostnames should be included with the Initiator and Receiver roles. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity making the requirement. (Subject SID. Not pluralizable.) Receiver: The entity receiving the requirement. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- An S-expression headed by any of the following SIDs may be --- used to represent the actual requirement: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage OpenTCPConnection SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage Name: Allow Code: 08000804 Type: verb Description: An entity permits another entity to perform an action. Any included S-expression headed by a verb is construed as a sentence indicating what the Initiator allows to the Receiver. There may be multiple sentences; these are treated as pluralized objects (q.v.). This SID is used to express "third-party" observations about policy decisions imposed by one party on another. (Of course, the observing party may be either the policy maker or the policy receiver, complicating matters somewhat.) It is NOT used to express an action that the sender of the GIDO wants the receiver to perform; for that purpose, the Do SID should be used instead. May Contain: When: This contains the time that the permission was granted. Appropriate hostnames should be included with the Initiator and Receiver roles. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity granting the allowance. (Subject SID. Not pluralizable.) Receiver: The entity receiving the allowance. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- An S-expression headed by any of the following SIDs may be --- used to represent the actual allowed action: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage OpenTCPConnection SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage Name: Forbid Code: 08000805 Type: verb Description: An entity forbids another entity to perform an action. Any included S-expression headed by a verb is construed as a sentence indicating what the Initiator forbids to the Receiver. There may be multiple sentences; these are treated as pluralized objects (q.v.). This SID is used to express "third-party" observations about policy decisions imposed by one party on another. (Of course, the observing party may be either the policy maker or the policy receiver, complicating matters somewhat.) It is NOT used to express an action that the sender of the GIDO wants the receiver to perform; for that purpose, the Do SID should be used instead. May Contain: When: This contains the time that the forbidding was done. Appropriate hostnames should be included with the Initiator and Receiver roles. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity forbidding the action. (Subject SID. Not pluralizable.) Receiver: The entity being forbidden. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- An S-expression headed by any of the following SIDs may be --- used to represent the actual forbidden action: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage OpenTCPConnection SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage A.2.1.9. Auditing Verb SIDs Name: AuditAccount Code: 08000071 Type: verb Description: A user account is audited. May Contain: When: This contains the time at which (or during which) the auditing was performed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity performing the audit. (Subject SID. Not pluralizable.) Account: The account being audited. The host on which the account resides should be given here. (Direct object SID. Pluralizable.) Tool: The mechanism used to perform the auditing. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: AuditMessage Code: 08000072 Type: verb Description: Auditing is performed on specified messages. May Contain: When: This contains the time at which (or during which) the auditing was performed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity performing the audit. (Subject SID. Not pluralizable.) Message: The message(s) being audited. (Direct object SID. Pluralizable.) Tool: The mechanism used to perform the auditing. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: BlockMessage Code: 08000073 Type: verb Description: Specified messages are blocked. May Contain: When: This contains the time at which (or during which) the auditing was performed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity blocking the messages. (Subject SID. Not pluralizable.) Message: The message(s) being blocked. (Direct object SID. Pluralizable.) Tool: The mechanism used to block the messages. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: TraceMessage Code: 08000074 Type: verb Description: Specified messages are traced (to their source). May Contain: When: This contains the time at which (or during which) the auditing was performed. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity tracing the messages. (Subject SID. Not pluralizable.) Message: The message(s) being traced. (Direct object SID. Pluralizable.) Tool: The mechanism used to trace the messages. (Indirect object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.1.9. Analysis Verb SIDs Name: Attack Code: 08000081 Type: verb Description: This is an analysis by an analysis engine. It represents a diagnosis of an attack. Commonly it is used as the front end of a ByMeansOf (q.v.) structure--roughly speaking, "An attack occurred, by means of the following action." May Contain: Outcome: This indicates the success or failure of the attack. If the attack could be judged to have succeeded, then (for instance) the ReturnCode would be 0. Actual return codes should accompany the specifics of the attack in the tail ends of a ByMeansOf construct. When: This contains the time at which (or during which) the attack took place. Observer: The entity making the attack diagnosis. (Subject SID. Not pluralizable.) AttackSpecifics: High-level information about the attack. For example, the AttackID would go here. This is intended to be a "quick look" category so that systems that are expert in particular attacks could look for that ID and related parameters (if any). (Indirect object SID. Not pluralizable.) Initiator: The entity (if known) responsible for carrying out the attack. (Subject SID. Pluralizable.) Target: The entity (if known) that is the target of the attack. (Direct object SID. Pluralizable.) Multiplier: Means that this action was carried out the indicated number of times. Subject to interpretation as per Section 4.5. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Predict Code: 08000812 Type: verb Description: This is a prediction by an analysis engine. It requires a special SID because it does not represent either a successful or an attempted action. Any included S-expression headed by a verb SID is construed as a sentence indicating what the prediction is. The time and location of any prediction is to be placed in the prediction itself, not inside a When role directly within Predict. May Contain: Observer: The entity making the prediction. (Subject SID. Not pluralizable.) --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- An S-expression headed by any of the following SIDs may be --- used to represent the prediction: And HelpedCause ByMeansOf OpenApplicationSession CloseApplicationSession Login OpenFTP Request Require Allow Forbid Attack Copy Move Delete Execute Suspend Resume Terminate R