Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add organizations restrictions on top of markings to increase data segregation possibilities #2188

Closed
SamuelHassine opened this issue Jun 28, 2022 · 1 comment · Fixed by #2317
Assignees
Labels
feature use for describing a new feature to develop solved use to identify issue that has been solved (must be linked to the solving PR)
Milestone

Comments

@SamuelHassine
Copy link
Member

SamuelHassine commented Jun 28, 2022

Use case

Today, when an entity has marking X:A and marking Y:N, it will be only available to the group that has both marking.

Use case: be able to share an entity with 2 different customers/teams that have X:A on one side and Y:N on the other side.

Current Workaround

Add groups/markings representing all possible permutations.

Proposed Solution

Implement the ability to associated elements to specific organizations that will be only accessible for users that are part of these organizations

@SamuelHassine SamuelHassine added the feature use for describing a new feature to develop label Jun 28, 2022
@SamuelHassine SamuelHassine added this to the Release 5.4.0 milestone Jun 28, 2022
@richard-julien richard-julien changed the title Be able to add virtual markings to increase data seggregation possibilities Add groups restrictions on top of markings to increase data seggregation possibilities Sep 1, 2022
@richard-julien richard-julien changed the title Add groups restrictions on top of markings to increase data seggregation possibilities Add groups restrictions on top of markings to increase data segregation possibilities Sep 1, 2022
richard-julien added a commit that referenced this issue Sep 1, 2022
…ase data segregation possibilities (#2188)

- Report and intrusion-set
richard-julien added a commit that referenced this issue Sep 4, 2022
…ase data segregation possibilities (#2188)

- Report and intrusion-set
@richard-julien richard-julien changed the title Add groups restrictions on top of markings to increase data segregation possibilities Add organizations restrictions on top of markings to increase data segregation possibilities Sep 5, 2022
@richard-julien
Copy link
Member

Curious if, overall, the proposed changes would allow me to mark an IP Address (or any other entity, but just pulling IP Addr as an example) such that it is:

TLP:AMBER+STRICT within my organization (as that might be what "internal restrictions" I might place on anything shared from an external source at TLP:GREEN with my org)
TLP:GREEN within "CTI sharing group 1", where someone might have shared it at TLP:GREEN level to me
TLP:RED within "CTI sharing group 2", where someone else might have independently shared it TLP:RED with my org as audience

To clarify a bit, its ongoing work, so need to re-define a bit the semantic :)

Group = a set of marking. User can be assigned to multiple groups and so get a combination of granted markings
Organization = company of a user. A user could be inside multiple organizations.
So the PR is more about adding Organization restrictions in top of Group restrictions.
Organization restrictions is another level on top of markings. For me TLP:AMBER+STRICT is a first STIX approach of this problem because it means AMBER but for MY ORG only.
For info we decide to do like markings, no organization = all organizations

The big difference between groups and organizations is that group/markings are exclusive and organizations are inclusive
For example:
User definitions

USER01 is part of GROUP_GREEN (TLP:GREEN) - inside organizations COMPANY01
USER02 is part of GROUP_RED (TLP:RED) - inside organizations COMPANY01
USER03 is part of GROUP_GREEN (TLP:GREEN) - inside organizations RESTRICT
Data
Some use cases

IP adress 8.8.8.8 created with TLP:GREEN
-> USER01, USER02 and USER03 and all have access.
IP adress 8.8.8.8 created with TLP:GREEN + COMPANY01 orga restrictions
-> Only USER01 and USER02 have access.
IP adress 8.8.8.8 created with TLP:RED + COMPANY01 orga restrictions
-> Only USER02 have access.
So for your "CTI sharing group 1" i think it will be modelize as an Organization (type circle/sharing) that will have some sub organizations for example COMPANY01 + COMPANY02. So if you add the orga restrictions to "CTI sharing group 1", both organizations will have access to the IP.

Hope this help to understand our vision on this subject. :)

@richard-julien richard-julien self-assigned this Sep 5, 2022
richard-julien added a commit that referenced this issue Sep 5, 2022
richard-julien added a commit that referenced this issue Sep 8, 2022
…ase data segregation possibilities (#2188)

- Report and intrusion-set
richard-julien added a commit that referenced this issue Sep 8, 2022
richard-julien added a commit that referenced this issue Nov 15, 2022
richard-julien added a commit that referenced this issue Nov 15, 2022
richard-julien added a commit that referenced this issue Nov 15, 2022
Co-authored-by: Samuel Hassine <samuel.hassine@filigran.io>
@SamuelHassine SamuelHassine added the solved use to identify issue that has been solved (must be linked to the solving PR) label Nov 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature use for describing a new feature to develop solved use to identify issue that has been solved (must be linked to the solving PR)
Projects
None yet
2 participants