Using Clojure for public facing system in a bank - code security scanning - any luck?

[Jason Turner]

We work providing software to banks, partly in cloud but largely on premise products.

We have been Java based for many years, but now looking to move to Clojure as we all love it. While on almost every front it is looking good, our market causes us to need to clearly demonstrate a high level of security compliance. To that end historically we have used code security scanning and specifically HP Fortify. Even when using in Java the cost of such objective 'proof' of security health is a large number of false positives, and given that our customers look to these shared reports for confidence this means long and expensive work to document and then discuss each false positive.

Now trying with Clojure this is looking like it could be a killer problem for us: we have a very large number of issues, many of them in the core runtime. Analysing a sample it is pretty clear these are false positives - however we are concerned about the practicality of fighting through - explaining your own Java code (given that the majority of enterprise tooling and customer staff familiarity is in Java) is already hard, explaining Clojure internals which do not decompile to Java is not a promising prospect.

I am reaching out to see if anyone else has fought this fight and won, or at least not lost?

We have done some preliminary analysis and seems clear that a good portion of these issues could be handled if we could contribute PR changes to core Clojure - however I know that making changes to working code to avoid this kind of static analysis issue is typically not uniformly popular, and would anyhow need careful analysis to detect and avoid any potential performance impacts on added checks.

So on that front I am wondering if anyone has managed to contribute back any minor changes to core? 

[Alex Miller]

Hey Jason,

I have looked at the Fortify reports and as you mention, it contains thousands of items. I spent some time looking at it and while I did not examine every item, 100% of the items I did look at were either a false positive or unimportant. We have no plans to satisfy Fortify by “fixing” any of that.

It’s perfectly possible that there are some actual issues in there and we would be happy to take patches for anything serious.

I don’t have any other advice except that there are several banks that use Clojure now, so clearly this is not an issue for everyone.

[Jason Turner]

Hi Alex,

Thanks for the rapid feedback. Before anything else I should say that we loved Clojure before using it at work, and we're even more in love now we are using it at work - a huge thankyou to the core team and Rich, and a great community.

