A hacked Microsoft test account was assigned admin privileges
arstechnica.com
arstechnica.com
Groups and teams get created all over the place, with mysterious permissions, just so that you can play in Teams, or OneDrive, and these persist in the company directory almost indistinguishable from security groups.
Sometimes you get automated emails asking you if you still need something, but the messages are opaque, and in a really big company there's no-one you can really ask (helpdesk takes 2 days to get back to you, and what are you gonna do, hit up John Savill on Twitter?), so you hit ok and try to carry on.
Inevitably, the fabric starts to rend, and an attacker gets lucky at a weak spot and can jump sideways through the tenant to get what they want.
As a wise CISO once said, hackers dont break in, they log in.
Of course everyone is using (MS) cloud, skype, twitter one drive and what have you. It even throws some guy's name for good measure.
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.
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.
> 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 ...
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.
Perhaps on HN there are lots of people getting that FAANG salary but I'm not one of them. I'm not going to sacrifice my sanity and health for standard industry pay. If they pay average that is what they get. I recommend more people do the same, its part of why everyone is going insane nowadays, popping pills, therapy. Because they are fearfully trying to do the job of 20 people.
>prepare for the first "real fight"
> talk VIPs/whatever out of their temporary obsession
F that to h3ll and back. Not my responsibility unless I'm getting paid. The world would be getting better not worse if more people actually fought for their sanity rather than doing work for free. Paid or having a seat at the table, meaning actually having equal authority to the big whigs making hamfisted decisions that they don't understand. Too many people are in charge that should not be. Let them burn.
> forced to stop as it was "too embarrassing"
Exactly my point.
Its almost like security is some sort of ribbon campaign.
Anyone selling you security as a product is scamming you.
Regular people even don’t care about any security they just do their jobs.
There are also so many servers/applications/settings that you don’t have enough security aware employees to review everything.
If you look long enough any company at some point will have something open that should not be. That is what hacker groups do - they constantly look for an opening. They find these because company as it operates has to setup new servers new configurations all the time it is not set once and done.
Basically, we're experiencing the Windows XP security popup equivalent but at a service level, where at every step of a task you're asked to identify to something else and the back and forth to get the proper credentials with the proper rights can take days.
Support teams calling it fucks and throwing half the accounts and permission bucket at any newcomer is just humane.
Most of devs work is done in non prod environments so you can throw a lot of dev/test permission at them.
Support should be able to support through app permissions only.
Devops/oncall will need automated escalation requests for emergencies. A single “XP popup” that gets audited.
Elephant in the room is CI. I have no answer. I think CI needs a rethink. CI has a lot of power if hacked.
However, at most companies there is usually a hard thick line between production and test systems. Granting production access to a test account should be basically impossible, so how that happened should be what the investigation should focus on.
Also, TERRIBLE/HORRIBLE user access management and review. How do they let a test account be live for "months"? Don't they have some alerts for all test accounts in PROD environment to pester them daily??
(I keep ranting about the need of a strong and capable internal IT audit.. this is an alert that your IT audit SHOULD have set up for their Continuous Audit processes)
It's grade school stuff that they keep getting wrong.
Test pretty much always leads to prod.
MS security has put significant effort into tooling and best practice documentation to try and prevent these types of major screw-ups
M365 is quite bad at enforcing MFA, it's pay to play.
Access to everything means it was not a planned disclosure.
Also why does MS not design its systems to simply disallow one person to have such priviledges? They are attacked by state actors and have moles inside...
Is it 0%? Or more than 0? How much more?
Hard to say how often / what fraction of occurrences are never caught, or caught but never publicized.