1.Common Requirements1.1Important Dates2.Collaborative Information Sharing Scenario2.1Collaborative Environment2.2Collaborative Infrastructure Requirements3.Web Service Provider Scenario3.1Service provider environment3.2Infrastructure Requirements4.Distributed Office Security4.1Insurance Company environment4.2Infrastructure Requirements5.Research Organization Scenario5.1The Research Environment5.2Research Infrastructure RequirementsCyber Security Spring ’08 Final Project ScenariosSecond Draft1. Common RequirementsThere are four final project scenarios. Each scenario has a customer assigned. You can ask that customer or Prof. Hinrichs for clarification of the requirements. The class will divide into four groups of five people.In all scenarios, your group will be responsible for creating • A security policy and a threat model. What are the goals of the architecture? What are the threats that the design is concerned with?• A security architecture design. This design should identify what technologies are used and where. It should discuss the implementation and maintenance issues (e.g. key management and access changes in the in face of a changing population). Where appropriate, the design should discuss the tradeoffs and the motivations for choosing one technology or technique over another. The design should include an overview diagram which can be hand drawn.• A laboratory implementation for a subset of the design. Depending on what is implemented, you should submit an implementation design, configuration files, and supporting log data. In most cases you should also arrange a demonstration of the implementation.• A final presentation and writeup. The presentation and writeup will review the problem and your solution. It should be targeted at your customer. You will have 30 minutes allocated for the presentation.1.1 Important DatesMarch 13 – tentatively form groups and narrow set of projects down to four.March 27 - : group members and scenario assignments finalizedMarch 31 – April 4: groups meet with Prof. Hinrichs for initial design review and identification of lab implementation subset. An initial security policy is due at this time.April 24 and April 29: In class presentation of design.May 5: Final design and lab due2. Collaborative Information Sharing ScenarioIn this scenario, a number of different organizations are collaborating to address an urgent problem. Each organization has strong information labeling and information flow constraints. Each organization has a separate user authentication space.The primary goals for this architecture are:• Flexible but high assurance entity authentication- 1 -• Flexible but high assurance information sharing.The virtual customer is Mikel Matthews, [email protected] Collaborative EnvironmentIn response to an emergency, we need a scheme to quickly map how the labeling schemes relate and have an automated means to share information between the different organizations. The emergency may by a natural disaster like Katrina, a terrorist act like 9-11, or a regional war like in Iraq or Sudan. In all cases, people from a variety of organizations will need to share information starting very quickly for the period of weeks to years. This can be very sensitive information, so the design must also be careful to not drop security so much that the malicious entity can take advantage of the chaos of the event to gain access to restricted information. Several approaches have been taken to share data between organizations. One approach is to have each member of the coalition maintain their own portion of the data and use access control or a guard approach to automatically enables a process of upgrading/downgrading data between different labels. Alternatively, the coalition could create a joint data repository or community of interest that is accessed by all organizations. The joint authority can either be hosted by a "lead" organization (this is reasonable in a military setup), by a trusted third party (not easy to find), or maintained with a consensus based policy approach. Some recent work on the joint repository approach is described in the following papers:• Laura Pearlman, Von Welch, Ian Foster, Carl Kesselman, and Steven Tuecke. A Community Authorization Service for group collaboration. In Proceedings of the IEEE 3rd International Workshop on Policies for Distributed Systems and Networks, 2002.• Rakesh Bobba, Serban Gavrila, Virgil Gligor, Himanshu Khurana, and Radostina Koleva. Administering Access Control in Dynamic Coalitions. In Proceedings of the 19th USENIX Large Installation System Administration Conference (LISA), Tucson, AZ, December 2005.In addition to enabling information sharing, your design will also need to address how people are authenticated into the system. Since these collaborations are dynamic and not pre-planned a basic password scheme is not going to be sufficient. Most technologies that attempt scalable authentication use some form of certificates plus strong multi-factor authentication. Safely deploying and maintaining long-lived certificates is a major concern. In practice only limited forms of multi-factor authentication may be viable for coalition environments. This is because each organization is likely to retain its own identity certification process that is trusted by other domains in the coalition. Therefore, trusting multiple factors for the authentication gets complicated. There are protocols such as OpenID and SAML for delegating authentication to trusted parties.- 2 -2.2 Collaborative Infrastructure Requirements• High-assurance environment. • Strong, flexible cross-organization authenticationo Certificate-based• Strong, flexible cross-organization data sharing. • Automated, safe data-sharing3. Web Service Provider ScenarioThe target company is a mid-level Internet service provider. It wants to move into the web hosting space. It wants to offer a range of web hosting options from basic web sites to content management systems (CMS) to completely customer managed sites.In giving more power to the customer, the ISP must worry about attacks generating from the customer (either intentional or externally exploited). A poorly implemented javascript may open the customer up for a variety of attacks. Such attacks may steal resources from that customer or other customers, and the attack traffic may cause the ISP's addresses to get black listed which will cause
View Full Document
Unlocking...