And some sort of repository for the scripts (GIT, TeamServer, SVN, etc). On Wed, Apr 4, 2012 at 3:08 PM, Brian Desmond <[email protected]>wrote:
> *Aside from the security side of things in terms of process for issuing > the cert, don’t forget the timestamp server and to timestamp your > signatures. * > > * * > > *Thanks,* > > *Brian Desmond* > > *[email protected]* > > * * > > *w – 312.625.1438 | c – 312.731.3132* > > * * > > *From:* Steven Peck [mailto:[email protected]] > *Sent:* Wednesday, April 04, 2012 4:29 PM > > *To:* NT System Admin Issues > *Subject:* Re: Script signing ?**** > > ** ** > > We had a custom template for 'Code Signing' created by our security team > (they maintain the cert server stuff) but haven't had time to sit down and > actually implement it as a process because it's an IT wish list project and > we're a little buried at the moment. **** > > **** > > So the beginning of the structure is in place, just need to get time to > test, document and publisize it here.**** > > **** > > Steven Peck**** > > http://www.blkmtn.org**** > > > > **** > > On Wed, Apr 4, 2012 at 1:19 PM, Brian Desmond <[email protected]> > wrote:**** > > *I sign all my scripts with a commercial code signing cert. PowerShell in > particular by default requires this. If you have an internal PKI you should > be able to get a code signing cert off of there. They require some effort > to get commercially because of the risk involved in issuing something that > connotes a fairly high degree of trust.***** > > * ***** > > *IMO it’s a good practice. Most any script or binary that leaves my > computer gets signed. ***** > > * ***** > > *Thanks,***** > > *Brian Desmond***** > > *[email protected]***** > > * ***** > > *w – 312.625.1438 | c – 312.731.3132***** > > * ***** > > *From:* Christopher Bodnar [mailto:[email protected]] > *Sent:* Wednesday, April 04, 2012 2:49 PM > *To:* NT System Admin Issues > *Subject:* Script signing ?**** > > **** > > Anyone have to implement a policy regarding signed scripts due to an > internal or external audit? > > Had an internal audit recently and one of the "observations" was this: > > A script is a program written by an end user to execute an application. > It may be used for a variety of purposes, including logon scripts, > administration and general automation. A script executed by privileged > accounts creates security risks unless it is tightly controlled and > protected from unauthorized changes or malicious coding. A signed script > ensures the code was reviewed, approved and free from malicious coding. > Audit noted that administrators can execute unsigned scripts from any > workstation or server. Execution of a compromised script by an > administrator increases the risk that unauthorized access or > unauthorized changes on the network and data can occur > > With this as the "recommendation": > > Evaluate the feasibility of restricting administrators, administrative > workstation and domain controllers from executing unsigned scripts. > > So I've been looking at the feasibility of actually doing something like > this with combinations of Software Restriction Policies (certificate > policies) and possibly AppLocker. Which look to be a nightmare to try and > implement. The auditor has agreed to the following, which will be much less > intrusive: > > All scripts created by Domain Admins for Domain admins, going forward > would be signed > Creating a policy document > Creating documentation for the process > Training the admins on the new process > > Obviously nothing is enforcing this, but it's a start. Just wondered if > others have gone through something similar. > > > **** > > *Christopher Bodnar* > Enterprise Achitect I, Corporate Office of Technology **** > > Tel 610-807-6459 > 3900 Burgess Place, Bethlehem, PA 18017 > [email protected] **** > > > * > The Guardian Life Insurance Company of America* > * > *www.guardianlife.com **** > > > ----------------------------------------- This message, and any > attachments to it, may contain information that is privileged, > confidential, and exempt from disclosure under applicable law. If the > reader of this message is not the intended recipient, you are notified that > any use, dissemination, distribution, copying, or communication of this > message is strictly prohibited. If you have received this message in error, > please notify the sender immediately by return e-mail and delete the > message and any attachments. Thank you. **** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin**** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin**** > > ** ** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin**** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
<<image001.jpg>>
