Development Process Assurance

	Role of Development Process Assurance
	Development Process Assurance in the CC
		Class ACM – Configuration Management
		Class ALC – Lifecycle Support
		Class AMA – Maintenance of Assurance

Role of Development Process Assurance

	Evidence is produced in the context of a development process
	The development process can limit the:
		Quality of the evidence
		Trustworthiness of the evidence
		Future reusability of the evidence

Development Process Assurance in the CC

	CC institutionalizes Development Process Assurance through 3 Assurance Classes containing 11 Assurance Families
		Configuration Management (ACM)
			Automation, Capabilities, Scope
		Life Cycle Support (ALC)
			Development Security, Flaw Remediation, Life Cycle Definition, Tools and Techniques
		Maintenance of Assurance (AMA)
			Assurance Maintenance Plan, Component Categorization Report, Evidence of Assurance Maintenance, Security Impact Analysis

Configuration Management (ACM)

	Goal of CM is to impose discipline and control on the processes for refining and modifying the TOE and its evidence
	The three Families in the Class are:
		Configuration Management Automation (ACM_AUT)
		Configuration Management Capabilities (ACM_CAP)
		Configuration Management Scope (ACM_SCP)

Configuration Management Automation

	Focus is on increasing the effectiveness of the CM process
		Premise is that automated systems are less susceptible to human error or negligence
	Two Components, levelled on how much of TOE is subject to automated CM
		Partial CM Automation
		Complete CM Automation

Partial CM Automation

	The developer shall use a CM system.
		provides automated means by which only authorised changes are made to the TOE implementation representation.
		provides an automated means to support the generation of the TOE.
	The developer shall provide a CM plan.
		Describe the automated tools used in the CM system and how they are used.

Complete CM Automation

	The developer shall use a CM system.
		provides automated means by which only authorised changes are made to the TOE implementation representation, and to all other configuration items.
		provides an automated means to support the generation of the TOE.
		provides an automated means to ascertain the changes between the TOE and its preceding version.
		provides an automated means to identify all other configuration items that are affected by the modification of a given configuration item.
	The developer shall provide a CM plan.
		Describe the automated tools used in the CM system and how they are used.

Configuration Management Capabilities

	Goals of CM capabilities are to:
		ensure that the TOE is correct and complete before it is sent to the consumer;
		ensure that no configuration items are missed during evaluation;
		prevent unauthorised modification, addition, or deletion of TOE configuration items
	Five Components, levelled on capabilities, scope of CM documentation, and presence of developer justification that CM system meets its security requirements
		Version Numbers
		Configuration Items
		Authorization Controls
		Generation Support and Acceptance Procedures
		Advanced Support

Version Numbers

	The developer shall provide a reference for the TOE.
		Unique TOE reference for each TOE version
		TOE shall be labelled with its reference.

Configuration Items

	Developer shall use a CM system
		Shall uniquely identify all configuration items.
	Developer shall provide CM documentation.
		Shall include a configuration list that describes the configuration items that comprise the TOE
		Shall describe the method used to uniquely identify the configuration items

Authorization Controls

	Developer shall use a CM system
		shall provide measures such that only authorised changes are made to the configuration items
	Developer shall provide CM documentation
		Shall include a CM Plan that describes how the CM system is used
		Shall include evidence that all configuration items have been and are being effectively maintained under the CM system and that demonstrates that the CM system is operating in accordance with the CM plan.

Generation Support and Acceptance

	Developer shall use a CM system
		Shall support generation of the TOE
	Developer shall provide CM documentation
		(In addition to configuration list and CM Plan) shall include an acceptance plan that describes the procedures used to accept modified or newly created configuration items as part of the TOE.

