Secure access management for secure operational networks (SAMSON)

Transcription

1 Secure access management for secure operational networks (SAMSON) Security concept of operations (Security CONOPS) Dr. Daniel Charlebois Mr. Bruce Carruthers Mr. Glen Henderson Mr. Darcy Simmelink DRDC Ottawa Research Centre Defence Research and Development Canada Scientific Report DRDC-RDDC-2016-R001 January 2016

2 This publication has been peer-reviewed and published by the Editorial Office of Defence Research and Development Canada, an agency of the Department of National Defence of Canada. Inquiries can be sent to: This S&T document is provided for convenience of reference only. Her Majesty the Queen in right of Canada, as represented by the Minister of National Defence ("Canada"), makes no representations or warranties, express or implied, of any kind whatsoever, and assumes no liability for the accuracy, reliability, completeness, currency or usefulness of any information, product, process or material included in this document. Nothing in this document should be interpreted as an endorsement for the specific use of any tool, technique or process examined in it. Any reliance on, or use of, any information, product, process or material included in this document is at the sole risk of the person so using it or relying on it. Canada does not assume any liability in respect of any damages or losses arising out of or in connection with the use of, or reliance on, any information, product, Template process in or use: material (2010) included SR Advanced in this Template_EN document. (051115).dotm Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2016 Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2016

3 Abstract The Secure Access Management for Secure Operational Networks (SAMSON) project has demonstrated data-centric information protection on an existing unmodified operational network. The integration of access management technologies and protection mechanisms can lead to the hosting of multi-caveated information on a single network. Adopting a SAMSON data-centric security posture results in an improved security posture, auditing, enhanced information sharing and minimal impact to the operator. SAMSON can collapse caveats onto an existing classified network and significantly reduce costs of the Canadian Armed Forces maintaining multiple independent Canadian Eyes Only (CEO) networks. This report documents the Security Specific aspects of the SAMSON Concept of Operations (CONOPS). This Security CONOPS uses a standard DIM Secur template to document the security specific: 1) Roles and responsibilities; 2) Architecture (security specific) features of SAMSON; and 3) mapping to conventional security and information security. This Security CONOPS assumes SAMSON will deploy in an existing accredited level II (SECRET) network, and will inherit all of the security protections of the level II host network. These assumptions will be clearly defined. Significance to defence and security This document is specifically for any project or group wishing to deploy SAMSON in an operational environment. The Security CONOPS will map SAMSON specific roles and responsibilities in a typical network environment as well as identify how existing roles need to be expanded to support SAMSON. This document will also identify how SAMSON fits within the physical environment, and any changes required in the physical environment to support SAMSON. This document will form the basis for any long term project support estimates, identify personnel roles and responsibilities, and identify physical environment changes required to deploy SAMSON in a typical Level II network. SAMSON was deployed in a Level II network for the Coalition Attack Guidance Experiment (CAGE 2012). The roles and responsibilities, system architecture, and conventional security outlined in this document were demonstrated as part of the CAGE II deployment. The evidence generated during the exercise, including the roles and responsibilities, were submitted as Certification and Accreditation evidence for formal evaluation. DRDC-RDDC-2016-R001 i

4 Résumé Le projet SAMSON (Gestion de l accès sécuritaire aux réseaux opérationnels secrets) a démontré la protection de l'information centrée sur les données sur un réseau opérationnel existant non modifié. L'intégration de technologies de gestion de l'accès et de mécanismes de protection permet d'héberger de l'information comportant de multiples restrictions sur un même réseau. L'adoption d'une posture de sécurité axée sur les données SAMSON permet d'améliorer la sécurité, la vérification et l échange d information, en plus de minimiser les répercussions sur l utilisateur. SAMSON permet de combiner plusieurs restrictions sur un même réseau classifié existant et de réduire de façon importante le coût du maintien de plusieurs réseaux indépendants réservés aux Canadiens (RAC) par les Forces armées canadiennes. Le présent rapport documente les aspects propres à la sécurité du concept d'opération (CONOPS) SAMSON. Ce CONOPS de sécurité est basé sur un modèle standard de la Dir Sécur GI pour documenter les éléments propres à la sécurité : 1) rôles et responsabilités, 2) caractéristiques de l'architecture SAMSON (propres à la sécurité), 3) application à la sécurité conventionnelle et à la sécurité de l'information. Le CONOPS de sécurité repose sur le principe selon lequel SAMSON sera mis en service sur un réseau agréé existant de niveau II (SECRET) et héritera de toutes les protections de sécurité du réseau hôte de niveau II. Ces hypothèses seront définies clairement. Importance pour la défense et la sécurité Le présent document a été créé expressément pour tout projet ou groupe qui souhaiterait mettre en service SAMSON dans un environnement opérationnel. Le CONOPS de sécurité déterminera les rôles et responsabilités propres à SAMSON dans un environnement réseau type ainsi que l'expansion nécessaire des rôles existants à l'appui. Ce document permettra également de déterminer le positionnement de SAMSON dans l'environnement physique, ainsi que tout changement nécessaire à l'environnement physique à l'appui de SAMSON. Ce document servira de base pour les estimations sur le soutien de projets à long terme et permettra de définir les responsabilités et les rôles personnels, ainsi que les changements à l'environnement physique nécessaires à la mise en service de SAMSON sur un réseau type de niveau II. SAMSON a été mis en service sur un réseau de niveau II pour l'expérience d exécution de l attaque de la coalition (CAGE 2012). Les rôles et responsabilités, l'architecture de système et la sécurité conventionnelle présentés dans le document ont été démontrés dans le cadre de la mise en œuvre de CAGE II. Les preuves recueillies dans le cadre de cet exercice, y compris les rôles et responsabilités, ont été soumises comme preuves de certification et d'accréditation aux fins de l'évaluation officielle. ii DRDC-RDDC-2016-R001

