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 11 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) ) (Receiver (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') ) (Receiver (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). A ReferTo clause which points to a role ReferAs of this kind is subject to the following rules: The ReferTo clause can only appear directly below a role SID, and it must be the *only* clause appearing below that role SID. * 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. A ReferTo clause MUST NOT be placed anywhere within the scope of *any* ReferAs clause. Also, where a ReferTo effectively includes a sentence or a series of atom clauses, as described above, the included clauses MUST conform to the concordance as laid out in Appendix A. 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 up to three special roles: one which is the subject of the verb, one which is the direct object of the verb, and one which is the indirect object of the verb. (Not all three are required to be present for each verb.) These special roles may be either pluralizable or not. If a role is designated as pluralizable, then it may appear multiple times beneath the verb. At most one object role--direct or indirect--may be pluralized for any given 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. Attribute Inferences Inferences may not be made across simple sentences. Recall that a simple sentence is one containing exactly one verb SID, which is at the head. Descriptors are not inherited from one simple sentence to another, even when those simple sentences are connected by a conjunction. Note that this forces encoders to place each relevant piece of information in each position where it could be used. For example, in the following sentence (ByMeansOf (Attack ... (Target (HostName 'test.example.com') ) ) (SendMessage ... (Receiver ... ) ) ) one cannot infer fromt he HostName in the Target role that that is the host receiving the message in the SendMessage verb. To express that fact, the encoder must repeat the HostName clause within the Receiver role in the SendMessage simple sentence. 4.6.4. 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') (StandardTCPPort 79) (ReferAs 0x02020202) ) ) (SendMessage (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (ReferTo 0x01010101) ) (Receiver (ReferTo 0x02020202) ) (Message (ByteSize 72348) ) ) ) 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') ) (AttackSpecifics (AttackID 0x0000000100000057) (Certainty 100) (Severity 50) ) ) (And (ConnectTCP (When (Time 15:34:05 27 Mar 1999 UTC) ) (Initiator (ReferTo 0x01010101) ) (Receiver (HostName 'small.world.com') (StandardTCPPort 79) (ReferAs 0x02020202) ) ) (SendMessage (When (Time 15:34:10 27 Mar 1999 UTC) ) (Initiator (ReferTo 0x01010101) ) (Receiver (ReferTo 0x02020202) ) (Message (ByteSize 72348) ) ) ) ) 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) ) (Receiver (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) ) (Receiver (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) ) (Receiver (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) ) (Receiver (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) ) (Receiver (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) ) (Receiver (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) ) (Receiver (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) ) (Receiver (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 unique value representing the identity and the instance of the component generating the GIDO or GIDO addendum. The purpose of this field is to enable identification of the originator of a GIDO and to enable communication with this originator. (Note that an eventual goal of this field is to uniquely identify mobile CIDF components as well. The current implementation does not support that requirement.) The field has four sub-fields described as follows: IP address (4 octets, big-endian) - IP address of the originator. Process ID (4 octets, big-endian) - Process identity of the originator. Instance (4 octets) - Number (e.g., process start time) that when combined with process ID and IP address gives a unique value across a network over time. Pad (4 octets) - 0-filled field reserved for future use. 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. When: Indicates when the machine was rebooted. Machine: This contains the host that 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. When: This indicates when the machine was shut down. Machine: This contains the host that 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. When: This indicates when the machine was booted up. Machine: This contains the host that 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. Source addresses, ports, etc go in here (even if they might be forged). (Subject SID. Pluralizable.) Receiver: The entity receiving the message. Destination addresses, ports, etc go in here. (Indirect object SID. Pluralizable.) Session: The channel on which the message is being sent. Message: Information about the message being sent. The encoder may use the NetworkProtocol and TransportProtocol SIDs to identify the type of channel. (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. Attributes of the message should 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: TCPConnect 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. Source addresses, ports, etc go in here (even if it is possible that they are forged). (Subject SID. Pluralizable.) Receiver: The entity serving the session request. The *actual* port serving the session will be given here, as well as the standard port which specifies the protocol believed to be used on the connection. (Indirect object SID. Pluralizable.) Session: Attributes of the session. (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. Source addresses, ports, etc go in here (even if it is possible that they are forged). (Subject SID. Pluralizable.) Receiver: The entity serving the session request. The *actual* port serving the session will be given here, as well as the standard port used to identify the protocol believed to be used in the connection. (Direct object SID. Pluralizable.) Account: Information about the account being logged into, if applicable. (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: 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.) Receiver: 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.) Receiver: 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.) Receiver: ProcessID should be used to identify the FTP daemon 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. A mail message can 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 TCPConnect 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 TCPConnect 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 TCPConnect 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 TCPConnect 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.) AttackPath: The path traversed by the attack being traced. TracePath: The path traversed by the attack through the Observer. 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 Reboot Shutdown Boot SendMessage TCPConnect SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage A.2.1.11. Command Verb SIDs Name: Do Code: 08000811 Type: verb Description: This is an explicit request for an action. This is distinguished from Request in the following way: Request is used to express the thought, "X requests Y to do Z." Do is used to express the thought, "Do Z." In other words, a Request is a passive assertion of fact, that a request has taken place; a Do is an active request. Before acceding to the request, the actual receiver of the message should try to match itself to the Receiver, and to authenticate the Initiator, and to check the authorization of the Initiator to request the action. Any included S-expression headed by a verb SID is construed as a sentence indicating what it is that the Receiver should do. The time and location of the action are not included in the Do verb directly, but are instead placed in the included sentences. May Contain: Initiator: The entity making the request. (Subject SID. Not pluralizable.) Receiver: The entity receiving the request. (Direct object SID. Pluralizable.) Multiplier: Means that this action is to be 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 requested action: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage TCPConnect SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage A.2.1.12. Addendum Verb SIDs Name: Translate Code: 08000821 Type: verb Description: Translate is used only in GIDO addendums to provide translations of data fields (i.e., the arguments of atom SIDs) where needed because of Network Address Translation (NAT) devices, firewalls, etc. Translate defines how to translate branches of the original GIDO as described in section 6.2.1. May Contain: Instance: If an instance is specified, it indicates the instance to which this translation applies. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- The Translate verb expects two S-expressions headed by --- any of the following SIDs: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage ObserveMessage MessageStatistics TCPConnect OpenApplicationSession CloseApplicationSession Login OpenFTP SendMail ObserveState ChangeState AcquireProxy ReleaseProxy Request Require Allow Forbid AuditAccount AuditMessage BlockMessage TraceMessage Attack Predict Do Translate TranslateSID Embellish Did Name: TranslateSID Code: 08000822 Type: verb Description: TranslateSID is used only in GIDO addendums to provide translations of data fields (i.e., the arguments of atom SIDs) where needed because of Network Address Translation (NAT) devices, firewalls, etc. While Translate translates an entire branch of an S-expression, TranslateSID translates a single SID-value pair as described in section 6.2.1. May Contain: Instance: If an instance is specified, it indicates the instance to which this translation applies. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- The TranslateSID verb expects two S-expressions headed by --- any of the following SIDs: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage ObserveMessage MessageStatistics TCPConnect OpenApplicationSession CloseApplicationSession Login OpenFTP SendMail ObserveState ChangeState AcquireProxy ReleaseProxy Request Require Allow Forbid AuditAccount AuditMessage BlockMessage TraceMessage Attack Predict Do Translate TranslateSID Embellish Did Name: Embellish Code: 08000823 Type: verb Description: Embellish is used only in GIDO addendums to provide additional information related to the original GIDO. Embellish is used to annotate the original GIDO with information not provided by the originator as described in section 6.2.2. May Contain: Instance: If an instance is specified, it indicates the instance to which this embellishment applies. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World --- The Embellish verb expects a single S-expression headed by --- any of the following SIDs: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage ObserveMessage MessageStatistics TCPConnect OpenApplicationSession CloseApplicationSession Login OpenFTP SendMail ObserveState ChangeState AcquireProxy ReleaseProxy Request Require Allow Forbid AuditAccount AuditMessage BlockMessage TraceMessage Attack Predict Do Translate TranslateSID Embellish Did Name: Did Code: 08000824 Type: verb Description: Did is used only in GIDO addendums to provide a description of what was done in response to a request for an action (i.e., a sentence with the 'Do' verb) in the original GIDO. Did is used to express the thought, "I Did Z", where Z is the sentence represented by the S-expression following the Did verb. May Contain: --- 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 describe the performed action: And HelpedCause ByMeansOf Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage TCPConnect SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage A.2.2. Role SIDs A.2.2.1. General Purpose Role SIDs Name: Initiator Code: 08001001 Type: role Description: The process responsible for "doing" the containing verb. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs are used to describe the user executing --- the initiating process: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs are used to describe the process itself: ProcessID ProcessName ProcessStatus Priority RevPriority SystemTime UserTime CPUTime TCPPort UDPPort --- The following SIDs are used to describe the machine on which --- the user is executing the initiating process: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: Observer Code: 08001003 Type: role Description: The process observing an action or a system state, or analyzing a sequence of events. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs are used to describe the user running the --- observing process: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs are used to describe the observing process: ProcessID ProcessName ProcessStatus Priority RevPriority SystemTime UserTime CPUTime TCPPort UDPPort --- The following SIDs are used to describe the machine on which --- the observation is made: HostName FQHostName IPV4Address ArchitectureName OSName --- The following SIDs are used to describe the protocol used to --- express the observation: ObservationSourceType --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World A.2.2.2. File-Related Role SIDs Name: FileSource Code: 08001021 Type: role Description: The source of a file operation. This may be the source of a copy or a move, or it may be the target of a delete. It may contain the host on which the file resides (or at least can be accessed). More specific information about the interpretation of FileSource is included with each applicable verb description. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs are used to describe the file or files --- being copied, moved, or deleted: FileName FullFileName ByteSize TimeCreated TimeModified TimeAccessed DirectoryName FullDirectoryName MACObjectLabel AFSProtectionGroupName AFSACL --- The following SIDs are used to describe the host on which --- those files reside: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: FileDestination Code: 08001022 Type: role Description: The destination of a file operation. It may contain the host on which the file is to reside (or at least to be accessed). More specific information about the interpretation of FileDestination is included with each applicable verb description. May Contain: --- The following SIDs are used to describe the file or files --- which are newly placed as a result of a file copy or move: FileName FullFileName ByteSize TimeCreated TimeModified TimeAccessed DirectoryName FullDirectoryName MACObjectLabel AFSProtectionGroupName AFSACL --- The following SIDs are used to describe the host on which --- those files now reside: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World A.2.2.3. Process-Related Role SIDs Name: Process Code: 08001011 Type: role Description: A process executing on a single host. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs are used to describe the process running --- on the host. ProcessID ProcessName ProcessStatus Priority RevPriority SystemTime UserTime CPUTime TCPPort UDPPort --- The following SIDs are used to describe the program being run --- in the process. ProgramName VersionNumber LanguageName ProgramText CodeSequence --- The following SIDs are used to describe the file containing --- the executable running as the process. FileName FullFileName ByteSize TimeCreated TimeModified TimeAccessed DirectoryName FullDirectoryName MACObjectLabel AFSProtectionGroupName AFSACL --- The following SIDs are used to describe the host on which the --- process is running. HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: Tool Code: 08001013 Type: role Description: A mechanism used to perform an action. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs are used to describe the process the tool --- is running as: ProcessID ProcessName ProcessStatus Priority RevPriority SystemTime UserTime CPUTime TCPPort UDPPort --- The following SIDs are used to describe the program used as --- the tool: ProgramName VersionNumber LanguageName ProgramText CodeSequence --- The following SIDs are used to describe the file containing --- the executable for the tool: FileName FullFileName ByteSize TimeCreated TimeModified TimeAccessed DirectoryName FullDirectoryName MACObjectLabel AFSProtectionGroupName AFSACL --- The following SIDs are used to describe the host on which the --- tool is running: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World A.2.2.4. User-Related Role SIDs Name: Account Code: 08001031 Type: role Description: A user account. May Contain: --- The following SIDs describe the user who the account --- represents: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs describe the host on which that account --- resides: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: Proxy Code: 08001032 Type: role Description: A principal on behalf of whom an entity acts. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs describe the user whose privileges have --- been acquired or released: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs describe the host on which those --- privileges apply: HostName FQHostName IPV4Address ArchitectureName OSName --- The following SIDs describe the domain in which those --- privileges apply: --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World A.2.2.5. Network-Related Role SIDs Name: Receiver Code: 08001002 Type: role Description: The process receiving a message, being subjected to a policy. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs are used to describe the receiving user: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs are used to describe the process representing --- the receiver: ProcessID ProcessName ProcessStatus Priority RevPriority SystemTime UserTime CPUTime TCPPort UDPPort --- The following SIDs are used to describe the machine on which --- that process is running: HostName FQHostName IPV4Address ArchitectureName OSName --- The following SIDs are used to identify the specific protocol --- being used: StandardTCPPort StandardUDPPort --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: Session Code: 08001012 Type: role Description: A session (i.e., a communication) occurring (in general) between two hosts. This SID has been DEPRECATED; the contained information should be placed within the applicable Message or Receiver role. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs identify the protocol used to conduct the --- session: DataLinkProtocol NetworkProtocol TransportProtocol StandardTCPPort StandardUDPPort --- The following SIDs identify the host serving the session: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.2.6. Messaging-Related Role SIDs Name: Message Code: 08001051 Type: role Description: Information about a specific message referred to as part of a sentence. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs describe the protocol of which the message --- is a part (for instance, TCP if the message is a TCP packet): DataLinkProtocol NetworkProtocol TransportProtocol --- The following SIDs give the header fields of the message: EtherAddress EtherPreamble EtherType EtherFrameCheckSeq SourceIPV4Address DestinationIPV4Address SourceIPV4Mask DestinationIPV4Mask IPV4Port IPV4PortRange IPV4VerIHL IPV4ServiceType IPV4TotalLength IPV4Identifier IPV4Flags IPV4FragOffset IPV4TTL IPV4Protocol IPV4Checksum TCPSourcePort TCPDestinationPort TCPPortRange TCPSourcePortRange TCPDestinationPortRange TCPSequenceNumber TCPAckNumber TCPWindow TCPChecksum TCPUrgentPointer TCPMSS TCPFlags TCPFlagsMask UDPPort UDPSourcePort UDPDestinationPort UDPPortRange UDPSourcePortRange UDPDestinationPortRange UDPLength UDPChecksum ICMPType ICMPCode --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: MessagePattern Code: 08001052 Type: role Description: Information about a pattern that messages either do or do not match (e.g., for the purposes of giving context to statistics). WARNING: This SID has been DEPRECATED. You should use SendMessage with the appropriate use of the Multiplier SID. May Contain: --- The following SIDs describe the protocol of which the message --- is a part (for instance, TCP if the message is a TCP packet): DataLinkProtocol NetworkProtocol TransportProtocol --- The following SIDs give the header fields of the message: EtherAddress EtherPreamble EtherType EtherFrameCheckSeq SourceIPV4Address DestinationIPV4Address SourceIPV4Mask DestinationIPV4Mask IPV4Port IPV4PortRange IPV4VerIHL IPV4ServiceType IPV4TotalLength IPV4Identifier IPV4Flags IPV4FragOffset IPV4TTL IPV4Protocol IPV4Checksum TCPSourcePort TCPDestinationPort TCPPortRange TCPSourcePortRange TCPDestinationPortRange TCPSequenceNumber TCPAckNumber TCPWindow TCPChecksum TCPUrgentPointer TCPMSS TCPFlags TCPFlagsMask UDPPort UDPSourcePort UDPDestinationPort UDPPortRange UDPSourcePortRange UDPDestinationPortRange UDPLength UDPChecksum ICMPType ICMPCode --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: MailMessage Code: 08001054 Type: role Description: Information about an e-mail message referred to as part of a SendMail sentence. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs describe the e-mail message being sent: MailMessageID Content ContentType ContentEncoding --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.2.7. State-Related Role SIDs Name: OldState Code: 08001041 Type: role Description: A previous state of the system. May Contain: --- The following SIDs identify the host or network being defined --- as the "system": HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: CurrentState Code: 08001042 Type: role Description: A current state of the system (current defined with respect to the time given in the When). May Contain: --- The following SIDs identify the host or network being defined --- as the "system": HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: Machine Code: 08001043 Type: role Description: A machine which is either rebooted, booted, or shut down. May Contain: --- The following SIDs identify the host being powered up or down. HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World A.2.2.8. Analysis-Related Role SIDs Name: AttackSpecifics Code: 08001014 Type: role Description: High-level information about an attack. May Contain: --- The following SIDs are used to describe the attack: AttackNickname AttackID --- The following SIDs are used to describe the analyzer's --- appraisal of the seriousness of the attack: Certainty Severity --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: Target Code: 08001004 Type: role Description: The target of an attack, as described in the Attack verb. May Contain: Multiplier: If this role is designated as pluralizable under the containing verb, this SID may be used as described in Section 4.5. --- The following SIDs are used to describe the user that is the --- target of the attack: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs are used to describe the targeted process: ProcessID ProcessName ProcessStatus Priority RevPriority SystemTime UserTime CPUTime TCPPort UDPPort --- The following SIDs are used to describe the targeted machine: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are attribute SIDs: Owner Certifier Parent Developer --- The following are universally usable SIDs: Comment World Name: Statistics Code: 08001053 Type: role Description: A collection of statistics gathered as part of a sampling sentence, such as MessageStatistics. WARNING: This SID has been DEPRECATED. You should use SendMessage with the appropriate use of the Multiplier SID. May Contain: --- The following SIDs give summary statistics of the number of --- messages matching the accompanying MessagePattern: TotalCount MatchCount DistinctMatchCount --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.2.9. Auditing Role SIDs Name: AttackPath Code: 08001061 Type: role Description: Information about the path that an attack travels. This may not be the actual final path but a best guess. May Contain: IPV4Path: Identifies the path along which the attack traveled. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: TracePath Code: 08001062 Type: role Description: Information about how an event traveled through the observing component. May Contain: IPV4Path: Contains two IPv4 addresses, one identifying the connection where the event entered, the second where the event exited. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: ReceivedVia Code: 08001063 Type: role Description: The connection *from which* an event travels to the entering connection (see TracePath and TraceMessage). May Contain: IPV4Address: The IPv4 address of the sourcing connection. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: ReceivedFrom Code: 08001064 Type: role Description: The device that sent a trace request (see TracePath and TraceMessage). May Contain: IPV4Address: The IPv4 address of the requesting device. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: AuditPath Code: 08001065 Type: role Description: Information about how a component audited an event. May Contain: IPV4Path: Contains two elements, the first representing the connection into the component, the second the connection out of the component that the specified audit is being performed on. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: BlockPath Code: 08001066 Type: role Description: Information about how a component blocked an event. May Contain: IPV4Path: Contains two elements, the first representing the connection into the component, the second the connection out of the component that the specified block is applied to. --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.3. Adverb SIDs Name: Outcome Code: 08005001 Type: adverb Description: Information about the return status of the containing verb. This may affect the interpretation of the sentence, obviously: if the verb is Delete, but there is an Outcome including a clause such as (CIDFReturnCode failed), then the interpretation is that a Delete was attempted, but it didn't succeed. Inversely, if there is no Outcome role in a sentence, then the verb--if it represents an event--can be presumed to have happened successfully. May Contain: --- The following SIDs describe the observer's appraisal of the --- seriousness of the report: Certainty Severity --- When the verb represents an action, the following SIDs denote --- the status or the result of the attempted action: ReturnCode ActualReturnCode CIDFReturnCode TCPConnectionStatus --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: When Code: 08005002 Type: adverb Description: Information about when an event took place, or when a response is to take place (if the sentence is a prescription). May Contain: --- The following SIDs describe the time at which the event occurs: Time BeginTime EndTime Duration --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.4. Attribute SIDs Name: Owner Code: 08001801 Type: attribute Description: An entity with ownership rights to the object specified in the containing role clause. If there is no specific assignment of ownership, then this refers to an entity with the right to control access to the object. May Contain: --- The following SIDs describe the user who owns the parent object: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs describe the host on which that user resides: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Certifier Code: 08001802 Type: attribute Description: An entity which vouches for the identity of the object. May Contain: --- The following SIDs describe the user who certifies the parent --- object: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs describe the host on which that user resides: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Parent Code: 08001803 Type: attribute Description: An entity which created the object. May Contain: --- The following SIDs describe the user who created the parent --- object: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs describe the host on which that user resides: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World Name: Developer Code: 08001804 Type: attribute Description: An entity which developed the object (typically a program). May Contain: --- The following SIDs describe the user who developed the parent --- object: UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress --- The following SIDs describe the host on which that user resides: HostName FQHostName IPV4Address ArchitectureName OSName --- The following are referent SIDs: ReferAs ReferTo --- The following are universally usable SIDs: Comment World A.2.5. Atom SIDs A.2.5.1. General Purpose Atom SIDs Name: Comment Code: 0400000b Type: string Description: A comment in text. Name: Instance Code: 02000079 Type: ulong Description: The instance within a S-expression to which a translation or embellishment applies. Name: World Code: 0600007a Type: arrayulong Description: This SID takes a list of worlds as described in Section 4.3. Each world is represented by a name (used for human exposition), and a ulong code. This code is encoded in the same manner as SIDs are, although they represent a different name space. Currently defined worlds and codes are: Unix 00000001 Name: Multiplier Code: 0200007b Type: ulong Description: Briefly, pluralizes either an entire sentence or a single role clause within a sentence, with listed attributes being applied to each instance. For more details, see Section 4.5. A.2.5.2. File Descriptor SIDs Name: FileName Code: 04000012 Type: string Description: The name of a file. It may be incompletely specified; i.e., in the Unix world, it may be either 'passwd' or '/etc/passwd'; both are allowed. Name: FullFileName Code: 04000013 Type: string Description: The name of a file. It must be completely specified; i.e., in the Unix world, it must be '/etc/passwd', not just 'passwd'. Name: ByteSize Code: 02000005 Type: ulong Description: The length of a file, data structure (or in general any object whose size can be measured this way) in bytes (octets). Name: TimeCreated Code: 02000014 Type: ulong Description: The time at which an object (such as a file) was created. Expressed in seconds since Unix Epoch 1970. Name: TimeModified Code: 02000015 Type: ulong Description: The time at which an object (such as a file) was last modified. Expressed in seconds since Unix Epoch 1970. Name: TimeAccessed Code: 02000016 Type: ulong Description: The time at which an object (such as a file) was last accessed (read). Expressed in seconds since Unix Epoch 1970. Name: DirectoryName Code: 04000017 Type: string Description: As with FileName, but for a directory. Name: FullDirectoryName Code: 04000018 Type: string Description: As with FullFileName, but for a directory. Name: MACObjectLabel Code: 04000066 Type: string Description: The security label of an object. Name: AFSProtectionGroupName Code: 0400006e Type: string Description: The protection group associated with a given ACL. This is a combination of the form ::. Name: AFSACL Code: 0000006f Type: char Description: The access permission granted on a directory, to a a given AFSProtectionGroup, as given by the following table: r = Read. l = Lookup. i = Insert. d = Delete. w = Write. k = locK. a = Administer. A.2.5.3. Program Descriptor SIDs Name: ProgramName Code: 04000029 Type: string Description: A name (which may be colloquial) of a program (e.g., 'MS Word 5.0' or simply 'MS Word'), as opposed to the filename at which it resides on a particular host. Therefore, all instances of a single program should have the same ProgramName (as expressed by a given observer). Name: VersionNumber Code: 0400002a Type: string Description: A version number associated with a program. Name: LanguageName Code: 0400001b Type: string Description: A name of a programming language (e.g., 'Pascal'). Name: ProgramText Code: 0400006b Type: string Description: A source code program. Name: CodeSequence Code: 0400006c Type: arrayoctet Description: A machine-code (or byte-code) program. WARNING: This SID has been DEPRECATED. A.2.5.4. Process Descriptor SIDs Name: ProcessID Code: 02000027 Type: ulong Description: The ID number of a process. Name: ProcessName Code: 04000028 Type: string Description: The name of a process (typically used for daemon or service name). Name: ProcessStatus Code: 0000002b Type: octet Description: The status of a process, as given by the following table: 0 = active /* running */ 1 = suspended /* awaiting an OS action */ 2 = killed /* terminated by external signal */ 3 = finished /* terminated internally */ 4 = unknown (no such process?) 5-255 = reserved Name: Priority Code: 0100002c Type: short Description: The priority of a process, with high-priority processes being given a lower number. Name: RevPriority Code: 0100002d Type: short Description: As with Priority, but with high-priority processes being given a higher number. Name: SystemTime Code: 0200002e Type: float Description: Time spent (by a process) in system/kernel, in seconds. Name: UserTime Code: 0200002f Type: float Description: Time spent (by a process) in user space, in seconds. Name: CPUTime Code: 02000030 Type: float Description: Time spent (by a process) in execution, total, in seconds. That is, CPUTime = SystemTime + UserTime. Name: TCPPort Code: 0100004c Type: ushort Description: Abstraction of TCP header field. A.2.5.5. User Descriptor SIDs Name: UserName Code: 0400001c Type: string Description: The name of a user account. Name: RealName Code: 0400001d Type: string Description: A real name of (ordinarily) a human being (e.g., 'Joe Smith'). Name: PrincipalName Code: 0400001e Type: string Description: A name of an entity that may be used for authentication purposes. Kerberos names are PrincipalNames. Name: UserID Code: 0200001f Type: ulong Description: An ID number associated with a user account. It can be counted on to be unique per machine at any time. Name: CurrentUserName Code: 04000020 Type: string Description: A name associated with a user account that is active at a given time (as opposed to the name under which the user in question logged in). Name: CurrentUserID Code: 02000021 Type: ulong Description: An ID number associated with a user account that is active at a given time (see CurrentUserName). Name: EffectiveUserName Code: 04000022 Type: string Description: A name associated with a user account which represents the privileges held by a user session (as opposed to either a UserName or a CurrentUserName). Name: EffectiveUserID Code: 02000023 Type: ulong Description: An ID number associated with a user account which represents the privileges held by a user session (see EffectiveUserName). Name: GroupName Code: 04000024 Type: string Description: A name associated with a user group. This can be bound to either a user or an object such as a file. Name: GroupID Code: 02000025 Type: ulong Description: A user group ID number. (See GroupName.) Name: GroupUUID Code: 04000026 Type: string Description: A UUID associated with a group. This has stronger guarantees of non-duplication than a GroupID. The string is actually an array of 16 octets (bytes). Name: MACLabel Code: 04000062 Type: string Description: The security label of a user. Name: MACEffectiveLabel Code: 04000063 Type: string Description: The security label of a effective user. Name: MACClearances Code: 04000064 Type: string Description: The clearances of a user. Name: EMailAddress Code: 04000067 Type: string Description: A standard-format e-mail address (name@domain). A.2.5.6. Time Descriptor SIDs Name: Time Code: 02000001 Type: ulong Description: A moment in time, given in seconds since midnight at the beginning of 1970, UTC. If an action necessarily occupies an interval of time, and no other interval is given, this specifies the end of that interval. Name: BeginTime Code: 02000002 Type: ulong Description: A moment in time which indicates when an event began or is to begin. Expressed in seconds since Unix Epoch 1970. Name: EndTime Code: 02000003 Type: ulong Description: A moment in time which indicates when an event ended or is to end. Expressed in seconds since Unix Epoch 1970. Name: Duration Code: 02000004 Type: ulong Description: The length of an interval which an event spans. Expressed in *microseconds*. A.2.5.7. Host Descriptor SIDs Name: HostName Code: 0400000c Type: string Description: The name of a host. It may be incompletely qualified; i.e., it may be 'first' instead of 'first.example.com'; both are allowed. Name: FQHostName Code: 0400000d Type: string Description: As above, but a fully qualified host name (e.g., 'ten.ada.net.'). The ending dot is assumed if absent. Name: IPV4Address Code: 02000039 Type: ulong Description: The IPv4 address of the host. However, if this SID is accompanied by a IPV4Mask, then the combination refers to a network or subnet. Name: ArchitectureName Code: 04000019 Type: string Description: A name of a machine architecture (e.g., 'Intel 586'). Name: OSName Code: 0400001a Type: string Description: A name of an operating system (e.g., 'SunOS 4.1.3'). A.2.5.8. Domain Descriptor SIDs Name: DomainName Code: 0400000e Type: string Description: A (DNS) name of a domain. Name: FQDomainName Code: 0400000f Type: string Description: As above, but fully qualified (e.g., 'ada.net.'). Again, the ending dot is assumed if absent. Name: DomainID Code: 02000010 Type: ulong Description: An administrative domain's ID. Name: DomainUUID Code: 04000011 Type: arrayoctet Description: A UUID associated with an administrative domain. The array is 16 octets long. Name: KerberosKDCName Code: 0400006d Type: string Description: Indicates the host name of the Kerberos server. Name: AFSServerName Code: 04000070 Type: string Description: Indicates the name of the host serving the AFS file within a cell. Name: IPV4Address Code: 02000039 Type: ulong Description: The IPv4 address of the domain, masked by an accompanying IPV4Mask. Name: IPV4Mask Code: 0200003a Type: ulong Description: Makes a domain (typically a subnet) out of an accompanying IPV4Address (when used where allowed). A.2.5.9. Protocol Descriptor SIDs Name: DataLinkProtocol Code: 00000032 Type: octet Description: The data link protocol, as indicated by the following table: 0 = reserved 1 = Ethernet 2 = Token ring 3 = ARC net 4 = IEEE 802.5, SNAP header 5 = IEEE 802.2, FDDI 6 = IEEE 802.3, MAN 7 = SLIP 8 = PPP 9-255 = reserved Name: NetworkProtocol Code: 00000033 Type: octet Description: The network layer protocol, as indicated by the ETHER TYPES section in the IETF Assigned Numbers RFC. Name: TransportProtocol Code: 00000034 Type: octet Description: The transport layer protocol, as indicated by the Assigned Internet Protocol Numbers table of the IETF Assigned Numbers RFC. Name: StandardTCPPort Code: 01000095 Type: ushort Description: The standard TCP port for a session protocol, as defined in RFC 1700, or in the "living document" extensions, given as an FTP URL at the end of the port section in RFC 1700. They are used to identify the protocol (e.g., 23 for telnet) in a session. Name: StandardUDPPort Code: 01000096 Type: ushort Description: The standard UDP port for a session protocol, as defined in RFC 1700, or in the "living document" extensions, given as an FTP URL at the end of the port section in RFC 1700. They are used to identify the protocol (e.g., 23 for telnet) in a session. A.2.5.10. Ethernet Header SIDs Name: EtherAddress Code: 04000035 Type: arrayoctet Description: Ethernet header field. The array is 6 octets long. Name: EtherPreamble Code: 04000036 Type: arrayoctet Description: Ethernet header field. The array is 8 octets long. Name: EtherType Code: 01000037 Type: ushort Description: Ethernet header field. Name: EtherFrameCheckSeq Code: 02000038 Type: ulong Description: Ethernet header field. A.2.5.11. IPv4 Header SIDs Name: SourceIPV4Address Code: 0200003b Type: ulong Description: IPV4 header field. Name: DestinationIPV4Address Code: 0200003c Type: ulong Description: IPV4 header field. Name: SourceIPV4Mask Code: 0200003d Type: ulong Description: Mask for interpreting the accompanying IPV4 address field. Name: DestinationIPV4Mask Code: 0200003e Type: ulong Description: Mask for interpreting the accompanying IPV4 address field. Name: IPV4Port Code: 0100003f Type: ushort Description: IPV4 header field. Name: IPV4PortRange Code: 05000040 Type: arrayshort Description: A range of transport ports, to be used either in describing message patterns or response prescriptions. The array is 2 ushorts long. Name: IPV4VerIHL Code: 00000041 Type: octet Description: IPV4 header field. Name: IPV4ServiceType Code: 00000042 Type: octet Description: IPV4 header field. Name: IPV4TotalLength Code: 01000043 Type: ushort Description: IPV4 header field. Name: IPV4Identifier Code: 01000044 Type: ushort Description: IPV4 header field. Name: IPV4Flags Code: 00000045 Type: octet Description: IPV4 header field. Name: IPV4FragOffset Code: 01000046 Type: ushort Description: IPV4 header field. Name: IPV4TTL Code: 00000047 Type: octet Description: IPV4 header field. Name: IPV4Protocol Code: 00000048 Type: octet Description: IPV4 header field. This has been DEPRECATED; you should use TransportProtocol instead. Name: IPV4Checksum Code: 01000049 Type: ushort Description: IPV4 header field. A.2.5.12. ICMP Descriptor SIDs Name: ICMPType Code: 0000004a Type: octet Description: ICMP header field. Name: ICMPCode Code: 0000004b Type: octet Description: ICMP header field. A.2.5.13. TCP Header SIDs Name: TCPSourcePort Code: 0100004d Type: ushort Description: TCP header field. Name: TCPDestinationPort Code: 0100004e Type: ushort Description: TCP header field. Name: TCPPortRange Code: 0500004f Type: arrayshort Description: Provides the capability to specify a range of TCP ports in either describing message patterns or response prescriptions. The array is 2 ushorts long. Name: TCPSourcePortRange Code: 05000050 Type: arrayshort Description: Provides the capability to specify a range of TCP source ports in either describing message patterns or response prescriptions. The array is 2 ushorts long. Name: TCPDestinationPortRange Code: 05000051 Type: arrayshort Description: Provides the capability to specify a range of TCP destination ports in either describing message patterns or response prescriptions. The array is 2 ushorts long. Name: TCPSequenceNumber Code: 02000052 Type: ulong Description: TCP header field. Name: TCPAckNumber Code: 02000053 Type: ulong Description: TCP header field. Name: TCPWindow Code: 01000054 Type: ushort Description: TCP header field. Name: TCPChecksum Code: 01000055 Type: ushort Description: TCP header field. Name: TCPUrgentPointer Code: 01000056 Type: ushort Description: TCP header field. Name: TCPMSS Code: 01000057 Type: ushort Description: TCP header field. Name: TCPFlags Code: 00000058 Type: octet Description: TCP header field. Name: TCPFlagsMask Code: 00000059 Type: octet Description: TCP header field. A.2.5.14. UDP Header SIDs Name: UDPPort Code: 0100005a Type: ushort Description: Abstraction of UDP header field. Name: UDPSourcePort Code: 0100005b Type: ushort Description: UDP header field. Name: UDPDestinationPort Code: 0100005c Type: ushort Description: UDP header field. Name: UDPPortRange Code: 0500005d Type: arrayshort Description: Provides the capability to specify a range of UDP ports in either describing message patterns or response prescriptions. The array is 2 ushorts long. Name: UDPSourcePortRange Code: 0500005e Type: arrayshort Description: Provides the capability to specify a range of UDP source ports in either describing message patterns or response prescriptions. The array is 2 ushorts long. Name: UDPDestinationPortRange Code: 0500005f Type: arrayshort Description: Provides the capability to specify a range of UDP destination ports in either describing message patterns or response prescriptions. The array is 2 ushorts long. Name: UDPLength Code: 01000060 Type: ushort Description: UDP header field. Name: UDPChecksum Code: 01000061 Type: ushort Description: UDP header field. A.2.5.15. Mail Descriptor SIDs Name: MailMessageID Code: 04000094 Type: string Description: The tag used by an e-mail sending process (e.g., sendmail) to refer to a message, qualified by an associated HostName. Name: ByteSize Code: 02000005 Type: ulong Description: The length of a file, data structure (or in general any object whose size can be measured this way) in bytes (octets). Name: ContentType Code: 04000068 Type: string Description: The MIME type of an object (e.g., 'text/html'). Name: ContentEncoding Code: 04000069 Type: string Description: The MIME encoding of an object. Name: Content Code: 0400006a Type: arrayoctet Description: The actual content of an object (typically accompanies ContentType and/or ContentEncoding). WARNING: This SID has been DEPRECATED. A.2.5.16. Terminal Descriptor SIDs Name: TerminalName Code: 04000071 Type: string Description: A terminal name. A.2.5.17. Observation Descriptor SIDs Name: ObservationSourceType Code: 04000031 Type: string Description: The name of one of a number of standard auditing formats. A.2.5.18. Authorization Descriptor SIDs Name: ACL Code: 04000065 Type: string Description: An access control list, in some format. This ought to be standardized, but isn't. The following is a proposed format: Magic number: CIDFV1.0, followed by newline. Then a series of lines conforming to the following-- Principal name with no whitespace, wildcards accepted. Whitespace (but not newline). Object name with no whitespace, wildcards accepted. Whitespace (but not newline). A string of letters indicating permitted operations by that principal on that object, wildcards accepted. May include non-standard letters, but the following letters are defined: r = read, w = write, a = append, x = execute. Newline. Repeat above in multiple lines as necessary. A principal is permitted an action if any line gives it that permission. A.2.5.19. Statistics SIDs Name: TotalCount Code: 02000074 Type: ulong Description: The total number of objects sampled in a statistics-gathering session. WARNING: This SID has been DEPRECATED. You should use SendMessage with the appropriate use of the Multiplier SID. Name: MatchCount Code: 02000075 Type: ulong Description: The number of objects matching a pattern in a statistics-gathering session. WARNING: This SID has been DEPRECATED. You should use SendMessage with the appropriate use of the Multiplier SID. Name: DistinctMatchCount Code: 02000076 Type: ulong Description: The number of *distinct* objects matching a pattern in a statistics-gathering session. In particular, if an object is reported twice, it counts twice in MatchCount, but only once in DistinctMatchCount. WARNING: This SID has been DEPRECATED. You should use SendMessage with the appropriate use of the Multiplier SID. A.2.5.20. Attack Descriptor SIDs Name: AttackNickname Code: 04000072 Type: string Description: A nickname associated with a perceived attack (e.g., 'Ping of Death'). Name: AttackID Code: 06000073 Type: arraylong Description: An array of 2 longs that represents a basic category of attack (e.g., "Ping of Death"). This quantity is broken into two longs: the first long represents a list ID, and the second long represents a particular attack drawn from that list. Developers who wish to add new attacks to this list must acquire a list ID--however, once this has been done, new attacks can be added freely to that list. Here are the current lists: List ID = 0x00000001 (Penetration) 0x00000000 = Unknown penetration attack (i.e., not in current list) 0x00000002 = Password guessing attack 0x00000003 = Use of an unserviced port or port that is prohibited by policy 0x00000004 = Attempt to use well-known passwords against well-known accounts 0x00000005 = Send an ICMP redirect message 0x00000006 = Generic code for routing protocol attack - more specific codes are available to specific attack 0x00000007 = Generic code for NFS attack - more specific codes are available to specific attack 0x00000008 = RFC 822 mail from a pipe 0x00000009 = Fingerd attack 0x0000000a = TCP hi-jacking 0x0000000b = Enable or disable features and set values RPC.Admind 0x0000000c = BackOrifice command usage 0x0000000d = DNS hostname overflow attack (CA-98.05) 0x0000000e = DNS length overflow attack (CA-98.05) 0x0000000f = E-mail debug attack 0x00000010 = SMTP decode attack 0x00000011 = E-mail listserv buffer overflow attack 0x00000012 = E-mail WIZ attack 0x00000013 = Perl fingerd attack 0x00000014 = FTP args core dump attack 0x00000015 = FTP bounce attack (CA-97.27) 0x00000016 = FTP privileged port bounce attack 0x00000017 = FTP privileged port attack 0x00000018 = FTP CWD ~root attack 0x00000019 = FTP site exec .. attack 0x0000001a = FTP site exec tar attack 0x0000001b = HTTP campas cgi-bin attack 0x0000001c = HTTP count cgi-bin attack (CA-97.24) 0x0000001d = HTTP .. attack 0x0000001e = HTTP glimpse cgi-bin attack 0x0000001f = HTTP Internet Explorer .BAT file attack 0x00000020 = HTTP Internet Explorer 3.0 .URL/.LNK attack 0x00000021 = HTTP IIS 3.0 ASP %2e attack 0x00000022 = HTTP IIS 3.0 ASP . attack 0x00000023 = HTTP NCSA httpd buffer overflow attack 0x00000024 = HTTP Novell convert cgi-bin attack 0x00000025 = HTTP PHF attack 0x00000026 = HTTP PHP buffer overflow attack 0x00000027 = HTTP PHP cgi-bin file read attack 0x00000028 = HTTP SCO view-source cgi-bin attack 0x00000029 = HTTP SGI handler cgi-bin attack 0x0000002a = HTTP SGI Webdist cgi-bin attack 0x0000002b = HTTP access of Unix password file 0x0000002c = HTTP webSite Win-C-Sample attack 0x0000002d = HTTP webSite uploader file upload 0x0000002e = Ident newlines attack 0x0000002f = Ident buffer overflow attack 0x00000030 = IMAP buffer overflow attack 0x00000031 = INN control message attack 0x00000032 = INN buffer overflow attack 0x00000033 = IP fragmentation attack 0x00000034 = IRCd buffer overflow attack 0x00000035 = Kerberos IV user snarf attack (CA-96.03) 0x00000036 = NFS file handle guess attack 0x00000037 = NFS mknod attempt 0x00000038 = NFS UID bug attack 0x00000039 = NIS buffer overflow attack (CA-98.06) 0x0000003a = PCNFSd exec attack (CA-96.08) 0x0000003b = POP buffer overflow attack (CA-97.09 and CA-98.08) 0x0000003c = HP/UX remote watch attack 0x0000003d = Rlogin -froot attack 0x0000003e = SMB SessionSetupAndX password overflow 0x0000003f = Statd file creation attack 0x00000040 = Statd buffer overflow attack 0x00000041 = Sun SNMP Backdoor 0x00000042 = TFTP get command 0x00000043 = TFTP put command 0x00000044 = Windows .pwl password file access attempt 0x00000045 = Ypupdated exec attack (CA-95.17) 0x00000046 = Mountd buffer overflow (CA-98.12) 0x00000047 = Tooltalk stack overflow (CA-98.11) 0x00000048 = MIME buffer overflow (CA-98.10) 0x00000049 = FTP Signal Handling vulnerability (CA-97.16) 0x0000004a = Metamail MIME vulnerability (CA-97.14) 0x0000004b = Rlogin buffer overflow (CA-97.06) 0x0000004c = Email MIME buffer overflow (CA-97.05) 0x0000004d = Talkd stack smashing (CA-97.04) 0x0000004e = FTP site exec .. attack 0x0000004f = General buffer overflow, such as eject, ffbconfig, fdformat, etc. 0x00000050 = Reserved account (not intended to run processes) executed code 0x00000051 = Authority violation (EUID not Author) 0x00000052 = User altered environment configuration of other user 0x00000053 = Unix ps vulnerability 0x00000054 = Unauthorized password modification 0x00000055 = Unauthorized modification to system executable*/ 0x00000056 = Root was acquired by user not designated as an administrator 0x00000057 = Root was acquired by an unknown method (not SU, not setuid) 0x00000058 = Anonymous FTP user modified Filesystem 0x00000059 = FTP login using reserved account name 0x0000005a = FTP senstive file retrieval 0x0000005b = FTP site exec attack 0x0000005c = FTP core attack 0x0000005d = Syslog buffer overflow (CA-95.13) (New) List ID = 0x00000002 (Denial of Service) 0x00000000 = Unknown denial of service attack (i.e., not in current list) 0x00000001 = DNS cache poisoning (CA-98.05) 0x00000002 = SYN flood attack (CA-96.21) 0x00000003 = Ping Of Death attack (CA-96.26) 0x00000004 = Land denial of service attack (CA-97.28) 0x00000005 = Smurf denial of service attack (CA-98.01) 0x00000006 = Chargen/echo denial of service attack, aka Pepsi (CA-96.01) 0x00000007 = Ascend kill denial of service attack 0x00000008 = SMTP Qmail length denial of service attack 0x00000009 = SMTP Qmail RCPT denial of service attack 0x0000000a = Redirecting finger 0x0000000b = HTTP Apache denial of service attack 0x0000000c = Rwhod buffer overflow attack 0x0000000d = SNMP attack against WINS server 0x0000000e = Talk flash attack 0x0000000f = TearDrop fragmentation attack & variations (CA-97.28) 0x00000010 = UDP mal-formed packet attack 0x00000011 = Windows out-of-band denial of service attack (WinNuke) 0x00000012 = Resource exhaustion: process table 0x00000013 = Resource exhaustion: file system 0x00000014 = FTP NLIST denial of service 0x00000015 = Solaris mail bomb attack (New) List ID = 0x00000003 (Unusual Access) 0x00000000 = Unknown unusual access attack (i.e., not in current list) 0x00000001 = Unusual get/put of a file, such as /etc/passwd 0x00000002 = Connection not usually expected, but permitted by policy - connection need not complete 0x00000003 = Unusual traffic pattern 0x00000004 = No ARP reply indicating host is down 0x00000005 = HTTP Shell Interpreter Accesses 0x00000006 = Ident error in request 0x00000007 = Duplicate IP's 0x00000008 = Unknown IP protocol 0x00000009 = RealSecure session kills 0x0000000a = SelSvc remote holdfile attack 0x0000000b = Source-routed connections 0x0000000d = Windows remote registry read 0x0000000e = ActiveX controls in HTTP traffic 0x0000000f = Java in HTTP traffic 0x00000010 = ShockWave applets in HTTP traffic 0x00000011 = Vulnerable HTTP Client 0x00000012 = Malformed packets that violate TCP/IP rules 0x00000013 = Remote use of packet capturing tools 0x00000014 = Local use of packet capturing tools 0x00000015 = Errors while connecting to Windows servers 0x00000016 = Windows null session login (possible anonymous user backdoor) 0x00000017 = Attempted illegal login 0x00000018 = Successful illegal login 0x00000019 = Illegal privilege escalation 0x0000001A = Local host clock has been set back more than "cnt" seconds 0x0000001B = Suspicious Unix SYSCALL argument name 0x0000001C = Unix root core file creation 0x0000001D = Unix root core file access 0x0000001E = Suspicious private file alteration 0x0000001F = Suspicious file creation 0x00000020 = Modification of system resource 0x00000021 = Suspicious SETUID file created 0x00000022 = Warez client activity 0x00000023 = Warez server activity 0x00000024 = Possible Trojan horse execution 0x00000025 = Critical process killed 0x00000026 = Possible Loadmodule attack 0x00000027 = Access denied to a file or object 0x00000028 = Process subversion (New) 0x00000029 = Process abuse (New) List ID = 0x00000004 (Flooding) 0x00000000 = Unknown flooding attack (i.e., not in current list) 0x00000001 = Unusually high number of UDP datagrams 0x00000002 = Unusually high number of ICMP datagrams 0x00000003 = HTTP Get (New) List ID = 0x00000005 (Probe) 0x00000000 = Unknown probe attack (i.e., not in current list) 0x00000001 = Standard port scan 0x00000002 = DNS requests for host information 0x00000003 = DNS Zone Xfer from high port number 0x00000004 = DNS Zone transfers 0x00000005 = SMTP Expn: line 0x00000006 = SMTP Vrfy: line 0x00000007 = Use of FTP SYST command 0x00000008 = HTTP nph-test-cgi attack (CA-97.07) A.2.5.21. Alert Descriptor SIDs 0x0000000a = HTTP test-cgi attack 0x0000000b = TCP half scan attack 0x0000000c = ISS scan (CA-93.14) 0x0000000d = Portmap dump attack 0x0000000e = Normal or heavy SATAN scan of a machine (CA-95.07a) 0x0000000f = Traceroute being used to map the net 0x00000010 = FTP directory probing 0x00000011 = Light SATAN scan of a machine (New) 0x00000012 = Ping scan (New) 0x00000013 = Finger probe (New) 0x00000014 = Port map dump (New) 0x00000015 = Ruser (New) 0x00000016 = Mount scan (New) 0x00000017 = Ping sweep (New) 0x00000018 = Horizontal scan (New) A.2.5.21. Alert Descriptor SIDs Name: Certainty Code: 00000006 Type: octet Description: The certainty with which an analysis result is believed to hold, as measured by the observer. Values of 101 through 255 are invalid. A value of 100 means absolute certainty. A value of 0 means no certainty; it does not mean that there is absolute certainty that the analysis does *not* hold (this shouldn't be used very often). Name: Severity Code: 00000007 Type: octet Description: The severity of an event, as measured by the observer. A value of 0 means that the event is believed to represent no risk to the system (again, this shouldn't be used very often). A value of 100 expresses maximum severity. What represents maximum severity will clearly vary from system to system. In other words, caveat receptor. Values of 101 through 255 are invalid. A.2.5.22. Outcome or Status Descriptor SIDs Name: ReturnCode Code: 01000008 Type: short Description: A generic return code value, which indicates the result of an (attempted) action. The only thing one may assume is that zero means success. Nonzero values may indicate failure, or they may indicate that the result is pending some removal of a block, or that success was qualified in some way. The primary value of this SID is to serve as a lowest common denominator feedback and as a base class for other return code SIDs. Name: ActualReturnCode Code: 01000009 Type: short Description: The actual return code as delivered by a program, a script, a function call, etc. To use this extension, the return code must satisfy the "zero=success" constraint. Name: CIDFReturnCode Code: 0100000a Type: short Description: This is also a generic return code value, but designed to supply more information than a bare ReturnCode. This is an enumerated value, according to the following table: 0 = success 1 = pending 2 = failed (no reason given) 3 = failed due to server error 4 = failed, rejected by server 5 = failed due to client error 6 = failed, interrupted by user 7+ = reserved Name: TCPConnectionStatus Code: 01000097 Type: ushort Description: One of the following enumerated values: 0: Connection in an otherwise not-enumerated state. 1: Initial SYN packet sent only 2: Intial SYN and SYN-ACK response from receiver only 3: Three way handshake achieved but no application data sent 4: Connection established in good health and application data transmitted A.2.5.23. Auditing Related Atom SIDs Name: IPV4Path Code: 0600009a Type: arrayulong Description: An array of IPv4 addresses--each in network (big-endian) byte order--representing the path that an event traverses. A.2.6. Conjunction SIDs Name: And Code: 08004001 Type: conjunction Description: The 'And' conjunction takes two or more sentences as arguments. If each of the sentences is an event, then the compound sentence headed by 'And' asserts that all the events took place. If each of the sentences is a prescription, then the compount sentence prescribes all of the prescriptions. Format: (And ... ) May Contain: --- The following are referent SIDs: ReferAs ReferTo --- The And SID may contain any number of sentences headed by any --- of the following SIDs: And Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage ObserveMessage MessageStatistics TCPConnect OpenApplicationSession CloseApplicationSession Login OpenFTP SendMail ObserveState ChangeState AcquireProxy ReleaseProxy Request Require Allow Forbid AuditAccount AuditMessage BlockMessage TraceMessage Attack Predict Do Translate TranslateSID Embellish Did Name: HelpedCause Code: 08004004 Type: conjunction Description: Sentence1 through SentenceN are all true, and furthermore, Sentence2 through SentenceN all represent events. In addition, Sentence1 helped cause Sentence2 to happen, Sentence2 helped cause Sentence3 to happen, and so forth. Note that Sentence1 does not have to be an event; it could be a system state that set the stage for Sentence2. Format: (HelpedCause ... ) May Contain: --- The following are referent SIDs: ReferAs ReferTo --- The HelpedCause SID must contain two sentences headed by --- any of the following SIDs: And HelpedCause ByMeansOf OpenApplicationSession CloseApplicationSession Login OpenFTP Request Require Allow Forbid Attack Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage TCPConnect SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage Name: ByMeansOf Code: 08004007 Type: conjunction Description: Sentence1 through SentenceN are all events. More precisely, Sentence1 occurred by means of Sentence2, and Sentence2 occurred by means of Sentence3, and so forth. For example, one logs into a machine *by means of* opening a telnet session with that machine. Format: (ByMeansOf ... ) May Contain: --- The following are referent SIDs: ReferAs ReferTo --- The ByMeansOf SID may contain any number of sentences headed --- by any of the following SIDs: And HelpedCause ByMeansOf OpenApplicationSession CloseApplicationSession Login OpenFTP Request Require Allow Forbid Attack Copy Move Delete Execute Suspend Resume Terminate Reboot Shutdown Boot SendMessage TCPConnect SendMail AcquireProxy ReleaseProxy AuditAccount AuditMessage BlockMessage TraceMessage A.2.7. Referent SIDs Name: ReferAs Code: 02000077 Type: ulong Description: (See Section 4.2.7.) Name: ReferTo Code: 02000078 Type: ulong Description: (See Section 4.2.7.) Appendix B B.1. Signature Algorithm Field Values Signature algorithm field values are specified in the following table. Note that the value 0 is not a valid algorithm field value. +------------------------------------------------+ | Value | Algorithm | Algorithm Specification | +------------------------------------------------+ | 1 | DSS-SHA | FIPS PUB 186, FIPS PUB 180 | +------------------------------------------------+ B.2. Algorithm-Specific Parameters B.2.1. DSS-SHA 1. p Size (1 octet). Size of the DSS 'p' parameter. If this value is 0, then the receiver should use the local 'p' parameter. 2. p (0-128 octets). The value of the DSS 'p' parameter. 3. q Size (1 octet). Size of the DSS 'q' parameter. If this value is 0, then the receiver should use the local 'q' parameter. 4. q (0-20 octets). The value of the DSS 'q' parameter. 5. g Size (1 octet). Size of the DSS 'g' parameter. If this value is 0, then the receiver should use the local 'g' parameter. 6. g (0-128 octets). The value of the DSS 'g' parameter. Appendix C C.1. References [SExp] http://theory.lcs.mit.edu/~rivest/sexp.html