PP Workshop at RSA

How to Write a (Good) Protection Profile:

© atsec information security, 2011 How to Write a (Good) Protection Profile Suggested Methods and Strategies

Content:

© atsec information security, 2011 2 Content What to expect A short history of PPs Outline of PP development – the 5 main steps Details of PP development Product type characterization Definition of the intended environment Derivation of the security functionality Assurance components Using the flexibility of the CC Partial instantiations Conditional and optional requirements Refinements of functional and assurance requirements

History of PPs:

© atsec information security, 2011 3 History of PPs How it started At first there were “Functionality Classes” Invented in the German Criteria (1989) Defined “packages” of functionality for defined product types Did not address assurance requirements It was assumed that they were defined independently Did not address threats, assumptions, and objectives This was left to the “Security Requirements document” No predefined SFR structure Just a list of generic security functionality as guidance Taken one-to-one into the ITSEC (1991)

History of PPs:

© atsec information security, 2011 4 History of PPs The US Federal Criteria (December 1992) Introduced the concept of “Protection Profiles” Extended the concept of functionality classes to include Assumptions, threats, objectives, operational environment Security functional requirements and security assurance requirements Was significantly more elaborate on the purpose and development of Protection Profiles than the CC Concept was taken into the CC, but some details and justifications got lost

History of PPs:

© atsec information security, 2011 5 History of PPs PP structure in the Federal Criteria Descriptive Elements Rationale Functional Requirements Development Assurance Requirements Evaluation Assurance Requirements

PP Structure in the Federal Criteria:

© atsec information security, 2011 6 PP Structure in the Federal Criteria

PP Development in the Federal Criteria:

© atsec information security, 2011 7 PP Development in the Federal Criteria

Federal Criteria and Protection Profiles :

© atsec information security, 2011 8 Federal Criteria and Protection Profiles Learning from History Protection Profile concepts were well elaborated already in 1992 It was a natural extension of the concept of “functionality classes” Experience with them showed that more guidance was required and more information should be provided The Common Criteria did not take this further or even keep the level of detail Should have looked more into what already existed

Protection Profile - Purpose:

© atsec information security, 2011 9 Protection Profile - Purpose What the CC state A Protection Profile is: an implementation-independent statement of security needs for a TOE type (Definition in part 1 of the CC) The CC gives consumers, especially in consumer groups and communities of interest, an implementation-independent structure, termed the Protection Profile (PP), in which to express their security requirements in an unambiguous manner. Whereas an ST always describes a specific TOE, a PP is intended to describe a TOE type. The same PP may therefore be used as a template for many different STs to be used in different evaluations.

Protection Profiles - Purpose:

© atsec information security, 2011 10 Protection Profiles - Purpose Text from the CC A PP describes the general requirements for a TOE type, and is therefore typically written by: A user community seeking to come to a consensus on the requirements for a given TOE type A developer of a TOE, or a group of developers of similar TOEs wishing to establish a minimum baseline for that type of TOE A government or large corporation specifying its requirements as part of its acquisition process A combination of all 3 groups would be even better!

Protection Profile – Content:

© atsec information security, 2011 11 Protection Profile – Content Mandatory Content A PP introduction containing a narrative description of the TOE type A security problem definition, showing threats, Organizational Security Policies and assumptions Security objectives, showing how the solution to the security problem is divided between security objectives for the TOE and security objectives for the operational environment of the TOE Security requirements (functional and assurance) Those are the mandatory parts, not necessarily sufficient to understand and use the PP!

A Disclaimer:

© atsec information security, 2011 12 A Disclaimer Scheme Specifics This presentation deliberately does not deal with any scheme specific policies, guidance, or criteria interpretations. Many CC schemes have such policies, guidance and interpretations. They often apply for evaluations rather than Protection Profiles, but some policies and interpretations related to the use of components of parts 2 and 3 of the CC also apply for Protection Profiles. We will point out in the presentation where the PP developer should seek guidance from the scheme he wants to have his PP evaluated in and/or accepted by.

Purpose of this Workshop:

