This page talks about language used to design experiments. It should both be used to design metadescriptions and perhaps to make them more specific to a particular experiment the user wants to run.

Examples

I'll start with a few examples of experiments first, that we should be able to design in this language.

1. A botnet experiment where a worm infects some vulnerable hosts, they organize into a P2P botnet with some botmaster and start exchanging C&C traffic. Experimenter wants to observe the evolution of the botnet and the amount of traffic that master receives. There are three classes of experiments here that need to be combined together:
   1. an experiment where worm spreads and infects vulnerable hosts
   2. an experiment where some hosts organize into P2P network and somehow elect a botmaster
   3. an experiment where peers start exchanging some C&C botnet traffic

2. A cache poisoning experiment where the attacker poisons a DNS cache to take over authority for a given domain. The attacker then creates a phishing page and tries to steal user's usernames/passwords. There are two classes of experiments that need to be combined:
   1. an experiment where a DNS cache is poisoned, subclass of cache poisoning experiments
   2. an experiment where a phishing attack is conducted via a Web page to steal usernames/passwords

3. An ARP spoofing experiment where the attacker puts himself in between two nodes and then modifies their traffic. There are two classes of experiments that need to be combined:
   1. an experiment where ARP poisoning happens between two nodes by the attacker
   2. an experiment where an attacker changes traffic passing through it

Requirements

We may end up with a single language or a set of related languages. Here is what we need to express:

1. Logical topologies - both at the level of individual nodes or groups of nodes. We are expressing a logical topology of the experiment where there are objects that do something in the experiment - generate traffic, change state, hold data, whatever. Whether these objects are individually generated or generated as a group of entities, whether they are physical nodes or virtual, etc. does not matter. The expressiveness should be such that the actual implementation of objects and the cardinality of each object is orthogonal to the topology description. We should however be able to give hints such as "these objects are in the same network or on same physical node or object A resides on object B". These hints are called constraints.
2. Timeline of events - we need to express the ordering of actions that some objects will take in the experiment, their duration, repetition and concurrency. We also need to express state transitions in objects. In some domains this is called a workflow. It could be pre-created in the experiment design stage or it could be generated manually during the experiment (mined from events that happen as user takes manual actions) or a mix of those. Each experiment class must have some default workflow that user can manipulate during experiment design.
3. Invariants - we need to express what MUST happen in the experiment for it to be valid. Valid here means "for it to belong to a class of experiments whose metadescription we used" plus any other conditions that user wants to impose. There are two types of invariants:
   1. those that deal with objects and their states ("cache must be poisoned")
   2. those that deal with events and their features ("traffic must flow from A to B for 5 minutes at 100Mbps")

Note that intentionally this is all pretty high-level and is orthogonal to any generator used to generate topologies, traffic, etc. There must be a mapping process that selects eligible generators for each dimension and takes their output and maps objects and events to it. More about this mapping process later.

Diving in

I'll now ignore the question which language to use to design experiments because I think that pretty much any language can be used once we know what we want to say. To figure this out I'll try to use a variant of FSA (finite state automata) and Arun's adaptation of TLA (temporal logic algebra) to describe example experiments from above. If the level of detail is right we can decide on appropriate language in the next step.

Example 1: botnet

This example used 3 metadescriptions. Let's go through each of them:

Worm spread metadescription

Dimensions:

• Logical topology: (in English: There must be two sets of hosts, at least one infected host in infected set and at least one vulnerable host in vulnerable set. There can be a third set of hosts that are not vulnerable or infected.)
• Timeline of events: (in English: Each infected host generates scan events that target a vulnerable host - double line means one object acts upon another. There is at least one such event for a vulnerable host and at least one pair of scan+vulnerable host in the experiment. Once an infection event occurs on vulnerable host it transitions to an infected state. An infected host may scan other, non-vulnerable hosts). Note that I haven't yet defined what scan and infection events mean. I have to do this somewhere but I think the right place for this would be a common repository of domain knowledge rather than attaching these per experiment class since many classes of experiments may need same definitions. Ultimately what I'd like to say in these definitions in plain English is:
  • scan event generates traffic from A to B that exploits a vulnerability at B
  • infection event at B executes some code that places a copy of malware at B with ability to auto-start

• Invariants: There are some in definition of topology and timeline above. No additional ones are needed here.

P2P w leader metadescription

• Logical topology:

(in English: There must be two sets of hosts, at least one infected host in infected set and at least one vulnerable host in vulnerable set. There can be a third set of hosts that are not vulnerable or infected.)

• Timeline of events: (in English: Each infected host generates scan events that target a vulnerable host - double line means one object acts upon another. There is at least one such event for a vulnerable host and at least one pair of scan+vulnerable host in the experiment. Once an infection event occurs on vulnerable host it transitions to an infected state. An infected host may scan other, non-vulnerable hosts). Note that I haven't yet defined what scan and infection events mean. I have to do this somewhere but I think the right place for this would be a common repository of domain knowledge rather than attaching these per experiment class since many classes of experiments may need same definitions. Ultimately what I'd like to say in these definitions in plain English is:
  • scan event generates traffic from A to B that exploits a vulnerability at B
  • infection event at B executes some code that places a copy of malware at B with ability to auto-start

• Invariants: There are some in definition of topology and timeline above. No additional ones are needed here.