Department of Computer & Information Sciences. INFO-450: Information Systems Security Syllabus

Transcription

1 Department of Computer & Information Sciences INFO-450: Information Systems Security Syllabus Course Description This course provides a deep and comprehensive study of the security principles and practices of information systems. Topics include basic information security concepts, common attacking techniques, common security policies, basic cryptographic tools, authentication, access control, software security, operating system security, and legal and ethical issues in information systems security. Through this course, students shall be able to understand the basic principles and practices in information systems security. In particular, understand what the foundational theory is behind computer security, what the common threats are, and how to play with the games with attackers. Textbook W. Stallings, Computer Security: Principles and Practice, 2 st Edition, Prentice Hall, ISBN: , Recommended Supplement M. Stamp, Information Security: Principles and Practice, 2 st Edition, Wiley, ISBN: , M. E. Whitman and H. J. Mattord, Principles of Information Security, 4 st Edition, Course Technology, ISBN: , M. Bishop, Computer Security: Art and Science, Addison Wesley, ISBN: , G. McGraw, Software Security: Building Security In, Addison Wesley, ISBN: , Prerequisite CSCI-360: Computer Networks CSCI-342: Introduction to Information Security Major Topics 1. Overview 1.1. Computer Security Concepts 1.2. Threats, Attacks, and Assets 1.3. Security Functional Requirements 1.4. A Security Architecture for Open Systems 1.5. Computer Security Trends

2 1.6. Computer Security Strategy PART ONE COMPUTER SECURITY TECHNOLOGY AND PRINCIPLES 2. Cryptographic Tools 2.1. Confidentiality with Symmetric Encryption 2.2. Message Authentication and Hash Functions 2.3. Public-Key Encryption 2.4. Digital Signatures and Key Management 2.5. Random and Pseudorandom Numbers 2.6. Practical Application: Encryption of Stored Data 3. User Authentication 3.1. Means of Authentication 3.2. Password-Based Authentication 3.3. Token-Based Authentication 3.4. Biometric Authentication 3.5. Remote User Authentication 3.6. Security Issues for User Authentication 3.7. Practical Application: An Iris Biometric System 3.8. Case Study: Security Problems for ATM Systems 4. Access Control 4.1. Access Control Principles 4.2. Subjects, Objects, and Access Rights 4.3. Discretionary Access Control 4.4. Example: UNIX File Access Control 4.5. Role-Based Access Control 4.6. Case Study: RBAC System for a Bank 5. Database Security 5.1. The Need for Database Security 5.2. Database Management Systems 5.3. Relational Databases 5.4. Database Access Control 5.5. Inference 5.6. Statistical Databases 5.7. Database Encryption 5.8. Cloud Security 6. Malicious Software 6.1. Types of Malicious Software (Malware) 6.2. Propagation Infected Content Viruses 6.3. Propagation Vulnerability Exploit Worms 6.4. Propagation Social Engineering SPAM , Trojans 6.5. Payload System Corruption 6.6. Payload Attack Agent Zombie, Bots 6.7. Payload Information Theft Keyloggers, Phishing, Spyware 6.8. Payload Stealthing Backdoors, Rootkits 6.9. Countermeasures 7. Denial-of-Service Attacks 7.1. Denial-of-Service Attacks 7.2. Flooding Attacks 7.3. Distributed Denial-of-Service Attacks

