You can't secure what you don't acknowledge.SM

Thursday, December 20, 2007

Hilarious Christmas video that says it like it is

Check out PGP's 'The 12 Threats of Christmas'...It's really well done and it'll make you think about security. Even better...it'll make you laugh.
http://www.youtube.com/watch?v=PSRPGHyYq90

Merry Christmas!

Yours Truly,
Kevin

Wednesday, December 19, 2007

Firewall Best Practices

Based on yesterday's post regarding firewall best practices, I thought it made sense to go ahead and post the 'best practices' content here as well. This is straight out of my Firewall Best Practices document I just recently updated:


Firewalls are not the end all, be all solution to information security. They are, however, a necessary component of an effective network security infrastructure. The following list is a set of reasonable practices to consider in order to ensure your firewall(s) is configured for optimal effectiveness. Remember, “best practices” aren’t a one-size-fits-all solution. Furthermore, reasonable firewall configuration and management doesn’t automatically minimize risks. Your mileage – and your priorities – will vary.

1. Don’t assume your firewall is the answer to your network security. Things are way more complicated.
2. Deny all traffic by default and only enable those ports, protocols, and services that are needed.
3. Make sure the security rule set on the firewall remains consistent with the organization’s written information security policy. Also, be sure not to confuse your firewall rulebase with your internal ‘security policy’. They’re not the same. The former outlines what the firewall lets in and out of the network. The latter is for internal dos and don’ts outlining ‘this is how we do things here’. You do have a set of security policies, right?
4. Limit the number of applications that run on the firewall in order to maximize CPU cycles and network throughput. This will let the firewall do what it’s best at doing. Consider running anti-virus, content filtering, VPN, DHCP, and authentication software on other dedicated systems behind the firewall and, in some cases, in front of the firewall.
5. Run the firewall service as a unique user ID instead of administrator or root.
6. Set or change the default firewall administrator or root password before you ever connect it to the public Internet. It sounds too obvious, but I often see it in my work – many firewall passwords are never set or changed from their default. Make it a long complex passphrase that’d be very difficult to guess and ideally easy to remember. Change the password every 6-12 months or if it’s ever suspected to have been compromised.
7. Do not rely on packet filtering alone. Use stateful inspection, proxies, and application level inspection where possible.
8. Filter packets for correct source and destination addresses to keep malicious traffic from entering and leaving your network. This will help prevent denial of service attacks.
9. Ensure that physical access to the firewall is controlled. Again, another obvious statement but you’d be amazed at how many firewalls out there are accessible to anyone and everyone who wants to wreak havoc.
10. Keep your firewall configuration as simple as possible and eliminate unneeded or redundant rules to ensure that the firewall is configured to support your specific needs. This requires auditing your rulebase periodically which can be done manually, or ideally, using a tool such as Karalon’s TrafficIQ Pro (www.karalon.com).
11. Perform regular security tests against your firewall including any VPN endpoints it’s hosting. New exploits are continuously discovered and must be tested for on a consistent basis. In addition, the slightest firewall system or rule set modifications can completely change the firewall’s security capabilities. Perform these tests on every interface of the firewall in all directions. Also, if possible, perform these tests with and without the firewall rules enabled to determine how vulnerable you will be when the firewall is not functioning properly.
12. Patch the firewall’s operating system and application software with the latest code on a regular basis. This requires continually monitoring (or subscribing to) your firewall vendor’s security bulletins. However, make sure you test these updates in a controlled, non-production timeframe or environment whenever possible.
13. Use firewalls internally to segment networks and permit access control based upon business needs.
14. Enable firewall logging and alerting if possible but ONLY if it’s going to be managed. Otherwise, it’s a waste of processor cycles. Treat the logs as business records and include them in your information retention policy.
15. Use a secure remote syslog server that makes log modification and manipulation more difficult for a malicious attacker.
16. Consider outsourcing your firewall management to a managed service provider so you can leverage their aggregation of expertise, network trending analysis and intelligence. This will also save you time and money by allowing you and your team to focus on your core business needs.
17. Use change-management practices such as those outlined by ITIL for the firewall to approve changes needed, assess the reason(s) for the changes, document the changes made, and describe the necessary back-out procedures in case the changes fail. This is extremely important.
18. Require that all remote computers run personal firewall/intrusion prevention software. Firewalls can be easily circumvented if using wireless network systems internally, so it pays to have another layer of defense on your hosts. Make this something that cannot be easily disabled by users. No exceptions.
19. Regularly backup the firewall rulebase and configuration files and keep the backups offsite. This doesn’t seem important until the time comes for you to restore after a system failure, etc.
20. Remember that firewalls are rarely in a position to prevent attacks that originate from inside your network. An acceptable usage policy, personal firewalls and host-based intrusion prevention software, network monitoring, content filtering, and access controls on all hosts can help lower these risks.

Tuesday, December 18, 2007

Firewall change management? Who needs that anyway...

I recently had someone contact me and ask about the change management item I list in my Firewall Best Practices document. This person's inquiry revolved around them trying to get management to adopt change management practices and the troubles associated with having to properly and realistically explain to management the risks involved of not having good practices. This person wanted to know if I could explain the risks involved when a firewall best practice such as this is not implemented and potential exposure an organization could face. A book could be written about the specifics regarding change management and firewalls. Here's a good real-world example I've experienced...

Not too long ago I worked on a project where a network admin in a large organization made an offline/out of process change to a critical firewall that ended up creating hours of downtime for their e-commerce customers. That loss PLUS a couple weeks of consulting time to figure out what went wrong and how to prevent it in the future created some pretty serious business risks and costs. Stuff that didn't have to be IF:
  1. They would've had the right change management processes in place (such as those outlined in ITIL)
  2. Had employee buy-in so the processes were followed
  3. Automated and enforced their policies and processes where possible using a technology such as those offered by Voyence and Configuresoft

I've always said and it deserves repeating here: as long as people have their hands in security, there will always be vulnerabilities and business risks.