Change Management practices in Security Markings

Hi,

Foundry enforces the concept of change management in many components of the platform (datasets, repos, ontology proposals, etc.). This principle has been gradually adopted for operations in the control panel. The approval workflow already enforces a 4-eye principle on sensitive operations such as Egress policies. This should be extended to:

  1. creation of security markings
  2. changes in the security markings (e.g. add/remove groups)

image

Creation and managing permissions centralized in admins when users raise issues. This process involves manual work, it is hard to trace, and it is error-prone. Also, relies in good-faith as it can be argued the group associated to Manage permissions can add themselves temporarily to the marking membership without proper controls and traceability in place.

An approval workflow would therefore make sense. A user could create a security marking proposal, which would go to the group who manages the platform. This would enable to scale operations of the platform more seamlessly.

Changes in the markings, can be approved by the group who Manages marking permissions. thus providing a transparency of changes in security markings to its members. (who requested, who approved, when etc.)

Note: Which role should a user have in order to propose a marking creation is debatable and should be possible to tweak.

4 Likes