Honeywell Network Entity-Relationship Database

Honeywell
Network Entity-Relationship
Database

28 July, 2000

Revision 1.6

Contact: Robert P. Goldman, mailto:goldman@htc.honeywell.com

Developed at Honeywell Technology Center, 3660 Technology Drive, Minneapolis, MN 55418

Development funded by DARPA contract F30602-99-C-0177, the ARGUS project of the Strategic Information Assessment program

Note: The current version of this document is Microsoft Word 97. I hope to replace this with HTML for more portability and better revision control. It is currently best viewed in the "Online Layout" view of Word, which allows you to expand/collapse headings.

Acknowledgments: This document was partially inspired by an Intrusion Reference Model developed at HTC and partly by information about the UCSB STAT tools' configuration database. We thank Giovanni Vigna for providing this information and assistance helping us to understand it.

Overview
Purpose of this Model

The Network Entity Relationship Database (NERD) is intended to provide a common model of a network and contained hosts suitable for configuration and interoperability of intrusion detection systems and related security software. The NERD is part of a larger Intrusion Reference Model (IRM), which contains additional information about security goals and attack plans. This document represents a preliminary (and incomplete) draft of the schema, intended for comment.

CLASSIC Modeling Language

The NERD is defined in an AT&T-developed information modeling language called CLASSIC. This language allows you to describe objects not only in terms of their relations to other known objects, but also at the level of intensional structure. It can answer queries either as extensional lists of values, or as descriptions that necessarily hold in all possible answers. The extensible CLASSIC schema is accessible like any other data in CLASSIC. The same language can be used for describing the schema, querying the database, or expressing answers. There are implementations in LISP, C, and C++. Licenses (at no charge) for research purposes are available from AT&T.

Further CLASSIC information may be found at http://www.bell-labs.com/project/classic/

For more in-depth information, we recommend http://www.research.att.com/sw/tools/classic/papers/finalsigmod.ps

Inheritance Hierarchy

The following two diagrams give an overall view of the inheritance (ISA, or AKO) hierarchy of the NERD schema that we are proposing as a shared resource for the SIA program, for sharing network descriptions and configuring systems. Some details were omitted for clarity.

Concept Hierarchy

Concepts (classes) are on lines prefixed with a - (e.g., IP Address immediately below).

Grouped under the concepts are its roles (slots, fields). With the roles we supply information about the type of the filler(s) (e.g., the octet1 field of an IP Address must be an integer between 0 and 255), and any cardinality restrictions on the role (e.g., there must be exactly 1 filler of the octet1 role of the IP Address concept; an IP setup object may have 0 any number of fillers for its Nameserver role).

IP Address

OCTET 1: INTEGER 0..255[1]

OCTET 2: INTEGER 0..255[1]

OCTET 3: INTEGER 0..255[1]

OCTET 4: INTEGER 0..255[1]

Comments:

Possibly this should be changed to a HOST object, to permit equality testing.

Ethernet Address

OCTET 1: INTEGER 0..255[1]

OCTET 2: INTEGER 0..255[1]

OCTET 3: INTEGER 0..255[1]

OCTET 4: INTEGER 0..255[1]

OCTET 5: INTEGER 0..255[1]

OCTET 6: INTEGER 0..255[1]

Comments: Possibly this should be changed to a HOST object, to permit equality testing (cf. IP address).

IP Setup

Giovanni Vigna writes: "An ipsetup object is a set of configuration parameters that specifies an endpoint for datagram delivery in an IP network." Ours is a slight expansion of his object.

Has-IP-Address: IP Address[1]

Netmask: IP Address[1]

Gateway: IP Address[1-¥ ]

Nameserver: IP Address[0-¥ ]

Who is it that you get name service from through this interface?

Network Protocol

ENUM: IP, AppleTalk, Novell

IP Transport protocol

ENUM: TCP, UDP, ICMP

Authentication Protocol

ENUM: Password, PublicKey, IP address, LANMAN, PAP, CHAP

Router Protocol

ENUM: BGP, OPSF

Interface

