Source Code Security Audit

[DonRichards]

Source Code Analysis (OWASP, Nikto, etc)

Audit security vulnerabilities to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. Audit for configuration issues, identify additional security issues of known published vulnerabilities.

Automating Penetration Testing Options

• In a CI/CD Pipeline
• Embedded script
• With a 2nd VM

[DonRichards]

@MarcusBarnes Thoughts?

[MarcusBarnes]

@DonRichards This is great stuff. Thanks - we can touch base during the Sprint to coordinate our efforts based on the time available to us. Thank you again!

[DonRichards]

Possible Things to test for:

• Abuse of Functionality‎
• Data Structure Attacks‎
• Embedded Malicious Code‎
• Exploitation of Authentication‎
• Injection‎
• Path Traversal Attack‎
• Probabilistic Techniques‎
• Protocol Manipulation‎
• Resource Depletion‎
• Resource Manipulation‎
• Sniffing Attacks‎
• Spoofing‎

\ Let us know if there is anything on this list you'd like us to focus on.

[ruebot]

@Islandora-CLAW/sprinters feel free to chime in here.

[MarcusBarnes]

N.B.: Today's release of Drupal 8.1.7 includes a security update to address the vulnerability detailed at: https://httpoxy.org/ which affects Guzzle - a third-party dependency for Drupal 8.

[ruebot]

Thanks @MarcusBarnes! @DiegoPino, @whikloj and I are on it.

[ruebot]

@MarcusBarnes @DonRichards are y'all still working on this? Anything to report?

[DonRichards]

Yes sir. Been at it most of today. Found a possible simple solution. Should this code be part of a branch for a sprint?

[ruebot]

@DonRichards what's the code? What are y'all proposing to do?

[MarcusBarnes]

@ruebot Along with @DonRichards, I did some research into potential tools to help with on-going code security and gained some insight on how to continue this work. We can close this issue when @DonRichards is happy to do so. Even with this initial look, the focus will chance somewhat once the MVP spec. is decided upon. I will probably continue this line of investigation as part of my participation with the ISIG. Thank you for the opportunity to participate!

[manez]

@MarcusBarnes anything reportable on the tools front? It's nice to highlight alternative ways to sprint 😄

[DonRichards]

My thought would be either create a suite of tools in the repo or create a security tool in a new repo to pull into CLAW as a submodule. Either way I'm testing Nikto currently.

[ruebot]

@DonRichards if you could draft up a proposal for @dannylamb and I, and the @Islandora-CLAW/committers, that would be greatly beneficial.

[DonRichards]

http://goo.gl/vyBbnm @dannylamb Is this roughly the correct direction? Not super detailed. Just looking for feedback before I dive too deep on this.

[ruebot]

^^ @Islandora-CLAW/committers please review @DonRichards proposal.

[bryjbrown]

👍 Looks good to me, having Travis run a security test suite against commits (eventually) sounds like a great goal to work towards.

[whikloj]

I can't quite see how this will work in my mind. But the idea and plan seems sound. 👍

[ruebot]

@DonRichards @MarcusBarnes I'm curious how much of the stack we as a community can sustainably take care of, and what your thoughts are on that.

IMO, the operating systems, Drupal, Apache, MySQL, etc., are covered by their own security teams. Fedora makes use of the Maven victims-enforcer plugin on every Maven build, which means it is hooked into TravisCI and Jenkins. We can make sure we have that Maven plugin included in all of our Java projects. That said, that leaves the PHP microservices, and Drupal modules in CLAW. Would you be willing to update your proposal to reflect a security plan for those components?

@Islandora-CLAW/committers I'm curious as to your thoughts here too.

[acoburn]

This is just my personal opinion, but while automated security audits can be useful for identifying certain well-known vulnerabilities, I see them as only a very partial solution. These audits will contain both false positives and false negatives, and it is not clear to me that the vulnerabilities that they identify are always the areas that are most vulnerable in a given software stack.

[DonRichards]

@ruebot PHP microservices and Drupal modules does narrow it down and would speed up developing a series of scripts for Travis.

@acoburn I agree but also argue that some reasonable level of checking should be done. As long as it doesn't encourage developer complacency I believe it's a wise step.

[DonRichards]

Overview Setup an automated process for continuous monitoring, vulnerability management, and security policy compliance evaluation reporting. Primarily focusing on PHP microservices and Islandora Drupal modules.

[ruebot]

@DonRichards how would you like to proceed with this ticket before it gets too stale? Would you like to refocus your efforts here and align it with the MVP, or would you like to close the issue and come back to it later?

[ruebot]

@DonRichards ping

[DonRichards]

Hi @ruebot I've been doing some research into this for other projects. While looking into a continuous security integration to validate the security posture for non-infrastructure software through Travis continuous integration pipeline I've come across a few options. These could be easy enough to implement and quick to code.

ISIG is already developing this security posture. Does CLAW want to rely on ISIG's suggestions for this?

Assuming the security suite is a separate repo because of the size and possible use I can put together a starting point in the next few days to look at.

I just created an empty repo for this; https://github.com/DonRichards/CPS

But I agree if this isn't something quickly wrapped up it might be useful to revisit later. As for now it might actually help people develop faster and more confidently.

But I'm open to suggestions.

[ruebot]

Please expand more on the security posture.

[DonRichards]

Overall security plan and assessment of what is important to a check (vulnerabilities, injection, code standards, etc.).

Knowing what is import help develop the scope for testing. If we start with a catch all we could end up test for DDOS attack issues when that is outside the scope of our stack.

[ruebot]

Can you explicitly outline;

• how this is different from what you originally proposed, and has already been commented on
• what you are volunteering to work on
• what you are committing to deliver
• how this aligns with the MVP

[DonRichards]

• Does not differ much if at all.
• I'm willing to create a submodule to accomplish this via spinning up a VM in travis and test.
• Committing to create a starting point to automate the testing, document how to make additions
• MVP: The ability to restrict access to collections and/or individual resources across all representations (test restrictions work).

[DonRichards]

I am wondering if Codecov is enough to start with? It's already been integrated with some of the submodules.

[ruebot]

Where does Codecov overlap with what you are proposing?

[DonRichards]

Just think it's all part of Code quality

[ruebot]

Closing this for now since the scope has changed a few times, and we're do not have consensus on what it is. If we sort out the scope, we can re-open or create a new ticket. Feel free to create an item on a future CLAW Call if need be.