© atsec information security, 2011 13 Purpose of this Workshop How to write useful Protection Profiles How to define and describe the product type How to define and describe the security problem the type of products are intended to solve How to the most restrictive intended environment Any product is allowed to provide more security allowing it to be operated in a less restrictive environment How to define the minimum security functionality Allowing for more security functionality Allowing for sufficient flexibility to not prohibit innovation How to provide guidance for developers, ST authors, and evaluators Many existing PPs don’t use the flexibility of the PP framework!

Workshop Goals:

© atsec information security, 2011 14 Workshop Goals PP Development Strategy How to write a readable and useful PP introduction How to develop the “Security Problem Definition” and the Security Objectives In a systematic way In a readable and useful form Using the CC formalities at the end How to derive the Security Functional Requirements Not looking into CC part 2 until required With guidance for ST authors and developers How to derive Security Assurance Requirements

Writing a PP – How to Start:

© atsec information security, 2011 15 Writing a PP – How to Start General Rules Rule Number 1: Don’t look into the Common Criteria until it is necessary! Rule Number 2: Know what you want to target! Rule Number 3: Know what you do not want to target! Rule Number 4: Abstract from existing implementations! Rule Number 5: Document all your thoughts in the PP!

Writing a PP – How to Start:

© atsec information security, 2011 16 Writing a PP – How to Start First Step Identify the target product type Just roughly, refinements are done later in the process Identify the stakeholders for the PP Vendors, users, others Identify potential overlap with existing PPs If there is, decide how do you want to address this If there is, decide if a new PP is needed Characterize the security functionality Just roughly, refinements are done later in the process

Writing a PP – How to Start:

© atsec information security, 2011 17 Writing a PP – How to Start Second Step Build a community including: Different vendors of the product type They need to describe what they have Different users of the product type They need to describe what they want / need Evaluation facilities They should help to shape the PP Certification bodies They should ensure CB acceptance and mutual recognition

Writing a PP – How to Start:

© atsec information security, 2011 18 Writing a PP – How to Start Third Step Refine the initial ideas from step 1: Characterize the product type more precisely Identify the intended operational environment Identify the security objectives Refine the required security functionality Do all this without looking into the CC!

Writing a PP – How to Start:

© atsec information security, 2011 19 Writing a PP – How to Start Fourth Step Develop an informal abstract model of the product type What are the mandatory security functions What are optional security functions (those that the PP is supposed to address somehow) What are the compliance requirements to security standards Examples are standards for cryptographic protocols, cryptographic algorithms, other security related protocols What are the users/systems that need to be authenticated What is subject to access control How is the security functionality managed Identify the product type specific assurance requirements

Writing a PP – How to Start:

© atsec information security, 2011 20 Writing a PP – How to Start Fifth Step Transform the results of the previous steps into the structure required by the Common Criteria Don’t do this until you have agreed on the intended environment, the required security functionality, and until the functional model has been developed! Refine the general model while doing this There will always be questions that come up during this last phase Return to previous steps (step 3) when considered necessary Put the result out for wider review Finalize the PP

Writing a PP – An iterative Process:

© atsec information security, 2011 21 Writing a PP – An iterative Process Getting closer to the End PP Development is an iterative process Don’t think you can do it top down! When you have a “stable” functional model you will need to check the “security problem definition” again for completeness and consistency For sure you will identify additional assumptions and refine the threats and objectives As a result you most likely will need to modify the functional model … and then get back to the “security problem definition”

Writing a PP – An iterative Process:

© atsec information security, 2011 22 Writing a PP – An iterative Process When to Stop Don’t be afraid of perfection! You will never reach it! Salvadore Dali Decide yourself when to stop the iterations Get the PP evaluated Which usually will result in modifications Set up a process to obtain feedback from users of the PP Keep the development community alive to decide when an update is needed

Details of PP Development:

© atsec information security, 2011 23 Details of PP Development From Theory to Practice Now we discuss the PP sections and how to develop their content Always keep in mind that this is an iterative process We will not discuss this further Keep in mind that all the PP sections are closely interrelated Making (and keeping) them consistent is not easy If you think your PP needs additional sections Write them down and put them into the PP!!!

