CSE 5-7359
Software Security
Southern
Methodist University
Dates : 14 January – 6 May 2006
Times : 1000 - 1250 Saturdays (live)
Instructor : William A. Bralick, Jr., Ph.D.
Email : drwilltx@nospam.yahoo.com
William A. Bralick, Jr. received a Bachelor of Science degree in Computer Science from the University of Wisconsin - Madison, a Master of Science degree in Computer Science from The Air Force Institute of Technology, and a Doctorate of Philosophy in Computer Science from The Pennsylvania State University.
Now the vice-president of STX Cadware, Inc., Dr. Bralick was until recently the Enterprise Applications Architect at Club Corporation in Dallas. Formerly, he was Dallas District Manager for Collective Technologies and, prior to that, a Lead Software Engineer at Raytheon TI Systems (the company formerly known as Texas Instruments Defense Systems and Electronics Group) in the Advanced Airborne Electro-Optics division where he was doing cool, real-time things in Ada 95. His research interests include the use of formal models in software engineering, the application of algebraic and abstract systems theory to the specification of software systems, and hardware/software co-design.
Dr. Bralick has extensive practical experience in the development and acquisition of large-scale software systems. Besides his current project, he has worked on the development and acquisition of a large-scale, real-time space-related C3I system. He was also a systems and software engineer on the Identification Friend, Foe, or Neutral Joint Test Force -- a million-line, real-time simulation environment. He is a member of the Association for Computing Machinery, the Institute for Electrical and Electronics Engineers Computer Society, and Tau Beta Pi.
[Viega02] Viega, John, Gary McGraw, Building Secure Software: How to Avoid Security Problems the Right Way, Addison-Wesley, Boston, 2002.
[Oaks01] Oaks, Scott, Java Security, Second edition, O’Reilly & Associates, Inc., Sebastopol, CA, 2001
Software faults lie at the heart of insecure software. Vulnerable software may be attacked across a network and it might be protected from attack by network resources, but the fundamental flaw lies in the software itself. This course is dedicated to exploring how to write software that is secure because it has reduced or eliminated the security flaws that are unintentionally (or intentionally) written into the software in the first place. Network security is not addressed specifically in this course. Nor is cryptography. Programmers are (generally) not cryptographers – if a little knowledge is a dangerous thing then a little cryptographic knowledge is a dangerously insecure thing. As a practical matter, the course also examines security resources and standard practices in Java.
Upon completion of the course, each student will:
· Comprehend the fundamentals of software security.
· Understand the difference between authentication and authorization.
· Comprehend how technology selection affects software security.
· Comprehend sources of risk in source code – why insecure code is usually bad code.
· Understand the pros and cons of open/closed source software.
· Comprehend specific technology risks in software
· Understand software security at the application and database levels.
· Comprehend overall security features and practices in Java.
· Understand Java security components – security manager, access controller, etc.
· Understand keys and their management in Java.
Owing to our medium, the class will consist mostly of informal lectures. These will be coupled with outside class reading, self-graded practice exercises, some web-based research, and three in-class exams. The student should read the relevant material (see the included schedule) before each lecture. N.B. readings and lectures are both testable; some assigned readings will not be discussed during lecture and some lectures will not be based on any assigned readings.
1. Every student is responsible for staying up-to-date on class announcements, any assignments, and any other information that is presented in class. It is the sole responsibility of the student to obtain materials and information for missed classes. N.B. the instructor does not handle the distribution of the lectures. Please refer any such questions to the appropriate staff at SMU, NTU, or local education and training administrators.
2. It is extremely troublesome for all parties concerned to resolve an incomplete grade after the end of a semester – avoid this.
3. If you want a return receipt for any email sent me, then set your email appropriately – I may send an ACK upon receipt, but this is neither guaranteed nor promised.
4. [Shrink-wrap policy.] The topics listed in the syllabus are only an estimate of the material that may be covered during the course. Some material may be deleted or added at the discretion of the instructor.
5. Disability Accommodations: Students needing academic accommodations for a disability must first contact Ms. Rebecca Marin, Coordinator, Services for Students with Disabilities (214-768-4557)* to verify the disability and establish eligibility for accommodations. They should then schedule an appointment with the professor to make appropriate arrangements. (See University Policy No. 2.4.)
6. Religious Observance: Religiously observant students wishing to be absent on holidays that require missing class should notify their professors in writing at the beginning of the semester, and should discuss with them, in advance, acceptable ways of making up any work missed because of the absence. (See University Policy No. 1.9.)
7. Excused Absences for University Extracurricular Activities: Students participating in an officially sanctioned, scheduled University extracurricular activity will be given the opportunity to make up class assignments or other graded assignments missed as a result of their participation. It is the responsibility of the student to make arrangements with the instructor prior to any missed scheduled examination or other missed assignment for making up the work. (University Undergraduate Catalogue)
|
Course grade will be computed as follows: Midterm Exam I (11 Feb 2006) 25% Midterm Exam II (25 Mar 2006) 25% Final Exam ( 6 May 2006) 50% |
You
will be graded on the following scale: A [92 - 100] C [72 - 78] A- [90 - 92] C- [70 - 72] B+ [88 - 90] D+ [68 - 70] B [82 - 88] D [62 - 68] B- [80 - 82] D- [60 - 62] C+ [78 - 80] F [0 - 60] |
Schedule (approximate) |
||
Date[WB1][1] |
Lecture |
Readings |
|
14 Jan 06 |
Administrivia |
|
|
|
Introduction to Software Security |
Viega ch 1 |
|
21 Jan 06 |
Software Security Risk Management |
Viega ch 2-3 |
|
28 Jan 06 |
Open Source: Panacea? |
Viega ch 4-5 |
|
|
Guiding Principles |
|
|
4 Feb 06 |
Software Security Auditing |
Viega ch 6 |
|
11 Feb 06 |
Mid-Term
Exam[2] I |
25% – 1st third |
|
|
Specific Risks |
|
|
18 Feb 06 |
Buffer Overflows and Access Control |
Viega ch 7-8 |
|
25 Feb 06 |
Access Control and Race Conditions |
Viega ch 8-9 |
|
04 Mar 06 |
Trust |
Viega ch 12-13, Thompson95[3] |
|
11 Mar 06 |
Application Security |
Viega ch 14-15 |
|
18 Mar 06 |
Spring Break – No Class |
|
|
25 Mar 06 |
Mid-Term Exam II |
25% – 2nd third |
|
01 Apr 06 |
Introduction to Secure Java Software |
Oaks ch 1-3 |
|
08 Apr 06 |
Java Security Components |
Oaks ch 4-6 |
|
15 Apr 06 |
Holy
Saturday – No Class |
|
|
22 Apr 06 |
Security
Providers and Keys |
Oaks ch 8-10 |
|
|
Messages and Signatures |
Oaks ch 11-12 |
|
29 Apr 06 |
Authentication
and Authorization |
Oaks ch 15 |
|
06 May 06 |
Final
Exam [4] |
Exam = 50%: 25% – final third 25% –comprehensive |