Advanced Support

	Developer shall use a CM system
		That shall require that the person responsible for accepting a configuration item into CM is not the person who developed it.
		That shall clearly identify the configuration items comprising TSF.
		That shall support the audit of all modifications to the TOE, including as a minimum the originator, date, and time in the audit trail.
		That shall be able to identify the master copy of all material used to generate the TOE.
	Developer shall provide CM documentation (that)
		(In addition to configuration list, CM Plan, and acceptance plan) shall include integration procedures describing how the CM system is applied in the TOE manufacturing process
		Shall demonstrate that
			use of the CM system, together with the development security measures, allow only authorised changes to be made to the TOE
			use of the integration procedures ensures that the generation of the TOE is correctly performed in an authorised manner
			CM system is sufficient to ensure that the person responsible for accepting a configuration item into CM is not the person who developed it.
		Shall justify that the acceptance procedures provide for an adequate and appropriate review of changes to all configuration items.

Configuration Management Scope

	Goal of CM Scope is to:
		ensure that the TOE implementation representation is tracked;
		ensure that all necessary documentation, including problem reports, are tracked during development and operation;
		ensure that configuration options (e.g. compiler switches) are tracked; and
		ensure that development tools are tracked.
	Three Components, levelled on the basis of what information is beingtracked by the CM system
		TOE CM Coverage
		Problem Tracking CM Coverage
		Development Tools CM Coverage

TOE CM Coverage

	Developer shall provide CM documentation that shall:
		show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation
		describe how configuration items are tracked by the CM system

Problem Tracking CM Coverage

	Developer shall provide CM documentation that shall:
		show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation, and security flaws
		describe how configuration items are tracked by the CM system

Development Tools CM Coverage

	Developer shall provide CM documentation that shall:
		show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation security flaws, and development tools and related information
		describe how configuration items are tracked by the CM system

Life Cycle Support (ALC)

	Goal of life cycle support is to integrate and formalize security engineering and evidence production into the development process
	The four Families in the Class are:
		Development Security (ALC_DVS)
		Flaw Remediation (ALC_FLR)
		Life Cycle Definition (ALC_LCD)
		Tools and Techniques (ALC_TAT)

Development Security

	Goal of Development Security is to establish measures to remove or reduce threats that might exist at the developer’s site
	Two Components, levelled on the basis of justification for sufficiency of security measures
		Identification of Security Measures
		Sufficiency of Security Measures

Identification of Security Measures

	The developer shall produce development security documentation that shall
		describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment
		provide evidence that these security measures are followed during the development and maintenance of the TOE

Sufficiency of Security Measures

	The developer shall produce development security documentation that shall
		describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment
		provide evidence that these security measures are followed during the development and maintenance of the TOE
			the evidence shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE

Flaw Remediation

	Goal of Flaw Remediation is to:
		Ensure future maintenance and support for the TOE
		Track, correct, and distribute flaw corrections
	Three Components, levelled on the increasing extent in scope of the flaw remediation procedures and the rigour of the flaw remediation policies
		Basic Flaw Remediation
		Flaw Reporting Procedures
		Systematic Flaw Remediation

Basic Flaw Remediation

	The developer shall document the flaw remediation procedures (in a way that shall):
		describe the procedures used to track all reported security flaws in each release of the TOE
		require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw
		require that corrective actions be identified for each of the security flaws
		describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users

Flaw Reporting Procedures

	The developer shall establish a procedure for accepting and acting upon user reports of security flaws and requests for corrections to those flaws (in a way that shall):
		ensure that any reported flaws are corrected and the correction issued to TOE users
		provide safeguards that any corrections to these security flaws do not introduce any new flaws

Systematic Flaw Remediation

	The developer shall document the flaw remediation procedures (in a way that shall):
		require timely responses for the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw
	The developer shall designate one or more specific points of contact for user reports and inquiries about security issues involving the TOE

Life Cycle Definition

	Goal of Life Cycle Definition is to provide effective (management) control over the system engineering process used to develop the TOE
	Three Components, levelled on the basis of increasing requirements for standardisation and measurability of the life-cycle model, and for compliance with that model
		Developer Defined Life-cycle Model
		Standardized Life-cycle Model
		Measurable Life-cycle Model

