training developers at appsecusa

speaker: John Dickson

Bruce Schneider wrote in March “I personallly believe that training uers in security is generally a waste of time and that the money canbe pnt better elsewhere”

Developer Training vs User Behavior training

  • both are trying to change behaviors
  • Developers have more power to say no/drive training by releaes
  • For developers, training is infrequent, but more disruptive. User awareness training is 15-45 minutes. Developer class is 1-2 days.
  • PCI DSS requires training

Numbers

  • Metrics rare even for HR training.
  • Turnover 20-30% in software development
  • Training budgets one of first things to cut in bad economy

A research study

  • included 600 developers. 100 had over 3 days of security training, but results didn’t turn out to reflect that. gave 15 multiple choice question quiz
  • “Didn’t want to ask how old they are because shouldn’t matter” [why not?]
  • Over half of developers had over 7 years of experience [we are in one of few inustries where this is considered odd or even worth mentioning]
  • Had hypothesis that finanical services sector would have an advantage, but didn’t score better. Sample size in that sector, too low.
  • Tested both awareness an defnesive coding
  • Largest enterprises had lowest secure coding knowledge. They weren’t the largest banks though. Suspects that would have raised numbers.
  • Architects did best, QA did worst. Developers were in the middle.
  • Most people understand what a XSS error is, but less than 20% know what to do about it. How do you operationalize the application security concepts.
  • Had to throw out 100 results (out of 600) because didn’t complete the uestions. This is common in studies. However, they didn’t fill in the harder questions. Results even worse if you count them as wrong.
  • Higher ed teaching at most one elective on security and likely just covers encryption. [Is it their job to do so? They also rarely cover testing or maiintenance or many other skills that are needed in the real world]
  • Study just did before and right after. Need to do again later to reinforce

How developers learn

  • Companies buy a class or e-learning modules
  • After graduate, people learn informally. Blogs, rss, social media,developer websites, email list, safari online [books aren’t dead]
  • Need refreshers preferably in bite size chunks. Include training in performance planning so developer feels accountable to understand
  • Try to do real world situations as refreshers. Talk about a breech
  • Incentives matter. Saw them making it more likely for people to fill out the survey. Even for a captive audience.

Survey will become a whitepaper.

“Need to sales/market the dev teams”

My take
Good session. The research study was interesting. I wish here was more time to go into that. There’s good talking points in it. I certainly agree on the need to customize training.

browser security at app sec usa

(missed the beginning of this, but apparently not too much. it was standing room only; was lucky to get a seat)

speaker: Robert Hansen

What is wanted

  • Google wants higher ad spend
  • Advertisers want to monetize users
  • Users want quality products and better search results
  • Everyone wants faster performance

Goal: protect sensitive info

Why Tor browser not solution

  • admitted to 100 hacked nodes. know there are more
  • “Grandpa” sends info over http instead of https and then hacked node hass it
  • Can’t do everything anonymously. Anonomous != privacy

What willing to give up for security

  • Usability – speed, bookmarks, autodfill,prefetching
  • Most popups and warnings (“do you want to allow scripts” is useless)

Problems/Current Solutions

  1. XDomain – request domain,no script. port locking,, remove credentials upon logout (limits what CSRF can do), split horizon dns (don’t let internet to see internal dns)
  2. command execution – nocript plugin, quickjava plugin, remove protocol handlers (“are you sure you want to run”), sandboxie (for windows), antivirus (incremental gain if have extra cpu; just don’t rely on it), whitelisting. Many techniques are like an onion. Protection in layers. VM, sandbox, striped down browser.
  3. Data exfiltration and privacy – disable Aero tranparency on Windows 7 so can’t see what behind window
  4. Man in the iddle – SSH, proxies, VN tunnel
  5. Pretext/phishing – NoScript, education. If don’t reuse passwords, it isn’t tgat helpful for someone to get it.

Plugins the speaker users

  • NoScript
  • FoxyProxy
  • RequestPolicy
  • QuickJava

However, to actually be secure, the web looks like 1996 – everything is text. But Lynx isn’t enough because nneed the ability to turn on.

Do Not Track

  • Sends a signal to websites that don’t want to be tracked
  • Three states
  • #1 complaint about IE 10 is that doesn’t respect the spec
  • Most browsers implement only 2 states – track or not at all
  • Firefox follows spec – do no track, track do not tell sites about my security preferences (which is confusing)

