-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At Mon, 25 Jun 2012 07:24:58 -0500, Mark McCullough wrote: > > I do audit response, trying to guess what the auditors will demand as a big > part of my job today, so please don't take this personally, more as > identifying areas auditors may need addressed. >
Not at all, Mark, I very much appreciate your feedback! > > You need to ensure you are maintaining at least four old passwords. > Password changes may not be done for one reason or another when a new one is > issued. Nothing is worse than a root password management system that you > can't use to get the root password. > Agreed. This functionality is planned [0]. > > What guarantee do you have that the hashes are actually deployed rather than > just leaving the root password on some insecure value? Even if it is just a > "Yes, I updated the root password and validated it" signoff for each system > with a person's name who did the work, something would need to be in place > to ensure it is the actual password. > Personally, I can't see implementing this without a configuration management system like puppet (or friends). It's not implemented yet, but what I plan to do is to provide for live audit using puppet's reporting capability (whereby nodes will report a hash of their root hash) so this can be compared with what credmgr *thinks* is deployed on the system. > > Password age will be key. There should be some framework (either political > or software) to ensure the password never actually gets beyond the maximum > age as defined by your organization. > Agreed, this functionality is planned [0]. > > What about people leaving the organization? The obvious answer with your > software is in such an event, issue a new password, but it is something that > needs to be kept in mind. Password change events aren't just the fixed > schedule of age. > Agreed, this functionality is planned [0]. > > An auditor will likely have a hard time with even encrypted email. It's a > reflex thing. If you use this with the intention of presenting to an > auditor, have an answer ready. > Well, short answer: yes. Long answer, this is *precisely* how the DNSSEC signing key for the root is protected. If it's good enough for ICANN, it *should* be good enough for an auditor. > > Outside your software, but be sure you have clearly defined properties on > who has access to that password. You could manage it from the encryption > keys, but have something to say that yes, this person is authorized. > I can give people a tool but I cannot write their corporate policies. I agree that this is equally vital. Hopefully anyone sufficiently clueful to manage root like this is aware that technical solutions *alone* aren't sufficient. > > Written before first cup of tea, so take this for mainly worth the electrons > allocated to send and display this. > Thanks again for your helpful feedback, Mark! I'm in the middle of moving house at the moment, so I can't promise when the next release will be...but soon. [0]: https://github.com/treyka/credmgr#todo Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, Sprl Trey Darley - Principal gpg fingerprint: C2AD E2A8 440C 8785 1958 B6DA 4176 9233 8F6D 8AF0 ++--------------------------------------------------------------------------++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/oqZAACgkQQXaSM49tivDjhwCZAQL1aWB/Ge1dmZZ388Yr8vyq juIAoJ9euUngLcLHDLqLppr9IDxSycCL =H+fn -----END PGP SIGNATURE----- _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