Yes - I did see your previous comment but as was a long time back and I had a broader context seemed useful to use a new post. I understand your point - making changes to avoid false positives is frustrating at best. At this point in time we are analysing to first see to what extent we can 'fix' these, and then what the picture looks like once they are 'fixed' (given that on top of these issues there will obviously be both false and real positives (presumably) in our own codebase (currently just a small prototype system); so if we find any real issues we will definitely feed back to you thanks. I think that we will anyway report back to you our findings on the core false positives - I understand you may not pick them up but seems a good source of info.

Wrt the context - you are right there are several banks using Clojure - I have reached out a bit to get advice or experience, but so far not been able to find anyone who has had to do this and been successful. I think a key factor is that many banks operate (not without justification) quite different policies wrt their own home-build projects and services and products which they license from third party vendors; so I suspect that the majority of use is for in house work - e.g. Capital One, Nubank.

Anyhow I agree this isn't an issue for everyone - ironically and very frustratingly we are convinced that Clojure is actually facilitating security over e.g. Java in many many ways.

For us the real challenge is to find a cost effective (fairly) objective scalable means of evidencing to our customers that the product has a robust security design: we are smallish and have a large customer base of large customers. Sorry to bother you with various questions around this - but wondering if you may have the experience or contacts to highlight some alternative avenue:

• We are currently using HP Fortify which is not a bad product, but there are others such as Veracode. To my knowledge they are all broadly similar and none of them are currently providing anything Clojure friendly - but would you know of something more Clojure friendly?
• Our current approach is based around this route of using known objective analysis - for all its shortcomings (it is painful enough in Java). We are just now pondering to what extent we could solidly demonstrate on a more 'hammock based' approach i.e. list out long list of vulnerability categories and cite the design and implementation approaches which mitigate or prevent. This is in itself useful and an extension of what we anyway do - but customer wise it is obviously not really 'objective'. A way to make it more strongly objective would be to use a third party - that may however be costly.
• Similarly we are wondering to what extent we could expand the work we do in terms of ethical hacking / penetration testing - perhaps we could raise the bar there in terms of automation.

Thanks a gain for your time.

[Alex Miller]

On Friday, April 13, 2018 at 8:38:51 AM UTC-5, Jason Turner wrote:

Hi Alex,

Thanks for the rapid feedback. Before anything else I should say that we loved Clojure before using it at work, and we're even more in love now we are using it at work - a huge thankyou to the core team and Rich, and a great community.

Yes - I did see your previous comment but as was a long time back and I had a broader context seemed useful to use a new post. I understand your point - making changes to avoid false positives is frustrating at best. At this point in time we are analysing to first see to what extent we can 'fix' these, and then what the picture looks like once they are 'fixed' (given that on top of these issues there will obviously be both false and real positives (presumably) in our own codebase (currently just a small prototype system); so if we find any real issues we will definitely feed back to you thanks. I think that we will anyway report back to you our findings on the core false positives - I understand you may not pick them up but seems a good source of info.

Wrt the context - you are right there are several banks using Clojure - I have reached out a bit to get advice or experience, but so far not been able to find anyone who has had to do this and been successful. I think a key factor is that many banks operate (not without justification) quite different policies wrt their own home-build projects and services and products which they license from third party vendors; so I suspect that the majority of use is for in house work - e.g. Capital One, Nubank.

Anyhow I agree this isn't an issue for everyone - ironically and very frustratingly we are convinced that Clojure is actually facilitating security over e.g. Java in many many ways.

For us the real challenge is to find a cost effective (fairly) objective scalable means of evidencing to our customers that the product has a robust security design: we are smallish and have a large customer base of large customers. Sorry to bother you with various questions around this - but wondering if you may have the experience or contacts to highlight some alternative avenue:

• We are currently using HP Fortify which is not a bad product, but there are others such as Veracode. To my knowledge they are all broadly similar and none of them are currently providing anything Clojure friendly - but would you know of something more Clojure friendly?

Sorry, I'm not aware of any better alternative. 

• Our current approach is based around this route of using known objective analysis - for all its shortcomings (it is painful enough in Java). We are just now pondering to what extent we could solidly demonstrate on a more 'hammock based' approach i.e. list out long list of vulnerability categories and cite the design and implementation approaches which mitigate or prevent. This is in itself useful and an extension of what we anyway do - but customer wise it is obviously not really 'objective'. A way to make it more strongly objective would be to use a third party - that may however be costly.
• Similarly we are wondering to what extent we could expand the work we do in terms of ethical hacking / penetration testing - perhaps we could raise the bar there in terms of automation.

You might want to talk to Aaron Bedra about some of this - he does security consulting and is deeply knowledgeable about Clojure systems as well (and spurred a lot of changes in the Clojure web frameworks to default to better security).

[Jason Turner]

Excellent Alex - thanks a lot.

[Didier]

I'd love an independent penetration and security audit of the Clojure codebase. Especially around the socket repl in a localhost restricted way and making sure its not exploitable.

I wonder how much it costs, and if Clojurist together could have one funded.

[Alex Miller]

The socket repl is inherently not secure. It allows anyone to connect and run arbitrary code on the process. However, by default it is not running - you need to add extra system properties to start the server(s). If someone can start your server with arbitrary system properties, I'd say that is a bigger problem.

[Aaron Bedra]

Thanks for the shout Alex. Jason reached out to me directly but I figured it would be better to answer this for the broader group. I’ve got a lot of thoughts around this and I am happy to dive deeper into any of these as well.

On the topic of static analysis, I don’t think that application static analysis is a good fit for Clojure programs. It’s not that it couldn’t be done, it’s that static analysis on a language like Clojure is incredibly complicated and bound to produce a very high number of false positives. As it sits today, static analysis catches between 20-35% of security issues, which really isn’t a great start and certainly doesn’t produce secure software. Producing secure software requires much much more than static analysis.

IMHO a company that is looking to produce secure software should be practicing the following:

• Threat modeling
• Design and architecture review
• Data classification
• Trust modeling
• Code review (human based and static analysis if applicable)
• Dependency analysis
• Dynamic analysis (penetration testing)
• Infrastructure/Deployment analysis (newer but still incredibly important and now easier on platforms like AWS) including activities like vulnerability and patch management and container analysis

Long story short is I put little faith in static analysis. It’s a tool in a long list of practices on the way to producing secure software. I emphasize it much less when working on a Clojure program, but to me that doesn’t make Clojure worse off from a security perspective, it just means that I will double down on some of the other practices. There are so many default traits of Clojure programs that put it ahead of traditional languages that more than make up for the lack of ability to produce clear static analysis.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aaron Bedra]

Penetration testing is something performed on an application, but a source code review of the language is certainly an interesting idea. My company does these all the time. I ran this by my folks and there was certainly interest. If we could publish the results and create a healthy discussion my company would be happy to participate and do this at a fixed and heavily discounted price.

In terms of socket repl it is and will always be a security anti-pattern. But that should be understood and considered as a trade-off for the ability to access a running program. There could be recommendations made, but I don’t see a lot of value in pointing out what we already know to be a poor idea from a security perspective. I think that conversation should shift towards compensating controls around the environment to make sure limitations on repl access are present and auditable.

> On Apr 13, 2018, at 12:51 PM, Didier <did...@gmail.com> wrote:
>
> I'd love an independent penetration and security audit of the Clojure codebase. Especially around the socket repl in a localhost restricted way and making sure its not exploitable.
>
> I wonder how much it costs, and if Clojurist together could have one funded.
>

[Gregg Reynolds]

On Fri, Apr 13, 2018, 4:09 PM Aaron Bedra <aaron...@gmail.com> wrote:

Penetration testing is something performed on an application, but a source code review of the language is certainly an interesting idea. My company does these all the time. I ran this by my folks and there was certainly interest. If we could publish the results and create a healthy discussion my company would be happy to participate and do this at a fixed and heavily discounted price.

Naive question from the clueless peanut gallery: are you talking about a security audit of clojure core (& etc) source, which could then be cited as evidence by app developers?

E.g. I build an app against a signed version of clojure which is "certified" in some sense? Then I only have to audit my code (and lib dependencies)?

Gregg

[Dragan Djuric]

Hi all. Very interesting thread! I guess that not many Clojure developers are in this situation, but I hope many more will be; that would mean that Clojure got the foot in the door of the enterprise.

Gregg, I need a little clarification on the last thing you mentioned: Is a dependency treated as secure and given the green checkmark in usual security procedures if there is a (community) security audit that systematically listed vulnerabilities and recommended ways to avoid them? What is (in your experience with banking) the minimum amount of "burden" necessary so that an artifact is given a passing mark? Is there a broader standard, or each client has its own checklist? How defined those procedures are? Do they update at glacial place, or a good and honest efforts on case-to-case basis are accepted (such as hiring a security expert to audit the code with not-so-standard procedures)?

[Gregg Reynolds]

On Sun, Apr 15, 2018, 4:59 AM Dragan Djuric <drag...@gmail.com> wrote:

Hi all. Very interesting thread! I guess that not many Clojure developers are in this situation, but I hope many more will be; that would mean that Clojure got the foot in the door of the enterprise.

Gregg, I need a little clarification on the last thing you mentioned: Is a dependency treated as secure and given the green checkmark in usual security procedures if there is a (community) security audit that systematically listed vulnerabilities and recommended ways to avoid them?

Danged if I know. But obviously if you are building a high security system that uses third party libs they must be certified in some manner. If that can be done reliably then it need not be repeated for each user.

What

is (in your experience with banking) the minimum amount of "burden" necessary so that an artifact is given a passing mark?

My banking experience is limited to depositing and spending, hah hah. Actually I once worked briefly in a bank processing center. The entire system was written in IBM Sys/370 assembler. It was kinda fun. Security? You mean the guard at the door? (This was pre-internet)

Is

there a broader standard, or each client has its own checklist? How defined those procedures are? Do they update at glacial place, or a good and honest efforts on case-to-case basis are accepted (such as hiring a security expert to audit the code with not-so-standard procedures)?

Those are damn good questions and I don't know the answer to any of them. Frankly i've never thought about this much. But now I do it seems like an obvious business opportunity: if you can sign a blob of code then you can offer a security warrant for it. For a fee. Maybe people do this but I've never seen it. Probably too risky?

G

[Jason Turner]

Dragan our experience is that organisations often adopt something like BlackDuck and then use that as their benchmark.

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[Jason Turner]

Thanks a lot Aaron for getting in touch.

We are pretty much following all the practices you have listed - and I agree that they overall have more impact than static analysis, and can do more to lead to a secure deliverable; it is good though to note them and review to what extent we can make them a bit more formal. The main appeal of static analysis for us and our customer base is that it provides a somewhat objective point of comparison, so if we can see our way to partly or fully replacing that with a more formal/objective presentation of these aspects that may well help us.

[Aaron Bedra]

I have several customers who are in the financial services space using Clojure. To get an idea of the rigor behind what they need, I have attached the FSSCC workbook. The maturity input section shows the baseline set of controls that financial institutions are measured against. There are other standards as well, but this covers the majority of it and is based on the FFIEC cybersecurity guidelines. This supports the notion that it takes much more than static analysis when considering the maturity of a security program.