csce 548 secure system standards risk management n.
Skip this Video
Loading SlideShow in 5 Seconds..
CSCE 548 Secure System Standards Risk Management PowerPoint Presentation
Download Presentation
CSCE 548 Secure System Standards Risk Management

Loading in 2 Seconds...

play fullscreen
1 / 56

CSCE 548 Secure System Standards Risk Management - PowerPoint PPT Presentation

  • Uploaded on

CSCE 548 Secure System Standards Risk Management. Announcement. Job Openings: Daniel Rusu, Dreamgol, LLC 803-727-5634 Announcements. Job openings: Peter J. Johnson, Staffing Consultant 978.927.7000 (m) / (e)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CSCE 548 Secure System Standards Risk Management' - feng

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • Job Openings:
    • Daniel Rusu, Dreamgol, LLC
    • 803-727-5634
  • Job openings:
    • Peter J. Johnson, Staffing Consultant
    • 978.927.7000 (m) / (e)
    • (linkedin)
    • Massachusetts, Maryland, Virginia, and Ohio for computer scientists and software engineers with credentials in the fields of security, networking and privacy
    • US citizenship
  • Job Openings:
    • Charleston, system development
    • C, Python, and Java, Linux, specifically Fedora 14, cellular communications, electrical engineering or the basic principles, and mysql
    • Android, iPhone / iPad developers to build the follow on versions of a current geo-location / SMS application
    • Contact info upon request
  • Requirements available at
  • Useful links:
    • OWASP, Open Web Application Security Project,
    • Sample projects
homework 1
Homework 1

Choose a team member among your class mates. This selection is for this exercise only.

List the steps of RMF for the "KillerAppCo's iWare 1.0 Server" given in your text book. (3 points)

Carry out similar RMF on the computing resources owned by your team member. For example, understand the "business" context may include goals like graduating from USC, making profit from writing software to a company, etc. Document your RMF activities and findings. (7 points)

BONUS points (2 points): Have your partner evaluate your risk management report and comment on it.

  • This lecture:
    • McGraw: Chapter 2
    • Recommended:
      • Rainbow Series Library,
      • Common Criteria,
  • Next lecture:
    • Software Development Lifecycle – Dr. J. Vidal





Risk Assessment


Financial Loss

Dollar Amount Losses by Type

Total Loss (2006): $53,494,290 CSI/FBI Computer Crime and Security Survey

Computer Security Institute


Percentage of IT Budget

Spent on Security

Percentage of Organizations

Using ROI, NPV, or IRR Metrics

CSI/FBI Computer Crime and Security Survey

Computer Security Institute

Security Protection


Real Cost of Cyber Attack

  • Damage of the target may not reflect the real amount of damage
  • Services may rely on the attacked service, causing a cascading and escalating damage
  • Need: support for decision makers to
    • Evaluate risk and consequences of cyber attacks
    • Support methods to prevent, deter, and mitigate consequences of attacks

System Security Engineering

(Traditional View)

Specify System


Identify and

Install Safeguards

Identify Threats,

Vulnerabilities, Attacks





Risk is acceptably low


Carry Out Fixes

and Validate

Identify Business

and Technical Risks

Define Risk

Mitigation Strategy

Synthesize and Rank


Measurement and Reporting

Risk Management Framework

(Business Context)

Understand Business


understand the business context
Understand the Business Context
  • “Who cares?”
  • Identify business goals, priorities and circumstances, e.g.,
    • Increasing revenue
    • Meeting service-level agreements
    • Reducing development cost
    • Generating high return investment
  • Identify software risk to consider
identify business and technical risks
Identify Business and Technical Risks
  • “Why should business care?”
  • Business risk
    • Direct threat
    • Indirect threat
  • Consequences
    • Financial loss
    • Loss of reputation
    • Violation of customer or regulatory constraints
    • Liability
  • Tying technical risks to the business context in a meaningful way
synthesize and rank the risks
Synthesize and Rank the Risks
  • “What should be done first?”
  • Prioritization of identified risks based on business goals
  • Allocating resources
  • Risk metrics:
    • Risk likelihood
    • Risk impact
    • Risk severity
    • Number of emerging risks
define the risk mitigation strategy
Define the Risk Mitigation Strategy
  • “How to mitigate risks?”
  • Available technology and resources
  • Constrained by the business context: what can the organization afford, integrate, and understand
  • Need validation techniques
carry out fixes and validate
Carry Out Fixes and Validate
  • Perform actions defined in the previous stage
  • Measure “completeness” against the risk mitigation strategy
    • Progress against risk
    • Remaining risks
    • Assurance of mechanisms
  • Testing
measuring and reporting
Measuring and Reporting
  • Continuous and consistent identification and storage of risk information over time
  • Maintain risk information at all stages of risk management
  • Establish measurements, e.g.,
    • Number of risks, severity of risks, cost of mitigation, etc.