An interface corresponds to a physical interface to a Data Link. Therefore, there can be multiple setups for a single interface. Giovanni Vigna writes about his concept: "An interface is an endpoint for network communication. A network interface is always inside a node and attached to a network." Actually, an interface is connected to a Data Link (qv.)

Has-IP-Setup: IP Setup[0-1]

Runs: Network Protocol[1-¥ ]

Ethernet-Interface

Link Address: Ethernet Address[1]

Comments: This can automatically be recognized by adding the definition that an Ethernet Interface is an interface with a Link Address that is an Ethernet Address.

IP Ethernet Interface

Constraints: This is an Ethernet-Interface that has an IP Setup in its Has-IP-setup slot, or that has its RUNS slot bound to IP. An IP Ethernet Interface must have an IP setup object. This class will be recognized automatically. One can just create an Ethernet interface object and it will be automatically recognized.

Link-Medium

ENUM: Thin-Cable, Thick-Cable, Twisted-Pair, Token-ring cable, Wireless, Telephony, Fiber

Ethernet-Switch-Type

ENUM: Hub, Switch

Link [synonym: DataLink]

Connects: Interface [0..¥]

Ethernet-Link

Has- Medium: Ethernet-Medium[1]

Link-Speed: INTEGER[1] Megabits per second.

Cable Ethernet

Constraints: Has-Medium must be Thin-Cable or Thick-Cable

Twisted-pair Ethernet

Constraints: Has Medium must be Twisted-Pair How-Switched: Ethernet-Switch-Type[1]

Sniffable-Ethernet

Constraints: A link is sniffable if it is a Cable Ethernet or it is a Twisted-Pair Ethernet whose how-switched is filled with Hub This class will be automatically classified by CLASSIC. It will not be necessary for you to indicate that a link is a sniffable-ethernet link.

Port

Port number: INTEGER 1..65535 [1]

Protocol: IP-Protocol[1]

We need to represent ports as these tuples of port number and protocol because a single port number can be used differently for TCP and UDP.

Well-known-port

Constraint: Port number is less than or equal to 1024.

Comments: This class will automatically be recognized. There is no need to explicitly state that a port is a well-known-port. The CLASSIC database should infer this itself.

Software version

Comments: This concept is intended to provide ways for us to canonically represent software revisions across multiple applications, without worrying whether one refers to Windows NT SP4 as having a patchlevel of 4, or as having a patchlevel of "SP4", etc. For easier equality testing, we might want to make this a HOST object.

Major: Integer[1]

Minor: Integer[1]

Patchlevel: INTEGER[1] [synonyms: service-pack, service-release]

File

URI: String [1-¥] Universal Resource Identifier

Simple-File

Directory

Device-File

This is a file that is really a device mapped into the file system of some host.

Service

Relies-upon: File [0-¥]

– intended to capture configuration and content dependencies. For example, the Berkeley remote login services (qv.) rely on the ".rhosts" file(s) for authentication.

Comments: The notion of service is intended to capture things that network services (defined as services that listen to ports) and local services (applications and daemons) have in common.

Comments: Note that we don't expect that these can be thoroughly modeled, but we can enumerate some key services with important vulnerabilities.

Network Service

A network service is something that listens at a port or ports and responds to requests.

It is definitional of a network service that it listens to a port. Other properties are not necessary to recognition.

Listens-to-port: Port[1-¥ ]

Sends-on-port: Port[0-¥ ]

Talks-to-port: Port[0-¥ ]

Certain services will only accept connections from specific source ports.

Has-transport-protocol: Transport Protocol[1]

Has-authentication-protocol: Authentication Protocol [0.¥]

Traffic-Encrypted: boolean[1]

WWW [Synonym: HTTP]

SSH

NFS

DNS

FTP

CIFS [Synonym: Samba]

X-Window

Berkeley-Remote-Login

Covers rsh, rlogin, rcp

Local Service

