
Ask HN: My infosec auditor rejects open source. What now? - _ix
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.<p>We&#x27;re obligated to complete a new proprietary audit and we’ve hit a snag: the auditor doesn&#x27;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.<p>She suggests that open source projects can disappear without notice. For instance, instead of AlientVault OSSIM, she prefers AlienVault&#x27;s premium USM, despite USM’s reliance on the same open source projects.<p>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?<p>Risk calculation is tricky, but I would accept those associated with these projects disappearing any time soon.<p>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.<p>How do I move forward? Are there any resources I can share with her making my case for open source software?<p>tl;dr: Our auditor arbitrarily objects to open source for remediating security risks. How do I convince her these software solutions should be acceptable?
======
pentesterlab
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".

~~~
mdh
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.

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

~~~
tedmiston
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](http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm),
[https://medium.com/@azerbike/i-ve-just-liberated-my-
modules-...](https://medium.com/@azerbike/i-ve-just-liberated-my-
modules-9045c06be67c)).

~~~
op00to
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.

------
dahart
> 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/](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.

~~~
hga
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.

------
late2part
Get a new auditor. Reference this:
[http://serverfault.com/questions/293217/our-security-
auditor...](http://serverfault.com/questions/293217/our-security-auditor-is-
an-idiot-how-do-i-give-him-the-information-he-wants)

~~~
i336_
Thanks so much for this, twas some crazy reading.

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

~~~
i336_
Yeah... that. Uhhhh....

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

~~~
_ix
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.

------
percept
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.)