Assets-Threat Model (1)

  • Threats compromise assets
  • Threats have a probability of occurrence and severity of effect
  • Assets have values
  • Assets are vulnerable to threats




Assets-Threat Model (2)

  • Risk: expected loss from the threat against an asset
  • R=V*P*S
    • R risk
    • V value of asset
    • P probability of occurrence of threat
    • V vulnerability of the asset to the threat

System-Failure Model

  • Estimate probability of highly undesirable events
  • Risk: likelihood of undesirable outcome






Risk Acceptance

  • Certification
    • How well the system meet the security requirements (technical)
  • Accreditation
    • Management’s approval of automated system (administrative)

Incident Handling Computer Security Incident Handling Guide, Recommendations of the National Institute of Standards and Technology


How to Response?

  • Actions to avoid further loss from intrusion
  • Terminate intrusion and protect against reoccurrence
  • Law enforcement – prosecute
  • Enhance defensive security
  • Reconstructive methods based on:
    • Time period of intrusion
    • Changes made by legitimate users during the effected period
    • Regular backups, audit trail based detection of effected components, semantic based recovery, minimal roll-back for recovery.

Roles and Responsibilities

  • User:
    • Vigilant for unusual behavior
    • Report incidents
  • Manager:
    • Awareness training
    • Policies and procedures
  • System administration:
    • Install safeguards
    • Monitor system
    • Respond to incidents, including preservation of evidences

Computer Incident Response Team

  • Assist in handling security incidents
    • Formal
    • Informal
  • Incident reporting and dissemination of incident information
  • Computer Security Officer
    • Coordinate computer security efforts
  • Others: law enforcement coordinator, investigative support, media relations, etc.

Incident Response Process 1.


  • Baseline Protection
  • Planning and guidance
  • Roles and Responsibilities – Training
  • Incident response team

Incident Response Process 2.

Identification and assessment

  • Symptoms
  • Nature of incident
    • Identify perpetrator, origin and extent of attack
    • Can be done during attack or after the attack
  • Gather evidences
    • Key stroke monitoring, honey nets, system logs, network traffic, etc.
    • Legislations on Monitoring!
  • Report on preliminary findings

Incident Response Process 3.


  • Reduce the chance of spread of incident
  • Determine sensitive data
  • Terminate suspicious connections, personnel, applications, etc.
  • Move critical computing services
  • Handle human aspects, e.g., perception management, panic, etc.

Incident Response Process 4.


  • Determine and remove cause of incident if economically feasible
  • Improve defenses, software, hardware, middleware, physical security, etc.
  • Increase awareness and training
  • Perform vulnerability analysis

Incident Response Process 5.


  • Determine course of action
  • Reestablish system functionality
  • Reporting and notifications
  • Documentation of incident handling and evidence preservation

Follow Up Procedures

  • Incident evaluation:
    • Quality of incident (preparation, time to response, tools used, evaluation of response, etc.)
    • Cost of incident (monetary cost, disruption, lost data, hardware damage, etc.)
  • Preparing report
  • Revise policies and procedures
security awareness and training
Security Awareness and Training
  • Major weakness: users unawareness
  • Organizational effort
  • Educational effort
  • Customer training
  • Federal Trade Commission: program to educate customers about web scams
building it secure
Building It Secure
  • 1960s: US Department of Defense (DoD) risk of unsecured information systems
  • 1970s:
    • 1977: DoD Computer Security Initiative
    • US Government and private concerns
    • National Bureau of Standards (NBS – now NIST)
      • Responsible for standards for acquisition and use of federal computing systems
      • Federal Information Processing Standards (FIPS PUBs)
  • Two initiatives for security:
    • Cryptography standards
      • 1973: invitation for technical proposals for ciphers
      • 1977: Data Encryption Standard
      • 2001: Advanced Encryption Standard (NIST)
    • Development and evaluation processes for secure systems
      • Conferences and workshops
      • Involves researchers, constructors, vendors, software developers, and users
      • 1979: Mitre Corporation: entrusted to produce an initial set of criteria to evaluate the security of a system handling classified data
national computer security center
National Computer Security Center
  • 1981: National Computer Security Center (NCSC) was established within NSA
    • To provide technical support and reference for government agencies
    • To define a set of criteria for the evaluation and assessment of security
    • To encourage and perform research in the field of security
    • To develop verification and testing tools
    • To increase security awareness in both federal and private sector
  • 1985: Trusted Computer System Evaluation Criteria (TCSEC) == Orange Book
orange book
Orange Book
  • Orange Book objectives
    • Guidance of what security features to build into new products
    • Provide measurement to evaluate security of systems
    • Basis for specifying security requirements
  • Security features and Assurances
  • Trusted Computing Base (TCB) security components of the system: hardware, software, and firmware + reference monitor
orange book1
Orange Book


  • Users: evaluation metrics to assess the reliability of the security system for protection of classified or sensitive information when
    • Commercial product
    • Internally developed system
  • Developers/vendors: design guide showing security features to be included in commercial systems
  • Designers: guide for the specification of security requirements
