using components with known vulnerabilities at app sec usa

A9 is the new addition to the OWASP Top 10. The panel is Ryan Berg (Sonatype CSO), Jeff Williams (Aspect) with Mark Miller (TSWA) moderating.

80% of an application is assembled from open source components.

  • Jeff: still have about same amount of custom code, but amount of library code exploded.
  • Ryan: when started doing dynamic analysis, classpaths were too big to load all the classes. But don’t pay attention to entire universe pull in. Has seen examples were it is 99% of the app being open source. Thinks 90% is common.
  • Jeff: # is mileading. Much of that code is never invoked. Some there to compile parts of a dependency and are never used. Don’t expect 80% of vunlerabilities to be in open source code.
  • Ryan: It’s callable even if not calling. OGNL attack in Struts can call ANYTHING on classpath
  • Ryan: 1.3 is the most popular version of Struts. Not even Struts 2. [Struts 1 and 2 are completely different, this isnt a patching problem. The guy on Struts 1.2 is a patching problem]

26 million downloads # overcounts because builds not projects but undercounts because enterprises download once for all projects

Attitude

  • Ryan:
    I just want this library and I want it to work. I don’t care how many friends it brings with it. Roach motel.
  • Jeff: The libraries come from the dependencies. Not a great way to find out what bringing in. [maven dependency tree does this]

Nearly 2/3 of organization don’tknow which component are used in their applications

  • Ryan: Most organizations don’t know what apps they have. That’s job #1. Know the critical apps but not by most use. Assume your intranet is on the internet when doing security.
  • Jeff: First mention of Sonatype’s product. [surprised this didn’t come from Ryan]
  • Jeff: Question assumption that need a bill of materials. Matters more what is in them. Is it crap? Manufacturing chooses parts intelligently. Material data safety sheets. We should want a library that is supported and was written by people who know about app sec.
  • Ryan: Is the component active. Has it had a release in the last two years. If nobody is around who caes that there is a problem…
  • Ryan: Developers want to use the cool thing. “Spring sold out; everyone using Stripes now”. Has same security issues. From a business standpoint, don’t want to be on the newest, coolest thing and be th one to discover problem.s
  • Jeff: Make app sec visible so can make informed decisions about risk.
  • Jeff: A9 is about making one piece of metadata visible so don’t make ridiculous decisions. That info isn’t visible to th people at StackOverflow saying to use the cool thing
  • Ryan: Many developers donn’t know what a web requet looks like anymore. Frameworks abstract all tis information. Start trusting the library.

Maven Central

  • Jeff: “sha” in answer to what comes out of Maven Central
  • Ryan: How many people check the checksum after download. Very few

How inventory

  • Jeff: Can scan ports to find web apps. Or can instrument app servers. Once know where apps are, need to catalog libraries using.
  • Ryan: Don’t assume a jar called log4j-1.3.jar isn’tlog4j-1.3.5 or log4j-2.0.jar, People have policies saying can only use a certain version name.

Patching

  • Jeff: Open source developers don’t put security fixes in branches all the time. Sometimes you have to pull in the next functional release to get it
  • Ryan: Hae to pay attention or acknowledge risk of being on older version. Must accept burden/exposure.
  • Jeff: When asked about vendors don’t find out about security issue their product uses until the public does. Then they need to start. The bigger problem is when the only mention of the patch is in a SVN commit comment. Want it to be seemless like OS patches are now – automatic updates. It hasn’t always been that way.

What can we expect

  • Ryan: Happy to see getting back to basic blocking. Should you be using a library with a vulnerability you can google. This is step 1.
  • Jeff: For every known vulnerability, probably many unknown ones since not scrutinized
  • Ryan: How bring supply chain mechanics to software development.

My take
Great session. Jeff and Ryan sounded like they were having a real conversation/discussion about little differences while presenting the same message. And Ryan didn’t plug Sonatype CLM which surprised me. They have a vendor table so everyone should have seen it that wanted to. But still, it was nice that he focused on information and not marketing.

protect yourself – data loss on the net at app sec usa

speaker: Kelly Fitzgerald