PP Introduction:

© atsec information security, 2011 24 PP Introduction Purpose of the Protection Profile Identify the type of product: Its purpose Its intended (most restrictive) operational environment Its (generic) overall functionality Its mandatory security functionality In natural language As precise as possible As open as possible Not mandating specific architectures or mechanisms unless there is a reason to mandate them Its specific assurance requirements

PP Introduction:

© atsec information security, 2011 25 PP Introduction How to define the Product Type Clearly characterize The product type What is this product for Common architectures (as covered by the PP) The intended operational environment(s) Yes there may be multiple! The minimum security functionality expected Make it clear that this is a minimum – every vendor is allowed to do better! Point to the sections of the introduction where more detailed information is provided

Product Type Characterization:

© atsec information security, 2011 26 Product Type Characterization Example This Protection Profiles addresses firewall products intended to be operated as an appliance in a protected and well managed physical environment. The minimum security functionality a firewall compliant to this Protection Profile is required to implement is: Provision of at least three different physical network interfaces (one for the unprotected network, one for the protected network, one for a DMZ) IP filtering capabilities with definable filter rules (see section x1 for details) Application level filtering for dedicated application level protocols with adaptive filtering rules (see section x2 for details) Audit functionality (see section x3 for details of the events that need to be auditable and the audit configuration options required) Management functionality (see section x4 for details) Authentication of administrative personnel (see section x5 for details)

PP Introduction – Product Type Characterization:

© atsec information security, 2011 27 PP Introduction – Product Type Characterization General Rules Stay away from prescribing technical solutions Unless you really want to mandate them! Define the required security functional requirements In a first step in natural language Again, stay away from mandating specific technical solutions Instead, define requirements every technical solution needs to satisfy Define the intended operational environment Allowing for less restrictive environments if the product provides additional security functionality

PP Introduction:

© atsec information security, 2011 28 PP Introduction Security Functionality Describe the security functionality in natural language Keep in mind who the intended readers are: Vendors Users of the product Evaluators / Authors of Security Targets All of them can be assumed to already have a good technical understanding of the product type So, don’t be afraid to keep the description at a technical level Don’t try to give a beginner’s lecture on the product type!

PP Introduction:

© atsec information security, 2011 29 PP Introduction Security Functionality Stay away from specific technical solutions! Unless you really want them to be mandatory Characterize the architecture(s) allowed (or even mandated) Usually one should allow more than one overall architecture Differentiate between mandatory, conditional and optional functionality Keep the description of the security functionality at a requirements level Provide guidance for developers as well as ST authors where necessary

Security Functionality – A Bad Example:

© atsec information security, 2011 30 Security Functionality – A Bad Example User Authentication The product shall authenticate users using a combination of user-ID and password Passwords must be at least 16 characters long and must contain at least two digits, one special character and no character should appear more than 3 times in a password The product must enforce that passwords are changed every 4 weeks and the new password should not be identical to one used by the same user in the last year The product must lock the user account after 3 successive unsuccessful authentication attempts

Security Functionality – A Bad Example:

© atsec information security, 2011 31 Security Functionality – A Bad Example Why is this bad? It prescribes a specific technology (one that is known to be weak), prohibiting products that use a better technology It prescribes specific methods intended to improve the bad technology (ignoring that those “improvements” have their own problems) It demands a functionality that can be easily used to cause another security problem (denial of service) It is limited to human users (what about other systems?) Therefore the proposed “security functionality” may inacceptable for many operational environments!

Security Functionality – A Good Example:

© atsec information security, 2011 32 Security Functionality – A Good Example User Authentication The product shall authenticate administrative users using an authentication method which ensures: that the probability of correctly guessing or spoofing authentication information in the intended operational environment is less than 10 -8 that attempts to guess or spoof authentication information are detectable by an authorized administrator when more than 10 such attempts have been tried for the same user without there being a successful authentication for that user that the number of consecutive unsuccessful authentication attempts is limited to not more than 100 per minute Note to ST authors: Blocking a user account after a defined number (<100) of consecutive unsuccessful authentication attempts and generating an audit record satisfies the requirement above, but may be misused to cause denial of service.

