It may be a surprise to some that after years and years of being told to rotate secrets on a periodic basis (change your password every 60 days), NIST suddenly admitted they were wrong and changed the recommendation in June 2017 in NIST Special Publication 800-63. Few companies implemented these changes and I am not sure if reluctance is from lack of awareness or confusion. It is hard to argue against the logic that brought about the change, however.
There is little consistency in calculating the strength and determining policy. Throwing fuel on the burning problem is a number of vendors and IAM professionals hooked on rotation solutions and simply not willing to accept the changes to their market until forced. To add fuel to the fire of confusion, there is no consistency in how strong is a secret. NIST Special Publication 800-57 talks of “cryptoperiods” and was written by different people originally a year earlier. Today its seems both an indicator of the change to come and somewhat in conflict. Then there other standard organizations in other countries and even in the USA, with their own standards often in conflict with NIST, making it a daunting task to determine your organizational strategy and how you can be compliant. Take Thycotic, and howsecureismypassword return very different results for the same password. What kind of computer is this based on anyhow?
Arguably it is an audit that usually pushes companies to adopt best practices when they fail to change themselves. Ironic, since almost every company will tell you that an audit does not drive its security strategy. I personally expected auditors to give it about 12-18 months then start writing up companies that have failed to update their secret policies to the new guidelines. Why? Because I could not agree more with NIST that the risk of a secret being compromised is highest during the task of rotation. Did your parents not tell you not to open the oven to check on the Soufflé? Why if the password will take 600 years to crack, are we rotating it every 90 days unless we worried that it was revealed or compromised and if so, where was that likly to happen?
There are some clear guidelines on where to put effort to secure secrets, instead of setting up complex time based periodic rotation.
1) Start with an original secret. https://haveibeenpwned.com/ offers a means to check if the password was previously compromised and there a lot of credential stuffing files around. Any time a password is chosen, check it against as large a list as possible. Include passwords unique to your company that should never be used, like the CEO name, the office or the company name. Tough when you rotate them constantly. I have found companies with thousands of identical hashes in their active directory because the same password was issued by some team creating credentials. These accounts are then not used or never rotated.
2) Pick a strong one. Base the strength on the risk and importance of what it is protecting and ensure that it is capable of surviving longer than the service. Use a cert or key if you can as the length and strength of these are usually far superior to passwords. This is especially true for API's and NPID's. Let's not make this about length, but strength and err on the side of super strong.
3) Store it correctly – Every time I hear of a breach that includes unencrypted passwords being stolen, I cringe. Forcing a password change, then storing it in a simple database table encrypted with reversible encryption is not secure. These breaches came from a credential store that was poorly thought out, and no amount of rotating will protect them.
4) Rotate as needed. This is not periodically, but if there is a reason for concern. If hashed by SHA1 or some other protocol no longer considered secure or if there is any concern that it has been compromised. We rotate passwords in PAM to ensure non-repudiation. The question to ask is, is is the secret safe per 1,2,3 above or are you forced to assume the risk of rotating it.
5) Secure the creation and rotation process. I cannot count how many companies have raised concern about the security of their credentials in SaaS or other cloud-based services as secrets should need higher security, then email passwords via outlook and O365 when they create an account, to a team mailbox protected by a poor strength password and archived and stored with regular email. Remember the risk is highest during the task of rotation.
Of course as much as possible, please use more than a secret alone. For example MFA, One Time Passwords (OTP), Biometrics, ABAC or some other form of policy-based access controls that leverage attributes known and stored in your IBoR. Using 1 attribute (a secret) is never as strong as using multiple for identity verification. This includes limiting the from where, at what times, and the means of use. Lastly, UEBA, when used with these identity attributes, can be extremely powerful in identifying the need to rotate a secret.
No comments:
Post a Comment