PP-Module for Voice and Video over IP (VVoIP)

Version: 1.0
2015-08-14
National Information Assurance Partnership

Revision History

Contents

1 Overview

This is going to show some tests:

• Terms with abbrs like ASLR, or API, should be found a linked automatically.
• And components can be refered to by their name: FQQ_QQQ.1
• And so can requirements: FQQ_QQQ.1.1 or by their unique identifier: FQQ_QQQ.1.1
• Or you can stop them ASLR
• This is how you do a picture:
  

  Figure 1: Niap's Logo
• And this is how you reference it: Figure 1
• This is how you do an equation with an arbitrary counter:

  $$x=\frac{-b\pm\sqrt{b^{2}-4ac}}{2a}$$

  (1)

• And this is how you reference it: 1
• The following content should be included if:

  • "this" is selected from FQQ_QQQ.1.1

  Some text
• The following content should be included if:

  • the TOE implements "Widget Thing"

  Someting dependent on a feature
• And here's the audit event table for mandatory requirements.
  
• Test for an xref to section

1.1 Terms

1.1.1 Common Criteria Terms

1.1.2 Technical Terms

2 Compliant Targets of Evaluation

2.1 TOE Boundary

Figure 2: General TOE

2.2 TOE Platform

3 Use Cases

[USE CASE 1] Elephant-own device

This is everything we need to describe in words about this use case.

For a the list of appropriate selections and acceptable assignment values for this configuration, see .

This PP-Module inherits exact conformance as required from the specified Base-PPs and as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:

• PP-Module for MDM Agents, Version 1.0
• PP-Module for File Encryption Enterprise Management, Version 1.0
• PP-Module for File Encryption, Version 2.0

This PP-Module is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Revision 5 [CC] when App PP, GPOS PP, or MDF is the Base-PP.

This PP-Module is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5 [CC] when MDM PP is the Base-PP.

This PP-Module does not claim conformance to any Protection Profile.

This PP-Module does not claim conformance to any packages.

4 Threats

T.NETWORK_ATTACK

An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with applications and services running on or part of the OS with the intent of compromise. Engagement may consist of altering existing legitimate communications.

T.NETWORK_EAVESDROP

An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between applications and services that are running on or part of the OS.

T.LOCAL_ATTACK

An attacker may compromise applications running on the OS. The compromised application may provide maliciously formatted input to the OS through a variety of channels including unprivileged system calls and messaging via the file system.

T.LIMITED_PHYSICAL_ACCESS

An attacker may attempt to access data on the OS while having a limited amount of time with the physical device.

5 Assumptions

A.PLATFORM

The OS relies upon a trustworthy computing platform for its execution. This underlying platform is out of scope of this PP.

A.PROPER_USER

The user of the OS is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy. At the same time, malicious software could act as the user, so requirements which confine malicious subjects are still in scope.

A.PROPER_ADMIN

The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy.

6 Security Objectives for the TOE

O.ACCOUNTABILITY

Conformant OSes ensure that information exists that allows administrators to discover unintentional issues with the configuration and operation of the operating system and discover its cause. Gathering event information and immediately transmitting it to another system can also enable incident response in the event of system compromise.

O.INTEGRITY

Conformant OSes ensure the integrity of their update packages. OSes are seldom if ever shipped without errors, and the ability to deploy patches and updates with integrity is critical to enterprise network security. Conformant OSes provide execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems.

O.MANAGEMENT

To facilitate management by users and the enterprise, conformant OSes provide consistent and supported interfaces for their security-relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform-supported deployment mechanisms and formats, as well as providing mechanisms for configuration and application execution control.

O.PROTECTED_STORAGE

To address the issue of loss of confidentiality of credentials in the event of loss of physical control of the storage medium, conformant OSes provide data-at-rest protection for credentials. Conformant OSes also provide access controls which allow users to keep their files private from other users of the same system.

O.PROTECTED_COMMS

To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant OSes provide mechanisms to create trusted channels for CSP and sensitive data. Both CSP and sensitive data should not be exposed outside of the platform.

7 Security Objectives for the Operational Environment

OE.PLATFORM

The OS relies on being installed on trusted hardware.

OE.PROPER_USER

The user of the OS is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy. Standard user accounts are provisioned in accordance with the least privilege model. Users requiring higher levels of access should have a separate account dedicated for that use.

OE.PROPER_ADMIN

The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy.

7.1 Security Objectives Rationale

8 Security Requirements

• Refinement operation (denoted by bold text or strikethrough text): is used to add details to a requirement (including replacing an assignment with a more restrictive selection) or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
• Selection (denoted by italicized text): is used to select one or more options provided by the [CC] in stating a requirement.
• Assignment operation (denoted by italicized text): is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
• Iteration operation: is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

8.1 TOE Security Functional Requirements

8.2 TOE Security Functional Requirements Rationale

The following rationale provides justification for each security objective for the TOE, showing that the SFRs are suitable to meet and achieve the security objectives:

9 Consistency Rationale

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

This PP-Module does not define any Optional SFRs.

A.2 Objective Requirements

This PP-Module does not define any Objective SFRs.

A.3 Objective Requirements

This PP-Module does not define any Objective SFRs.

Appendix B - Selection-based SFRs

This PP-Module does not define any selection-based SFRs.

Appendix C - Extended Component Definitions

C.1 Background and Scope

C.2 Extended Component Definitions

Appendix D - Inherently Satisfied Requirements

Appendix E - References

Appendix F - Bibliography

Appendix G - Acronyms

Appendix H - Bibliography

Appendix I - Acronyms