5 Table of contents Abstract i Significance to defence and security i Résumé ii Importance pour la défense et la sécurité ii Table of contents iii List of figures v List of tables vi 1 Introduction Purpose SAMSON definition Scope Overview SAMSON overview SAMSON security overview Identity management service Key management service Authorization service Trusted audit service Policy enforcement points (PEP) Cryptographic transformation service (CTS) Secure labeling service Information System (IS) security roles and responsible authorities SAMSON roles SAMSON users Host environment roles System administrators Operational authority System architecture Connectivity SAMSON message delivery Physical connectivity Data flow Component functional descriptions Policy enforcement point (PEP) Security labeling service Identity attribute service Authorization service DRDC-RDDC-2016-R001 iii

6 3.3.5 Key management service Cryptographic transformation service Trusted audit service Conventional security SAMSON physical security SAMSON locations Host environment physical security Audit Common indicators of security incidents Information technology security SAMSON-specific ITSEC Non-SAMSON ITSEC References Bibliography List of symbols/abbreviations/acronyms/initialisms iv DRDC-RDDC-2016-R001

7 List of figures Figure 1: SAMSON within an existing IT environment Figure 2: SAMSON security services Figure 3: SAMSON security services and PEPs logical overview Figure 4: The SAMSON reference monitor Figure 5: XACML components Figure 6: SAMSON intercept (PEP) with policy, audit and cryptographic services Figure 7: SAMSON core components Figure 8: Physical connection of SAMSON to an IT infrastructure Figure 9: Data objects and processes relationships Figure 10: PEP data mediation process Figure 11: SAMSON identity attribute service Figure 12: SAMSON authorization service Figure 13: Key management service architecture Figure 14: Use of cryptographic services by PEPs Figure 15: Trusted audit service architecture DRDC-RDDC-2016-R001 v

8 List of tables Table 1: XACML security policy mapped to SAMSON information protection component vi DRDC-RDDC-2016-R001

9 1 Introduction DND/CF currently uses logically and physically separate networks to achieve need-to-know separation in the classified environment based on warning terms, or caveats. Each network becomes a community of interest enclave that operates at a SYSTEM-HIGH mode of operation using Discretionary Access Controls (DAC) that are deemed sufficient to address the requisite need-to-know requirements for their use. This has resulted in a proliferation of enclaves, various silos of data, with each silo requiring a supporting community (Information Technology (IT), security, and accreditation). The currently supported 60+ networks [7] within DND have resulted in unsustainable increase in support costs, physical infrastructure support and overall complexity to the DND/CF information systems. These information silos have also resulted in inefficient information management, dangerous data sharing practices and inconsistent application of security policy across the CF networks [4] [5] [6]. DND/CF is moving towards an Attribute Based Access Control (ABAC) [5] type of intercept point providing access control to various enclaves. This intercept point will create an operations zone (i.e., rel CAN/US) and a restricted zone (i.e., CEO). Access is gated to the restricted zone (CEO) through a Zone Interface Point (ZIP). This move will reduce the physical infrastructure of the 60+ networks, and allow for virtualization of the servers to be placed on the same physical machine. This is the first step towards a SAMSON style data-centric network protection. 1.1 Purpose This Security Concept of Operations (CONOPS) provides a security context for the intended use and operation SAMSON. SAMSON will provide caveat need-to-know separation of files, s and chat messages within a single security domain. This Security CONOPS will serve as a reference for Contractor staff and Certification & Accreditation (C&A) authorities. Typically in the Certification and Accreditation (C&A) of any system, security controls are grouped into categories in order to facilitate the understanding, aid developers and accreditors, and ensure complete coverage so there are no large gaps that an attacker can exploit. The Security CONOPS is created with the same categories and groupings to ensure complete coverage of controls, identify gaps and aid the development team, accreditors, and maintainers of the system. This document identifies how SAMSON (defined below) fits within an existing network, and what are the impacts on the roles, responsibilities, and conventional security measures employed today. This document is specific to the security considerations and implementation of the physical and logical architecture, system interconnections and interactions, and the implemented controls that govern SAMSON. 1.2 SAMSON definition SAMSON is a collection of security services that are inserted into an existing accredited network to provide cryptographic separation and policy-based access control at the data level. This policy-based access control and cryptographic separation enables different enclaves (caveats) to DRDC-RDDC-2016-R001 1