3 7.4. Application-Based Bandwidth Attacks 7.5. Reflector and Amplifier Attacks 7.6. Defenses Against Denial-of-Service Attacks 7.7. Responding to a Denial-of-Service Attack PART TWO SOFTWARE SECURITY AND TRUSTED SYSTEMS 8. Buffer Overflow 8.1. Stack Overflows 8.2. Defending Against Buffer Overflows 8.3. Other Forms of Overflow Attacks 9. Software Security 9.1. Software Security Issues 9.2. Handling Program Input 9.3. Writing Safe Program Code 9.4. Interacting with the Operating System and Other Programs 9.5. Handling Program Output 10. Operating System Security Introduction to Operating System Security System Security Planning Operating Systems Hardening Application Security Security Maintenance Linux/Unix Security Windows Security Virtualization Security 11. Trusted Computing and Multilevel Security The Bell-LaPadula Model for Computer Security Other Formal Models for Computer Security The Concept of Trusted Systems Application of Multilevel Security Trusted Computing and the Trusted Platform Module Common Criteria for Information Technology Security Evaluation Assurance and Evaluation PART THREE MANAGEMENT ISSUES 12. IT Security Management and Risk Assessment IT Security Management Organizational Context and Security Policy Security Risk Assessment Detailed Security Risk Analysis Case Study: Silver Star Mines 13. IT Security Controls, Plans, and Procedures IT Security Management Implementation Security Controls or Safeguards IT Security Plan Implementation of Controls Implementation Follow-up Case Study: Silver Star Mines

4 14. Physical and Infrastructure Security Overview Physical Security Threats Physical Security Prevention and Mitigation Measures Recovery from Physical Security Breaches Example: A Corporate Physical Security Policy Integration of Physical and Logical Security 15. Human Resources Security Security Awareness, Training, and Education Employment Practices and Policies and Internet Use Policies Computer Security Incident Response Teams 16. Security Auditing Security Auditing Architecture The Security Audit Trail Implementing the Logging Function Audit Trail Analysis Example: An Integrated Approach 17. Legal and Ethical Aspects Cybercrime and Computer Crime Intellectual Property Privacy Ethical Issues Learning Outcomes A student completing this course is expected to be able to: 1. State the basic concepts in information systems security, including security technology and principles, software security and trusted systems, and IT security management. 2. Explain concepts related to various cryptographic tools. 3. State the requirements and mechanisms for identification and authentication. 4. Explain and compare the various access control policies and models as well as the assurance of these models. 5. State the characteristics of typical security architectures, including multi-level security systems. 6. State the criteria of evaluating secure information systems, including evaluation of secure operating systems and secure network systems. 7. List the database security issues and solutions, including models, architectures, and mechanisms for database security. 8. State program security issues, including virus, worm, and logical bombs. 9. State the basic concepts and general techniques in security auditing and risk assessment. 10. State the issues related to administration security, physical security, and program security. 11. Determine appropriate mechanisms for protecting information systems ranging from operating systems, to database management systems, and to applications.

5 Grading Letter Grade A B C D F 0 59 Evaluation Procedures Homework Assignment 20% Quiz 10% Midterm Exam 10% Final Exam 20% Project &Presentation 40% Projects The group projects will involve setting up systems and writing programs that demonstrate important concepts and mechanisms introduced in the classes. The most common reason for not doing well on projects is not starting them early enough. You will be given plenty of time to complete each project. However, if you wait until the last minute to start, you may not be able to finish. Start early and plan to have it finished a few days ahead of the due date. Many unexpected problems typically arise during programming, particularly when debugging. You should plan for these things to happen. The department computer lab will be available for project work. We will also make an environment available for you that can be used to work on projects on your own computer. Your lack of staring early is not an excuse for turning in your project late, including having your computer crash. There are a number of sources for help. This includes office hours, and discussion groups on the class website. Group Rules: each group is to have a maximum 2 people. This means that you can work on your project individually or with another person. If you work in a group of two, you may collaborate on ONLY with your group member and not with a member of another group. Group selection is made by ing the instructor by the 3 rd class meeting. Once you select a group member, you may not change group membership. Each project submitted by a group will include a separate submission by each group member indicating a percentage describing each group member s contribution. Equal contribution means each member (in a 2 person group) contribute 50%. Anything different from equal contribution will result in a reduction in grade from the group member who contributes less and an increase in grade for the group member who contributes more. The oral class presentation will be done in groups of 2. If there are an odd number of students registered for the class, a single student will have the option of either presenting individually or joining a group (making a single group of 3). Homework All work will be submitted electronically. Homework and Projects are due at 11:59 PM on the due date described in the assignments. Late policy is as follows: 10% grade penalty for one day of lateness 50% grade penalty for two days of lateness