Security Functionality – A Good Example:

© atsec information security, 2011 33 Security Functionality – A Good Example Why is this good? It defines the security requirements for authentication, not how to implement those requirements It leaves the freedom to the developer which authentication method(s) to use and how he satisfies the requirements It does not prescribe any specific aspect of the authentication functionality (other than the limitation of consecutive unsuccessful authentication attempts) It implicitly requires the developer to justify why his implementation satisfies the requirements The method used in the bad example would have a hard time to justify that they satisfy the requirements!

Security Functionality – A Good Example:

© atsec information security, 2011 34 Security Functionality – A Good Example “User” Authentication – Authenticating other Systems The product shall set up a trusted channel to all other external systems that are used to support the security functionality. Note that a trusted channel implies authentication of the communication partner. On untrusted networks the trusted channel shall be based on defined cryptographic standards like IPSec, SSH, or SSL/TLS. The support of TLS V1 is mandatory, support of other standards mentioned above is optional. If supported the options mentioned below need to be taken into account. The following versions of the standards and the following options shall be supported: IPSec ….. SSH …. TLS ….

Some Remarks on the Example (1):

© atsec information security, 2011 35 Some Remarks on the Example (1) What needs to be explained The CC views other IT systems also as “users” Make it clear that different authentication methods are required for different types of users The requirement is a “conditional requirement” of the type “If – then” If other systems are used to support the security functionality, then they need to be authenticated (and the communication with them needs to be over a secured channel) If SSH is supported as such an authentication method, then it needs to be in accordance with the following standard description and the following options…

Some Remarks on the Example (2):

© atsec information security, 2011 36 Some Remarks on the Example (2) Some further Explanations The requirement addresses all communication channels to other trusted IT systems Specific products may have more of those than the PP requires For example a specific product may make use of en external directory server If it does, the requirement demands that this connection is protected If the channel is dedicated and physically protected (e. g. a bus within a box in a physically protected environment), cryptographic protocols are not required

Generic Requirements versus Specific Security Functions:

© atsec information security, 2011 37 Generic Requirements versus Specific Security Functions Where to draw the line Stay generic where you do not need a specific functionality Define specific security functionality where you need it – but not more than you need Example: Compliance to specific functional standards like LDAP, TLS, IPSec, cryptographic algorithms Specific security functionality is mainly required for interoperability or compliance to specific policies But you should specify not more than what is actually required

The Security Problem Definition:

© atsec information security, 2011 38 The Security Problem Definition What is this? Just a specification what security problem the product type is intended to address Sounds simple, but actually isn’t The security problem should be defined without specific technical solutions in mind Even less than in the product type description Answer a set of simple questions: What are the threats the product type should counter? What kind and level of protection is required? What is expected from the environment? How is the product intended to be used?

The Security Problem Definition:

© atsec information security, 2011 39 The Security Problem Definition From the CC “The usefulness of the results of an evaluation strongly depends on the ST, and the usefulness of the ST strongly depends on the quality of the security problem definition. It is therefore often worthwhile to spend significant resources and use well-defined processes and analyses to derive a good security problem definition” This applies also and especially to Protection Profiles!

The Security Problem Definition:

© atsec information security, 2011 40 The Security Problem Definition What is a Threat? Bad example: The product should be protected form buffer overflows. Why is this bad? Because a buffer overflow is no threat – it is a potential vulnerability! Why is a buffer overflow (potentially) bad? Because it may lead to code infiltration or corruption of TSF or user data So, what is the threat? An attackers ability to corrupt TSF code, TSF data, or user data (regardless if one exploits a buffer overflow or another vulnerability)

The Security Problem Definition:

© atsec information security, 2011 41 The Security Problem Definition How to derive the Threats Imagine a product of the type described in the PP in its operational environment Perform a hypothetical assessment of the security risks Taking a catalog of defined risks as a basis is usually a good starting point Identify which (or which parts of them) should be addressed by the product and which by the environment Don’t define (yet) how the product should do this Identify (and describe) the expected “threat agents” In a generic way, refinements will be done later