10

11 policies required by the enterprise, the data is tagged with relevant attributes (i.e., classification, releasability caveats) and the system performs access control decisions based on a comparison of the attributes of the data object and the attributes of the person requesting access to the data. SAMSON provides the ability to protect itself and associated data from unauthorized access or modification and provides an audit trail to ensure accountability for authorized actions SAMSON overview SAMSON is a collection of authorization, authentication and protection services that communicate over a private security network. These protection and security services exchange standardized extensible Markup Language (XML) messages in order to authenticate the user, mediate the information being requested, assess policy, request keys/cryptographic services and audit all access. A network environment that is protected by the SAMSON security overlay will have SAMSON enabled application proxies positioned between the user workstation and the back end data service that is serving data to the user s application. In that location, the application proxies are able to monitor the information request/response cycle. By intercepting the information flow, SAMSON can be invoked to mitigate access to data and only release information when the request is compliant with the security policy. The software components that intercept information requests are part of the application PEP intercept. The information that is being requested is: Formulate the information request in terms of a policy decision request; Send the policy decision request to the Authorization Service (AS); Respond to the decision that has been returned in a policy decision response; Perform any needed transformations on the data; and Audit the actions that were taken in the course of processing this information request. Since the communication protocols and data formats vary depending on the type of application that is to be protected, the proxy portion of the application PEP will vary in its implementation. However, the general application proxy architecture for intercepting data, the leveraging of the defined core security services and information protection logic that defines how SAMSON processes data requests, leads to the complete picture of the SAMSON security architecture. DRDC-RDDC-2016-R001 3

12

13 5. The Authorization Service calls upon the Identity Management Service to retrieve security attributes of the user, including the user s membership in communities of interest. This information is returned to the Authorization Service which then evaluates the request against the policy and returns a decision to the PEP. 6. Where the transaction is permitted, the PEP calls upon the Cryptographic Transformation Service (CTS) to decrypt the file prior to delivery. 7. The CTS calls upon the Key Management Service using a token that is stored with the file to retrieve the key that was used to encrypt the file. 8. After decryption, the external label is compared to the internal (encrypted) label. The external label is unencrypted for faster access, while the identical internal label is encrypted for security. 9. After performing the decryption process on the data asset, the file is ready to be delivered to the end user. However, prior to delivery, an audit record of the transaction is submitted, along the Audit Message Bus, to the Trusted Audit Store and, subsequently, to the Audit Store. The Audit store is any existing Security Information and Event Management (SIEM) auditing tool that exists within the network. A Trusted Audit Store creates audit records that are digitally signed and each new record digitally chained to the previous audit records. Within SAMSON this creates a chain of trust of all authorized file access. 10. The decrypted file is then delivered to the end user. For more information, please review the SAMSON Architecture Design Document [1] and Detailed Design Document [2] SAMSON security overview The SAMSON system is designed to operate in a Secret high 1 environment, so the security requirements inherent in this system-high security network are assumed to be in place. From a security safeguard perspective, it is assumed that the Secret high operating environment has adequate security controls in place for confidentiality protection and has been accredited to this level. Thus data exposed to another user would be a security violation but not a breach. The second user is accredited to the Secret level, but did not have the need to know. This means that while a high robustness (or high strength of mechanisms) solution to separate caveats may be required for the overall system solution (i.e., system-high network environment + SAMSON), a lower robustness level (or lower strength of mechanisms) could be acceptable for a SAMSON protected system component ( or chat server) which primarily addresses need-to-know separation and access control in this existing Secret high environment. For example, SAMSON would provide the high strength mechanism to provide confidentiality, while the server (and administrator) could be at a lower robustness level (enhanced reliability). 1 The architecture of SAMSON could work in a Multiple Independent Security Level (MILS) environment, but was not done for budget and accreditation reasons [3]. The scope of the project was limited to a single security level Secret. Thus Secret high level. DRDC-RDDC-2016-R001 5

14 SAMSON mediates access to information on a single SECRET network. It uses a policy engine that can receive information access requests from SAMSON components and return a decision (allow/deny) based on a single security policy. Through this policy engine, SAMSON gates access to information, since all actions against caveat labelled data are first vetted and audited by the security service components. Policy-based access control to information assets is assisted by the integrated leveraging of ancillary security services in a SAMSON environment, namely: Management of SAMSON identities and attributes; Authentication of SAMSON identities; Secure labeling of information assets; and Trusted auditing of security events and user actions. SAMSON uses a Service Oriented Architecture (SOA) approach where all security services are made available as independent services through open interfaces. The information exchange formats within this architecture utilize industry accepted, open standards that are based on the extensible Markup Language (XML). In this way, SAMSON is an enabling infrastructure that allows security services to be leveraged by applications through a trusted messaging system. SAMSON provides four core capabilities: The message delivery mechanisms; The Security Policy; The Policy Enforcement Points (PEPs); and Content protection for data at rest. SAMSON also requires these Commercial Off The Shelf (COTS) products to be connected to a SAMSON interface: Identity Management Service (for endpoint labeling and authentication); Authentication Service with an Active Directory Domain Controller; Cryptographic Key Service provided by the StrongAuth Appliance; and Trusted Time Service for consistent time stamping for the audit logs. 6 DRDC-RDDC-2016-R001