Developer Defined Life-cycle Model

	The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE (that shall):
		provide for the necessary control over the development and maintenance of the TOE
	The developer shall provide life-cycle definition documentation (that shall):
		describe the model used to develop and maintain the TOE

Standardized Life-cycle Model

	The developer shall use a standardised life-cycle model to develop and maintain the TOE
	The developer shall provide life-cycle definition documentation (that shall):
		explain why the model was chosen
		explain how the model is used to develop and maintain the TOE
		demonstrate compliance with the standardised life-cycle model

Measurable Life-cycle Model

	The developer shall use a standardised and measurable life-cycle model to develop and maintain the TOE
	The developer shall measure the TOE development using the standardised and measurable life-cycle model
	The developer shall provide life-cycle definition documentation (that shall):
		describe the model used to develop and maintain the TOE, including the details of its arithmetic parameters and/or metrics used to measure the TOE development against the model
		demonstrate compliance with the standardised and measurable life-cycle model
		provide the results of the measurements of the TOE development using the standardised and measurable life-cycle model

Tools and Techniques

	Goal of Tools and Techniques is to prevent ill-defined, inconsistent or incorrect development tools from being used to develop the TOE
	Three Components, levelled on the basis of increasing requirements on the description and scope of the implementation standards and the documentation of implementation-dependent options
		Well-Defined Development Tools
		Compliance With Implementation Standards
		Compliance With Implementation Standards – All Parts

Well-Defined Development Tools

	The developer shall identify the development tools being used for the TOE
		All development tools used for implementation shall be well-defined
	The developer shall document the selected implementation-dependent options of the development tools
		(This documentation) shall unambiguously define the meaning of all statements used in the implementation
		(This documentation) shall unambiguously define the meaning of all implementation-dependent options

Compliance With Implementation Standards

	The developer shall describe the implementation standards to be applied
		At this level, the accountability is only for the implementation representations that the developer is actually developing

Compliance With Implementation Standards – All Parts

	The developer shall describe the implementation standards for all parts of the TOE
		At this level, the accountability is extended to the implementation representations that are automatically incorporated by the tools that the developer is using (e.g., runtime libraries)

Maintenance of Assurance (AMA)

	Goal of Assurance Maintenance is to ensure that an evaluated and certified TOE still meets its ST requirements as the TOE or its environment changes
	The four Families in the Class are:
		Assurance Maintenance Plan (AMA_AMP)
		TOE Component Categorization Report (AMA_CAT)
		Evidence of Assurance Maintenance (AMA_EVD)
		Security Impact Analysis (AMA_SIA)

Assurance Maintenance Plan

	Goal of the Assurance Maintenance Plan is to identify the plans and procedures a developer must implement in order to ensure that the assurance that was established in the certified TOE is maintained as changes are made to the TOE or its environment.
		The AM Plan is specific to the TOE, and is tailored to the developer's own practices and procedures
	One Component
		Assurance Maintenance Plan

Assurance Maintenance Plan

	The developer shall provide an AM Plan (that shall)
		contain or reference a brief description of the TOE, including the security functionality it provides
		identify the certified version of the TOE, and shall reference the evaluation results
		reference the TOE component categorisation report for the certified version of the TOE
		define the scope of changes to the TOE that are covered by the plan
		describe the TOE life-cycle, and shall identify the current plans for any new releases of the TOE, together with a brief description of any planned changes that are likely to have a significant security impact
		describe the assurance maintenance cycle, stating and justifying the planned schedule of AM audits and the target date of the next re-evaluation of the TOE

