Security and Trust

Overview

The business objects for Security and Trust capture the information needed to for each organisation to be able to enforce their own human resources and security policies. Because these policies are not common across the organisations, what is recorded is the information about security and trust. BDA platforms then use the security and trust information to enforce the local policies. For example, one company may require a senior manager to approve the release of a “confidential” model and only to organisations in the EU. Another organisation may require two senior managers to approve the release and only to organisations that have signed a “risk sharing partnership” agreement.

The Security and Trust objects are:

  • Contract:
    • A contract is an identifiable object that represents a binding agreement.
    • It can have relationships to the organisation of people who are bound by the contract, and can also have approvals to show who “signed” the contract.
    • It can point to documents(s) which is the actual contract (e.g. in a document management system)
    • One contract can relate to other contracts, e.g. there could be a major partnership contract, and then many related contracts for the individual pieces of work
    • A contract can point to the object(s) about which it is the agreement.
    • For more information see: SysML - Contracts Diagram.
../../../_images/contract_4x3.png

Icon for Contract

  • Security Classification:
    • Security classifications are ways to specify the level of security that is applied to something.
    • It can have documents to describe the classification
    • It can point to the object(s) to which it applies, and that assignment can have approvals e.g. there could be a business rule to say that all assignments of “Public Domain” classification must be signed by a manager.
    • For more information see: SysML - Security Classifications Diagram.
../../../_images/security_classification_4x3.png

Icon for Security Classification

  • Information Right:
    • This is to identify what may or may not be allowed for the information in the sense of legal rights or obligations. For example, it could be a standard clause in a contract, or the right to allow copies to be made only by Persons who are in a particular organisation but with the restriction that those copies must be destroyed at the end of the specified period.
    • They have a source for the information right. This is a document, and will usually be a document that is also assigned to a contract.
    • They can be assigned to objects(s) to grant the rights, in the context of a particular contract
    • For more information see: SysML - Information Rights Diagram.
../../../_images/access_right_4x3.png

Icon for Access Right

An illustrative example

The Security and Trust objects can be associated with most of the business objects. The choice depends on the business rules and the scenario. In the example below there are two contracts for setting up the team of trust. The first is the “Collaboration context” contract which is associated to a contract to agree “ID certification”, i.e. so the partners in the team know you are who you say you are.

../../../_images/st_team_of_trust.png

Contract for ID certification within a Team of Trust

Associated to a Team of trust “Collaboration context” contract, can be a contract to agree the definition of the security classification and access rights that can be applied to objects that will be used for collaboration.

../../../_images/st_assignment.png

Assignment of Information Rights and Security Classifications

For more information see eLearn: Enterprise Collaboration > Module 3 > Highlight 6: Managing Intellectual Property in Collaboration

Representation using Business Object Model classes

This is a simple scenario describing one way to use the different Security and Trust objects. It uses the Very Simple Example, of a beam of constant cross section that is supported at one end, and deflection occurs at the other. The example assumes a set of Security and Trust business rules, but these could be different for different scenarios.

The diagram below shows a contract (in yellow) for setting up the “ID Certification” within a Team of Trust. It is an agreement between three organisations, and has been signed by a “Legal Representative” type of person in each organisation. The contract points to a document which in turn points to a DigitalFile. This could be a link to a file in a Document Management system.

../../../_images/vse_ea_st_team_of_trust.png

Contract for ID certification within a Team of Trust

Two more contracts are associated with the first contract in the illustration below. As described in the illustrative example section above, a general contract is set up to agree the information rights (in dark pink) between the parties. In this example the information rights are between two parties but they could be between more. The information rights point to an information source which, in this example happens to be the same document as the document for the contract. One of the information rights states that the rights granted are to be able to read the object, but any copies must be destroyed at the end of the usage period. This period is declared in the InformationUsageRight.

On the left of the diagram there is also a specific contract set up that is related to the information rights contract, and is for doing a particular piece of work.

../../../_images/vse_ea_st_collaboration_contract.png

Contracts for the collaboration

The central area of the image below shows the part of the Associative Model Network (from the first study in the Very Simple Example) needed to compute the deflection model. It shows that the deflection model is to be of a particular model type, and it is to be derived from three key values and another model. The deflection model has an actual activity associated to it.

Around the left and bottom of the diagram, “read but not distribute” information rights are assigned to the model types and key value types. These are the definitions for the models, so have greater rights because they may be used in other projects.

Along the top of the diagram, “read and destroy after period” rights are assigned to the instances. These are the live product data so have stricter rights. Security classifications are added in the pink area on the right of the diagram. For the model type this is a “public domain” classification, but the model instance is sensitive information so is given a “confidential” classification. Because of this “confidential” classification the assigned information rights have to be authorised by a legal representative of the organisation (top right).

Finally the green area shows the specific contract for doing a particular piece of work is assigned to the actual activity for the model instance.

../../../_images/vse_ea_st_assignment.png

Assignment of Information Rights and Security Classifications

Section author: Judith Crockford