15 Samson Policy Admin Policy Repository Samson Audit Analyst/ Admin Audit Record Repository

16 Key management service This service is responsible for the creation, storage, and retrieval of cryptographic keys. Each SAMSON protected asset is encrypted with its own unique key and the Key Management Service (KMS) provides all symmetric key management functions that are needed by SAMSON cryptographic services Authorization service The SAMSON Authorization Service (AS) is responsible for giving approve or deny decisions based on the identity of the user, relevant policies and label of the data. The Policy Decision Point (PDP) is a standalone service module, and communicates over the messaging server with other SAMSON components. SAMSON policies are based on the Organization for the Advancement of Structured Information Standards (OASIS) extensible Access Control Markup Language (XACML), Version 2. Policy Decision Point (PDP): The PDP accepts mediation requests from Policy Enforcement Points (PEP), retrieves all policies for the user and caveat from a database of policies, evaluates the policies against the mediation request sent by a PEP and renders a decision that is returned to the PEP. The PDP will return a deny message if either: no policy specifically grants access; or there is an explicit deny policy Trusted audit service A tamper-resistant record of policy decision activities is made in support of short term Security Incident and Event Monitoring (SIEM) and long-term forensic activities. The trusted audit captures all relevant information (policies, user, caveat, time, decision, service requested) Policy enforcement points (PEP) The Policy Enforcement Point (PEP) is a common component that is used throughout SAMSON for enforcing and auditing information protection of data assets. The PEP is made of two major components, the application data proxy, and the SAMSON messaging client. The data proxy changes with every service protected, for example, a Microsoft exchange PEP must understand the protocol being used in order to perform SAMSON security services on each individual . The SAMSON messaging client, formats the messages and controls the flow of information between the individual SAMSON components, this allows the PEP to utilize the SAMSON security services. The SAMSON messaging client is identical for each PEP. Each Application PEP has an Application Interface that can intercept the data between the client application and SAMSON protected application (i.e., to exchange server). The remainder of the PEP is a derivation from a generic SAMSON PEP design and, therefore, follows a common information handling process. The generic PEP is instantiated for each application that needs to act as a bridge (or interface) between the SAMSON infrastructure and external services such as data or security providers. In the case of application PEPs this bridging includes data mediation and auditing. 8 DRDC-RDDC-2016-R001

17 A PEP requires labeled metadata from which policy decision requests originate. For application PEPs, this information is obtained through interception of the application s information request/response cycle. That is, as data is requested from a SAMSON protected application, a SAMSON component intercepts the information request and forwards it to the PEP Dispatcher that serves as the bridge between the application information path and the remaining SAMSON security services network that can request mediation Cryptographic transformation service (CTS) SAMSON protected assets are stored in an encrypted form. When a user has the policy right to access an object, SAMSON decrypts the asset prior to delivery. In this way, the only means to access a SAMSON protected object is through SAMSON services which will require a policy check to be performed and an audit record to be generated for each data request. The CTS is the SAMSON component that provides these encryption and decryption capabilities Secure labeling service Information objects are also defined by security attributes encapsulated within the security label that has been bound to and stored with the data. This service applies, extracts, verifies and validates labels on data objects that are protected by the SAMSON security architecture. DRDC-RDDC-2016-R001 9

18 2 Information System (IS) security roles and responsible authorities The following roles and responsibilities are identified for the SAMSON system. Depending on the organization s policies and the security and assurance requirements of the business applications and related information assets, these roles can be implemented with one individual assigned to all the roles for low assurance implementations or each role may be assigned to a specific individual for high assurance implementations. 2.1 SAMSON roles All of the following SAMSON Administrator roles, with the exception of the Security Officer, log on to SAMSON through a SAMSON PEP to perform their required functions: Policy Administrator: Responsible for the generation, modification, removal and activation of all Policies within the SAMSON system; Audit Administrator: Responsible for the maintenance and upkeep of the SAMSON Trusted Audit System; Audit Analyst: Responsible for the analysis of the collected audit data and to report security breaches or conditions that require investigation to the SAMSON Security Officer; IdM Administrator: Responsible for assigning the SAMSON user provisioning (caveats, communities of interest, etc.); SAMSON Administrator: Responsible for the initial configuration of SAMSON, for its ongoing maintenance and database integrity. Other functions include changing performing database backups and starting and stopping services as needed; and Security Officer: Responsible for the custody of the cryptographic keys used within the SAMSON system and crypto support devices, such as StrongAuth. Security Officers may also add, delete, and configure other administrative users, including defining and configuring new roles; reviewing audit data to determine if corrective actions are required; ensuring that the SAMSON environment is configured with the correct robustness; ensuring that policies used are correct, accurate and implemented correctly. 2.2 SAMSON users SAMSON users are defined as any user that has a client workstation that performs labeling, attaches metadata to the data object, and has an application that points to a SAMSON PEP. A user can have both SAMSON and non-samson client services at the same time (SAMSON protected file server and a non-protected file server). 10 DRDC-RDDC-2016-R001

