Information Security Management

1. Information Security Management Dr. William Hery hery@isis.poly.edu CS 996 Spring 2004

2. Outline of Presentation • Course Motivation • Approach to Learning in This Course • Course Topics • Highlights of course topics to show linkage • Term Project

3. Course Motivation • For SFS students: fill in gaps in National Security Telecommunications and Information Systems Security Committee (NSTISSC) certification for NSA • NSTISSI 4011: National Training Standards for INFOSEC Professionals • NSTISSI 4013: National Training Standards for Systems Administrators in INFOSEC • NSTISSI 4014: National Training Standards for Information Systems Security Officers • Most technical topics are covered in other courses • Missing NSTISSI technical tidbits inserted as needed

4. Course Motivation (continued) • The course will be a survey of information security management topics over a systemlife cycle • Broad management perspective applicable to DoD/NSA, civilian government agencies, corporate world: think like a manager • If you are a manager • If you have to deal with a manager • System, not detail, focus • Not about security products (crypto, fiewall, etc.), but how to use them in a system • Many topics are subjective, not objective • There may be no “right way” or “right answer” • Nasir Memon: “it’s a blah, blah, blah course” • But this doesn’t mean its useless or easy :-)

5. Approach to Learning in this course • Weekly graded homework • Each student will present a 45 minute lecture on a topic--and assign homework for it • Reading and discussion • Active participation in discussion part of grade! • Outside guest expert talks • Student team projects (more later)

6. References • Primary text: Ronald Krutz and Russell Vines, The CISM Prep Guide, Wiley, 2003, ISBN 0-471-45598-9 • Supplementary material from: • Ross Anderson, Security Engineering, Wiley, 2001, ISBN 0-471-38922-6 • Tipton and Krause, Information Security Management Handbook, 4th Edition, Auerbach, ISBN 0-8493-1518-2 • Various web sites, etc.

7. What is Information Security? • A set of properties of the information system, not a technology • These properties are provided with a set of processes and technologies • The properties: CIA • Confidentiality: only permitted entities are allowed to “see” the information • Integrity: only permitted entities are allowed to modify the information (this includes creation and deletion) • Availability: the information is available when needed

8. Related security concepts • Authentication: a means to verify that an entity is who it claims to be for decisions in support of confidentiality and integrity • Access Control: a means to enforce which entities have access to information to support confidentiality and integrity • Authorization: a combination of authentication (who) and access control • Non-repudiation: integrity of the pair (information, creator of information) • Privacy: confidentiality of personal information • Anonymity: confidentiality of identity

9. DoD terminology • Communications Security (COMSEC) • Security of information (voice, data) while in transit. Includes switched circuits, radio links, microwave, satellite, packet nets, Asynchronous Transfer Mode (ATM), Synchronous Optical Networks (SONET), Packet over fiber, free space optics, etc. • Computer Security (COMPUSEC) • Security of information while stored or being processed on a computer • Information Security (INFOSEC) • COMPUSEC + COMSEC • Transmission Security (TRANSEC) • Security of Transmission media • Operations Security (OPSEC) • Processes for protecting potentially sensitive unclassified material • Automated Information Systems (AIS) • Computers + networks linking computers

10. Security vs. Reliability • Security attacks, software flaws, and hardware failure can all lead to violations of “CIA” • For some events, it may be hard to determine which class of flaws is the cause. • Some protection and recovery mechanisms are the same for both security attacks and hardware or software failures

11. Security vs Reliability Differences • Hardware failures • No malicious cause • Usually affects “A”, sometimes “I” or “C” • Typically independent events • Testing is often reliable • Stochastic and temporal failure models useful • “Availability” is a standard term and used in a different • Software failure • No malicious attack: design or coding error • Can affect “A”, sometimes “I” or “C” • Often correlated events from same flaw as similar state conditions arise in different instantiations • Stochastic models of limited value

12. Security vs Reliability Differences (continued) • Security breach • Malicious attack • Serious attacks often attempt to hide event • Can affect “A”, sometimes “I” or “C” • In most cases, the most serious impacts are attacks on “I” or “C” • Many attacks are highly correlated worldwide, but some are very targeted and correlations may be hard to find

