Linux Security Tip-of-the-day: Research Before Implementation

82

With the current barrage of security threats there are far too many people (including corporate decision makers) that are willing to push any solution to try to reduce their risk. The issue is that some solutions that are pushed are not properly tested and/or researched prior to moving to the end-users. The most common results of these rushed decisions are:

  • Lost Services
  • Reduced uptime
  • Increased CPU load, resulting is reduced employee efficiency
  • Lost connections to necessary external services
  • Conflicting solutions
  • Or the dreaded introduction of new points of failure/weakness
As an Administrator, Engineer or Analyst you must follow the directions of those above you, but you must also take the proper steps to avoid the issues noted above.
So here are my recommendations for testing and research.
  1. If the new solution involves a firewall modification it may be a good idea to obtain the proper approval then run a packet capturing service on the backbone to capture the soon-to-be targeted packets. This information when reviewed will allow you to see just how many users and services may loose connectivity, or it may point you to an existing issue that would be the result of what you are attempting to stop.
  2. When testing new client side security software do not only run the standard detection tests, you also want to setup the systems to log CPU, memory and hard disk performance before and after installation so you have a baseline and can accurately determine the impact on the users. Lost productivity can quickly add up and make the cost of implantation of a product much more expensive than the general assumed licensing and support costs. If the new load is too great from active scanning, then it may be advisable to propose scheduling for the scans to run after hours so the users are not impacted.
  3. When setting up or modifying an internet proxy server rules you first want to setup the proxy server to log the traffic that has been proposed to be blocked/redirected, you can then review the logs and determine if the current use is beyond the original estimates and prompt the appropriate individuals to question the users to determine if the site/service is really needed. This will help to reduce the lost productivity cost from the new rules.
  4. When adding a new solution, test it in-depth with the current solutions to see if there may be a conflict in actions that may open a new weakness.
  5. Segregate your test systems from the current active systems on the network, this will make sure that if new vulnerabilities are exposed and/or exploited that the backlash will not impact the current active user base.
  6. Check the internet for help requests, bug report, vulnerability listings and user feedback on the proposed solution. This will help you to asses the solution before hand and know what kind of issues you should focus on during your evaluation.
  7. Search the internet for Total Cost of Ownership calculations from other users of the proposed solutions, this can help you to truly identify if the cost to to good to be true.
  8. Notify and train the users on the new solutions, this training will help to reduce your service calls and potentially lead to users helping to identify issues before they become widespread problems.
To most these should be second nature, but these recommendations will save you a lot of time, money and headaches so they are worth following.