19 2.3 Host environment roles The following roles are provided by the hosting target environment. These are divided into administrative and authority System administrators The following roles are provided by the hosting target environment for maintenance and updates to the core server, network and storage systems, outside of SAMSON administrators: Server Administrators; Network Administrators; and Storage Administrators. There are roles required by the systems which support SAMSON, which will already be in existence within the host target environment, but are outside the scope of SAMSON: IdM Administrators; Active Directory Administrators; extensible Messaging and Presence Protocol (XMPP): Openfire Administrators (IM, Audit, and SAMSON); and Application (File Services, , IM) Administrators Operational authority SAMSON resides under the operational authority of the host network. This includes any accreditation, inspection, physical and environmental inspection roles from the host network. DRDC-RDDC-2016-R001 11

20

21 Figure 5: XACML components. Table 1 maps the SAMSON information protection architectural components to the XACML security policy expression and enforcement standard. Table 1: XACML security policy mapped to SAMSON information protection component. XACML Component SAMSON Architectural Component Policy Decision Point (PDP) Policy Information Point (PIP) Policy Enforcement Points (PEPs) The SAMSON Authorization Service provides an interface to a PDP to apply a single unified security policy against information access requests. The SAMSON Identity Attribute and Security Labelling Services act as policy information points, retrieving security attributes bound to users and data, respectively, that can be used as supplemental and context-specific information to assist in the determination of a policy decision. SAMSON Policy Enforcement Points intercept data requests between the user and the target service. These PEPs apply the policy decision returned from the Authorization Service and perform information protection transformation on data to protect the data against unauthorized disclosure by leveraging the Cryptographic Transformation and Key Management Service. DRDC-RDDC-2016-R001 13

22 XACML Component Policy Administration Points (PAPs) SAMSON Architectural Component SAMSON, as a security overlay, is designed to leverage existing COTS-based security products such as commercially available PDPs, audit and identity management solutions. As a result, a target environment would use the administrative services provided by those products. However, SAMSON can supplement the security protections on administrative interfaces by applying the reference monitor protection model to those interfaces. In the same way it protects data assets, a PEP can gate access to all administrative interfaces including the PAP. SAMSON goes beyond the traditional XACML language by incorporating Trusted Audit Services and Cryptographic Transformation Services into the design of the PEP architecture, as shown in Figure 6, ensuring that a tamper-resistant audit trail is kept of all user-initiated transactions, and all data is encrypted passing through a PEP. Since all SAMSON data passes through a PEP for encryption/decryption, this is a convenient point for auditing all access to/from the data as well. The PEP collects all the relevant information to make a policy decision, and then audits all of the access control information in an audit log. The Trusted Audit Services then digitally signs the information and digitally chains it to the previous audit record (using a cryptographic hashing algorithm). This creates a trusted audit chain of information, where audit tampering can be detected. The Cryptographic Transformation Services protects information against unauthorized disclosure through cryptographic protections that occur as part of the data handling routines when information passes through SAMSON policy enforcement points, as shown in Figure 6. Figure 6: SAMSON intercept (PEP) with policy, audit and cryptographic services. 14 DRDC-RDDC-2016-R001

23 3.1 Connectivity SAMSON is a collection of COTS security services that forces applications to consistently use these services through a trusted messaging system. While there are specific SAMSON components that are mandatory to a SAMSON deployment, additional COTS security services can be added to the minimum required, extending SAMSON to protect information assets in a variety of environments. The two sections below will discuss the message delivery and physical connectivity. Since SAMSON is a service oriented architecture, the service components that make up SAMSON can be called as required. This is described in the message delivery section. SAMSON can also be physically connected in a variety of ways, depending on the local needs and security requirements. SAMSON can be physically separated into four distinct networks for maximum security or as few as two (original data network and the SAMSON services). This is described in the physical connectivity section SAMSON message delivery SAMSON is implemented as a Service Oriented Architecture (SOA) whereby all security requirements are met by independent services that are accessible through open, well-defined interfaces. The information exchange formats within this architecture utilize industry accepted, open standards that are based on the extensible Markup Language (XML). It is important to recognize that the architectural goal of the SAMSON infrastructure is to provide a common set of security interfaces and the ability for data handling applications to leverage those services for a universal application of the domain s security policy. Conceptually, the SAMSON security services act as security gateways with the ability to route an internally generated SAMSON security service information request to the actual external service or process that will handle the request. SAMSON is, therefore, not tied to any specific vendor solution and can replace any vendor solution with another product that provides similar capabilities. In this way, all SAMSON security interfaces conform to a common set of design goals, including: They can be made to work with any external vendor solution, product or implementation; They can be extended to include any SAMSON-specific capabilities that are not reflected in the chosen standard; They are appropriately secured in order to ensure the confidentiality and integrity of these information exchanges; and New security services can be added to the architecture without the need to redesign or redeploy the entire security overlay. DRDC-RDDC-2016-R001 15

