Our company has recently started courting clients who demand more robust security policies and we’ve opened our doors to third parties to validate our controls.
We're obligated to complete a new proprietary audit and we’ve hit a snag: the auditor doesn't accept open source, but her disapproval is inconsistent. pfSense is questionable. Elastic fails to meet her standards. OpenVPN passes. AlienVault OSSIM fails. Linux generally passes. Firefox fails.
She suggests that open source projects can disappear without notice. For instance, instead of AlientVault OSSIM, she prefers AlienVault's premium USM, despite USM’s reliance on the same open source projects.
Is this any better? Does AlienVault have the resources to maintain major components of their system after my auditor’s worst fears for open source are fully realized? Is the OSSEC project in any danger of collapsing soon? Are the linux kernel developers getting ready to close up shop?
Risk calculation is tricky, but I would accept those associated with these projects disappearing any time soon.
We invested in infrastructure upgrades this year in response to this audit. We don’t have the resources to acquire more commercial solutions when there appears to be acceptable (and popular) free and open source alternatives. We’ve already deployed AlientVault OSSIM at our sites, along with a few Elastic stack nodes. We use these systems to satisfy log aggregation, HIDS, IDS, IPS, and vulnerability detection requirements, etc. She shelved the discussion for now, but the issues on her tracker have yet to be remediated.
How do I move forward? Are there any resources I can share with her making my case for open source software?
tl;dr: Our auditor arbitrarily objects to open source for remediating security risks. How do I convince her these software solutions should be acceptable?
Long answer: it's a risk game, you may get away by showing that you have processes in place to manage this risk for open source projects: * internal backup of the source tree. * in-house skills to perform basic patching of the software if the development get discontinued. * alternative solution and roll-out plan in case the development of your current solution gets discontinued. * ...
Finally, risks can be accepted and someone ("the business") can sign-off on them. You don't have to remediate everything. It's just an awareness exercise for "the business".