| | 41 | The entire system has a domain knowledge database that contains domain-specific information, such as: |
| | 42 | * Context: |
| | 43 | * what is an IP address |
| | 44 | * what is an IP flow |
| | 45 | * what is an IP packet pair |
| | 46 | * what is a TCP connection (consists of three packets with following features ..) |
| | 47 | * what is a DNS request/reply, what makes a reply match the request |
| | 48 | * what is an HTTP request/reply, what makes a reply match the request |
| | 49 | * what is the syntax of a DNS record |
| | 50 | * Parameterization: |
| | 51 | * for each type of object and each type of event in any metadescription what kind of parameters can be defined. E.g., for HTTP request this would be timing of requests and content of requests (type=GET/PUT/POST, filename). Note that this is divorced from the actual generator of such event, parameters are strictly related to events, regardless of how they are generated. |
| | 52 | * Relationships: |
| | 53 | * One type of traffic induces another: HTTP traffic leads to DNS traffic leads to ARP traffic |
| | 54 | * Nodes have IP and ARP addresses per each interface |
| | 55 | * Web files may contain forms that require user input |
| | 56 | * HTTP replies depend on Web files stored at a server-specific location |
| | 57 | * DNS records reside in caches and have info about name=address mappings, and info about authorities for domains |
| | 58 | |
| | 59 | The context part would be mostly populated by us. The parameterization and relationship parts would be seeded by us but then extended by other experts that create meta-descriptions. There is an automated way of identifying unknowns from a meta-description that must be defined in the knowledge DB. |
| | 60 | |
| | 63 | Our system keeps the following info about each generator: |
| | 64 | * Name |
| | 65 | * Contact of the author or N/A for non-supported generators |
| | 66 | * URL of the manual for the generator |
| | 67 | * What is the type of its output (e.g. Topology) - the types mentioned here are from the same enum list as object types in the logical topology |
| | 68 | * What parameters users can customize - these come from the same list as parameters in the parameterization part of the knowledge DB. A generator may have some parameters specific to itself, we don't care about those in this item. We care about parameters that describe a certain event/object and which of them we can manipulate if we choose this generator. |
| | 69 | * How the parameters can be customized, e.g., randomized, input by user, selected from a list ... |
| | 70 | * Other inputs of the generator, their range of values and their relationship to the parameters from the above two items |
| | 71 | |
