For people taking the course for 4 credits, you will need to complete an extra project that will contribute 20% to your grade.
If you have a special passion in a particular area of security, feel free to suggest a topic or a project. Below are some topics that might be interesting. Let me know of a project interest, and I can work with you to identify additional papers to read or an interesting project to perform. Ideally, we will have your project agreed upon by October 19 so you have plenty of time to complete it.
Here are some projects suggested by UIUC research groups
In trust negotiation approaches to authorization, resources are protected by attribute-based access policies, rather than explicit access control lists. Entities use cryptographic credentials issued by third-party attribute certifiers (e.g., professional organizations, employers, or government bodies) to prove various attributes about themselves. Since these attributes might themselves be considered sensitive, they can optionally be protected by release policies placing constraints on the individuals to whom they can be disclosed. As such, a trust negotiation session evolves into a bilateral and iterative exchange of policies and credentials with the end goal of developing new trust relationships on-the-fly.
Performance Evaluation of new trust negotiation framework Professor Winslett's research group has developed a trust negotiation framework called TrustBuilder2. TrustBuilder2 provides a flexible environment for designing, developing, and experimenting with trust negotiation approaches to authorization. We are looking for a student who is interested in security mechanisms to profile the execution of the TrustBuilder2 framework. The student would use tools such as Eclipse's TPTP to examine execution traces, identify bottlenecks, and develop a model describing the system overheads associated with the trust negotiation process. They would then optimize portions of the TrustBuilder2, taking care to ensure that the security properties of the system remain unaffected.
We have also developed a tool for efficiently analyzing the access control policies used in trust management and trust negotiation approaches to authorization. Our tool, Clouseau, analyzes these types of policies to determine all possible ways in which a policy can be satisfied by a given collection of attribute credentials. This enables the design of negotiation strategies that can maximize users' privacy by minimizing the amount of sensitive information disclosed during the protocol.
Implement policy compiler Clouseau analyzes policies written in an intermediate language that specifies constraints on the credentials and credential chains that need to be disclosed in order to satisfy a given policy. We have developed a compilation procedure for translating policies specified in the RT family of trust management languages into a format suitable for analysis by Clouseau, and have formally proven correctness and completeness of this compilation procedure. We are looking for a student who would be interested in implementing this policy compiler and integrating it with TrustBuilder2. The student would need to study a paper that we have written describing the policy compilation process, become familiar with TrustBuilder2, and implement a policy compiler that can function either in a stand-alone manner, or as a plug-in to the TrustBuilder2 runtime system.
Analyze XACML policies To demonstrate the flexibility of the Clouseau approach to policy analysis, we are also interested in analyzing other types of policy languages, such as XACML (an industry-standard access control policy language). We are looking for a student who is interested in authentication and authorization systems and would have an interest in developing a compilation procedure for translating XACML policies into a format that could be analyzed by Clouseau. The student would need to review the XACML standards, become familiar with Clouseau, develop a process for translating XACML policies into the intermediate language supported by Clouseau, and work with one of Professor Winslett's graduate students to formally prove the correctness and completeness of the defined compilation procedure.
Our tool, written using LLVM, currently infers privileges for Linux. For a project, a student could enhance the privilege analysis tool to infer privileges for Solaris, Windows, or some other OS of the student's choice. The source code for our Linux prototype could be used as a starting point.
For a project, a student could find existing exploit code and experimentally determine whether these exploits work on programs compiled with the SAFECode compiler. Exploit code used in worms and virii would be of particular interest. The MetaSploit framework might be a good starting place for this project.
One difficulty for the project is that there is not much working exploit code available for the documented vulnerabilities in the Linux kernel. For a project, a student could develop original working exploit code for these vulnerabilities.
An interesting project would be to write a tool using LLVM that generates models of a program's system call behavior and then checks that model to see if it allows certain malicious behaviors. The systrace policy generator tool I wrote last year could be used as a starting point for this project. Due to the size of the project, it may be possible to create two subprojects: the first is to generate a model from the program using LLVM, and the second is to check the model for resiliency against mimi-cry attacks.
Given a program that uses a mix of high and low data and can be executed in a high or low context. The program will then have instructions which are high or secure if the instructions access or manipulate the secure variables, and low instructions which do not access the high variables. Can we then automatically split the program into the secure and insecure parts, so that we can execute the secure part with higher privilege than the insecure part?
The concept of partitioning the program for security concerns was introduced by Andrew Myers' group at Cornell in the paper: Untrusted hosts and confidentiality: Secure Program Partitioning - www.cs.cornell.edu/zdance/zznm01.ps This idea was followed up in the paper: Secure Program Partitioning - www.cis.upenn.edu/~stevez/papers/ZZNM02.pdf The following paper is an example of how program partitioning can be done: Data Sandboxing - www.cs.uic.edu/~venkat/research/papers/data-sandboxing-acsac06.pdf
The programming effort can be divided into the following parts
Firewall Performance Firewalls are configured by ordered access control lists. These lists can be quite long. Traditionally, firewall devices would interpret these lists in order, so in theory the delay for a packet that matches at the end would be greater than the delay for a packet matching at the beginning. Newer firewalls optionally implement smarter runtime structures to improve throughput. What is the real performance hit in the linear case. How much does the smart lookup structure help? What kind of optimizations could one perform to help? The PIX firewalls in the Cyber Security course lab could be used for this project.
Firewall and Route Optimization This project requires more background knowledge on firewalls and routing. In a PIX firewall's configuration, the inbound traffic (arriving at the firewall) is controlled by the inbound ACLs and the outbound (leaving the firewall) traffic is controlled by the outbound ACLs. While the ACLs control the packet filtering on interfaces, what traffic gets routed to an interface is controlled by the routing rules and translation rules. Thus it's possible that some filters in the ACLs are redundant due to that the routing and translation rules already prevent the filters from being hit at all. For outbound ACLs, we can correlate with the firewall's own routing and translation rules. For inbound ACLs, we can correlate with the connected routers; e.g., we can correlate a FWSM blade's inbound ACLs with its hosting Cat6k's routing and translation rules. If we find an ACL to be redundant, we can further "verify" it through the hit-count, which should be zero since the last related route/translation change.