U.S. Cybersecurity Report Available
Kaelem writes "Kevin Rose put up a copy of the report Cybersecurity for the Homeland (pdf), due to be released tomorrow. It talks about some interesting things, like expanding the US-CERT website as well as funding for colleges to develop cybersecurity curriculum."
Who'd miss it if it was blown up?
_O_
.|< The named which can be named is not the true named
Anyone who anyone would care about?
_O_
.|< The named which can be named is not the true named
Here is what I did for one of my clients:
First thing; Clear security policy. Goes something like this:
You get the idea. This master policy shall be clear and simple at the highest level. Group and organizational policies shall include more detail as applicable to the group. However, they must all trace back to this master policy. When possible, the application of industry standards shall be spelled out as they relate to this policy.
It goes without saying that everyone involved (customers, vendors, partners, and employees) shall get the appropriate training. The more clear and concise the policy, of course, the less time would have to be spent on detailed training.
Idealy, all of this should be established and clearly agreed upon by everyone within the enterprise before a single piece of equipment is touched or configured.
Now that you have a clearly written and agreed upon policy, it's time to impliment it. Here are some suggestions that I like to employ that can pretty much transcend most security policies:
Firewall off everything except VPN. Don't even trust SSH from outside your company lan. If you must, trush SSH to a hardened box in a security island that is a lobby gateway to yet another single hardened box inside the lan that you can lobby gateway to any other box on the lan.
Use a colo or managed host for web if possible. If not, definately put this on a security island with as little as possible (and tightly controled as possible) access to inside the company LAN.
Use certificates for VPN access. Use a revocation list that can be accessed by the VPN clients. Have tight restrictions on how often the revocation lists have to be updated.
Road warrier machines should be set up so that private key is either smart card based or with a prompt-able password. You dont want to have your airport laptop thief access to the company VPN.
Impliment (as part of your policy) and ENFORCE a strict no wireless policy from inside the company without manditory VPN. Enforce the requirement that all WIFI access points be provided by IT or some authorized organization. Enforce this by war-walking throughout facility and conficating unauthorized WIFI sites. Invoke an internal 'fine' if you must to get this message across.
Allow NO vendor, partner, customer, etc. full unrestriced access to your internal lans. Restrict their access. Partners's networks shall have VPN access only to those subnets within your network they need to fulfill their jobs. This can be implemented via VPN and access control lists. I have done this with the open source VPN solutions and iptables. Don't claim that it cannot be done without spending $100k's on equipment. And PLEASE remember to terminate this access when the contract is completed. You did remember to implement and use that revocation list, did you?
Do not allow transient vendor access to your company network. If you need services from a vendor that you have not had a relation with in the past; you should either drive (YOU having your hands on the keyboard) while they tell you what to do; or you should be CLOSELY shoulder surfing while they are doing their thing. I do not allow any new or temporary vendor unattended access to a system on our networks.
Have a CLEAR, DOCUMENTED and AGREED policy and procedure of what to do when someone leavs. This
Cleara