4 ms·

> Kevin Beaumont—a researcher and security professional with decades of experience, including a stint working for Microsoft—pointed out on Mastodon that the onl

> Kevin Beaumont—a researcher and security professional with decades of experience, including a stint working for Microsoft—pointed out on Mastodon that the only way for an account to assign the all-powerful full_access_as_app role to an OAuth app is for the account to have administrator privileges. “Somebody,” he said, “made a pretty big config error in production.” Without knowing details of the system: That would not seem to be the problem, and I'm surprised someone with expertise would say it is. There should be no way for someone to make that error. Whoever designed it and whoever administers it should have made it impossible; they would be responsible. If you build and operate a factory with a button that electrocutes everyone inside, and someone mistakenly presses that button, it's clear where the problem is.

skywhopper 3y ago
How do you suggest they make config errors “impossible”?
- wolverine876 3y ago
  Don't make it a configuration option, restrict the option to only very specific conditions, require multiple approvals and verifications, limit the duration of the configuration (e.g., it disables after 7 days unless reset), audit it, etc etc.
citizenpaul 3y ago
I doubt the problem is technical. There probably were 20 best practices and safeguards in place to prevent it technically. The problem is guardrails and best practices only matter if they are cared about by the organization/leadership/bureaucracy. I've been told to give super admin/root rights to VIPs that had no business with such things many times over the years even though it overrode all policy/procedure/regulation/law. Its also compounded by every job is a cross-cross-cross-parttimecross-cross-dualrole-trirole job these days. I've seen role based controls that had more roles than actual permissions that were possible to grant so the entire point of the RBAC was self defeating. It was actually less time to simply grant permissions individually but of course that meant the reports would not show roles so it was not allowed. That doesn't come from the tech people that comes from poor leadership. On a side note I once designed an add on to a RBAC permission system to overcome this problem for an in house ERP. We had a permission type called "Permission Exception" If someone needed a permission outside of their role they got it assigned this way so a report could be generated that showed everyone that could do things outside of a job role. I've never seen it anywhere else. All it did was add a flag to the permission but it worked. HR would check the permission exceptions every quarter and see what needed removed from people. It kept the permissions in check by actual knowledgeable authority rather than some part time help desk position trying to cluelessly trial error untangle permissions.
- wolverine876 3y ago
  Yes, that's what I was saying, though it could be technical management. Whoever configured it that way may have been put in a position to fail. > I've been told to give super admin rights to VIPs that had no business with such things many times over the years even though it overrode all One can establish the power to say 'no', at least in many places. The systems are your work domain (depending on your job title); you can make clear that outsiders are not permitted inside. An essential is to establish credibility: 'Leave it to me - stay off my turf - and it will get done.' When they say the VIP needs something, find out what they really need and deliver that with amazing promptness and reliability (i.e., no saying later, 'oh, I didn't think of that!'). Everyone will be happy and impressed. It also gives the impression that what you say is serious - you really mean that these security issues are serious. If you go along with the request, you convey that it's just talk. Easily said in a comment, much harder to do of course. But remember that if you follow their instructions, and stuff goes wrong, it's your fault - your name is on the systems; the failures and successes are your reputation; and also you were supposed to advise them ...
  - csydas 3y ago
    > An essential is to establish credibility: 'Leave it to me - stay off my turf - and it will get done.' When they say the VIP needs something, find out what they really need and deliver that with amazing promptness and reliability (i.e., no saying later, 'oh, I didn't think of that!'). Everyone will be happy and impressed. I do agree that this is necessary, but I would add that for more effective policy, there needs to be (semi-)public demonstrations of those with higher titles actively refusing excessive access rights beyond their scope so that everyone can see the commitment to the security practices. We started this in a previous org and it was as simple of statements as when someone offers to give additional access rights to someone who really doesn't need it, the someone declines with the reasons: - It's a security risk to give out too many permissions - [The someone] shouldn't have that access anyways, it should always be gated This made it a lot easier to talk VIPs/whatever out of their temporary obsession with higher privileges as there was just an established social norm that the right thing to do is not to seek more access rights than are absolutely needed. Along with a very strong enforcement of change management on access rights that required very publicly visible documentation for such changes, it just got a lot easier to make the social cost of persons wanting access rights they didn't need too expensive for the VIPs/whatever -- none of them wanted to be the person in the change management report that got flagged for requesting access for frivolous reasons. For a short time we even levied the results of phishing email test emails against such VIPs/whatever as a demonstration that they really do need restricted rights, though this was forced to stop as it was "too embarrassing" for some of the VIPs/whatevers who had a horrible track record with phishing emails. It's very simple to introduce, but enforcement just takes some time and a few potentially awkward conversations at first to prepare for the first "real fight" over access rights.

skywhopper 3y ago

How do you suggest they make config errors “impossible”?

wolverine876 3y ago
Don't make it a configuration option, restrict the option to only very specific conditions, require multiple approvals and verifications, limit the duration of the configuration (e.g., it disables after 7 days unless reset), audit it, etc etc.

citizenpaul 3y ago

I doubt the problem is technical. There probably were 20 best practices and safeguards in place to prevent it technically. The problem is guardrails and best practices only matter if they are cared about by the organization/leadership/bureaucracy. I've been told to give super admin/root rights to VIPs that had no business with such things many times over the years even though it overrode all policy/procedure/regulation/law. Its also compounded by every job is a cross-cross-cross-parttimecross-cross-dualrole-trirole job these days. I've seen role based controls that had more roles than actual permissions that were possible to grant so the entire point of the RBAC was self defeating. It was actually less time to simply grant permissions individually but of course that meant the reports would not show roles so it was not allowed. That doesn't come from the tech people that comes from poor leadership. On a side note I once designed an add on to a RBAC permission system to overcome this problem for an in house ERP. We had a permission type called "Permission Exception" If someone needed a permission outside of their role they got it assigned this way so a report could be generated that showed everyone that could do things outside of a job role. I've never seen it anywhere else. All it did was add a flag to the permission but it worked. HR would check the permission exceptions every quarter and see what needed removed from people. It kept the permissions in check by actual knowledgeable authority rather than some part time help desk position trying to cluelessly trial error untangle permissions.

wolverine876 3y ago
Yes, that's what I was saying, though it could be technical management. Whoever configured it that way may have been put in a position to fail. > I've been told to give super admin rights to VIPs that had no business with such things many times over the years even though it overrode all One can establish the power to say 'no', at least in many places. The systems are your work domain (depending on your job title); you can make clear that outsiders are not permitted inside. An essential is to establish credibility: 'Leave it to me - stay off my turf - and it will get done.' When they say the VIP needs something, find out what they really need and deliver that with amazing promptness and reliability (i.e., no saying later, 'oh, I didn't think of that!'). Everyone will be happy and impressed. It also gives the impression that what you say is serious - you really mean that these security issues are serious. If you go along with the request, you convey that it's just talk. Easily said in a comment, much harder to do of course. But remember that if you follow their instructions, and stuff goes wrong, it's your fault - your name is on the systems; the failures and successes are your reputation; and also you were supposed to advise them ...
- csydas 3y ago
  > An essential is to establish credibility: 'Leave it to me - stay off my turf - and it will get done.' When they say the VIP needs something, find out what they really need and deliver that with amazing promptness and reliability (i.e., no saying later, 'oh, I didn't think of that!'). Everyone will be happy and impressed. I do agree that this is necessary, but I would add that for more effective policy, there needs to be (semi-)public demonstrations of those with higher titles actively refusing excessive access rights beyond their scope so that everyone can see the commitment to the security practices. We started this in a previous org and it was as simple of statements as when someone offers to give additional access rights to someone who really doesn't need it, the someone declines with the reasons: - It's a security risk to give out too many permissions - [The someone] shouldn't have that access anyways, it should always be gated This made it a lot easier to talk VIPs/whatever out of their temporary obsession with higher privileges as there was just an established social norm that the right thing to do is not to seek more access rights than are absolutely needed. Along with a very strong enforcement of change management on access rights that required very publicly visible documentation for such changes, it just got a lot easier to make the social cost of persons wanting access rights they didn't need too expensive for the VIPs/whatever -- none of them wanted to be the person in the change management report that got flagged for requesting access for frivolous reasons. For a short time we even levied the results of phishing email test emails against such VIPs/whatever as a demonstration that they really do need restricted rights, though this was forced to stop as it was "too embarrassing" for some of the VIPs/whatevers who had a horrible track record with phishing emails. It's very simple to introduce, but enforcement just takes some time and a few potentially awkward conversations at first to prepare for the first "real fight" over access rights.