24 The SAMSON architecture achieves its data protection requirements through the use of three core architectural components: 1. A Secure Messaging Service Bus (SMSB): The ability for SAMSON components to exchange data in a manner that is secure, protocol agnostic, and reliable. 2. Security Services Gateways: The ability to bridge between the SAMSON security architecture and the back end (non-samson) applications that provide the needed security functionality. These services include authorization for adherence to policy, cryptographic services for protection of data and audit for the creation of a trusted chain of evidence. 3. Policy Enforcement Points (PEPs): The ability to link external application and security services to the SAMSON infrastructure in a manner that adheres to the SAMSON security protection principles. These components can be seen in their proper context in Figure 7. The SMSB is the blue lines connecting the core components through a standard message format. Audit uses a SMSB as well, with specific audit related messages. Figure 7: SAMSON core components. The SAMSON policy engine and the security policy it enforces work with the security gateways and PEPs to ensure that only information to which a user has a right to access is delivered to the endpoint. As illustrated in Figure 4, policy decisions are based upon the user s community memberships and the caveats contained within the security labels that are tied to the information that has been requested. If a user does not have the policy right to perform actions on the data, the 16 DRDC-RDDC-2016-R001

25 StrongAuth Crypto Appliance

26 3.2 Data flow As stated at the start of this chapter, SAMSON is a collection of COTS security services that forces applications to consistently use these services through a trusted messaging system. These security services pass XML messages over the SMSB messaging bus. The XML messages are data objects that are passed between SAMSON services. The diagram (Figure 9) shown below provides a visual representation of the data objects and their relationships with the functional processes within the SAMSON System. This diagram shows the messages sent and services required on the network. Any new/replacement services are required to provide identical messaging capability (i.e., the Crypto appliance would receive a reference token and return the matching encryption key associated with that token). The figure also provides a complete map of security message bus messages, for complete test coverage. All messages can be defined, tested and varied to ensure the service provided can perform as expected and can handle malformed service requests (and audit them). It should be noted that the Identity Query Service (IQS) functionality is shown here in green as a matter of completeness; this functionality was not used in the final test environment. External Actors are shown in yellow. User Caveat Appropriate caveats for user Active Directory Authentication Service userid Ipaddress ProgramName Operation Target Notes ActionResult Trusted Audit Audit Data SIEM Audit Alarms Validate user IDM Label query User Workstation Appropriate caveats for user IQS Staging Area User requests access to resource Decrypted file Application PEP Filename Svc_action (list,read) Resource caveat msgid User resourcecaveat Policy_action SLS (read,write) {Functions: Read config file, Scan for Plugin, Validate Label, Extract Caveat} PDP msgid Permit Or Deny decrypt User Filename Policy_action Svc_action Newfilename resourcecaveat Protected Resources Crypto Protection Services Enc/decrypt keys token Resource Container {Objects: Caveat, Token, UUID, Filename} Result userid Caveat_value RequestID accountid RequestID accountid Caveats_request Result userid Caveat_value UserID, Caveat Request userid, caveats Nationality,clearance Policies Subjects, Actions, Resources, Environment CryptoAppliance Caveats_request IdMGW Policy Admin {Policy Functions: delete,create,edit,modify, Activate, deactivate} Figure 9: Data objects and processes relationships. A PEP is a common component element that is used throughout SAMSON for providing security services and information protection. A PEP mediates access to a server (i.e., a file server) according to policy, decrypts data and audits transactions. Each PEP is an instance of a generic PEP design structure and, therefore, follows a common information handling process. Each PEP can send and receive messages, as shown in Figure 9, from the services identified in the figure. 18 DRDC-RDDC-2016-R001

27 Therefore the SAMSON PEP is made of two parts the first part that understands the protocol of the client/server data request/response cycle, and the second part that is identical across all PEPs on a network that can talk to the SAMSON services. Creating a new SAMSON PEP can be done by understanding and mediating the data request/response cycle. 3.3 Component functional descriptions SAMSON intercepts data between a client workstation and an endpoint on an operational network. The Policy Enforcement Point interrupts the data flow between the client workstation and data server. Once the data flow is captured, the resulting data object (file, , chat message) can be intercepted, and SAMSON security services can be applied against the data object. These security service gateways provide defined security capabilities according to a specific data protocol interface. Each of the SAMSON services will be discussed below, starting with the information processing logic of the PEP. The PEP sends a message to the Security Labeling Service (SLS) and retrieves the security label of the data. The PEP then calls the Authorization Service (AS), and then the Identity Attribute Service (IAS) to determine if access should be granted, based on the label of the data, identity attributes and authorization allowed. If access is granted, a Cryptographic Transformation Service (CTS) is called to encrypt/decrypt the data, and finally call the Trusted Audit Service (TAS) to audit this transaction. This is discussed in the section below Policy enforcement point (PEP) A generic PEP is instantiated for each application and security service that needs mediation. The SAMSON operational environment includes (but is not limited to) application PEPs for: file sharing, instant messaging and . In principle, however, any application can be made SAMSON-compatible through the creation and adaption of an instance of the generic PEP. Application PEPs are composed of two primary subcomponents: An application data network service proxy; and A SAMSON messaging client that connects the PEP to the XMPP domain(s) to allow the PEP to draw upon and utilize SAMSON security services. DRDC-RDDC-2016-R001 19

