That was a little bit too easy. (Thanks!)
On Tue, Apr 26, 2016 at 8:49 PM, Susan Bradley <sbrad...@pacbell.net> wrote: > http://www.patchmanagement.org/ > > Go there and sign up. > > > On 4/26/2016 5:31 PM, Richard Stovall wrote: > >> <Thread hijack> >> >> How does one subscribe to the fabled patch management list? >> >> </> >> >> On Tue, Apr 26, 2016 at 7:59 PM, Andrew S. Baker <asbz...@gmail.com >> <mailto:asbz...@gmail.com>> wrote: >> >> From the article: >> >> /*>>For instance, we recommend using system monitoring tools that >> present users with information about the last login attempt, so >> they can see if they’re responsible for failed login attempts. << >> */ >> Do they really believe that if users are inconvenienced by >> password changes every 30 or 60 or 90 days, that they'll actually >> bother to match up their activities with information that >> indicates last login of the system? >> >> The fact that they could not point to an improved security posture >> by their new stance indicates its weakness. Let's see if they >> feel the same way about it in 5 or 6 months. >> >> The fact is, we are at a good point in computing history to go >> with changing passwords, since so many online services are doing >> it. Back when people only had an eternal bankcard pin and a >> changing corporate password, it would be easy to see how the >> changing password would be a huge annoyance. >> >> Today? Let's see how many users feel that identity theft is a >> worthwhile trade-off for password changing convenience, after they >> experience the former. >> >> If user convenience is the paramount consideration for information >> security, then it's hard to see what other authentication and >> authorization options will be deemed acceptable. >> -- Two-factor? Inconvenient. >> -- Digital certificates? Inconvenient. >> >> Reducing the scope of exposure is the primary purpose of changing >> passwords. >> >> */>>The new password may have been used elsewhere, and attackers >> can exploit this too.<< /* >> >> A. Pure Speculation. >> B. There's nothing to prevent the current password from being used >> somewhere else, too. Frankly, if the next password a user selects >> is used somewhere else, then there is an equal chance that they >> will use their current password on the next service that they sign >> up for. They are just employing poor password hygiene and they are >> not only going to do so if the corporate password changes. >> >> >> */>>The new password is also more likely to be written down, which >> represents another vulnerability. <</* >> >> For any user that is likely to write down their next password, >> they are also likely to be reusing passwords across sites. See >> previous point. >> >> This means that their poor password practices are *already* >> endangering the current environment. >> >> >> */>>New passwords are also more likely to be forgotten, and this >> carries the productivity costs of users being locked out of their >> accounts, and service desks having to reset passwords.<</* >> >> >> Whine, whine, whine. The deployment of a self-service password >> portal eliminates this risk, and is not an uncommon solution. >> >> >> What has been offered here is not a reason or a set of reasons, >> but a set of ill-considered excuses. >> >> Anyhoo, it will be interesting what their guidance is next year... >> >> >> >> Regards, >> >> ***ASB* >> **_http://XeeMe.com/AndrewBaker <http://xeeme.com/AndrewBaker>_ >> >> ***Providing Expert Technology Consulting Services for the SMB >> market…* >> >> * GPG: *1AF3 EEC3 7C3C E88E B0EF 4319 8F28 A483 A182 EF3A >> >> >> >> On Mon, Apr 25, 2016 at 6:56 PM, Dave Lum <l...@ochin.org >> <mailto:l...@ochin.org>> wrote: >> >> Anyone see the debate on the Patch management list, driven by >> this: >> >> https://www.cesg.gov.uk/articles/problems-forcing-regular-password-expiry >> >> I don’t even know how it’s a debate other than the desired >> frequency (no one-size-fits-all on that IMO). Even six months >> is far better than never. With expiring passwords you at bare >> minimum mitigate employee’s that leave. >> >> *David Lum* >> >> */Systems Administrator III/** >> **P:**503.943.2500 <tel:503.943.2500>** >> **E:**l...@ochin.org <mailto:l...@ochin.org>** >> **A:**1881 SW Naito Parkway, Portland, OR 97201*** >> >> >> Facebook Link <https://www.facebook.com/OCHINinc>Twitter Link >> <https://twitter.com/ochininc>Linkedin Link >> <http://www.linkedin.com/company/ochin>www.ochin.org >> <https://www.ochin.org/> >> OCHIN email >> >> Attention: Information contained in this message and or >> attachments is intended only for the recipient(s) named above >> and may contain confidential and or privileged material that >> is protected under State or Federal law. If you are not the >> intended recipient, any disclosure, copying, distribution or >> action taken on it is prohibited. If you believe you have >> received this email in error, please contact the sender with a >> copy to complia...@ochin.org <mailto:complia...@ochin.org>, >> delete this email and destroy all copies. >> >> >> >> > > >
