> How large of an application base are you using > certificate-based policies with? Well, for a reasons aready mentioned by Darren and Susan, I don't use SRP. My point was just to point out what I think could be a barrier for hash-based SRP as a global workstation lockdown mechanism.
--Al > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Clay, Justin (ITS) > Sent: Tuesday, February 14, 2006 10:42 PM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] Hash-based Software Restriction Policy > > > Alexander, > > I have to agree that in all honestly I'll probably not be > able to use the HASH policy in the way that I'd like. You're > right that it'll likely just be too much administrative > overhead to hash new executables constantly - every month at > least just for MS patches. > > Given your input and the more time I've thought about it, > certificate policies seem like a better fit. My only concern > would be some of the strange 3rd-party applications we have > (like the catalog software at the Public Libraries) which are > supported by very small vendors that might not spend the time > or money to sign their packages. > > How large of an application base are you using > certificate-based policies with? Is it a basic install with > just Windows and Office? How do you get the certificates? > > Thanks for your input! > > -Justin > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Alexander Suhovey > Sent: Tuesday, February 14, 2006 1:02 PM > To: Alexander Suhovey > Subject: RE: [ActiveDir] Hash-based Software Restriction Policy > > > I wonder if this approach would work in modern hostile > environment where patches just keep coming. Don't you think > that locking down > workstation(s) > in this way will put a great deal of additional work to the > change management process? In case you don't have one you'll > really need it. > You > see, with every change (patches and updates for OS and > software) of binary base on your clients first you will need > to find out changed binaries, add new hashes (including those > of setup files) to GPO, then wait for policy to propagate, > and only after that you can start making actual changes. And > this is all in addition to your usual QA process for changes. > Sounds like quite a lot of work to me. > I'd use Certificate policies instead. MS as well as major sw > vendors usually sign executables. By using certificate > policies you achieve at least same level of security as with > hashes and guess what - you don't need to maintain a huge > and ever growing list of hashes, just a few software signing > certificates you trust. As for executables that are not > signed, you can always use your own certificate trusted by > your clients. > > Don't get me wrong, I'm not trying to say that hash-based > software restriction policy is evil, its beautiful. I'm just > curious if it is worthy and workable in real corp. > environments. Anyone? > > --Al > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > Clay, > > Justin (ITS) > > Sent: Monday, February 13, 2006 10:27 PM > > To: activedir@mail.activedir.org > > Subject: [ActiveDir] Hash-based Software Restriction Policy > > > Hey All, > > > > > I was curious if any of you have set up hash-based > software > restriction policies. I'd like to set up a policy > to only > allow the executables that I've hashed to run, and > I'm hoping > that someone has a list of all of the base > executables I'll > need to hash just for WinXP to boot and > log in successfully. > Hopefully someone else has already > done the work, so that I > don't have to use trial and error > to figure out all the exe's > I need to hash. > > > > > Thanks, > > > > > Justin Clay > > ITS Enterprise Services > > Metropolitan Government of Nashville and Davidson County > Howard > > School Building > > Phone: (615) 880-2573 > > > > > > > ITS ENTERPRISE SERVICES EMAIL NOTICE The information > > > contained in this email and any attachments > is > confidential and may be subject to copyright or other > > intellectual property protection. If you are not the intended > > recipient, you are not authorized to use or disclose this > > information, and we request that you notify us by reply mail > > or telephone and delete the original message from your mail system. > > > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > ITS ENTERPRISE SERVICES EMAIL NOTICE > > The information contained in this email and any attachments > is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended > recipient, you are not authorized to use or disclose this > information, and we request that you notify us by reply mail > or telephone and delete the original message from your mail system. > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