13. Management Concerns • Classified information at DoD/NSA/other govt agencies • National security, loss of life, “sources and methods,” political, career impacts of security breech • Unclassified government information • Political, financial, legal, career impacts of security breech • Corporate • Financial, intellectual property, legal, corporate image, career impacts of security breech • Many large corporations, some small corporations push for strong security, but with mixed results (management issues?) • Almost no managers: neat technology

14. What’s Behind Management Decisions for Security • Perfect security is impossible • Great security is very expensive--do we need it? • No security is dangerous • What is the appropriate middle ground? • Need to balance • What do we think we need (requirements)? • What will it cost (money, development time, usability, functionality, performance, etc.)?

15. Sources of Security Requirements • Risk analysis (national security, lives, property, money) • Legal (e. g., HIPAA, privacy laws) • Higher level government/corporate policies • Corporate/agency image • Others derived from the above • Requirements may change due to costs, changing threat environment, etc.

16. System Life Cycle Steps for Security • Risk analysis • Security requirements analysis • Security is a “non-functional” requirement, as is reliability • High level security policy (statement of requirements) • Overall system engineering • Includes design and development • Lower level security policies developed • Security should be an integral element from the start • Security management of deployed system • Incident Response • Business Continuity Planning • Decommissioning of systems and components

17. Risk Analysis • What is at risk (national security, lives, property, money)? • Some risk models are based on $ values • Where does the threat come from? • Motivation (national security, money, fame, • Capabilities (intellect, equipment, money) • What vulnerabilities can be exploited • Technical • Process • People • Risk mitigation • Eliminate/reduce risk • Accept risk (with recovery process) • Transfer risk

18. Security Policy • Essentially a statement of security requirements • Every security policy statement should have a corresponding enforcement mechanism • Policies are at multiple levels • High level policies flow down to multiple lower level policies • High level; e. g., “company proprietary information shall be protected from release to unauthorized personnel” • Mid level; e. g., “there shall be no externally initiated ftp sessions” • Low level; e. g., a firewall rule blocking incoming traffic on ports 20 (ftp data), 21 (ftp control), and 69 (tftp) • The firewall is the enforcement mechanism • Policies also define management processes (e. g., incident response actions) and personnel rules (e. g., don’t write down passwords)

19. Security system engineering • Part of overall systems engineering process • Iterates requirements, design, review through multiple levels of detail • Includes design and development • Lower level security policies developed • Security should be an integral element from the start

20. Student talks • Presentations will focus on management and processes, not technical details (you know them already) • Presenter will be given basic references and other reference pointers, and is encouraged to search for more material • Presenter to assign background reading the week before the talk • Presentation should review background briefly, but assume audience has read them • Presentation should focus on advanced material • Prepare for ~ 45 minutes of presentation material, but use one hour+ with discussion • Active participation of audience is encouraged • Presenter to assign homework on topic • Full class topics will be given by a 2 person team

21. Course Outline & number of student presentations • *Risk Analysis (2 person team) • Legal (HIPAA, etc.) and other requirements (1) • Privacy requirements • *Security Policy (2 person team) • *Security System Engineering--design phase (1) • Security engineering for software (1) • Assessment and assurance • Architecture of classified systems • Certification and Accreditation of systems for classified data (1)

22. Course Outline (continued) • Security management of deployed systems (2) • Business continuity planning (1) • Incident response (1) • Physical security (1) • EMSEC/TEMPEST/TRANSEC (1) • Information System Security Officer (1) • Government key management policy (1) • Security audit

23. Student Team Project • Teams of ~3 students • Pick a system (discuss choice with me) • Want simple functionality, security issues, whole system (e. g., client and server side) • Submit a 1-2 page proposal to management (Dr. Hery) • Assess risks, threats, vulnerabilities • Develop a security policy • Do a high level system security design • Present a “preliminary design review” (PDR) to management (include risk analysis, policies, system architecture) • Iterate on risk assessment, policy, design • Present a final “critical design review” (CDR) to management and the class • Write a final report to management on above

24. Tentative semester schedule

25. Tentative semester schedule (continued)