Note: You can view the full content of our pages on any browser or Internet device. However, our pages look best in browsers that support Web Standards.
This basic course would be appropriate for most conventional computer science programs. As background preparation, students should know and understand operating systems, networks, compilers and programming, and general computer principles. This course does not go deeply into cryptography, so advanced mathematics or computational complexity are not needed. Advanced undergraduate or graduate students would be appropriate for such a course.
This outline covers most of the book, except for the more formal models of computing (in Chapter 5), multilevel secure databases (in Chapter 6) and the details of cryptography (Chapter 10). The pace is about one to two weeks per chapter. Obviously, by omitting one chapter an instructor can spend more time on an interesting topic from another. The order is essentially the order of topics in the book, although the book is written with relatively few dependencies between chapters, so the instructor can rearrange topics.
Possible term project: If an isolated network lab is available, divide class into red team and blue. Objective of red team is to secure network; objective of blue team is to compromise some aspect of security of network. Decide rules of engagement first: e.g., is blue team’s goal to perform any nature of compromise (easier for blue team), or only to obtain a specific access right to a specific access (easier for red team). Both teams to keep detailed notes of analysis performed, decisions made, actions taken. At conclusion of exercise (after approximately four to six weeks) general class discussion of actions taken, results obtained. Note: This exercise should be performed only if a dedicated, isolated network is available for testing. It should not be formed on any shared, public, or open network
| Week | Topic, subtopics | Reading, in Security in Computing, 3/e | Outside references | Example projects, assigned work, class discussion topics |
|---|---|---|---|---|
| 1 | Introduction
|
Chapter 1 | Cybersecurity Today and Tomorrow: Pay Now or Pay Later, National Research Council, National Academy Press, 2002 | Each student to bring in one computer security incident from the news of the previous week; class discussion of incidents. |
| 2 | Cryptography
|
Chapter 2 | Schneier, Bruce, “Why Cryptography is Harder than It Looks”. [See also DEN82 or HOF90] |
|
| 3 | Security in programs—I: flaws
|
pp. 95–141 | Ken Thompson, “Reflections on Trusting Trust,” Communications of the ACM, Vol. 27, No. 8, August 1984, pp. 761–763. Landwehr, C., A. Bull, J. McDermott, and W. Choi, A Taxonomy of Computer Program Security Flaws, ACM Computing Surveys, Vol. 26, No. 3, September 1994. See also [SPAF89] |
Student report on a current instance of malicious code; class discussion on detection and prevention techniques. |
| 4 | Security in programs—II: defenses
|
pp. 150–178 | Pawson, R. and C. Woodward, “Restoring the Craft of Software Development: A Review of Extreme Programming”, CSC World, 2002. The Ten Most Critical Web Application Security Vulnerabilities, The Open Web Application Security Project, 2003, www.owasp.org |
Student report on limitations of testing; class discussion of testing approaches, strengths, weaknesses. Class discussion of ways a clever programmer can subvert code and still evade program development controls. Class discussion of ways to improve the quality of mass market commercial software. |
| 5 | Security in conventional operating systems
|
pp. 179–208 | Lampson, Butler, “Protection,” Proc. 5th Princeton Conference on Information Sciences & Systems, Princeton, 1971. Reprinted in ACM Operating Systems Review Vol.8, No. 1, Jan.1974, pp. 18-24 external sources on protection in current commercial operating system (instructor’s choice) |
Students study, report on protection features in contemporary operating system; discussion on strengths of mechanisms, quality of implementation, completeness of protection |
| (Possible exam) | ||||
| 6 | Identification and authentication
|
pp. 209–228 | Kent, S. and L. Millett, eds., IDs–Not that Easy: Questions About Nationwide Identity Systems, National Academy Press, 2002. |
Student reports on different biometric authentication technologies; class discussion on usability, discrimination, available products. Class discussion on password selection criteria: usability, strength. Why people choose insecure passwords. |
| 7 | Trusted operating systems
|
pp. 250–282 | Saltzer and Schroeder design principles; [SAL75 (more detailed) or SAL74 (alternate)] |
|
| 8 | Trusted operating systems: independent evaluation
|
pp. 282–297 | Possible expansion on U.S. TCSEC, its goals, strengths, weaknesses; see [AND82] Possible expansion on Common Criteria, its strengths and weaknesses; market acceptance |
|
| 9 | Database management systems and security | pp. 310–346 | W. Frawley and G. Piatetsky-Shapiro and C. Matheus, "Knowledge Discovery in Databases: An Overview." AI Magazine, Fall 1992, pp 213–228 |
Class discussion on data mining, e.g., as practiced for marketing, and security implications |
| (Possible exam) | ||||
| 10 | Network security—I: Threats
|
pp. 363–425 | CERT, “Security of the Internet,” The Froehlich/Kent Encyclopedia of Telecommunications, New York: Marcel Dekker, Vol. 15, 1997, pp. 231–255. Lipson, Howard, Tracking and Tracing Cyber-Attacks: Technical Challenges and Global Policy Issues, CERT Coordination Center, 2002. An Introduction to Computer Security: The NIST Handbook, 1996. Numerous articles and books on attacking and defending specific types of networks and hosts. |
|
| 11 | Network security–II: Controls
|
pp. 425–457 | Stoneburner, Gary, Alice Goguen, Alexis Feringa, Risk Management Guide for Information Technology Systems: Recommendations of the National Institute for Standards and Technology, 2001. Cheswick, W., "An Evening with Berferd, In Which a Cracker is Lured, Endured, and Studied," Proc Winter USENIX Conf, Jan 1992. See also [CHE94, CHE02] |
|
| 12 | Network security—III: Technologies
|
pp. 457–479 |
Designing an Authentication System: a Dialogue in Four Scenes Home Network Security, CERT Coordination Center. McHugh, John, Alan Christie, and Julia Allen, "Defending Yourself: The Role of Intrusion Detection Systems," IEEE Software, September/October 2000, pp. 42–51. |
Student reports on vendors’ products: goal, threats countered, threats not addressed, apparent strength |
| 13 | Management of security
|
Chapter 8 |
Geer, Daniel, “Risk Management is Where the Money Is,” The Risks Digest, Vol. 20, Issue 6, Nov. 12, 1998, in Abrams, Marshall, Sushil Jajodia, and Harold Podell, eds., Information Security: An Integrated Collection of Essays, IEEE Computer Society Press, 1995 |
|
| 14 | Legal aspects of security
|
pp. 553–595 | "Whodunnit?" The Economist, March 29, 2001, |
Class discussion: comparison of computer crime to other crimes of property; difficulty to investigate, prosecute |
| 15 | Privacy and ethics
|
pp. 595–628 |
Kent, S. and L. Millett, Who Goes There? Authentication Through the Lens of Privacy, National Academy Press, 2003. |
Class discussion of ethical issues from the case studies |
| Final exam | ||||
We do not give a complete syllabus for this course. Basically, it uses the entire book, perhaps studying Chapter 10 immediately after Chapter 2, thus unifying the cryptography discussion.
The one-term version omitted certain more formal topics, such as multilevel secure database management systems, and formal models of secure systems. These topics should be studied in this course.
This course should be supplemented with student readings of the actual literature of the field. Papers such as Denning and Schlörer [DEN83a] on database inference, Landwehr [LAN83] on building trusted operating systems, Rushby and Randell [RUS83] on a separation design for networks, Thompson [THO83] on malicious code, and Bellovin [BEL89] on protocol failures are classics that are reasonably easy for students to appreciate. The instructor should direct students to the suggested readings at the ends of chapters.
The instructor will probably have a particular interest, for example, mobile code security, solid software development practices, network protocols analysis, or incident recognition. In such an area the instructor will want to have students read some of the latest papers.