The Security Problem Definition:

© atsec information security, 2011 42 The Security Problem Definition What is a Security Objective Description of a generic security goal for the product type Bad Example: (in a Firewall PP) The TOE shall prohibit any attack from an untrusted network Why is this bad? This is a nice wish, but not a traceable security objective Almost as bad as: “The TOE shall provide all the security I need” Good Example: (in a Firewall PP) The TOE shall filter the whole network traffic from an untrusted network in accordance with defined rules The TOE shall block network packets from the untrusted network that don’t comply with those rules

The Security Problem Definition:

© atsec information security, 2011 43 The Security Problem Definition How to derive Security Objectives This is often done by taking a threat and stating: “The product shall counter threat X” This is not very helpful Better: The product shall counter threat X / the following aspect of threat X by providing the following … This helps in two ways: Mapping the threats to security objectives Mapping the security objectives to security functionality

The Security Problem Definition:

© atsec information security, 2011 44 The Security Problem Definition Example: Firewall Generic threat: an attack from the untrusted network using network packets in a malicious way Security objective(s): detect (as far as possible) such an attack by inspecting network traffic and block the network packets related to an attack Audit attempted attacks (when detected) Raise an alarm if an attack was detected but some malicious packets have already passed the system Allow the product to be configured to detect (and prevent) new attacks

The Security Problem Definition:

© atsec information security, 2011 45 The Security Problem Definition Example: Operating System Threat: authorized users get access to data in way they are not authorized to Security Objectives: Data objects are protected from unauthorized access using a discretionary access control policy Management of access rights is restricted to authorized users

The Security Problem Definition:

© atsec information security, 2011 46 The Security Problem Definition Example: Operating System Threat: authorized users get access to data in way they are not authorized to Implied Security Objectives: Data is stored in data objects, and the protection is at this level Access rights need to be manageable by users specifically authorized to do so The product needs to ensure it knows who is attempting to access a data object or attempts to manage access rights

The Security Problem Definition:

© atsec information security, 2011 47 The Security Problem Definition Security Objectives versus Security Functionality As you have seen from the examples: There is no clear boundary “Security objectives” should be more general than “security functionality” This is definitively true for a Security Target, not necessarily for a Protection Profile Don’t care too much about the difference, just find your way to show a clear path from the threats to the security functionality defined in the PP

Security Problem Definition - Assumptions:

© atsec information security, 2011 48 Security Problem Definition - Assumptions How to derive Assumptions Think of threats the product type can not counter completely Consider the product type operating in a totally unprotected environment with potentially hostile users What needs to exist to have the product still providing security E. g. physically protected environment E. g. trusted administrators E. g. trusted systems in the environment providing specific supporting services

Security Problem Definition - Assumptions:

© atsec information security, 2011 49 Security Problem Definition - Assumptions How to derive Assumptions Don’t make “implicit assumptions” Like “it should be clear that this product type needs a physically protected environment” Justify your assumptions (and document the justification) This helps to understand why it was made This helps to derive potentially more specific assumptions in a Security Target This helps ST authors to identify additional security functionality in their product that allows to weaken an assumption

Security Problem Definition - Assumptions:

© atsec information security, 2011 50 Security Problem Definition - Assumptions Some Additional Remarks Assumptions need to be reasonable Assuming a smart card is always in a physically protected environment is not reasonable A Security Target author needs to explain if the assumptions can be weakened for his product It may be addressed by additional security functionality The CC “officially” does not allow a Security Target to make additional assumption This should apply for additional assumptions related to additional security functionality!

Security Problem Definition - Assumptions:

© atsec information security, 2011 51 Security Problem Definition - Assumptions Additional Assumptions in STs Example: A Security Target includes additional security functionality for data consistency in a distributed TSF not mentioned in the PP The Security Target makes the assumption that the inter-TSF network is protected by the TOE environment This should be allowed, provided the assumption is reasonable In some products the inter-TSF network for data consistency is normally within a physically protected environment and the performance requirements are too high to allow for encryption by the TSF

Security Functional Requirements:

