Home

Welcome to Development Area for the Protection Profile for General-Purpose Operating Systems 4.0

This wiki exists to facilitate discussion of technical care-abouts for a Protection Profile about operating systems, which are captured in the ESR here:

• Essential Security Requirements document

A live rendering of the Protection Profile, hosted on OpenShift, is available in several forms:

• Traditional Form
• Traditional Form w/ Assurance Activities Expanded
• Inline Objective and Optional Requirements Form
• Tabular Form
• Simplified, Requirements-only Form (easiest for quick scoping)

It is updated every minute based on the most recent push to GitHub.

Previous documents are major inputs to this effort, and their content will be handled as outlined in the NIAP Way Ahead Statement on General-Purpose Operating Systems:

• Analysis of General Purpose Operating System Protection Profile 3.9
• Analysis of DISA OS Security Requirements Guide
  • Configurations for Standalone and Directory Bound Use Cases

The intent of this PP effort is to succeed these documents.

The applicability of policy documents is also considered:

• Applicability of NIST Special Publication 800-53
• Applicability of CNSS Instruction 1253

High-priority

Security functionality that actually has an impact on a system's resistance to attack, or resistance to malware persistence after an attack:

• Anti-exploitation features
  • ASLR
  • DEP (objective: enforced W^X)
  • SEHOP etc?
• Cryptographic services to applications
  • Crypto (investigate requirements of CESG PRIME, relationship to standards)
    • End State ::
    • Encryption AES-128 in GCM-128 (and optionally CBC*)
    • Pseudo-random function HMAC-SHA256-128
    • Diffie-Hellman group 256bit random ECP (RFC5903), Group 19
    • Authentication ECDSA-256 with SHA256 on P-256 curve
    • Interim State ::
    • Encryption AES128_ CBC
    • SHA-1
    • Diffie-Hellman group Group 5 (1536 bits)
  • credential storage - hardware backed (TPM1.2/2, TrustZone, Smart Cards?)
    • this relates to FIA_PK_EXT.1 Public key based authentication in GP OS 3.9
  • TLS client services
    • certificate path validation
• Trusted software update
  • for the OS itself
  • for applications (whose update is managed by the OS, which importantly enables software inventory)
  • Updates should be configurable to be non user controllable so they're force installed.
• Trusted/Secure Boot (What about Measured Boot?)
  • Should also warn the user if Secure Boot has not been enabled
• Trusted/Secure Load or Run (objective)
  • Verification of code in kernel modules, userspace before load/execution
  • Built in Anti-Malware checks?
  • PatchGuard like checks on files on disk?
  • Application Sandboxing to restrict application capability
• Data at rest - Data protection for when the device is powered down or hybernated
  • DAR could be extended to cover devices powered on but at the lock screen?
• Authentication - Mention something about access should only be granted if a valid access token is provided (This needs to cover access to device, access to services on that device, and device access to network)
• Application White listing
  • Ability for an administrator to specify allow (white) or block (black) lists for executable code on the device. Should cover path rules, hash rules, and signature rules to allow fine grain control of what can // cannot run.
  • Should be configurable per device or per user
  • Should also cover word writable locations in ostensibly non user controlled areas such as some paths in %windir% on Microsoft platforms
• Security policy enforcement
  • Security policies pushed from an Enterprise should be securely applied and not removable by the end user
  • Local firewall rules may be required to enforce specific behaviors (such as managed tunnels)
  • VPN should not be disableable by the user
  • Accounts should run at a low privileged level to ensure that policy can not be tampered with
• External interfaces
  • Ability to disable / enable interfaces that the Enterprise does not require
  • Fine grain control shouldn't be mandatory - "on/off" should be good enough for most enterprises
• Event collection / Auditing
  • The OS should generate logging events for critical security incidents. These logs must be able to be sent to a central logging system - local logs aren't that helpful.

Medium Priority

Security functionality that might sometimes have a security impact, but doesn't address the most serious threats. Common Criteria evaluation of these features might provide some value, and it's worth discussing whether it's worth codifying.

• Auditing
  • FAU_GEN.1, FAU_GEN.2, FAU_SAR.1, FAU_SAR.2, FAU_STG.1, FAU_STG.3, FAU_STG.4 will need to be rewritten in a far more compact form
  • many of the auditing requirements likely make sense to fold into FMT_SMF
• Behavior with removable media
• Remote Management Capabilities (optional)
  • this relates to FMT_SMF_RMT.1.1 Remote Management in GP OS 3.9
  • this currently is not distinguished between binding to directory services (which enables multi-user login) and acceptance into configuration requirements (perhaps by the user, e.g. in the MDM model).
  • for both management and binding to directory services, we are primarily seeking the ability of the system to connect (over a trusted channel) to a server which provides such services. This is how we can satisfy the password/account and settings management stuff that policy types believe is really important. The policies themselves should not be specified in this PP -- we should largely specify an optional requirement to perform such binding to a server which can perform the enforcement.
• Access Control
  • say something about world-writable files, or other obvious violations of the system's ability to protect itself
  • endless and awkward discussion of subjects/objects and access control policies provides little value

Low Priority

Security functionality that has a negligible security impact:

• Host-based firewall functionality
  • see FDP_IFC.1 Subset information flow control and FDP_IFF.1 Simple security attributes
  • testing may be called for, but only as part of FMT_SMF
• Extensive password requirements enforced by local system
  • password requirements are a responsibility for the directory server, if the system is bound to one for authentication. While some very basic password requirements may make sense, much of this is out of scope for endpoints and is instead appropriate for directory servers. This is where the threat of hash harvesting comes into play, which is what such requirements are designed to address.
• Reliable time stamps (FPT_STM.1)
  • This is not of any concern. Provision of time services can be an assumption.
• Residual Information Protection
  • Real-world, non-CC security testing will take care of this concern.
• Obscured feedback during authentication
  • This is not worth expressing, since every vendor does it.

Common Criteria evaluation of these features would provide little value.