5 ms·

The trouble with blog posts like this is that they are effectively click-bait written to drive traffic to a blog (i.e. aiming to ensure high ranking on search).

The trouble with blog posts like this is that they are effectively click-bait written to drive traffic to a blog (i.e. aiming to ensure high ranking on search). I say that because taking this blog post as an article, it makes one major false assumption: Credential Leakage = Compromise. In reality, anyone who knows AWS IAM knows that you can: - Activate/Deactivate credentials - Time-gate policies - IP-restrict policies - Use roles with STS temporary credentials - Use roles in conjunction with the externalId attribute - Many more things I've missed out.... Yes sure you probably should rotate your credentials yada yada (or perhaps use the "new" X.509 auth method instead). But that doesn't detract the fact that this blog is making a cheap-shot and not really taking into account the strengths of AWS IAM in terms of the security granularity that make it possible (with a correct, layered config) to comfortably say Credential Leakage DOES NOT equal Compromise. You just need to take a minute to RTFM and sit down and plan your IAM setup, instead of just doing it on a whim. AWS IAM is actually one of the best bits of AWS. Its one of the areas where AWS leads in comparison to its competitors (IMHO).

uptownfunk 4y ago
What’s a good guide to learn IAM?
- mdaniel 4y ago
  It's still early access, but I bought a copy of https://awsiamguide.com/ https://awsiamguide.com/ and I think it has potential
