OpenControls Logo

STIG Viewer

STIGViewer Support

Symantec ProxySG must use Role-Based Access Control (RBAC) to assign privileges to users for access to files and functions.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-94685SYMP-NM-000170SV-104515r1_ruleCCI-000366medium
Description
Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on organizational information systems associated with the organization-defined roles. When administrators are assigned to the organizational roles, they inherit the authorizations or privileges defined for those roles. RBAC simplifies privilege administration for organizations because privileges are not assigned directly to every administrator (which can be a significant number of individuals for mid- to large-size organizations) but are instead acquired through role assignments. RBAC can be implemented either as a mandatory or discretionary form of access control. The RBAC policies and the subjects and objects are defined uniquely for each network device, so they cannot be specified in the requirement.
STIGDate
Symantec ProxySG NDM Security Technical Implementation Guide2019-12-20

Related Frameworks

2 mappings across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (8) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-01Configuration Management Program
1.00
END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
MON-01Continuous Monitoring
1.00
MON-01.7File Integrity Monitoring (FIM)
1.00
CFG-02Secure Baseline Configurations
0.50
CFG-02.7Approved Configuration Deviations
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (100) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-12Session Termination
1.00
AC-16(1)Dynamic Attribute Association
1.00
AC-17(1)Monitoring and Control
1.00
AC-2Account Management
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(11)Usage Conditions
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-24(1)Transmit Access Authorization Information
1.00
AC-25Reference Monitor
1.00

+90 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.4.1
1.00
3.4.2
1.00
CCI2 mappings
CCI-000366
1.00
CCI-002169
1.00
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

DE.CM-09
1.00
PR.PS-01
1.00
PR.DS-10
0.50
PR.PSPlatform Security
0.50
PR.PS-05
0.50

Who does this work

10 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-104515r1_chk)

Confirm that role-based access control is configured. 1. Log on to the Management Console. 2. Click Configuration >> Policy >> Visual Policy Manager. 3. Click "Launch", select "Admin Access Layer" verify that at least one rule has been defined, and that each rule does not have "Any" or a single user defined in the "Source" field. Instead, each rule should have a user group specified in the "Source" field. 4. Confirm with the ProxySG administrator that each rule has the appropriate permission for the user or group specified in the rule (Action set to "Allow Read-Only Access" or "Allow Read-Write Access"). If Symantec ProxySG does not use Role-Based Access Control (RBAC) to assign privileges to users for access to files and functions, this is a finding.

Fix Text (F-100803r1_fix)

Configure the ProxySG for role-based group access. 1. Log on to the Web Management Console. 2. Click Configuration >> Policy >> Visual Policy Manager. 3. Click "Launch", select "Admin Access Layer". 4. For each rule that does not have an Action of "None" or "Deny" that also does not have a user group set in the "Source" field, right-click the "Source" field and click "Set". 5. Click each "Source Object" that represents a specific user (vs a user group) and click "Remove". 6. Click "New" and select "Group" from the menu. Enter the correct information for the desired user group which should have access to the ProxySG and click "OK", then "OK" again. Repeat for each rule in the Admin Access layer. 7. Click the "Install Policy" button to commit the changes to the Symantec ProxySG.