Skip to main content
Version: 7.2405.x.x LTS

Security

The following actors are important from a security point of view:

  • The user accessing the administration web application, nevisDetect Web App. The nevisDetect Web App is an Angular 2 based Single Page Application (SPA) running in the browser of the user.
  • The components of nevisDetect accessing others components.

In most environments a set of (security) roles are assigned to an identity (an identity can be e.g., a user). To be able to integrate your enterprise environment seamlessly into nevisDetect, nevisDetect maps the security roles onto permissions, as you can see in the figure Role-permission-mapping below:

Role-permission-mapping

From now on, we call this mapping within nevisDetect role-permission-mapping. nevisDetect ships with a default role-permission-mapping. Use this default mapping as a starting point for your custom mapping configuration.

The default mapping is based on the assumption that for every persona a separate security role exists. Additionally, there are security roles representing the different components of nevisDetect, see the table Personas and security roles below for an overview of all available personas and security roles. This allows an uniform treatment of all actors (users and components) from a security point of view.

Persona/componentSecurity role
Support desk user (Persona)DETECT_HELPDESK
Security expertDETECT_SECURITY_OFFICER
OperatorDETECT_OPERATOR
Forensic expertDETECT_FORENSIC_EXPERT
nevisDetect CoreDETECT_CORE
nevisDetect Feature CorrelatorDETECT_FEATURE_CORRELATOR
nevisDetect PersistencyDETECT_PERSISTENCY
nevisDetect ControllerDETECT_CONTROLLER

See how in the default role-permission-mapping a security role is mapped onto permissions:

Security role: DETECT_FORENSIC_EXPERT

  • APP_MANAGEMENT_READ
  • APP_MANAGEMENT_PLUGIN_WRITE
  • APP_MANAGEMENT_GLOBAL_WRITE
  • APP_MANAGEMENT_FILTER_WRITE
  • APP_MONITORING_READ
  • CASE_OVERVIEW_READ
  • CASE_WRITE
  • CID_READ
  • GENERATED_RULES_READ
  • GENERATED_RULE_TOGGLE_ACTIVE
  • GENERATED RULE_WRITE
  • PLUGIN_OVERVIEW_READ
  • PLUGIN_RISK_SCORE_WRITE
  • POLICY_OVERVIEW_READ
  • POLICY_TOGGLE_ACTIVE
  • POLICY_WRITE
  • POLICY_CREATE
  • REFDATA_READ
  • RISK_SCORE_NORMALIZATION_CALCULATE
  • RISK_SCORE_NORMALIZATION_READ
  • USER_OVERVIEW_READ

Security role: DETECT_SECURITY_OFFICER

  • APP_MANAGEMENT_READ
  • APP_MANAGEMENT_PLUGIN_WRITE
  • APP_MANAGEMENT_GLOBAL_WRITE
  • APP_MANAGEMENT_FILTER_WRITE
  • APP_MONITORING_READ
  • CASE_OVERVIEW_READ
  • CASE_WRITE
  • GENERATED_RULES_READ
  • GENERATED_RULE_TOGGLE_ACTIVE
  • GENERATED_RULE_WRITE
  • PLUGIN_OVERVIEW_READ
  • PLUGIN_RISK_SCORE_WRITE
  • POLICY_OVERVIEW_READ
  • POLICY_TOGGLE_ACTIVE
  • POLICY_WRITE
  • POLICY_CREATE
  • REFDATA_READ
  • RISK_SCORE_NORMALIZATION_CALCULATE
  • RISK_SCORE_NORMALIZATION_READ
  • USER_OVERVIEW_READ

Security role: DETECT_OPERATOR

  • APP_MANAGEMENT_READ
  • APP_MANAGEMENT_PLUGIN_WRITE
  • APP_MONITORING_READ
  • PLUGIN_OVERVIEW_READ
  • REFDATA_READ
  • RISK_SCORE_NORMALIZATION_READ

Security role: DETECT_HELPDESK

  • CASE_OVERVIEW_READ
  • CASE_WRITE
  • GENERATED_RULES_READ
  • GENERATED_RULE_TOGGLE_ACTIVE
  • PLUGIN_OVERVIEW_READ
  • POLICY_OVERVIEW_READ
  • REFDATA_READ
  • RISK_SCORE_NORMALIZATION_READ
  • USER_OVERVIEW_READ
  • CID_READ

For a complete overview of the existing permissions and the default mapping, see Appendix: Role to Permission Mapping.

note

One security role can be mapped onto several permissions.

Authentication​

nevisProxy and nevisAuth take care of the user authentication and the assignment of the security roles:

  • They include the identity of the user as well as his security roles in the Nevis SecToken and forward the token to nevisDetect.
  • nevisDetect authenticates the user by verifying the signature of the SecToken.

The authentication of a nevisDetect component happens during the 2-way TLS handshake:

  • The calling component sends its X509 certificate during the TLS handshake.
  • The called component ensures that the X509 certificate is issued by a known and trusted Certificate Authority.

Authorization​

The authorization process includes three steps:

  1. First, the system retrieves the security roles of the caller.
  • In the case of a user, the security roles are retrieved from the SecToken.
  • In the case of a nevisDetect component, a single security role is derived from the Subject of the X509 certificate. For this, it is possible to configure a regular expression. The default regular expression extracts the Common Name (CN) from the Subject of the X509 certificate.
  1. As a next step, the system retrieves the permissions of the caller based on its security role.
  2. Finally, the system ensures that the caller has the requested permission for the service.