1. Information Security Management
Dr. William Hery
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 system life 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
Supplementary material from:
Ross Anderson, Security Engineering, Wiley, 2001, ISBN
Tipton and Krause, Information Security Management Handbook, 4th Edition, Auerbach, ISBN
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)