Managing Confidentiality and Security Levels

This section explains how to manage security levels to implement your data confidentiality strategy.

  1. Select the command Configure My ENOVIA from the Tools icon.

  2. Select the Advanced tab.

  3. Select the Resources command, then the Security Level tab.

    This displays the confidentiality table. By default, only one security level is defined:

    Security Level
    Security levels are integers and must be entered in ascending order.
    Alias Name
    Alias for the corresponding security level, for example Confidential, Sensitive, Critical, Top Secret, etc. For level 0, the alias is Public.
    Description

    This descriptive text is a confidentiality message displayed in the CATIA V6 GUI when you start a V6 session, enabling you to protect confidential data. The message is uploaded to the user in CATIA V6 when connecting to the server.

    For example, you can enforce the protection of intellectual property by guaranteeing that any sensitive information that is displayed in CATIA V6 is correctly tagged when printing or generating documents (e.g. PDF), or when taking a snapshot of the CATIA window (for example, when using the "print screen" capability).

    The confidentiality messages that can be defined here do not support localization, i.e. they are used as is in CATIA V6.

  4. Click the Add Rows command, add the security level integer, alias name and description (confidentiality message), then click the Save button.

    In this example, three additional levels were created:

  5. Select the People command, the Project tab, then click the New... command to create a project.

    You must create a project because the project must be linked to the security level. All users logging onto this project then inherit the accredited security level.

    To do so, when creating the project, select the security level in the Accreditation list:

    In our example, let's assume that you select Sensitive for the accreditation. This means that your project has security level 1 accreditation.

  6. Create a security context referencing the project you just created, then create a user, for example User1.

    Let's assume User1 starts a CATIA V6 session, then creates and propagates a product in the database. The v_sec_level or confidentiality level of the product is tagged "1" because the project that created it has security level 1 accreditation.

    A simple attribute of type integer is added to the PLMEntity to store the level of confidentiality of the data:

    <Simple Name="V_sec_level" Uuid="75773879-fca9-4e79-a6f9-9edbe238e009" 
    AccessMode="ReadWrite" Mandatory="No" MultiValuated="No" Visibility="Public"
    Type="Integer" Protection="Free" CAAExposition="L0"></Simple>

    The default value is 0. This means that all existing data will have a level of confidentiality of 0. This applies also to new data (unless the current security level of the project is otherwise, without customization). By default there is no filtering.

    All the objects created during a session and which have the confidentiality attribute not valuated and defined will inherit the accreditation value for the current connected project .

    But at this point two problems occur:


    • any other user (for the moment) connected to the same project inherits the same accreditation: no distinction is made; the data is still not secured because everybody has the same rights
    • if User1 searches for objects belonging the Sensitive category (alias), the search will return no result: to be able to perform this type of search, you must first edit and recompile the corresponding masks for the confidential data types to make the confidentiality visible and updatable in the V6 GUI.

  7. Edit the corresponding masks.

    To allow the valuation, modification and visualization of the security level, the security masks of the targeted data types (products, documents, etc.) have to be changed to account for this attribute (read, write, query and create masks).

    The confidentiality vector is based on two attributes defined within the metadata:


    • V_sec_level is a persistent attribute with an integer type to assign the confidentiality to an object. This attribute is never seen within a mask.
    • V_Confidentiality as a computed attribute, non persistent with string type to manage the external view of the value (eg, Critical) associated to the persistent information. Each mask with this attribute defined will be visible in the GUI.

    Here is an example for the PLM entity type ENOSAM_VPMPart:

    ENTITY ENOSAM_VPMPart 
    ATTR PLM_ExternalID;N;N;$
    ATTR V_version;N;N;$
    ATTR V_maturity;N;N;$
    ATTR V_description;N;N;$
    ATTR LOCKUSER;N;N;$
    ATTR V_discipline;N;N;$
    ATTR V_usage;N;N;$
    ATTR C_created;N;N;$
    ATTR C_modified;N;N;$
    ATTR V_user;Y;N;$
    ATTR V_organization;Y;N;$
    ATTR V_project;N;N;$
    ATTR V_ApplicabilityDate;N;N;$
    ATTR V_confidentiality;N;N;$
    ATTR V_sec_level;N;N;$

    This is the creation mask:

    //-------------------------------
    FUNC Create
    //-------------------------------
    FATTR PLM_ExternalID;Y
    FATTR V_description;Y
    FATTR V_confidentiality;Y

    This is the query mask:

    //-------------------------------
    FUNC Query
    //-------------------------------
    FATTR PLM_ExternalID;Y
    FATTR V_version;Y
    FATTR V_maturity;Y
    FATTR V_description;Y
    FATTR LOCKUSER;Y
    FATTR V_discipline;Y
    FATTR V_usage;Y
    FATTR C_created;Y
    FATTR C_modified;Y
    FATTR V_user;Y
    FATTR V_organization;Y
    FATTR V_project;Y
    FATTR V_ApplicabilityDate;Y
    FATTR V_sec_level;Y

    Query/search do not support the computed attribute V_Confidentiality in the GUI. Only the V_sec_level is supported and visible through mask management (Query/EZquery/Read). That means that the end user needs to know the confidentiality semantics (for example, 0 represents public, 1 represents sensitive, etc.) to express the "where" clause in the advanced search panel.

    Then, recompile and deploy the masks.

    A customization of the New... dialog box is required to retrieve the definition of the security levels. This definition is stored in a resource object of a new type:


    • Modeler: PLMPosAbstractTable
    • Customization: PnOTableDS
    • Reference type: PLMPosTableRef

    The attribute PLM_ExternalID of this table is set to a predefined value (because there is only one table allowed for confidentiality level definition).

    The alias of one confidentiality level is stored in the attribute V_row_name of the table.

    The value of one confidentiality level is stored in the attribute V_row_value of the table.

    For more information, refer to the CAA documentation.

  8. Start a V6 session as User1.

    The property panel for the New... command for all objects associated to a confidentiality level will be displayed based on the mask definition for creation.

    The confidentiality information created is displayed as a value to select from a list. You select a value to be stored with the object. If not, the confidentiality attribute will be the same as the accreditation level for the current project:



    On the server side, during the propagation in the database, the project accreditation information will be retrieved in order to value the confidentiality vector of the new objects accordingly. The same behavior also applies to clone and import processes on the server side.

    When modifying data, a Properties dialog box for all objects associated to a confidentiality level will be displayed based on the mask definition. The confidentiality information created is displayed as a value to select from a list:

    When searching/querying, a Search dialog box for all objects associated to a confidentiality level will be displayed based on the mask definition. The confidentiality information will be visible only via its persistent value (integer), and not via its alias:

    For the moment, access to confidential information is still not filtered. Policy and rule customization is required to filter data based on the data's confidentiality level.

  9. Customize policies and/or rules to filter user access to confidential data based on user accreditation.

    We have already seen that the optional property named ACCREDITATION is added to the person and project objects. This property stores an integer. No property is considered equivalent to 0.

    This property is the administrative counterpart of the V_sec_level PLM attribute which supports confidentiality on VPM data. Since P&O objects are not VPM data, this property is needed to manage confidentiality on those objects.

    Using this property, security filters for policies and rules accounting for confidentiality can be written. For example, the filter:

    "attribute[VPLMatt/PLMEntity/V_sec_level]
    <= context.user.property[ACCREDITATION].value"

    filters out data whose security level is higher than the accreditation level of the connected user (where PLMEntity is the PLM data type).

    The following sample expression is provided and can be deployed in policy and/or rule filter expressions in order to implement confidentiality-based access checking: UserConfidentialData. This expression grants access to data with security level lower than or equal to user accreditation:

    attribute[VPLMatt/PLMEntity/V_sec_level].value <=
    context.user.property[Accreditation].value

    Let's assume that you implemented the above expression, then you created User1 and User2, both connected to the same project, where:


    • the accreditation level of the project is set to level 1 (it is added to the existing level 1 which is public)
    • the accreditation level of User1 is set to level 2
    • the accreditation level of User2 is set to level 1.

    If you modify the WRITE mask, User1 will be able to edit the properties of an object, set the security level to 2, then propagate the object to the database.

    If you modify the CREATE mask, when creating a new object, User1 will be able to select security level 0 (public), 1 or 2, but User2 will only be able to choose from security level 0 (public) or 1, because the accreditation level of the user is checked beforehand: the expression grants access to data with security level lower than or equal to user accreditation.

    Note: Filtering on confidentiality and accreditation levels in policies and rules may affect the query/expand performance.