{"text_format":"1","workbook":"xlsx","n_sheets":4,"sheets":["Sheet0","Sheet2","Sheet1","Sheetx"],"not_rendered":{"charts":0,"images":0,"macros":1,"external_links":1,"defined_names":2,"comments":3,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"Sheet0","index":0,"n_rows":173,"n_cols":19,"rows_kept":173,"cut":false,"hidden":false,"merged":[]}
["IA Control","CCI","SRGID","STIGID","SRG Requirement","Requirement","SRG VulDiscussion","VulDiscussion","Status","SRG Check","Check","SRG Fix","Fix","Severity","Mitigation","Artifact Description","Status Justification"]
["AC-17 (2)","CCI-000068","SRG-APP-000014-CTR-000035","","The container platform must use TLS 1.2 or greater for secure container image transport from trusted sources.","","The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.",null,"Not Applicable","Review the container platform configuration to verify that TLS 1.2 or greater is being used for secure container image transport from trusted sources. \n\nIf TLS 1.2 or greater is not being used for secure container image transport, this is a finding.","","Configure the container platform to use TLS 1.2 or greater when components communicate internally or externally. The fix ensures that all communication components in the container platform are configured to utilize secure versions of TLS.","","CAT II","",null,{"$f":"VLOOKUP(\"D0001\", Sheet1!A:B,2,0)","v":"D0001-   TLS settings\nRancher MCM runs on top of a Kubernetes cluster and does not  have the ability to configure at that level. It is important to configure the platform in a way that uses strong cryptography wherever possible.\n"},{"$f":"VLOOKUP(\"N0001\", Sheet1!M:N,2,0)","v":"RKE2 can configure this. Possibly inherently meets here because if the underlying platform provides the functionality then the applications should inherit. \n\nRancher MCM can, at the application/ingress level, configure ingress objects to use certain TLS settings but this is not at the node level.\n\nD0001 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0001 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-17 (2)","CCI-000068","SRG-APP-000014-CTR-000040","","The container platform must use TLS 1.2 or greater for secure communication.","","The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.",null,"Not Applicable","Review the container platform configuration to verify that TLS 1.2 or greater is being used for communication by the container platform nodes and components. \n\nIf TLS 1.2 or greater is not being used for secure communication, this is a finding.","","Configure the container platform to use TLS 1.2 or greater for node and component communication.","","CAT II",null,null,{"$f":"VLOOKUP(\"D0001\", Sheet1!A:B,2,0)","v":"D0001-   TLS settings\nRancher MCM runs on top of a Kubernetes cluster and does not  have the ability to configure at that level. It is important to configure the platform in a way that uses strong cryptography wherever possible.\n"},{"$f":"VLOOKUP(\"N0001\", Sheet1!M:N,2,0)","v":"RKE2 can configure this. Possibly inherently meets here because if the underlying platform provides the functionality then the applications should inherit. \n\nRancher MCM can, at the application/ingress level, configure ingress objects to use certain TLS settings but this is not at the node level.\n\nD0001 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0001 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (1)","CCI-000015","SRG-APP-000023-CTR-000055","","The container platform must use a centralized user management solution to support account management functions.","Rancher MCM must use a centralized user management solution to support account management functions.","Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error.\n\nA comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated or by disabling accounts located in non-centralized account stores, such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service.\n\nThe application must be configured to automatically provide account management functions, and these functions must immediately enforce the organization's current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure-providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies, that when placed together, contain an overall automated mechanism supporting an organization's automated account management requirements.\n\nAccount management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; or using automated telephonic notification to report atypical system account usage.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if it is using a centralized user management system for user management functions. \n\nIf the container platform is not using a centralized user management system for user management functions, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use a centralized user management system for user management functions.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (2)","CCI-000016","SRG-APP-000024-CTR-000060","","The container platform must automatically remove or disable temporary user accounts after 72 hours.","Temporary/Initial administrator accounts must be removed or disabled after 72 hours.","If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary user accounts must be set upon account creation.\n\nTemporary user accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation.\n\nIf temporary user accounts are used, the application must be configured to automatically terminate these types of accounts after a DoD-defined period of 72 hours.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0003\", Sheet1!A:B,2,0)","v":"D0003 - Temporary/Initial administrator accounts\nRancher MCM requires the set up of an initial administrator account when first launched. This administrative user is used to configure the portions of Rancher MCM. Once another form of authn/authz is configured this user is no longer needed and needs to be manually removed as it has unlimited privileges by default.   "},"Applicable - Configurable","Review the container platform configuration to determine if temporary user accounts are automatically removed or disabled after 72 hours. \n\nIf temporary user accounts are not automatically removed or disabled after 72 hours, this is a finding.","From the Main Menu, select Users & Authentication -> Users.\n\nVerifiy all Temporary/Initial administrator accounts user accounts are removed or inactive. If Temporary/Initial administrator accounts exist and state is not 'Inactive', this is a finding. \n\n ","Configure the container platform to automatically remove or disable temporary user accounts after 72 hours.","For each user to delete or set State to 'Inactive':\nFrom the Main Menu, select Users & Authentication -> Users.\n\nCheck the box next to the user to remove. \n\nClick the button to Delete. \n\nFollow the prompt to verify by typing the user for deletion (case sensitive). \n\nSelect Delete. ","CAT II",""]
["AC-2 (3)","CCI-000017","SRG-APP-000025-CTR-000065","","The container platform must automatically disable accounts after a 35-day period of account inactivity.","","Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.\n\nThis policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local login administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations.",null,"Not Applicable","Determine if the container platform automatically disables accounts after a 35-day period of account inactivity. \n\nIf the container platform does not automatically disable accounts after a 35-day period of account inactivity, this is a finding.",null,"Configure the container platform to automatically disable accounts after a 35-day period of account inactivity.",null,"CAT II","",null,"User management provided outside Rancher MCM scope. Rancher MCM uses external systems for user management and authentication. Rancher MCM then does authorization to determine access permissions.",{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-000018","SRG-APP-000026-CTR-000070","","The container platform must automatically audit account creation.","Rancher MCM must automatically audit account creation.","Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to create a new account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created, and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if audit records are automatically created upon account creation. \n\nIf audit records are not automatically created upon account creation, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically create audit records on account creation.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-2 (4)","CCI-001403","SRG-APP-000027-CTR-000075","","The container platform must automatically audit account modification.","","Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if account modification is automatically audited. \n\nIf account modification is not automatically audited, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account modification.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-2 (4)","CCI-001404","SRG-APP-000028-CTR-000080","","The container platform must automatically audit account-disabling actions.","","When application accounts are disabled, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to disable authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account-disabling actions provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if account disabling is automatically audited. \n\nIf account disabling is not automatically audited, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account disabling.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-2 (4)","CCI-001405","SRG-APP-000029-CTR-000085","","The container platform must automatically audit account removal actions.","","When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if account removal is automatically audited. \n\nIf account removal is not automatically audited, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account removal.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-3","CCI-000213","SRG-APP-000033-CTR-000090","","Least privilege access and need to know must be required to access the container platform registry.","","The container platform registry is used to store images and is the keeper of truth for trusted images within the platform. To guarantee the images integrity, access to the registry must be limited to those individuals who need to perform tasks to the images such as the update, creation, or deletion of images. Without this control access, images can be deleted that are in use by the container platform causing a denial of service (DoS), and images can be modified or introduced without going through the testing and validation process allowing for the intentional or unintentional introduction of containers with flaws and vulnerabilities.","","Not Applicable","Review the container platform configuration to determine if least privilege and need-to-know access is being used for container platform registry access. \n\nIf least privilege and need-to-know access is not being used for container platform registry access, this is a finding.","","Configure the container platform to use least privilege and need to know when granting access to the container platform registry. The fix ensures the proper roles and permissions are configured.","","CAT II","",null,"Rancher MCM has no integrated platform registry."]
["AC-3","CCI-000213","SRG-APP-000033-CTR-000095","","Least privilege access and need to know must be required to access the container platform runtime.","Least privilege access and need to know must be required to access Rancher MCM.","The container platform runtime is used to instantiate containers. If this process is accessed by those persons who are not authorized, those containers offering services can be brought to a denial of service (DoS) situation, disabling a large number of services with a small change to the container platform. To limit this threat, it is important to limit access to the runtime to only those individuals with runtime duties.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if only those individuals with runtime duties have access to the container platform runtime. \n\nIf users have access to the container platform runtime that do not have runtime duties, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use least privilege and need to know when granting access to the container runtime. The fix ensures the proper roles and permissions are configured.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-3","CCI-000213","SRG-APP-000033-CTR-000100","","Least privilege access and need to know must be required to access the container platform keystore.","Ensure the default role a user is assigned when allowed by the central authentication system is User-Base.","The container platform keystore is used to store access keys and tokens for trusted access to and from the container platform. The keystore gives the container platform a method to store the confidential data in a secure way and to encrypt the data when at rest. If this data is not protected through access controls, it can be used to access trusted sources as the container platform breaking the trusted relationship. To circumvent unauthorized access to the keystore, the container platform must have access controls in place to only allow those individuals with keystore duties.","Rancher MCM uses roles for authentication.  It is nessary to ensures the proper roles and permissions are configured. The role used by default does not ensure least privilege. The default role needs to be changed to allow least privilege access.","Applicable - Configurable","Review the container platform to determine if only those individuals with keystore duties have access to the container platform keystore. \n\nIf users have access to the container platform keystore that do not have keystore duties, this is a finding.","From the GUI, Navigate to:\nUsers & Authentication->Roles\n\nClick \"Standard User\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", ensure \"No\" is selected. \n\nClick \"User-Base\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", ensure \"Yes\" is selected\n\nIf \"No\" is not selected for Standard User, this is a finding. \nIf \"Yes\" is not selected for User-Base, this is a finding. ","Configure the container platform to use least privilege and need to know when granting access to the container keystore. The fix ensures the proper roles and permissions are configured.","From the GUI, Navigate to:\nUsers & Authentication->Roles\n\nClick \"Standard User\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", select \"No\" and click Save.\n\nClick \"User-Base\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", select \"Yes\" and click \"Save\"","CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-4","CCI-001368","SRG-APP-000038-CTR-000105","","The container platform must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.","Rancher MCM must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.","Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are using labels and separate namespace for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies is being enforced. \n\nIf the organization-defined information flow policies are not being enforced, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-4","CCI-001414","SRG-APP-000039-CTR-000110","","The container platform must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies.","Rancher MCM must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies.","Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are: using labels for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if organization-defined information flow controls are implemented. \n\nIf information flow controls are not implemented, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to implement organization-defined information flow controls.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-7 a","CCI-000044","SRG-APP-000065-CTR-000115","","The container platform must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.","Rancher MCM must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.","By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if it is configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.\n\nIf the container platform is not configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-8 a","CCI-000048","SRG-APP-000068-CTR-000120","","The container platform must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components.","","The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.","","Not Applicable","Review the container platform configuration to determine if the Standard Mandatory DoD Notice and Consent Banner is configured to be displayed before granting access to platform components. \n\nLog in to the container platform components and verify that the Standard Mandatory DoD  Notice and Consent Banner is being displayed before granting access.\n\nIf the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding.","","Configure the container platform to display the Standard Mandatory DoD Notice and Consent Banner before granting access to container platform components.","","CAT III","",null,"Exhibiting and banner would be performed by the OS or any user services executing within Rancher MCM.","This has not been implemented by Rancher MCM as of writing this 08/10/2021"]
["AC-8 b","CCI-000050","SRG-APP-000069-CTR-000125","","The container platform must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.","","The banner must be acknowledged by the user prior to allowing the user access to any container platform component. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. \n\nTo establish acceptance of the application usage policy, a click-through banner at application logon is required. The application must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating \"OK\".","","Not Applicable","Log in to the container platform components to determine if the Standard Mandatory DoD Notice and Consent Banner remains on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access. \n\nIf the Standard Mandatory DoD Notice and Consent Banner does not stay on the screen until the users acknowledge the usage and conditions, this is a finding.","","Configure the container platform to retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.","","CAT III","",null,"Exhibiting and banner would be performed by the OS or any user services executing within Rancher MCM.","This has not been implemented by Rancher MCM as of writing this 08/10/2021"]
["AU-12 a","CCI-000169","SRG-APP-000089-CTR-000150","","The container platform must generate audit records for all DoD-defined auditable events within all components in the platform.","Rancher MCM must generate audit records for all DoD-defined auditable events within all components in the platform.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, including security incidents that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to have the appropriate and required data logged. To handle the need to log DoD-defined auditable events, the container platform must offer a mechanism to change and manage the events that are audited.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to generate audit records for all DoD-defined auditable events within all components in the platform. \n\nGenerate DoD-defined auditable events within all the components to determine if the events are being audited. \n\nIf the container platform is not configured to generate audit records for all DoD-defined auditable events within the components or the events are  not generating audit records, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records for all DoD-defined auditable events within all the components of the container platform.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-12 b","CCI-000171","SRG-APP-000090-CTR-000155","","The container platform must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.","Rancher MCM must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.","Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n \nThe list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if the container platform is configured to allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited. \n\nIf the container platform is not configured to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"Rancher MCM can have Audit logging turned on at the app level (operations peformed inside Rancher), RKE2 can also have audit logging turned on at the platform level (operations performed on the kubernetes cluster).\n\nThis should be able to be translated to a notification system if auditing is aggregated and filtered.\n\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"]
["AU-12 c","CCI-000172","SRG-APP-000091-CTR-000160","","The container platform must generate audit records when successful/unsuccessful attempts to access privileges occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access privileges occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to generate audit records when successful/unsuccessful attempts are made to access privileges. \n\nIf the container platform is not configured to generate audit records on successful/unsuccessful access to privileges, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records when successful/unsuccessful attempts are made to access privileges occur.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-14 (1)","CCI-001464","SRG-APP-000092-CTR-000165","","The container platform must initiate session auditing upon startup.","Rancher MCM must initiate session auditing upon startup.","When the container platform is started, container platform components and user services can also be started. It is important that the container platform begin auditing on startup in order to handle container platform startup events along with events for container platform components and services that begin on startup.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration for session audits. \n\nEnsure audit policy for session logging at startup is enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf the container platform is not configured to meet this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit logs for session logging at startup. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000130","SRG-APP-000095-CTR-000170","","All audit records must identify what type of event has occurred within the container platform.","All audit records must identify what type of event has occurred within Rancher MCM.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know what type of event occurred.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration for audit event types. Ensure audit policy for event type is enabled. \n\nVerify records showing what type of event occurred are written to the log. \n\nValidate system documentation is current. \n\nIf log data does not show the type of event, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to include the event type in the log data. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000131","SRG-APP-000096-CTR-000175","","The container platform audit records must have a date and time association with all events.","Rancher MCM audit records must have a date and time association with all events.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know when the event occurred. To establish the time of the event, the audit record must contain the date and time.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration for audit events date and time. \n\nEnsure audit policy for event date and time are enabled. \n\nVerify records showing event date and time are included in the log. \n\nValidate system documentation is current. \n\nIf the date and time are not included, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to include log date and time with the event. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000132","SRG-APP-000097-CTR-000180","","All audit records must identify where in the container platform the event occurred.","All audit records must identify where in Rancher MCM the event occurred.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know where within the container platform the event occurred.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if all audit records identify where in the container platform the event occurred. \n\nGenerate audit records and view the audit records to verify that the records do identify where in the container platform the event occurred. \n\nIf the container platform is not configured to generate audit records that identify where in the container platform the event occurred, or if the generated audit records do not identify where in the container platform the event occurred, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records that identify where in the container platform the event occurred.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000133","SRG-APP-000098-CTR-000185","","All audit records must identify the source of the event within the container platform.","All audit records must identify the source of the event within Rancher MCM.","Audit data is important when there are issues, to include security incidents that must be investigated. Since the audit data may be part of a larger audit system, it is important for the audit data to also include the container platform name for traceability back to the container platform itself and not just the container platform components.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review container platform audit policy configuration for logons establishing the sources of events. \n\nEnsure audit policy is configured to generate sufficient information to resolve the source, e.g., source IP, of the log event. \n\nVerify records showing by requesting a user access the container platform and generate log events, and then review the logs to determine if the source of the event can be established. \n\nIf the source of the event cannot be determined, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform registry, keystore, and runtime to generate the source of each loggable event. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000134","SRG-APP-000099-CTR-000190","","All audit records must generate the event results within the container platform.","All audit records must generate the event results within Rancher MCM.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know the outcome of the event.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if audit records contain the audit event results. \n\nGenerate audit records and review the data to validate that the record does contain the event result. \n\nIf the container platform is not configured to generate audit records with  the event result or the audit record does not contain the event result, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records that contain the event result.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-001487","SRG-APP-000100-CTR-000195","","All audit records must identify any users associated with the event within the container platform.","All audit records must identify any users associated with the event within Rancher MCM.","Without information that establishes the identity of the user associated with the events, security personnel cannot determine responsibility for the potentially harmful event.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review container platform documentation and the log files on the application server to determine if the logs contain information that establishes the identity of the user or process associated with log event data. \n\nIf the container platform does not produce logs that establish the identity of the user or process associated with log event data, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform logging system to log the identity of the user or process related to the events.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-001487","SRG-APP-000100-CTR-000200","","All audit records must identify any containers associated with the event within the container platform.","All audit records must identify any containers associated with the event within Rancher MCM.","Without information that establishes the identity of the containers offering user services or running on behalf of a user within the platform associated with audit events, security personnel cannot determine responsibility for potentially harmful events.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to generate audit records that contain the component information that generated the audit record. \n\nGenerate audit records and review the data to determine if records are generated containing the component information that generated the record. \n\nIf the container platform is not configured to generate audit records containing the component information or records are generated that do not contain the component information that generated the record, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to include the component information that generated the audit record.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3 (1)","CCI-000135","SRG-APP-000101-CTR-000205","","The container platform must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.","Rancher MCM must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.","During an investigation of an incident, it is important to fully understand what took place. Often, information is not part of the audited event due to the data's nature, security risk, or audit log size. Organizations must consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. At a minimum, the organization must audit either full-text recording of privileged commands, or the individual identities of group users, or both.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the documentation and deployment configuration to determine if the container platform is configured to generate full-text recording of privileged commands or the individual identities of group users at a minimum. \n\nHave a user execute a privileged command and review the log data to validate that the full-text or identity of the individual is being logged. \n\nIf the container platform is not meeting this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate the full-text recording of privileged commands, or the individual identities of group users, or both.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-5 b","CCI-000140","SRG-APP-000109-CTR-000215","","The container platform must take appropriate action upon an audit failure.","Rancher MCM must take appropriate action upon an audit failure.","It is critical that when the container platform is at risk of failing to process audit logs as required that it take action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.\n\nBecause availability of the services provided by the container platform, approved actions in response to an audit failure are as follows:\n\n(i) If the failure was caused by the lack of audit record storage capacity, the container platform must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.\n\n(ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the container platform must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the configuration settings to determine how the container platform components are configured for audit failures. When the audit failure is due to the lack of audit record storage, the container platform must continue generating audit records, restarting services if necessary, and overwrite the oldest audit records in a first-in-first-out manner. \n\nIf the audit failure is due to a communication to a centralized collection server, the container platform must queue audit records locally until communication is restored or the records are retrieved manually.  \n\nIf the container platform is not configured to handle audit failures appropriately, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to continue generating audit records overwriting oldest audit records in a first-in-first-out manner when the failure is due to a lack of audit record storage.   When the audit failure is due to a communication to a centralized collection server, configure the container platform to queue audit records locally until communication is restored or the records are retrieved manually.  If other actions are to be taken for audit record failures, the actions and rationale must be documented in the system security plan and risk acceptance approvals must be obtained.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-6 (4)","CCI-000154","SRG-APP-000111-CTR-000220","","The container platform components must provide the ability to send audit logs to a central enterprise repository for review and analysis.","Rancher MCM components must provide the ability to send audit logs to a central enterprise repository for review and analysis.","The container platform components must send audit events to a central managed audit log repository to provide reporting, analysis, and alert notification. Incident response relies on successful timely, accurate system analysis in order for the organization to identify and respond to possible security events.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the configuration settings to determine if the container platform components are configured to send audit events to central managed audit log repository. \n\nIf the container platform is not configured to send audit events to central managed audit log repository, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform components to send audit logs to a central managed audit log repository.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-8 a","CCI-000159","SRG-APP-000116-CTR-000235","","The container platform must use internal system clocks to generate audit record time stamps.","","Understanding when and sequence of events for an incident is crucial to understand what may have taken place. Without a common clock, the components generating audit events could be out of synchronization and would then present a picture of the event that is warped and corrupted. To give a clear picture, it is important that the container platform and its components use a common internal clock.","","Applicable - Inherently Meets","Review the container platform configuration files to determine if the internal system clock is used for time stamps. \n\nIf the container platform does not use the internal system clock to generate time stamps, this is a finding.","","Configure the container platform to use internal system clocks to generate time stamps for log records.","","CAT II","",null,"Rancher MCM uses system clocks to generate time stamps. "]
["AU-9","CCI-000162","SRG-APP-000118-CTR-000240","","The container platform must protect audit information from any type of unauthorized read access.","Rancher MCM must protect audit information from any type of unauthorized read access.","If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access.\n\nThis requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories.\n\nAdditionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine where audit information is stored. \n\nIf the audit information is not protected from any type of unauthorized read access, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to protect the storage of audit information from unauthorized read access.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-000163","SRG-APP-000119-CTR-000245","","The container platform must protect audit information from unauthorized modification.","Rancher MCM must protect audit information from unauthorized modification.","If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification.\n\nThis requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.\n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine where audit information is stored. \n\nIf the audit log data is not protected from unauthorized modification, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect the storage of audit information from unauthorized modification.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-9","CCI-000164","SRG-APP-000120-CTR-000250","","The container platform must protect audit information from unauthorized deletion.","Rancher MCM must protect audit information from unauthorized deletion.","If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design.\n\nSome commonly employed methods include: ensuring log files receive the proper file system permissions utilizing file system protections, restricting access, and backing up log data to ensure log data is retained.\n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit information may include data from other applications or be included with the audit application itself.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine where audit information is stored. \n\nIf the audit log data is not protected from unauthorized deletion, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect the storage of audit information from unauthorized deletion.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-001493","SRG-APP-000121-CTR-000255","","The container platform must protect audit tools from unauthorized access.","Rancher MCM must protect audit tools from unauthorized access.","Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform to validate container platform audit tools are protected from unauthorized access. \n\nIf the audit tools are not protected from unauthorized access, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect audit tools from unauthorized access.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-001494","SRG-APP-000122-CTR-000260","","The container platform must protect audit tools from unauthorized modification.","Rancher MCM must protect audit tools from unauthorized modification.","Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform to validate container platform audit tools are protected from unauthorized modification. \n\nIf the audit tools are not protected from unauthorized modification, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect audit tools from unauthorized modification.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-001495","SRG-APP-000123-CTR-000265","","The container platform must protect audit tools from unauthorized deletion.","Rancher MCM must protect audit tools from unauthorized deletion.","Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to validate container platform audit tools are protected from unauthorized deletion. \n\nIf the audit tools are not protected from unauthorized deletion, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to protect audit tools from unauthorized deletion.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9 (3)","CCI-001350","SRG-APP-000126-CTR-000275","","The container platform must use FIPS validated cryptographic mechanisms to protect the integrity of log information.","Rancher MCM must use FIPS validated cryptographic mechanisms to protect the integrity of log information.","To fully investigate an incident and to have trust in the audit data that is generated, it is important to put in place data protections. Without integrity protections, unauthorized changes may be made to the audit files and reliable forensic analysis and discovery of the source of malicious system activity may be degraded. Although digital signatures are one example of protecting integrity, this control is not intended to cause a new cryptographic hash to be generated every time a record is added to a log file. \n\nIntegrity protections can also be implemented by using cryptographic techniques for security function isolation and file system protections to protect against unauthorized changes.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if FIPS-validated cryptographic mechanisms are being used to protect the integrity of log information. \n\nIf FIPS-validated cryptographic mechanisms are not being used to protect the integrity of log information, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use FIPS-validated cryptographic mechanisms to protect the integrity of log information.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (3)","CCI-001749","SRG-APP-000131-CTR-000280","","The container platform must be built from verified packages.","","It is important to patch and upgrade the container platform when patches and upgrades are available. More important is to get these patches and upgrades from a known source. To validate the authenticity of any patches and upgrades before installation, the container platform must check that the files are digitally signed by sources approved by the organization.",{"$f":"VLOOKUP(\"D0008\", Sheet1!A:B,2,0)","v":"D0008 - Images are built securely\n\nRancher MCM Images are built on standard container images such as UBI7, UBI8, Alpine, and Scratch images. The required packages installed on these are verified using the standard package managers such as YUM and DNF to ensure security patches are authentic."},"Applicable - Inherently Meets","Review the container platform configuration to verify it has been built from packages that are digitally signed by known and approved sources. \n\nIf the container platform was built from packages that are not digitally signed or are from unknown or non-approved sources, this is a finding.","","Rebuild the container platform from verified packages that are digitally signed by known and approved sources.","","CAT II","",null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (3)","CCI-001749","SRG-APP-000131-CTR-000285","","The container platform must verify container images.","","The container platform must be capable of validating container images are signed and that the digital signature is from a recognized and approved source approved by the organization. Allowing any container image to be introduced into the registry and instantiated into a container can allow for services to be introduced that are not trusted and may contain malicious code, which introduces unwanted services. These unwanted services can cause harm and security risks to the hosting server, the container platform, other services running within the container platform, and the overall organization.","","Not Applicable","Review the container platform configuration to determine if container images are verified by enforcing image signing and that the image is signed recognized by an approved source. \n\nIf container images are not verified or the signature is not verified as a recognized and approved source, this is a finding.","","Configure the container platform to verify container images are digitally signed and the signature is from a recognized and approved source.","","CAT II","",null,"Container validation is outside the scope of Rancher MCM",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000290","","The container platform must limit privileges to the container platform registry.","","To control what is instantiated within the container platform, it is important to control access to the registry. Without this control, container images can be introduced and instantiated by accident or on container platform startup. Without control of the registry, security measures put in place for the runtime can be bypassed meaning the controls of approval and testing are also bypassed. Only those individuals and roles approved by the organization can have access to the container platform registry.","","Not Applicable","Review the container platform registry configuration to determine if the level of access to the registry is controlled through user privileges. \n\nAttempt to perform registry operations to determine if the privileges are enforced. \n\nIf the container platform registry is not limited through user privileges or the user privileges are not enforced, this is a finding.","","Configure the container platform to use and enforce user privileges when accessing the container platform registry.","","CAT II","",null,"Rancher MCM does not have a platform registry. ",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000295","","The container platform must limit privileges to the container platform runtime.","","To control what is instantiated within the container platform, it is important to control access to the runtime. Without this control, container platform specific services and customer services can be introduced without receiving approval and going through proper testing. Only those individuals and roles approved by the organization can have access to the container platform runtime.","","Not Applicable","Review the container platform runtime configuration to determine if the level of access to the runtime is controlled through user privileges. \n\nAttempt to perform runtime operations to determine if the privileges are enforced. \n\nIf the container platform runtime is not limited through user privileges or the user privileges are not enforced, this is a finding.","","Configure the container platform to use and enforce user privileges when accessing the container platform runtime.","","CAT II","",null,"Access to container runtime is outside the scope of Rancher MCM",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000300","","The container platform must limit privileges to the container platform keystore.","","The container platform keystore is used to store credentials used to build a trust between the container platform and some external source. This trust relationship is authorized by the organization. If a malicious user were to have access to the container platform keystore, two negative scenarios could develop:\n\n1) Keys not approved could be introduced and \n2) Approved keys deleted, leading to the introduction of container images from sources that were never approved by the organization. \n\nTo thwart this threat, it is important to protect the container platform keystore and give access to only those individuals and roles approved by the organization.","","Not Applicable","Review the container platform keystore configuration to determine if the level of access to the keystore is controlled through user privileges. \n\nAttempt to perform keystore operations to determine if the privileges are enforced. \n\nIf the container platform keystore is not limited through user privileges or the user privileges are not enforced, this is a finding.","","Configure the container platform to use and enforce user privileges when accessing the container platform keystore.","","CAT II","",null,"Keystore is managed by Kubernetes. Rancher MCM does not configure this. ",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000305","","Configuration files for the container platform must be protected.","","The secure configuration of the container platform must be protected by disallowing changes to be implemented by non-privileged users. Changes to the container platform can introduce security risks or stability issues and undermine change management procedures. Securing configuration files from non-privileged user modification can be enforced using file ownership and permissions.","","Not Applicable","Review the container platform to verify that configuration files cannot be modified by non-privileged users. \n\nIf non-privileged users can modify configuration files, this is a finding.","","Configure the container platform to only allow configuration modifications by privileged users.","","CAT II","",null,"This is accomplished outside the scope of Rancher MCM.",{"$f":"VLOOKUP(\"N0005\", Sheet1!M:N,2,0)","v":"N0005\nAudit logging in Rancher starts up when the app container starts with an ENV parameter. As stated in D0004 in this document, for all the logging there needs to have applied audit policies to the RKE2 platform as well. \n\nKubernetes has a api flag 'audit-log-mode=blocking-strict'  which actually prevents the Kube-API from proceeding with any action until it has successfully written the audit log. I have this in the RKE2 STIG under \n\nC0004\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nI don't think Rancher has this capability on it's own "}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000310","","Authentication files for the container platform must be protected.","Authentication files for Rancher MCM must be protected.","The secure configuration of the container platform must be protected by disallowing changing to be implemented by non-privileged users. Changes to the container platform can introduce security risks and stability issues and undermine change management procedures. To secure authentication files from non-privileged user modification can be enforced using file ownership and permissions.\n\nExamples of authentication files are keys, certificates, and tokens.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to verify that authentication files cannot be modified by non-privileged users. \n\nIf non-privileged users can modify key and certificate files, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to only allow authentication file modifications by privileged users.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-7 a","CCI-000381","SRG-APP-000141-CTR-000315","","The container platform must be configured with only essential configurations.","","The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed.","","Applicable - Inherently Meets","Review the container platform configuration and verify that only those components needed for operation are installed. \n\nIf components are installed that are not used for the intended purpose of the organization, this is a finding.","","Identify the role the container platform is intended to play in the production environment and remove any components that are not needed or used for the intended purpose.","","CAT II","",null,"Mike Can you elabrate on how Rancher installs the components etc…"]
["CM-7 a","CCI-000381","SRG-APP-000141-CTR-000320","","The container platform registry must contain only container images for those capabilities being offered by the container platform.","","Allowing container images to reside within the container platform registry that are not essential to the capabilities being offered by the container platform becomes a potential security risk. By allowing these non-essential container images to exist, the possibility for accidental instantiation exists. The images may be unpatched, not supported, or offer non-approved capabilities. Those images for customer services are considered essential capabilities.",null,"Not Applicable","Review the container platform registry and the container images being stored. \n\nIf container images are stored in the registry and are not being used to offer container platform capabilities, this is a finding.","","Remove all container images from the container platform registry that are not being used or contain features and functions not supported by the platform.","","CAT II","",null,"Rancher MCM allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users."]
["CM-7 b","CCI-000382","SRG-APP-000142-CTR-000325","","The container platform runtime must enforce ports, protocols, and services that adhere to the PPSM CAL.","Rancher MCM runtime must enforce ports, protocols, and services that adhere to the PPSM CAL","Ports, protocols, and services within the container platform runtime must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy.",{"$f":"VLOOKUP(\"D0011\", Sheet1!A:B,2,0)","v":"D0011 - Ports Protocols, and Services\nRancher is designed to be deployed in a Kubernetes environment, which implies it is container based. Proper hardening of the surrounding environment is independent of Rancher MCM but ensures Rancher MCM will inherently meet security requirements.\n\nProperly configured Kubernetes environments use 3rd party proxies combined with control frameworks called ingress controllers which maintain the configuration state of the proxies for external traffic. Kubernetes also has internal control over network traffic through it's software defined network (SDN). This essentially means Kubernetes controls what ports are exposed to the container from both internal and external traffic. \n\nA default deployment of Rancher MCM exposes only port 80 (HTTP traffic) and port 443 (HTTPS traffic). These ports are enforced by the rest of the Kubernetes SDN and ingress controllers. The ports the server expects are dependant on what kubernetes routes are configurable, and should be verified."},"Applicable - Configurable","Review the container platform documentation and deployment configuration to determine which ports and protocols are enabled. \n\nVerify the ports and protocols being used are not prohibited by PPSM CAL in accordance to DoD Instruction 8551.01 Policy and are necessary for the operations and applications.\n\nIf any of the ports or protocols is prohibited or not necessary for the operation, this is a finding.",{"$f":"VLOOKUP(\"C0011\", Sheet1!C:D,2,0)","v":"C0011 - Check container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable. Note that other parts of the system could override this behavior.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Ports'\nEnsure 'Publish the container port' contains a setting of 80 or 443\n\nOpen the config panel 'Command'\nEnsure the 'Command' box contains '--http-listen-port=80 --https-listen-port=443'"},"Configure the container platform to disable any ports or protocols that are prohibited by the PPSM CAL and not necessary for the operation.",{"$f":"VLOOKUP(\"F0011\", Sheet1!E:F,2,0)","v":"F0011 - Fix container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nClick the configuration button (three dots) at the top right of the screen.\nSelect 'Edit'.\n\nEnsure port mapping contains only ports 80 or 443 are present for HTTP or HTTPS traffic. Click 'Add port' if additional mappings is required.\n\nClick 'Show advanced options' at the bottom of the page.\n\nOpen the 'Command' config panel.\nEnsure 'Command' contains '--http-listen-port=80 --https-listen-port=443', add if necessary."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-7 b","CCI-000382","SRG-APP-000142-CTR-000330","","The container platform runtime must enforce the use of ports that are non-privileged.","Rancher MCM runtime must enforce the use of ports that are non-privileged.","Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container.",{"$f":"VLOOKUP(\"D0011\", Sheet1!A:B,2,0)","v":"D0011 - Ports Protocols, and Services\nRancher is designed to be deployed in a Kubernetes environment, which implies it is container based. Proper hardening of the surrounding environment is independent of Rancher MCM but ensures Rancher MCM will inherently meet security requirements.\n\nProperly configured Kubernetes environments use 3rd party proxies combined with control frameworks called ingress controllers which maintain the configuration state of the proxies for external traffic. Kubernetes also has internal control over network traffic through it's software defined network (SDN). This essentially means Kubernetes controls what ports are exposed to the container from both internal and external traffic. \n\nA default deployment of Rancher MCM exposes only port 80 (HTTP traffic) and port 443 (HTTPS traffic). These ports are enforced by the rest of the Kubernetes SDN and ingress controllers. The ports the server expects are dependant on what kubernetes routes are configurable, and should be verified."},"Applicable - Configurable","Review the container platform configuration and the containers within the platform by performing the following checks:\n\n1. Verify the container platform is configured to disallow the use of privileged ports by containers.\n2. Validate all containers within the container platform are using non-privileged ports.\n3. Attempt to instantiate a container image that uses a privileged port.\n\nIf the container platform is not configured to disallow the use of privileged ports, this is a finding.\n\nIf the container platform has containers using privileged ports, this is a finding.\n\nIf the container platform allows containers to be instantiated that use privileged ports, this is a finding.",{"$f":"VLOOKUP(\"C0011\", Sheet1!C:D,2,0)","v":"C0011 - Check container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable. Note that other parts of the system could override this behavior.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Ports'\nEnsure 'Publish the container port' contains a setting of 80 or 443\n\nOpen the config panel 'Command'\nEnsure the 'Command' box contains '--http-listen-port=80 --https-listen-port=443'"},"Configure the container platform to disallow the use of privileged ports by containers. Move any containers that are using privileged ports to non-privileged ports.",{"$f":"VLOOKUP(\"F0011\", Sheet1!E:F,2,0)","v":"F0011 - Fix container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nClick the configuration button (three dots) at the top right of the screen.\nSelect 'Edit'.\n\nEnsure port mapping contains only ports 80 or 443 are present for HTTP or HTTPS traffic. Click 'Add port' if additional mappings is required.\n\nClick 'Show advanced options' at the bottom of the page.\n\nOpen the 'Command' config panel.\nEnsure 'Command' contains '--http-listen-port=80 --https-listen-port=443', add if necessary."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000335","","The container platform must uniquely identify and authenticate users.","Rancher MCM must uniquely identify and authenticate users.","The container platform requires user accounts to perform container platform tasks. These tasks may pertain to the overall container platform or may be component-specific, thus requiring users to authenticate against those specific components. To ensure accountability and prevent unauthenticated access, users must be identified and authenticated to prevent potential misuse and compromise of the system.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if users are uniquely identified and authenticated. \n\nIf users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to uniquely identify and authenticate users.",{"$f":"VLOOKUP(\"F0002\",'[1] Sheet4'!E:F,2,0)","v":{"$error":"#N/A"}},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000340","","The container platform application program interface (API) must uniquely identify and authenticate users.","Rancher MCM application program interface (API) must uniquely identify and authenticate users.","The container platform requires user accounts to perform container platform tasks. These tasks are often performed through the container platform API. Protecting the API from users who are not authorized or authenticated is essential to keep the container platform stable. Protection of platform and application data and enhances the protections put in place for Denial-of Service (DoS) attacks.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if users are uniquely identified and authenticated before the API is executed. \n\nIf users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to uniquely identify and authenticate users before container platform API access.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000345","","The container platform must uniquely identify and authenticate processes acting on behalf of the users.","Rancher MCM must uniquely identify and authenticate processes acting on behalf of the users.","The container platform will instantiate a container image and use the user privileges given to the user used to execute the container. To ensure accountability and prevent unauthenticated access to containers, the user the container is using to execute must be uniquely identified and authenticated to prevent potential misuse and compromise of the system.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if processes acting on behalf of users are uniquely identified and authenticated. \n\nIf processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to uniquely identify and authenticate processes acting on behalf of users.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"The screen where logging aggregation is set up/administered through he Rancher GUI is protected by the Rancher RBAC. For a person to delete this they would need to have permissions allowing it. \n\nThis is separate from a user having permissions in kubernetes straight up that would allow a person to delete the logging aggregation system.\n\nThird- a person could go through the OS itself to make modifications to logging subsystems.\n\nNot sure how to properly enumerate these things."]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000350","","The container platform application program interface (API) must uniquely identify and authenticate processes acting on behalf of the users.","Rancher MCM application program interface (API) must uniquely identify and authenticate processes acting on behalf of the users.","The container platform API can be used to perform any task within the platform. Often, the API is used to create tasks that perform some kind of maintenance task and run without user interaction. To guarantee the task is authorized, it is important to authenticate the task. These tasks, even though executed without user intervention, run on behalf of a user and must run with the user's authorization. If tasks are allowed to be created without authentication, users could bypass authentication and authorization mechanisms put in place for user interfaces. This could lead to users gaining greater access than given to the user putting the container platform into a compromised state.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform API configuration to determine if processes acting on behalf of users are uniquely identified and authenticated. \n\nIf processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform API to uniquely identify and authenticate processes acting on behalf of users.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"Rancher doesn't do any log aggregation by itself, only assists with the integration. It would be on the logging aggregator, such as splunk, to provide this control."]
["IA-2 (1)","CCI-000765","SRG-APP-000149-CTR-000355","","The container platform must use multifactor authentication for network access to privileged accounts.","Rancher MCM must use multifactor authentication for network access to privileged accounts.","Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased.\n\nMultifactor authentication requires using two or more factors to achieve authentication.\n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric).\n\nA privileged account is defined as an information system account with authorizations of a privileged user.\n\nNetwork access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet).",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to privileged accounts. \n\nIf the container platform does not use multifactor authentication for network access to privileged accounts, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use multifactor authentication for network access to privileged accounts.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["IA-2 (2)","CCI-000766","SRG-APP-000150-CTR-000360","","The container platform must use multifactor authentication for network access to non-privileged accounts.","Rancher MCM must use multifactor authentication for network access to non-privileged accounts.","To ensure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.\n\nMultifactor authentication uses two or more factors to achieve authentication.\n\nFactors include: \n(i) Something you know (e.g., password/PIN); \n(ii) Something you have (e.g., cryptographic identification device, token); or \n(iii) Something you are (e.g., biometric).\n\nA non-privileged account is any information system account with authorizations of a non-privileged user.\n\nNetwork access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection.\n\nApplications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to non-privileged accounts. \n\nIf the container platform does not use multifactor authentication for network access to non-privileged accounts, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use multifactor authentication for network access to non-privileged accounts.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["IA-2 (3)","CCI-000767","SRG-APP-000151-CTR-000365","","The container platform must use multifactor authentication for local access to privileged accounts.","","To ensure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.\n\nMultifactor authentication is defined as using two or more factors to achieve authentication.\n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric).\n\nA privileged account is defined as an information system account with authorizations of a privileged user.\n\nLocal access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.","","Not Applicable","Review the container platform configuration to determine if multifactor authentication is used for local access to privileged accounts. \n\nIf multifactor authentication for local access to privileged accounts is not being used, this is a finding.","","Configure the container platform to use multifactor authentication for local access to privileged accounts.","","CAT II","",null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["IA-2 (4)","CCI-000768","SRG-APP-000152-CTR-000370","","The container platform must use multifactor authentication for local access to non-privileged accounts.","","To ensure accountability, prevent unauthenticated access, and prevent misuse of the system, non-privileged users must utilize multi-factor authentication for local access.\n\nMultifactor authentication is defined as using two or more factors to achieve authentication.\n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric).\n\nA non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user.\n\nLocal access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.","","Not Applicable","Review the container platform configuration to determine if multifactor authentication is used for local access to non-privileged accounts. \n\nIf multifactor authentication for local access to non-privileged accounts is not being used, this is a finding.","","Configure the container platform to use multifactor authentication for local access to non-privileged accounts.","","CAT II","",null,{"$f":"VLOOKUP(\"N0009\", Sheet1!M:N,2,0)","v":"N0009 - Rancher MCM is a container running on a kubernetes platform\nRancher does not provide the capability of modifying the container Runtime. \n\nIt also does not have access to the full filesystem of the underlying OS. Only certain paths are mounted to the Rancher containers."}]
["IA-2 (5)","CCI-000770","SRG-APP-000153-CTR-000375","","The container platform must ensure users are authenticated with an individual authenticator prior to using a group authenticator.","Rancher MCM must ensure users are authenticated with an individual authenticator prior to using a group authenticator.","To ensure individual accountability and prevent unauthorized access, application users must be individually identified and authenticated.\n\nIndividual accountability mandates that each user be uniquely identified. A group authenticator is a shared account or some other form of authentication that allows multiple unique individuals to access the application using a single account.\n\nIf an application allows or provides for group authenticators, it must first individually authenticate users prior to implementing group authenticator functionality.\n\nSome applications may not need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.\n\nThere may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server, which contains publicly releasable information.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Not Applicable","Review the container platform configuration to determine if the container platform is configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator. \n\nIf the container platform is not configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator, this is a finding.","","Configure the container platform to ensure users are authenticated with an individual authenticator prior to using a group authenticator.","","CAT II","",null,{"$f":"VLOOKUP(\"N0009\", Sheet1!M:N,2,0)","v":"N0009 - Rancher MCM is a container running on a kubernetes platform\nRancher does not provide the capability of modifying the container Runtime. \n\nIt also does not have access to the full filesystem of the underlying OS. Only certain paths are mounted to the Rancher containers."}]
["IA-2 (8)","CCI-001941","SRG-APP-000156-CTR-000380","","The container platform must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.","","A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAnti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoD PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also compliant.\n\nConfigure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.","","Not Applicable","Review the container platform configuration to determine if the container platform is configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. \n\nIf the container platform is not configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts, this is a finding.","","Configure the container platform to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.","","CAT II","",null,{"$f":"VLOOKUP(\"N0009\", Sheet1!M:N,2,0)","v":"N0009 - Rancher MCM is a container running on a kubernetes platform\nRancher does not provide the capability of modifying the container Runtime. \n\nIt also does not have access to the full filesystem of the underlying OS. Only certain paths are mounted to the Rancher containers."}]
["IA-2 (9)","CCI-001942","SRG-APP-000157-CTR-000385","","The container platform must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.","","A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.\n\nA non-privileged account is any operating system account with authorizations of a non-privileged user.\n\nTechniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.","","Applicable - Inherently Meets","Review the container platform configuration to determine if the container platform is configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts. \n\nIf the container platform is not configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts, this is a finding.","","Configure the container platform to provide replay-resistant authentication mechanisms for network access to non-privileged accounts.","","CAT II","",null,"Rancher MCM protects all keys and secrets it has control over via RBAC. ","Example would be access keys and tokens. Host files are not controlled by Rancher so things like node-node certificates and keys are not under Ranchers control. Rancher also can't see node-tokens generated by RKE2. These would need OS file permission protection and OS level authentication."]
["IA-3","CCI-000778","SRG-APP-000158-CTR-000390","","The container platform must uniquely identify all network-connected nodes before establishing any connection.","","A container platform usually consists of multiple nodes. It is important for these nodes to be uniquely identified before a connection is allowed. Without identifying the nodes, unidentified or unknown nodes may be introduced, thereby facilitating malicious activity.","","Not Applicable","Review the container platform configuration to determine if the container platform uniquely identifies all nodes before establishing a connection. \n\nIf the container platform is not configured to uniquely identify all nodes before establishing the connection, this is a finding.","","Configure the container platform to uniquely identify all nodes before establishing the connection.","","CAT II","",null,"Basic installation of Rancher does not enable any non-required items."]
["IA-4 e","CCI-000795","SRG-APP-000163-CTR-000395","","The container platform must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.","Rancher MCM must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.","Inactive identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.\n\nApplications need to track periods of inactivity and disable application identifiers after 35 days of inactivity.\n\nManagement of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual.\n\nTo avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity. \n\nIf identifiers are not disabled after 35 days of inactivity, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["IA-5 (1) (a)","CCI-000205","SRG-APP-000164-CTR-000400","","The container platform must enforce a minimum 15-character password length.","Rancher MCM must enforce a minimum 15-character password length.","The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.\n\nPassword complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.\n\nUse of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform enforces a minimum 15-character password length. \n\nIf the container platform does not enforce a 15-character password length, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce a minimum 15-character password length.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0011\", Sheet1!M:N,2,0)","v":"Rancher MCM is a web application. RKE2 hosts kubernetes and all ports associated with that with a few extras like 6443 and 9345\n\nD0012 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n"}]
["IA-5 (1) (e)","CCI-000200","SRG-APP-000165-CTR-000405","","The container platform must prohibit password reuse for a minimum of 10 generations.","Rancher MCM must prohibit password reuse for a minimum of 10 generations.","Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals.\n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the result is a password that is not changed as per policy requirements.\n\nThe references for this check are:\nNIST SP 800-53 :: IA-5 (1) (e)\nNIST SP 800-53A :: IA-5 (1).1 (v)\nNIST SP 800-53 Revision 4 :: IA-5 (1)\nCNSS 1253",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it prohibits password reuse for a minimum of five generations. \n\nIf the container platform does not prohibit password reuse for a minimum of five generations, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to prohibit password reuse for a minimum of five generations.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0011\", Sheet1!M:N,2,0)","v":"Rancher MCM is a web application. RKE2 hosts kubernetes and all ports associated with that with a few extras like 6443 and 9345\n\nD0012 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n"}]
["IA-5 (1) (a)","CCI-000192","SRG-APP-000166-CTR-000410","","The container platform must enforce password complexity by requiring that at least one uppercase character be used.","Rancher MCM must enforce password complexity by requiring that at least one uppercase character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one uppercase character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one uppercase character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one uppercase character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (a)","CCI-000193","SRG-APP-000167-CTR-000415","","The container platform must enforce password complexity by requiring that at least one lowercase character be used.","Rancher MCM must enforce password complexity by requiring that at least one lowercase character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one lowercase character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one lowercase character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one lowercase character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (a)","CCI-000194","SRG-APP-000168-CTR-000420","","The container platform must enforce password complexity by requiring that at least one numeric character be used.","Rancher MCM must enforce password complexity by requiring that at least one numeric character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one numeric character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one numeric character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one numeric character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (a)","CCI-001619","SRG-APP-000169-CTR-000425","","The container platform must enforce password complexity by requiring that at least one special character be used.","Rancher MCM must enforce password complexity by requiring that at least one special character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nSpecial characters are those characters that are not alphanumeric. Examples include ~ ! @ # $ % ^ *.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one special character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one special character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one special character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (b)","CCI-000195","SRG-APP-000170-CTR-000430","","The container platform must require the change of at least 15 of the total number of characters when passwords are changed.","Rancher MCM must require the change of at least 15 of the total number of characters when passwords are changed.","If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.\n\nThe number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it requires the change of at least 15 of the total number of characters when passwords are changed. \n\nIf the container platform does not require the change of at least 15 of the total number of characters when passwords are changed, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to require the change of at least 15 of the total number of characters when passwords are changed.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (c)","CCI-000196","SRG-APP-000171-CTR-000435","","For container platform using password authentication, the application must store only cryptographic representations of passwords.","Rancher MCM using password authentication, the application must store only cryptographic representations of passwords.","Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication.\n\nExamples of situations where a user ID and password might be used include:\n\n- When the user does not use a CAC and is not a current DoD employee, member of the military, or DoD contractor.\n\n- When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied.\n\n- When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection.\n\nIf the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security.\n\nVerifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows:\n\nH0 = H(pwd, H(salt))\nHn = H(Hn-1,H(salt))\n\nIn the above, \"n\" is a cryptographically-strong random [*3] number. \"Hn\" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares \"Hn\" with the stored \"Hn\". A salt is essentially a fixed-length cryptographically strong random value.\n\nAnother method is using a keyed-hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key.\n\nThis requirement applies to all accounts including authentication server, AAA, and local account, including the root account and the account of last resort.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it using password authentication and stores only cryptographic representations of the passwords. \n\nIf the container platform is using password authentication and does not store only cryptographic representations of passwords, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to store only cryptographic representations of passwords if passwords are being used for authentication.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (c)","CCI-000197","SRG-APP-000172-CTR-000440","","For accounts using password authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.","For accounts using password authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.","Passwords need to be protected on entry, in transmission, during authentication, and when stored. If compromised at any of these security points, a nefarious user can use the password along with stolen user account information to gain access or to escalate privileges. The container platform may require account authentication during container platform tasks and before accessing container platform components, e.g. runtime, registry, and keystore.\n\nDuring any user authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the documentation and configuration to determine if the container platform enforces the required FIPS-validated encrypt passwords when they are transmitted. \n\nIf the container platform is not configured to meet this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to transmit only encrypted FIPS-validated SHA-2 or later representations of passwords.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT I","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (d)","CCI-000198","SRG-APP-000173-CTR-000445","","The container platform must enforce 24 hours (one day) as the minimum password lifetime.","Rancher MCM must enforce 24 hours (one day) as the minimum password lifetime.","Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement.\n\nRestricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy-based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces 24 hours/1 day as the minimum password lifetime. \n\nIf the container platform does not enforce 24 hours/1 day as the minimum password lifetime, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce 24 hours/1 day as the minimum password lifetime.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (d)","CCI-000199","SRG-APP-000174-CTR-000450","","The container platform must enforce a 60-day maximum password lifetime restriction.","Rancher MCM must enforce a 60-day maximum password lifetime restriction.","Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. \n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. \n\nThis requirement does not include emergency administration accounts that are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces a 60-day maximum password lifetime restriction. \n\nIf the container platform does not enforce a 60-day maximum password lifetime restriction, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce a 60-day maximum password lifetime restriction.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"This might be RBAC, but upgrading Rancher is technically done out of band from Ranchers capability itself. An cattle-system namespace administrator external of Rancher with Rancher or Kube credentials needs to update using Helm. If that makes any sense at all. This might be N/A"]
["IA-5 (2) (c)","CCI-000187","SRG-APP-000177-CTR-000465","","The container platform must map the authenticated identity to the individual user or group account for PKI-based authentication.","Rancher MCM must map the authenticated identity to the individual user or group account for PKI-based authentication.","The container platform and its components may require authentication before use. When the authentication is PKI-based, the container platform or component must map the certificate to a user account. If the certificate is not mapped to a user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation and configuration to ensure the container platform provides a PKI integration capability that meets DoD PKI infrastructure requirements. \n\nIf the container platform is not configured to meet this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to utilize the DoD Enterprise PKI infrastructure.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-6","CCI-000206","SRG-APP-000178-CTR-000470","","The container platform must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.","Rancher MCM must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.","To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the container platform and its components, e.g., runtime, registry, and keystore, must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.\n\nObfuscation of user-provided information when typed is a method used in addressing this risk.\n\nDisplaying asterisks when a user types in a password is an example of obscuring feedback of authentication information.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review container platform documentation and configuration to determine if any interfaces that are provided for authentication purposes display the user's password when it is typed into the data entry field. \n\nIf authentication information is not obfuscated when entered, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-7 a","CCI-001876","SRG-APP-000181-CTR-000485","","The container platform must provide an audit reduction capability that supports on-demand reporting requirements.","Rancher MCM must provide an audit reduction capability that supports on-demand reporting requirements.","The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. \n\nAudit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports.\n\nThis requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to provide an audit reduction capability that supports on-demand reporting requirements. \n\nIf the container platform is not configured to support on-demand reporting requirements, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to support on-demand reporting requirements.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["MA-4 c","CCI-000877","SRG-APP-000185-CTR-000490","","The container platform must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.","Rancher MCM must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.","If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information, and potentially sensitive application data.\n\nNon-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.\n\nThis requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing \"ping,\" \"ls,\" \"ipconfig,\" or the hardware and software implementing the monitoring port of an Ethernet switch).",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. \n\nIf the container platform is not configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-10","CCI-001133","SRG-APP-000190-CTR-000500","","The application must terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity;","","Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. \n\nTerminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection. This does not mean that the application terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.","","Applicable - Inherently Meets","This requirement is NA for this technology.","","The requirement is NA. No fix is required.","","CAT II","",null," All ports used by Rancher are needed by default."]
["SC-2","CCI-001082","SRG-APP-000211-CTR-000530","","The container platform must separate user functionality (including user interface services) from information system management functionality.","","Separating user functionality from management functionality is a requirement for all the components within the container platform. Without the separation, users may have access to management functions that can degrade the container platform and the services being offered and can offer a method to bypass testing and validation of functions before introduced into a production environment.\n\nThe separation should be enforced by each component within the container platform.","","Applicable - Inherently Meets","Review the container platform configuration to determine if management functionality is separated from user functionality. \n\nValidate that the separation is also implemented within the components by trying to execute management functions for each component as a user. \n\nIf the container platform is not configured to separate management and user functionality or if component management and user functionality are not separated, this is a finding.",null,"Configure the container platform and its components to separate management and user functionality.","","CAT II","",null,"Management and User fuctionality is separated by default. ",{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-23","CCI-001184","SRG-APP-000219-CTR-000550","","The container platform must protect authenticity of communications sessions with the use of FIPS-validated 140-2 or 140-3 security requirements for cryptographic modules.","","The container platform is responsible for pulling images from trusted sources and placing those images into its registry. To protect the transmission of images, the container platform must use FIPS-validated 140-2 or 140-3 cryptographic modules. This added protection defends against main-in-the-middle attacks where malicious code could be added to an image during transmission.","","Not Applicable","Review the container platform configuration to determine if FIPS-validated 140-2 or 140-3 cryptographic modules are being used to protect container images during transmission. \n\nIf FIPS-validated 140-2 or 140-3 cryptographic modules are not being use, this is a finding.","","Configure the container platform to use FIPS-validated 140-2 or 140-3 cryptographic modules to protect container images during transmission.","","CAT I","",null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["SC-24","CCI-001190","SRG-APP-000225-CTR-000570","","The container platform runtime must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.","","The container platform offers services for container image orchestration and services for users. If any of these services were to fail into an insecure state, security measures for user and data separation and image instantiation could become absent. In addition, audit log protections could be relaxed allowing for investigation of what occurred could be lost. To protect services and data, it is important for the container platform to fail to a secure state if the container platform registry initialization fails, shutdown fails, or aborts fail.","","Not Applicable","Review documentation and configuration to determine if the container platform runtime fails to a secure state if system initialization fails, shutdown fails, or aborts fail. \n\nIf the container platform runtime cannot be configured to fail securely, this is a finding.","","Configure the container platform runtime to fail to a secure state if system initialization fails, shutdown fails, or aborts fail.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-24","CCI-001665","SRG-APP-000226-CTR-000575","","The container platform must preserve any information necessary to determine the cause of the disruption or failure.","","When a failure occurs within the container platform, preserving the state of the container platform and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.","","Not Applicable","Review the container platform configuration to determine if information necessary to determine the cause of a disruption or failure is preserved. \n\nIf the information is not preserved, this is a finding.","","Configure the container platform to preserve information necessary to determine the cause of the disruption or failure.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-3","CCI-001084","SRG-APP-000233-CTR-000585","","The container platform runtime must isolate security functions from non-security functions.","","The container platform runtime must be configured to isolate those services used for security functions from those used for non-security functions. This separation can be performed using environment variables, labels, network segregation, and kernel groups.","","Not Applicable","Verify container platform runtime configuration settings to determine whether container services used for security functions are located in an isolated security function such as a separate environment variables, labels, network segregation, and kernel groups.\n\nIf security-related functions are not separate, this is a finding.","","Configure the container platform runtime to isolate security functions from non-security functions.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (2)","CCI-001682","SRG-APP-000234-CTR-000590","","The container platform must never automatically remove or disable emergency accounts.","","Emergency accounts are administrator accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability.\n\nEmergency accounts are different from infrequently used accounts (i.e., local logon accounts used by system administrators when network or normal logon/access is not available). Infrequently used accounts also remain available and are not subject to automatic termination dates. However, an emergency account is normally a different account that is created for use by vendors or system maintainers.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0003\", Sheet1!A:B,2,0)","v":"D0003 - Temporary/Initial administrator accounts\nRancher MCM requires the set up of an initial administrator account when first launched. This administrative user is used to configure the portions of Rancher MCM. Once another form of authn/authz is configured this user is no longer needed and needs to be manually removed as it has unlimited privileges by default.   "},"Applicable - Inherently Meets","Review the container platform to determine if emergency accounts are automatically removed or disabled. \n\nIf emergency accounts are automatically removed or disabled, this is a finding.","","Configure the container platform to never remove or disable emergency accounts.","","CAT II","",null,"When Rancher MCM is first set up it creates a local auth administrator account. This account does not go away automatically and is considered an emergency account.",{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-4","CCI-001090","SRG-APP-000243-CTR-000595","","The container platform must prohibit containers from accessing privileged resources.","","Containers images instantiated within the container platform may request access to host system resources. Access to privileged resources can allow for unauthorized and unintended transfer of information, but in some cases, these resources may be needed for the service being offered by the container. By default, containers should be denied instantiation when privileged system resources are requested and granted only after approval has been given.\n\nWhen access to privileged resources is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged access to host system resources.\n\nExamples of system resources that should be protected are kernel namespaces and host system sensitive directories such as /etc and /usr.","","Not Applicable","Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to access host system privileged resources. \n\nIf the container platform does not block containers requesting host system privileged resources, this is a finding.","","Configure the container platform to block instantiation of containers requesting access to host system-privileged resources.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-4","CCI-001090","SRG-APP-000243-CTR-000600","","The container platform must prevent unauthorized and unintended information transfer via shared system resources.","","The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users.","","Not Applicable","Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process. \n\nIf the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding.","","Deploy a container platform capable of effectively protecting the resources of one process or user from unauthorized access by another user or process. Configure the container platform to effectively protect the resources of one process or user from unauthorized access by another user or process. The container security solution should help the user understand where the code in the environment was deployed from, and provide controls that prevent deployment from untrusted sources or registries.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-5 (1)","CCI-001094","SRG-APP-000246-CTR-000605","","The container platform must restrict individuals' ability to launch organizationally defined denial-of-service (DoS) attacks against other information systems.","","The container platform will offer services to users and these services share resources available on the hosting system. To share the resources in a manner that does not exhaust or over utilize resources, it is necessary for the container platform to have mechanisms that allow developers to size there containers to provide minimum and maximum amounts. If there is no mechanism to specify limits, container services can cause DoS by over utilization.","","Not Applicable","Review the container platform implementation and security documentation and components settings to determine if the information system restricts the ability of users or systems to launch organization-defined DoS attacks against other information systems or networks from the container platform. \n\nIf the container platform is not configured to restrict this ability, this is a finding.","","Configure the container platform to restrict the ability of users or other systems to launch DoS attacks from the container platform components by setting resource quotas on resources such as memory, storage, and CPU utilization.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SI-11 a","CCI-001312","SRG-APP-000266-CTR-000625","","The container platform must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.","","The container platform is responsible for offering services to users. These services could be across diverse user groups and data types. To protect information about the container platform, services, users, and data, it is important during error message generation to offer enough information to diagnose the error, but not reveal information that needs to be protected.","","Not Applicable","Review documentation and logs to determine if the container platform writes sensitive information such as passwords or private keys into the logs and administrative messages. \n\nIf the container platform writes sensitive or potentially harmful information into the logs and administrative messages, this is a finding.","","Configure the container platform to not write sensitive information into the logs and administrative messages.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-9 (3)","CCI-001496","SRG-APP-000290-CTR-000670","","The container platform must use cryptographic mechanisms to protect the integrity of audit tools.","Rancher MCM must use cryptographic mechanisms to protect the integrity of audit tools.","Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nAudit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.\n\nIt is common for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.\n\nTo address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if the integrity of the audit tools is protected using cryptographic mechanisms. \n\nIf audit tools are not protected through cryptographic mechanisms, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use cryptographic mechanisms to protect the integrity of audit tools.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-001683","SRG-APP-000291-CTR-000675","","The container platform must notify system administrators and ISSO when accounts are created.","","Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Sending notification of account creation events to the system administrator and ISSO is one method for mitigating this risk.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are created. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are created.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-2 (4)","CCI-001684","SRG-APP-000292-CTR-000680","","The container platform must notify system administrators and ISSO when accounts are modified.","","When application accounts are modified, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account modification events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are modified. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are modified.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-2 (4)","CCI-001685","SRG-APP-000293-CTR-000685","","The container platform must notify system administrators and ISSO for account disabling actions.","","When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account disabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are disabled. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are disabled.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-2 (4)","CCI-001686","SRG-APP-000294-CTR-000690","","The container platform must notify system administrators and ISSO for account removal actions.","","When application accounts are removed, user accessibility is affected. Accounts are utilized for identifying users or for identifying the application processes themselves. Sending notification of account removal events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time, and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are removed. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are removed.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-12 (1)","CCI-002364","SRG-APP-000297-CTR-000705","","Access to the container platform must display an explicit logout message to user indicating the reliable termination of authenticated communication sessions.","","Access to the container platform will occur through web and terminal sessions. Any web interfaces must conform to application and web security requirements. Terminal access to the container platform and its components must provide a logout facility that terminates the connection to the component or the platform.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Inherently Meets","Review documentation and configuration settings to determine if the container platform displays a logout message. \n\nIf the container platform does not display a logout message, this is a finding.",null,"Configure the container platform components to display an explicit logout message to users.",null,"CAT III","",null,"Rancher MCM provides a logout message by default in the core install. This is not configurable. ",{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (10)","CCI-002142","SRG-APP-000317-CTR-000735","","The container platform must terminate shared/group account credentials when members leave the group.","Rancher MCM must terminate shared/group account credentials when members leave the group.","If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. A shared/group account credential is a shared form of authentication that allows multiple individuals to access the application using a single account. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. Examples of credentials include passwords and group membership certificates.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Determine if the container platform is configured to terminate shared/group account credentials when members leave the group. \n\nIf the container platform does not terminated shared/group account credentials when members leave the group, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to terminate shared/group account credentials when members leave the group.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,{"$f":"VLOOKUP(\"n0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (11)","CCI-002145","SRG-APP-000318-CTR-000740","","The container platform must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.","Rancher MCM must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.","Activity under unusual conditions can indicate hostile activity. For example, what is normal activity during business hours can indicate hostile activity if it occurs during off hours.\n\nDepending on mission needs and conditions, account usage restrictions based on conditions and circumstances may be critical to limit access to resources and data to comply with operational or mission access control requirements. Thus, the application must be configured to enforce the specific conditions or circumstances under which application accounts can be used (e.g., by restricting usage to certain days of the week, time of day, or specific durations of time).",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Determine if the container platform is configured to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts. \n\nIf the container platform does not enforce organization-defined circumstances and/or usage conditions for organization-defined accounts, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,{"$f":"VLOOKUP(\"n0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-002130","SRG-APP-000319-CTR-000745","","The container platform must automatically audit account-enabling actions.","Rancher MCM must automatically audit account-enabling actions.","Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Automatically auditing account enabling actions provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Determine if the container platform is configured to automatically audit account-enabling actions. \n\nIf the container platform is not configured to automatically audit account-enabling actions, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account-enabling actions.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,{"$f":"VLOOKUP(\"n0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-002132","SRG-APP-000320-CTR-000750","","The container platform must notify system administrator and ISSO of account enabling actions.","","Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Sending notification of account enabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nIn order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals so they can investigate the event.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Determine if the container platform is configured to notify system administrator and ISSO of account enabling actions.\n\nIf the container platform is not configured to notify system administrator and ISSO of account enabling actions, this is a finding.","","Configure the container platform to notify system administrator and ISSO of account enabling actions.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-6 (10)","CCI-002235","SRG-APP-000340-CTR-000770","","The container platform must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.","Rancher MCM must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.","Controlling what users can perform privileged functions prevents unauthorized users from performing tasks that may expose data or degrade the container platform. When users are not segregated into privileged and non-privileged users, unauthorized individuals may perform tasks such as deploying containers, pulling images into the register, and modify keys in the keystore. These actions can introduce malicious containers and cause denial-of-service (DoS) attacks and undermine the container platform integrity. The enforcement may take place at the container platform and can be implemented within each container platform component (e.g. runtime, registry, and keystore).",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation to obtain the definition of the container platform functionality considered privileged in the context of the information system in question. \n\nReview the container platform security configuration and/or other means used to protect privileged functionality from unauthorized use. \n\nIf the configuration does not protect all of the actions defined as privileged, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to security to protect all privileged functionality. Assigning roles that limit what actions a particular user can perform are the most common means of meeting this requirement.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,{"$f":"VLOOKUP(\"n0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-6 (8)","CCI-002233","SRG-APP-000342-CTR-000775","","Container images instantiated by the container platform must execute using least privileges.","","Containers running within the container platform must execute as non-privileged. When a container can execute as a privileged container, the privileged container is also a privileged user within the hosting system, and the hosting system becomes a major security risk. It is important for the container platform runtime to validate the container user and disallow instantiation if the container is trying to execute with more privileges than required, as a privileged user, or is trying to perform a privilege escalation.\n\nWhen privileged access is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged execution.\n\nExamples of privileged users are root, admin, and default service accounts for the container platform.",null,"Not Applicable","Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to execute with more privileges than required or with privileged permissions. \n\nIf the container platform does not block containers requesting privileged permissions, privilege escalation, or allows containers to have more privileges than required, this is a finding.","","Configure the container platform to block instantiation with no more privileges than necessary.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-6 (9)","CCI-002234","SRG-APP-000343-CTR-000780","","The container platform must audit the execution of privileged functions.","Rancher MCM must audit the execution of privileged functions.","Privileged functions within the container platform can be component specific or can envelope the entire container platform. Because of the nature of the commands, it is important to understand what command was executed for either investigation of an incident or for debugging/error correction; therefore, privileged function execution must be audited.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review container platform documentation and log configuration to verify the application server logs privileged activity. \n\nIf the container platform is not configured to log privileged activity, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to log privileged activity.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,{"$f":"VLOOKUP(\"n0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Is this saying all things around the platform should be STIGed? So automatic inherited?"]
["AC-7 b","CCI-002238","SRG-APP-000345-CTR-000785","","The container platform must automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.","","By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Determine if the container platform is configured to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. \n\nIf the container platform is not configured to lock the account, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["AU-4","CCI-001849","SRG-APP-000357-CTR-000800","","The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.","Rancher MCM must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.","In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity.\n\nThe task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements. \n\nIf audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,"There are lots of tools that are certified integrations, like RBAC Authn/Authz, Monitoring, Logging, Service Mesh. Rancher can do it all. In some cases super easy, like point and click. There are runtime scanners that can also be installed but it is not part of the Core Rancher deployment like all the other things mentioned. Not sure how to approach these kinds of things."]
["AU-4 (1)","CCI-001851","SRG-APP-000358-CTR-000805","","Audit records must be stored at a secondary location.","Audit records must be stored at a secondary location.","Auditable events are used in the investigation of incidents and must be protected from being deleted or altered. Often, events that took place in the past must be viewed to understand the entire incident. For the purposes of audit event protection and recall, audit events are often off-loaded to an external storage location. The container platform must provide a mechanism to assist in the off-loading of the audit data or at a minimum, must not hinder an external process used for audit event off-loading.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Verify the log records are being off-loaded to a separate system or transferred from the container platform storage location to a storage location other than the container platform itself. \n\nThe information system may demonstrate this capability using a log management application, system configuration, or other means. \n\nIf logs are not being off-loaded, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to off-load the logs to a remote log or management server.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,"This relates to the conversation we had about how incomming web app traffic to rancher goes through the ingress controller. This ingress controller needs to be configured to use strong TLS settings. Technically Rancher can configure this through the UI.\n\nSee the mitigation in the RKE2 STIG:\n\nM0001\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l","M0001 - secure kubernetes ingress\nThis requirement can be mitigated by setting Kubernetes object configuration and configuring the ingress controller used by your organization to ensure traffic entering the internal cluster network is terminated using DoD-approved certificates and use NSA-approved encryption ciphers \n\nExample Configuration for making an Nginx ingress controller reencrypt external traffic for internal use.\nExample command to alter the ingress configuration:\n'kubectl edit ingress rancher'\nExample annotations to ensure traffic from the ingress to the pod is encrypted\n'nginx.ingress.kubernetes.io/backend-protocol: ''HTTPS'''\nor\n'nginx.ingress.kubernetes.io/ssl-passthrough'\n\nExample configuration to limit TLS ciphers, and enforce TLS versions in an Nginx ingress controller \n'''\nkind: ConfigMap\napiVersion: v1\nmetadata:\n  name: nginx-config\ndata:\n  ssl-ciphers: ''ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA''\n  ssl-protocols: ''TLSv1 TLSv1.1 TLSv1.2 TLSv1.3''\n'''\n\nMost ingress controllers allow for supplying certificates for terminating external traffic coming into the internal cluster network. These certificates should be DoD-approved and the controller should be configured to only use NSA-approved encryption ciphers.\n\nExample Nginx settings for mitigating DDOS attacks. Defined here: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#rate-limiting\nnginx.ingress.kubernetes.io/limit-connections: number of concurrent connections allowed from a single IP address. A 503 error is returned when exceeding this limit.\nnginx.ingress.kubernetes.io/limit-rps: number of requests accepted from a given IP each second. The burst limit is set to this limit multiplied by the burst multiplier, the default multiplier is 5. When clients exceed this limit, limit-req-status-code default: 503 is returned.\nnginx.ingress.kubernetes.io/limit-rpm: number of requests accepted from a given IP each minute. The burst limit is set to this limit multiplied by the burst multiplier, the default multiplier is 5. When clients exceed this limit, limit-req-status-code default: 503 is returned.\nnginx.ingress.kubernetes.io/limit-burst-multiplier: multiplier of the limit rate for burst size. The default burst multiplier is 5, this annotation override the default multiplier. When clients exceed this limit, limit-req-status-code default: 503 is returned.\nnginx.ingress.kubernetes.io/limit-rate-after: initial number of kilobytes after which the further transmission of a response to a given connection will be rate limited. This feature must be used with proxy-buffering enabled.\nnginx.ingress.kubernetes.io/limit-rate: number of kilobytes per second allowed to send to a given connection. The zero value disables rate limiting. This feature must be used with proxy-buffering enabled.\nnginx.ingress.kubernetes.io/limit-whitelist: client IP source ranges to be excluded from rate-limiting. The value is a comma separated list of CIDRs.\n\n---\n\nExample command to alter the ingress configuration:\n'kubectl edit ingress rancher'\n> Note: Ensure ingress outbound port is going to service port 443\n\nExample command to alter the service configuration:\n'kubectl edit svc rancher'\n> Note: Ensure pod port is going to pod port 443, and incomming port is 443\n\nExample command to alter the deployment configuration:\n'kubectl edit deploy rancher'\n> Note: Ensure container port is 443\n\n---\n\nThe following environment variables are available for supplying to the Rancher server to limit the TLS encryption version and ciphers used internally.\n\nCATTLE_TLS_MIN_VERSION\t1.2\nCATTLE_TLS_CIPHERS\n\nAllowed TLS cipher suites:\nTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,\nTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,\nTLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,\nTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,\nTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,\nTLS_ECDHE_RSA_WITH_CHACHA20_POLY1305\n\n---\n\nAdditional tools, such as Istio and LinkerD, are available to provide mutual authentication and additonal security features."]
["AU-5 (1)","CCI-001855","SRG-APP-000359-CTR-000810","","The container platform must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.","Rancher MCM must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.","If security personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity. \n\nIf the container platform is not configured to provide an immediate real-time alert, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to provide an immediate real-time alert to the SA and ISSO when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-5 (2)","CCI-001858","SRG-APP-000360-CTR-000815","","The container platform must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.","Rancher MCM must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.","It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts. \n\nIf the container platform is not configured to provide an immediate real-time alert, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-8 b","CCI-001890","SRG-APP-000374-CTR-000865","","All audit records must use UTC or GMT time stamps.","All audit records must use UTC or GMT time stamps.","The container platform and its components must generate audit records using either Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) time stamps or local time that offset from UTC. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform.\n\nTime stamps generated by the container platform and its components must include date and time.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform documentation and configuration files to determine if time stamps for log records can be mapped to UTC or GMT or local time that offsets from UTC. \n\nIf the time stamp cannot be mapped to UTC or GMT, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use UTC or GMT or local time that offset from UTC based time stamps for log records.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-8 b","CCI-001889","SRG-APP-000375-CTR-000870","","The container platform must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.","Rancher MCM must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.","To properly investigate an event, it is important to have enough granularity within the time stamps to determine the chronological order of the audited events. Without this granularity, events may be interpreted out of proper sequence, thus hobbling the investigation or causing the investigation to come to inaccurate conclusions.\n\nTime stamps generated by the container platform include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform documentation and configuration files to determine if time stamps for log records meet a granularity of one second. \n\nIf the time stamp cannot generate to a one-second granularity, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use time stamps for log records that can meet a granularity of one second.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-11 (2)","CCI-001812","SRG-APP-000378-CTR-000880","","The container platform must prohibit the installation of patches and updates without explicit privileged status.","Rancher MCM must prohibit the installation of patches and updates without explicit privileged status.","Controlling access to those users and roles responsible for patching and updating the container platform reduces the risk of untested or potentially malicious software from being installed within the platform. This access may be separate from the access required to install container images into the registry and those access requirements required to instantiate an image into a service. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if patches and updates can only be installed through accounts with privileged status. \n\nAttempt to install a patch or upgrade using a non-privileged user account. \n\nIf patches or updates can be installed using a non-privileged account or the container platform is not configured to stop the installation using a non-privileged account, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to only allow patch installation and upgrades using privileged accounts.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-11 (2)","CCI-001812","SRG-APP-000378-CTR-000885","","The container platform runtime must prohibit the instantiation of container images without explicit privileged status.","Rancher MCM runtime must prohibit the instantiation of container images without explicit privileged status.","Controlling access to those users and roles responsible for container image instantiation reduces the risk of untested or potentially malicious containers from being executed within the platform and on the hosting system. This access may be separate from the access required to install container images into the registry and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform runtime configuration to determine if only accounts given specific container instantiation privileges can execute the container image instantiation process. \n\nAttempt to instantiate a container image using an account that does not have the proper privileges to execute the process. \n\nIf container images can be instantiated using an account without the proper privileges, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "}," Configure the container platform runtime to prohibit the instantiation of container images without explicit container image instantiation privileges given to users.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT I","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-11 (2)","CCI-001812","SRG-APP-000378-CTR-000890","","The container platform registry must prohibit installation or modification of container images without explicit privileged status.","Rancher MCM registry must prohibit installation or modification of container images without explicit privileged status.","Controlling access to those users and roles that perform container platform registry functions reduces the risk of untested or potentially malicious containers from being introduced into the platform. This access may be separate from the access required to instantiate container images into services and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review container platform registry security settings with respect to non-administrative users' ability to create, alter, or replace container images. \n\nIf any such permissions exist and are not documented and approved, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Document and obtain approval for any non-administrative users who require the ability to create, alter, or replace container images within the container platform registry. Implement the approved permissions. Revoke any unapproved permissions.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"Rancher MCM is only accessible through the web api or web GUI. I imagine that means this is N/A"]
["CM-5 (1)","CCI-001813","SRG-APP-000380-CTR-000900","","The container platform must enforce access restrictions for container platform configuration changes.","Rancher MCM must enforce access restrictions for container platform configuration changes.","Configuration changes cause the container platform to change the way it operates. These changes can be used to improve the system with added features or performance, but these configuration changes can also be used to introduce malicious features and degrade performance. To control the configuration changes made to the container platform, it is important that only authorized users are allowed, through container platform enforcement, to make configuration changes.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation and configuration settings to determine if the container platform enforces access restrictions associated with changes to container platform components configuration. \n\nIf the container platform does not enforce such access restrictions, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce access restrictions associated with changes to the container platform components configuration.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["CM-5 (1)","CCI-001814","SRG-APP-000381-CTR-000905","","The container platform must enforce access restrictions and support auditing of the enforcement actions.","Rancher MCM must enforce access restrictions and support auditing of the enforcement actions.","Auditing the enforcement of access restrictions against changes to the container platform helps identify attacks and provides forensic data for investigation for after-the-fact actions. Attempts to change configurations, components, or data maintained by a component (e.g., images in the registry, running containers in the runtime, or keys in the keystore) must be audited. \n\nEnforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review container platform documentation and logs to determine if enforcement actions used to restrict access associated with changes to the container platform are logged. \n\nIf these actions are not logged, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to log the enforcement actions used to restrict access associated with changes.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["CM-7 (1) (b)","CCI-001762","SRG-APP-000383-CTR-000910","","All non-essential, unnecessary, and unsecure DoD ports, protocols, and services must be disabled in the container platform.","","To properly offer services to the user and to orchestrate containers, the container platform may offer services that use ports and protocols that best fit those services. The container platform, when offering the services, must only offer the services on ports and protocols authorized by the DoD.\n\nTo validate that the services are using only the approved ports and protocols, the organization must perform a periodic scan/review of the container platform and disable functions, ports, protocols, and services deemed to be unneeded or non-secure.","","Applicable - Inherently Meets","Review the container platform configuration to determine if services or capabilities presently on the information system are required for operational or mission needs. \n\nIf additional services or capabilities are present on the system, this is a finding.","","Configure the container platform to only utilize secure ports and protocols required for operation that have been accepted for use as per the Ports, Protocols, and Services Category Assignments List (CAL) from DISA (PPSM).","","CAT II","",null,null,"I need to review Rancher MCM and see what FIPs features will be in 2.6"]
["CM-7 (2)","CCI-001764","SRG-APP-000384-CTR-000915","","The container platform must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.","Rancher MCM must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.","The container platform may offer components such as DNS services, firewall services, router services, or web services that are not required by every organization to meet their needs. Container platform components may also add capabilities that run counter to the mission or that provide users with functionality that exceeds mission requirements. To meet the requirements of an organization, the container platform must have a method to remove or disable components not required to meet the organization's mission.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation and configuration setting to determine if policies, rules, or restrictions exist regarding usage of container platform components. \n\nIf no such no restrictions are in place, this is not a finding. \n\nIdentify any components the organization requires to be disabled or removed and configure the container platform according to that policy. \n\nIf the container platform components are not disabled or removed according to the organization's policy, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform so that any platform components that are not required in order to meet the organization's mission are disabled or removed. Document the components that must be disabled or removed for reference.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"I need to review Rancher MCM and see what FIPs features will be in 2.6"]
["CM-7 (5) (b)","CCI-001774","SRG-APP-000386-CTR-000920","","The container platform registry must employ a deny-all, permit-by-exception (whitelist) policy to allow only authorized container images in the container platform.","","Controlling the sources where container images can be pulled from allows the organization to define what software can be run within the container platform. Allowing any container image to be introduced and instantiated within the container platform may introduce malicious code and vulnerabilities to the platform and the hosting system. \n\nThe container platform registry must deny all container images except for those signed by organizational-approved sources.","","Not Applicable","Review documentation and configuration settings to identify if the container platform whitelisting specifies which container platform components are allowed to execute.\n\nCheck for the existence of policy settings or policy files that can be configured to restrict container platform component execution. Demonstrate how the program execution is restricted. Look for a deny-all, permit-by-exception policy of restriction.\n\nSome methods for restricting execution include but are not limited to the use of custom capabilities built into the application or Software Restriction Policies, Application Security Manager, or Role-Based Access Controls (RBAC).\n\nIf container platform whitelisting is not utilized or does not follow a deny-all, permit-by-exception (whitelist) policy, this is a finding.","","Configure the container platform to utilize a deny-all, permit-by-exception policy when allowing the execution of authorized software.","","CAT II","",null,{"$f":"VLOOKUP(\"N0013\",Sheet1!M:N,2,0)","v":"RKE2 does node auth with tokens. \nSee\nD0013 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-11","CCI-002038","SRG-APP-000389-CTR-000925","","The container platform must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.","","Controlling user access is paramount in securing the container platform. During a user's access to the container platform, events may occur that change the user's access and which require reauthentication. For instance, if the capability to change security roles or escalate privileges is implemented, it is critical the user reauthenticate.\n\nIn addition to the reauthentication requirements associated with change in security roles or privilege escalation, organizations may require reauthentication of individuals in other situations, including (but not limited to) the following circumstances:\n\n(i) When authenticators change; \n(ii) When roles change; \n(iii) When security categories of information systems change; \n(iv) When the execution of privileged functions occurs; \n(v) After a fixed period of time; or\n(vi) Periodically.\n\nWithin the DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.","","Not Applicable","Review documentation and configuration to determine if the container platform requires a user to reauthenticate when organization-defined circumstances or situations are met. \n\nIf the container platform does not meet this requirement, this is a finding.",null,"Configure the container platform to require a user to reauthenticate when organization-defined circumstances or situations are met.","","CAT II","",null,"Authentication of users is handled by organization-defined external resources, which would handle reauthentication. Rancher MCM then uses the authenticated user to determine authorization of services."]
["IA-11","CCI-002039","SRG-APP-000390-CTR-000930","","The container platform must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication.","","The container platform may require external devices be used to fully orchestrate the services needed for users. Examples would be storage or external servers. Without reauthentication, unidentified or unknown devices may be introduced; thereby facilitating malicious activity.\n\nThe container platform must be capable of allowing the organization to set requirements associated with device reauthentication. Examples are:\n\nOrganizations may require reauthentication of devices, including (but not limited to), the following other situations:\n\n(i) When authenticators change; \n(ii) When roles change; \n(iii) When security categories of information systems change;\n(iv) After a fixed period of time; or \n(v) Periodically.\n\nFor distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions.","","Not Applicable","Review documentation and configuration to determine if the container platform requires devices to reauthenticate when organization-defined circumstances or situations require reauthentication. \n\nIf the container platform does not require a device to reauthenticate, this is a finding.","","Configure the container platform to require devices to reauthenticate when organization-defined circumstances or situations require reauthentication.","","CAT II","",null,"Authentication of users is handled by organization-defined external resources, which would handle reauthentication. Rancher MCM then uses the authenticated user to determine authorization of services."]
["IA-2 (12)","CCI-001953","SRG-APP-000391-CTR-000935","","The container platform must be configured to use multi-factor authentication for user authentication.","","Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. To standardize and reduce the risks of unauthorized access, the use of multifactor token-based credentials is the preferred method.\n\nDoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.","","Not Applicable","Review documentation and configuration to ensure the container platform is configured to use an approved DoD multifactor token (CAC) when accessing platform via user interfaces. \n\nIf multifactor authentication is not configured, this is a finding.","","Configure the container platform to accept standard DoD multifactor token-based credentials when users interface with the platform.","","CAT II","",null,"Authentication of users is handled by organization-defined external resources, which would handle reauthentication. Rancher MCM then uses the authenticated user to determine authorization of services."]
["IA-5 (1) (f)","CCI-002041","SRG-APP-000397-CTR-000955","","The container platform must allow the use of a temporary password for system logons with an immediate change to a permanent password.","","Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial login.\n\nTemporary passwords are typically used to allow access to applications when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts, which allow the users to log in, yet forces them to change the password once they have successfully authenticated.","","Not Applicable","Review the container platform configuration to determine if the platform is configured to allow the use of a temporary password for system logons with an immediate change to a permanent password. \n\nIf the container platform is not configured to allow temporary passwords with immediate change to a permanent password, this is a finding.","","Configure the container platform to allow the use of a temporary password for system logons with an immediate change to a permanent password.","","CAT II","",null,"Endpoint management falls outside the Rancher MCM scope."]
["IA-5 (13)","CCI-002007","SRG-APP-000400-CTR-000960","","The container platform must prohibit the use of cached authenticators after an organization-defined time period.","","If cached authentication information is out of date, the validity of the authentication information may be questionable.","","Not Applicable","Review the container platform configuration to determine if the platform is configured to prohibit the use of cached authenticators after an organization-defined time period. \n\nIf the container platform is not configured to prohibit the use of cached authenticators after an organization-defined time period, this is a finding.","","Configure the container platform to prohibit the use of cached authenticators after an organization-defined time period.","","CAT II","",null,"Network management provided outside Rancher MCM scope."]
["IA-5 (2) (d)","CCI-001991","SRG-APP-000401-CTR-000965","","The container platform, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.","","The potential of allowing access to users who are no longer authorized  (have revoked certificates) increases unless a local cache of revocation data is configured.","","Not Applicable","Review the container platform configuration.\n\n If the container platform is not implemented to use a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network, this is a finding.","","Configure the container platform to implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.","","CAT II","",null,"PKI-based authentication falls outside the Rancher MCM scope."]
["IA-8 (1)","CCI-002009","SRG-APP-000402-CTR-000970","","The container platform must accept Personal Identity Verification (PIV) credentials from other federal agencies.","","Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. It is essential to accept PIV credentials from other federal agencies and eliminate the possibility of access being denied to authorized users.\n\nPIV credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials.","","Not Applicable","Review the documentation and configuration to determine if the container platform accepts PIV credentials from other federal agencies. \n\nIf the container platform does not accept other federal agency PIV credentials, this is a finding.","","Configure the container platform to accept PIV credentials from other federal agencies.","","CAT II","",null,"Authentication of users is handled by organization defined external resources. Racher MCM then uses the authenticated user to determine authorization of services."]
["MA-4 (1) (a)","CCI-002884","SRG-APP-000409-CTR-000990","","The container platform must audit non-local maintenance and diagnostic sessions' organization-defined audit events associated with non-local maintenance.","","To fully investigate an attack, it is important to understand the event and those events taking place during the same time period. Often, non-local administrative access and diagnostic sessions are not logged. These events are seen as only administrative functions and not worthy of being audited, but these events are important in any investigation and are a major tool for assessing and investigating attacks.","","Not Applicable","Review the container platform to verify if the platform is auditing non-local maintenance and diagnostic sessions' organization-defined audit events. \n\nIf the container platform is not auditing non-local maintenance and diagnostic sessions' organization-defined audit events, this is a finding.","","Configure the container platform to audit non-local maintenance and diagnostic sessions' organization-defined audit events.","","CAT II","",null,"Any requirements for tools used for nonlocal maintenance are outside the scope of the Racher MCM. "]
["MA-4 (6)","CCI-002890","SRG-APP-000411-CTR-000995","","Container platform applications and Application Program Interfaces (API) used for nonlocal maintenance sessions must use FIPS-validated keyed-hash message authentication code (HMAC) to protect the integrity of nonlocal maintenance and diagnostic communications.","","Unapproved mechanisms that are used for authentication to the cryptographic module are not verified, and therefore cannot be relied on to provide confidentiality or integrity, and DoD data may be compromised.\n\nNonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network.\n\nCurrently, HMAC is the only FIPS-approved algorithm for generating and verifying message/data authentication codes in accordance with FIPS 198-1. Products that are FIPS 140-2 validated will have an HMAC that meets specification; however, the option must be configured for use as the only message authentication code used for authentication to cryptographic modules.\n\nSeparate requirements for configuring applications and protocols used by each product (e.g., SNMPv3, SSHv2, NTP, and other protocols and applications that require server/client authentication) are required to implement this requirement. The SSHv2 protocol suite must be mandated in the product because it includes layer 7 protocols such as SCP and SFTP that can be used for secure file transfers.","","Not Applicable","Validate that container platform applications and APIs used for nonlocal maintenance sessions are using FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications. \n\nIf the sessions are not using FIPS-validated HMAC, this is a finding.","","Configure the container platform applications and APIs used for nonlocal maintenance sessions to use FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications.","","CAT II","",null,"Any requirements for tools used for nonlocal maintenance are outside the Rancher MCM scope."]
["MA-4 (6)","CCI-003123","SRG-APP-000412-CTR-001000","","The container platform must configure web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.","","Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.\n\nNonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network.","","Not Applicable","Validate the container platform web management tools and Application Program Interfaces (API) are configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions. \n\nIf the web management tools and API are not configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms, this is a finding.","","Configure the container platform web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.","","CAT II","",null,"Web maintenance tool falls outside the Rancher MCM scope."]
["RA-5 (5)","CCI-001067","SRG-APP-000414-CTR-001010","","Vulnerability scanning applications must implement privileged access authorization to all container platform components, containers, and container images for selected organization-defined vulnerability scanning activities.","","In certain situations, the nature of the vulnerability scanning may be more intrusive, or the container platform component that is the subject of the scanning may contain highly sensitive information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and protects the sensitive nature of such scanning.\n\nThe vulnerability scanning application must utilize privileged access authorization for the scanning account.","","Not Applicable","Validate that scanning applications have privileged access to container platform components, containers, and container images to properly perform vulnerability scans. \n\nIf privileged access is not given to the scanning application, this is a finding.","","Configure the vulnerability scanning application to have privileged access to the container platform components, containers, and container images.","","CAT II","",null,"The capabilities of a vulnerability scanning tool is outside theRancher MCM scope."]
["SC-13","CCI-002450","SRG-APP-000416-CTR-001015","","The container platform must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.","","Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data and images. The container platform must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.","","","Review documentation to verify that the container platform is using NSA-approved cryptography to protect classified data and applications. \n\nIf the container platform is not using NSA-approved cryptography for classified data and applications, this is a finding.","","Configure the container platform to utilize NSA-approved cryptography to protect classified information.","","CAT II",""]
["SC-28 (1)","CCI-002476","SRG-APP-000429-CTR-001060","","The container platform keystore must implement encryption to prevent unauthorized disclosure of information at rest within the container platform.","","Container platform keystore is used for container deployments for persistent storage of all its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any unauthorized disclosure. Selection of a cryptographic mechanism is based on the need to protect the confidentiality of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information.","","","Review container platform keystore documentation and configuration to verify encryption levels meet the information sensitivity level. \n\nIf the container platform keystore encryption configuration does not meet system requirements, this is a finding.","","Configure the container platform keystore encryption to maintain the confidentiality and integrity of information for applicable sensitivity level.","","CAT II",""]
["SC-39","CCI-002530","SRG-APP-000431-CTR-001065","","The container platform runtime must maintain separate execution domains for each container by assigning each container a separate address space.","","Container namespace access is limited upon runtime execution. Each container is a distinct process so that communication between containers is performed in a manner controlled through security policies that limits the communication so one container cannot modify another container. Different groups of containers with different security needs should be deployed in separate namespaces as a first level of isolation.\n\nNamespaces are a key boundary for network policies, orchestrator access control restrictions, and other important security controls. Separating workloads into namespaces can help contain attacks and limit the impact of mistakes or destructive actions by authorized users.","","Applicable - Inherently Meets","Review container platform runtime documentation and configuration is maintaining a separate execution domain for each executing process. Different groups of applications, and services with different security needs, should be deployed in separate namespaces as a first level of isolation. \n\nIf container platform runtime is not configured to execute processes in separate domains and namespaces, this is a finding. \n\nIf namespaces use defaults, this is a finding.","","Deploy a container platform runtime capable of maintaining a separate execution domain and namespace for each executing process. Create a namespace for each containers, defining them as logical groups.","","CAT II","",null,"Rancher MCM has the concept of namespaces to divide pods (applications) into their own domain. It is up to the SA to use these appropriately for the user services that are implemented."]
["SC-5","CCI-002385","SRG-APP-000435-CTR-001070","","The container platform must protect against or limit the effects of all types of denial-of-service (DoS) attacks by employing organization-defined security safeguards.","Rancher MCM API must not allow kubeconfig files and tokens to have infinite time-to-live.","DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.\n\nThis requirement addresses the configuration of the container platform to mitigate the impact of DoS attacks that have occurred. For each container platform component, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting runtime processes or restricting the number of sessions the container platform runtime open, limiting container resources to memory and CPU).\n\nProcesses are an important indicator of security-and operations-relevant container activity. Process names and their arguments provide important visibility into a container’s activity. If an image includes non-default aliases or renamed binaries, attackers will still attempt to use well-known names.\n\nThe same malicious or unwanted activity might affect multiple deployments across different applications or environments. Staff investigating a potential incident need to find those exposures quickly.","Rancher MCM allows users to generate kubeconfig files and API tokens using their account credentials and these tokens have the capability to never expire unless you invalidate them manually.\n\nIt is important for users to need to re-authenticate periodically in case of misplaced tokens or kubeconfig files on a valid account. This invalidation/TTL maximum can be set globally to ensure these tokens can not have infinite time-to-live. ","","Review documentation and configuration to determine if the container platform can protect against or limit the effects of all types of DoS attacks by employing defined security safeguards against resource depletion. Examples of resource limits are on memory, storage, and CPU. \n\nIf the container platform cannot be configured to protect against or limit the effects of all types of DoS, this is a finding.","","Configure the container platform to protect against or limit the effects of all types of DoS attacks by employing defined security safeguards. Safeguards such as resource limits on memory, storage, and CPU can be used.","","CAT II",""]
["SC-8","CCI-002418","SRG-APP-000439-CTR-001080","","The application must protect the confidentiality and integrity of transmitted information.","","Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. \n\nThis requirement applies only to those applications that either are distributed or can allow access to data non-locally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.\n\nCommunication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.","","Not Applicable","This requirement is NA for this technology.","","The requirement is NA. No fix is required.","","CAT II","",null,"Rancher MCM service account must utilize certificates for authentication."]
["SC-8 (2)","CCI-002420","SRG-APP-000441-CTR-001090","","The container platform must maintain the confidentiality and integrity of information during preparation for transmission.","","Information may be unintentionally or maliciously disclosed or modified during preparation for transmission within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When transmitting data, the container platform components need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.","","Not Applicable","Review the documentation and deployed configuration to determine if the container platform maintains the confidentiality and integrity of information during preparation before transmission. \n\nIf the confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during preparation before transmission, this is a finding.","","Configure the container platform to maintain the confidentiality and integrity of information using mechanisms such as TLS, TLS VPNs, or IPsec during preparation for transmission.","","CAT II","",null,"Rancher MCM service account must utilize certificates for authentication."]
["SC-8 (2)","CCI-002422","SRG-APP-000442-CTR-001095","","The container platform must maintain the confidentiality and integrity of information during reception.","","Information either can be unintentionally or maliciously disclosed or modified during reception for reception within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When receiving data, the container platform components need to leverage protection mechanisms, such as TLS, TLS VPNs, or IPsec.","","Applicable - Inherently Meets","Review documentation and configuration settings to determine if the container platform maintains the confidentiality and integrity of information during reception.\n\nIf confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during reception, this is a finding.","","Configure the container platform to maintain the confidentiality and integrity using mechanisms such as TLS, TLS VPNs, or IPsec during reception.","","CAT II","",null,"Security control STIG Check and Fix is addressed in the following security controls:\nAC-17(2)\nAC-3\nSC-23\nSC-8"]
["SI-10 (3)","CCI-002754","SRG-APP-000447-CTR-001100","","The container platform must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.","","Software or code parameters typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata.\n\nThis requirement guards against adverse or unintended system behavior caused by invalid inputs, where container platform components responses to the invalid input may be disruptive or cause the container image runtime to fail into an unsafe state.\n\nThe behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.","","Applicable - Inherently Meets","Review the configuration to determine if the container platform behaves in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. \n\nIf the container platform does not meet this requirement, this is a finding.","","Configure the container platform behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.","","CAT II","",null,"Input by the SA and authorized users is through the GUI or Command Line. Input is validated and gives an error for invalid inputs. Rancher MCM invalid inputs does not leave the system in an unpredictable state."]
["SI-16","CCI-002824","SRG-APP-000450-CTR-001105","","The container platform must implement organization-defined security safeguards to protect system CPU and memory from resource depletion and unauthorized code execution.","","The execution of images within the container platform runtime must implement organizational defined security safeguards to prevent distributed denial-of-service (DDOS) and other possible attacks against the container image at runtime.\n\nSecurity safeguards employed to protect memory and CPU include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be software-enforced. Other means of protection are to limit memory and CPU resources to a container.","","Not Applicable","Review the container platform configuration to determine if safeguards are in place to protect the system memory and CPU from resource depletion and unauthorized execution. \n\nIf safeguards are not in place, this is a finding.","","Configure the container platform to have safeguards in place to protect the system memory and CPU from resource depletion and unauthorized code execution.","","CAT II","",null,"Container runtime not in Rancher MCM scope; CPU and Memory limits covered in Container Hardening Guidelines."]
["SI-2 (6)","CCI-002617","SRG-APP-000454-CTR-001110","","The container platform must remove old components after updated versions have been installed.","Rancher MCM must remove old components after updated versions have been installed.","Previous versions of container platform components that are not removed from the container platform after updates have been installed may be exploited by adversaries by causing older components to execute which contain vulnerabilities. When these components are deleted, the likelihood of this happening is removed.","","","Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version. \n\nIf organization-defined images do not contain the latest approved vendor software image version, this is a finding. \n\nReview container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed. \n\nIf organization-defined images are not removed after updated versions have been installed, this is a finding. \n\nReview container platform runtime documentation and configuration to determine if organization-define images are executing latest image version from the container platform registry. \n\nIf container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.","","Configure the container platform registry to update organization-defined images with current approved vendor version and remove obsolete images after updated versions have been installed. Configure the container platform runtime to execute latest organization-defined images from the container platform registry.","","CAT II",""]
["SI-2 (6)","CCI-002617","SRG-APP-000454-CTR-001115","","The container platform registry must remove old container images after updating versions have been made available.","","Obsolete and stale images need to be removed from the registry to ensure the container platform maintains a secure posture. While the storing of these images does not directly pose a threat, they do increase the likelihood of these images being deployed. Removing stale or obsolete images and only keeping the most recent versions of those that are still in use removes any possibility of vulnerable images being deployed.","","","Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version. \n\nIf organization-defined images do not contain the latest approved vendor software image version, this is a finding. \n\nReview container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed. \n\nIf organization-defined images are not removed after updated versions have been installed, this is a finding. \n\nReview container platform runtime documentation and configuration to determine if organization-defined images are executing latest image version from the container registry. \n\nIf container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.","","Configure the container platform registry to update organization-defined images with current approved vendor version and remove obsolete images after updated versions have been installed. Configure the container platform runtime to execute latest organization-defined images from the container platform registry.","","CAT II",""]
["SI-2 c","CCI-002605","SRG-APP-000456-CTR-001125","","The container platform registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. ","","Software supporting the container platform, images in the registry must stay up to date with the latest patches, service packs, and hot fixes. Not updating the container platform and container images will expose the organization to vulnerabilities.\n\nFlaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.\n\nOrganization-defined time periods for updating security-relevant container platform components may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw).\n\nThis requirement will apply to software patch management solutions that are used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.\n\nThe container platform components will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The container platform registry will ensure the images are current. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).","","","Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). \n\nIf the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.\n\nThe container platform registry should help the user understand where the code in the environment was deployed from, and must provide controls that prevent deployment from untrusted sources or registries.","","Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed.","","CAT II",""]
["SI-2 c","CCI-002605","SRG-APP-000456-CTR-001130","","The container platform runtime must have updates installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).","","The container platform runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly. A vulnerable runtime exposes all containers it supports, as well as the host itself, to potentially significant risk. Organizations should use tools to look for Common Vulnerabilities and Exposures (CVEs) vulnerabilities in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes.","","","Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). \n\nIf the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.\n\nThe container platform registry should help the user understand where the code in the environment was deployed from and must provide controls that prevent deployment from untrusted sources or registries.","","Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed within the time period directed by the authoritative source.","","CAT II",""]
["SI-6 a","CCI-002696","SRG-APP-000472-CTR-001170","","The organization-defined role must verify correct operation of security functions in the container platform.","","Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform. The container platform components must identity and ensure the security functions are still operational and applicable to the organization.\n\nSecurity functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.\n\nNotifications provided by information systems include, for example, electronic alerts to system administrators.","","","Review container platform documentation and configuration verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM). \n\nIf verification of the correct operation of security functions is not performed, this is a finding.","","Configure the container platform configuration and installation settings to perform verification of the correct operation of security functions.","","CAT II",""]
["SI-6 b","CCI-002699","SRG-APP-000473-CTR-001175","","The container platform must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.","","Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform.\n\nSecurity functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.\n\nNotifications provided by information systems include, for example, electronic alerts to organization-defined role.","","","Review container platform documentation.\n\nVerify that the container platform is configured to perform verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM), upon product startup/restart, by a user with privileged access, and/or every 30 days.\n\nIf it is not, this is a finding.","","Configure the container platform to perform verification of the correct operation of security functions, which may include the connection validation, upon product startup/restart, or by a user with privileged access, and/or every 30 days.","","CAT II",""]
["SI-6 d","CCI-002702","SRG-APP-000474-CTR-001180","","The container platform must provide system notifications to the system administrator and operational staff when anomalies in the operation of the organization-defined security functions are discovered.","Mike - Please Verify The technology inherently meets this requirement.","If anomalies are not acted upon, security functions may fail to secure the container within the container platform runtime.\n\nSecurity functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.\n\nNotifications provided by information systems include, for example, electronic alerts to system administrators.","","Applicable - Inherently Meets","Review container platform runtime documentation and configuration settings. \n\nIf the container platform is not configured to notify organization-defined information system role when anomalies in the operation of security functions as defined by site security plan are discovered, this is a finding.","","Configure the container platform runtime to notify system administrator and operation staff when anomalies in the operation of the security functions as defined in site security plan are discovered.","","CAT II","",null,"The technology supports this requirement and cannot be configured to be out of compliance. "]
["AU-12 c","CCI-000172","SRG-APP-000492-CTR-001220","","The container platform must generate audit records when successful/unsuccessful attempts to access security objects occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access security objects occur.","The container platform and its components must generate audit records when successful and unsuccessful access security objects occur. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation access controls levels can access by unauthorized users unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security objects. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to access security objects occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000493-CTR-001225","","The container platform must generate audit records when successful/unsuccessful attempts to access security levels occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access security levels occur.","Unauthorized users could access the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can access security levels unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security levels. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to access security levels occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000494-CTR-001230","","The container platform must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access categories of information. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to access categories of information.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000495-CTR-001235","","The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify privileges occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to modify privileges.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000496-CTR-001240","","The container platform must generate audit records when successful/unsuccessful attempts to modify security objects occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify security objects occur.","The container platform and its components must generate audit records when modifying security objects. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can modify security objects unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security objects. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security objects.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000497-CTR-001245","","The container platform must generate audit records when successful/unsuccessful attempts to modify security levels occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify security levels occur.","Unauthorized users could modify the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can modify security levels unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security levels. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security levels.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000498-CTR-001250","","The container platform must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to modify categories of information. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts are made to modify categories of information.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000499-CTR-001255","","The container platform must generate audit records when successful/unsuccessful attempts to delete privileges occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete privileges occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to delete privileges. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts are made to delete privileges occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000500-CTR-001260","","The container platform must generate audit records when successful/unsuccessful attempts to delete security levels occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete security levels occur.","The container platform and its components must generate audit records when deleting security levels. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can delete security levels unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to delete security levels. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to delete security levels.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000501-CTR-001265","","The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete security objects occur.","Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to delete security objects occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000502-CTR-001270","","The container platform must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete categories of information occur. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to delete categories of information occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000503-CTR-001275","","The container platform must generate audit records when successful/unsuccessful logon attempts occur.","Rancher MCM must generate audit records when successful/unsuccessful logon attempts occur.","The container platform and its components must generate audit records when successful and unsuccessful logon attempts occur. The information system can determine if an account is compromised or is in the process of being compromised and can take actions to thwart the attack. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration for audit logon events. \n\nEnsure audit policy for successful and unsuccessful logon events are enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf logon attempts do not generate log records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform registry, keystore, and runtime to generate audit log for successful and unsuccessful logon for any all accounts and services. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000504-CTR-001280","","The container platform must generate audit record for privileged activities.","Rancher MCM must generate audit record for privileged activities.","The container platform components will generate audit records for privilege activities and container platform runtime, registry, and keystore must generate access audit records to detect possible malicious intent. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without these activities. Audit records can be generated from various components within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the documentation and configuration guides to determine if the container platform generates log records for privileged activities. \n\nIf log records are not generated for privileged activities, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate log records for privileged activities.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000505-CTR-001285","","The container platform audit records must record user access start and end times.","Rancher MCM audit records must record user access start and end times.","The container platform must generate audit records showing start and end times for users and services acting on behalf of a user accessing the registry and keystore. These components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration for audit user access start and end times. \n\nEnsure audit policy for user access start and end times are enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf user access start and end times do not generate log records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit log for user access start and end times for any all accounts and services. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000506-CTR-001290","","The container platform must generate audit records when concurrent logons from different workstations and systems occur.","Rancher MCM must generate audit records when concurrent logons from different workstations and systems occur.","The container platform and its components must generate audit records for concurrent logons from workstations perform remote maintenance, runtime instances, connectivity to the container registry, and keystore. All the components must use the same standard so the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration for audit logon events. \n\nEnsure audit policy for concurrent logons from different workstations and systems is enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf concurrent logons from different workstations and systems do not generate log records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit log for concurrent logins from multiple workstations and systems. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000507-CTR-001295","","The container platform runtime must generate audit records when successful/unsuccessful attempts to access objects occur.","","Container platform runtime objects are defined as configuration files, code, etc. This provides the ability to configure resources and software parameters prior to image execution from the container platform registry. An unauthorized user with malicious intent could modify existing objects causing vulnerabilities or attacks. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without audit record generation.\n\nWithout audit record generation, unauthorized users can access objects unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify that the runtime generates audit records on successful/unsuccessful access to objects. \n\nIf audit records are not generated by the runtime when objects are successfully/unsuccessfully accessed, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform runtime to generate audit records on successful/unsuccessful access to objects.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000508-CTR-001300","","Direct access to the container platform must generate audit records.","Direct access to Rancher MCM must generate audit records.","Direct access to the container platform and its components must generate audit records. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if direct access of the container platform generates audit records. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when accessed directly.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000509-CTR-001305","","The container platform must generate audit records for all account creations, modifications, disabling, and termination events.","Rancher MCM must generate audit records for all account creations, modifications, disabling, and termination events.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to generate audit records for all account creations, modifications, disabling, and termination events. \n\nIf the container platform is not configured to generate the audit records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records for all account creations, modifications, disabling, and termination events.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000510-CTR-001310","","The container runtime must generate audit records for all container execution, shutdown, restart events, and program initiations.","Rancher MCM runtime must generate audit records for all container execution, shutdown, restart events, and program initiations.","The container runtime must generate audit records that are specific to the security and mission needs of the organization. Without audit record, it would be difficult to establish, correlate, and investigate events relating to an incident.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container runtime configuration to validate audit record generation for container execution, shutdown, and restart events. \n\nIf the container runtime does not generate records for container execution, shutdown and restart events, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container runtime to generate audit records for container execution, shutdown, and restart events.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["SC-13","CCI-002450","SRG-APP-000514-CTR-001315","","The container platform must use a valid FIPS 140-2 approved cryptographic modules to generate hashes.","","The cryptographic module used must have at least one validated hash algorithm. This validated hash algorithm must be used to generate cryptographic hashes for all cryptographic security function within the container platform components being evaluated.\n\nFIPS 140-2 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.","","Not Applicable","Review the container platform configuration to validate that valid FIPS 140-2 approved cryptographic modules are being used to generate hashes. \n\nIf non-valid or unapproved FIPS 140-2 cryptographic modules are being used to generate hashes, this is a finding.","","Configure the container platform to use valid FIPS 140-2 approved cryptographic modules to generate hashes.","","CAT II","",null,"Racher MCM does not contain confidential data, such as PII, unless a user service deployed within Rancher MCM operates on this type of data. If a user service is deployed that operates on confidential data, the service would need to implement this control."]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-000790","","The container platform must provide the configuration for organization-identified individuals or roles to change the auditing to be performed on all components, based on all selectable event criteria within organization-defined time thresholds.","","Auditing requirements may change per organization or situation within and organization. With the container platform allowing an organization to customize the auditing, an organization can decide to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.\n\nModifying auditing within the container platform must be controlled to only those individuals or roles identified by the organization to modify auditable events.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review documentation and configuration setting. \n\nIf the container platform does not provide the ability for users in authorized roles to reconfigure auditing at any time of the user's choosing, this is a finding. \n\nIf changes in audit configuration cannot take effect until after a certain time or date, or until some event, such as a server restart, has occurred, and if that time or event does not meet the requirements specified by the organization, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Deploy a container platform that provides the ability for users in authorized roles to reconfigure auditing at any time. Deploy a container platform that allows audit configuration changes to take effect within the timeframe required by the organization and without involving actions or events that the organization rules unacceptable.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-001325","","Container platform components must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.","Is there a Helm check/fix for this?","Container platform components are part of the overall container platform, offering services that enable the container platform to fully orchestrate user containers. These components may fall outside the scope of this document, but they still must be secured. Examples of such components are DNS, routers, and firewalls. These and any other services offered by the container platform must follow the appropriate STIG or SRG for the technology offered. If a STIG or SRG is not available for the technology, then best practices for the technology must be used. For example, the Cloud Native Computing Foundation (CNCF) is an open-source organization that is working on container platform best practices.","","","Review the container platform configuration to determine the services offered by the container platform and validate that any services that are offered are configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs. \n\nIf container platform services are not configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs, this is a finding.","","Configure container services in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.","","CAT II",""]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-001330","","The container platform must be able to store and instantiate industry standard container images.","","Monitoring the container images and containers during their lifecycle is important to guarantee the container platform is secure. To monitor the containers and images, security tools can be put in place. To fully utilize the security tools available, using images formatted in an industry standard format should be used. This allows the tools to fully understand the images and containers. One standard being worked on by industry leaders in the container space is the Open Container Initiative (OCI). This group is developing a standard container image format.","","","Review the container platform configuration and documentation to determine if the platform is configured to store and instantiate industry standard container images. \n\nIf the container platform cannot instantiate industry standard container images, this is a finding.","","Enable the container platform to store and instantiate industry standard container image formats.","","CAT II",""]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-001335","","The container platform must continuously scan components, containers, and images for vulnerabilities.","","Finding vulnerabilities quickly within the container platform and within containers deployed within the platform is important to keep the overall platform secure. When a vulnerability within a component or container is unknown or allowed to remain unpatched, other containers and customers within the platform become vulnerability. The vulnerability can lead to the loss of application data, organizational infrastructure data, and denial of service (DoS) to hosted applications.\n\nVulnerability scanning can be performed by the container platform or by external applications.","","","Review the container platform to validate continuous vulnerability scans of components, containers, and container images are being performed. \n\nIf continuous vulnerability scans are not being performed, this is a finding.","","Implement continuous vulnerability scans of container platform components, containers, and container images either by the container platform or from external vulnerability scanning applications.","","CAT II",""]
["AC-17 (2)","CCI-001453","SRG-APP-000560-CTR-001340","","The container platform must prohibit communication using TLS versions 1.0 and 1.1, and SSL 2.0 and 3.0.","","The container platform and its components will prohibit the use of SSL and unauthorized versions of TLS protocols to properly secure communication.\n\nThe use of unsupported protocol exposes vulnerabilities to the container platform by rogue traffic interceptions, man-in-the middle-attacks, and impersonation of users or services from the container platform runtime, registry, and keystore.\n\nThe container platform and its components will adhere to NIST 800-52R2.",null,"Applicable - Inherently Meets","Review the container platform configuration to determine if TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 are prohibited for communication. \n\nIf communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 is permitted, this is a finding.","","Configure the container platform to prohibit communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0.","","CAT II",""]
["IA-5 (2) (a)","CCI-000185","SRG-APP-000605-CTR-001380","","The container platform must validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation.","Need to elaborate here. This is a placeholder. Rancher MCM must verify the certificates used for Rancher's ingress is a valid DOD certificate. This is achived by verifying the helm installation contains correct parameters.","A certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate and discourages the use of self-signed certificates.\n\nCertification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Compliance checks should be in accordance to RFC 5280.\n\nNot adhering to RFC 5280 could result in rogue certificates, session hijacks, man-in-the-middle, denial-of-service attacks, malware, and data or information manipulation.","Rancher MCM must verify the certificates used for Rancher's ingress is a valid DOD certificate. This is achived by verifying the helm installation contains correct parameters.","Applicable - Configurable","Review the container platform configuration to verify the container platform is validating certificates used for Transport Layer Security (TLS) functions by performing a RFC 5280-compliant certification path validation and that self-signed certificates are not being used. \n\nIf the container platform is not validating certificates used for TLS functions by performing an RFC 5280-compliant certification path validation, this is a finding. \n\nIf self-signed certificates are in use, this is a finding.","Verify helm installation contained correct parameters\nFrom the console, Type:\n`helm get values rancher -n cattle-system`\n\nThe output must contain:\n```\nprivateCA: true\ningress:\n  tls:\n    source: secret\n```\nIf the output source is not 'secret', this is a finding.\n\nVerify contents of certificates are correct: \nFrom the console, type:\nkubectl -n cattle-system get secret tls-rancher-ingress -o 'jsonpath={.data.tls\\.crt}' | base64 --decode | openssl x509 -noout -text\n\nkubectl -n cattle-system get secret tls-ca -o 'jsonpath={.data.cacerts\\.pem}' | base64 --decode | openssl x509 -noout -text\n","Configure the container platform to validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation and to disable the use of self-signed certificates.","Update the secrets to contain valid certificates.\n\n--Need to write Steps here","CAT II",""]
["IA-7","CCI-000803","SRG-APP-000610-CTR-001385","","The container platform must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).","","Without the use of digital signature, information can be altered by unauthorized accounts accessing or modifying the container platform registry, keystore, and container at runtime. Digital signatures provide non-repudiation for transactions between the components within the container platform. Without the use of approved FIPS-validated SHA-2 or higher hash function with digital signatures, the container platform cannot claim the validity of the individual or service identity and guarantee private key is kept secret. Keeping the private keys secure is vital for validating individuals or service identity prior to information exchange. The container platform must be configured to use SHA-2 or higher hash functions for digital signatures in accordance with SP 800-131Ar2.","","Not Applicable","Review the container platform configuration to validate that a FIPS-validated SHA-2 or higher hash function is being used for digital signature generation and verification. \n\nIf a FIPS-validated SHA-2 or higher hash function is not being used for digital signature generation and verification, this is a finding.","","Configure the container platform to use a FIPS-validated SHA-2 or higher hash function for digital signature generation and verification.","","CAT II","",null,"Rancher MCM does not authenticate users, but uses external organizational services for authentication and Rancher MCM authorizes users for what the user may do. This control is about authenticating users before use of cryptographic modules and is out of scope of Rancher MCM"]
["SC-13","CCI-002450","SRG-APP-000635-CTR-001405","","The container platform must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.","","Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.\n\nCryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the container platform component and information residing in the container platform registry and keystore.","","Not Applicable","Review the container platform configuration to ensure FIPS-validated cryptographic modules are implemented to encrypt unclassified information requiring confidentiality. \n\nIf FIPS-validated cryptographic modules are not being used, this is a finding.","","Configure the container platform to use FIPS-validated cryptographic modules to encrypt unclassified information requiring confidentiality.","","CAT I","",null,"Rancher MCM does not contain confidential data, such as PII, unless a user service deployed within Rancher MCM operates on this type of data. If a user service is deployed that operates on confidential data, the service would need to implement this control."]

{"sheet":"Sheet2","index":1,"n_rows":3,"n_cols":17,"rows_kept":3,"cut":false,"hidden":false,"merged":[]}
["IA Control","CCI","SRGID","STIGID","SRG Requirement","Requirement","SRG VulDiscussion","VulDiscussion","Status","SRG Check","Check","SRG Fix","Fix","Severity","Mitigation","Artifact Description","Status Justification"]
["CM-7 a","CCI-000381","SRG-APP-000141-CTR-000315","","The container platform must be configured with only essential configurations.","","The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed.","","Applicable - Inherently Meets","Review the container platform configuration and verify that only those components needed for operation are installed. \n\nIf components are installed that are not used for the intended purpose of the organization, this is a finding.","","Identify the role the container platform is intended to play in the production environment and remove any components that are not needed or used for the intended purpose.","","CAT II","",null,"Mike Can you elabrate on how Rancher installs the components etc…"]
["AC-17 (2)","CCI-001453","SRG-APP-000560-CTR-001340","","The container platform must prohibit communication using TLS versions 1.0 and 1.1, and SSL 2.0 and 3.0.","","The container platform and its components will prohibit the use of SSL and unauthorized versions of TLS protocols to properly secure communication.\n\nThe use of unsupported protocol exposes vulnerabilities to the container platform by rogue traffic interceptions, man-in-the middle-attacks, and impersonation of users or services from the container platform runtime, registry, and keystore.\n\nThe container platform and its components will adhere to NIST 800-52R2.",null,"Applicable - Inherently Meets","Review the container platform configuration to determine if TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 are prohibited for communication. \n\nIf communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 is permitted, this is a finding.","","Configure the container platform to prohibit communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0.","","CAT II","",null,"Same here"]

{"sheet":"Sheet1","index":2,"n_rows":12,"n_cols":14,"rows_kept":12,"cut":false,"hidden":false,"merged":[]}
["Discussion ID","Discussion","Check ID","Check","Fix ID","Fix","Mitigation ID","Mitigation","Justification ID","Justification","Artifact Description ID","Artifact Description","Rfed Notes ID","Note"]
["D0001","D0001-   TLS settings\nRancher MCM runs on top of a Kubernetes cluster and does not  have the ability to configure at that level. It is important to configure the platform in a way that uses strong cryptography wherever possible.\n","C0001",null,"F0001",null,null,null,null,"TLS services are not a part of the Rancher MCM MCM scope.",null,null,"N0001","RKE2 can configure this. Possibly inherently meets here because if the underlying platform provides the functionality then the applications should inherit. \n\nRancher MCM can, at the application/ingress level, configure ingress objects to use certain TLS settings but this is not at the node level.\n\nD0001 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0001 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"]
["D0002","D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n","C0002","C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. ","F0002","F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself.",null,null,null,null,null,null,"N0002","N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"]
["D0004","D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application.","C0004","C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n","F0004","F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n",null,null,null,null,null,null,"N0004","Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"]
["D0005","D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.",null,null,null,null,null,null,null,null,null,null,"N0005","N0005\nAudit logging in Rancher starts up when the app container starts with an ENV parameter. As stated in D0004 in this document, for all the logging there needs to have applied audit policies to the RKE2 platform as well. \n\nKubernetes has a api flag 'audit-log-mode=blocking-strict'  which actually prevents the Kube-API from proceeding with any action until it has successfully written the audit log. I have this in the RKE2 STIG under \n\nC0004\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nI don't think Rancher has this capability on it's own "]
["D0006","D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}","C0006","C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization.","F0006","F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization.",null,null,null,null,null,null,"N0006","N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"]
["D0008","D0008 - Images are built securely\n\nRancher MCM Images are built on standard container images such as UBI7, UBI8, Alpine, and Scratch images. The required packages installed on these are verified using the standard package managers such as YUM and DNF to ensure security patches are authentic."]
[null,null,null,null,null,null,null,null,null,null,null,null,"N0009","N0009 - Rancher MCM is a container running on a kubernetes platform\nRancher does not provide the capability of modifying the container Runtime. \n\nIt also does not have access to the full filesystem of the underlying OS. Only certain paths are mounted to the Rancher containers."]
[null,null,null,null,null,null,null,null,null,null,null,null,"N0010","N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."]
["D0011","D0011 - Ports Protocols, and Services\nRancher is designed to be deployed in a Kubernetes environment, which implies it is container based. Proper hardening of the surrounding environment is independent of Rancher MCM but ensures Rancher MCM will inherently meet security requirements.\n\nProperly configured Kubernetes environments use 3rd party proxies combined with control frameworks called ingress controllers which maintain the configuration state of the proxies for external traffic. Kubernetes also has internal control over network traffic through it's software defined network (SDN). This essentially means Kubernetes controls what ports are exposed to the container from both internal and external traffic. \n\nA default deployment of Rancher MCM exposes only port 80 (HTTP traffic) and port 443 (HTTPS traffic). These ports are enforced by the rest of the Kubernetes SDN and ingress controllers. The ports the server expects are dependant on what kubernetes routes are configurable, and should be verified.","C0011","C0011 - Check container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable. Note that other parts of the system could override this behavior.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Ports'\nEnsure 'Publish the container port' contains a setting of 80 or 443\n\nOpen the config panel 'Command'\nEnsure the 'Command' box contains '--http-listen-port=80 --https-listen-port=443'","F0011","F0011 - Fix container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nClick the configuration button (three dots) at the top right of the screen.\nSelect 'Edit'.\n\nEnsure port mapping contains only ports 80 or 443 are present for HTTP or HTTPS traffic. Click 'Add port' if additional mappings is required.\n\nClick 'Show advanced options' at the bottom of the page.\n\nOpen the 'Command' config panel.\nEnsure 'Command' contains '--http-listen-port=80 --https-listen-port=443', add if necessary.",null,null,null,null,null,null,"N0011","Rancher MCM is a web application. RKE2 hosts kubernetes and all ports associated with that with a few extras like 6443 and 9345\n\nD0012 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n"]
[null,null,null,null,null,null,null,null,null,null,null,null,"N0013","RKE2 does node auth with tokens. \nSee\nD0013 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"]
["D0003","D0003 - Temporary/Initial administrator accounts\nRancher MCM requires the set up of an initial administrator account when first launched. This administrative user is used to configure the portions of Rancher MCM. Once another form of authn/authz is configured this user is no longer needed and needs to be manually removed as it has unlimited privileges by default.   ",null,"Was D0003, moved to be consistant. "]

{"sheet":"Sheetx","index":3,"n_rows":174,"n_cols":19,"rows_kept":174,"cut":false,"hidden":false,"merged":[]}
["IA Control","CCI","SRGID","STIGID","SRG Requirement","Requirement","SRG VulDiscussion","VulDiscussion","Status","SRG Check","Check","SRG Fix","Fix","Severity","Mitigation","Artifact Description","Status Justification"]
["AC-17 (2)","CCI-000068","SRG-APP-000014-CTR-000035","","The container platform must use TLS 1.2 or greater for secure container image transport from trusted sources.","","The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.",null,"Not Applicable","Review the container platform configuration to verify that TLS 1.2 or greater is being used for secure container image transport from trusted sources. \n\nIf TLS 1.2 or greater is not being used for secure container image transport, this is a finding.","","Configure the container platform to use TLS 1.2 or greater when components communicate internally or externally. The fix ensures that all communication components in the container platform are configured to utilize secure versions of TLS.","","CAT II","",null,{"$f":"VLOOKUP(\"D0001\", Sheet1!A:B,2,0)","v":"D0001-   TLS settings\nRancher MCM runs on top of a Kubernetes cluster and does not  have the ability to configure at that level. It is important to configure the platform in a way that uses strong cryptography wherever possible.\n"},{"$f":"VLOOKUP(\"N0001\", Sheet1!M:N,2,0)","v":"RKE2 can configure this. Possibly inherently meets here because if the underlying platform provides the functionality then the applications should inherit. \n\nRancher MCM can, at the application/ingress level, configure ingress objects to use certain TLS settings but this is not at the node level.\n\nD0001 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0001 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-17 (2)","CCI-000068","SRG-APP-000014-CTR-000040","","The container platform must use TLS 1.2 or greater for secure communication.","","The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.",null,"Not Applicable","Review the container platform configuration to verify that TLS 1.2 or greater is being used for communication by the container platform nodes and components. \n\nIf TLS 1.2 or greater is not being used for secure communication, this is a finding.","","Configure the container platform to use TLS 1.2 or greater for node and component communication.","","CAT II",null,null,{"$f":"VLOOKUP(\"D0001\", Sheet1!A:B,2,0)","v":"D0001-   TLS settings\nRancher MCM runs on top of a Kubernetes cluster and does not  have the ability to configure at that level. It is important to configure the platform in a way that uses strong cryptography wherever possible.\n"},{"$f":"VLOOKUP(\"N0001\", Sheet1!M:N,2,0)","v":"RKE2 can configure this. Possibly inherently meets here because if the underlying platform provides the functionality then the applications should inherit. \n\nRancher MCM can, at the application/ingress level, configure ingress objects to use certain TLS settings but this is not at the node level.\n\nD0001 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0001 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (1)","CCI-000015","SRG-APP-000023-CTR-000055","","The container platform must use a centralized user management solution to support account management functions.","Rancher MCM must use a centralized user management solution to support account management functions.","Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error.\n\nA comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated or by disabling accounts located in non-centralized account stores, such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service.\n\nThe application must be configured to automatically provide account management functions, and these functions must immediately enforce the organization's current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure-providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies, that when placed together, contain an overall automated mechanism supporting an organization's automated account management requirements.\n\nAccount management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; or using automated telephonic notification to report atypical system account usage.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if it is using a centralized user management system for user management functions. \n\nIf the container platform is not using a centralized user management system for user management functions, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use a centralized user management system for user management functions.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (2)","CCI-000016","SRG-APP-000024-CTR-000060","","The container platform must automatically remove or disable temporary user accounts after 72 hours.","Temporary/Initial administrator accounts must be removed or disabled after 72 hours.","If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary user accounts must be set upon account creation.\n\nTemporary user accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation.\n\nIf temporary user accounts are used, the application must be configured to automatically terminate these types of accounts after a DoD-defined period of 72 hours.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0003\", Sheet1!A:B,2,0)","v":"D0003 - Temporary/Initial administrator accounts\nRancher MCM requires the set up of an initial administrator account when first launched. This administrative user is used to configure the portions of Rancher MCM. Once another form of authn/authz is configured this user is no longer needed and needs to be manually removed as it has unlimited privileges by default.   "},"Applicable - Configurable","Review the container platform configuration to determine if temporary user accounts are automatically removed or disabled after 72 hours. \n\nIf temporary user accounts are not automatically removed or disabled after 72 hours, this is a finding.","From the Main Menu, select Users & Authentication -> Users.\n\nVerifiy all Temporary/Initial administrator accounts user accounts are removed or inactive. If Temporary/Initial administrator accounts exist and state is not 'Inactive', this is a finding. \n\n ","Configure the container platform to automatically remove or disable temporary user accounts after 72 hours.","For each user to delete or set State to 'Inactive':\nFrom the Main Menu, select Users & Authentication -> Users.\n\nCheck the box next to the user to remove. \n\nClick the button to Delete. \n\nFollow the prompt to verify by typing the user for deletion (case sensitive). \n\nSelect Delete. ","CAT II",""]
["AC-2 (3)","CCI-000017","SRG-APP-000025-CTR-000065","","The container platform must automatically disable accounts after a 35-day period of account inactivity.","","Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.\n\nThis policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local login administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations.",null,"Not Applicable","Determine if the container platform automatically disables accounts after a 35-day period of account inactivity. \n\nIf the container platform does not automatically disable accounts after a 35-day period of account inactivity, this is a finding.",null,"Configure the container platform to automatically disable accounts after a 35-day period of account inactivity.",null,"CAT II","",null,"User management provided outside Rancher MCM scope. Rancher MCM uses external systems for user management and authentication. Rancher MCM then does authorization to determine access permissions.",{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-000018","SRG-APP-000026-CTR-000070","","The container platform must automatically audit account creation.","Rancher MCM must automatically audit account creation.","Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to create a new account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created, and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if audit records are automatically created upon account creation. \n\nIf audit records are not automatically created upon account creation, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically create audit records on account creation.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-2 (4)","CCI-001403","SRG-APP-000027-CTR-000075","","The container platform must automatically audit account modification.","","Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if account modification is automatically audited. \n\nIf account modification is not automatically audited, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account modification.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-2 (4)","CCI-001404","SRG-APP-000028-CTR-000080","","The container platform must automatically audit account-disabling actions.","","When application accounts are disabled, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to disable authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account-disabling actions provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if account disabling is automatically audited. \n\nIf account disabling is not automatically audited, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account disabling.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-2 (4)","CCI-001405","SRG-APP-000029-CTR-000085","","The container platform must automatically audit account removal actions.","","When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if account removal is automatically audited. \n\nIf account removal is not automatically audited, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account removal.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AC-3","CCI-000213","SRG-APP-000033-CTR-000090","","Least privilege access and need to know must be required to access the container platform registry.","","The container platform registry is used to store images and is the keeper of truth for trusted images within the platform. To guarantee the images integrity, access to the registry must be limited to those individuals who need to perform tasks to the images such as the update, creation, or deletion of images. Without this control access, images can be deleted that are in use by the container platform causing a denial of service (DoS), and images can be modified or introduced without going through the testing and validation process allowing for the intentional or unintentional introduction of containers with flaws and vulnerabilities.","","Not Applicable","Review the container platform configuration to determine if least privilege and need-to-know access is being used for container platform registry access. \n\nIf least privilege and need-to-know access is not being used for container platform registry access, this is a finding.","","Configure the container platform to use least privilege and need to know when granting access to the container platform registry. The fix ensures the proper roles and permissions are configured.","","CAT II","",null,"Rancher MCM has no integrated platform registry."]
["AC-3","CCI-000213","SRG-APP-000033-CTR-000095","","Least privilege access and need to know must be required to access the container platform runtime.","Least privilege access and need to know must be required to access Rancher MCM.","The container platform runtime is used to instantiate containers. If this process is accessed by those persons who are not authorized, those containers offering services can be brought to a denial of service (DoS) situation, disabling a large number of services with a small change to the container platform. To limit this threat, it is important to limit access to the runtime to only those individuals with runtime duties.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if only those individuals with runtime duties have access to the container platform runtime. \n\nIf users have access to the container platform runtime that do not have runtime duties, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use least privilege and need to know when granting access to the container runtime. The fix ensures the proper roles and permissions are configured.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-3","CCI-000213","SRG-APP-000033-CTR-000100","","Least privilege access and need to know must be required to access the container platform keystore.","Ensure the default role a user is assigned when allowed by the central authentication system is User-Base.","The container platform keystore is used to store access keys and tokens for trusted access to and from the container platform. The keystore gives the container platform a method to store the confidential data in a secure way and to encrypt the data when at rest. If this data is not protected through access controls, it can be used to access trusted sources as the container platform breaking the trusted relationship. To circumvent unauthorized access to the keystore, the container platform must have access controls in place to only allow those individuals with keystore duties.","Rancher MCM uses roles for authentication.  It is nessary to ensures the proper roles and permissions are configured. The role used by default does not ensure least privilege. The default role needs to be changed to allow least privilege access.","Applicable - Configurable","Review the container platform to determine if only those individuals with keystore duties have access to the container platform keystore. \n\nIf users have access to the container platform keystore that do not have keystore duties, this is a finding.","From the GUI, Navigate to:\nUsers & Authentication->Roles\n\nClick \"Standard User\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", ensure \"No\" is selected. \n\nClick \"User-Base\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", ensure \"Yes\" is selected\n\nIf \"No\" is not selected for Standard User, this is a finding. \nIf \"Yes\" is not selected for User-Base, this is a finding. ","Configure the container platform to use least privilege and need to know when granting access to the container keystore. The fix ensures the proper roles and permissions are configured.","From the GUI, Navigate to:\nUsers & Authentication->Roles\n\nClick \"Standard User\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", select \"No\" and click Save.\n\nClick \"User-Base\"\nAt the top right, click the 3 dots, and then \"Edit Config\"\nUnder \"New User Default\", select \"Yes\" and click \"Save\"","CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-4","CCI-001368","SRG-APP-000038-CTR-000105","","The container platform must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.","Rancher MCM must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.","Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are using labels and separate namespace for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies is being enforced. \n\nIf the organization-defined information flow policies are not being enforced, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-4","CCI-001414","SRG-APP-000039-CTR-000110","","The container platform must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies.","Rancher MCM must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies.","Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are: using labels for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if organization-defined information flow controls are implemented. \n\nIf information flow controls are not implemented, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to implement organization-defined information flow controls.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-7 a","CCI-000044","SRG-APP-000065-CTR-000115","","The container platform must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.","Rancher MCM must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.","By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if it is configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.\n\nIf the container platform is not configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-8 a","CCI-000048","SRG-APP-000068-CTR-000120","","The container platform must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components.","","The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.","","Not Applicable","Review the container platform configuration to determine if the Standard Mandatory DoD Notice and Consent Banner is configured to be displayed before granting access to platform components. \n\nLog in to the container platform components and verify that the Standard Mandatory DoD  Notice and Consent Banner is being displayed before granting access.\n\nIf the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding.","","Configure the container platform to display the Standard Mandatory DoD Notice and Consent Banner before granting access to container platform components.","","CAT III","",null,"Exhibiting and banner would be performed by the OS or any user services executing within Rancher MCM.","This has not been implemented by Rancher MCM as of writing this 08/10/2021"]
["AC-8 b","CCI-000050","SRG-APP-000069-CTR-000125","","The container platform must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.","","The banner must be acknowledged by the user prior to allowing the user access to any container platform component. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. \n\nTo establish acceptance of the application usage policy, a click-through banner at application logon is required. The application must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating \"OK\".","","Not Applicable","Log in to the container platform components to determine if the Standard Mandatory DoD Notice and Consent Banner remains on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access. \n\nIf the Standard Mandatory DoD Notice and Consent Banner does not stay on the screen until the users acknowledge the usage and conditions, this is a finding.","","Configure the container platform to retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.","","CAT III","",null,"Exhibiting and banner would be performed by the OS or any user services executing within Rancher MCM.","This has not been implemented by Rancher MCM as of writing this 08/10/2021"]
["AU-12 a","CCI-000169","SRG-APP-000089-CTR-000150","","The container platform must generate audit records for all DoD-defined auditable events within all components in the platform.","Rancher MCM must generate audit records for all DoD-defined auditable events within all components in the platform.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, including security incidents that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to have the appropriate and required data logged. To handle the need to log DoD-defined auditable events, the container platform must offer a mechanism to change and manage the events that are audited.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to generate audit records for all DoD-defined auditable events within all components in the platform. \n\nGenerate DoD-defined auditable events within all the components to determine if the events are being audited. \n\nIf the container platform is not configured to generate audit records for all DoD-defined auditable events within the components or the events are  not generating audit records, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records for all DoD-defined auditable events within all the components of the container platform.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-12 b","CCI-000171","SRG-APP-000090-CTR-000155","","The container platform must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.","Rancher MCM must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.","Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n \nThe list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to determine if the container platform is configured to allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited. \n\nIf the container platform is not configured to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"Rancher MCM can have Audit logging turned on at the app level (operations peformed inside Rancher), RKE2 can also have audit logging turned on at the platform level (operations performed on the kubernetes cluster).\n\nThis should be able to be translated to a notification system if auditing is aggregated and filtered.\n\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"]
["AU-12 c","CCI-000172","SRG-APP-000091-CTR-000160","","The container platform must generate audit records when successful/unsuccessful attempts to access privileges occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access privileges occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to generate audit records when successful/unsuccessful attempts are made to access privileges. \n\nIf the container platform is not configured to generate audit records on successful/unsuccessful access to privileges, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records when successful/unsuccessful attempts are made to access privileges occur.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-14 (1)","CCI-001464","SRG-APP-000092-CTR-000165","","The container platform must initiate session auditing upon startup.","Rancher MCM must initiate session auditing upon startup.","When the container platform is started, container platform components and user services can also be started. It is important that the container platform begin auditing on startup in order to handle container platform startup events along with events for container platform components and services that begin on startup.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration for session audits. \n\nEnsure audit policy for session logging at startup is enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf the container platform is not configured to meet this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit logs for session logging at startup. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000130","SRG-APP-000095-CTR-000170","","All audit records must identify what type of event has occurred within the container platform.","All audit records must identify what type of event has occurred within Rancher MCM.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know what type of event occurred.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration for audit event types. Ensure audit policy for event type is enabled. \n\nVerify records showing what type of event occurred are written to the log. \n\nValidate system documentation is current. \n\nIf log data does not show the type of event, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to include the event type in the log data. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000131","SRG-APP-000096-CTR-000175","","The container platform audit records must have a date and time association with all events.","Rancher MCM audit records must have a date and time association with all events.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know when the event occurred. To establish the time of the event, the audit record must contain the date and time.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration for audit events date and time. \n\nEnsure audit policy for event date and time are enabled. \n\nVerify records showing event date and time are included in the log. \n\nValidate system documentation is current. \n\nIf the date and time are not included, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to include log date and time with the event. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000132","SRG-APP-000097-CTR-000180","","All audit records must identify where in the container platform the event occurred.","All audit records must identify where in Rancher MCM the event occurred.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know where within the container platform the event occurred.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if all audit records identify where in the container platform the event occurred. \n\nGenerate audit records and view the audit records to verify that the records do identify where in the container platform the event occurred. \n\nIf the container platform is not configured to generate audit records that identify where in the container platform the event occurred, or if the generated audit records do not identify where in the container platform the event occurred, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records that identify where in the container platform the event occurred.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000133","SRG-APP-000098-CTR-000185","","All audit records must identify the source of the event within the container platform.","All audit records must identify the source of the event within Rancher MCM.","Audit data is important when there are issues, to include security incidents that must be investigated. Since the audit data may be part of a larger audit system, it is important for the audit data to also include the container platform name for traceability back to the container platform itself and not just the container platform components.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review container platform audit policy configuration for logons establishing the sources of events. \n\nEnsure audit policy is configured to generate sufficient information to resolve the source, e.g., source IP, of the log event. \n\nVerify records showing by requesting a user access the container platform and generate log events, and then review the logs to determine if the source of the event can be established. \n\nIf the source of the event cannot be determined, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform registry, keystore, and runtime to generate the source of each loggable event. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-000134","SRG-APP-000099-CTR-000190","","All audit records must generate the event results within the container platform.","All audit records must generate the event results within Rancher MCM.","Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know the outcome of the event.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if audit records contain the audit event results. \n\nGenerate audit records and review the data to validate that the record does contain the event result. \n\nIf the container platform is not configured to generate audit records with  the event result or the audit record does not contain the event result, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate audit records that contain the event result.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-001487","SRG-APP-000100-CTR-000195","","All audit records must identify any users associated with the event within the container platform.","All audit records must identify any users associated with the event within Rancher MCM.","Without information that establishes the identity of the user associated with the events, security personnel cannot determine responsibility for the potentially harmful event.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review container platform documentation and the log files on the application server to determine if the logs contain information that establishes the identity of the user or process associated with log event data. \n\nIf the container platform does not produce logs that establish the identity of the user or process associated with log event data, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform logging system to log the identity of the user or process related to the events.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3","CCI-001487","SRG-APP-000100-CTR-000200","","All audit records must identify any containers associated with the event within the container platform.","All audit records must identify any containers associated with the event within Rancher MCM.","Without information that establishes the identity of the containers offering user services or running on behalf of a user within the platform associated with audit events, security personnel cannot determine responsibility for potentially harmful events.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to generate audit records that contain the component information that generated the audit record. \n\nGenerate audit records and review the data to determine if records are generated containing the component information that generated the record. \n\nIf the container platform is not configured to generate audit records containing the component information or records are generated that do not contain the component information that generated the record, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to include the component information that generated the audit record.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-3 (1)","CCI-000135","SRG-APP-000101-CTR-000205","","The container platform must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.","Rancher MCM must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.","During an investigation of an incident, it is important to fully understand what took place. Often, information is not part of the audited event due to the data's nature, security risk, or audit log size. Organizations must consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. At a minimum, the organization must audit either full-text recording of privileged commands, or the individual identities of group users, or both.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review the documentation and deployment configuration to determine if the container platform is configured to generate full-text recording of privileged commands or the individual identities of group users at a minimum. \n\nHave a user execute a privileged command and review the log data to validate that the full-text or identity of the individual is being logged. \n\nIf the container platform is not meeting this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to generate the full-text recording of privileged commands, or the individual identities of group users, or both.",{"$f":"VLOOKUP(\"F0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II",""]
["AU-5 b","CCI-000140","SRG-APP-000109-CTR-000215","","The container platform must take appropriate action upon an audit failure.","Rancher MCM must take appropriate action upon an audit failure.","It is critical that when the container platform is at risk of failing to process audit logs as required that it take action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.\n\nBecause availability of the services provided by the container platform, approved actions in response to an audit failure are as follows:\n\n(i) If the failure was caused by the lack of audit record storage capacity, the container platform must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.\n\n(ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the container platform must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the configuration settings to determine how the container platform components are configured for audit failures. When the audit failure is due to the lack of audit record storage, the container platform must continue generating audit records, restarting services if necessary, and overwrite the oldest audit records in a first-in-first-out manner. \n\nIf the audit failure is due to a communication to a centralized collection server, the container platform must queue audit records locally until communication is restored or the records are retrieved manually.  \n\nIf the container platform is not configured to handle audit failures appropriately, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to continue generating audit records overwriting oldest audit records in a first-in-first-out manner when the failure is due to a lack of audit record storage.   When the audit failure is due to a communication to a centralized collection server, configure the container platform to queue audit records locally until communication is restored or the records are retrieved manually.  If other actions are to be taken for audit record failures, the actions and rationale must be documented in the system security plan and risk acceptance approvals must be obtained.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-6 (4)","CCI-000154","SRG-APP-000111-CTR-000220","","The container platform components must provide the ability to send audit logs to a central enterprise repository for review and analysis.","Rancher MCM components must provide the ability to send audit logs to a central enterprise repository for review and analysis.","The container platform components must send audit events to a central managed audit log repository to provide reporting, analysis, and alert notification. Incident response relies on successful timely, accurate system analysis in order for the organization to identify and respond to possible security events.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the configuration settings to determine if the container platform components are configured to send audit events to central managed audit log repository. \n\nIf the container platform is not configured to send audit events to central managed audit log repository, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform components to send audit logs to a central managed audit log repository.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-8 a","CCI-000159","SRG-APP-000116-CTR-000235","","The container platform must use internal system clocks to generate audit record time stamps.","","Understanding when and sequence of events for an incident is crucial to understand what may have taken place. Without a common clock, the components generating audit events could be out of synchronization and would then present a picture of the event that is warped and corrupted. To give a clear picture, it is important that the container platform and its components use a common internal clock.","","Applicable - Inherently Meets","Review the container platform configuration files to determine if the internal system clock is used for time stamps. \n\nIf the container platform does not use the internal system clock to generate time stamps, this is a finding.","","Configure the container platform to use internal system clocks to generate time stamps for log records.","","CAT II","",null,"Rancher MCM uses system clocks to generate time stamps. "]
["AU-9","CCI-000162","SRG-APP-000118-CTR-000240","","The container platform must protect audit information from any type of unauthorized read access.","Rancher MCM must protect audit information from any type of unauthorized read access.","If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access.\n\nThis requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories.\n\nAdditionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine where audit information is stored. \n\nIf the audit information is not protected from any type of unauthorized read access, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to protect the storage of audit information from unauthorized read access.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-000163","SRG-APP-000119-CTR-000245","","The container platform must protect audit information from unauthorized modification.","Rancher MCM must protect audit information from unauthorized modification.","If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification.\n\nThis requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.\n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine where audit information is stored. \n\nIf the audit log data is not protected from unauthorized modification, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect the storage of audit information from unauthorized modification.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-9","CCI-000164","SRG-APP-000120-CTR-000250","","The container platform must protect audit information from unauthorized deletion.","Rancher MCM must protect audit information from unauthorized deletion.","If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design.\n\nSome commonly employed methods include: ensuring log files receive the proper file system permissions utilizing file system protections, restricting access, and backing up log data to ensure log data is retained.\n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit information may include data from other applications or be included with the audit application itself.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine where audit information is stored. \n\nIf the audit log data is not protected from unauthorized deletion, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect the storage of audit information from unauthorized deletion.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-001493","SRG-APP-000121-CTR-000255","","The container platform must protect audit tools from unauthorized access.","Rancher MCM must protect audit tools from unauthorized access.","Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform to validate container platform audit tools are protected from unauthorized access. \n\nIf the audit tools are not protected from unauthorized access, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect audit tools from unauthorized access.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-001494","SRG-APP-000122-CTR-000260","","The container platform must protect audit tools from unauthorized modification.","Rancher MCM must protect audit tools from unauthorized modification.","Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform to validate container platform audit tools are protected from unauthorized modification. \n\nIf the audit tools are not protected from unauthorized modification, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to protect audit tools from unauthorized modification.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9","CCI-001495","SRG-APP-000123-CTR-000265","","The container platform must protect audit tools from unauthorized deletion.","Rancher MCM must protect audit tools from unauthorized deletion.","Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to validate container platform audit tools are protected from unauthorized deletion. \n\nIf the audit tools are not protected from unauthorized deletion, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to protect audit tools from unauthorized deletion.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["AU-9 (3)","CCI-001350","SRG-APP-000126-CTR-000275","","The container platform must use FIPS validated cryptographic mechanisms to protect the integrity of log information.","Rancher MCM must use FIPS validated cryptographic mechanisms to protect the integrity of log information.","To fully investigate an incident and to have trust in the audit data that is generated, it is important to put in place data protections. Without integrity protections, unauthorized changes may be made to the audit files and reliable forensic analysis and discovery of the source of malicious system activity may be degraded. Although digital signatures are one example of protecting integrity, this control is not intended to cause a new cryptographic hash to be generated every time a record is added to a log file. \n\nIntegrity protections can also be implemented by using cryptographic techniques for security function isolation and file system protections to protect against unauthorized changes.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if FIPS-validated cryptographic mechanisms are being used to protect the integrity of log information. \n\nIf FIPS-validated cryptographic mechanisms are not being used to protect the integrity of log information, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use FIPS-validated cryptographic mechanisms to protect the integrity of log information.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (3)","CCI-001749","SRG-APP-000131-CTR-000280","","The container platform must be built from verified packages.","","It is important to patch and upgrade the container platform when patches and upgrades are available. More important is to get these patches and upgrades from a known source. To validate the authenticity of any patches and upgrades before installation, the container platform must check that the files are digitally signed by sources approved by the organization.",{"$f":"VLOOKUP(\"D0008\", Sheet1!A:B,2,0)","v":"D0008 - Images are built securely\n\nRancher MCM Images are built on standard container images such as UBI7, UBI8, Alpine, and Scratch images. The required packages installed on these are verified using the standard package managers such as YUM and DNF to ensure security patches are authentic."},"Applicable - Inherently Meets","Review the container platform configuration to verify it has been built from packages that are digitally signed by known and approved sources. \n\nIf the container platform was built from packages that are not digitally signed or are from unknown or non-approved sources, this is a finding.","","Rebuild the container platform from verified packages that are digitally signed by known and approved sources.","","CAT II","",null,{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (3)","CCI-001749","SRG-APP-000131-CTR-000285","","The container platform must verify container images.","","The container platform must be capable of validating container images are signed and that the digital signature is from a recognized and approved source approved by the organization. Allowing any container image to be introduced into the registry and instantiated into a container can allow for services to be introduced that are not trusted and may contain malicious code, which introduces unwanted services. These unwanted services can cause harm and security risks to the hosting server, the container platform, other services running within the container platform, and the overall organization.","","Not Applicable","Review the container platform configuration to determine if container images are verified by enforcing image signing and that the image is signed recognized by an approved source. \n\nIf container images are not verified or the signature is not verified as a recognized and approved source, this is a finding.","","Configure the container platform to verify container images are digitally signed and the signature is from a recognized and approved source.","","CAT II","",null,"Container validation is outside the scope of Rancher MCM",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000290","","The container platform must limit privileges to the container platform registry.","","To control what is instantiated within the container platform, it is important to control access to the registry. Without this control, container images can be introduced and instantiated by accident or on container platform startup. Without control of the registry, security measures put in place for the runtime can be bypassed meaning the controls of approval and testing are also bypassed. Only those individuals and roles approved by the organization can have access to the container platform registry.","","Not Applicable","Review the container platform registry configuration to determine if the level of access to the registry is controlled through user privileges. \n\nAttempt to perform registry operations to determine if the privileges are enforced. \n\nIf the container platform registry is not limited through user privileges or the user privileges are not enforced, this is a finding.","","Configure the container platform to use and enforce user privileges when accessing the container platform registry.","","CAT II","",null,"Rancher MCM does not have a platform registry. ",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000295","","The container platform must limit privileges to the container platform runtime.","","To control what is instantiated within the container platform, it is important to control access to the runtime. Without this control, container platform specific services and customer services can be introduced without receiving approval and going through proper testing. Only those individuals and roles approved by the organization can have access to the container platform runtime.","","Not Applicable","Review the container platform runtime configuration to determine if the level of access to the runtime is controlled through user privileges. \n\nAttempt to perform runtime operations to determine if the privileges are enforced. \n\nIf the container platform runtime is not limited through user privileges or the user privileges are not enforced, this is a finding.","","Configure the container platform to use and enforce user privileges when accessing the container platform runtime.","","CAT II","",null,"Access to container runtime is outside the scope of Rancher MCM",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000300","","The container platform must limit privileges to the container platform keystore.","","The container platform keystore is used to store credentials used to build a trust between the container platform and some external source. This trust relationship is authorized by the organization. If a malicious user were to have access to the container platform keystore, two negative scenarios could develop:\n\n1) Keys not approved could be introduced and \n2) Approved keys deleted, leading to the introduction of container images from sources that were never approved by the organization. \n\nTo thwart this threat, it is important to protect the container platform keystore and give access to only those individuals and roles approved by the organization.","","Not Applicable","Review the container platform keystore configuration to determine if the level of access to the keystore is controlled through user privileges. \n\nAttempt to perform keystore operations to determine if the privileges are enforced. \n\nIf the container platform keystore is not limited through user privileges or the user privileges are not enforced, this is a finding.","","Configure the container platform to use and enforce user privileges when accessing the container platform keystore.","","CAT II","",null,"Keystore is managed by Kubernetes. Rancher MCM does not configure this. ",{"$f":"VLOOKUP(\"N0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000305","","Configuration files for the container platform must be protected.","","The secure configuration of the container platform must be protected by disallowing changes to be implemented by non-privileged users. Changes to the container platform can introduce security risks or stability issues and undermine change management procedures. Securing configuration files from non-privileged user modification can be enforced using file ownership and permissions.","","Not Applicable","Review the container platform to verify that configuration files cannot be modified by non-privileged users. \n\nIf non-privileged users can modify configuration files, this is a finding.","","Configure the container platform to only allow configuration modifications by privileged users.","","CAT II","",null,"This is accomplished outside the scope of Rancher MCM.",{"$f":"VLOOKUP(\"N0005\", Sheet1!M:N,2,0)","v":"N0005\nAudit logging in Rancher starts up when the app container starts with an ENV parameter. As stated in D0004 in this document, for all the logging there needs to have applied audit policies to the RKE2 platform as well. \n\nKubernetes has a api flag 'audit-log-mode=blocking-strict'  which actually prevents the Kube-API from proceeding with any action until it has successfully written the audit log. I have this in the RKE2 STIG under \n\nC0004\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nI don't think Rancher has this capability on it's own "}]
["CM-5 (6)","CCI-001499","SRG-APP-000133-CTR-000310","","Authentication files for the container platform must be protected.","Authentication files for Rancher MCM must be protected.","The secure configuration of the container platform must be protected by disallowing changing to be implemented by non-privileged users. Changes to the container platform can introduce security risks and stability issues and undermine change management procedures. To secure authentication files from non-privileged user modification can be enforced using file ownership and permissions.\n\nExamples of authentication files are keys, certificates, and tokens.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform to verify that authentication files cannot be modified by non-privileged users. \n\nIf non-privileged users can modify key and certificate files, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to only allow authentication file modifications by privileged users.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-7 a","CCI-000381","SRG-APP-000141-CTR-000315","","The container platform must be configured with only essential configurations.","","The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed.","","Applicable - Inherently Meets","Review the container platform configuration and verify that only those components needed for operation are installed. \n\nIf components are installed that are not used for the intended purpose of the organization, this is a finding.","","Identify the role the container platform is intended to play in the production environment and remove any components that are not needed or used for the intended purpose.","","CAT II","",null,"Mike Can you elabrate on how Rancher installs the components etc…"]
["CM-7 a","CCI-000381","SRG-APP-000141-CTR-000320","","The container platform registry must contain only container images for those capabilities being offered by the container platform.","","Allowing container images to reside within the container platform registry that are not essential to the capabilities being offered by the container platform becomes a potential security risk. By allowing these non-essential container images to exist, the possibility for accidental instantiation exists. The images may be unpatched, not supported, or offer non-approved capabilities. Those images for customer services are considered essential capabilities.",null,"Not Applicable","Review the container platform registry and the container images being stored. \n\nIf container images are stored in the registry and are not being used to offer container platform capabilities, this is a finding.","","Remove all container images from the container platform registry that are not being used or contain features and functions not supported by the platform.","","CAT II","",null,"Rancher MCM allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users."]
["CM-7 b","CCI-000382","SRG-APP-000142-CTR-000325","","The container platform runtime must enforce ports, protocols, and services that adhere to the PPSM CAL.","Rancher MCM runtime must enforce ports, protocols, and services that adhere to the PPSM CAL","Ports, protocols, and services within the container platform runtime must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy.",{"$f":"VLOOKUP(\"D0011\", Sheet1!A:B,2,0)","v":"D0011 - Ports Protocols, and Services\nRancher is designed to be deployed in a Kubernetes environment, which implies it is container based. Proper hardening of the surrounding environment is independent of Rancher MCM but ensures Rancher MCM will inherently meet security requirements.\n\nProperly configured Kubernetes environments use 3rd party proxies combined with control frameworks called ingress controllers which maintain the configuration state of the proxies for external traffic. Kubernetes also has internal control over network traffic through it's software defined network (SDN). This essentially means Kubernetes controls what ports are exposed to the container from both internal and external traffic. \n\nA default deployment of Rancher MCM exposes only port 80 (HTTP traffic) and port 443 (HTTPS traffic). These ports are enforced by the rest of the Kubernetes SDN and ingress controllers. The ports the server expects are dependant on what kubernetes routes are configurable, and should be verified."},"Applicable - Configurable","Review the container platform documentation and deployment configuration to determine which ports and protocols are enabled. \n\nVerify the ports and protocols being used are not prohibited by PPSM CAL in accordance to DoD Instruction 8551.01 Policy and are necessary for the operations and applications.\n\nIf any of the ports or protocols is prohibited or not necessary for the operation, this is a finding.",{"$f":"VLOOKUP(\"C0011\", Sheet1!C:D,2,0)","v":"C0011 - Check container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable. Note that other parts of the system could override this behavior.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Ports'\nEnsure 'Publish the container port' contains a setting of 80 or 443\n\nOpen the config panel 'Command'\nEnsure the 'Command' box contains '--http-listen-port=80 --https-listen-port=443'"},"Configure the container platform to disable any ports or protocols that are prohibited by the PPSM CAL and not necessary for the operation.",{"$f":"VLOOKUP(\"F0011\", Sheet1!E:F,2,0)","v":"F0011 - Fix container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nClick the configuration button (three dots) at the top right of the screen.\nSelect 'Edit'.\n\nEnsure port mapping contains only ports 80 or 443 are present for HTTP or HTTPS traffic. Click 'Add port' if additional mappings is required.\n\nClick 'Show advanced options' at the bottom of the page.\n\nOpen the 'Command' config panel.\nEnsure 'Command' contains '--http-listen-port=80 --https-listen-port=443', add if necessary."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-7 b","CCI-000382","SRG-APP-000142-CTR-000330","","The container platform runtime must enforce the use of ports that are non-privileged.","Rancher MCM runtime must enforce the use of ports that are non-privileged.","Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container.",{"$f":"VLOOKUP(\"D0011\", Sheet1!A:B,2,0)","v":"D0011 - Ports Protocols, and Services\nRancher is designed to be deployed in a Kubernetes environment, which implies it is container based. Proper hardening of the surrounding environment is independent of Rancher MCM but ensures Rancher MCM will inherently meet security requirements.\n\nProperly configured Kubernetes environments use 3rd party proxies combined with control frameworks called ingress controllers which maintain the configuration state of the proxies for external traffic. Kubernetes also has internal control over network traffic through it's software defined network (SDN). This essentially means Kubernetes controls what ports are exposed to the container from both internal and external traffic. \n\nA default deployment of Rancher MCM exposes only port 80 (HTTP traffic) and port 443 (HTTPS traffic). These ports are enforced by the rest of the Kubernetes SDN and ingress controllers. The ports the server expects are dependant on what kubernetes routes are configurable, and should be verified."},"Applicable - Configurable","Review the container platform configuration and the containers within the platform by performing the following checks:\n\n1. Verify the container platform is configured to disallow the use of privileged ports by containers.\n2. Validate all containers within the container platform are using non-privileged ports.\n3. Attempt to instantiate a container image that uses a privileged port.\n\nIf the container platform is not configured to disallow the use of privileged ports, this is a finding.\n\nIf the container platform has containers using privileged ports, this is a finding.\n\nIf the container platform allows containers to be instantiated that use privileged ports, this is a finding.",{"$f":"VLOOKUP(\"C0011\", Sheet1!C:D,2,0)","v":"C0011 - Check container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable. Note that other parts of the system could override this behavior.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Ports'\nEnsure 'Publish the container port' contains a setting of 80 or 443\n\nOpen the config panel 'Command'\nEnsure the 'Command' box contains '--http-listen-port=80 --https-listen-port=443'"},"Configure the container platform to disallow the use of privileged ports by containers. Move any containers that are using privileged ports to non-privileged ports.",{"$f":"VLOOKUP(\"F0011\", Sheet1!E:F,2,0)","v":"F0011 - Fix container ports\nFrom the Rancher UI the ports configured by Kubernetes and the ports that the server use are viewable and configurable.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nClick the configuration button (three dots) at the top right of the screen.\nSelect 'Edit'.\n\nEnsure port mapping contains only ports 80 or 443 are present for HTTP or HTTPS traffic. Click 'Add port' if additional mappings is required.\n\nClick 'Show advanced options' at the bottom of the page.\n\nOpen the 'Command' config panel.\nEnsure 'Command' contains '--http-listen-port=80 --https-listen-port=443', add if necessary."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000335","","The container platform must uniquely identify and authenticate users.","Rancher MCM must uniquely identify and authenticate users.","The container platform requires user accounts to perform container platform tasks. These tasks may pertain to the overall container platform or may be component-specific, thus requiring users to authenticate against those specific components. To ensure accountability and prevent unauthenticated access, users must be identified and authenticated to prevent potential misuse and compromise of the system.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if users are uniquely identified and authenticated. \n\nIf users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to uniquely identify and authenticate users.",{"$f":"VLOOKUP(\"F0002\",'[1] Sheet4'!E:F,2,0)","v":{"$error":"#N/A"}},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000340","","The container platform application program interface (API) must uniquely identify and authenticate users.","Rancher MCM application program interface (API) must uniquely identify and authenticate users.","The container platform requires user accounts to perform container platform tasks. These tasks are often performed through the container platform API. Protecting the API from users who are not authorized or authenticated is essential to keep the container platform stable. Protection of platform and application data and enhances the protections put in place for Denial-of Service (DoS) attacks.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if users are uniquely identified and authenticated before the API is executed. \n\nIf users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to uniquely identify and authenticate users before container platform API access.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000345","","The container platform must uniquely identify and authenticate processes acting on behalf of the users.","Rancher MCM must uniquely identify and authenticate processes acting on behalf of the users.","The container platform will instantiate a container image and use the user privileges given to the user used to execute the container. To ensure accountability and prevent unauthenticated access to containers, the user the container is using to execute must be uniquely identified and authenticated to prevent potential misuse and compromise of the system.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if processes acting on behalf of users are uniquely identified and authenticated. \n\nIf processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to uniquely identify and authenticate processes acting on behalf of users.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"The screen where logging aggregation is set up/administered through he Rancher GUI is protected by the Rancher RBAC. For a person to delete this they would need to have permissions allowing it. \n\nThis is separate from a user having permissions in kubernetes straight up that would allow a person to delete the logging aggregation system.\n\nThird- a person could go through the OS itself to make modifications to logging subsystems.\n\nNot sure how to properly enumerate these things."]
["IA-2","CCI-000764","SRG-APP-000148-CTR-000350","","The container platform application program interface (API) must uniquely identify and authenticate processes acting on behalf of the users.","Rancher MCM application program interface (API) must uniquely identify and authenticate processes acting on behalf of the users.","The container platform API can be used to perform any task within the platform. Often, the API is used to create tasks that perform some kind of maintenance task and run without user interaction. To guarantee the task is authorized, it is important to authenticate the task. These tasks, even though executed without user intervention, run on behalf of a user and must run with the user's authorization. If tasks are allowed to be created without authentication, users could bypass authentication and authorization mechanisms put in place for user interfaces. This could lead to users gaining greater access than given to the user putting the container platform into a compromised state.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform API configuration to determine if processes acting on behalf of users are uniquely identified and authenticated. \n\nIf processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform API to uniquely identify and authenticate processes acting on behalf of users.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"Rancher doesn't do any log aggregation by itself, only assists with the integration. It would be on the logging aggregator, such as splunk, to provide this control."]
["IA-2 (1)","CCI-000765","SRG-APP-000149-CTR-000355","","The container platform must use multifactor authentication for network access to privileged accounts.","Rancher MCM must use multifactor authentication for network access to privileged accounts.","Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased.\n\nMultifactor authentication requires using two or more factors to achieve authentication.\n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric).\n\nA privileged account is defined as an information system account with authorizations of a privileged user.\n\nNetwork access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet).",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to privileged accounts. \n\nIf the container platform does not use multifactor authentication for network access to privileged accounts, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use multifactor authentication for network access to privileged accounts.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["IA-2 (2)","CCI-000766","SRG-APP-000150-CTR-000360","","The container platform must use multifactor authentication for network access to non-privileged accounts.","Rancher MCM must use multifactor authentication for network access to non-privileged accounts.","To ensure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.\n\nMultifactor authentication uses two or more factors to achieve authentication.\n\nFactors include: \n(i) Something you know (e.g., password/PIN); \n(ii) Something you have (e.g., cryptographic identification device, token); or \n(iii) Something you are (e.g., biometric).\n\nA non-privileged account is any information system account with authorizations of a non-privileged user.\n\nNetwork access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection.\n\nApplications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to non-privileged accounts. \n\nIf the container platform does not use multifactor authentication for network access to non-privileged accounts, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to use multifactor authentication for network access to non-privileged accounts.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["IA-2 (3)","CCI-000767","SRG-APP-000151-CTR-000365","","The container platform must use multifactor authentication for local access to privileged accounts.","","To ensure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.\n\nMultifactor authentication is defined as using two or more factors to achieve authentication.\n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric).\n\nA privileged account is defined as an information system account with authorizations of a privileged user.\n\nLocal access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.","","Not Applicable","Review the container platform configuration to determine if multifactor authentication is used for local access to privileged accounts. \n\nIf multifactor authentication for local access to privileged accounts is not being used, this is a finding.","","Configure the container platform to use multifactor authentication for local access to privileged accounts.","","CAT II","",null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["IA-2 (4)","CCI-000768","SRG-APP-000152-CTR-000370","","The container platform must use multifactor authentication for local access to non-privileged accounts.","","To ensure accountability, prevent unauthenticated access, and prevent misuse of the system, non-privileged users must utilize multi-factor authentication for local access.\n\nMultifactor authentication is defined as using two or more factors to achieve authentication.\n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric).\n\nA non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user.\n\nLocal access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.","","Not Applicable","Review the container platform configuration to determine if multifactor authentication is used for local access to non-privileged accounts. \n\nIf multifactor authentication for local access to non-privileged accounts is not being used, this is a finding.","","Configure the container platform to use multifactor authentication for local access to non-privileged accounts.","","CAT II","",null,{"$f":"VLOOKUP(\"N0009\", Sheet1!M:N,2,0)","v":"N0009 - Rancher MCM is a container running on a kubernetes platform\nRancher does not provide the capability of modifying the container Runtime. \n\nIt also does not have access to the full filesystem of the underlying OS. Only certain paths are mounted to the Rancher containers."}]
["IA-2 (5)","CCI-000770","SRG-APP-000153-CTR-000375","","The container platform must ensure users are authenticated with an individual authenticator prior to using a group authenticator.","Rancher MCM must ensure users are authenticated with an individual authenticator prior to using a group authenticator.","To ensure individual accountability and prevent unauthorized access, application users must be individually identified and authenticated.\n\nIndividual accountability mandates that each user be uniquely identified. A group authenticator is a shared account or some other form of authentication that allows multiple unique individuals to access the application using a single account.\n\nIf an application allows or provides for group authenticators, it must first individually authenticate users prior to implementing group authenticator functionality.\n\nSome applications may not need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.\n\nThere may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server, which contains publicly releasable information.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Not Applicable","Review the container platform configuration to determine if the container platform is configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator. \n\nIf the container platform is not configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator, this is a finding.","","Configure the container platform to ensure users are authenticated with an individual authenticator prior to using a group authenticator.","","CAT II","",null,{"$f":"VLOOKUP(\"N0009\", Sheet1!M:N,2,0)","v":"N0009 - Rancher MCM is a container running on a kubernetes platform\nRancher does not provide the capability of modifying the container Runtime. \n\nIt also does not have access to the full filesystem of the underlying OS. Only certain paths are mounted to the Rancher containers."}]
["IA-2 (8)","CCI-001941","SRG-APP-000156-CTR-000380","","The container platform must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.","","A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAnti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoD PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also compliant.\n\nConfigure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.","","Not Applicable","Review the container platform configuration to determine if the container platform is configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. \n\nIf the container platform is not configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts, this is a finding.","","Configure the container platform to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.","","CAT II","",null,{"$f":"VLOOKUP(\"N0009\", Sheet1!M:N,2,0)","v":"N0009 - Rancher MCM is a container running on a kubernetes platform\nRancher does not provide the capability of modifying the container Runtime. \n\nIt also does not have access to the full filesystem of the underlying OS. Only certain paths are mounted to the Rancher containers."}]
["IA-2 (9)","CCI-001942","SRG-APP-000157-CTR-000385","","The container platform must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.","","A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.\n\nA non-privileged account is any operating system account with authorizations of a non-privileged user.\n\nTechniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.","","Applicable - Inherently Meets","Review the container platform configuration to determine if the container platform is configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts. \n\nIf the container platform is not configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts, this is a finding.","","Configure the container platform to provide replay-resistant authentication mechanisms for network access to non-privileged accounts.","","CAT II","",null,"Rancher MCM protects all keys and secrets it has control over via RBAC. ","Example would be access keys and tokens. Host files are not controlled by Rancher so things like node-node certificates and keys are not under Ranchers control. Rancher also can't see node-tokens generated by RKE2. These would need OS file permission protection and OS level authentication."]
["IA-3","CCI-000778","SRG-APP-000158-CTR-000390","","The container platform must uniquely identify all network-connected nodes before establishing any connection.","","A container platform usually consists of multiple nodes. It is important for these nodes to be uniquely identified before a connection is allowed. Without identifying the nodes, unidentified or unknown nodes may be introduced, thereby facilitating malicious activity.","","Not Applicable","Review the container platform configuration to determine if the container platform uniquely identifies all nodes before establishing a connection. \n\nIf the container platform is not configured to uniquely identify all nodes before establishing the connection, this is a finding.","","Configure the container platform to uniquely identify all nodes before establishing the connection.","","CAT II","",null,"Basic installation of Rancher does not enable any non-required items."]
["IA-4 e","CCI-000795","SRG-APP-000163-CTR-000395","","The container platform must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.","Rancher MCM must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.","Inactive identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.\n\nApplications need to track periods of inactivity and disable application identifiers after 35 days of inactivity.\n\nManagement of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual.\n\nTo avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity. \n\nIf identifiers are not disabled after 35 days of inactivity, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["IA-5 (1) (a)","CCI-000205","SRG-APP-000164-CTR-000400","","The container platform must enforce a minimum 15-character password length.","Rancher MCM must enforce a minimum 15-character password length.","The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.\n\nPassword complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.\n\nUse of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform enforces a minimum 15-character password length. \n\nIf the container platform does not enforce a 15-character password length, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce a minimum 15-character password length.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0011\", Sheet1!M:N,2,0)","v":"Rancher MCM is a web application. RKE2 hosts kubernetes and all ports associated with that with a few extras like 6443 and 9345\n\nD0012 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n"}]
["IA-5 (1) (e)","CCI-000200","SRG-APP-000165-CTR-000405","","The container platform must prohibit password reuse for a minimum of 10 generations.","Rancher MCM must prohibit password reuse for a minimum of 10 generations.","Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals.\n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the result is a password that is not changed as per policy requirements.\n\nThe references for this check are:\nNIST SP 800-53 :: IA-5 (1) (e)\nNIST SP 800-53A :: IA-5 (1).1 (v)\nNIST SP 800-53 Revision 4 :: IA-5 (1)\nCNSS 1253",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it prohibits password reuse for a minimum of five generations. \n\nIf the container platform does not prohibit password reuse for a minimum of five generations, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to prohibit password reuse for a minimum of five generations.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0011\", Sheet1!M:N,2,0)","v":"Rancher MCM is a web application. RKE2 hosts kubernetes and all ports associated with that with a few extras like 6443 and 9345\n\nD0012 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n"}]
["IA-5 (1) (a)","CCI-000192","SRG-APP-000166-CTR-000410","","The container platform must enforce password complexity by requiring that at least one uppercase character be used.","Rancher MCM must enforce password complexity by requiring that at least one uppercase character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one uppercase character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one uppercase character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one uppercase character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (a)","CCI-000193","SRG-APP-000167-CTR-000415","","The container platform must enforce password complexity by requiring that at least one lowercase character be used.","Rancher MCM must enforce password complexity by requiring that at least one lowercase character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one lowercase character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one lowercase character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one lowercase character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (a)","CCI-000194","SRG-APP-000168-CTR-000420","","The container platform must enforce password complexity by requiring that at least one numeric character be used.","Rancher MCM must enforce password complexity by requiring that at least one numeric character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one numeric character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one numeric character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one numeric character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (a)","CCI-001619","SRG-APP-000169-CTR-000425","","The container platform must enforce password complexity by requiring that at least one special character be used.","Rancher MCM must enforce password complexity by requiring that at least one special character be used.","Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nSpecial characters are those characters that are not alphanumeric. Examples include ~ ! @ # $ % ^ *.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces password complexity by requiring that at least one special character be used. \n\nIf the container platform does not enforce password complexity by requiring that at least one special character be used, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce password complexity by requiring that at least one special character be used.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (b)","CCI-000195","SRG-APP-000170-CTR-000430","","The container platform must require the change of at least 15 of the total number of characters when passwords are changed.","Rancher MCM must require the change of at least 15 of the total number of characters when passwords are changed.","If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.\n\nThe number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it requires the change of at least 15 of the total number of characters when passwords are changed. \n\nIf the container platform does not require the change of at least 15 of the total number of characters when passwords are changed, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to require the change of at least 15 of the total number of characters when passwords are changed.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (c)","CCI-000196","SRG-APP-000171-CTR-000435","","For container platform using password authentication, the application must store only cryptographic representations of passwords.","Rancher MCM using password authentication, the application must store only cryptographic representations of passwords.","Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication.\n\nExamples of situations where a user ID and password might be used include:\n\n- When the user does not use a CAC and is not a current DoD employee, member of the military, or DoD contractor.\n\n- When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied.\n\n- When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection.\n\nIf the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security.\n\nVerifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows:\n\nH0 = H(pwd, H(salt))\nHn = H(Hn-1,H(salt))\n\nIn the above, \"n\" is a cryptographically-strong random [*3] number. \"Hn\" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares \"Hn\" with the stored \"Hn\". A salt is essentially a fixed-length cryptographically strong random value.\n\nAnother method is using a keyed-hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key.\n\nThis requirement applies to all accounts including authentication server, AAA, and local account, including the root account and the account of last resort.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it using password authentication and stores only cryptographic representations of the passwords. \n\nIf the container platform is using password authentication and does not store only cryptographic representations of passwords, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to store only cryptographic representations of passwords if passwords are being used for authentication.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (c)","CCI-000197","SRG-APP-000172-CTR-000440","","For accounts using password authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.","For accounts using password authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.","Passwords need to be protected on entry, in transmission, during authentication, and when stored. If compromised at any of these security points, a nefarious user can use the password along with stolen user account information to gain access or to escalate privileges. The container platform may require account authentication during container platform tasks and before accessing container platform components, e.g. runtime, registry, and keystore.\n\nDuring any user authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the documentation and configuration to determine if the container platform enforces the required FIPS-validated encrypt passwords when they are transmitted. \n\nIf the container platform is not configured to meet this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to transmit only encrypted FIPS-validated SHA-2 or later representations of passwords.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT I","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (d)","CCI-000198","SRG-APP-000173-CTR-000445","","The container platform must enforce 24 hours (one day) as the minimum password lifetime.","Rancher MCM must enforce 24 hours (one day) as the minimum password lifetime.","Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement.\n\nRestricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy-based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces 24 hours/1 day as the minimum password lifetime. \n\nIf the container platform does not enforce 24 hours/1 day as the minimum password lifetime, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce 24 hours/1 day as the minimum password lifetime.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-5 (1) (d)","CCI-000199","SRG-APP-000174-CTR-000450","","The container platform must enforce a 60-day maximum password lifetime restriction.","Rancher MCM must enforce a 60-day maximum password lifetime restriction.","Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. \n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. \n\nThis requirement does not include emergency administration accounts that are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if it enforces a 60-day maximum password lifetime restriction. \n\nIf the container platform does not enforce a 60-day maximum password lifetime restriction, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce a 60-day maximum password lifetime restriction.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"This might be RBAC, but upgrading Rancher is technically done out of band from Ranchers capability itself. An cattle-system namespace administrator external of Rancher with Rancher or Kube credentials needs to update using Helm. If that makes any sense at all. This might be N/A"]
["IA-5 (2) (c)","CCI-000187","SRG-APP-000177-CTR-000465","","The container platform must map the authenticated identity to the individual user or group account for PKI-based authentication.","Rancher MCM must map the authenticated identity to the individual user or group account for PKI-based authentication.","The container platform and its components may require authentication before use. When the authentication is PKI-based, the container platform or component must map the certificate to a user account. If the certificate is not mapped to a user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation and configuration to ensure the container platform provides a PKI integration capability that meets DoD PKI infrastructure requirements. \n\nIf the container platform is not configured to meet this requirement, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to utilize the DoD Enterprise PKI infrastructure.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-6","CCI-000206","SRG-APP-000178-CTR-000470","","The container platform must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.","Rancher MCM must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.","To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the container platform and its components, e.g., runtime, registry, and keystore, must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.\n\nObfuscation of user-provided information when typed is a method used in addressing this risk.\n\nDisplaying asterisks when a user types in a password is an example of obscuring feedback of authentication information.",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review container platform documentation and configuration to determine if any interfaces that are provided for authentication purposes display the user's password when it is typed into the data entry field. \n\nIf authentication information is not obfuscated when entered, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-7 a","CCI-001876","SRG-APP-000181-CTR-000485","","The container platform must provide an audit reduction capability that supports on-demand reporting requirements.","Rancher MCM must provide an audit reduction capability that supports on-demand reporting requirements.","The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. \n\nAudit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports.\n\nThis requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to provide an audit reduction capability that supports on-demand reporting requirements. \n\nIf the container platform is not configured to support on-demand reporting requirements, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to support on-demand reporting requirements.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["MA-4 c","CCI-000877","SRG-APP-000185-CTR-000490","","The container platform must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.","Rancher MCM must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.","If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information, and potentially sensitive application data.\n\nNon-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.\n\nThis requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing \"ping,\" \"ls,\" \"ipconfig,\" or the hardware and software implementing the monitoring port of an Ethernet switch).",{"$f":"VLOOKUP(\"D0002\",Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. \n\nIf the container platform is not configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions, this is a finding.",{"$f":"VLOOKUP(\"C0002\",Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.",{"$f":"VLOOKUP(\"F0002\",Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-10","CCI-001133","SRG-APP-000190-CTR-000500","","The application must terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity;","","Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. \n\nTerminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection. This does not mean that the application terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.","","Applicable - Inherently Meets","This requirement is NA for this technology.","","The requirement is NA. No fix is required.","","CAT II","",null," All ports used by Rancher are needed by default."]
["SC-2","CCI-001082","SRG-APP-000211-CTR-000530","","The container platform must separate user functionality (including user interface services) from information system management functionality.","","Separating user functionality from management functionality is a requirement for all the components within the container platform. Without the separation, users may have access to management functions that can degrade the container platform and the services being offered and can offer a method to bypass testing and validation of functions before introduced into a production environment.\n\nThe separation should be enforced by each component within the container platform.","","Applicable - Inherently Meets","Review the container platform configuration to determine if management functionality is separated from user functionality. \n\nValidate that the separation is also implemented within the components by trying to execute management functions for each component as a user. \n\nIf the container platform is not configured to separate management and user functionality or if component management and user functionality are not separated, this is a finding.",null,"Configure the container platform and its components to separate management and user functionality.","","CAT II","",null,"Management and User fuctionality is separated by default. ",{"$f":"VLOOKUP(\"N0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-23","CCI-001184","SRG-APP-000219-CTR-000550","","The container platform must protect authenticity of communications sessions with the use of FIPS-validated 140-2 or 140-3 security requirements for cryptographic modules.","","The container platform is responsible for pulling images from trusted sources and placing those images into its registry. To protect the transmission of images, the container platform must use FIPS-validated 140-2 or 140-3 cryptographic modules. This added protection defends against main-in-the-middle attacks where malicious code could be added to an image during transmission.","","Not Applicable","Review the container platform configuration to determine if FIPS-validated 140-2 or 140-3 cryptographic modules are being used to protect container images during transmission. \n\nIf FIPS-validated 140-2 or 140-3 cryptographic modules are not being use, this is a finding.","","Configure the container platform to use FIPS-validated 140-2 or 140-3 cryptographic modules to protect container images during transmission.","","CAT I","",null,{"$f":"VLOOKUP(\"N0010\", Sheet1!M:N,2,0)","v":"N0010 - \nRancher MCM does not have an integrated container registry.\n\nIt is important to verify container images to ensure the software supply chain is not compromised. RKE2 attempts to be as non-prescriptive as possible and in doing so does not dictate how a container registry should be configured and used. All organizations should implement a process of initially pulling and verifying images from SUSE/RGS and then maintaining that integrity. This can be done through the use of their own container registries, notaries, or other methods of verification."}]
["SC-24","CCI-001190","SRG-APP-000225-CTR-000570","","The container platform runtime must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.","","The container platform offers services for container image orchestration and services for users. If any of these services were to fail into an insecure state, security measures for user and data separation and image instantiation could become absent. In addition, audit log protections could be relaxed allowing for investigation of what occurred could be lost. To protect services and data, it is important for the container platform to fail to a secure state if the container platform registry initialization fails, shutdown fails, or aborts fail.","","Not Applicable","Review documentation and configuration to determine if the container platform runtime fails to a secure state if system initialization fails, shutdown fails, or aborts fail. \n\nIf the container platform runtime cannot be configured to fail securely, this is a finding.","","Configure the container platform runtime to fail to a secure state if system initialization fails, shutdown fails, or aborts fail.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-24","CCI-001665","SRG-APP-000226-CTR-000575","","The container platform must preserve any information necessary to determine the cause of the disruption or failure.","","When a failure occurs within the container platform, preserving the state of the container platform and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.","","Not Applicable","Review the container platform configuration to determine if information necessary to determine the cause of a disruption or failure is preserved. \n\nIf the information is not preserved, this is a finding.","","Configure the container platform to preserve information necessary to determine the cause of the disruption or failure.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-3","CCI-001084","SRG-APP-000233-CTR-000585","","The container platform runtime must isolate security functions from non-security functions.","","The container platform runtime must be configured to isolate those services used for security functions from those used for non-security functions. This separation can be performed using environment variables, labels, network segregation, and kernel groups.","","Not Applicable","Verify container platform runtime configuration settings to determine whether container services used for security functions are located in an isolated security function such as a separate environment variables, labels, network segregation, and kernel groups.\n\nIf security-related functions are not separate, this is a finding.","","Configure the container platform runtime to isolate security functions from non-security functions.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (2)","CCI-001682","SRG-APP-000234-CTR-000590","","The container platform must never automatically remove or disable emergency accounts.","","Emergency accounts are administrator accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability.\n\nEmergency accounts are different from infrequently used accounts (i.e., local logon accounts used by system administrators when network or normal logon/access is not available). Infrequently used accounts also remain available and are not subject to automatic termination dates. However, an emergency account is normally a different account that is created for use by vendors or system maintainers.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0003\", Sheet1!A:B,2,0)","v":"D0003 - Temporary/Initial administrator accounts\nRancher MCM requires the set up of an initial administrator account when first launched. This administrative user is used to configure the portions of Rancher MCM. Once another form of authn/authz is configured this user is no longer needed and needs to be manually removed as it has unlimited privileges by default.   "},"Applicable - Inherently Meets","Review the container platform to determine if emergency accounts are automatically removed or disabled. \n\nIf emergency accounts are automatically removed or disabled, this is a finding.","","Configure the container platform to never remove or disable emergency accounts.","","CAT II","",null,"When Rancher MCM is first set up it creates a local auth administrator account. This account does not go away automatically and is considered an emergency account.",{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-4","CCI-001090","SRG-APP-000243-CTR-000595","","The container platform must prohibit containers from accessing privileged resources.","","Containers images instantiated within the container platform may request access to host system resources. Access to privileged resources can allow for unauthorized and unintended transfer of information, but in some cases, these resources may be needed for the service being offered by the container. By default, containers should be denied instantiation when privileged system resources are requested and granted only after approval has been given.\n\nWhen access to privileged resources is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged access to host system resources.\n\nExamples of system resources that should be protected are kernel namespaces and host system sensitive directories such as /etc and /usr.","","Not Applicable","Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to access host system privileged resources. \n\nIf the container platform does not block containers requesting host system privileged resources, this is a finding.","","Configure the container platform to block instantiation of containers requesting access to host system-privileged resources.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-4","CCI-001090","SRG-APP-000243-CTR-000600","","The container platform must prevent unauthorized and unintended information transfer via shared system resources.","","The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users.","","Not Applicable","Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process. \n\nIf the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding.","","Deploy a container platform capable of effectively protecting the resources of one process or user from unauthorized access by another user or process. Configure the container platform to effectively protect the resources of one process or user from unauthorized access by another user or process. The container security solution should help the user understand where the code in the environment was deployed from, and provide controls that prevent deployment from untrusted sources or registries.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SC-5 (1)","CCI-001094","SRG-APP-000246-CTR-000605","","The container platform must restrict individuals' ability to launch organizationally defined denial-of-service (DoS) attacks against other information systems.","","The container platform will offer services to users and these services share resources available on the hosting system. To share the resources in a manner that does not exhaust or over utilize resources, it is necessary for the container platform to have mechanisms that allow developers to size there containers to provide minimum and maximum amounts. If there is no mechanism to specify limits, container services can cause DoS by over utilization.","","Not Applicable","Review the container platform implementation and security documentation and components settings to determine if the information system restricts the ability of users or systems to launch organization-defined DoS attacks against other information systems or networks from the container platform. \n\nIf the container platform is not configured to restrict this ability, this is a finding.","","Configure the container platform to restrict the ability of users or other systems to launch DoS attacks from the container platform components by setting resource quotas on resources such as memory, storage, and CPU utilization.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["SI-11 a","CCI-001312","SRG-APP-000266-CTR-000625","","The container platform must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.","","The container platform is responsible for offering services to users. These services could be across diverse user groups and data types. To protect information about the container platform, services, users, and data, it is important during error message generation to offer enough information to diagnose the error, but not reveal information that needs to be protected.","","Not Applicable","Review documentation and logs to determine if the container platform writes sensitive information such as passwords or private keys into the logs and administrative messages. \n\nIf the container platform writes sensitive or potentially harmful information into the logs and administrative messages, this is a finding.","","Configure the container platform to not write sensitive information into the logs and administrative messages.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-9 (3)","CCI-001496","SRG-APP-000290-CTR-000670","","The container platform must use cryptographic mechanisms to protect the integrity of audit tools.","Rancher MCM must use cryptographic mechanisms to protect the integrity of audit tools.","Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nAudit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.\n\nIt is common for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.\n\nTo address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if the integrity of the audit tools is protected using cryptographic mechanisms. \n\nIf audit tools are not protected through cryptographic mechanisms, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use cryptographic mechanisms to protect the integrity of audit tools.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-001683","SRG-APP-000291-CTR-000675","","The container platform must notify system administrators and ISSO when accounts are created.","","Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Sending notification of account creation events to the system administrator and ISSO is one method for mitigating this risk.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are created. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are created.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-2 (4)","CCI-001684","SRG-APP-000292-CTR-000680","","The container platform must notify system administrators and ISSO when accounts are modified.","","When application accounts are modified, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account modification events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are modified. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are modified.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-2 (4)","CCI-001685","SRG-APP-000293-CTR-000685","","The container platform must notify system administrators and ISSO for account disabling actions.","","When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account disabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are disabled. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are disabled.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-2 (4)","CCI-001686","SRG-APP-000294-CTR-000690","","The container platform must notify system administrators and ISSO for account removal actions.","","When application accounts are removed, user accessibility is affected. Accounts are utilized for identifying users or for identifying the application processes themselves. Sending notification of account removal events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time, and provides logging that can be used for forensic purposes.\n\nTo address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are removed. \n\nIf system administrators and ISSO are not notified, this is a finding.","","Configure the container platform to notify system administrators and ISSO when accounts are removed.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-12 (1)","CCI-002364","SRG-APP-000297-CTR-000705","","Access to the container platform must display an explicit logout message to user indicating the reliable termination of authenticated communication sessions.","","Access to the container platform will occur through web and terminal sessions. Any web interfaces must conform to application and web security requirements. Terminal access to the container platform and its components must provide a logout facility that terminates the connection to the component or the platform.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Inherently Meets","Review documentation and configuration settings to determine if the container platform displays a logout message. \n\nIf the container platform does not display a logout message, this is a finding.",null,"Configure the container platform components to display an explicit logout message to users.",null,"CAT III","",null,"Rancher MCM provides a logout message by default in the core install. This is not configurable. ",{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (10)","CCI-002142","SRG-APP-000317-CTR-000735","","The container platform must terminate shared/group account credentials when members leave the group.","Rancher MCM must terminate shared/group account credentials when members leave the group.","If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. A shared/group account credential is a shared form of authentication that allows multiple individuals to access the application using a single account. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. Examples of credentials include passwords and group membership certificates.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Determine if the container platform is configured to terminate shared/group account credentials when members leave the group. \n\nIf the container platform does not terminated shared/group account credentials when members leave the group, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to terminate shared/group account credentials when members leave the group.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,{"$f":"VLOOKUP(\"n0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (11)","CCI-002145","SRG-APP-000318-CTR-000740","","The container platform must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.","Rancher MCM must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.","Activity under unusual conditions can indicate hostile activity. For example, what is normal activity during business hours can indicate hostile activity if it occurs during off hours.\n\nDepending on mission needs and conditions, account usage restrictions based on conditions and circumstances may be critical to limit access to resources and data to comply with operational or mission access control requirements. Thus, the application must be configured to enforce the specific conditions or circumstances under which application accounts can be used (e.g., by restricting usage to certain days of the week, time of day, or specific durations of time).",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Determine if the container platform is configured to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts. \n\nIf the container platform does not enforce organization-defined circumstances and/or usage conditions for organization-defined accounts, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,{"$f":"VLOOKUP(\"n0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-002130","SRG-APP-000319-CTR-000745","","The container platform must automatically audit account-enabling actions.","Rancher MCM must automatically audit account-enabling actions.","Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Automatically auditing account enabling actions provides logging that can be used for forensic purposes.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Determine if the container platform is configured to automatically audit account-enabling actions. \n\nIf the container platform is not configured to automatically audit account-enabling actions, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to automatically audit account-enabling actions.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,{"$f":"VLOOKUP(\"n0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-2 (4)","CCI-002132","SRG-APP-000320-CTR-000750","","The container platform must notify system administrator and ISSO of account enabling actions.","","Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Sending notification of account enabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nIn order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals so they can investigate the event.\n\nTo address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",{"$f":"VLOOKUP(\"D0005\", Sheet1!A:B,2,0)","v":"D0005 - Application and Audit log aggregation\n\nRancher MCM provides audit record generation capabilities when enabled. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken. Events include:\n- Timestamps of API events\n- Full text recording of where/who/what/when\n- Recording of priveledged functions\n- Source of Event\n- Result of action, success or rejection\n- User account creation and modification\n\nRancher MCM Audit Logging is limited to those which happen directly inside the Rancher MCM API. Additional logging configuration is required to ensure all events are captured throughout the clusters. \n\nOnce all logging policies are in place cluster-level logging is required for additional security controls. Implementing a cluster-level logging solution provides mechanisms to store, aggregate, analyze, and query workload and audit logs produced by the cluster and applications.\n\nThere are a number of common architectures for cluster-level logging including:\n\n- Run an agent on every node that collects from the host and sends logs to a central location.\n- Run a side-car in every container that the application sends logs to which is configured to send logs to a central location.\n- Configure applications in the containers to send logs directly to a central location.\n\nThe Rancher MCM Multi-Cluster Manager also provides many certified integrations that allow for deployment of logging solutions into RKE2.\n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails."},"Not Applicable","Determine if the container platform is configured to notify system administrator and ISSO of account enabling actions.\n\nIf the container platform is not configured to notify system administrator and ISSO of account enabling actions, this is a finding.","","Configure the container platform to notify system administrator and ISSO of account enabling actions.","","CAT II","",null,"Permissions to events and alerting are outside the Rancher MCM scope. "]
["AC-6 (10)","CCI-002235","SRG-APP-000340-CTR-000770","","The container platform must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.","Rancher MCM must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.","Controlling what users can perform privileged functions prevents unauthorized users from performing tasks that may expose data or degrade the container platform. When users are not segregated into privileged and non-privileged users, unauthorized individuals may perform tasks such as deploying containers, pulling images into the register, and modify keys in the keystore. These actions can introduce malicious containers and cause denial-of-service (DoS) attacks and undermine the container platform integrity. The enforcement may take place at the container platform and can be implemented within each container platform component (e.g. runtime, registry, and keystore).",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation to obtain the definition of the container platform functionality considered privileged in the context of the information system in question. \n\nReview the container platform security configuration and/or other means used to protect privileged functionality from unauthorized use. \n\nIf the configuration does not protect all of the actions defined as privileged, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to security to protect all privileged functionality. Assigning roles that limit what actions a particular user can perform are the most common means of meeting this requirement.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,{"$f":"VLOOKUP(\"n0002\", Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"},{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-6 (8)","CCI-002233","SRG-APP-000342-CTR-000775","","Container images instantiated by the container platform must execute using least privileges.","","Containers running within the container platform must execute as non-privileged. When a container can execute as a privileged container, the privileged container is also a privileged user within the hosting system, and the hosting system becomes a major security risk. It is important for the container platform runtime to validate the container user and disallow instantiation if the container is trying to execute with more privileges than required, as a privileged user, or is trying to perform a privilege escalation.\n\nWhen privileged access is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged execution.\n\nExamples of privileged users are root, admin, and default service accounts for the container platform.",null,"Not Applicable","Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to execute with more privileges than required or with privileged permissions. \n\nIf the container platform does not block containers requesting privileged permissions, privilege escalation, or allows containers to have more privileges than required, this is a finding.","","Configure the container platform to block instantiation with no more privileges than necessary.","","CAT II","",null,{"$f":"VLOOKUP(\"N0006\", Sheet1!M:N,2,0)","v":"N0006 -\nRancher can assist in setting up the interface between kubernetes/RKE2 clusters and log aggregation systems like elasticsearch and splunk, but this capability is similar to the authentication/authz systems where Rancher doesn't actually serve the functionality itself but makes it easy to set up the interface.\n\n\nlook at https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/apps/charts and you can see the options for \"Rancher approved integrations\" (Blue). As an example, I installed a monitoring stack. If you go to https://rancher.disa-eval.tomatodamato.com/dashboard/c/local/monitoring you can see the various monitoring tools already set up\n\nSee D0007 and M0007 in \nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AC-6 (9)","CCI-002234","SRG-APP-000343-CTR-000780","","The container platform must audit the execution of privileged functions.","Rancher MCM must audit the execution of privileged functions.","Privileged functions within the container platform can be component specific or can envelope the entire container platform. Because of the nature of the commands, it is important to understand what command was executed for either investigation of an incident or for debugging/error correction; therefore, privileged function execution must be audited.",{"$f":"VLOOKUP(\"D0004\", Sheet1!A:B,2,0)","v":"D0004 - Audit logs should be enabled\nRancher MCM provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit logging at the platform level also needs to be enabled. This will need to be done through the Kubernetes engine and is not always configurable through the Rancher MCM application.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nCluster administrators with authorized access can view logs produced by the Rancher MCM server. Audit and normal application logs generated by Rancher MCM can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nTo meet the requirements of this control an administrator with access to the local cluster configuration must add the 'AUDIT_LOG' environment variable with a level of at least  2 in the Rancher MCM deployment configuration. This setting will persist between restarts of the application."},"Applicable - Configurable","Review container platform documentation and log configuration to verify the application server logs privileged activity. \n\nIf the container platform is not configured to log privileged activity, this is a finding.",{"$f":"VLOOKUP(\"c0004\", Sheet1!C:D,2,0)","v":"C0004 - \nEnsure audit logging is enabled\nEnsure environment variables enabling audit logging are present.\n\nDropdown\nGlobal Settings->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nOpen the config panel 'Environment Variables'\n\nAnything except a list item 'AUDIT_LEVEL' with a value 2, or 3, this is a finding. \n\n"},"Configure the container platform to log privileged activity.",{"$f":"VLOOKUP(\"f0004\", Sheet1!E:F,2,0)","v":"F0004 - enable audit logging\nEnable Audit Logging by passing environment variables to the Rancher MCM server container.\n\nDropdown\nGlobal ->  local ->  System\n\nUnder 'Namespace: cattle-system' select 'rancher'\n\nPress the config button at the top right (three dots) and select 'Edit'\n\nOpen the 'Environment Variables' panel\n\nClick 'Add Variable'\n\nEnter 'AUDIT_LEVEL = 3 or 2'\n\nClick 'Save' at the bottom of the page\n\n"},"CAT II","",null,{"$f":"VLOOKUP(\"n0004\", Sheet1!M:N,2,0)","v":"Rancher MCM has the ability to administer Kubernetes. When these actions are done with auditing enabled on the Rancher MCM application then the event is audited. If a user circumvents Rancher MCM and performs operations on the Kubernetes platform directly through the api-server this event would not be audited by Rancher MCM alone. You would need to add audit logging policies to RKE2/Kubernetes in addition to the Rancher MCM audit logging to be sure everything is audited.\n\nD0002 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0004 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Is this saying all things around the platform should be STIGed? So automatic inherited?"]
["AC-7 b","CCI-002238","SRG-APP-000345-CTR-000785","","The container platform must automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.","","By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Determine if the container platform is configured to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. \n\nIf the container platform is not configured to lock the account, this is a finding.",{"$f":"VLOOKUP(\"c0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.",{"$f":"VLOOKUP(\"f0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["AU-4","CCI-001849","SRG-APP-000357-CTR-000800","","The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.","Rancher MCM must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.","In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity.\n\nThe task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements. \n\nIf audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,"There are lots of tools that are certified integrations, like RBAC Authn/Authz, Monitoring, Logging, Service Mesh. Rancher can do it all. In some cases super easy, like point and click. There are runtime scanners that can also be installed but it is not part of the Core Rancher deployment like all the other things mentioned. Not sure how to approach these kinds of things."]
["AU-4 (1)","CCI-001851","SRG-APP-000358-CTR-000805","","Audit records must be stored at a secondary location.","Audit records must be stored at a secondary location.","Auditable events are used in the investigation of incidents and must be protected from being deleted or altered. Often, events that took place in the past must be viewed to understand the entire incident. For the purposes of audit event protection and recall, audit events are often off-loaded to an external storage location. The container platform must provide a mechanism to assist in the off-loading of the audit data or at a minimum, must not hinder an external process used for audit event off-loading.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Verify the log records are being off-loaded to a separate system or transferred from the container platform storage location to a storage location other than the container platform itself. \n\nThe information system may demonstrate this capability using a log management application, system configuration, or other means. \n\nIf logs are not being off-loaded, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to off-load the logs to a remote log or management server.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,"This relates to the conversation we had about how incomming web app traffic to rancher goes through the ingress controller. This ingress controller needs to be configured to use strong TLS settings. Technically Rancher can configure this through the UI.\n\nSee the mitigation in the RKE2 STIG:\n\nM0001\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l","M0001 - secure kubernetes ingress\nThis requirement can be mitigated by setting Kubernetes object configuration and configuring the ingress controller used by your organization to ensure traffic entering the internal cluster network is terminated using DoD-approved certificates and use NSA-approved encryption ciphers \n\nExample Configuration for making an Nginx ingress controller reencrypt external traffic for internal use.\nExample command to alter the ingress configuration:\n'kubectl edit ingress rancher'\nExample annotations to ensure traffic from the ingress to the pod is encrypted\n'nginx.ingress.kubernetes.io/backend-protocol: ''HTTPS'''\nor\n'nginx.ingress.kubernetes.io/ssl-passthrough'\n\nExample configuration to limit TLS ciphers, and enforce TLS versions in an Nginx ingress controller \n'''\nkind: ConfigMap\napiVersion: v1\nmetadata:\n  name: nginx-config\ndata:\n  ssl-ciphers: ''ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA''\n  ssl-protocols: ''TLSv1 TLSv1.1 TLSv1.2 TLSv1.3''\n'''\n\nMost ingress controllers allow for supplying certificates for terminating external traffic coming into the internal cluster network. These certificates should be DoD-approved and the controller should be configured to only use NSA-approved encryption ciphers.\n\nExample Nginx settings for mitigating DDOS attacks. Defined here: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#rate-limiting\nnginx.ingress.kubernetes.io/limit-connections: number of concurrent connections allowed from a single IP address. A 503 error is returned when exceeding this limit.\nnginx.ingress.kubernetes.io/limit-rps: number of requests accepted from a given IP each second. The burst limit is set to this limit multiplied by the burst multiplier, the default multiplier is 5. When clients exceed this limit, limit-req-status-code default: 503 is returned.\nnginx.ingress.kubernetes.io/limit-rpm: number of requests accepted from a given IP each minute. The burst limit is set to this limit multiplied by the burst multiplier, the default multiplier is 5. When clients exceed this limit, limit-req-status-code default: 503 is returned.\nnginx.ingress.kubernetes.io/limit-burst-multiplier: multiplier of the limit rate for burst size. The default burst multiplier is 5, this annotation override the default multiplier. When clients exceed this limit, limit-req-status-code default: 503 is returned.\nnginx.ingress.kubernetes.io/limit-rate-after: initial number of kilobytes after which the further transmission of a response to a given connection will be rate limited. This feature must be used with proxy-buffering enabled.\nnginx.ingress.kubernetes.io/limit-rate: number of kilobytes per second allowed to send to a given connection. The zero value disables rate limiting. This feature must be used with proxy-buffering enabled.\nnginx.ingress.kubernetes.io/limit-whitelist: client IP source ranges to be excluded from rate-limiting. The value is a comma separated list of CIDRs.\n\n---\n\nExample command to alter the ingress configuration:\n'kubectl edit ingress rancher'\n> Note: Ensure ingress outbound port is going to service port 443\n\nExample command to alter the service configuration:\n'kubectl edit svc rancher'\n> Note: Ensure pod port is going to pod port 443, and incomming port is 443\n\nExample command to alter the deployment configuration:\n'kubectl edit deploy rancher'\n> Note: Ensure container port is 443\n\n---\n\nThe following environment variables are available for supplying to the Rancher server to limit the TLS encryption version and ciphers used internally.\n\nCATTLE_TLS_MIN_VERSION\t1.2\nCATTLE_TLS_CIPHERS\n\nAllowed TLS cipher suites:\nTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,\nTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,\nTLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,\nTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,\nTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,\nTLS_ECDHE_RSA_WITH_CHACHA20_POLY1305\n\n---\n\nAdditional tools, such as Istio and LinkerD, are available to provide mutual authentication and additonal security features."]
["AU-5 (1)","CCI-001855","SRG-APP-000359-CTR-000810","","The container platform must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.","Rancher MCM must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.","If security personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity. \n\nIf the container platform is not configured to provide an immediate real-time alert, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to provide an immediate real-time alert to the SA and ISSO when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-5 (2)","CCI-001858","SRG-APP-000360-CTR-000815","","The container platform must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.","Rancher MCM must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.","It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if it is configured to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts. \n\nIf the container platform is not configured to provide an immediate real-time alert, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-8 b","CCI-001890","SRG-APP-000374-CTR-000865","","All audit records must use UTC or GMT time stamps.","All audit records must use UTC or GMT time stamps.","The container platform and its components must generate audit records using either Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) time stamps or local time that offset from UTC. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform.\n\nTime stamps generated by the container platform and its components must include date and time.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform documentation and configuration files to determine if time stamps for log records can be mapped to UTC or GMT or local time that offsets from UTC. \n\nIf the time stamp cannot be mapped to UTC or GMT, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use UTC or GMT or local time that offset from UTC based time stamps for log records.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["AU-8 b","CCI-001889","SRG-APP-000375-CTR-000870","","The container platform must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.","Rancher MCM must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.","To properly investigate an event, it is important to have enough granularity within the time stamps to determine the chronological order of the audited events. Without this granularity, events may be interpreted out of proper sequence, thus hobbling the investigation or causing the investigation to come to inaccurate conclusions.\n\nTime stamps generated by the container platform include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform documentation and configuration files to determine if time stamps for log records meet a granularity of one second. \n\nIf the time stamp cannot generate to a one-second granularity, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to use time stamps for log records that can meet a granularity of one second.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-11 (2)","CCI-001812","SRG-APP-000378-CTR-000880","","The container platform must prohibit the installation of patches and updates without explicit privileged status.","Rancher MCM must prohibit the installation of patches and updates without explicit privileged status.","Controlling access to those users and roles responsible for patching and updating the container platform reduces the risk of untested or potentially malicious software from being installed within the platform. This access may be separate from the access required to install container images into the registry and those access requirements required to instantiate an image into a service. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform configuration to determine if patches and updates can only be installed through accounts with privileged status. \n\nAttempt to install a patch or upgrade using a non-privileged user account. \n\nIf patches or updates can be installed using a non-privileged account or the container platform is not configured to stop the installation using a non-privileged account, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to only allow patch installation and upgrades using privileged accounts.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-11 (2)","CCI-001812","SRG-APP-000378-CTR-000885","","The container platform runtime must prohibit the instantiation of container images without explicit privileged status.","Rancher MCM runtime must prohibit the instantiation of container images without explicit privileged status.","Controlling access to those users and roles responsible for container image instantiation reduces the risk of untested or potentially malicious containers from being executed within the platform and on the hosting system. This access may be separate from the access required to install container images into the registry and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review the container platform runtime configuration to determine if only accounts given specific container instantiation privileges can execute the container image instantiation process. \n\nAttempt to instantiate a container image using an account that does not have the proper privileges to execute the process. \n\nIf container images can be instantiated using an account without the proper privileges, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "}," Configure the container platform runtime to prohibit the instantiation of container images without explicit container image instantiation privileges given to users.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT I","",null,null,{"$f":"VLOOKUP(\"N0002\",Sheet1!M:N,2,0)","v":"N0002- RBAC\nLittle bit of a grey area.\n\nRancher allows/simplifies integration of kubernetes and authn/authz but it is not itself supposed to be used as an IAM service. Once configured Rancher helps with assigning RBAC rules to users. Kubernetes also supports RBAC and usage credentials can be created directly in kubernetes, even using Rancher (command line feature for example), to  create credentials not tracked by Rancher. \n\nWhen first set up there are only administrators. If additional users are added you will need to configure their RBAC. By default a user is a \"basic user\" who has fairly limited access to the global and cluster levels.\n\nD0003 in\n\nRancher MCM DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EcRpJYUk2-lCuaYC-c9f3z0BucVB15cKb0DkJG5YPcBwpA?e=zR1k8l\n\nD0003 in\n\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["CM-11 (2)","CCI-001812","SRG-APP-000378-CTR-000890","","The container platform registry must prohibit installation or modification of container images without explicit privileged status.","Rancher MCM registry must prohibit installation or modification of container images without explicit privileged status.","Controlling access to those users and roles that perform container platform registry functions reduces the risk of untested or potentially malicious containers from being introduced into the platform. This access may be separate from the access required to instantiate container images into services and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review container platform registry security settings with respect to non-administrative users' ability to create, alter, or replace container images. \n\nIf any such permissions exist and are not documented and approved, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Document and obtain approval for any non-administrative users who require the ability to create, alter, or replace container images within the container platform registry. Implement the approved permissions. Revoke any unapproved permissions.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"Rancher MCM is only accessible through the web api or web GUI. I imagine that means this is N/A"]
["CM-5 (1)","CCI-001813","SRG-APP-000380-CTR-000900","","The container platform must enforce access restrictions for container platform configuration changes.","Rancher MCM must enforce access restrictions for container platform configuration changes.","Configuration changes cause the container platform to change the way it operates. These changes can be used to improve the system with added features or performance, but these configuration changes can also be used to introduce malicious features and degrade performance. To control the configuration changes made to the container platform, it is important that only authorized users are allowed, through container platform enforcement, to make configuration changes.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation and configuration settings to determine if the container platform enforces access restrictions associated with changes to container platform components configuration. \n\nIf the container platform does not enforce such access restrictions, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to enforce access restrictions associated with changes to the container platform components configuration.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["CM-5 (1)","CCI-001814","SRG-APP-000381-CTR-000905","","The container platform must enforce access restrictions and support auditing of the enforcement actions.","Rancher MCM must enforce access restrictions and support auditing of the enforcement actions.","Auditing the enforcement of access restrictions against changes to the container platform helps identify attacks and provides forensic data for investigation for after-the-fact actions. Attempts to change configurations, components, or data maintained by a component (e.g., images in the registry, running containers in the runtime, or keys in the keystore) must be audited. \n\nEnforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review container platform documentation and logs to determine if enforcement actions used to restrict access associated with changes to the container platform are logged. \n\nIf these actions are not logged, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform to log the enforcement actions used to restrict access associated with changes.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II",""]
["CM-7 (1) (b)","CCI-001762","SRG-APP-000383-CTR-000910","","All non-essential, unnecessary, and unsecure DoD ports, protocols, and services must be disabled in the container platform.","","To properly offer services to the user and to orchestrate containers, the container platform may offer services that use ports and protocols that best fit those services. The container platform, when offering the services, must only offer the services on ports and protocols authorized by the DoD.\n\nTo validate that the services are using only the approved ports and protocols, the organization must perform a periodic scan/review of the container platform and disable functions, ports, protocols, and services deemed to be unneeded or non-secure.","","Applicable - Inherently Meets","Review the container platform configuration to determine if services or capabilities presently on the information system are required for operational or mission needs. \n\nIf additional services or capabilities are present on the system, this is a finding.","","Configure the container platform to only utilize secure ports and protocols required for operation that have been accepted for use as per the Ports, Protocols, and Services Category Assignments List (CAL) from DISA (PPSM).","","CAT II","",null,null,"I need to review Rancher MCM and see what FIPs features will be in 2.6"]
["CM-7 (2)","CCI-001764","SRG-APP-000384-CTR-000915","","The container platform must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.","Rancher MCM must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.","The container platform may offer components such as DNS services, firewall services, router services, or web services that are not required by every organization to meet their needs. Container platform components may also add capabilities that run counter to the mission or that provide users with functionality that exceeds mission requirements. To meet the requirements of an organization, the container platform must have a method to remove or disable components not required to meet the organization's mission.",{"$f":"VLOOKUP(\"D0002\", Sheet1!A:B,2,0)","v":"D0002 - RBAC Integration and Authn/Authz\nRancher MCM has the capability of integrating with external centralized authentication. The authentication mechanism needs to be initially enabled and configured. The proxy authenticates users and forwards their requests to Kubernetes clusters using a service account. \nThe Rancher MCM authentication proxy integrates with the following external authentication services:\nAUTH SERVICE - AVAILABLE AS OF\nMicrosoft Active Directory v2.0.0\nGitHub v2.0.0\nMicrosoft Azure AD v2.0.3\nFreeIPA v2.0.5\nOpenLDAP v2.0.5\nMicrosoft AD FS v2.0.7\nPingIdentity v2.0.7\nKeycloak v2.1.0\nOkta v2.2.0\nGoogle OAuth v2.3.0\nShibboleth v2.4.0\n\nCentralized authentication services provide additional functionality fullfilling security requirements:\n- multi-factor authentication which would be compatible with Rancher MCM. \n- disabling users after a period of time.\n- storage and transmission of secure information is encrypted.\n- secure authentication protocols such as LDAP over TLS, or LDAPS using FIPS 140-2 approved encryption modules\n- PKI based authentication\n"},"Applicable - Configurable","Review documentation and configuration setting to determine if policies, rules, or restrictions exist regarding usage of container platform components. \n\nIf no such no restrictions are in place, this is not a finding. \n\nIdentify any components the organization requires to be disabled or removed and configure the container platform according to that policy. \n\nIf the container platform components are not disabled or removed according to the organization's policy, this is a finding.",{"$f":"VLOOKUP(\"C0002\", Sheet1!C:D,2,0)","v":"C0002 - RBAC Integration and Authn/Authz\nView and modify authentication settings through the Rancher MCM UI.\n\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nThis screen shows the authentication that is configured. \n\nIf no authentication is configured, this is a finding. "},"Configure the container platform so that any platform components that are not required in order to meet the organization's mission are disabled or removed. Document the components that must be disabled or removed for reference.",{"$f":"VLOOKUP(\"F0002\", Sheet1!E:F,2,0)","v":"F0002 - RBAC Integration and Authn/Authz\nFrom the main 'Global' view. Select from the dropdown\nSecurity -> Authentication\n\nFrom this screen the authentication mechanism can be selected and configured. Consult with the SIEM administrator to obtain the correct configuration required for the organization. Additional configuration may be required for the authentication service itself."},"CAT II","",null,null,"I need to review Rancher MCM and see what FIPs features will be in 2.6"]
["CM-7 (5) (b)","CCI-001774","SRG-APP-000386-CTR-000920","","The container platform registry must employ a deny-all, permit-by-exception (whitelist) policy to allow only authorized container images in the container platform.","","Controlling the sources where container images can be pulled from allows the organization to define what software can be run within the container platform. Allowing any container image to be introduced and instantiated within the container platform may introduce malicious code and vulnerabilities to the platform and the hosting system. \n\nThe container platform registry must deny all container images except for those signed by organizational-approved sources.","","Not Applicable","Review documentation and configuration settings to identify if the container platform whitelisting specifies which container platform components are allowed to execute.\n\nCheck for the existence of policy settings or policy files that can be configured to restrict container platform component execution. Demonstrate how the program execution is restricted. Look for a deny-all, permit-by-exception policy of restriction.\n\nSome methods for restricting execution include but are not limited to the use of custom capabilities built into the application or Software Restriction Policies, Application Security Manager, or Role-Based Access Controls (RBAC).\n\nIf container platform whitelisting is not utilized or does not follow a deny-all, permit-by-exception (whitelist) policy, this is a finding.","","Configure the container platform to utilize a deny-all, permit-by-exception policy when allowing the execution of authorized software.","","CAT II","",null,{"$f":"VLOOKUP(\"N0013\",Sheet1!M:N,2,0)","v":"RKE2 does node auth with tokens. \nSee\nD0013 in\nRKE2 DISA STIG\nhttps://rancherfederalcom-my.sharepoint.com/:x:/g/personal/mike_damato_rancherfederal_com/EVGs001r2jBIpFvRhAQvUwQBLfirqi4G5WxRE5-2xlnHHA?e=jbF22c"}]
["IA-11","CCI-002038","SRG-APP-000389-CTR-000925","","The container platform must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.","","Controlling user access is paramount in securing the container platform. During a user's access to the container platform, events may occur that change the user's access and which require reauthentication. For instance, if the capability to change security roles or escalate privileges is implemented, it is critical the user reauthenticate.\n\nIn addition to the reauthentication requirements associated with change in security roles or privilege escalation, organizations may require reauthentication of individuals in other situations, including (but not limited to) the following circumstances:\n\n(i) When authenticators change; \n(ii) When roles change; \n(iii) When security categories of information systems change; \n(iv) When the execution of privileged functions occurs; \n(v) After a fixed period of time; or\n(vi) Periodically.\n\nWithin the DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.","","Not Applicable","Review documentation and configuration to determine if the container platform requires a user to reauthenticate when organization-defined circumstances or situations are met. \n\nIf the container platform does not meet this requirement, this is a finding.",null,"Configure the container platform to require a user to reauthenticate when organization-defined circumstances or situations are met.","","CAT II","",null,"Authentication of users is handled by organization-defined external resources, which would handle reauthentication. Rancher MCM then uses the authenticated user to determine authorization of services."]
["IA-11","CCI-002039","SRG-APP-000390-CTR-000930","","The container platform must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication.","","The container platform may require external devices be used to fully orchestrate the services needed for users. Examples would be storage or external servers. Without reauthentication, unidentified or unknown devices may be introduced; thereby facilitating malicious activity.\n\nThe container platform must be capable of allowing the organization to set requirements associated with device reauthentication. Examples are:\n\nOrganizations may require reauthentication of devices, including (but not limited to), the following other situations:\n\n(i) When authenticators change; \n(ii) When roles change; \n(iii) When security categories of information systems change;\n(iv) After a fixed period of time; or \n(v) Periodically.\n\nFor distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions.","","Not Applicable","Review documentation and configuration to determine if the container platform requires devices to reauthenticate when organization-defined circumstances or situations require reauthentication. \n\nIf the container platform does not require a device to reauthenticate, this is a finding.","","Configure the container platform to require devices to reauthenticate when organization-defined circumstances or situations require reauthentication.","","CAT II","",null,"Authentication of users is handled by organization-defined external resources, which would handle reauthentication. Rancher MCM then uses the authenticated user to determine authorization of services."]
["IA-2 (12)","CCI-001953","SRG-APP-000391-CTR-000935","","The container platform must be configured to use multi-factor authentication for user authentication.","","Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. To standardize and reduce the risks of unauthorized access, the use of multifactor token-based credentials is the preferred method.\n\nDoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.","","Not Applicable","Review documentation and configuration to ensure the container platform is configured to use an approved DoD multifactor token (CAC) when accessing platform via user interfaces. \n\nIf multifactor authentication is not configured, this is a finding.","","Configure the container platform to accept standard DoD multifactor token-based credentials when users interface with the platform.","","CAT II","",null,"Authentication of users is handled by organization-defined external resources, which would handle reauthentication. Rancher MCM then uses the authenticated user to determine authorization of services."]
["IA-5 (1) (f)","CCI-002041","SRG-APP-000397-CTR-000955","","The container platform must allow the use of a temporary password for system logons with an immediate change to a permanent password.","","Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial login.\n\nTemporary passwords are typically used to allow access to applications when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts, which allow the users to log in, yet forces them to change the password once they have successfully authenticated.","","Not Applicable","Review the container platform configuration to determine if the platform is configured to allow the use of a temporary password for system logons with an immediate change to a permanent password. \n\nIf the container platform is not configured to allow temporary passwords with immediate change to a permanent password, this is a finding.","","Configure the container platform to allow the use of a temporary password for system logons with an immediate change to a permanent password.","","CAT II","",null,"Endpoint management falls outside the Rancher MCM scope."]
["IA-5 (13)","CCI-002007","SRG-APP-000400-CTR-000960","","The container platform must prohibit the use of cached authenticators after an organization-defined time period.","","If cached authentication information is out of date, the validity of the authentication information may be questionable.","","Not Applicable","Review the container platform configuration to determine if the platform is configured to prohibit the use of cached authenticators after an organization-defined time period. \n\nIf the container platform is not configured to prohibit the use of cached authenticators after an organization-defined time period, this is a finding.","","Configure the container platform to prohibit the use of cached authenticators after an organization-defined time period.","","CAT II","",null,"Network management provided outside Rancher MCM scope."]
["IA-5 (2) (d)","CCI-001991","SRG-APP-000401-CTR-000965","","The container platform, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.","","The potential of allowing access to users who are no longer authorized  (have revoked certificates) increases unless a local cache of revocation data is configured.","","Not Applicable","Review the container platform configuration.\n\n If the container platform is not implemented to use a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network, this is a finding.","","Configure the container platform to implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.","","CAT II","",null,"PKI-based authentication falls outside the Rancher MCM scope."]
["IA-8 (1)","CCI-002009","SRG-APP-000402-CTR-000970","","The container platform must accept Personal Identity Verification (PIV) credentials from other federal agencies.","","Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. It is essential to accept PIV credentials from other federal agencies and eliminate the possibility of access being denied to authorized users.\n\nPIV credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials.","","Not Applicable","Review the documentation and configuration to determine if the container platform accepts PIV credentials from other federal agencies. \n\nIf the container platform does not accept other federal agency PIV credentials, this is a finding.","","Configure the container platform to accept PIV credentials from other federal agencies.","","CAT II","",null,"Authentication of users is handled by organization defined external resources. Racher MCM then uses the authenticated user to determine authorization of services."]
["MA-4 (1) (a)","CCI-002884","SRG-APP-000409-CTR-000990","","The container platform must audit non-local maintenance and diagnostic sessions' organization-defined audit events associated with non-local maintenance.","","To fully investigate an attack, it is important to understand the event and those events taking place during the same time period. Often, non-local administrative access and diagnostic sessions are not logged. These events are seen as only administrative functions and not worthy of being audited, but these events are important in any investigation and are a major tool for assessing and investigating attacks.","","Not Applicable","Review the container platform to verify if the platform is auditing non-local maintenance and diagnostic sessions' organization-defined audit events. \n\nIf the container platform is not auditing non-local maintenance and diagnostic sessions' organization-defined audit events, this is a finding.","","Configure the container platform to audit non-local maintenance and diagnostic sessions' organization-defined audit events.","","CAT II","",null,"Any requirements for tools used for nonlocal maintenance are outside the scope of the Racher MCM. "]
["MA-4 (6)","CCI-002890","SRG-APP-000411-CTR-000995","","Container platform applications and Application Program Interfaces (API) used for nonlocal maintenance sessions must use FIPS-validated keyed-hash message authentication code (HMAC) to protect the integrity of nonlocal maintenance and diagnostic communications.","","Unapproved mechanisms that are used for authentication to the cryptographic module are not verified, and therefore cannot be relied on to provide confidentiality or integrity, and DoD data may be compromised.\n\nNonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network.\n\nCurrently, HMAC is the only FIPS-approved algorithm for generating and verifying message/data authentication codes in accordance with FIPS 198-1. Products that are FIPS 140-2 validated will have an HMAC that meets specification; however, the option must be configured for use as the only message authentication code used for authentication to cryptographic modules.\n\nSeparate requirements for configuring applications and protocols used by each product (e.g., SNMPv3, SSHv2, NTP, and other protocols and applications that require server/client authentication) are required to implement this requirement. The SSHv2 protocol suite must be mandated in the product because it includes layer 7 protocols such as SCP and SFTP that can be used for secure file transfers.","","Not Applicable","Validate that container platform applications and APIs used for nonlocal maintenance sessions are using FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications. \n\nIf the sessions are not using FIPS-validated HMAC, this is a finding.","","Configure the container platform applications and APIs used for nonlocal maintenance sessions to use FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications.","","CAT II","",null,"Any requirements for tools used for nonlocal maintenance are outside the Rancher MCM scope."]
["MA-4 (6)","CCI-003123","SRG-APP-000412-CTR-001000","","The container platform must configure web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.","","Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.\n\nNonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network.","","Not Applicable","Validate the container platform web management tools and Application Program Interfaces (API) are configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions. \n\nIf the web management tools and API are not configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms, this is a finding.","","Configure the container platform web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.","","CAT II","",null,"Web maintenance tool falls outside the Rancher MCM scope."]
["RA-5 (5)","CCI-001067","SRG-APP-000414-CTR-001010","","Vulnerability scanning applications must implement privileged access authorization to all container platform components, containers, and container images for selected organization-defined vulnerability scanning activities.","","In certain situations, the nature of the vulnerability scanning may be more intrusive, or the container platform component that is the subject of the scanning may contain highly sensitive information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and protects the sensitive nature of such scanning.\n\nThe vulnerability scanning application must utilize privileged access authorization for the scanning account.","","Not Applicable","Validate that scanning applications have privileged access to container platform components, containers, and container images to properly perform vulnerability scans. \n\nIf privileged access is not given to the scanning application, this is a finding.","","Configure the vulnerability scanning application to have privileged access to the container platform components, containers, and container images.","","CAT II","",null,"The capabilities of a vulnerability scanning tool is outside theRancher MCM scope."]
["SC-13","CCI-002450","SRG-APP-000416-CTR-001015","","The container platform must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.","","Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data and images. The container platform must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.","","","Review documentation to verify that the container platform is using NSA-approved cryptography to protect classified data and applications. \n\nIf the container platform is not using NSA-approved cryptography for classified data and applications, this is a finding.","","Configure the container platform to utilize NSA-approved cryptography to protect classified information.","","CAT II",""]
["SC-28 (1)","CCI-002476","SRG-APP-000429-CTR-001060","","The container platform keystore must implement encryption to prevent unauthorized disclosure of information at rest within the container platform.","","Container platform keystore is used for container deployments for persistent storage of all its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any unauthorized disclosure. Selection of a cryptographic mechanism is based on the need to protect the confidentiality of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information.","","","Review container platform keystore documentation and configuration to verify encryption levels meet the information sensitivity level. \n\nIf the container platform keystore encryption configuration does not meet system requirements, this is a finding.","","Configure the container platform keystore encryption to maintain the confidentiality and integrity of information for applicable sensitivity level.","","CAT II",""]
["SC-39","CCI-002530","SRG-APP-000431-CTR-001065","","The container platform runtime must maintain separate execution domains for each container by assigning each container a separate address space.","","Container namespace access is limited upon runtime execution. Each container is a distinct process so that communication between containers is performed in a manner controlled through security policies that limits the communication so one container cannot modify another container. Different groups of containers with different security needs should be deployed in separate namespaces as a first level of isolation.\n\nNamespaces are a key boundary for network policies, orchestrator access control restrictions, and other important security controls. Separating workloads into namespaces can help contain attacks and limit the impact of mistakes or destructive actions by authorized users.","","Applicable - Inherently Meets","Review container platform runtime documentation and configuration is maintaining a separate execution domain for each executing process. Different groups of applications, and services with different security needs, should be deployed in separate namespaces as a first level of isolation. \n\nIf container platform runtime is not configured to execute processes in separate domains and namespaces, this is a finding. \n\nIf namespaces use defaults, this is a finding.","","Deploy a container platform runtime capable of maintaining a separate execution domain and namespace for each executing process. Create a namespace for each containers, defining them as logical groups.","","CAT II","",null,"Rancher MCM has the concept of namespaces to divide pods (applications) into their own domain. It is up to the SA to use these appropriately for the user services that are implemented."]
["SC-5","CCI-002385","SRG-APP-000435-CTR-001070","","The container platform must protect against or limit the effects of all types of denial-of-service (DoS) attacks by employing organization-defined security safeguards.","Rancher MCM API must not allow kubeconfig files and tokens to have infinite time-to-live.","DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.\n\nThis requirement addresses the configuration of the container platform to mitigate the impact of DoS attacks that have occurred. For each container platform component, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting runtime processes or restricting the number of sessions the container platform runtime open, limiting container resources to memory and CPU).\n\nProcesses are an important indicator of security-and operations-relevant container activity. Process names and their arguments provide important visibility into a container’s activity. If an image includes non-default aliases or renamed binaries, attackers will still attempt to use well-known names.\n\nThe same malicious or unwanted activity might affect multiple deployments across different applications or environments. Staff investigating a potential incident need to find those exposures quickly.","Rancher MCM allows users to generate kubeconfig files and API tokens using their account credentials and these tokens have the capability to never expire unless you invalidate them manually.\n\nIt is important for users to need to re-authenticate periodically in case of misplaced tokens or kubeconfig files on a valid account. This invalidation/TTL maximum can be set globally to ensure these tokens can not have infinite time-to-live. ","","Review documentation and configuration to determine if the container platform can protect against or limit the effects of all types of DoS attacks by employing defined security safeguards against resource depletion. Examples of resource limits are on memory, storage, and CPU. \n\nIf the container platform cannot be configured to protect against or limit the effects of all types of DoS, this is a finding.","","Configure the container platform to protect against or limit the effects of all types of DoS attacks by employing defined security safeguards. Safeguards such as resource limits on memory, storage, and CPU can be used.","","CAT II",""]
["SC-8","CCI-002418","SRG-APP-000439-CTR-001080","","The application must protect the confidentiality and integrity of transmitted information.","","Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. \n\nThis requirement applies only to those applications that either are distributed or can allow access to data non-locally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.\n\nCommunication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.","","Not Applicable","This requirement is NA for this technology.","","The requirement is NA. No fix is required.","","CAT II","",null,"Rancher MCM service account must utilize certificates for authentication."]
["SC-8 (2)","CCI-002420","SRG-APP-000441-CTR-001090","","The container platform must maintain the confidentiality and integrity of information during preparation for transmission.","","Information may be unintentionally or maliciously disclosed or modified during preparation for transmission within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When transmitting data, the container platform components need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.","","Not Applicable","Review the documentation and deployed configuration to determine if the container platform maintains the confidentiality and integrity of information during preparation before transmission. \n\nIf the confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during preparation before transmission, this is a finding.","","Configure the container platform to maintain the confidentiality and integrity of information using mechanisms such as TLS, TLS VPNs, or IPsec during preparation for transmission.","","CAT II","",null,"Rancher MCM service account must utilize certificates for authentication."]
["SC-8 (2)","CCI-002422","SRG-APP-000442-CTR-001095","","The container platform must maintain the confidentiality and integrity of information during reception.","","Information either can be unintentionally or maliciously disclosed or modified during reception for reception within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When receiving data, the container platform components need to leverage protection mechanisms, such as TLS, TLS VPNs, or IPsec.","","Applicable - Inherently Meets","Review documentation and configuration settings to determine if the container platform maintains the confidentiality and integrity of information during reception.\n\nIf confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during reception, this is a finding.","","Configure the container platform to maintain the confidentiality and integrity using mechanisms such as TLS, TLS VPNs, or IPsec during reception.","","CAT II","",null,"Security control STIG Check and Fix is addressed in the following security controls:\nAC-17(2)\nAC-3\nSC-23\nSC-8"]
["SI-10 (3)","CCI-002754","SRG-APP-000447-CTR-001100","","The container platform must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.","","Software or code parameters typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata.\n\nThis requirement guards against adverse or unintended system behavior caused by invalid inputs, where container platform components responses to the invalid input may be disruptive or cause the container image runtime to fail into an unsafe state.\n\nThe behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.","","Applicable - Inherently Meets","Review the configuration to determine if the container platform behaves in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. \n\nIf the container platform does not meet this requirement, this is a finding.","","Configure the container platform behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.","","CAT II","",null,"Input by the SA and authorized users is through the GUI or Command Line. Input is validated and gives an error for invalid inputs. Rancher MCM invalid inputs does not leave the system in an unpredictable state."]
["SI-16","CCI-002824","SRG-APP-000450-CTR-001105","","The container platform must implement organization-defined security safeguards to protect system CPU and memory from resource depletion and unauthorized code execution.","","The execution of images within the container platform runtime must implement organizational defined security safeguards to prevent distributed denial-of-service (DDOS) and other possible attacks against the container image at runtime.\n\nSecurity safeguards employed to protect memory and CPU include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be software-enforced. Other means of protection are to limit memory and CPU resources to a container.","","Not Applicable","Review the container platform configuration to determine if safeguards are in place to protect the system memory and CPU from resource depletion and unauthorized execution. \n\nIf safeguards are not in place, this is a finding.","","Configure the container platform to have safeguards in place to protect the system memory and CPU from resource depletion and unauthorized code execution.","","CAT II","",null,"Container runtime not in Rancher MCM scope; CPU and Memory limits covered in Container Hardening Guidelines."]
["SI-2 (6)","CCI-002617","SRG-APP-000454-CTR-001110","","The container platform must remove old components after updated versions have been installed.","Rancher MCM must remove old components after updated versions have been installed.","Previous versions of container platform components that are not removed from the container platform after updates have been installed may be exploited by adversaries by causing older components to execute which contain vulnerabilities. When these components are deleted, the likelihood of this happening is removed.","","","Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version. \n\nIf organization-defined images do not contain the latest approved vendor software image version, this is a finding. \n\nReview container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed. \n\nIf organization-defined images are not removed after updated versions have been installed, this is a finding. \n\nReview container platform runtime documentation and configuration to determine if organization-define images are executing latest image version from the container platform registry. \n\nIf container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.","","Configure the container platform registry to update organization-defined images with current approved vendor version and remove obsolete images after updated versions have been installed. Configure the container platform runtime to execute latest organization-defined images from the container platform registry.","","CAT II",""]
["SI-2 (6)","CCI-002617","SRG-APP-000454-CTR-001115","","The container platform registry must remove old container images after updating versions have been made available.","","Obsolete and stale images need to be removed from the registry to ensure the container platform maintains a secure posture. While the storing of these images does not directly pose a threat, they do increase the likelihood of these images being deployed. Removing stale or obsolete images and only keeping the most recent versions of those that are still in use removes any possibility of vulnerable images being deployed.","","","Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version. \n\nIf organization-defined images do not contain the latest approved vendor software image version, this is a finding. \n\nReview container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed. \n\nIf organization-defined images are not removed after updated versions have been installed, this is a finding. \n\nReview container platform runtime documentation and configuration to determine if organization-defined images are executing latest image version from the container registry. \n\nIf container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.","","Configure the container platform registry to update organization-defined images with current approved vendor version and remove obsolete images after updated versions have been installed. Configure the container platform runtime to execute latest organization-defined images from the container platform registry.","","CAT II",""]
["SI-2 c","CCI-002605","SRG-APP-000456-CTR-001125","","The container platform registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs. ","","Software supporting the container platform, images in the registry must stay up to date with the latest patches, service packs, and hot fixes. Not updating the container platform and container images will expose the organization to vulnerabilities.\n\nFlaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.\n\nOrganization-defined time periods for updating security-relevant container platform components may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw).\n\nThis requirement will apply to software patch management solutions that are used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.\n\nThe container platform components will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The container platform registry will ensure the images are current. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).","","","Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). \n\nIf the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.\n\nThe container platform registry should help the user understand where the code in the environment was deployed from, and must provide controls that prevent deployment from untrusted sources or registries.","","Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed.","","CAT II",""]
["SI-2 c","CCI-002605","SRG-APP-000456-CTR-001130","","The container platform runtime must have updates installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).","","The container platform runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly. A vulnerable runtime exposes all containers it supports, as well as the host itself, to potentially significant risk. Organizations should use tools to look for Common Vulnerabilities and Exposures (CVEs) vulnerabilities in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes.","","","Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.). \n\nIf the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.\n\nThe container platform registry should help the user understand where the code in the environment was deployed from and must provide controls that prevent deployment from untrusted sources or registries.","","Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed within the time period directed by the authoritative source.","","CAT II",""]
["SI-6 a","CCI-002696","SRG-APP-000472-CTR-001170","","The organization-defined role must verify correct operation of security functions in the container platform.","","Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform. The container platform components must identity and ensure the security functions are still operational and applicable to the organization.\n\nSecurity functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.\n\nNotifications provided by information systems include, for example, electronic alerts to system administrators.","","","Review container platform documentation and configuration verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM). \n\nIf verification of the correct operation of security functions is not performed, this is a finding.","","Configure the container platform configuration and installation settings to perform verification of the correct operation of security functions.","","CAT II",""]
["SI-6 b","CCI-002699","SRG-APP-000473-CTR-001175","","The container platform must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.","","Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform.\n\nSecurity functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.\n\nNotifications provided by information systems include, for example, electronic alerts to organization-defined role.","","","Review container platform documentation.\n\nVerify that the container platform is configured to perform verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM), upon product startup/restart, by a user with privileged access, and/or every 30 days.\n\nIf it is not, this is a finding.","","Configure the container platform to perform verification of the correct operation of security functions, which may include the connection validation, upon product startup/restart, or by a user with privileged access, and/or every 30 days.","","CAT II",""]
["SI-6 d","CCI-002702","SRG-APP-000474-CTR-001180","","The container platform must provide system notifications to the system administrator and operational staff when anomalies in the operation of the organization-defined security functions are discovered.","Mike - Please Verify The technology inherently meets this requirement.","If anomalies are not acted upon, security functions may fail to secure the container within the container platform runtime.\n\nSecurity functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.\n\nNotifications provided by information systems include, for example, electronic alerts to system administrators.","","Applicable - Inherently Meets","Review container platform runtime documentation and configuration settings. \n\nIf the container platform is not configured to notify organization-defined information system role when anomalies in the operation of security functions as defined by site security plan are discovered, this is a finding.","","Configure the container platform runtime to notify system administrator and operation staff when anomalies in the operation of the security functions as defined in site security plan are discovered.","","CAT II","",null,"The technology supports this requirement and cannot be configured to be out of compliance. "]
["AU-12 c","CCI-000172","SRG-APP-000492-CTR-001220","","The container platform must generate audit records when successful/unsuccessful attempts to access security objects occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access security objects occur.","The container platform and its components must generate audit records when successful and unsuccessful access security objects occur. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation access controls levels can access by unauthorized users unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security objects. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to access security objects occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000493-CTR-001225","","The container platform must generate audit records when successful/unsuccessful attempts to access security levels occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access security levels occur.","Unauthorized users could access the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can access security levels unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security levels. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to access security levels occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000494-CTR-001230","","The container platform must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access categories of information. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to access categories of information.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000495-CTR-001235","","The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify privileges occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to modify privileges.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000496-CTR-001240","","The container platform must generate audit records when successful/unsuccessful attempts to modify security objects occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify security objects occur.","The container platform and its components must generate audit records when modifying security objects. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can modify security objects unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security objects. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security objects.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000497-CTR-001245","","The container platform must generate audit records when successful/unsuccessful attempts to modify security levels occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify security levels occur.","Unauthorized users could modify the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can modify security levels unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security levels. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security levels.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000498-CTR-001250","","The container platform must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to modify categories of information. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts are made to modify categories of information.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000499-CTR-001255","","The container platform must generate audit records when successful/unsuccessful attempts to delete privileges occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete privileges occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to delete privileges. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts are made to delete privileges occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000500-CTR-001260","","The container platform must generate audit records when successful/unsuccessful attempts to delete security levels occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete security levels occur.","The container platform and its components must generate audit records when deleting security levels. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can delete security levels unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to delete security levels. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when successful/unsuccessful attempts to delete security levels.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000501-CTR-001265","","The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete security objects occur.","Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.\n\nWithout audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to delete security objects occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000502-CTR-001270","","The container platform must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.","Rancher MCM must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete categories of information occur. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records on successful/unsuccessful attempts to delete categories of information occur.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000503-CTR-001275","","The container platform must generate audit records when successful/unsuccessful logon attempts occur.","Rancher MCM must generate audit records when successful/unsuccessful logon attempts occur.","The container platform and its components must generate audit records when successful and unsuccessful logon attempts occur. The information system can determine if an account is compromised or is in the process of being compromised and can take actions to thwart the attack. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration for audit logon events. \n\nEnsure audit policy for successful and unsuccessful logon events are enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf logon attempts do not generate log records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform registry, keystore, and runtime to generate audit log for successful and unsuccessful logon for any all accounts and services. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000504-CTR-001280","","The container platform must generate audit record for privileged activities.","Rancher MCM must generate audit record for privileged activities.","The container platform components will generate audit records for privilege activities and container platform runtime, registry, and keystore must generate access audit records to detect possible malicious intent. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without these activities. Audit records can be generated from various components within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the documentation and configuration guides to determine if the container platform generates log records for privileged activities. \n\nIf log records are not generated for privileged activities, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate log records for privileged activities.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000505-CTR-001285","","The container platform audit records must record user access start and end times.","Rancher MCM audit records must record user access start and end times.","The container platform must generate audit records showing start and end times for users and services acting on behalf of a user accessing the registry and keystore. These components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration for audit user access start and end times. \n\nEnsure audit policy for user access start and end times are enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf user access start and end times do not generate log records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit log for user access start and end times for any all accounts and services. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000506-CTR-001290","","The container platform must generate audit records when concurrent logons from different workstations and systems occur.","Rancher MCM must generate audit records when concurrent logons from different workstations and systems occur.","The container platform and its components must generate audit records for concurrent logons from workstations perform remote maintenance, runtime instances, connectivity to the container registry, and keystore. All the components must use the same standard so the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration for audit logon events. \n\nEnsure audit policy for concurrent logons from different workstations and systems is enabled. \n\nVerify events are written to the log. \n\nValidate system documentation is current. \n\nIf concurrent logons from different workstations and systems do not generate log records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit log for concurrent logins from multiple workstations and systems. Revise all applicable system documentation.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000507-CTR-001295","","The container platform runtime must generate audit records when successful/unsuccessful attempts to access objects occur.","","Container platform runtime objects are defined as configuration files, code, etc. This provides the ability to configure resources and software parameters prior to image execution from the container platform registry. An unauthorized user with malicious intent could modify existing objects causing vulnerabilities or attacks. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without audit record generation.\n\nWithout audit record generation, unauthorized users can access objects unknowingly for malicious intent creating vulnerabilities within the container platform.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to verify that the runtime generates audit records on successful/unsuccessful access to objects. \n\nIf audit records are not generated by the runtime when objects are successfully/unsuccessfully accessed, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform runtime to generate audit records on successful/unsuccessful access to objects.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000508-CTR-001300","","Direct access to the container platform must generate audit records.","Direct access to Rancher MCM must generate audit records.","Direct access to the container platform and its components must generate audit records. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if direct access of the container platform generates audit records. \n\nIf audit records are not generated, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records when accessed directly.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000509-CTR-001305","","The container platform must generate audit records for all account creations, modifications, disabling, and termination events.","Rancher MCM must generate audit records for all account creations, modifications, disabling, and termination events.","Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAudit records can be generated from various components within the information system (e.g., module or policy filter).",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container platform configuration to determine if the container platform is configured to generate audit records for all account creations, modifications, disabling, and termination events. \n\nIf the container platform is not configured to generate the audit records, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container platform to generate audit records for all account creations, modifications, disabling, and termination events.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["AU-12 c","CCI-000172","SRG-APP-000510-CTR-001310","","The container runtime must generate audit records for all container execution, shutdown, restart events, and program initiations.","Rancher MCM runtime must generate audit records for all container execution, shutdown, restart events, and program initiations.","The container runtime must generate audit records that are specific to the security and mission needs of the organization. Without audit record, it would be difficult to establish, correlate, and investigate events relating to an incident.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review the container runtime configuration to validate audit record generation for container execution, shutdown, and restart events. \n\nIf the container runtime does not generate records for container execution, shutdown and restart events, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Configure the container runtime to generate audit records for container execution, shutdown, and restart events.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["SC-13","CCI-002450","SRG-APP-000514-CTR-001315","","The container platform must use a valid FIPS 140-2 approved cryptographic modules to generate hashes.","","The cryptographic module used must have at least one validated hash algorithm. This validated hash algorithm must be used to generate cryptographic hashes for all cryptographic security function within the container platform components being evaluated.\n\nFIPS 140-2 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.","","Not Applicable","Review the container platform configuration to validate that valid FIPS 140-2 approved cryptographic modules are being used to generate hashes. \n\nIf non-valid or unapproved FIPS 140-2 cryptographic modules are being used to generate hashes, this is a finding.","","Configure the container platform to use valid FIPS 140-2 approved cryptographic modules to generate hashes.","","CAT II","",null,"Racher MCM does not contain confidential data, such as PII, unless a user service deployed within Rancher MCM operates on this type of data. If a user service is deployed that operates on confidential data, the service would need to implement this control."]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-000790","","The container platform must provide the configuration for organization-identified individuals or roles to change the auditing to be performed on all components, based on all selectable event criteria within organization-defined time thresholds.","","Auditing requirements may change per organization or situation within and organization. With the container platform allowing an organization to customize the auditing, an organization can decide to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.\n\nModifying auditing within the container platform must be controlled to only those individuals or roles identified by the organization to modify auditable events.",{"$f":"VLOOKUP(\"D0006\", Sheet1!A:B,2,0)","v":"D0006 - Rancher logging capability and optional aggregation\nThe Rancher server automatically logs everything at the container level. These logs are stored on the system which are then optionally picked up by further log aggregation systems.\n\nCluster administrators with authorized access can view logs produced by the Rancher server as well as change logging settings to trigger a new deployment with the new settings. Audit and normal application logs generated by Rancher can be forwarded to a remote log aggregation system for use by authorized viewers as well. This system can in turn be configured for further log processing, monitoring, backup, and alerting. This aggregation also should include failover and buffering in the event that a logging subsystem fails. The logging mechanism of the individual server is independent and will kill the server process if this logging mechanism fails.\n\nRancher provides audit record generation capabilities. Audit logs capture what happened, when it happened, who initiated it, and what cluster it affected in order to ensure non-repudiation of actions taken.\n\nAudit log verbosity can be set to one of the following levels:\n0 - Disable audit log (default setting).\n1 - Log event metadata.\n2 - Log event metadata and request body.\n3 - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same auditID value. \n\nApplication logs can be set to one of the following levels:\ninfo = Logs informational messages. This is the default log level.\ndebug = Logs more detailed messages that can be used to debug.\ntrace = Logs very detailed messages on internal functions. This is very verbose and can contain sensitive information.\n\nLog metadata includes the following information (sample):\n\n{\n  'auditID': '30022177-9e2e-43d1-b0d0-06ef9d3db183',\n  'requestURI': '/v3/schemas',\n  'sourceIPs': ['::1'],\n  'user': {\n    'name': 'user-f4tt2',\n    'group': ['system:authenticated']\n  },\n  'verb': 'GET',\n  'stage': 'RequestReceived',\n  'stageTimestamp': '2018-07-20 10:22:43 +0800'\n  'requestBody': {\n    [redacted]\n  }\n}"},"Applicable - Configurable","Review documentation and configuration setting. \n\nIf the container platform does not provide the ability for users in authorized roles to reconfigure auditing at any time of the user's choosing, this is a finding. \n\nIf changes in audit configuration cannot take effect until after a certain time or date, or until some event, such as a server restart, has occurred, and if that time or event does not meet the requirements specified by the organization, this is a finding.",{"$f":"VLOOKUP(\"C0006\", Sheet1!C:D,2,0)","v":"C0006 - Ensure logging aggregation is enabled\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"Deploy a container platform that provides the ability for users in authorized roles to reconfigure auditing at any time. Deploy a container platform that allows audit configuration changes to take effect within the timeframe required by the organization and without involving actions or events that the organization rules unacceptable.",{"$f":"VLOOKUP(\"F0006\", Sheet1!E:F,2,0)","v":"F0006 - Enable log aggregation\nSelect the cluster in question from the top left dropdown menu\n\nFrom the top menu, under tools, select Logging \n\nThis screen should show the current configuration for log aggregation. Consult with the SIEM administrator to obtain the correct configuration required for the organization."},"CAT II",""]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-001325","","Container platform components must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.","Is there a Helm check/fix for this?","Container platform components are part of the overall container platform, offering services that enable the container platform to fully orchestrate user containers. These components may fall outside the scope of this document, but they still must be secured. Examples of such components are DNS, routers, and firewalls. These and any other services offered by the container platform must follow the appropriate STIG or SRG for the technology offered. If a STIG or SRG is not available for the technology, then best practices for the technology must be used. For example, the Cloud Native Computing Foundation (CNCF) is an open-source organization that is working on container platform best practices.","","","Review the container platform configuration to determine the services offered by the container platform and validate that any services that are offered are configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs. \n\nIf container platform services are not configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs, this is a finding.","","Configure container services in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.","","CAT II",""]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-001330","","The container platform must be able to store and instantiate industry standard container images.","","Monitoring the container images and containers during their lifecycle is important to guarantee the container platform is secure. To monitor the containers and images, security tools can be put in place. To fully utilize the security tools available, using images formatted in an industry standard format should be used. This allows the tools to fully understand the images and containers. One standard being worked on by industry leaders in the container space is the Open Container Initiative (OCI). This group is developing a standard container image format.","","","Review the container platform configuration and documentation to determine if the platform is configured to store and instantiate industry standard container images. \n\nIf the container platform cannot instantiate industry standard container images, this is a finding.","","Enable the container platform to store and instantiate industry standard container image formats.","","CAT II",""]
["CM-6 b","CCI-000366","SRG-APP-000516-CTR-001335","","The container platform must continuously scan components, containers, and images for vulnerabilities.","","Finding vulnerabilities quickly within the container platform and within containers deployed within the platform is important to keep the overall platform secure. When a vulnerability within a component or container is unknown or allowed to remain unpatched, other containers and customers within the platform become vulnerability. The vulnerability can lead to the loss of application data, organizational infrastructure data, and denial of service (DoS) to hosted applications.\n\nVulnerability scanning can be performed by the container platform or by external applications.","","","Review the container platform to validate continuous vulnerability scans of components, containers, and container images are being performed. \n\nIf continuous vulnerability scans are not being performed, this is a finding.","","Implement continuous vulnerability scans of container platform components, containers, and container images either by the container platform or from external vulnerability scanning applications.","","CAT II",""]
["AC-17 (2)","CCI-001453","SRG-APP-000560-CTR-001340","","The container platform must prohibit communication using TLS versions 1.0 and 1.1, and SSL 2.0 and 3.0.","","The container platform and its components will prohibit the use of SSL and unauthorized versions of TLS protocols to properly secure communication.\n\nThe use of unsupported protocol exposes vulnerabilities to the container platform by rogue traffic interceptions, man-in-the middle-attacks, and impersonation of users or services from the container platform runtime, registry, and keystore.\n\nThe container platform and its components will adhere to NIST 800-52R2.",null,"Applicable - Inherently Meets","Review the container platform configuration to determine if TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 are prohibited for communication. \n\nIf communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 is permitted, this is a finding.","","Configure the container platform to prohibit communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0.","","CAT II",""]
["IA-5 (2) (a)","CCI-000185","SRG-APP-000605-CTR-001380","","The container platform must validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation.","Need to elaborate here. This is a placeholder. Rancher MCM must verify the certificates used for Rancher's ingress is a valid DOD certificate. This is achived by verifying the helm installation contains correct parameters.","A certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate and discourages the use of self-signed certificates.\n\nCertification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Compliance checks should be in accordance to RFC 5280.\n\nNot adhering to RFC 5280 could result in rogue certificates, session hijacks, man-in-the-middle, denial-of-service attacks, malware, and data or information manipulation.","Rancher MCM must verify the certificates used for Rancher's ingress is a valid DOD certificate. This is achived by verifying the helm installation contains correct parameters.","Applicable - Configurable","Review the container platform configuration to verify the container platform is validating certificates used for Transport Layer Security (TLS) functions by performing a RFC 5280-compliant certification path validation and that self-signed certificates are not being used. \n\nIf the container platform is not validating certificates used for TLS functions by performing an RFC 5280-compliant certification path validation, this is a finding. \n\nIf self-signed certificates are in use, this is a finding.","Verify helm installation contained correct parameters\nFrom the console, Type:\n`helm get values rancher -n cattle-system`\n\nThe output must contain:\n```\nprivateCA: true\ningress:\n  tls:\n    source: secret\n```\nIf the output source is not 'secret', this is a finding.\n\nVerify contents of certificates are correct: \nFrom the console, type:\nkubectl -n cattle-system get secret tls-rancher-ingress -o 'jsonpath={.data.tls\\.crt}' | base64 --decode | openssl x509 -noout -text\n\nkubectl -n cattle-system get secret tls-ca -o 'jsonpath={.data.cacerts\\.pem}' | base64 --decode | openssl x509 -noout -text\n","Configure the container platform to validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation and to disable the use of self-signed certificates.","Update the secrets to contain valid certificates.\n\n--Need to write Steps here","CAT II",""]
["IA-7","CCI-000803","SRG-APP-000610-CTR-001385","","The container platform must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).","","Without the use of digital signature, information can be altered by unauthorized accounts accessing or modifying the container platform registry, keystore, and container at runtime. Digital signatures provide non-repudiation for transactions between the components within the container platform. Without the use of approved FIPS-validated SHA-2 or higher hash function with digital signatures, the container platform cannot claim the validity of the individual or service identity and guarantee private key is kept secret. Keeping the private keys secure is vital for validating individuals or service identity prior to information exchange. The container platform must be configured to use SHA-2 or higher hash functions for digital signatures in accordance with SP 800-131Ar2.","","Not Applicable","Review the container platform configuration to validate that a FIPS-validated SHA-2 or higher hash function is being used for digital signature generation and verification. \n\nIf a FIPS-validated SHA-2 or higher hash function is not being used for digital signature generation and verification, this is a finding.","","Configure the container platform to use a FIPS-validated SHA-2 or higher hash function for digital signature generation and verification.","","CAT II","",null,"Rancher MCM does not authenticate users, but uses external organizational services for authentication and Rancher MCM authorizes users for what the user may do. This control is about authenticating users before use of cryptographic modules and is out of scope of Rancher MCM"]
["SC-13","CCI-002450","SRG-APP-000635-CTR-001405","","The container platform must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.","","Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.\n\nCryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the container platform component and information residing in the container platform registry and keystore.","","Not Applicable","Review the container platform configuration to ensure FIPS-validated cryptographic modules are implemented to encrypt unclassified information requiring confidentiality. \n\nIf FIPS-validated cryptographic modules are not being used, this is a finding.","","Configure the container platform to use FIPS-validated cryptographic modules to encrypt unclassified information requiring confidentiality.","","CAT I","",null,"Rancher MCM does not contain confidential data, such as PII, unless a user service deployed within Rancher MCM operates on this type of data. If a user service is deployed that operates on confidential data, the service would need to implement this control."]
["CM-7 b","CCI-000382","SRG-APP-000645-CTR-001410","","The container platform must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission.","Rancher MCM must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission.","The use of secure ports, protocols and services within the container platform must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy.\n\nUnsecure protocols for transmission will expose the information system data and information, making the session susceptible to manipulation, hijacking, and man-in-the middle attacks.","Unsecure protocols for transmission will expose the information system data and information, making the session susceptible to manipulation, hijacking, and man-in-the middle attacks.\n\nTo ensure that traffic coming through the ingress controller is re-encrypted internally, switch off port 80 on the service object and direct ingress traffic to port 443 over HTTPS.","Applicable - Configurable","Review the container platform configuration to verify that container platform is not using protocols that transmit authentication data unencrypted and that the container platform is not using flawed cryptographic algorithms for transmission. \n\nIf the container platform is using protocols to transmit authentication data unencrypted or is using flawed cryptographic algorithms, this is a finding.","kubectl get ingress -n cattle-system rancher -o yaml\nverify:\nspec:\n  rules:\n  - host: rancher.example.com < Caution-http://rancher.example.com > \n    http:\n      paths:\n      - backend:\n          service:\n            name: rancher\n            port:\n              number: 443\n\nkubectl get svc rancher -n cattle-system -o yaml\nVerify:\nspec:\n  clusterIP: 10.43.145.4\n  clusterIPs:\n  - 10.43.145.4\n  ipFamilies:\n  - IPv4\n  ipFamilyPolicy: SingleStack\n  ports:\n  - name: https-internal\n    port: 443\n    protocol: TCP\n    targetPort: 443","Configure the container platform to use protocols that transmit authentication data encrypted and to use cryptographic algorithms that are not flawed.","Execute the following:\nkubectl patch -n cattle-system service rancher -p '{\"spec\":{\"ports\":[{\"port\":443,\"targetPort\":443}]}}'\nexport RANCHER_HOSTNAME=rancher.disa-eval-2-6.tomatodamato.com < Caution-http://rancher.disa-eval-2-6.tomatodamato.com > \nkubectl -n cattle-system patch ingress rancher -p \"{\\\"metadata\\\":{\\\"annotations\\\":{\\\"nginx.ingress.kubernetes.io/backend-protocol\\ < Caution-http://nginx.ingress.kubernetes.io/backend-protocol\\ > \":\\\"HTTPS\\\"}},\\\"spec\\\":{\\\"rules\\\":[{\\\"host\\\":\\\"$RANCHER_HOSTNAME\\\",\\\"http\\\":{\\\"paths\\\":[{\\\"backend\\\":{\\\"service\\\":{\\\"name\\\":\\\"rancher\\\",\\\"port\\\":{\\\"number\\\":443}}},\\\"pathType\\\":\\\"ImplementationSpecific\\\"}]}}]}}\"\nkubectl patch -n cattle-system service rancher --type=json -p '[{\"op\":\"remove\",\"path\":\"/spec/ports/0\"}]'","CAT I",""]