Assurance Maintenance Plan (cont)

	The developer shall provide an AM Plan (that shall)
		identify the individual(s) who will assume the role of developer security analyst for the TOE
		describe how the developer security analyst role will ensure that the procedures documented or referenced in the AM Plan are followed
		describe how the developer security analyst role will ensure that all developer actions involved in the analysis of the security impact of changes affecting the TOE are performed correctly
		justify why the identified developer security analyst(s) have sufficient familiarity with the security target, functional specification and (where appropriate) high-level design of the TOE, and with the evaluation results and all applicable assurance requirements for the certified version of the TOE
		describe or reference the procedures to be applied to maintain the assurance in the TOE, which as a minimum shall include the procedures for configuration management, maintenance of assurance evidence, performance of the analysis of the security impact of changes affecting the TOE, and flaw remediation

TOE Component Categorization Report

	Goal of the TOE Component Categorization Report is to complement the AM Plan by providing a categorisation of the components of a TOE (e.g. TSF subsystems) according to their relevance to security
		This categorisation acts as a focus for the developer's security impact analysis, and also for the subsequent re-evaluation of the TOE
	One Component
		TOE Component Categorization Report

TOE Component Categorization Report

	The developer shall provide a TOE component categorisation report for the certified version of the TOE (that shall):
		categorise each component of the TOE,
			in each TSF representation from the most abstract to the least abstract
			according to security relevance– at least categorised as either TSP-enforcing or non-TSP-enforcing
		describe the categorisation scheme used,
			Know how to categorise new components
			Know when to re-categorise existing TOE components following changes to the TOE or its security target
		identify any tools used in the development environment that, if modified, will have an impact on the assurance that the TOE satisfies its security target

Evidence of Assurance Maintenance

	Goal of Evidence of Assurance Maintenance is to establish confidence that the assurance in the TOE is being maintained by the developer, in accordance with the AM Plan
		Developer produces evidence of security analysis and security process conformance
		Evaluator audits evidence (to keep developer honest)
	One Component
		Evidence of Maintenance Process

Evidence of Maintenance Process

	The developer security analyst shall provide AM documentation for the current version of the TOE (that shall):
		include a configuration list and a list of identified vulnerabilities in the TOE
			The list of identified vulnerabilities in the current version of the TOE shall show, for each vulnerability, that the vulnerability cannot be exploited in the intended environment for the TOE
		describe the configuration items that comprise the current version of the TOE
		provide evidence that the procedures documented or referenced in the AM Plan are being followed

Security Impact Analysis

	Goal of Security Impact Analysis is to provide confidence that assurance has been maintained in the TOE
		Relies on a developer analysis of the security impact of all changes affecting the TOE since it was certified
	Two Components, levelled according to the degree to which an evaluator validates the developer's security impact analysis
		Sampling of Security Impact Analysis
		Examination of Security Impact Analysis

Sampling of Security Impact Analysis

	The developer security analyst shall, for the current version of the TOE, provide a security impact analysis that covers all changes affecting the TOE as compared with the certified version (which shall):
		identify the certified TOE from which the current version of the TOE was derived
		identify all new and modified TOE components that are categorised as TSP-enforcing
		for each change affecting the security target or TSF representations
			briefly describe the change and any effects it has on lower representation levels
			identify all IT security functions and all TOE components categorised as TSP-enforcing that are affected by the change

Sampling of Security Impact Analysis

		for each change which results in a modification of the implementation representation of the TSF or the IT environment, identify the test evidence that shows, to the required level of assurance, that the TSF continues to be correctly implemented following the change
		for each applicable assurance requirement in the configuration management (Class ACM Configuration management), life cycle support (Class ALC Life cycle support), delivery and operation (Class ADO Delivery and operation) and guidance documents (Class AGD Guidance documents) assurance classes, identify any evaluation deliverables that have changed, and provide a brief description of each change and its impact on assurance
		for each applicable assurance requirement in the vulnerability assessment (Class AVA Vulnerability assessment) assurance class, identify which evaluation deliverables have changed and which have not, and give reasons for the decision taken as to whether or not to update the deliverable

Examination of Security Impact Analysis

	No additional developer requirements
	Evaluator is required to do a complete check of the security impact analysis documentation to verify that all changes to the TOE have been analyzed and the conclusions documented