4 ms·

AWS doesn't consider them sensitive, but some organizations do. My feeling is that I would rather avoid leaking any info about my AWS environments. Just because

AWS doesn't consider them sensitive, but some organizations do. My feeling is that I would rather avoid leaking any info about my AWS environments. Just because AWS doesn't think they can be dangerous doesn't mean someone else won't find a way.

abadpoli 3y ago
And those organizations are building their security model off of false assumptions, and are wrong.
- mschuster91 3y ago
  Defense in depth, always assume that anything can get used as an attack vector including AWS itself.
  - abadpoli 3y ago
    It’s not defense in depth to build your security model off of false assumptions, it’s just bad security.
    - laserlight 3y ago
      I don't understand your reasoning. Neither my name nor where I live nor my phone number nor my license plate are secrets. Yet I don't go around wearing a t-shirt with my personally identifying information printed on it. What am I missing?
      - elcomet 3y ago
        If you assume it is a secret, you might start to use it as an access key, or similar things. That's where the error is. You should assume it is public (but avoid publishing it yourself of course, that's defense in depth)
      - abadpoli 3y ago
        If you knew that there was an assassin out there trying to find you and cause you harm, would you consider “I don’t wear a t-shirt with my address on it” to be any form of protection against that assassin? If you want protection against that, you need to focus on better home security, hiring bodyguards, going to the police etc, and you’re better off assuming that the assassin will find your address regardless of whether or not you wear a t-shirt with it printed on. Put another way: there’s a difference between “I don’t do this thing” and “I rely on not doing this thing for my safety”. The second one makes a lot more assumptions than the first one does, and those assumptions can lead to problems if they are false assumptions.
        laserlight 3y ago
        > Put another way: there’s a difference between “I don’t do this thing” and “I rely on not doing this thing for my safety”. That was my point. The fact that some organizations consider AWS account IDs sensitive is independent of whether they rely on it being sensitive or not. I might have taken all precautions against an assassin attack, yet I won't make the assassin's job easier by announcing my PII to them. The fact that I won't announce my PII says nothing about whether I took the security precautions.
        abadpoli 3y ago
        If an organization considers it sensitive, that implies they’re putting some level of reliance on it being so. Otherwise there would be no point in considering it sensitive. There’s a difference between “making it easier for an attacker” and using it as a security control, even if it’s not the only security control. The point is that even if you don’t go around wearing a shirt with your address on it, that should never factor in to your designs for security. It should never be considered a security control, even a “defense in depth” one. In fact, your threat model should ideally ask the question “assume someone does walk around with a shirt with my address on it, will I still be safe?” That doesn’t mean you’re actually going to go do it, but if the answer is yes, that’s how you know you’ve done your job.
        3y ago
      - junon 3y ago
        If you place any sort of security assumptions on AWS account IDs into your threat model, you're effectively directly introducing a security vulnerability. If you're not then why include it into your security threat model to begin with? I believe that is their point. Since AWS does not, and has never, treated that information as secret, then there is absolutely no reason to consider it sensitive because there is no security guarantees with how AWS handles those IDs (as this article demonstrates). Thus, either you're including them into your threat model as sensitive and thus immediately opening up yourself to vulnerabilities (bad security), or you're not including them at all (and thus not treating them as sensitive/secret/whatever). The argument the parent had (and that I agree with) is that you should do the latter unless AWS provides a means to work with those IDs securely (it won't because they're not secrets).
        kube-system 3y ago
        This is a false dichotomy. There is a deep chasm between "publish everything", and "this is a secret", called operational security. Any time a topic like this comes up, there are people on this forum that try to apply the "security by obscurity does not work" principle to every security topic under the sun, when in reality, that principle really only applies to the world of cryptography. In meat space, where humans operate on plaintext, keeping a secret is a very valid approach to some topics. This is why things like NDAs exist.
        evandale 3y ago
        How is it possible for a user of AWS to keep the account ID secret if Amazon doesn't even consider it secret? If Amazon leaked your account ID they could point to their docs and say the account ID was never meant to be a secret, sensitive, or confidential.
        kube-system 3y ago
        You can walk over to the user's desk and ask them not to share it. Whether or not Amazon leaks it is unrelated to my employees' ability to follow instructions. There is a lot of data that exists in a space somewhere between "100% secret" and "100% public". This is one of those situations, for many organizations.
      - evandale 3y ago
        This is posted in other places but Amazon explicitly says they're not secret, sensitive, or confidential. https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html https://docs.aws.amazon.com/accounts/latest/reference/manage... > While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.
