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.

Teaching Assistant: Seung Joon Park

Topics (Tentative)

Security Policy Basics

• Overview of Security Policies. Introduction and Motivation. Types of security policies/requirements: confidentiality, integrity, and combinations of them.
• Design Principles for Security The principles include least privilege, complete mediation, separation of privilege, open design, etc. Many of these principles were formulated decades ago and are as important today as then.
• Role-Based Access Control (RBAC). Role-based access control, in some form or another, is nearly ubiquitous, because it greatly eases development and maintenance of security policies. We will discuss the recent ANSI Standard for RBAC.
• Attribute-Based Access Control (ABAC). ABAC allows access control decisions to depend on multiple attributes of the requester, not just their identity or role. An example of ABAC is the U.S. Navy proposal for Enterprise Dynamic Access Control (EDAC).
• Case study: Clinical Information Systems. Clinical information systems store patients' medical histories, sometimes called Electronic Health Records (EHRs). This is an extremely important and complex application domain with high-stakes security requirements.

Trust Management and Trust Negotiation

• Introduction and motivation. Trust management is access control for systems in which there is no single completely and globally trusted entity. The essential ingredients of trust management are support for attribute-based access control and delegation. We will look at several examples of systems where traditional access control is inadequate, and where trust management fits the bill.
• Trust Management Systems. We will examine some notable trust management systems, such as SPKI/SDSI, Binder, and Cassandra.
• Trust Negotiation. In open systems like the Internet, strangers can establish trust in each other by learning about each other's attributes, described in digital credentials that are disclosed during trust negotiation to gradually build up enough trust to complete a sensitive interaction [ISRL]. We will study policies and strategies for trust negotiation.
• Case Study: Clinical Information Systems. Clinical information systems are an excellent example of the need for trust management. As a large, interesting, and realistic case study, we will examine a security policy for Electronic Health Records developed by the UK's National Health Service.

Database Security Policies

• RBAC in Databases. SQL provides a standard level of support for RBAC. Some databases, such as Sybase, also support more advanced RBAC features.
• Information Inference. Information inference control ensures that users cannot indirectly infer information that they are not allowed to access directly.
• Multi-Level Databases. Multi-level databases support military-style multi-level security classifications (top secret, secret, classified, etc.).

Operating System Security Policies

• Introduction and Motivation. We will discuss traditional Operating System security mechanisms, their limitations, and how those limitations can be overcome.
• Case Study: Security-Enhanced Linux (SE Linux). SE Linux was developed by the National Security Agency and is now incorporated in the mainstream 2.6 Linux kernel, distributed by RedHat and others (the extensions are turned off by default, though). We will discuss the design and security benefits of SE Linux.
• Development and Analysis of SE Linux Policies. The difficulty of security policy development is a major issue facing widespread use of SE Linux. We will discuss tools that can help users understand and validate SE Linux policies.

Security Policy Technologies for the Web

• XACML The eXtensible Access Control Markup Language (XACML) is an XML-based security policy language standardized by OASIS. We will briefly discuss related technologies, such as X.509 and SAML. We will discuss XACML's ability to support RBAC, delegation, and trust management.
• RBAC on the Web Architectures for using RBAC on the Web.

Digital Rights Management (DRM)

• Rights Expression Languages. Policy languages for digital rights management include XrRML and ODRL.

Readings

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.

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.