28 Figure 10: PEP data mediation process. The PEP will (1) examine the originating request to determine the user s identity and the action requested and will also (2) call the SLS to look ahead to the data being requested to acquire the security attributes in the security label that have been bound to the target information. Combined with any environmental data needed to make the policy decision, the PEP has sufficient information to (3) submit a policy request to the SAMSON Authorization Service. Depending on the policy decision that is returned to the proxy, the data is either made available to the user or denied. As an application proxy, the PEP calls the Cryptographic Transformation Service (CTS) to transform the data in accordance with the SAMSON information processing logic (CTS is internal to the PEP, and is thus not a service call across the security bus). SAMSON transforms all information assets to individually encrypted objects that can then be stored on the native host-network server; each protected using a unique symmetric key. When access to an information asset has been granted, the object must be (4) decrypted by the CTS prior to release to the end user. The decryption process is requested by the PEP by calling upon the SAMSON Cryptographic Transformation Service. The final step in the information protection logic deals with the (5) creation of an audit record. Being the data interception point, the point where policy is enforced and the point where transformation on data is performed, makes the PEP the most appropriate place to generate an audit event regarding the transaction. A failure of any SAMSON component to provide a valid response during the processing of this transaction would similarly be recorded with this transaction request. 20 DRDC-RDDC-2016-R001

29 3.3.2 Security labeling service The SAMSON architecture has the ability to operate on data assets that have security labels attached to: Files; messages (and, individually, files attached to messages); Instant Message Chat Rooms; and TLS protected web sessions. These labels are attached to data objects either through explicit assignment of a security label by the data owner or through an automated assignment of an appropriate caveat by a context aware labeling function. Given the different formats that a data object can take, there is no single SLS that can handle all data formats; however, all SLSs will have a consistent behaviour. Taking the file-based SLS as an example, the SLS instantiation that works on files, the SLS is called with the name of a data asset for which the security label is needed and with specific instructions on what information is needed from the label on the data. Specifically, the SLS must be able to: Extract the label; Verify that the label has not been tampered with; and Validate that the label is correct for the data to which it is bound. Verification of a label is a check to ensure that the cryptographic binding that ties a security label to a document has not changed. The validation of a label is achieved by applying heuristic analysis against the content to ensure that the label is appropriate for the content, for example, a scan for specific sensitive words. Each of these calls can be done separately since they involve more sophisticated processing. For example, when listing a directory it may not be necessary to verify the integrity on labels, but when a file is requested, the label must not have been tampered with prior to its release. As with the CTS, the SLS must work directly on the data itself and, therefore, must be co-located where the originating data asset is stored. Each PEP will, therefore, require an SLS deployed as part of the PEP installation Identity attribute service The SAMSON Identity Attribute Service (IAS) manages the security attributes of SAMSON users within the deployed environment. At a minimum, the SAMSON IAS is composed of: The IAS and its messaging interface; The COTS-based back end IdM service or application; The user security attribute storage facility; and An administrative interface for modifying the user caveat information. These four components (in blue) are deployed in the following configuration (Figure 11). DRDC-RDDC-2016-R001 21

30 Figure 11: SAMSON identity attribute service. The Security Attribute Storage facility is the central repository for all SAMSON security information associated with users in the SAMSON environment. This may be the primary IdM repository for all user information or a separate repository used exclusively for SAMSON security information that is maintained and synchronized with the user identity authoritative source. However, the user security attribute storage facility is the de facto authority for the determination of the security attribute information used during the evaluation of SAMSON protected data requests. The interface presented by the IAS is used by other SAMSON components to acquire user attribute information from the user security attribute repository. This is most notably seen in the Authorization Service s need to obtain community of interest membership information from the IAS as part of the policy decision process. All SAMSON components that require information from the IAS formulate a request using the IAS message format (Service Provisioning Markup Language SPML and Directory Services Markup Language DSML) and transmit this request over the SAMSON security message bus. A web-based interface is used to set and maintain the user s security attribute information. In a deployment scenario where there is a separate repository for user security attribute information versus user identity information, synchronization between repositories will be required. While this synchronization would be performed by the IdM itself, outside of the SAMSON messaging services, the authoritative nature of the various sources must be maintained. 22 DRDC-RDDC-2016-R001

31 3.3.4 Authorization service The central core security service for the SAMSON demonstrator is its Authorization Service. This service is a reference monitor, a software module that mediates all software access to data objects and verifies that the access requests are allowed by the access control policy. Data objects, in the SAMSON architecture, can be information assets, data services, session objects, or real-time sessions. The Authorization Service module dictates the conditions under which an entity is authorized to access a protected object by interpreting a single, universal security policy in the context of a policy decision function. Information access requests are intercepted by the application PEPs. The information request details at the PEP are formulated into a policy request message and transmitted to the Authorization Service that is acting as a PDP. The Authorization Service applies its policy engine logic to derive a policy response that is returned to the PEP for enforcement. This policy decision message exchange is transmitted via the SAMSON security message bus using an appropriate message content format, such as the extensible Access Control Markup Language (XACML). At a minimum, the Authorization Service is composed of: The Authorization Service SAMSON messaging client (the security service gateway); The Authorization Service Policy Engine; The Policy Storage facility; and An administrative interface for modifying the policy. These four components (in blue) are to be deployed in the following configuration (Figure 12). DRDC-RDDC-2016-R001 23