Comments: Note that these include both common applications and local daemons (those that don't listen on ports).

ps

fetchmail

cron

Operating System

Comments: This is a particular installation of an OS. Note that we will have to add features for patchlevel/service packs and revision numbers. These will have to be managed to be in canonical form for interoperability.

We should be able to add constraining rules that will automagically fill in the manufacturer for the proprietary operating systems.

Runs: Service [0-¥ ]

Manufacturer: String[1]

Revision: Software-version[1]

Accounts: Account [1-¥]

Root-Account: Account [1]

UNIX

LINUX

Kernel version: Software-revision[1]

Comments: The customary version number for LINUX may not be that helpful, since it varies across the distributions. At any rate, it's not all that's needed; we should also have the kernel revision number.

CiscoOS [synonym: IOS]

Solaris

Comments: This terminology is actually misleading; I believe that the official Sun line is that Solaris is the overall package, and the operating system is still SunOS. I'm also pretty sure that the two products have different version numbering. Solaris should probably be avoided.

Windows

NT

Windows 2000

Windows NT

Legacy

Windows 95

Windows 98

Processor-Architecture

ENUM: Sparc, Intel [x86], Alpha, PA-RISC

Comments: ‘Intel’ will be replaced by x86, to take into account possible later divergent architectures developed by Intel and to recognize the fact that non-intel manufacturers make processors in this family. We could easily add other options, such as PPC, Itanium, SH3, etc.

Host-Subtype

ENUM: Server, Production

Comments: This was added only to serve UCSB needs. I’m not sure of its semantics: should probably be put in the UCSB: namespace for better clarity.

Account

Host Account

Comments: The host account is a concept created to separate user accounts tied to a particular host from those that are shared via things like NT domains and NIS.

Username: STRING[1]

Host-of: Host [1]

Operating-system-of : operating system[1]

The operating system is necessary to uniquely identify a particular account, since multiple-boot accounts may have different accounts for the same userid on different OSes.

Owned-by: Person [1-¥]

E.g. root accounts are typically owned by a group. This is possibly a bad model because accounts may not be owned by a person in the sense of a user (as approved to a person with administration responsibility), e.g., mail accounts, daemon ‘users.’

Unix Account

Constraints: The operating-system of the account is a flavor of UNIX.

uid: INTEGER[1]

Group

has-account : Account[0-¥ ]

Host Group

Comments: See Host Account concept

Host-of: Host [1]

Operating-system-of : operating system[1]

Unix Group

Constraints: The operating-system of the account is a flavor of UNIX.

Gid: INTEGER[1]

Person

Comments: A stub. Haven’t put any info here; not sure this is necessary to model. But having a placeholder that’s unused is pretty benign in CLASSIC.

Location

Node

Runs: Service[0-¥ ]

Comments: This is an attribute that needs to be rectified with the UCSB model that it's operating systems (qv.) that run services. That is a more accurate model in the real world of multiple – OS machines. For now, if single-boot simplifying assumption is acceptable, we can just use rules to fill this slot from the operating-system of a Node. Actually, this is a sensible rule, even with multiple-boot systems – This is just a possibly different-then-expected semantics for RUNS, which means something like "potentially is running," not that the host is currently running the service.

Manufacturer: String [1]

HOST

Parent-Network: Network [1]

Note that this might be better changed to permit multiple parent networks.

RUNS-OS: Operating-system [1-¥]

UCSB::Subtype: Host-Subtype [0-1]

This was added to avoid information loss in absorbing a UCSB configuration database.

Model-Name: String [1] – Could change to permit >1 for non-standard namings.

Processor-Speed: INTEGER [1]

Processor speed in MHz.

Memory: INTEGER [1]

Memory in Mb.

Storage: INTEGER [1]

Storage in Mb, i.e., disk space. Possibly this should be refined to track disks. Not sure there’s a need.

Workstation

X terminal

Printer

Hub

Switch

Router

Bridges: Network [2-¥ ]

has-protocol: router protocol[1]

Network

Network-node: Node[0-¥ ]

Subnetwork: Network[0-¥ ]

Network-member: Classic-thing [1-¥]

Network-members can be either networks, or nodes. The set of network-members is the union of the network-node and subnetwork sets.

Has-links: Link [1-¥]

Bridged by: router[0-¥ ]

Domain

This concept is currently just a placeholder. We do not have a rich model of a domain right now.