Security Mechanisms for General Access
AppResponse 11 users can access an AppResponse 11 system via three methods.
Method 1: Browser/web UI access
The Web UI is accessible from HTTPS, with the customer able to supply their own SSL certificate. HTTP can be enabled, but is insecure. Users authenticate with username/password through Local, RADIUS, or TACACS+ authentication methods. User authentication with SAML is also supported. With SAML enabled, the user credentials depends on the IdP used; e.g., CAC cards may be supported. Once authenticated, further communications use OAUTH2 with signed JWT access tokens.
Method 2: REST API
REST API access is accessible from HTTPS, with the customer able to supply their own SSL certificate. HTTP can be enabled, but is insecure. Users authenticate with username/password through Local, RADIUS, or TACACS+ authentication methods. Once authenticated, further communications use OAUTH2 with signed JWT access tokens.
Method 3: CLI
The CLI is accessible from SSH and serial port. Users authenticate with username/password through Local, RADIUS, or TACACS+ authentication methods. Internally, the CLI makes the same REST calls as the Web UI does. The commands are protected by OAUTH2 + JWT.
Security Mechanisms for Captured/Stored Packets
AppResponse 11 users decide which packets are stored on/captured to disk. (Part of AppResponse 11 setup and configuration is deciding which users should have the admin privileges to create/update Capture Job configurations that control which packets are – and are not – captured on disk.)
AppResponse 11 stores packets to disk exactly as they were seen “on the wire” – in-the-clear packets are stored as such, encrypted packets are stored as encrypted packets.
AppResponse 11 users can optionally supply private keys that allow AppResponse 11 to decrypt packets (i.e., HTTPS) that involve the specific servers the private keys relate to. The packet analysis that is done on these decrypted packets produces the packet metadata (groups/objects and related metrics/statistics) that are calculated by the ASA and WTA feature modules. Even though AppResponse 11 can decrypt encrypted packets and calculate packet metadata from them, it will continue to store those packets on disk as encrypted packets.
AppResponse 11’s RBAC architecture supports an explicit permission that controls if an AppResponse 11 user has access to the packets stored in AppResponse 11, as shown here:
As a result, only users who have been assigned a role that has given Full Control for this Access Packets/Live Views permission can access packet data in AppResponse 11. (Again, part of AppResponse 11 setup and configuration is deciding which users should have this permission.) This is the fundamental mechanism that controls which users have access to packets in an AppResponse 11 system. This applies to all users who are authenticated via any of the supported authentication mechanisms: Locally, or via TACACS+, or via RADIUS, or via a SAML-enabled system. This also applies regardless of whether users interact with an AppResponse 11 appliance via it’s web UI, via Packet Analyzer Plus, or via the published AppResponse 11 REST API.
AppResponse 11 users (whose role grants Full Control to the Access Packets/Live Views permission) can access packets via the web UI, Packet Analyzer Plus, and the AppResponse 11 REST API. Again, all packets that are accessed by any of these methods will be the packets as they are stored on-disk – in-the-clear packets will be downloaded as such, encrypted packets will be downloaded as encrypted packets. What this means:
◼ If you want to analyze packets downloaded from AppResponse 11 in Packet Analyzer Plus (or Transaction Analyzer, Wireshark, etc.) that are encrypted, you will need to obtain/supply the private keys needed for decrypting those packets via some other means.
In other words, you can download encrypted packets but you cannot download the private keys that you configured in AppResponse 11 to allow it to do real-time packet decryption.
◼ Once you configure AppResponse 11 to use private keys for real-time packet decryption, there is no way to extract those private keys off the AppResponse 11 appliance for any offline packet analysis.
The AppResponse 11 8180 model (only) supports the option for an additional level of data-at-rest encryption for all packet (and non-packet metadata) that is stored on one or more 120 TB storage units that are attached to an 8180.
Security Mechanisms for SSL/TLS Keys
As part of normal product use, AppResponse 11 users routinely provide the following types of sensitive information:
◼ SSL/TLS private key to secure browser-appliance and REST API-appliance communication (for management/admin and data analysis)
◼ SSL/TLS private keys to decrypt encrypted traffic for individual servers (usually web)
◼ SSL/TLS private key
◼ to secure the enhanced NetFlow information that an AR11 appliance can export to NetProfiler
◼ SSL/TLS private key to secure the communication between AR11 and a SAML IdP (if the AR11 user has chosen to use SAML)
This user-provided information is automatically encrypted and stored in a secure vault in the appliance. The vault is protected by a key that is auto-generated algorithmically and is known only to the software running on the appliance. The information in the vault is decrypted/unlocked during normal boot and is made available in system memory for use by relevant software components. Once the user inputs any sensitive information into the vault, there is no way to get that information out of the vault, i.e., AppResponse 11 does not support copying or exporting information out of the vault. This means, this sensitive info is protected even if someone were to get physical access to AppResponse 11's hard disks.