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 9 April 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. Finally, 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. 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 Nevertheless, we propose to take a similar tack. We will begin with a general language construct, called S-expressions [ref]. 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 IntentionallyHelpedCause; this SID is 24 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-educated readers at least plausible. (InSequence (Login (Location (Time '14:57:36 24 Feb 1998') ) (Initiator (HostName 'big.evil.com') ) (Account (UserName 'joe') (RealName 'Joe Cool') (HostName 'ten.ada.net') (ReferAs 0x12345678) ) ) (Delete (World Unix) (Location (HostName 'ten.ada.net') (Time '14:58:12 24 Feb 1998') ) (Initiator (ReferTo 0x12345678) ) (Source (AbsoluteFileName '/etc/passwd') ) ) (Login (World Unix) (Outcome (CIDFReturnCode Failed) (Comment '/etc/passwd missing') ) (Location (Time '15:02:48 24 Feb 1998') ) (Initiator (HostName 'small.world.com') ) (Account (UserName 'mworth') (RealName 'Mary Worth') (HostName 'ten.ada.net') ) ) ) 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 Login, will be described in Section 4.2 * Role SIDs, such as Initiator and Destination, will be described in Section 4.3 * Adverb SIDs, such as Outcome and Location, will be described in Section 4.4 * Attribute SIDs, such as Owner, will be described in Section 4.5 * Atom SIDs, such as Username and Time, will be described in Section 4.6 * The referent SIDs, ReferTo and ReferAs, will be described in Section 4.7 * Conjunction SIDs, such as InSequence, will be described in Section 4.8 4.2. 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.3. 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.4. Adverb SIDs In addition, there are role SIDs that do not describe an object, but locate a verb SID or modify its meaning. They can be thought of as adverbial SIDs. The two currently defined are Location and Outcome. 4.5. Attribute SIDs Most role SIDs may only occur directly under a verb SID, but others, called attribute SIDs, can only occur directly under other role SIDs. Attribute SIDs are SIDs that describe an entity that has a relation to another entity, rather than to the whole sentence. 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 Source clause, and identifies the owner in an Owner clause that is placed directly within the Source clause, as follows: (Source # information about the file (Owner # information about the file's owner ) ) A role SID that is not an attribute SID can be distinguished by calling it an *ordinary* role SID. 4.6. 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.10 and 4.11. 4.7. Referent SIDs Referent SIDs allow one to link two or more sentences together (or occasionally, 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 or a role clause. Their interpretation varies depending on which case applies: * If a ReferAs clause is placed into a sentence, it can be said to *refer* to that sentence, *except* for any ReferAs clauses. (It is considered bad form to use more than one ReferAs clause in the same sentence at the top level.) Thereafter, a use of the corresponding ReferTo clause can be used in place of that sentence (although see warning below). * If a ReferAs clause is placed into a role clause, it is said to refer to the object described by the sequence of S-expressions following that role, *except* for any ReferAs clauses. (It is considered bad form to use more than one ReferAs clause in the same role clause.) Thereafter, a use of the corresponding ReferTo clause can be used in place of that object description (again, see warning below). * WARNING. The referent SIDs carry actual semantics, and are not simply macros. If a ReferAs clause is placed into a sentence, and that sentence refers to an event (say), then the ReferTo clause refers specifically to that specific event, and not simply to an event with the same attributes (which after all may not be uniquely identifying). Similarly, if a ReferAs clause is placed into a role clause, and that role clause describes an object (say) then the ReferTo clause refers specifically to the same object, and not simply to an object with the same attributes. Of course, if no specific item is denoted by the ReferAs clause, then this warning does not apply. For example, if ReferAs occurs in an assertion of state, then it can be interpreted as simply a macro, since there is no unique item being denoted. The scope rule applying to referent SIDs is as follows: The value of a referent clause is the verb or role within which it is found (roughly speaking), provided that that verb or role is in the same thread. A thread is defined as follows: * Any two parts of an S-expression (which may contain other S-expressions) is in the same thread. For instance, the entire example in Section 4.1 is all in the same thread. * If sentences are being transported with a GIDO header (as defined in Section 6), then a thread is further extended to cover all GIDOs with the same originator ID and thread ID. A producer MUST NOT re-use a referent (such as 0x12345678) within the same thread, for perpetuity. 4.8. 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 (Attack ...) (Login (Outcome (ReturnCode 1) ...) ...) (GatherMessageStats ...) ) to indicate that an attack occurred (which is ) as described by a failure to log in (), as illustrated by the following message packets (). Incidentally, ByMeansOf may take an arbitrary number of sentences; the notion of that SID being followed sequentially down the sentences. 4.9. 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 is 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) (Location (Time 123471298) (HostName wherefore.cs.ucdavis.edu) ) (Initiator (UserName stanifor) (Source (World SMB) (FileName '\\whatever\share1\ProgramFiles\SomeFile') ) ) 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 Source Filename, because they are overridden by the (World SMB) which appears in the Source 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. 4.10 Plural SIDS. 4.10.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.10.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.10.2 Subjects and Objects below Verbs For each verb SID, Appendix A denotes two special roles: one which is the subject of the verb, and one which is the object. The subject and object roles may appear multiple times beneath the verb. The interpretation of multiple subjects and/or objects is the association of each subject-object pair with the verb (but please refer to the "Note well" below). For example, the sentence "Joe executed (the commands named by) file1, file2, and file3" can be represented as (Execute (Initiator (UserName 'joe') ) (Process (FileName 'file1') ) (Process (FileName 'file2') ) (Process (FileName 'file3') ) ) Note that this has the same meaning as (And (Execute (Initiator (UserName 'joe') (ReferAs 0x1234) ) (Process (FileName 'file1') ) ) (Execute (Initiator (ReferTo 0x1234) ) (Process (FileName 'file2') ) ) (Execute (Initiator (ReferTo 0x1234) ) (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 0x1235) ) (Process (FileName 'file1') (ReferAs 0x1236 ) ) (Execute (Initiator (ReferTo 0x1235) ) (Process (FileName 'file2') (ReferAs 0x1237) ) (Execute (Initiator (UserName 'mary') (ReferAs 0x1238) ) (Process (ReferTo 0x1236) ) ) (Execute (Initiator (ReferTo 0x1238) ) (Process (ReferTo 0x1237) ) ) ) 4.11. 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. 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.12. Guidelines on Construction 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.12.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.12.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 on this ground. For instance, in the example below (InSequence (Delete (Initiator (RealName 'Joe Cool') ) (Source (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 Source SIDs within that sentence, even if it understands those, because it will not understand what they are the Initiator and Source *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.12.3. Rules and Guidelines for Using SIDs Whenever a component puts a SID into a sentence, the SID MUST be used with the number of arguments (usually one) that the SID's definition calls for (see the definitions in Appendix A). The SID's argument(s) MUST have the syntax and meaning that the SID's definition calls for. Otherwise the component is OUT OF CONFORMANCE with the SID's definition. A component that generates sentences MUST generate them in conformance with all of the SID definitions in this specification. Whenever the above rule permits, a component generating a sentence SHOULD use a SID from this specification. If this is not possible, then the implementation MUST define a new SID; misusing an existing SID is not allowed. If a component generating sentences uses a SID from a particular specification, and if that specification defines two applicable SIDs, one of which is strictly more specific than another, then the component SHOULD use the more specific one. If CIDF component X creates a sentence and CIDF component Y later has a copy of the sentence and passes it verbatim to CIDF component Z, then Y MAY do so even if the sentence violates the above rules and guidelines. The sentence MUST be passed verbatim and SHOULD be clearly ascribed to its originator. This provision frees databases and such from having to thoroughly understand and validate every sentence they process. However, if the CIDF component modifies any part of the sentence, then it is responsible for the sentence's compliance with the above rules and guidelines. 4.13. Detailed Examples [To be written.] 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 The following is a BNF-style "grammar" for S-expressions in CISL, along with encoding rules. In the exposition, the following terminals are assumed to be defined 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 * length_encode is described in Section 5.3 * simple_encode and array_encode are described in Section 5.4 5.2. 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.3. 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 6256 (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.4. Encoding Data If a SID code (bits 2--3) indicates that it takes a simple data type, then the data simply follows the SID code, with a length also indicated by the SID code (bits 4--6). 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] If a SID code indicates that it takes a dummy argument, that argument is encoded by a single octet, indicating the order of that dummy argument within the accompanying dummy argument list. The first argument is assigned the number 1, the second the number 2, and so forth. dummy_encode(arg) = [index of arg in argv] 5.5. 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 (Location (HostName 'ten.ada.net') (Time '14:58:12 24 Feb 1998') ) (Initiator (ReferTo 'FauxJoe') ) (Source (FileName (ExtendedBy UnixFullFileName) '/etc/passwd') ) ) [The rest of this section must be redone.] 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. 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. (Login (Location (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') ) ) 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, (Login (Location (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 (Login (Initiator (IPV4Address '198.76.29.7') ) (Account (IPV4Address '10.33.32.15') ) ) (Login (Initiator (IPV4Address '10.41.10.2') ) (Account (IPV4Address '198.76.160.240') ) ) ) yeilds the following translated S-expression (Login (Location (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') ) ) 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 (Login (Location (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') ) ) (Login (Location (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') ) ) ) For the above S-expression, (Translate (Instance 2) (Login (Initiator (IPV4Address '198.76.29.7') ) (Account (IPV4Address '10.33.32.15') ) ) (Login (Initiator (IPV4Address '10.41.10.2') ) (Account (IPV4Address '198.76.160.240') ) ) ) yeilds the following translated S-expression (And (Login (Location (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') ) ) (Login (Location (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') ) ) ) 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') ) ) yeilds the following translated S-expression (Login (Location (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') ) ) 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 (Login (Initiator (UserName 'fred') (RealName 'Fred Flintstone') ) ) ) the result is the following S-expression (Login (Location (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') ) ) As a second example, consider the following S-expression. (ByMeansOf (GatherMessageStats (MessagePattern (IPV4Protocol 6) (SourceIPV4Address 135.52.160.1) (TCPSourcePort 32760) (DestinationIPV4Address 134.52.160.11) (TCPDestinationPort 23) ) (Statistics (MatchCount 10) (DistinctMatchCount 10) ) (Location (BeginTime Fri Jun 12 21:23:34 1998) (EndTime Fri Jun 12 21:24:04 1998) ) ) (Attack (Location (BeginTime Fri Jun 12 21:23:34 1998) (EndTime Fri Jun 12 21:24:04 1998) ) (AttackID 0000000200000002) (Certainty 100) (Severity 50) ) ) 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 (GatherMessageStats (MessagePattern (IPV4Protocol 6) (SourceIPV4Address 135.52.160.1) (TCPSourcePort 32760) (DestinationIPV4Address 134.52.160.11) (TCPDestinationPort 23) ) (Statistics (MatchCount 10) (DistinctMatchCount 10) ) (Location (BeginTime Fri Jun 12 21:23:34 1998) (EndTime Fri Jun 12 21:24:04 1998) ) ) (Attack (Location (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) ) ) 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 (Source (FileName 'file1') ) ) (Delete (Source (FileName 'file2') ) ) ) Applying the following embellishment (Embellish (And (Delete (Initiator (UserName 'joe') ) ) ) ) yields the following S-expression. (And (Delete (Initiator (UserName 'joe') ) (Source (FileName 'file1') ) ) (Delete (Initiator (UserName 'joe') ) (Source (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 (Source (FileName 'file1') ) ) (Delete (Source (FileName 'file2') ) ) ) Applying the following embellishment (Embellish (Instance 2) (And (Delete (Initiator (UserName 'joe') ) ) ) ) yields the following S-expression. (And (Delete (Source (FileName 'file1') ) ) (Delete (Initiator (UserName 'joe') ) (Source (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 (Location (StartTime '14:57:36 24 Feb 1998') (EndTime '15:57:36 24 Feb 1998') ) ... ) ) A response addendum could look like (Did (BlockMessage (Location (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 (Location (StartTime '14:57:36 24 Feb 1998') (EndTime '15:57:36 24 Feb 1998') ) ... ) ) (Did (BlockMessage (Location (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. Certain SIDs (e.g., ReferTo) are limited in scope to a single thread. For GIDO addendums, the thread ID shall be the same as the thread ID of the original GIDO. 6. Originator ID (16 octets). This is a UUID representing the identity and the instance of the component generating the GIDO or GIDO addendum. The exact format of this field is described in the architecture document (q.v.). 7. Flags (1 octet). The bits of this flags octet are to be interpreted according to the following table: Bit Meaning --- ------- 0 (LSB) set = optional signature present (see below). clear = no optional signature 1--7 (MSB) reserved (MSB = most significant bit) The GIDO payload, plain or compressed, immediately follows the header. If bit 0 in Flags is cleared, indicating no optional signature, the GIDO ends with the payload (indicated by the GIDO Length header field). Otherwise, if bit 0 is set, indicating that a digital signature of the content is present, this signature is contained in a structure following the GIDO payload. Recall that the GIDO Length header field indicates the end of the GIDO payload, not including the signature structure. The signature structure has the following fields in it: 1. Signature algorithm (2 octets). Indicates the specific algorithm used (e.g., RSA or DSS). Specific assignment of algorithm identifiers are specified in Appendix B. 2. Signature length (2 octets). Indicates the length, including this field (signature length), of the signature structure, in octets. 3. Signature algorithm specific length (2 octets). Indicates the length, including this field (signature algorithm specific length), of the signature algorithm specific parameters, in octets. 4. Algorithm-specific parameters. These parameters depend on the algorithm, and are only present if the signature algorithm parameter length is greater than 0. Algorithm parameter formats for specific algorithms are described in Appendix B. 5. Signature data. This field contains the result of applying the signature algorithm to the entire GIDO, including GIDO header, up to the start of the signature structure. For GIDO addendums, the signature covers the GIDO and GIDO addendums that the current GIDO addendum modifies. 7.3. Class ID Codes The first bit of the Class ID indicates whether the body is a GIDO or GIDO addendum. If the bit is clear, then the body is a GIDO. If the bit is set, then the body is a GIDO addendum and the remaining bits in the Class ID are identical to the preceding GIDO. The following default Class ID codes are defined for events and analysis results. Under this scheme, class ids 0 thru 15 are reserved for CIDF event priorities, and 16 thru 31 are reserved for analysis report priorities. In addition, class ids 32 thru 127 are reserved for future CIDF extensions. IDS developers may use the remaining range (128 thru 255) for application-specific purposes. The terms E-box, A-box, etc. are defined in the architecture document (q.v.). (Default Event Class IDs) 00 - Complete Event 01 - Intermediate Event 02 - Incomplete Event 03 - E-box Internal Error Report 04 - E-box Internal Warning Report 05 - E-box Internal Status Message 06 - Reserved for E 07 - Reserved for E : 15 - Reserved for (Default Analysis Class IDs) 16 - Critical Security Violation 17 - Potential Security Violation 18 - Suspicious Report 19 - Warning Report 20 - Intermediate Result 21 - Informational Report 22 - A-box Internal Error Report 23 - A-box Internal Warning Report 24 - Reserved for A 25 - Reserved for A : 31 - Reserved for A (Default Response Class IDs) 32 - Reserved for R-boxes 33 - Reserved for R-boxes : 47 - Reserved for R-boxes 48 - Reserved for future use 49 - Reserved for future use : 127 - Reserved for future use (Undefined Priority Codes) 128 - Undefined : : (Undefined values may be employed for : application-specific purposes.) 255 - Undefined Appendix A A.1. Data Types The following data types are used in this draft: octet: an unsigned 8-bit byte char: a 7-bit compliant (ASCII) byte short: a 16-bit value, big-endian, signed ushort: same as short, but unsigned long: a 32-bit value, big-endian, signed ulong: same as long, but unsigned float: a 32-bit floating point value, IEEE compliant double: a 64-bit floating point value, IEEE compliant Each of these data types may be arrayed. The length and encoding of these arrays are explained in Section 5 of the draft. A.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 a verb, a role, an adverb, a metarole, or any of the atom types listed in Section A.1. * 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 metarole 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. Some of the SIDs here are listed without any notes; this means that any legal clause headed by such SIDs are valid underneath the entry SID. (The rows of asterisks serve only as separators and have no semantic import.) A.2.1. 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. Location: This contains the time at which the copy was completed. It may also contain the host on which the copy was conducted, for same-host copies (even if the files were accessed via NFS). For multi-host copies (e.g., via rcp), the hosts should be identified in the FileSource and FileDestination role clauses. 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. For multi-host copies, the host of the source files should be given here. When copying multiple files (which may be from different directories), use multiple FileSource roles. (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.) If this is a multi-host copy, the host of the destination should be specified here. (Object SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: This contains the time at which the move was completed, and also the host on which the move was conducted. 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. (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.) (Object SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: Delete Code: 08000013 Type: verb Description: A file, or set of files, is deleted. May Contain: Outcome: The exit status of the delete. Location: This contains the time at which the delete was completed, and also the host on which the delete was conducted. 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: This contains the time at which the program was initiated, and also the host on which it ran. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity executing the program. (Subject SID. 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: This contains the time at which the program was suspended, and also the host on which it was running when it 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: This contains the time at which the program was resuming, and also the host on which it ran. 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: This contains the time at which the program was terminated, and also the host on which it was running when it 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. May Contain: Outcome: The exit status of the login attempt. Location: 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 of the login attempt should be put here. (Subject SID. Not pluralizable.) Account: Information about the user account being logged into. (Object SID. Not pluralizable.) Session: Information about the session. ProcessID should be used to identify the login session process. (Object SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. May Contain: Outcome: The exit status of the FTP open attempt. Location: This contains the time of the FTP open attempt, and also the host *serving* the FTP session. 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. (Object SID. Not pluralizable.) Session: Information about the session. ProcessID should be used to identify the ftpd session process. (Object SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: CloseSession Code: 08000023 Type: verb Description: A user closes a session. This may be any of the sessions opened via either Login or OpenFTP. 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. Location: This contains the time at which the session was closed, and the name of the host serving the session. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity operating the session (the client). (Subject SID. Not pluralizable.) Session: The session being closed. ProcessID should be used to identify the server session that was closed. (Subject SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: This contains the time at which the proxy was obtained (or the attempt was made), and the name of the host granting the proxy. 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. 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: LoseProxy Code: 08000032 Type: verb Description: A user loses 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. Location: 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. 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: SendMessage Code: 08000041 Type: verb Description: A message is transmitted from one location to another. This is intended for the transport layer and below. An application-level description (such as for mail) should use the appropriate application-specific SID. May Contain: Outcome: ReturnCode or CIDFReturnCode, if present, represent the success or failure of the attempt to send a message. The actual return code should not be placed here. Instead, the encoder should use ByMeansOf to indicate the command by which the message would be sent, and use ActualReturnCode there. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity sending the message. (Subject SID. Not pluralizable.) Receiver: The entity receiving the message. (Object SID. Not pluralizable.) Session: The channel on which the message is being sent. The encoder may use the NetworkProtocol and TransportProtocol SIDs to identify the type of channel. Message: The message being sent. The actual content of the message is indicated using Content. ***** ReferAs ReferTo Instance World Multiplier Name: ObserveMessage Code: 08000042 Type: verb Description: An entity observes a message on the network. May Contain: Location: This contains the time at which the message was observed, as well as the machine (host or router) from which the observation was made, if all observations were made from the same machine. Observer: The entity observing the message. (Subject SID. Pluralizable.) Message: The message being observed. The actual content of the message can be indicated using Content. Otherwise, other attributes of the message may be placed here, such as NetworkProtocol and TransportProtocol, or the various message header SIDs. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: MessageStatistics Code: 08000043 Type: verb Description: An entity gathers statistics on messages observed on the network May Contain: Location: 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), as well as the machine (host or router) from which the observation was made, if all observations were made from the same machine. Observer: The entity gathering the statistics. (Subject SID. Pluralizable.) MessagePattern: The patterns that the messages are supposed to match. (Object SID. Not pluralizable.) Statistics: The statistics based on observation. (Object SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: 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. (Object SID. Pluralizable.) Message: Information about the e-mail message. The actual contents of the mail can be indicated using Content. A mail message can also be referred to with HostName and MailMessageID. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: ObserveState Code: 08000061 Type: verb Description: This gives the current state of the system. May Contain: Location: This contains the time for which "current state" has meaning. It also delineates the "system." If the system refers to a single host, that host is indicated here; if it refers to a LAN, then a network may be indicated here; and so forth. Observer: The entity observing the system. (Subject SID. Pluralizable.) CurrentState: The current state of the system. Any attributes of the system may be given here. (Object SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: ChangeState Code: 08000062 Type: verb Description: This reports a state change in the system. May Contain: Location: This contains the time at which the CurrentState is observed. It also delineates the "system" as outlined in ObserveState. Observer: The entity observing the system. (Subject SID. 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. (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. (Object SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: AuditAccount Code: 08000071 Type: verb Description: A user account is audited. May Contain: Location: This contains the time at which (or during which) the auditing was performed, as well as the host on which the account in question resides. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity performing the audit. (Subject SID. Pluralizable.) Account: The account being audited. (Object SID. Pluralizable.) Tool: The mechanism used to perform the auditing. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: AuditMessage Code: 08000072 Type: verb Description: Auditing is performed on specified messages. May Contain: Location: This contains the time at which (or during which) the auditing was performed, as well as the host on which the account in question resides. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity performing the audit. (Subject SID. Pluralizable.) Message: The message(s) being audited. (Object SID. Pluralizable.) Tool: The mechanism used to perform the auditing. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: BlockMessage Code: 08000073 Type: verb Description: Specified messages are blocked. May Contain: Location: This contains the time at which (or during which) the auditing was performed, as well as the machine on which the messages were blocked. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity blocking the messages. (Subject SID. Pluralizable.) Message: The message(s) being blocked. (Object SID. Pluralizable.) Tool: The mechanism used to block the messages. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: TraceMessage Code: 08000074 Type: verb Description: Specified messages are traced (to their source). May Contain: Location: This contains the time at which (or during which) the auditing was performed, as well as the machine from which the messages were traced. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity tracing the messages. (Subject SID. Pluralizable.) Message: The message(s) being traced. (Object SID. Pluralizable.) Tool: The mechanism used to trace the messages. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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. Location: This contains the time at which (or during which) the attack took place. If the entire attack took place on one machine, that too should be indicated here. Observer: The entity making the attack diagnosis. (Subject SID. 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). 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. (Object SID. Pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: Reboot Code: 08000091 Type: verb Description: A machine is rebooted, either deliberately or accidentally, either legitimately or illegitimately. May Contain: Outcome: This indicates the success or failure of the reboot. Location: This contains the host that was rebooted, as well as the time at which it was rebooted. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity responsible for performing the reboot. (Subject SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: Shutdown Code: 08000092 Type: verb Description: A machine is powered down, either deliberately or accidentally, either legitimately or illegitimately. May Contain: Outcome: This indicates the success or failure of the shutdown. Location: This contains the host that was shutdown, as well as the time at which it was shutdown. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity responsible for performing the shutdown. (Subject SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier Name: Boot Code: 08000093 Type: verb Description: A machine is powered up. May Contain: Outcome: This indicates the success or failure of the bootup. Location: This contains the host that was booted up, as well as the time at which it was booted up. Observer: The entity which observed and/or recorded this occurrence. Initiator: The entity responsible for performing the bootup. (Subject SID. Not pluralizable.) ***** ReferAs ReferTo Instance World Multiplier 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: Location: 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. (Object SID. Not pluralizable.) ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate SendMessage SendMail ObserveState AuditAccount AuditMessage BlockMessage TraceMessage Reboot Shutdown Boot ***** ReferAs ReferTo Instance World Multiplier 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: Location: 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. (Object SID. Not pluralizable.) ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate SendMessage SendMail ObserveState AuditAccount AuditMessage BlockMessage TraceMessage Reboot Shutdown Boot ***** ReferAs ReferTo Instance World Multiplier 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: Location: 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. (Object SID. Not pluralizable.) ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate SendMessage SendMail ObserveState AuditAccount AuditMessage BlockMessage TraceMessage Reboot Shutdown Boot ***** ReferAs ReferTo Instance World Multiplier 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: Location: 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. (Object SID. Not pluralizable.) ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate SendMessage SendMail ObserveState AuditAccount AuditMessage BlockMessage TraceMessage Reboot Shutdown Boot ***** ReferAs ReferTo Instance World Multiplier 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. (Object SID. Pluralizable.) ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate SendMessage SendMail ObserveState AuditAccount AuditMessage BlockMessage TraceMessage Reboot Shutdown Boot ***** ReferAs ReferTo Instance World Multiplier 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 Location role directly within Predict. May Contain: Observer: The entity making the prediction. (Subject SID. Pluralizable.) ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate Login OpenFTP CloseSession AcquireProxy LoseProxy SendMessage ObserveMessage MessageStatistics SendMail ObserveState ChangeState AuditAccount AuditMessage BlockMessage TraceMessage Attack Reboot Shutdown Boot Request Require Allow Forbid Predict Translate TranslateSID Embellish Did ***** ReferAs ReferTo Instance World Multiplier 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. ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate Login OpenFTP CloseSession AcquireProxy LoseProxy SendMessage ObserveMessage MessageStatistics SendMail ObserveState ChangeState AuditAccount AuditMessage BlockMessage TraceMessage Attack Reboot Shutdown Boot Request Require Allow Forbid Predict Translate TranslateSID Embellish Did ***** ReferAs ReferTo Instance World Multiplier 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. ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate Login OpenFTP CloseSession AcquireProxy LoseProxy SendMessage ObserveMessage MessageStatistics SendMail ObserveState ChangeState AuditAccount AuditMessage BlockMessage TraceMessage Attack Reboot Shutdown Boot Request Require Allow Forbid Predict Translate TranslateSID Embellish Did ***** ReferAs ReferTo Instance World Multiplier 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. ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate Login OpenFTP CloseSession AcquireProxy LoseProxy SendMessage ObserveMessage MessageStatistics SendMail ObserveState ChangeState AuditAccount AuditMessage BlockMessage TraceMessage Attack Reboot Shutdown Boot Request Require Allow Forbid Predict Translate TranslateSID Embellish Did ***** ReferAs ReferTo Instance World Multiplier 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: ***** And HelpedCause ByMeansOf ***** Copy Move Delete Execute Suspend Resume Terminate SendMessage SendMail ObserveState AuditAccount AuditMessage BlockMessage TraceMessage Reboot Shutdown Boot ***** ReferAs ReferTo Instance World Multiplier A.2.2. Role SIDs Name: Initiator Code: 08001001 Type: role Description: The process responsible for "doing" the containing verb. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Receiver Code: 08001002 Type: role Description: The process receiving a message, being subjected to a policy. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Observer Code: 08001003 Type: role Description: The process observing an action or a system state, or analyzing a sequence of events. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Target Code: 08001004 Type: role Description: The target of an attack, as described in the Attack verb. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Process Code: 08001011 Type: role Description: A process executing on a single host. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Session Code: 08001012 Type: role Description: A session (i.e., a communication) occurring (in general) between two hosts. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Tool Code: 08001013 Type: role Description: A mechanism used to perform an action. May Contain: ***** Owner Certifier Parent Developer ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: AttackSpecifics Code: 08001014 Type: role Description: High-level information about an attack. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** ProcessID ProcessName ProgramName VersionNumber ProcessStatus Priority RevPriority SystemTime UserTime CPUTime ContentType ContentEncoding Content ProgramText CodeSequence ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** AttackNickname AttackID ***** ReferAs ReferTo Instance World Multiplier 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: ***** Owner Certifier Parent Developer ***** ByteSize FileName FullFileName TimeCreated TimeModified TimeAccessed DirectoryName FullDirectoryName MACObjectLabel ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier 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: ***** Owner Certifier Parent Developer ***** ByteSize FileName FullFileName TimeCreated TimeModified TimeAccessed DirectoryName FullDirectoryName MACObjectLabel ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Account Code: 08001031 Type: role Description: A user account. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Proxy Code: 08001032 Type: role Description: A principal on behalf of whom an entity acts. May Contain: ***** Owner Certifier Parent Developer ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: OldState Code: 08001041 Type: role Description: A previous state of the system. May Contain: ***** Owner Certifier Parent Developer ***** ***** ReferAs ReferTo Instance World Multiplier Name: CurrentState Code: 08001042 Type: role Description: A current state of the system (current defined with respect to the time given in the Location). May Contain: ***** Owner Certifier Parent Developer ***** ***** ReferAs ReferTo Instance World Multiplier Name: Message Code: 08001051 Type: role Description: Information about a specific message referred to as part of a sentence. May Contain: ***** Owner Certifier Parent Developer ***** ObservationSourceType DataLinkProtocol NetworkProtocol TransportProtocol ***** EtherAddress EtherPreamble EtherType EtherFrameCheckSeq IPV4Address IPV4Mask SourceIPV4Address DestinationIPV4Address SourceIPV4Mask DestinationIPV4Mask IPV4Port IPV4PortRange IPV4VerIHL IPV4ServiceType IPV4TotalLength IPV4Identifier IPV4Flags IPV4FragOffset IPV4TTL IPV4Protocol IPV4Checksum ICMPType ICMPCode TCPPort TCPSourcePort TCPDestinationPort TCPPortRange TCPSourcePortRange TCPDestinationPortRange TCPSequenceNumber TCPAckNumber TCPWindow TCPChecksum TCPUrgentPointer TCPMSS TCPFlags TCPFlagsMask UDPPort UDPSourcePort UDPDestinationPort UDPPortRange UDPSourcePortRange UDPDestinationPortRange UDPLength UDPChecksum ***** ***** ReferAs ReferTo Instance World Multiplier 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). May Contain: ***** Owner Certifier Parent Developer ***** ObservationSourceType DataLinkProtocol NetworkProtocol TransportProtocol ***** EtherAddress EtherPreamble EtherType EtherFrameCheckSeq IPV4Address IPV4Mask SourceIPV4Address DestinationIPV4Address SourceIPV4Mask DestinationIPV4Mask IPV4Port IPV4PortRange IPV4VerIHL IPV4ServiceType IPV4TotalLength IPV4Identifier IPV4Flags IPV4FragOffset IPV4TTL IPV4Protocol IPV4Checksum ICMPType ICMPCode TCPPort TCPSourcePort TCPDestinationPort TCPPortRange TCPSourcePortRange TCPDestinationPortRange TCPSequenceNumber TCPAckNumber TCPWindow TCPChecksum TCPUrgentPointer TCPMSS TCPFlags TCPFlagsMask UDPPort UDPSourcePort UDPDestinationPort UDPPortRange UDPSourcePortRange UDPDestinationPortRange UDPLength UDPChecksum ***** ***** ReferAs ReferTo Instance World Multiplier Name: Statistics Code: 08001053 Type: role Description: A collection of statistics gathered as part of a sampling sentence, such as MessageStatistics. May Contain: ***** Owner Certifier Parent Developer ***** TotalCount MatchCount DistinctMatchCount ***** ReferAs ReferTo Instance World Multiplier A.2.3. 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: ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Certifier Code: 08001802 Type: attribute Description: An entity which vouches for the identity of the object. May Contain: ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Parent Code: 08001803 Type: attribute Description: An entity which created the object. May Contain: ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier Name: Developer Code: 08001804 Type: attribute Description: An entity which developed the object (typically a program). May Contain: ***** UserName RealName PrincipalName UserID CurrentUserName CurrentUserID EffectiveUserName EffectiveUserID GroupName GroupID GroupUUID MACLabel MACEffectiveLabel MACClearances EMailAddress AFSProtectionGroupName TerminalName ***** HostName FQHostName DomainName FQDomainName DomainID DomainUUID KerberosKDCName AFSServerName TerminalName ***** ReferAs ReferTo Instance World Multiplier A.2.4. Atom 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*. 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: 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. 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: Comment Code: 0400000b Type: string Description: A comment in text. 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: 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