© atsec information security, 2011 52 Security Functional Requirements How to Develop When following the previous steps you should have: A clear characterization of the product type An initial “security problem definition” with threats, assumptions, policies and security objectives Security objectives that are precise enough to start to develop a “functional model” Now you need to start this development The modeling technique will be product type specific Identifying a suitable modeling technique is crucial

Security Functional Model:

© atsec information security, 2011 53 Security Functional Model Modeling Techniques You may use more than one for your product type Example: Operating systems: Usually based on a user-subject-object-operation based model Users are “bound” to subjects Subjects perform operations on objects User/subject security attributes (and other TSF data) is used to decide allowance for operations Management aspects Subject/object life-cycle aspect (creation, deletion)

Security Functional Model:

© atsec information security, 2011 54 Security Functional Model Modeling Techniques Example: Firewall: Often based on a flow model: Data packet arrives at an interface Packet passes several steps in its flow through the product Steps include rules how to validate/modify/redirect the packet Potentially different model for management Privilege-operation type of model

Security Functional Model:

© atsec information security, 2011 55 Security Functional Model Purpose of the Security Functional Model Used to refine and validate the security functional requirements Used as a basis for discussion Models tend to get too specific after a while Good for the discussion and understanding, bad for a generic Protection Profile Try to abstract from details that are too specific Try to keep the details that everyone agrees upon

Security Functional Model:

© atsec information security, 2011 56 Security Functional Model Finalizing the Model At the end you should have a “stable” model (more or less in natural language), that is consistent with the “security problem definition” Write the model down in the PP! Now is the time to transform it into SFRs Now is the first time to look into part 2 of the CC Don’t do it before! Don’t even try to use part 2 in the derivation of the security objectives or the security functional model It was not designed for this

Transformation to SFRs:

© atsec information security, 2011 57 Transformation to SFRs How to Start Try to identify SFRs that may map to your model Try to express the functional model using SFRs You will identify: Model aspects that easily map to SFRs Model aspects that are hard to map to SFRs Model aspects that (in a first attempt) do not map to SFRs Aspects in SFRs that make you re-think aspects of your model For example dependencies mentioned in the CC For example details in SFRs you hadn’t considered in the model

Transformation to SFRs:

© atsec information security, 2011 58 Transformation to SFRs Next Steps Map those aspects that can be mapped easily Try to map those aspects that you identified harder to map using the flexibility defined in the CC Partial assignments Refinements Multiple instantiations Where this does not work to your satisfaction try: Conditional SFRs Extended functional packages Extended SFRs

Transformation to SFRs:

© atsec information security, 2011 59 Transformation to SFRs General Rules Try to define SFRs that are readable and understandable Keep the mapping to your functional model Don’t “bend” the CC to the extend that you stay within the SFRs defined in part 2 of the CC, but the result becomes incomprehensible Provide extensive explanations in form of Application Notes Don’t be afraid of extended SFRs when you think they help Extended SFRs usually don’t break mutual recognition

Playing with SFRs:

© atsec information security, 2011 60 Playing with SFRs Partial Assignment The problem: you want some freedom for ST authors in the assignment operation, but not the full freedom the CC allows The solution: Do a “partial assignment” that restricts the original assignment the way you want it to be restricted

Playing with SFRs:

© atsec information security, 2011 61 Playing with SFRs Partial Assignment Example: Original SFR from the CC: FDP_ACC.1.1 The TSF shall enforce the [assignment: access control SFP ] on [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP ]. Possible partial assignment: FDP_ACC.1.1 The TSF shall enforce the [assignment: access control SFP ] on processes acting on behalf of users [assignment: list of other subjects ], files [assignment: list of other objects ], and read, write [assignment: other operations among subjects and objects covered by the SFP ].

Playing with SFRs:

© atsec information security, 2011 62 Playing with SFRs Partial Assignment Explanation of the example: The PP may define processes as a mandatory type of subject, files as a mandatory type of object, read and write as mandatory operations The PP allows vendors to have additional subjects, objects and operations The PP wants those additional subjects, objects and operations to be regulated by the same access control policy This is what the example states