bagels 4y ago
It seems like a straw man to argue that leakage isn't the same as a compromise. Leakage of credentials sure has led to quite a few compromises.
- traceroute66 4y ago
  > Leakage of credentials sure has led to quite a few compromises. No. As per my post above, they "led to compromise" because lazy syadmins have been too inept to RTFM and make full use of IAM. I mean, I could post my IAM credentials right here. I've even been lazy and haven't rotated them for 5 years (yes I've already slapped myself on the wrist !). But they'll be naff all use to you because: - My credentials are deactivated when I'm not using them. - The STS policies they are linked to are IP-restricted - The Role policies they are linked to are also IP-restricted - The Role policies have minimal necessary privilege - The Role policies can only be invoked be an assumed role - The Roles have externalID attribute set using a UUID as value Thus even if I copy/pasted my credentials right here, you wouldn't even get past step 1 let alone any further. And that's just a simple example. You can go much more layered and granular than that. Its not rocket science, its not difficult, its just a case of the old PPPPPP (Prior Planning Prevents P* Poor Performance).
  - iampims 4y ago
    Share them then.
  - philsnow 4y ago
    We can't expect everybody to get to the level of understanding you have about the fine points of AWS IAM. It's a scalpel shotgun, an extremely sharp tool that can easily blow your company's entire leg off. Companies generally totter along until about 50 engineers / 100 employees before hiring a single security-focused engineer. When those first few security engineers come on board, you can bet they'll have a backlog of at least several months' if not a couple years' worth of research and remediation before they get anywhere near taming the company's IAM setup. The vast majority of companies are small and probably aren't where they need to be in terms of IAM practices. AWS adoption has become a lot more mainstream among companies. 10 years ago it was almost a secret weapon for forward-thinking (and VC-money-burning) companies that let them out-scale competitors. Unfortunately their defaults, documentation, guard rails, etc are still set up for those bleeding-edge, hyper-competent, top-0.01% companies.
    - 4y ago
gw99 4y ago
What's even worse is that IAM and Trusted Advisor will tell you what stupid things you have done. At no point does their article give guidance in turning that on. Because it compromises their sales pitch. Also if you push AWS keys into github (this does happen from time to time at the best organisation), github will nuke the rev. And even if you did it successfully there should be no damn keys which are usable because anything human issued should be via SSO and windowed or have MFA required set up. Everything else should be assume role based.
- christophetd 4y ago
  Hello! One of the authors here. We did release some (hopefully) actionable guidance alongside the study[1]. Trusted Advisor is a fair point, but note that most of its security checks only come with the Business or above AWS support plan. IAM Access Analyzer is a great service but it currently supports only 6 resource types[2]. We'll look into adding both, appreciate the feedback! [1]: https://securitylabs.datadoghq.com/articles/state-of-aws-cloud-security-followup/ https://securitylabs.datadoghq.com/articles/state-of-aws-clo... [2]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...
  - cloudy_future 4y ago
    "most of its security checks only come with the Business or above AWS support plan" Another fair point is Datadog also charges for its product.
    - christophetd 4y ago
      Sure. My point is that Trusted Advisor is also a commercial product, as opposed to IAM Access Analyzer which is free.
- electroly 4y ago
  FWIW all the interesting checks in Trusted Advisor (literally 100% of the good ones) are gated behind an AWS Support contract. We don't use Trusted Advisor because it's useless without a support contract, and as a small company we don't want to pay for a support contract that we don't otherwise need. I think it's not so great that AWS charges for these automated checks.

uptownfunk 4y ago

What’s a good guide to learn IAM?

mdaniel 4y ago
It's still early access, but I bought a copy of https://awsiamguide.com/ https://awsiamguide.com/ and I think it has potential

bagels 4y ago

It seems like a straw man to argue that leakage isn't the same as a compromise. Leakage of credentials sure has led to quite a few compromises.

traceroute66 4y ago
> Leakage of credentials sure has led to quite a few compromises. No. As per my post above, they "led to compromise" because lazy syadmins have been too inept to RTFM and make full use of IAM. I mean, I could post my IAM credentials right here. I've even been lazy and haven't rotated them for 5 years (yes I've already slapped myself on the wrist !). But they'll be naff all use to you because: - My credentials are deactivated when I'm not using them. - The STS policies they are linked to are IP-restricted - The Role policies they are linked to are also IP-restricted - The Role policies have minimal necessary privilege - The Role policies can only be invoked be an assumed role - The Roles have externalID attribute set using a UUID as value Thus even if I copy/pasted my credentials right here, you wouldn't even get past step 1 let alone any further. And that's just a simple example. You can go much more layered and granular than that. Its not rocket science, its not difficult, its just a case of the old PPPPPP (Prior Planning Prevents P* Poor Performance).
- iampims 4y ago
  Share them then.
- philsnow 4y ago
  We can't expect everybody to get to the level of understanding you have about the fine points of AWS IAM. It's a scalpel shotgun, an extremely sharp tool that can easily blow your company's entire leg off. Companies generally totter along until about 50 engineers / 100 employees before hiring a single security-focused engineer. When those first few security engineers come on board, you can bet they'll have a backlog of at least several months' if not a couple years' worth of research and remediation before they get anywhere near taming the company's IAM setup. The vast majority of companies are small and probably aren't where they need to be in terms of IAM practices. AWS adoption has become a lot more mainstream among companies. 10 years ago it was almost a secret weapon for forward-thinking (and VC-money-burning) companies that let them out-scale competitors. Unfortunately their defaults, documentation, guard rails, etc are still set up for those bleeding-edge, hyper-competent, top-0.01% companies.
  - 4y ago

gw99 4y ago

What's even worse is that IAM and Trusted Advisor will tell you what stupid things you have done. At no point does their article give guidance in turning that on. Because it compromises their sales pitch. Also if you push AWS keys into github (this does happen from time to time at the best organisation), github will nuke the rev. And even if you did it successfully there should be no damn keys which are usable because anything human issued should be via SSO and windowed or have MFA required set up. Everything else should be assume role based.

christophetd 4y ago
Hello! One of the authors here. We did release some (hopefully) actionable guidance alongside the study[1]. Trusted Advisor is a fair point, but note that most of its security checks only come with the Business or above AWS support plan. IAM Access Analyzer is a great service but it currently supports only 6 resource types[2]. We'll look into adding both, appreciate the feedback! [1]: https://securitylabs.datadoghq.com/articles/state-of-aws-cloud-security-followup/ https://securitylabs.datadoghq.com/articles/state-of-aws-clo... [2]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...
- cloudy_future 4y ago
  "most of its security checks only come with the Business or above AWS support plan" Another fair point is Datadog also charges for its product.
  - christophetd 4y ago
    Sure. My point is that Trusted Advisor is also a commercial product, as opposed to IAM Access Analyzer which is free.
electroly 4y ago
FWIW all the interesting checks in Trusted Advisor (literally 100% of the good ones) are gated behind an AWS Support contract. We don't use Trusted Advisor because it's useless without a support contract, and as a small company we don't want to pay for a support contract that we don't otherwise need. I think it's not so great that AWS charges for these automated checks.