6 A grade of zero for >2 days of lateness Note: plagiarism, copying, or cheating of any kind will result in a minimum of an F in the course for all parties involved and a maximum of expulsion from the University should I warrant the need to report it to the Student Judicial Affairs office. Attendance Policy Attendance is mandatory. It is the responsibility of the student to ensure that they sign the signin sheet prior to leaving class. Students that have not signed the sign-in sheet will be considered absent even if they attended class for that day. Students are allowed a maximum of two unexcused absences during the semester. Students that have more than two unexcused absences but less than or equal to four unexcused absences will have their course average reduced by five points. In addition, for each unexcused absence above four, students will receive an additional two points off from their course average. Excused absences require documentation from an authorized party. An absence due to medical reasons will require a note or document from a medical practitioner or institution. Where possible, permission to be absent from class should be obtained in advance. Attempting to obtain permission for being absent after the fact and without proper documentation is not acceptable. Cell Phone Policy Cell phones should be turned off or in silent mode and should be tucked away somewhere not visible to anyone, especially to the instructor. Students will receive a warning on their first infraction of this policy and will be asked to leave the class on each additional infraction and considered absent. In addition, the student will receive an F on any graded work that is due or carried out on that day. Under no circumstance is a student to use the phone in class in any capacity. This includes text messaging! Students that leave the class to talk on their cell phones will not be allowed to return to class. This policy is in effect from the start of class until the instructor dismisses the class. Test Taking Policy During a scheduled exam or quiz, you are required to clear all material from the desk or table prior to beginning your exam or quiz. All books, bags, and other personal material should be placed on the floor. Cell phone policy remains in effect during an exam or quiz. This means that the use of a cell phone without permission from the instructor will result in a zero. Please make sure to use the restroom prior to beginning your exam. If you must use the rest room during the exam, you will need to submit your exam or quiz and it will be graded as is. Cheating and Collaboration Policy Collaboration is a healthy and constructive way to learn and accomplish tasks. Unfortunately, many students often do not realize that what they believe to be collaboration is actually cheating. Cheating on assignments or projects does not benefit anyone, especially you, and undermines our trust. Because the line between collaboration and cheating can get confusing for students, especially those not exposed to proper collaboration behavior, you are asked to carefully consider what is discussed in this section; however, the rule of thumb should always be that when in doubt about whether a particular action can be considered cheating, ask your instructor. In this course, engaging directly with one another on assignments and projects can only enhance the learning process. But how you engage is very important. Discussing assignments and projects at a conceptual level, helping with conceptual bugs in code, or discussing lecture and text material is acceptable. When you turn in assignments, the content must be completely yours! Exceptions occur

7 when your instructor allows you to use material in the public domain; however, you will be required to reference the work. For the purpose of this course, using snippet of code from classmates accomplishes nothing! In the end, it is about what you have learned. Your grade means absolutely nothing to anyone once they figure out you cannot program. In the same token, helping someone by looking at their code, more often than none, leads to copying at some level. Please note that this is not the same as looking at someone else s code to learn to become a better programmer. In general, you are better off asking your instructor prior to looking at another classmate s code. Verbal collaboration is generally acceptable. Examples of acceptable collaboration: Discussing ambiguities in assignments or course materials to gain a better understanding of them; Providing assistance with Java, either in using the system facilities or with debugging tools. Discussing and explaining code provided in the course. Obtaining help on general programming issues (i.e. what does a specific error mean?); As a general rule, if you do not understand or cannot explain what you are handing in, or if you have written the same code as someone else, you are probably cheating. If you have given somebody some code, simply so that it can be used in that person's project, you are probably cheating. Here are some examples of clear cases of cheating: Copying files or parts of files (such as source code, written text, or unit tests) from another person or source. Copying (or retyping) files or parts of files with minor modifications such as style changes or minor logic modifications. Allowing someone else to copy your code or written assignment in any form. Getting help from someone whom you do not acknowledge on your solution. The policies in this section were adapted from those instituted in the Computer Science Department at Carnegie Mellon University.