The ALG providing user authentication intermediary services must use multifactor authentication for network access to non-privileged accounts.
An XCCDF Rule
Description
<VulnDiscussion>To assure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: 1) Something you know (e.g., password/PIN), 2) Something you have (e.g., cryptographic, identification device, token), and 3) Something you are (e.g., biometric). Non-privileged accounts are not authorized access to the network element regardless of access method. Network 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. Authenticating with a PKI credential and entering the associated PIN is an example of multifactor authentication. The CA API Gateway supports X.509, username/password, SAML, Kerberos, and RADIUS authentication. To provide multifactor authentication, the CA API Gateway must include a policy that uses multiple authentication assertions and include a route assertion that routes to a biometric back-end service and then evaluate the response to allow/disallow access to the Registered Service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
- ID
- SV-85979r1_rule
- Severity
- Medium
- References
- Updated
Remediation - Manual Procedure
Open the CA API Gateway - Policy Manager.
Double-click the Registered Services requiring multifactor authentication that were not properly configured.
For example, within the policy that leverages an RSA SecurID hardware token along with X.509, verify/add the "Require SSL/TLS with Client Certificate" Assertion, which will validate the certificate according to organizational requirements, then using that certificate to authenticate against LDAP or Active Directory, verify/add the "Authenticate Against Identity Provider" Assertion, and then verify/include the value from the hardware token in a request to the RSA SecurID RADIUS service via the "Authenticate Against RADIUS Server" Assertion.