CSE394: Security Policy Frameworks (Fall 2005)
Scott Stoller

Other CSE394 Pages

Announcements and Assignments
Discussion Forum on Blackboard

Course Description

Specification and enforcement of security policies are increasingly important for every organization and enterprise. As new computer systems are built and old systems grow, with security requirements becoming more complex, the number of security vulnerabilities due to incomplete or incorrect security policies is growing. This is stimulating the development of better frameworks and tools for expressing analyzing, and enforcing security policies.

The goals of this course are to expose students to a spectrum of classic and recent work on security policy frameworks and to let students explore an appropriate topic of their choice in detail through a course project.

We will discuss security policies for centralized systems as well as for systems involving multiple entities that have limited trust in each other, and methods and tools for policy analysis and enforcement. We will also explore how advanced security policy frameworks can be integrated with current security technologies, such as the eXtensible Access Control Markup Language (XACML) and the J2EE security framework.

No specific courses are required as pre-requisites. Students who will be U3 or U4 CSE/ISE majors in Fall 2005 should be ready for this course. If you have any doubts about whether you are ready for this course, please get in touch with me. Note that courses in operating systems and databases are not prerequisites; this course will supply the necessary background for the discussion of OS and DB security.

Course Work

There will be about half a dozen homework assignments and a course project (no exams). The homeworks will be short, since the focus is on the project. Projects may be done individually or in teams, depending on project size. I will suggest a few specific interesting projects. They will fall into two categories: policy development, and security framework development.

Policy development projects provide an opportunity for you to learn more about security issues in an application domain that you are interested in. A typical policy development project would be development of a prototypical security policy for a financial institution or for supply chain management.

Security framework development projects provide hands-on experience with security programming and detailed knowledge of current security standards. A typical security framework development project would be development of an extension of XACML or J2EE with more advanced security features.

Students are also welcome to suggest their own ideas for projects. You are welcome to discuss project ideas with me at any time.

Administrative Info

Meeting Time and Place: Tuesday and Thursday, 2:20pm-3:40pm. Physics P112.
Office Hours: Mon and Wed, 10am-11am, and by appointment and chance.
Credits: 3

Teaching Assistant: Seung Joon Park

Topics (Tentative)

Security Policy Basics

Trust Management and Trust Negotiation

Database Security Policies

Operating System Security Policies

Security Policy Technologies for the Web

Digital Rights Management (DRM)


There is no textbook for this course. We will read articles from conferences and journals. I will present each article in class, in detail, with all necessary background, and with time for discussion, since I realize that for many students, this might be their first time reading such articles.


Grading. Each assignment is graded relative to some maximum number of points (e.g., 20). The maximum number of points is unrelated to the weight of the assignment in the course grade. Each score is normalized into a number between zero and one (e.g., 19/20 -> 0.95) and then multiplied by the weight of the assignment to obtain a weighted score. Course grades are based primarily on the sum of the weighted scores.

Integrity. All students are expected to follow CEAS's policies governing academic dishonesty. Suspected academic dishonesty will be reported to CEAS's Committee on Academic Standing and Appeals (CASA). If you submit anything that includes any material created by other people, your submission must clearly indicate the sources of all such material. Failure to indicate the sources will be treated as plagiarism. Discussing assignments with other people is fine. However, each person must write his or her own submission independently. Showing your own work to other students, giving it to them, or making it accessible to them (e.g., by making the files world-readable, intentionally or through carelessness) will be treated as academic dishonesty.

Disabilities. If you have a physical, psychological, medical or learning disability that may impact on your ability to carry out assigned course work, I would urge that you contact the staff in the Disabled Student Services office (DSS), Room 133 Humanities (moved to ECC Bldg during renovation of Humanities), 632-6748/TDD. DSS will review your concerns and determine, with you, what accommodations are necessary and appropriate. All information and documentation of disability is confidential.

Submission of Assignments

Assignments that do not involve programming should be submitted on paper in class on the due date, unless the assignment specifies otherwise. Assignments submitted after the end of class on the due date are late and receive a -3% penalty. Assignments submitted the next day receive a -6% penalty, and so on.

Submission instructions for assignments that involve programming will be included in the assignment.

Grading Statistics

The following information may be slightly inaccurate, due to score adjustments, late submissions, etc.

Item   MaxPossible   Mean   Std.Dev.
hw1 100 71.4 23.1
hw2 30 15.4 6.0
hw3 30 23.4 4.4
hw4 20 10.3 2.6
proj1 100 91.1 4.9
proj2 100 76.1 25.2
proj3 100 89.4 4.7

Grading Weights