I was at a security conference recently and one of the presentations had some TLP:RED slides in it.
I couldn't help but find that pointless. The conference is open to the public, the only barrier to entry being a small amount of money to purchase a ticket. How would that prevent bad actors from signing up to access the sensitive information?
It absolutely makes sense when used within an organization where access/membership is properly vetted, but there, I feel like there was no point.
You're completely right: if that's not an invite only or vetted conference (that exist), this is just a marketing gimmick
to grab people attention. People who do that either don't understand what you feel intuitively, or do this attention grabbing thing intentionally. Just like "no media" presentations that just post their slides online later.
You're right that it doesn't make sense. It suggests a failure in data handling (who can I share this with?).
A lot of these are borrowed from the US .gov in which prosecution is a relatively effective way to get compliance with these policies, but, and I'll take some license here, are copied to appear sophisticated by unsophisticated players outside of that.
I've always found TLP confusing: it's not really clear (despite definition) what a community or organization is, which means that there's no clear decision procedure for determining whether a degree of access has been violated.
In my experience doing security embargos/disclosures, it's a lot easier to just explicitly enumerate the set of people/organizational entities who should be given access to non-public information.
> it's not really clear (despite definition) what a community or organization is
To make the parent’s point more obvious for people who are not used to a large enterprise context, concretely for example, at my workplace (which I would consider typical of a large organization) there are:
1) Regular employees and contractors who are employed by the main employer.
2) Employees who work for different legal entities from the main employer, have different sso domains handling their auth (and email domains for systems that do sharing protections via email) but are “really” part of the same company for security purposes. Think say people who came in as part of a merger but for various reasons their legal entity and brand needs to stick around so they have different auth, email etc.
3) People who work for actually different companies, have the same sso domains handling handling their auth and the same email domain as people in bucket 1 because we’ve given them logins and are working on sensitive security stuff (think: vendors and vendor contractors in the security or legal space)
4) People who work for actually different companies, have the same sso domains etc as bucket 1 and are not working on sensitive security stuff (think: vendors and vendor contractors everywhere else)
…and people sometimes move between groups 3 and 4 on a project by project basis. Notice all of these are “bound by common policies set by the organization” so all of them are in the “organization” for TLP at least by the second part of the definition, but 2,3 and 4 but don’t share a common affiliation by formal membership so are not part of the “organization” for the first half of the TLP definition.
So if I get a TLP:Amber document, who am I allowed to share it to? I should be sharing it to some of 1, 2 and 3 on a need to know basis. Most automated permission systems will allow me only to share it easily only with people in 1 and 3 or 4, and since people can move between 3 & 4 based on assignment it’s hard to know (and pretty much impossible to tell automatically) if some degree of access violation has occurred. People in 2 are generally sool if we’re trying to share things and I’m not prepared to handwave through the scary-looking “are you sure you want to share this with person x who isn’t from our org?” Boxes.
Basically explicit enumeration is just going to be way better any time you want to be doing this type of thing in the real world.
From the protocol the community and organization needs to be defined by the source of the information. If not, then it cannot be shared without request from the source. They even have example for those situations.
I've self-discovered a similar categorization for my imaginary social network that will dethrone El Zuck:
Ultimate - black/white - passwords/keys/finance/backups
Private - red - hidden by default
Protected - yellow - default "logged in to computer"
Public - green - shared w/ others (individuals)
Broadcast - blue - intentionally wide distribution
...the key insight being that as you go "deeper" you know "less" (if that makes sense). Take the pictures on my phone and the album names (eg: Fall Trip 2025).
If I post my headshot to hire-an-actor.com, that's "Blue/Broadcast". If I share a picture of my kid blowing out birthday candles, that's "Green/Public". From "Green" you might be able to see the LABELS of my "Yellow" stuff and request access to it, but there should be no indication that "Red" or "Black" even exists.
So basically you as a user always operate at "Yellow", and can push "up" to Green (aka: discord), or Blue (aka: tweeter), and can unlock "Red" or "Black" via Password or 2FA/Cert.
I wish there were a way to easily "vivify" this, but at least putting names to it exposes where/how we're currently lacking.
The biggest issue still remains that content is "slippery" ... if it's not 10000% protected and airgapped, there's a chance that it can "escape".
Yeah I got exited thinking this is about traffic lights. I use a bike to commute to work and recently I was thinking if I could adjust my cycling cadence so that I never hit a red light, but unfortunately the timing of the traffic lights in my city is not constant. If there was a publicly accessible API to get the current timing info, I could write an app to do that.
If you're in America, take a look at the strobe on top of school busses. I'm not sure if they still have them (they used to). It would flash at a specific frequency and trip a photovoltaic sensor connected to the traffic light, which would turn it green so the kids aren't late for class. If you had a bright enough strobe which flashed at the same frequency...you get the idea.
That wikipedia article makes a whole lot more sense defining what the traffic light protocol is. At first I thought this was some kind of tech protocol that's implemented by a computer. Now I realized it's an informal protocol.
Readit News
I couldn't help but find that pointless. The conference is open to the public, the only barrier to entry being a small amount of money to purchase a ticket. How would that prevent bad actors from signing up to access the sensitive information?
It absolutely makes sense when used within an organization where access/membership is properly vetted, but there, I feel like there was no point.
A lot of these are borrowed from the US .gov in which prosecution is a relatively effective way to get compliance with these policies, but, and I'll take some license here, are copied to appear sophisticated by unsophisticated players outside of that.
In my experience doing security embargos/disclosures, it's a lot easier to just explicitly enumerate the set of people/organizational entities who should be given access to non-public information.
To make the parent’s point more obvious for people who are not used to a large enterprise context, concretely for example, at my workplace (which I would consider typical of a large organization) there are:
1) Regular employees and contractors who are employed by the main employer.
2) Employees who work for different legal entities from the main employer, have different sso domains handling their auth (and email domains for systems that do sharing protections via email) but are “really” part of the same company for security purposes. Think say people who came in as part of a merger but for various reasons their legal entity and brand needs to stick around so they have different auth, email etc.
3) People who work for actually different companies, have the same sso domains handling handling their auth and the same email domain as people in bucket 1 because we’ve given them logins and are working on sensitive security stuff (think: vendors and vendor contractors in the security or legal space)
4) People who work for actually different companies, have the same sso domains etc as bucket 1 and are not working on sensitive security stuff (think: vendors and vendor contractors everywhere else)
…and people sometimes move between groups 3 and 4 on a project by project basis. Notice all of these are “bound by common policies set by the organization” so all of them are in the “organization” for TLP at least by the second part of the definition, but 2,3 and 4 but don’t share a common affiliation by formal membership so are not part of the “organization” for the first half of the TLP definition.
So if I get a TLP:Amber document, who am I allowed to share it to? I should be sharing it to some of 1, 2 and 3 on a need to know basis. Most automated permission systems will allow me only to share it easily only with people in 1 and 3 or 4, and since people can move between 3 & 4 based on assignment it’s hard to know (and pretty much impossible to tell automatically) if some degree of access violation has occurred. People in 2 are generally sool if we’re trying to share things and I’m not prepared to handwave through the scary-looking “are you sure you want to share this with person x who isn’t from our org?” Boxes.
Basically explicit enumeration is just going to be way better any time you want to be doing this type of thing in the real world.
If I post my headshot to hire-an-actor.com, that's "Blue/Broadcast". If I share a picture of my kid blowing out birthday candles, that's "Green/Public". From "Green" you might be able to see the LABELS of my "Yellow" stuff and request access to it, but there should be no indication that "Red" or "Black" even exists.
So basically you as a user always operate at "Yellow", and can push "up" to Green (aka: discord), or Blue (aka: tweeter), and can unlock "Red" or "Black" via Password or 2FA/Cert.
I wish there were a way to easily "vivify" this, but at least putting names to it exposes where/how we're currently lacking.
The biggest issue still remains that content is "slippery" ... if it's not 10000% protected and airgapped, there's a chance that it can "escape".
Its NOT about controlling traffic lights. Some are networked ("synchronized") so it might be interesting to read about how that's done. https://en.wikipedia.org/wiki/Traffic_light_control_and_coor...
Dead Comment