Access Control Matrix to BLP Lattice

TL;DR

This guide shows how to build a Bell-LaPadula (BLP) lattice structure from an Access Control Matrix. This is useful for implementing mandatory access control in systems where you need fine-grained security policies.

Building the BLP Lattice

1. Understand Your Access Control Matrix: The matrix defines who can do what to which resources. Rows represent subjects (users, processes), columns represent objects (files, databases). Cells contain permissions (read, write, execute).
2. Identify Security Levels: Assign a security level to each subject and object. These levels should be hierarchical – think of them as classifications like ‘Top Secret’, ‘Secret’, ‘Confidential’, ‘Unclassified’.
3. Create the Lattice Nodes: Each unique security level becomes a node in your BLP lattice.
4. Define Dominance Relation: This is crucial. A security level A dominates security level B if all information flowing from B to A does not compromise the system’s security. Typically, higher levels dominate lower levels. For example:
   • Top Secret dominates Secret
   • Secret dominates Confidential
   • Confidential dominates Unclassified
5. Representing Dominance: You can represent this with a graph. Draw arrows from higher-level nodes to lower-level nodes indicating dominance.
6. No Read Upwards Rule: Subjects at level L cannot read objects at levels above L. In the lattice, this means no edges point *up* from an object’s node to a subject’s node.

   # Example (Python): Check if a subject can read an object
   def can_read(subject_level, object_level):
     return subject_level >= object_level # Dominates or equal
   

7. No Write Downwards Rule: Subjects at level L cannot write to objects at levels below L. No edges point *down* from a subject’s node to an object’s node.

   # Example (Python): Check if a subject can write to an object
   def can_write(subject_level, object_level):
     return subject_level <= object_level # Dominated or equal
   

8. Apply the Rules to Your Matrix: Go through each cell in your Access Control Matrix. If a permission exists that violates either the 'No Read Upwards' or 'No Write Downwards' rule, you need to adjust the permissions or security levels.
   • If Subject A at level X has read access to Object B at level Y and X < Y, deny the read permission.
   • If Subject A at level X has write access to Object B at level Y and X > Y, deny the write permission.
9. Example Matrix Adjustment: Let's say your matrix initially allows a 'Confidential' user to read a 'Secret' file. You would remove that read permission.
10. Implement Enforcement: Integrate the lattice structure and rules into your system’s access control mechanism. This might involve modifying kernel-level security checks, using a policy engine, or implementing custom authorization logic in your application code.

Important Considerations

• Discretionary Access Control (DAC): BLP is mandatory; it overrides DAC.
• Trusted Subjects: Some subjects might be 'trusted' and allowed to bypass certain rules, but this should be carefully controlled.
• Complexity: Managing security levels can become complex in large systems.