SYSTEM DESCRIPTION An Internet-based information security lab, or lab, is a collection of systems and software used for teaching information security. Laboratory exercises give students practical experience with security vulnerabilities, security testing, and defenses. The students are not physically in the laboratory, but access it through the Internet. The lab comprises four kinds of entities: servers, sources, targets, and exercises. The first three are specially configured host systems in the lab. Servers provide presence for the students in the lab; servers do not participate in the exercises. Sources and targets participate in the exercises, with at least one source and target for each exercise. The exercises are either exploits or defenses, from the student's point of view. Each exercise has two parts: documentation and implementation. The documentation is provided by the instructor and usually consists of files and code samples that explain the exercise. Students are allowed to access the documentation for an exercise and are expected to construct and demonstrate an implementation. The instructor also provides a model solution which is not given to the students until the exercise is completed. Before each exercise, the lab is configured by an administrator. After the exercise is complete, the administrator restores the lab to an appropriate configuration. SETUP This is an individual activity. You are in charge of coming up with the system's functionality, as well as specifying the requirements: ACTIVITY 1. Start up a document, call it "Requirements Specification for X " where X is the title of your system. Also. place the following headers in the document to be filled out: (3) Overview [1] Description 3] Actors E Security Goals 3. Use Cases (8) Primary Actor (i) Preconditions (5) Main Flow of Events (2] [Misuse|Abuse] Case (1]) Security Requirements 2. Conduct a requirements elicitation session with the customer. Document the main features of the system. The customer is in charge of brainstorming the functionality, but must be reasonable as the instructor can override any customer decision. 3. Elaborate on the requirements by outlining two use cases and filling in the Overview section. What is the system, in general? What are the general security goals of the system? Who are the actors (both regular and malicious)? Write the titles of three use cases, and define the relevant actors for each use case. Don't write the scenarios just yet. 4. Write the main flow for one use case. Make this about 4-10 steps. Be specific about what information is being exchanged. You may add alternative flows if you see the need, but they are not required for this exercise. 5. Now write either a misuse case or abuse case (your choice) for that use case. A few notes: (5) Be sure to include both flow of events and harm done. (7) Make sure the flow affects your main flow, not your preconditions. You may violate a precondition in the process, but this section is for demonstrating how you can abuse/misuse the main flow. (1) Update the header to label each one as either Abuse or Misuse. 6. Sketch your other use cases (no need to be super-detailed on the use case). Write a detailed abuse or misuse case for each use case. Thus, your requirements document should have at least one abuse case and at least one misuse case, and three in total. exercise. 5. Now write either a misuse case or abuse case (your choice) for that use case. A few notes: (i]. Be sure to include both flow of events and harm done. ( Make sure the flow affects your main flow, not your preconditions. You may violate a precondition in the process, but this section is for demonstrating how you can abuse/misuse the main flow. (i]) Update the header to label each one as either Abuse or Misuse. 6. Sketch your other use cases (no need to be super-detailed on the use case). Write a detailed abuse or misuse case for each use case. Thus, your requirements document should have at least one abuse case and at least one misuse case, and three in total. 7. Now that you have defined multiple different abuse and misuse cases, generalize those into security requirements that are not specific to any particular use-case, but are specific to your system. Document it this way: (6) Add a list to the end of your requirements document that defines these security requirements. Each security requirement should have a self-documenting identifier, .9. "Sec1" (3) Add security requirement references to the step in the primary flows (and alternative flows if you added any)