32 Figure 12: SAMSON authorization service. The SAMSON Authorization Service is designed to work with pluggable components. It is possible to replace the policy engine, storage facility and administrative tools with any security policy solution so long as the policy gateway is able to bridge to the back-end third party policy (e.g., COTS) product. This ability to work with a back-end security product is inherent to the SAMSON design philosophy for SAMSON security service gateways. While not explicit in the SAMSON design, proper security architecture practices call for security modules to exercise the principle of least privilege, returning an explicit denial unless there is a specific policy right to access the information Key management service The SAMSON Key Management Service (KMS) manages the generation, storage and retrieval of symmetric keys that are used to cryptographically protect individual information assets. At a minimum, the SAMSON KMS is composed of: The KMS Service messaging client (the security service gateway); A Key Escrow Service; A Key Storage Facility; and A Key Generation Facility. These four components (in blue) are to be deployed in the following configuration (Figure 13). 24 DRDC-RDDC-2016-R001

33 Figure 13: Key management service architecture. This service is called by any SAMSON component that requests access to the cryptographic keys that are used to protect information assets. Typically, the only components that would require keying information are the locally deployed instantiations of the Cryptographic Service at the various PEPs in the deployed SAMSON security overlay. The KMS receives requests to generate keys and can act as a gateway to reform and redirect that request to a key generation facility (e.g., a Federal Information Processing Standards (FIPS) compliant library). The KMS also receives requests to store and retrieve keys, based on a unique token lookup value. This token value is stored with the protected data asset so that the PEP is able to ask for the correct key when requesting a decryption. Outside of the key storage facility, there is no linkage between the token and the key that could be used to derive the key through non-samson means Cryptographic transformation service The SAMSON Cryptographic Transformation Service (CTS) is responsible for performing the actual transformations on data assets in response to a directive from a SAMSON PEP to protect or unprotect the asset. The CTS is the only client service of the KMS. The CTS is composed of: The CTS Service messaging client (the security service gateway); and A cryptographic library or module. These two components (in blue) are to be deployed (in multiple instantiations) in the following configuration (Figure 14). DRDC-RDDC-2016-R001 25

34 Figure 14: Use of cryptographic services by PEPs. This CTS service receives an instruction, a reference to a data asset, a reference token for a key and target location for the result of the transformation. The instruction will dictate whether this is an encryption or decryption action. The CTS will use the key retrieved using the token to perform the targeted action on the data asset and place the result at the designated location. Unlike the previously described core services, the CTS must be co-located where the originating data asset is stored. For example, an application PEP that must cryptographically protect a data asset will call, using the SAMSON secure messaging bus, the locally deployed CTS using a local reference to the file. In this way, SAMSON follows a principle whereby services are moved to the data and not vice versa. There is no need to transmit a file to the CTS, the local CTS is able to see and protect the local copy of that file. This results in less exposure for the file since it does not need to be sent, does not require multiple copies (in different domains) of the file and strict local access control can be exercised over the file where it resides. This also means that a SAMSON deployment will have one AS, one IAS and one KMS, but will have multiple instantiations of the CTS; one for each deployed application PEP. The CTS can bridge to any cryptographic library, including libraries that have a FIPS certification. The actual selection of the cryptographic library will depend on the attitude towards risk and certification in the target environment Trusted audit service SAMSON includes an audit service that receives and stores, in a tamper-resistant and trusted manner, audit event information from the deployed SAMSON security overlay. The SAMSON Trusted Audit Server (TAS) manages the collection, processing, storage and analysis of the audit 26 DRDC-RDDC-2016-R001

35 records that are generated as SAMSON processes a request for SAMSON protected information assets. At a minimum, the SAMSON TAS is composed of: The TAS messaging client (the security service gateway); The TAS audit event processing logic; The TAS notification processing logic; The TAS audit store; The TAS integrity analysis tools; and The TAS analysis interface. Figure 15: Trusted audit service architecture. As depicted in Figure 15, the TAS service receives the audit messages from the application PEPs, which includes the full description of the request, the policy decision result and the intermediary results from all SAMSON components that were leveraged in order to derive the result that was returned to the application PEP. Each recoded transaction is a snapshot of the policy decision as well as a rationale for why a particular decision was made, a rationale that can be examined in a forensics context. The TAS audit event processing logic expands upon the audit data to include the record and block chaining data that form the chain-of-custody. This transformational logic also includes the ability to detect security incidents that need to be flagged to domain security officers through a standard event logging mechanism. In terms of preventing malicious activity against the target environment, SAMSON is uniquely placed to detect attempts to send illegal instructions, DRDC-RDDC-2016-R001 27