catlifeonmars 3y ago
I think making the assumption that account IDs won’t leak is the problem. It’s safer to assume that someone out there already has a directory of account IDs to buckets and that your efforts are better expended on other things, like actual secrets.

abadpoli 3y ago

And those organizations are building their security model off of false assumptions, and are wrong.

mschuster91 3y ago
Defense in depth, always assume that anything can get used as an attack vector including AWS itself.
- abadpoli 3y ago
  It’s not defense in depth to build your security model off of false assumptions, it’s just bad security.
  - laserlight 3y ago
    I don't understand your reasoning. Neither my name nor where I live nor my phone number nor my license plate are secrets. Yet I don't go around wearing a t-shirt with my personally identifying information printed on it. What am I missing?
    - elcomet 3y ago
      If you assume it is a secret, you might start to use it as an access key, or similar things. That's where the error is. You should assume it is public (but avoid publishing it yourself of course, that's defense in depth)
    - abadpoli 3y ago
      If you knew that there was an assassin out there trying to find you and cause you harm, would you consider “I don’t wear a t-shirt with my address on it” to be any form of protection against that assassin? If you want protection against that, you need to focus on better home security, hiring bodyguards, going to the police etc, and you’re better off assuming that the assassin will find your address regardless of whether or not you wear a t-shirt with it printed on. Put another way: there’s a difference between “I don’t do this thing” and “I rely on not doing this thing for my safety”. The second one makes a lot more assumptions than the first one does, and those assumptions can lead to problems if they are false assumptions.
      - laserlight 3y ago
        > Put another way: there’s a difference between “I don’t do this thing” and “I rely on not doing this thing for my safety”. That was my point. The fact that some organizations consider AWS account IDs sensitive is independent of whether they rely on it being sensitive or not. I might have taken all precautions against an assassin attack, yet I won't make the assassin's job easier by announcing my PII to them. The fact that I won't announce my PII says nothing about whether I took the security precautions.
        abadpoli 3y ago
        If an organization considers it sensitive, that implies they’re putting some level of reliance on it being so. Otherwise there would be no point in considering it sensitive. There’s a difference between “making it easier for an attacker” and using it as a security control, even if it’s not the only security control. The point is that even if you don’t go around wearing a shirt with your address on it, that should never factor in to your designs for security. It should never be considered a security control, even a “defense in depth” one. In fact, your threat model should ideally ask the question “assume someone does walk around with a shirt with my address on it, will I still be safe?” That doesn’t mean you’re actually going to go do it, but if the answer is yes, that’s how you know you’ve done your job.
        3y ago
    - junon 3y ago
      If you place any sort of security assumptions on AWS account IDs into your threat model, you're effectively directly introducing a security vulnerability. If you're not then why include it into your security threat model to begin with? I believe that is their point. Since AWS does not, and has never, treated that information as secret, then there is absolutely no reason to consider it sensitive because there is no security guarantees with how AWS handles those IDs (as this article demonstrates). Thus, either you're including them into your threat model as sensitive and thus immediately opening up yourself to vulnerabilities (bad security), or you're not including them at all (and thus not treating them as sensitive/secret/whatever). The argument the parent had (and that I agree with) is that you should do the latter unless AWS provides a means to work with those IDs securely (it won't because they're not secrets).
      - kube-system 3y ago
        This is a false dichotomy. There is a deep chasm between "publish everything", and "this is a secret", called operational security. Any time a topic like this comes up, there are people on this forum that try to apply the "security by obscurity does not work" principle to every security topic under the sun, when in reality, that principle really only applies to the world of cryptography. In meat space, where humans operate on plaintext, keeping a secret is a very valid approach to some topics. This is why things like NDAs exist.
        evandale 3y ago
        How is it possible for a user of AWS to keep the account ID secret if Amazon doesn't even consider it secret? If Amazon leaked your account ID they could point to their docs and say the account ID was never meant to be a secret, sensitive, or confidential.
        kube-system 3y ago
        You can walk over to the user's desk and ask them not to share it. Whether or not Amazon leaks it is unrelated to my employees' ability to follow instructions. There is a lot of data that exists in a space somewhere between "100% secret" and "100% public". This is one of those situations, for many organizations.
    - evandale 3y ago
      This is posted in other places but Amazon explicitly says they're not secret, sensitive, or confidential. https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html https://docs.aws.amazon.com/accounts/latest/reference/manage... > While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.

catlifeonmars 3y ago

I think making the assumption that account IDs won’t leak is the problem. It’s safer to assume that someone out there already has a directory of account IDs to buckets and that your efforts are better expended on other things, like actual secrets.