Cleaning Up Dead Bodies in AWS IAM
noq.dev
noq.dev
i.e. was the VP trying to reduce risk? scale out responsibility for managing access?
Agree that leaders should definitely be ready to motivate stakeholders and collaborating teams to act on this kind of info before spending significant time gathering & producing it.
Don't launch any projects in a firm direction because if they fail, it's a failure of commission. Wastes lots of time churning what-if scenarios, blocking things & generating reports no one wants in case he gets asked for them, so he can't be accused of a failure of omission.
It's the 3d chess played by someone who forgets what their actual day job is - getting shit done.
They have context into why you are doing something, even if you don’t.
In many orgs measurement of work takes precedence over actually achieving work.
Large companies have huge inertia. And these days we also have low average CEO tenure and frequent executive position changes. The upshot being that what a given executive does can be almost entirely disconnected from productive improvement without notable short-term harm to the company. In that kind of an environment, an ambitious executive can put the bulk of their energies to seeming effective without much worry as to actual effectiveness. Or just to indulging their personal predilections, like feeling important or in control.
It's generally assumed/understood that the higher you go the more control you have, but conversely the slower any change you try to effect is. So it's sort of like the old 3 envelopes school of management joke. They get 6-12 months to settle in. Then they do a reorg to bring in their team over the next compensation cycle. Next compensation cycle their team brings in their teams, and so on. About 3 years in and then people may start taking a long hard look at the progress or lack thereof. Finally because C-suite doesn't commit fratricide, they are given a tap on the shoulder and managed out with a nice severance, a process that may take another year.
So I've been at shops where the guy at the CTO was clearly not succeeding, didn't have stakeholders buy-in, and lacked the grunts respect. Nonetheless they got 3-5 years of very fat paychecks during which they hobbled the entire org.
At the IC level I've seen people bounced within their 90 day probation.
Or worse. Yet what you just described is something I recently witnessed at a Fortune 5000. So I can corroborate your point of view entirely.
Also, I once was let go the day after coming back from Christmas vacation (planned, whole office was out) as well as let go once a couple weeks before Christmas. The more time you spend in the industry, the more BS like this you’ll come across. These incidents were 13 years apart, but it goes to show that it’s the same, no matter when.
It's depressingly easy to end up in a situation where the line employees are overworked and underpaid, the first level managers are stressed out trying to really manage well their half-dozen direct reports while still producing work themselves, and the Directors and VPs end up passing reports back and forth all day, every day.
Rather write some code than deal with a chickenshit leader who wants 100 iterations of project plans for work we will never do or generating reports that no one will ever read.
Being paid to sit at a computer and not doing real work all day is more torturous than simply having actual tasks and work to do.
Same with security groups. Gartner has some "best practice" doc somewhere, someone loads that into a security tool, the tool flags things, and these checkboxes must go from red to green. The technical hurdles to comply or actual value do not matter.
They try to tailor a lot of these things to the OS/distribution, but fail in the most wonderful ways.
A recent example: they're aware of RHEL. They're also aware of 'firewalld'.
However, they have not managed to realize that this is simply a management interface to other firewalls -- imposing standards on a long-deprecated backend; iptables
Meanwhile, using incredibly inefficient and 'portable' command lines. ie: using find in such a way that an LDAP query happens for every file
Refusing to use the arguments available to the operating system they 'tailor' for. Ultimately timing out once you hold a certain number of files.
I don't have a good example of the command, but it was basically looking for 'worldly' permissions that were too open. It's important to note the users/groups could be discarded/ignored.
They were using 'find ... -exec ls -ld {} \;', which does an LDAP lookup on each result to resolve UIDs and GIDs to names.
They could have made the process far more efficient with either the native '-ls' argument built into find, or adding '-n' to the exec'd 'ls'
Either would skip the name resolution/domain. At a certain number of results/files the expense is too high, causing the job to time out
I like to call what I do "taking the coward's way out" -- using FreeIPA
My team setup the infrastructure in question and I've been too slow to learn it. FreeIPA is nice for quick/easy deployments.
I'm not sure how well it "scales", but it's great for getting comfortable with the "Domain Language" (sorry, pun)
The 'ls' output is honestly superfluous, though - 'find' will report the paths.
I won't even get into how these are batched/time limited. If not this, it'd be something else eventually
I'm not up on EKS-ELB these days, but if the nodes only allow ingress to NodePorts from the ELB, then it seems like those findings should be suppressed in most orgs.
If the SecEng team was partnering with the delivery team they'd know that before sending the report.
Probably maps to the SAT / NP-complete space. Congrats! Management of security permissions is virtually guaranteed to be non-polynomial.
All other users should have been going through some SSO using Microsoft AD, Okta, etc.
We live in a noun hell where every technical topic has a high barrier to entry that makes it hard to casually learn anything. It's difficult to be even a traditional generalist in this ecosystem, and yet the market treats people as if the only way to be considered valuable is to be a super generalist (depth + breadth).
Besides, most such acronyms for classes of security tools don't actually mean much. They just represent the current flavor of the week in the security arms race.
That's the OPPOSITE of how you're supposed to use acronyms. If you're going to spell it out anyway, why not do it the first time you talk about it like you're supposed to?
I guess people do it to sound cool or something, but I once maintained a legacy project that had an acronym for a name. Not a single person working at the entire company knew what the acronym originally meant, and of course, it was never documented.
Until last week, I had never heard or read the term CNAPP.
"CNAPP is a term first coined by Gartner in 2021 to describe an all-in-one platform that unifies security and compliance capabilities to prevent, detect, and respond to cloud security threats. A CNAPP integrates multiple cloud security solutions that have been traditionally siloed in a single user interface, making it easier for organizations to protect their entire cloud application footprint."
Thanks, Gartner. What a racket they have as a self-ordained arbiter of market segments.
Then there are backronyms and names that used to be acronyms, but technically aren't anymore.
1: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ab...
2: (evidently deprecated but still parsed) https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ac...
Ideally we'd learn about other people's problems BEFORE they become our problems so we're prepared to deal with them. Or we can just want to expand our realm of knowledge.