Many times, when someone in a position to design, recommend, or select information technology solutions is faced with a new challenge to tackle, the first impulse is to look for a security product to buy. Evaluations of feature sets lead to purchases, which lead to deployment evaluations, which may lead to another round of feature set evaluations when next the budget period cycles over.
Often, the simplest and most effective means of solving the problem is completely overlooked. The expense of buying licenses for a vertically integrated vendor stack, the time spent in evaluation, and the uncertainty of judging software by its advertised features rather than by experience you already have are all too often unnecessary. A lot of the time, you already have all the tools you need.
Many operating systems provide tools that are simple, small, and versatile when their functionality is combined with other such tools. Whereas "one size fits all" application suites depend on their extensive feature sets to satisfy the needs of as many users as possible, the core utilities of your OSes are at their best when they do as little as possible, but do it extremely well, and as simply as possible.
A little glue code is often all that is needed to turn a collection of system utilities into an effective security tool. Taking this approach provides a number of benefits that you will not get from Vendor Foo's Supermassive Security Suite:
- It does not cost any money in additional software licenses.
- No evaluation by reading advertisements is necessary, because you already have the tools in your hands, and you will not have to rely on the honesty of a vendor or contend with a resistance to full disclosure.
- It does not enforce additional steps toward task completion on you, as a way to work around integrated features you do not actually want in the first place.
- Modification to accomodate future needs, and incorporation into larger systems, is easy.
- It does exactly what you want, because you built it that way.
- If you answer to someone higher up the organizational chain, you will not have to get a stamp of approval for bringing new externally developed software into the network.
- It would allow you to enjoy the benefits of open source development, if the tools you use are open source, without having to explicitly add open source software to the network. This, of course, is related to the previous point.
- You do not have to rely on vendor response times and support channels to get the changes you need when you need them.
- It would not suffer from the sort of bloat that is typically associated with suites and vertically integrated stacks.
- You will know the solution inside and out, you will know the core tools of the platform better as a consequence of building the solution, and this could provide opportunity for building your reputation while you are at it.
As a bonus, if you leave the current organization, you will not have built an entire system from the ground up. This is a benefit because of the way copyright law usually favors the organization in such circumstances. If you have built a piece of software from scratch, the software typically "belongs" to the organization that employed you at the time. If all you did was write a little glue code to manage a set of disparate tools that are distributed with the platform itself, all you need to do if you want basically the same solution at some later place of employment is write a little glue code to tie the same system utilities together.
You will probably even do a better job the next time, because you will have learned from the experience of having done it the first time.