-
Notifications
You must be signed in to change notification settings - Fork 6
Home
This wiki exists to facilitate discussion of technical care-abouts for a Protection Profile about operating systems. It will serve as the basis for an Essential Security Requirements document.
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 Requirements from General Purpose Operating System Protection Profile 3.9
- Analysis of requirements from DISA OS Security Requirements Guide.
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)
- Cryptographic services to applications
- credential storage
- this relates to FIA_PK_EXT.1 Public key based authentication in GP OS 3.9
- TLS client services
- certificate path validation
- credential storage
- Trusted software update
- for the OS itself
- for applications (whose update is managed by the OS, which importantly enables software inventory)
- Trusted/Secure Boot
- Trusted/Secure Load or Run (objective)
- Verification of code in kernel modules, userspace before load/execution
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
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, and where 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.
A live rendering of the Protection Profile, hosted on OpenShift, is available in several forms:
- Traditional Form
- Traditional Form w/ Assurance Activities Expanded
- Tabular Form
- Simplified, Requirements-only Form (easiest for quick scoping)