Not happy with your proprietary security tools? Join the crowd, and then break away from that bunch of losers by using open source security software. In this tip, MailScanner developer Julian Field answers questions about the problems associated with open source migrations and offers advice about the best ways to avoid those problems. Field is also CTO of Fortress Systems (Washington, D.C.), a consultant and service provider for e-mail and e-mail security systems.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
What are the most common problems encountered in migrations from proprietary to open source security?
Field:The most common problem is the actual installation of the open source software package. Proprietary packages, however poor their performance and functionality might be, have developers who usually spend a large amount of time and effort creating the installer (using a closed-source installation package). The costs of the most common installation systems are beyond the funds available to the open-source community, and so installation is often slightly more awkward, relying more heavily on the knowledge and skills of the engineers installing the software.
Most open-source security systems do not run on Microsoft Windows, due in part to the huge learning curve required before a decent high-performance package can be written. Due to its nature as a tool-box of interacting, but separate, components, it is usually far easier to write security applications for Unix or Linux based systems. Microsoft Windows is very much one integrated system, where you are restricted in your actions by what Microsoft chooses to let you do in separate parts of the system. This isn't to say that these applications cannot be written for a Microsoft platform, it is that their design can be far more modular and insular in Unix- or Linux-based systems, without the possibility of causing any awkward reactions in other unrelated parts of the system.
This results in problems for companies that only know how to run Microsoft Windows based systems, as suddenly they are going to need to be able to run a Unix or Linux system for a new application. This is not hard, but it is new to them. The system administrators may need to attend training courses in Unix, as well as training for the security application if necessary.
Could you offers some ways to eliminate proprietary-to-open source security migration problems before they happen?
Field: Here's my short-list, starting with the most important tip:
- Talk to other people already using the software. It is usually very easy to get a long list of reference sites already using the software. You don't have to only go to the sites recommended as references by the closed-source vendors. Just ask on the mailing list and you will get an independent view from those actually using it.
- Is there decent support available? Consider purchasing an SLA from a company providing this for the software you are evaluating, but also look at the mailing lists associated with the software. Are questions answered most of the time? How long does it take for most people to resolve a problem?
- Run a pilot project. This is really essential for any new security system, be it closed-source or open-source, but it is an invaluable exercise to do. Run the software for one department or branch of your organisation, with a very fast "escape" procedure should any major problems arise.
- The pilot project should help you calculate the true implementation cost, involving hardware costs and user education that may be needed. This should also be kept in mind when considering any closed-source solution of course, but are often overlooked. Software that is "free as in speech" is usually not "free as in beer" for large sites, there are still ancillary costs involved.
- Read all the documentation and learn your way around the software, getting to know it as thoroughly as you can. You will get far more respect on mailing lists and from the developers if you have actually read what is available first. People who provide unpaid support do not like spending their time answering questions to which there are answers already available.