Thesis: Need to rethink how things work so they happen real time.

Aspect does a lot of code review and manual testing. That’s why they don’t have XSS and System.out.println() as the leading items. Static analysis tools are good at finding that.

Stats

• 98% of apps have at least one vulnerability
• On average, Apsect uncovers 22.4 serious vulnerabilities per app. A small fraction are in open source libraries.

We find vulnerabilities months or even years later. Developers are likely on another project by now. Or have at least forgotten the code. Which means they won’t have gotten any learning out of it.

Interception points

• HTTP Traffic – ZAP can be proxy between Selenium and app to sniff traffic.
• Data Flow
• Control flow – static or interactive
• Libraries and frameworks
• Configuration data – static analysis tools don’t look here. But could write a static analysis rule for it
• Back end connections – sometimes developers don’t know so isn’t in architecture review

What if this were the US tax code?
Imagine somone dropped the US Tax code on your desk and ask you to find the loopholes. It’s about a million lines of code. Lawyers don’t do it in one week. You wouldn’t read it line by line. You’d look for patterns. Caman Islands?

Mix existing techniques to get continuous security

• Code review useful, but hard to do real time. Need to take that effort and turn it into small automated tools. Make it into repeatable test case. ZAP does this – you can write a ZEST script to test for future instances of vulunerabiity. Mozilla is going to make that the standard way of reporting a bug to them.
• Static analysis – Great at enforcing simple checks. Explore positive rules. Custom rules for more complex patterns.
• Dynamic analysis
• Interactive application security testing – look at insides, good at data flow analysis, injection flaws, library testing
• JUnit – verify your controls are correct. Don’t see enough people using JUnit for security

My Take
This was similar in message to Jeff’s morning session. Some parts were the same (reuse) and some parts were different. And some parts went into different depth. And again Jeff mentioned Sonatype more than Ryan did.

General

• If couldn’t use OSS, you’d have no app or tools. It’s in many components. hhe question isn’t whether you are using it but whether you know.
• Takes a long time to fix because need to wait for each person down the tree to fix/pull the fixed version.

Struts 2 vulnerabiity

• FBI alert
• “Really important” but to who?
• At time of disclosure and shortly thereafter, not muh change. Not many downloads of new version right after announcement
• Roughly 5% upgrade as soon as new version comes out

Stats from research

• 90% of downloaded components from Maven Central in local repos
• 71% of apps have have been deployed have critical to severe vulnerabilities

Lego
Every block has a # on it. If find manufacturing issue, can go back to machine that is causing problem so can fi it. Toyota works the same way. If there is a problem, want to know who is affeced. Supply chain management.

The right questions

• How do you select components for your application. It shouldn’t be google. It shouldn’t be what your friends are using.
• Is project still in active development?
• How do developers know when they should upgrade

Need to ensure that is deployed is same jar as locally and in the build.

We are used to looking the other way

My take
My only gripe is that the talk started early. I could have been there early. But I wasn’t because over the first day and a half of conference, everything started on time. The actual talk was good. Ryan covered the importance of component selection and upgrading. And he was funny. Adding him to my mental list of great speakers. As with his earlier session with Jeff Williams, it wasn’t a Sonatype CLM ad.

speaker: Eoin Keary

As an industry, we are very busy but things don’t seem to be getting better. Big companies are hacked. If we have the brainpower and the budget, why aren’t things improving?

Asymmetric arms race

• like the bear. you don’t need to outrun the bear, just the guy behind you.
• You may be secure at any given time. But it’s like a treadmill. Things change

Too many variables and too limit time to ensure “real” security. Many attacks go after the business logic.

Current state

• 10 men years of development and two weeks of ethical hacking
• Testing targets 80-90% coverage.

“Risk comes from not knowing what you’re doing” – Warren Buffet

Testing is time limited. Tools give false positives so still need to investigate output. Code is pushed frequently. The value of the pen test drops because the code no longer matches that test.

Most tools cant scan for DOM/XSS. See DOM XSS Test Cases,

Robots are good at detecting known unknowns. Humans are good at detecting unknown unknowns.

We eat cheeseburger until the doctor says you are going to get a heart attack. We write insecure code until we get hacked.

Tool: https//github.com/jeremy long/DependencyCheck

We can’t improve what we can’t measure.. Risk changes depending on context. Just because it is XSS, doesn’t automatically make it high. Maybe it is on a page only one person can access.

My take
Nice analogies. It felt a bit like preaching to the choir though. I had trouble finding the organization in the presentation (hence the lack of organization in this blog post). In hindsight, I should have guessed this given the lengthy abstract. Also some of the “new” things were in earlier preentation. I left half an hour in. Possible the second half was better.