CIS 4615 meeting -*- Outline -*-

* Security Requirements Specification in the Common Criteria

   From www.commoncriteriaportal.org

** Protection Profiles
------------------------------------------
           PROTECTION PROFILE (PP)

Describe a type of TOE
   E.g., firewalls

Acts as a contract between consumers
  and developers

 Steps:

1. Consumer writes PP

   IT Necurity Needs      -->  PP
   (Threat Model's SFRs)

2. Consumer checks PP for consistency
   and completeness against SFRs

3. Developer writes Security Target (ST)

   PP   -->    ST

4. Developer checks that ST refines the PP

5. Developer builds a system,
   satisfying the ST

   ST    -->   System
------------------------------------------
        TOE is generic, a firewall as opposed to a Citrix firewall 80e

        Q: What is consistency?  
        Q: What is Completeness?

        Q: What is a refinement?
        Refinement means any system satisfying the ST will satisfy the
        SFRs (and assurrance requirments) in the PP.

        Q: What is meant by satisfction?
        That all the requirements are fulfilled (in the way stated).

        Q: So, if you need a system satisfying the TOE, can you use
        the developer's system?
        Yes, refinement and satisfaction are transitive.
        
------------------------------------------
        PROTECTION PROFILE OUTLINE

 I. Introduction, 
   A. Reference (title, authors, date)
   B. TOE overview
     1. Usage and Major Security Features
     2. TOE Type (name)
     3. Available software/hardware/firmware
        to be used as a basis
 II. Conformance claims (to other PPs...)
 III. Security Problem Definition
   A. Threats
   B. OSPs = security rules, procedures, 
             guidelines for operation
   C. Assumptions
 IV. Security Objectives
   A. Security Objectives
      for the TOE
   B. Security Objectives 
      for the Operational Environment
   C. Security Objectives Rationale
 V. Extended Components Definition
    (not described in CC Parts 2 or 3)
 VI. Security Requirements
   A. Security Functional Requirements
   B. Security Assurance Requirements
   C. Security Requirements Rationale
      
------------------------------------------
    OSP = organizational secruity policy

    notes:
      - should be given at high level of abstraction
        not detailed protocols or algorithms
      - only concerned with security, not functional requirements
      - not for a single product

** CC Part 2, Security Functional Requirements
*** terms
------------------------------------------
         CC PART 2 TERMINOLOGY

def: a *subject* is



def: an *object* is



def: *user data* is



def: *TSF data* is 



   - Authentication data
   - User attributes
   - Object attributes
   - Subject attributes
   - Information attributes

------------------------------------------
    ... an active entity, such as a process

    ... a passive entity, such as a file

    ... information that the TOE does not rely on for its security
    functions

    ... data that the TOE relies on for its security functions.

*** classes of security functional requirements
**** FAU audit requirements
------------------------------------------
 AUDIT REQUIREMENTS (FAU) FROM CC PART 2

Security Alarms

FAU_ARP.1.1 The TSF shall take
  [assignment: list of actions] 
  upon detection of a potential security
  violation.

Security Audit Data Generation

FAU_GEN.1.2 The TSF shall record within
each audit record at least the following
information:
a) Date and time of the event, 
   type of event, subject identity 
   (if applicable), and the outcome
   (success or failure) of the event; and
b) For each audit event type, 
   based on the auditable event definitions
   of the functional components included
   in the PP/ST,
   [assignment: other audit relevant
    information].

FAU_GEN.2.1 For audit events resulting 
from actions of identified users, 
the TSF shall be able to associate 
each auditable event with the identity 
of the user that caused the event.

------------------------------------------
    Q: Is any of that ambiguous?
     What does "success or failure" mean?

------------------------------------------
   OTHER REQUIREMENTS IN CC PART 2

Auditing (FAU)
  Security Audit Analysis
  Anomoly Detection
  Simple Attack Heuristics
  Complex Attack Heuristics
  Audit Review
  Audit Selection
  Audit Event Storage

Communication (FCO)
  Non-repudiation of Origin
  Non-repudiation of Receipt

Cryptographic Support (FCS)
  Cryptographic Key Management
  Cryptographic Operation

User Data Protection (FDP)
  Access Control Policy
  Access Control Functions
  Data Authentication

   FDP_DAU.1.1 The TSF shall provide a 
   capability to generate evidence that 
   can be used as a guarantee of the 
   validity of [assignment: list of objects 
   or information types].

   FDP_DAU.1.2 The TSF shall provide 
   [assignment: list of subjects] with 
   the ability to verify evidence of the 
   validity of the indicated information.

  ...
  Information Flow Control Policy
  Rollback
  Stored Data Integrity

------------------------------------------

------------------------------------------
   MORE REQUIREMENTS IN CC PART 2

Identification and Authentication (FIA)
  ...

Security Management (FMT)
  ...

Privacy (FPR)
  Anonymity
  Psuedonymity
  Unlinkability
  Unobservability

Protection of the TSF (FPT)
  ...

Resource Utilization (FRU)
  ...

TOE Access (FTA)
  ...

Trusted Paths/Channels (FTP)
  ...


------------------------------------------