Resolve Directory Access Control branch

[andrewbwm]

The directory_access_control branch was introduced to provide directory access control modelling capabilities.

This was requested by Victor from foreseeti for a language they are developing. Once this language has matured we should permanently resolve this branch. Until then the branch should be kept up to date when a release is made and master should be merged into it.

The current opinion is that we do not want want to include two distinct access control models in coreLang and therefore this branch should be removed. However, we may decide that the benefits of the two different models are worthwhile and we can merge the changes into master.

[andrewbwm]

The conversation regarding the need for a Directory or DirectoryEntry asset in coreLang resurfaced due to the Domain Policy Modification MITRE technique, and more specifically its Domain Trust Modification subtechnique.

The initial idea behind the Directory asset was for it to behave similarly to the Group asset, but allow for a downward compromise in the hierarchy. However, this did not adequately reflect the behaviour of directory service entries. Due to the fact that LDAP matches rules in the order they are listed and an earlier and more specific rule can be defined to restrict the access to a subtree in the directory hierarchy the generic downward compromise also proved problematic. We came up with two possible alternatives:

1. Use the Privileges asset to represent directory entries without using a downward compromise. This means that the modeller has to disaggregate rules into individual directory entry to directory entry associations. For example: access to dn.children="dc=example, dc=com" by * none access to dn.children="dc=com" by * manage Would lead to creating a manage association between the directory entry specifying these rules and every child directory in the dc=com subtree with the exception of the dc=example subtree entries. In doing so the associations are very granular, but the effort is shifted towards the modeller that has to interpret the directory service rules themselves and create individual associations. Since we expect to use tools to automatically generate coreLang models from LDAP rules this was seen as an acceptable drawback.

2. Create a DirectoryEntry that behaves similarly to Privileges, but also includes a downward compromise. This would mean that an exception association also would need to be added. This is likely to require some complex logic in the attack steps to implement if it even is possible. Therefore this was deemed non-viable at this particular stage in the project.

After several conversations with Victor Wallin and a discussion during the weekly coreLang meeting on June 15th the decision was made that the current Privileges asset replicates most of the behaviour needed to depict directory entries and we should go with alternative 1 present above.

[andrewbwm]

This means that the directory access branch is in fact no longer needed.

However, it should still be left intact, especially the DAC_v0.5.1rc2 tag which is used by the SOCCRATES project.

After the SOCCRATES project deems it no longer necessary the directory access branch should be removed.

[andrewbwm]

Since we are using Privileges to represent directory entries and the only association(excluding the specialised ones) between Privileges and IAMObjects is the manage association we only cover the manage access level. A full list of access levels used by OpenLDAP can be found here.

This is not currently an issue since the disclose, search, and read levels would be needed for discovery and reconnaissance purposes, which coreLang does not currently cover anyway. The auth would be needed if we decide to implement an Authenticate association in the future, for the time being we can have the Privileges asset grant access to Data containing Credentials if the need arises. I'm unsure what the compare access level entails for us. The write and manage access levels can be grouped together for now since they are very similar in their effects.