Hey Tyler, If you didn't pass an audit, and if you havent already, perhaps grab the necessary documentation and ensure you modify your policies so they align for your next attempt at certification.
Alot of the risk-treatments are best practice anyway, so you will have a secure network and be confident of being able to pass your next attempt. I'd also tier your network rather than it being flat, to give you some defence-in-depth should another of your controls fail. Implementing the audit controls, advice from here, and other best practices, you'll be well on your way.. Regarding best-practice stuff, everyone has their favourites, but look at the NIST guides for hosts, Team Cymru has excellent guides for network gear. I'm not sure if i've come across something specific to mobile devices, but storage encryption would be a must for lost devices, protocol encryption, password enforcement, etc.. Perhaps others can comment on their favourite sources of best-practice documentation.. Hope it helps. Chris. On Sat, Aug 14, 2010 at 3:36 AM, Tyler Robinson <[email protected]> wrote: > Wow again thanks so much everyone for the wonderful ideas I am starting the > planning phase on this and really appreciate the input seriously this is the > greatest mailing list with the smartest people in the industry well just my > bias opinion but thanks, one thing to throw into this well we are on the > topic, what is everyone using as a baseline or local hardening policy or > guideline to follow and are there premade templates or images that have > worked for anyone, I hate reinventing the wheel if there is good resources > for hardened images I have several hundred mobile devices to start working > on not to mention the new purchaces that keep coming in, I would like to > have a default local gpo or maybe an image that is prehardened to make this > more streamline but maybe I am just a lazy sys admin not wanting to do all > this work. Well again thanks everyone and if anyone has any other ideas I am > still testing please don’t hold out. If I ever see any of you at one of the > cons remind me I owe you a Beer or ten. > > Thanks, > > TR > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Jody & Jennifer > McCluggage > Sent: Thursday, August 12, 2010 8:09 PM > > To: 'PaulDotCom Security Weekly Mailing List' > Subject: Re: [Pauldotcom] Secure Remote Connections > > > > I agree with basically everything that everyone has said. Here are my > suggestions: > > > > 1. On the notebook computers, if using Windows, use Windows 7 Ultimate > or Enterprise to get BitLocker whole volume encryption. I know there are > many fine 3rd party software that can do whole volume encryption but the > benefit of BitLocker is that you can configure it to be totally transparent > to the end-user (no needing to have the end-user enter a separate password > to decrypt) and has Active Directory support. > > 2. Use Active Directory to centrally enable, configure, and enforce > the Windows Firewall. > > 3. Use a VPN solution that can leverage your domain active directory. > That way your users can log on with their domain credentials and you can > centrally control their access. If using Windows 2008, you can try to also > leverage its built in NAP to ensure that the remote users machine meet an > acceptable baseline before granting access. > > 4. If possible, use a solution that does not require the end user to > run with local administrator rights. It takes a bit of work to work out all > the kinks (it is a bit easier to do now with Vista/7) but in my opinion well > worth it. A knowledgeable end-user with local administrator rights can > undue all your best intentions. It will also limit damage that malware can > inflict (of course not eliminate them. Any malware will still have access > to whatever the user has but would protect system files and registry > settings only accessible to admin) > > > > Well that is my opinion at least. Good luck. > > > > Jody > > > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Jack Daniel > Sent: Wednesday, August 11, 2010 10:18 PM > To: PaulDotCom Security Weekly Mailing List > Subject: Re: [Pauldotcom] Secure Remote Connections > > > > My answer to most things remote-access related is OpenVPN. Make the users > establish the VPN connection, and tunnel whatever they need through that > (don't allow any direct access to resources over the Internet). Tie OpenVPN > authentication to your domain, add granular rules by user, and you have an > answer. You can even let them keep their RDP autologin for now, and fight > the desktop battle later. OpenVPN does require local admin rights on > Windows (for now, they're working on solving that), but I bet your road > warriors have admin rights on their systems. > > Jack > > On Wed, Aug 11, 2010 at 2:28 PM, Tyler Robinson <[email protected]> > wrote: > > Alright so after failing a recent security audit which I knew we would I > have a little bit of fire to allow me to make some corp changes one of them > being remote devices and policy. Currently there are mobile devices > unencrypted, and with cheesy passwords out on the road using unsecured RDP > to connect back to our terminal server to use apps, My question is what is > going to be an easy to roll out solution to make this situation secure I > worry that one of these devices will get stolen or sniffed and the terminal > server is on the LAN with the rest of everything , it’s a flat domain… so > how to I allow remote connections securely without allowing them to save > there stupid RDP Connection credentials(set to autologin) on an unpassworded > desktop. Any ideas or suggestions I have one year to plan, implement and > change this broken system, over about 10 corps all releated and setup the > same…. > > Thanks as always to everyone, > > TR > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > > > -- > ______________________________________ > Jack Daniel, Reluctant CISSP > http://twitter.com/jack_daniel > http://www.linkedin.com/in/jackadaniel > http://blog.uncommonsensesecurity.com > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