Interesting points and urls

  • Remember that the first three digits of your Social Security Number are based on where you live. Also interesting that you get SSN at birth now and didn’t in the past.
  • Spokeo – paid service that shows info about person including what credit card and ad agencies think about you. Thinks speaker is a boy. You can opt out of spokeo everything except name and age.
  • Knowing someone’s primary email, helps you see many acccounts – facebook data, etc.
  • On Facebook, most people keep unprotected profile pic, other pics, freinds list (ex a friend’s comments). Also watch for backgrounds in photos. Surroundings, books,reflections in glass/computer monitors
  • If you buy from someone on e-bay, you can probably find their location
  • Your Facebook friends are 70% people looking at your profile and 30% random noise
  • bing.com/social will show interesting info
  • openbook shows open posts by person
  • openstatussearch.com – make sure you have locked down status
  • wolfram alpha self-analytics tool
  • many people use full name or email in profile. Don’t use twitter/linked in/etc pictures because can connect your online pic to the rest of your internet presence. The search by image services aren’t good yet. [facial recognition seems like this will fail eventually too]
  • truedater.com – people will post stories about you. Similarly for don’t date him girl
  • People on linked in can pay to see who saw your profile
  • Amazon wish lists are public by default
  • United has upgrade status public. Only has first letter of first name and three letters of last nme. Could only find it new person already
  • Zillow, trulia, spokeo, blockshopper – all have your home’s info. Can’t get zillow off
  • Finding criminals can be tough because need to know county arrested in. But can search your and neighboring counties
  • Megan’s law offender app – shows where sexual offenders are
  • SearchDiggity – free tool to search for PII. Worry about typing in your info is still a valid fear
  • Do sensitive things on other taccounts, don’t use Oauth for touchy situtations, track old accounts down and delete them
  • Facebook has a blog – you can use it to find out about updates
  • Misinformation lets you stay anonymous
  • Can see people’s charitable and political donations
  • See if your credit card company offers virtual credit card numbers. Can use for online purchases and set short expiration date. Like a one time use number

My take
Great presentation. She took a guy who had a PII leak on a tv show and how much more she could find out about them. Entertaining and informative. It was a little short, but the Q&A were great. She brought cupcakes to bribe people to ask questions. I think we would have anyway as they were thoughtful questions. And it was good to get a break at the end.

jeff williams on dev ops and portfolios at app sec usa

Imagine application security is health care
We have a lot of doctors and patients. Think of app security as a public health issue. How do you stamp out SQL Injection as a disease. Can’t scale up patient level tehniques (penetration tests) to wipe out completely. New tools to instrument body to provide continuous real time monitoring. Annual checkups are reactive. That’s discovering a problem way too late and many people don’t even go that often. One day your phone will know you are sick before you do.

Tools are failing us

  • Static analysis tools – request.getParameter() and conn.executeStatement() calls aren’t explicit anymore. They are within your framework. Unless the tool knows your framework, it wont fin issues.
  • Penetration testing – spending time figuring out how to get tools to intercept traffic, doesn’t go fast enough to work with DevOps and Agile.

Showed the diagram that we climbing the wrong hill. We need “Continuous AppSec”

Definitions

  • Portfolio Scale: The right defenses for every application are present, correct and used properly. (you can’t look at thousands of apps manually
  • DevOps speed – applicaton security happens continuously and in real time

An example – clickjacking

  • Want to design a sensor so that if a vulnerability gets injected, we get notified. Could look at headers.
  • Datasource: HTTP, analysis technique: passive, expriment style: positive,environment: test
  • Choose based on speed, accuracy, feedback , scalability, ease of use and cost
  • Rather than an annual PDF per app, you can get data for the entire porfolio. Store in data warehouse so can get dashboard

Jeff wrote a tool: check your headers. Can check headers for common issues against a public website.

Other uses

  • Access control – could have tool generate matrix from code rather than rely on old doc. Help identify missing ones. Ask developers to produce sensors. Can feed into Sonar dashboard. [need standards or per app]
  • Known vulnerable libraries – Run DependencyCheck during every build (OWASP tool)
  • CSRF – run tests trhough ZAP, use ZEST to check CSRF token, get results via ZAP REST API
  • Check correctness of controls – tool don’t even try to validate correct. Write code test first so your tests cover this. Jeff used JUnit.
  • Injection – this is a data flow problem – for example, build an IAST sensor
  • Security intelligence – can gather any information such as outbound connections

What sensors you need

  • most likely to have at least one vulnerability of: identifiaion and authentication, session management. Static analysis companies find XSS because they check for that well
  • Figure out what most important to you

Model

  • Can’t do security testing without a model
  • Testers don’t know model so waste time testing SQL in an app without SQL
  • Risk of not testing things that are needed

Nice Venn diagram to show not testing what we care about. Plus spotty even within the areas that do overlap.

Continuous Application Security
Map business concerns, defense strategies, actual defenses and sensors. Should start with business concerns not sensors. That say a new threat/business priority becomes a sensor and you get data back on it in the dashboard. Real time data, iteration.

Get started by building a sensor and creating a dashboard with Excel. Then can switch to point where can show covers business concerns and can add more based on business.

Business case to do: build sensor ones,get benefits forever. Now, a pen tester IS the sensor and is a very expensive one.

Detecting attack is not the same as detecting vulnerabilities.

Most of the industry is looking at compliance. Want to get to monitoring. Thn can have a strategy and optimization. [Like the levels used by CMM and many other processes.]

We can never improve if our only metric i whether we are doing what everyone else is doing. This wouldn’t work to stamp out a disease and shouldn’t b our approach.

My take
I always like seeing Jeff Williams speak. He is a great speaker and usually presents a unique spin on an idea orr a new idea. I liked the heallth care hook here.