Playing with SFRs:

© atsec information security, 2011 63 Playing with SFRs Partial Assignment – Second Example Replacing an assignment by a selection Original SFR from the CC FDP_ITT.3.2 Upon detection of a data integrity error, the TSF shall [assignment: specify the action to be taken upon integrity error ]. Possible partial assignment: FDP_ITT.3.2 Upon detection of a data integrity error, the TSF shall [selection: discard the data and send an error message to the sender, request retransmission up to the defined threshold and discard the data if the integrity error persists, discard the data and use a defined default value ].

Playing with SFRs:

© atsec information security, 2011 64 Playing with SFRs Refinements Used to be more specific than the original SFR Example: Original SFR from the CC FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. Refinement: FPT_STM.1.1 The TSF shall be able to provide reliable time stamps with a resolution of at least one microsecond .

Playing with SFRs:

© atsec information security, 2011 65 Playing with SFRs Multiple Instantiations Often required when different types of users/subjects/objects are treated differently Example: Different access control policies Different methods of user authentication for different types of users Different default values for different types of TSF data Different tamper detection/resistance requirements for different parts of a distributed TSF

Stretching the Limits on SFR Use:

© atsec information security, 2011 66 Stretching the Limits on SFR Use Disclaimer Whenever aspects are presented that are not clearly within the boundary defined by the CC: get in touch with your certification body to ensure that they are accepted by your CB – and hopefully covered by mutual recognition! Aspects discussed under “Stretching the Limits of SFR Use” are among those

Stretching the Limits on SFR Use:

© atsec information security, 2011 67 Stretching the Limits on SFR Use Conditional Requirements The problem: You want to leave some freedom on how to address the security objectives This freedom has its limitations: If the developer chooses a specific way of addressing the security objectives, he needs to include specific additional security functionality Example: you allow the TSF to be distributed, but if it is, you require functions that ensure the consistency of specific TSF data among the distributed parts

Stretching the Limits on SFR Use:

© atsec information security, 2011 68 Stretching the Limits on SFR Use Conditional Requirements – Example If the TSF is distributed, the following additional security functional requirements need to be included in a ST: FPT_TDC.1 – Inter-TSF basic TSF data consistency FPT_ITT.1 – Basic internal TSF data transfer protection (of course both instantiated in a way as required by the product type)

Stretching the Limits on SFR Use:

© atsec information security, 2011 69 Stretching the Limits on SFR Use Extended Packages Idea first used in the BSI Operating System Protection Profile Extends the concept of “functional packages” as described in the CC Used to describe optional functionality in a PP Main extension is: extended packages come with a “security problem definition” explaining what security problem the package is intended to address Should be composable with the “base” PP and other extended packages

Extended Components:

© atsec information security, 2011 70 Extended Components When are they allowed to be used What the CC say: In the CC it is mandatory to base requirements on components from CC Part 2 or CC Part 3 with two exceptions: there are security objectives for the TOE that can not be translated to Part 2 SFRs, or there are third party requirements (e.g., laws, standards) that can not be translated to Part 3 SARs (e.g. regarding evaluation of cryptography); a security objective can be translated, but only with great difficulty and/or complexity based on components in CC Part 2 and/or CC Part 3.

Extended Components:

© atsec information security, 2011 71 Extended Components Addressing some Problem Areas in Part 2 Different SFR structure for protection of TSF data and user data But many product protect them using the same functions CC SFRs map management activities to roles But many products bind management activities to privileges, not roles You could define any possible combination of privileges as a “role”, but what if you have 100 privileges? Those are two areas where extended components may help

Extended Components:

© atsec information security, 2011 72 Extended Components Examples (for Slight Modifications) Examples addressing the TSF data / user data problem: FPT_ITT_EXT.1 The TSF shall protect TSF and user data from [selection: disclosure, modification ] when it is transmitted between separate parts of the TOE. FDP_SDI_EXT.2.1 The TSF shall monitor TSF and user data stored in containers controlled by the TSF for [assignment: integrity errors ] on all objects, based on the following attributes: [assignment: data attributes ]. FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment: action to be taken ].

