| 35 | | == Example 1: Botnet == |
| 36 | | |
| 37 | | This example used two metadescriptions. Let's go through each of them: |
| 38 | | |
| 39 | | === Worm spread metadescription === |
| 40 | | |
| 41 | | Dimensions: |
| 42 | | * '''Logical topology:''' |
| 43 | | |
| 44 | | [[Image(wormobj.jpg)]] |
| 45 | | |
| 46 | | (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. These sets are disjoint. All objects here are of type Nodes.) |
| 47 | | |
| 48 | | * '''Timeline of events: ''' |
| 49 | | |
| 50 | | [[Image(wormwf.jpg, 30%)]] |
| 51 | | |
| 52 | | (in English: Each infected host generates scan events that target a vulnerable host, scanning for vulnerability x. Once scan hits a vulnerable host with vulnerability x, an infection event occurs and vulnerable host becomes infected. |
| 53 | | |
| 54 | | Note that I haven't yet defined very well what scan event means. I have to do this somewhere but I think the right place for this would be a common repository of domain knowledge. |
| 55 | | |
| 56 | | * '''Invariants:''' There are some in definition of topology and timeline above. No additional ones are needed here. |
| 57 | | |
| 58 | | === P2P w leader and C&C traffic metadescription === |
| 59 | | |
| 60 | | * '''Logical topology:''' |
| 61 | | |
| 62 | | [[Image(peerobj.jpg)]] |
| 63 | | |
| 64 | | (in English: There must be two sets of hosts, at least two 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. All objects here are of type Nodes.) |
| 65 | | * '''Timeline of events: ''' |
| 66 | | |
| 67 | | [[Image(peerwf.jpg, 60%)]] |
| 68 | | |
| 69 | | (in English: Each peer contacts some other peer asking them to peer with it - the contacted peer may reply with a "yes". In parallel with this a peer somehow learns about a leader. If a leader object is known to a given peer, the peer will send it a "hello" message. The leader will then send commands to the peers it knows and may get reports from them back.). |
| 70 | | |
| 71 | | Note that I haven't defined what wannapeer, yespeer, leader, hello, cmd and report events are and I should define it in the common domain knowledge base. |
| 72 | | |
| 73 | | * '''Invariants:''' There are some in definition of topology and timeline above. No additional ones are needed here. |
| 74 | | |
| 75 | | === Experiment design === |
| 76 | | |
| 77 | | 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. I'll do something like this: |
| 78 | | |
| 79 | | [[Image(wp2pcomb.jpg)]] |
| 80 | | |
| 81 | | i.e. each infected host becomes a peer. |
| 82 | | |
| 83 | | The system now needs to offer me several generators: |
| 84 | | |
| 85 | | * It should offer a topology generator and map the initial infected set, vulnerable set and leader set to the topology that gets generated. |
| 86 | | * It should offer event generator for each of the events: scan, yespeer, wannapeer, leaderis, hello, cmd and report. Specifically for scan, yespeer, wannapeer, hello, cmd and report it should offer traffic generators. For leaderis it could either offer a traffic generator or an option to hardcode the leader ID into the peer software. |
| 87 | | * It should offer a malware generator for vulnerability x |
| 88 | | |
| 89 | | 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. |
