Information Security Management Dr. William Hery [email protected] CS 996 Spring 2004

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Information Security Management

Dr. William [email protected]

CS 996Spring 2004

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Outline of Presentation

• Course Motivation• Approach to Learning in This Course• Course Topics• Highlights of course topics to show

linkage• Term Project


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


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 :-)


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)


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.


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


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


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


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


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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.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


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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.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.)?

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.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.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.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


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


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)


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


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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.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)


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


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


Tentative semester schedule

2/4 *Overview (Hery)2/11 PRESENTATION TOPICS SELECTED

*Assessment/Assurance (Hery)*Architecture of Classified Systems (Hery)

2/18 TERM PROJECT TEAMS FORMED AND PROPOSALS DUE*Risk Analysis (2)

2/25 *Policy (2)3/3 *Secure Systems Engineering (2)3/10 Security Management and administration of Deployed Systems (1-2)3/17 Incident Response

Business Continuity Planning3/24 TERM PROJECT PRELIMINARY DESIGN REVIEW (PDR)

(outside class hours)

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Tentative semester schedule (continued)

3/24 Legal and other requirements (HIPAA, Sarbanes Oxley, CA1386)Privacy Requirements (Hery)

3/31 Security Engineering for SoftwareTRANSEC/EMSEC/Tempest (EE background)

4/14 Physical SecurityInformation System Security Officer

4/21 Government Key Management PolicySecurity Audit (taken)

Make upsession

Certification and AccreditationSpecial Topics

4/21-4/28 TERM PROJECT CRITICAL DESIGN REVIEWS (in class)TBD TERM PROJECT FINAL REPORT (due finals week)

Documents

Information Security Management Dr. William Hery [email protected] CS 996 Spring 2004