Extended Components:

© atsec information security, 2011 73 Extended Components Examples (for different Paradigm) FMT_PRI_EXT.1 Security privileges FMT_PRI_EXT.1.1 The TSF shall maintain the following security privileges [assignment: list of privileges ]. FMT_PRI_EXT.1.2 The TSF shall be able to assign privileges to users in a controlled way. FMT_MTD_EXT.1 Privilege-based Management of TSF data FMT_MTD_EXT.1.1 The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [assignment: other operations] ] the [assignment: list of TSF data ] to users that hold the following privileges [assignment: privileges required to perform the operations mentioned before ].

Assurance Requirements:

© atsec information security, 2011 74 Assurance Requirements The most neglected Part of PPs Most PPs just define an Evaluation Assurance Level (potentially with extensions taken from part 3 of the CC) This is the safe way to not break mutual recognition As long as one stays within the limitations defined in the MRA Still: Refinements are allowed operations that do not directly break mutual recognition Nevertheless contact your Certification Body if you use refinements for assurance requirements

Assurance Requirements:

© atsec information security, 2011 75 Assurance Requirements Refinements Refinements allow to make more precise statements on how to address the general assurance requirements in the CC Refinements allow even to provide more evaluation guidance than defined in the CEM Refinements could be used for example To mandate product type specific design methods and documents To mandate product type specific testing methods and test details To mandate product type specific details in guidance documentation

Assurance Requirements:

© atsec information security, 2011 76 Assurance Requirements Refinements General Rules Do not specify refinements without providing guidance how to evaluate the refined assurance requirements Be careful to stay within the limits allowed for a refinement Otherwise you risk mutual recognition Be sure your PP development community agrees on the refinement This helps to defend it in case of disputes

Assurance Requirements:

© atsec information security, 2011 77 Assurance Requirements Extended Requirements General Rule: Stay away from them unless there is no other way! If you still think they are necessary: Submit the extended requirement via your certification body to the CCDB as a request for extension/modification of the CC Provide also the required changes/extensions to the CEM Chances to get accepted are small, but at least you have initiated a discussion Discuss the problem that have lead to the extended requirements with your certification body

PP Maintenance:

© atsec information security, 2011 78 PP Maintenance On the Path to Perfection Keep your development community alive! Set up a defined channel for feedback on the PP Set up a defined process to deal with feedback Have this process as open as possible Think of a strategy to bring the feedback into the PP Issuing “technical corrigenda” and additional PP guidance Issuing “PP interpretations” You can be sure some people will misunderstand your PP Have a time plan for a PP revision

PP Maintenance:

© atsec information security, 2011 79 PP Maintenance Interpretations People will misinterpret requirements in your PP Vendors that want to make their product “compliant” Evaluators/certifiers that were not part of the development Users that don’t comply with the intended environment and the assumptions Clarify this using published interpretations Discussed and agreed upon by the PP development forum Involve certification bodies for more complicated issues

Additional Resources:

© atsec information security, 2011 80 Additional Resources Further Reading Historic documents Criteria for the Evaluation of Trustworthiness of Information Technology (IT) Systems, ISBN 3-88784-200-6, German Information Security Agency, January 1989 Information Technology Security Evaluation Criteria ( ITSEC ), June 1991 FEDERAL CRITERIA for INFORMATION TECHNOLOGY SECURITY, VOLUME I - Protection Profile Development, Version 1.0, December 1992, NIST & NSA

Additional Resources:

© atsec information security, 2011 81 Additional Resources Further Reading Current documents Common Criteria for Information Technology Security Evaluation, Parts 1 to 3, Version 3.1 Revision 3, July 2009 ISO/IEC TR 15446: Information technology — Security techniques — Guide for the production of Protection Profiles and Security Targets, Second Edition 2009 The PP/ST Guide, Version 2 Revision 0, August 2010, Bundesamt fuer Sicherheit in der Informationstechnik (BSI)

Thank you:

© atsec information security, 2011 82 Thank you More information about Common Criteria available on the atsec website: http://www.atsec.com