# GEC13 Session on Security Experimentation Date: March 13, 2012 Moderator: [Sean Peisert](http://www.cs.ucdavis.edu/~peisert/) (UC Davis & LBNL) Additional Speakers: Stephen Schwab (USC Information Sciences Institute) and Gale Pomper (U.S. Department of Defense) ## Concept: For now (and the forseeable future) malware-based experiments will be limited to the [DeterLab][3] testbed that is federated with GENI. What this means is that one can a GENI account to stitch together an experiment that involves DeterLab resources and other GENI resources. Malware will however have to be contained within DeterLab. However, there are classes of security experiments that do not involve malware. For example, the [Hive Mind][4] project is using GENI to experiment with a distributed monitoring architecture that could be used for detecting security events. There are others who have proposed doing wireless security experiments using the wireless resources in GENI. Other possibilities include using GENI to get access to real background traffic and using this to train anomaly detectors, for example. Therefore, the goal of this [session][1] was to attempt to come up with answers for the following five questions: 1. What kind of security experiments can be run on GENI? 2. Are any of these new classes of experiments that are particular to GENI? 3. What modifications might be needed to GENI policies or infrastructure to enable such experiments to be run? 4. If or how should GENI Operations should be involved with security experiments? (e.g. should GENI Operations be informed of any security experiments?) 5. What is considered a "security"-relevant experiment? (e.g., is training an anomaly detector a security experiment that requires GENI Operations to be notified?) ## Code of Ethics: Stephen Schwab gave a [presentation][2] on the ethics of performing security experiments in a live, shared network infrastructure, such as GENI. This presentation both introduced the draft code of ethics but helped to prompt discussion on allowable and unallowable classes of security experiments. The draft version 0.9 code of ethics currently reads as follows: 1. Avoid conducting experiments that are harmful to other GENI participants, the GENI infrastructure, or the Internet. 2. Coordinate security experiments in advance with GENI operators. 3. Respect the privacy and confidentiality of other GENI participants and users. 4. Access GENI resources and services only when authorized. The discussion about this code of ethics indicated that the code was relatively uncontroversial. However, there was considerable discussion in the vein of "Well, what about this?" The discussion highlighted the community's discomfort with "rules" that are not both precise and exhaustive. In some sense, this may auger the need for an "acceptable use policy" style set of rules in addition to a code of ethics. On the other hand, though an AUP may be precise, it would also be extremely hard to be both exhaustive *and* up to date. Thus, contacting operators and other experimenters (as indicated in the code of ethics) seems like the most feasible guideline. ## GENI for Security Experiments Gale Pomper proposed an approach in which GENI *can* be used for security experimentation, and proposed a number of experiments appropriate to GENI. (A revised summary will be sent out when Gale's slides are available.) ## External Users and GENI The discussion at GEC 14 about external users using GENI projects will add an additional level of discussion to the issue of security experiments and GENI. ## Wrap-up Returning to our questions at the outset: 1. What kind of security experiments can be run on GENI? - This is still open to debate, but largely, anything is appropriate as long as it is ethical, does not conflict with other experimenters, and is acceptable and legal with regard to interactions with external users (see GEC 14). 2. Are any of these new classes of experiments that are particular to GENI? - Yes, the diverse set of aggregators means that security policies must be accounted for, and experiments considering diverse security policies may have a home on GENI. Also, experiments that can take advantage of heterogeneous systems and networks may find particular value by running on GENI. 3. What modifications might be needed to GENI policies or infrastructure to enable such experiments to be run? - Clearly policies about external users need to be sorted out. The code of ethics may address the rest. An acceptable use policy may still be necessary if a code of ethics is determine to be insufficient. 4. If or how should GENI Operations should be involved with security experiments? (e.g. should GENI Operations be informed of any security experiments?) - GENI operations should be informed of security experiments, per the code of ethics. 5. What is considered a "security"-relevant experiment? (e.g., is training an anomaly detector a security experiment that requires GENI Operations to be notified?) - On the first order, a security relevant experiment is in the eye of the beholder. If the experimenter's ethical hackles are raised, then it is probably a security experiment. More specifically, a security relevant experiment is probably one that explicitly impact others (experimenters, aggregators, control framework, ordinary Internet, users). A pure networking experiment uses bandwidth, but the goal is clearly not explicitly to impact others. Tests of DOS attacks clearly are different. An exhaustive list of what is a security experiment will never be made. An exhaustive list of what is not a security experiment may be easier. [1]: http://groups.geni.net/geni/wiki/GEC13Agenda/SecurityExperimentation "Security Experimentation on GENI" [2]: http://groups.geni.net/geni/attachment/wiki/GENISecurity/experimenters-code-of-ethics-draft-0.9.pdf "Draft Experimenter's Code of Ethics" [3]: http://www.isi.deterlab.net/ [4]: http://groups.geni.net/geni/wiki/HiveMind