Future

  • More than 95% of browser revenue now comes from ads. Google paying almost $1B to be default search in Firefox.
  • Google attacking ad blockers.
  • locally sourced ads, require JavaScript to view websites, regulation in response to consumers.

Tool: Aviator for Mac to make more secure/private

My take on this
This was a lot of information in the part about his browser setup. I’m glad I know enough to be able to understand most of it! Some of it felt theoretical in that the perfect browser doesn’t actually. But I was surprised at how much technology exists to solve the problems we have. And the parts about advertisers influence were interesting.

keynote: security: i think we can win – app sec usa

speaker: Bill Cheswik

  • the sci fi authors of the 50’s didn’t come close to reality
  • Advanced persistent threats aren’t advanced. Buffer overflow, etc are known
  • the order of things is to make something new work and then figure out security – predicts security problems in Obamacare data handling
  • UI is sill evolving. touch is only a decade old
  • Old Microsoft menus are too slow. Can’t get faster at them like with UNIX. [lesson: support multiple levels of skill]
  • prefers “grapes to raisins” instead of “apples and oranges”
  • You don’t have to be a mechanic to use a car. But now adding a computer to your car. CAN bus “it just works” can be hacked by bad mp3 files. [Eek!]

Current state of affairs

  • The fact that we do banking and shopping (money) online shos the internet is working,
  • The current state of affairs is still lousy
  • Certain thing needs to work regardless of “what grandma does wih the keyboard”. It isn’t grandmas fault. She shouldn’t be ABLE to do something wrong.
  • We are all “grandma” at some point
  • Checklists , virus checking, strong user passwords and user education aren’t enough to solve bad engineering.
  • A virus checker finds evil software on a machine. It’s too late at that point.
  • Shared and dynamic libraries meant to save memory when we were memory constrained to share common OS binaries. We aren’t memory constrained anymore. Don’t need these binaries considered trusted as side effect of this anymore.

What does victory look like

  • OS that can’t be changed or subverted regardless of app or user action
  • Apps can’t tained OS can limit to signed and approved apps

Metrics

  • People want a number. But what is it measured in? Lines of code? Connectivity to Internet. (reference “an attack surface metric”)

    Metric 1 – setuid

  • Kernels talk to the world. Programs talk to the kernel. The diagram is usually shown th eother way
  • Quick way to rate UNIX system security: look for setuid programs as root that aren’t needed. Why need etra holes at the bottom of the boat.
  • Considers this # (5 in this case) to be a measure. [one is su though which seems like a door to anything]

Metric 2 – number of network services available to outside

  • Again, more than you think

Metric 3 – how muc will someone pay for a zero day exploit

  • Adobe Reader and MAc are low. iOS tops list with Firefox and Chrome blelow it
  • This is a factor of how security it is (how hard to find an issue) plus how desirable he platform is to find an error in
  • Predicts Android will have more issues because open source and hard to have displine when too many people finger in it.

Keep it small

  • Keep software simple/li>
  • Google’s Go language uses this small/fast is better principle

What works

  • CPU speed is a tool
  • Could use ores as separate machines with separate cache and memory
  • Personal responsibility for the code. Such a Kunth’s personal checks for finding a bug. [I actually did this at work. I wanted to prove i was possible to fix a certain issue reliabily. I offered my teammates $1 for each issue they found in that space. It cost me exactly $1.]
  • Literate programming.
  • Software”annealing” – just fix bugs and don’t make other changes for a long time. This is why sendmail and other old programs are stable
  • Strong type checking. Pascal style, not C
  • Virtual machines where line is between kernal and hardware
  • If you have other controls, a 4 digit PIN is fine

Excuses

    li>People write buggy code. Too many requirements. Too much change

  • Governance is a big concern
  • Still have DDOS
  • We have home field advantage
  • Believe we can win

Reference to Dean Kamen for doing security well in products – insulin pumps and wheelchairs [and segways]

Tool:
CertPatrol on Firefox – see what certs used

My take on this:
Good start to the conference. This situation is part of why my mother’s computer is a Chromebook. You can’t install software. If you mess up, you can easily reimage and not lose data or settngs. It’s not perfect, but it is closer.