orange book2
Orange book
  • Set of criteria and requirements
  • Three main categories:
    • Security policy – protection level offered by the system
    • Accountability – of the users and user operations
    • Assurance – of the reliability of the system
security policy
Security Policy
  • Concerns the definition of the policy regulation the access of users to information
    • Discretionary Access Control
    • Mandatory Access Control
    • Labels: for objects and subjects
    • Reuse of objects: basic storage elements must be cleaned before released to a new user
  • Identification/authentication
  • Audit
  • Trusted path: no users are attempting to access thr system fraudulently
  • Reliable hardware/software/firmware components that can be evaluated separately
  • Operation reliability
  • Development reliability
operation reliability
Operation reliability
  • During system operation
    • System architecture: TCB isolated from user processes, security kernel isolated from non-security critical portions of the TCB
    • System integrity: correct operation (use diagnostic software)
    • Covert channel analysis
    • Trusted facility management: separation of duties
    • Trusted recovery: recover security features after TCB failures
development reliability
Development reliability
  • System reliable during the development process. Formal methods.
    • System testing: security features tested and verified
    • Design specification and verification: correct design and implementation wrt security policy. TCB formal specifications proved
    • Configuration management: configuration of the system components and its documentation
    • Trusted distribution: no unauthorized modifications
  • Defined set of documents
  • Minimal set:
    • Trusted facility manual
    • Security features user’s guide
    • Test documentation
    • Design documentation
    • Personnel info: Operators, Users, Developers, Maintainers
orange book levels
Orange Book Levels

Highest Security

  • A1 Verified protection
  • B3 Security Domains
  • B2 Structured Protection
  • B1 Labeled Security Protections
  • C2 Controlled Access Protection
  • C1 Discretionary Security Protection
  • D Minimal Protection

No Security

ncsc rainbow series
NCSC Rainbow Series
  • Orange: Trusted Computer System Evaluation Criteria
  • Yellow: Guidance for applying the Orange Book
  • Red: Trusted Network Interpretation
  • Lavender: Trusted Database Interpretation
evaluation process
Evaluation Process
  • Preliminary technical review (PTR)
    • Preliminary technical report: architecture potential for target rating
  • Vendor assistance phase (VAP)
    • Review of the documentation needed for the evaluation process, e.g., security features user’s guide, trusted facility manual, design documentation, test plan. For B or higher, additional documentations are needed, e.g., covert channel analysis, formal model, etc.
  • Design analysis phase (DAP)
    • Initial product assessment report (IPAR): 100-200 pages, detailed info about the hardware, software architecture, security relevant features, team assessments, etc.
    • Technical Review Board
    • Recommendation to the NCSC
evaluation process1
Evaluation Process
  • Formal evaluation phase (FEP)
    • Product Bulletin: formal and public announcement
    • Final Evaluation Report: information from IPAR and testing results, additional tests, review code (B2 and up), formal policy model, proof.
    • Recommends rating for the system
    • NCSC decides final rating
  • Rating maintenance phase (RAMP)
    • Minor changes and revisions
    • Reevaluated
    • Rating maintenance plan
european criteria
European Criteria
  • German Information Security Agency: German Green Book (1988)
  • British Department of Trade and Industry and Ministry of Defense: several volumes of criteria
  • Canada, Australia, France: works on evaluation criteria
  • 1991: Information Technology Security Evaluation Criteria (ITSEC)
    • For European community
    • Decoupled features from assurance
    • Introduced new functionality requirement classes
    • Accommodated commercial security requirements
common criteria
Common Criteria
  • January 1996: Common Criteria
    • Joint work with Canada and Europe
    • Separates functionality from assurance
    • Nine classes of functionality: audit, communications, user data protection, identification and authentication, privacy, protection of trusted functions, resource utilization, establishing user sessions, and trusted path.
    • Seven classes of assurance: configuration management, delivery and operation, development, guidance documents, life cycle support, tests, and vulnerability assessment.
common criteria1
Common Criteria
  • Evaluation Assurance Levels (EAL)
    • EAL1: functionally tested
    • EAL2: structurally tested
    • EAL3: methodologically tested and checked
    • EAL4: methodologically designed, tested and reviewed
    • EAL5: semi-formally designed and tested
    • EAL6: semi-formally verified and tested
    • EAL7: formally verified design and tested
national information assurance partnership niap
National Information Assurance Partnership (NIAP)
  • 1997: National Institute of Standards and Technology (NIST), National Security Agency (NSA), and Industry
  • Aims to improve the efficiency of evaluation
  • Transfer methodologies and techniques to private sector laboratories
  • Functions: developing tests, test methods, tools for evaluating and improving security products, developing protection profiles and associated tests, establish formal and international schema for CC
next class
Next Class
  • Software Development Lifecycle