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 two 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 leader who then sends commands to them and they may send reports back

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 mix of FSA (finite state automata) and protocol diagrams, 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 two 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. These sets are disjoint.)

Note: I haven't said if these objects are nodes, resources or what. I should have a way of saying this.

• 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

Also note that I haven't said if each infected hosts scans ALL or SOME vulnerable hosts and how many. We should have a mechanism to specify this. Same comment goes for any "acts upon" relationship.

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

P2P w leader and C&C traffic metadescription

• Logical topology:

(in English: There must be two sets of hosts, at least two eligible peers and at least one leader. Nothing is said about relationship between sets so it's possible that there's an intersection between those that is non-empty.)

• Timeline of events:

(in English: Each eligible peer contacts some other eligible peers asking them to peer with it. If they agree both go into "peer" state, otherwise they both revert to eligible peer state. In each of peer states (elpeer, maypeer, peer) this object may somehow learn about a leader and go into lpeer state in which it knows leader identity. In lpeer state it may learn about other leaders as well. An object in lpeer state receives some commands from the leader and may report back to the leader.).

Note that I haven't defined what wannapeer, yespeer, leaderis, cmd and report events are and I should define it in the common domain knowledge base.

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

Experiment design

Now I'm a user who wants to design my experiment. I need to combine two metadescriptions and somehow tie them down to generator choices. To combine I need to specify how outputs of worm metadescription match inputs of P2P metadescription. This is simple and I'll just do something like:

i.e. each infected host becomes elpeer.

The system now needs to offer me several generators:

• It should offer a topology generator and map the initial infected set, vulnerable set and leader set to the topology that gets generated.
• It should offer event generator for each of the events: scan, infection, yespeer, wannapeer, leaderis, cmd and report. Specifically for scan, yespeer, wannapeer, cmd and report it should offer traffic generators. For infection it should offer malware generator. For leaderis it could either offer a traffic generator or an option to hardcode the leader ID into the peer software.

User either chooses each generator or agrees to use a default one for each choice. User can then manipulate the generators (their parameters) and the workflow. For example the user may add "patched" state after the "infected" one with the "patch" event to make the transition.