Ask HN: My infosec auditor rejects open source. What now? | Hacker News Reader

Ask HN: My infosec auditor rejects open source. What now?

33 points_ix17 comments

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?

Quick answer: get a better auditor.

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".

Agree with this but I would also ask the auditor to be very specific about the risk that she believes your organisation is exposed to. If its a specific concern about the suitability/support of certain tools in use in your infrastructure, you can respond to/address those. In particular, I would make sure that the risk is clear about the impact it could have if an OSS project was discontinued (as the parent refers to): its unlikely to have an immediate impact as, by definition, you have a working instance of the tool and the source code so nothing stops working. In many ways this is comparable to the sort of escrow clauses that auditors sometimes look for in commercial support arrangements and which are often deemed acceptable mitigation for commercial products. She should also be clear about likelihood. In my experience (I've been an auditor for c18 years), it can be the case that auditors think about the doomsday scenario - e.g. ALL of the OSS projects you use close down - rather than the more likely scenario that one or maybe two go dark. Again, if she can articulate the specific risk it may be possible for you to respond to real likelihood of a key tool's project stopping (which would parent's approach already covered but which can be prioritised according to risk).

If however its a more general/vague concern about OSS support then you'll have a hard time dealing with it and acceptance may be the appropriate route.

Sound advice. I've got some more work to do. Thank you.

> open source projects can disappear without notice

1. They can't. Someone can decide to stop working on a project, but it can not disappear.

2. You know what can disappear? commercial products.

> 2. You know what can disappear? commercial products.

This this this this! In fact, commercial software is GUARANTEED to disappear. Once it is no longer profitable to support the software, the commercial outfit has a duty to stockholders (in the case of public companies) to abandon the software and their customers. Once it's abandoned, it's impossible to provide support. At least with open source projects, you have both pieces of the broken case to glue back together when it brakes. If you are a Red Hat customer, I bet they would be game to talk to your auditor about the merits and benefits of open source security.

Re 2: Perhaps the auditor isn't referring to open source products being shutdown, but rather package info being pulled abruptly making the package inaccessible for some period of time. Particularly I'm thinking of the whole npm left-pad fiasco (http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm, https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...).

A responsible enterprise shouldn't be basing production deployments on package repositories that can get yanked. Mirror that shit if you want to keep making money.

> Are there any resources I can share with her making my case for open source software?

Here's a DOD guide to OSS, it might help a bit? Very interesting that the Government defines OSS as a subset of commercial software - "commercial" means anything available to the public, as opposed to private software. They do not distinguish between paid and free software or between companies and individuals.

http://dodcio.defense.gov/Open-Source-Software-FAQ/

See specifically the section "Why is it important to understand that open source software is commercial software"

Also see "Is there any quantitative evidence that open source software can be as good as (or better than) proprietary software?"

And there are links to resources for evaluating OSS licenses.

Indeed, the very strong impression I got as of 2004 was that the intelligence community loves open source, and were e.g. much happier running Linux than Windows on machines running on their secure networks (are we surprised?).

As others say, it sounds like you need a better auditor.

Get a new auditor. Reference this: http://serverfault.com/questions/293217/our-security-auditor...

Thanks so much for this, twas some crazy reading.

"Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use."

Yeah... that. Uhhhh....

Oh my, what a nightmare! Didn't know whether to laugh or cry while reading it :D

To me, it sound like your auditor's objections are based on the availability of (commercial) support, and not the nature of the code's license or whether one can read or modify it.

There are entire vendors who specialize in selling open-source software with commercial support; Red Hat is the most famous example.

I could see that being a reasonable objection -- It would be really easy to provide evidence of effective deployment of open source in my network if there I had a support contract, right? But, that's not the objection she made. I wish I could have recorded her making her case against Firefox.

We also maintain a premium OpenDNS account, integrated with Active Directory to assist in web content filtering. Because the word 'Open' appears in the product's name, she assumed that the solution was FOSS, and determined that it was insufficient in the context of the audit she was conducting.

From a business standpoint: play the game, check all the boxes. (And it never hurts to be flexible and open to different ideas, even those that seem counterintuitive.)

Reply on news.ycombinator.com