what could go wrong – thinking differently about security at app sec usa

speaker: Mary Ann Davidson

The speaker is from Oracle. I’ve never seen a non-Java or database presentation from them. Even so, I was suprised Oracle doesn’t make her put the standard loong disclaimer on there.

“Translation” is a key skill – ask dumb questions, ask why something is a problem without being condescending
Policymakers need to undertstand issues to make good decision. [otherwise you get policies like “developers can’t use the internet at work”

Analogies help when work. Can be humorous if not
One Little Dutch Boy stops water in dyke. “If only we had 300K Little Dutch Boys” – they will all drown when the dam breaks.
Fridge on network. Forgot password “family of five starves to death, locked out of refrigerator”

Principled vs purist

  • World isn’t perfect. Neither is security.
  • Real metric is whether customers are protected. How fast you patch is less important; customers don’t like patches. Won’t apply if think will break something.

Economics

  • Systemic risk (housing meltdown) – cannot be mitigated. Think about how to avoid systemic risk. The internet was not designed for everything to be on it such as fridges. Doesn’t mean all advances are bad. Have discussions before taking risk
  • Efficient resource allocation – time, money and QUALIFIED people are always constrained. Opportunity cost. If make do something silly, will crowd out more valuable work.
  • Market incentive – One off patches are expensive. Would rather build something new.

Game theory – Prisoner’s Dilemma

  • Should someone defect and sell encryption code to another country? Hasn’t happened

Biology

  • Chemical signaling – what if systems could communicate under attack and update defenses
  • Deception – we have honeypots

Military

  • Network centric warfare – translate information advantage into competitive advantage. Time to live infomation advantage
  • This makes the network itself a battlefield that you need to defend
  • Atacker’s goal is to disrupt defenders ability to wage war and prevent use of IT
  • Tools need to be designed for your threat environment. Don’t want a watergun on the battlefield
  • Situational awareness – who on the network, friend or foe, what i over the hill, etc
  • Defend what is strategic; not everything

Education

  • Can’t start security education too early. “Look both ways before crossing the Internet” – don’t open attahments
  • Universities need to reflect building IT as infrastructure
  • Vendors must educate every CS grad in basiic security and spend millions fixing avoidable preventable desig and code defects
  • CS classes must embed and reinforce security – compared to structures in engineering. It’s part of the circulum, not a one off
  • Have red team/blue team as part of all CS classes
  • Accreditation bdies should force curricula change

Developers are personally responsible for code

OODA (observe, orient, decide, act

  • Stay agile.
  • Can targets be evolving to keep opponents off balance

Solve the right problem. Not everything is a tech problem

Oracle does security with coding standards, training classes, coding standards, checklists. Not optional. When acquire groups, need to start doing. Still have resistance, but have to for cost and brand damage.

My take on this
I liked this session. It’s hard to say what you learned because it is about thinking, but the points raised were good.

html5 security features at app sec usa

speaker: Johannes Ullrich

HTML 5 risky business or security toolchest at app sec usa

HTML 5 is

  • Collection of JavaScript APIs
  • Features to enable modern desktop like applications or support mobile devices
  • Your browser supports HTML 5 even if you don’t use it [well, pieces of it]

Authentication

  • Inclusive authentication – proof of identiy of user
  • Exclusive authentication – disprove the identify of the user – for example, IP address isn’t for authentication bu can be second level such as making sure in network after log in. Similarly can use GPS
  • Half factor – password or token – attack whichever is weaker

[I missed the part about local storage because I was focused on trying to connect to the internet – remember humans can’t really multi-task]

Login with touch

  • Circle fpart of image. Don’t circle faces. Everyone does that.
  • Android has connect the dots where you pick the pattern. Most people pick a common pattern ike the leter C

Biometrics

  • Can do videoconferncing with just HTML5
  • Could use faes, hand signals/gestures or fingerprint
  • Not there yet. Hard to use when insufficient light
  • Can only reognize about 100 different patterns right now for faces
  • Apple not giving access t fingerprint reader yet
  • Ok as second factor, but not ready for primary use. More of a gimmick than an authentication feature right now

Accelerometer

  • Can detect camera moving
  • Too much noise for authentication. Too hard to make same pattern repeatedly
  • Better for detecting whether walking or if on phone

Notifications

  • Only Safari has push notifications with browser closed
  • Local notifications widely supported. Good for finding out if have mail
  • Could use like SMS messages for security. “Someone else logged in as you”. Proactively notify users of security events.
  • Often have to accept acount sharing. Let user decide what to do

URLs:
caniuse.com – what browser support which features
authonthemove.com – has demo

My take
The client side hash is really interesting. It would be nice if browsers would help with/encourage that.

http security headers at app sec usa

speaker: Kenneth Lee

Why care:

  • User security issue
  • Browser impacting change

HSTS (HTTP Strict Transport Security)

  • Use of SSL/TLS for site
  • When send his header, browsers wil guarantee to visit the url
  • User needs to visit the website a least once in order to receive the header.
  • Protect against man in the middle attack
  • But don’t want to make whole site HTTPS – capacity planning assumed less https. Wen ready to make whole site HTTS, this setting becomes deprecated
  • Need to prevent load balancer from always sending batck to http so doesn’t loop
  • He talked about the design Etsy used to implement this
  • Since multiple users can have accounts that use th same machine, set timeout to 0 so dont get other person’s preferences.
  • Browser handles via 302s transparently.
  • Need to make sure your CDN supports it. Similarly for 3rd party content providers. Can’t use off domain HTTP because browser dispays mixed content warnings. Firefox and Chrome block it by default.
  • IE and Safari mobile don’t support yet. Can’t use this header to solve routing problems.

X-Frame Options (XFO)

  • prevent clickjacking/framing website
  • used to have to use JavaScript to avoid being framed.
  • Can use JavaScript to log who framing you (if don’t know) so have list of sites that can frame you. Then you can create whitelist
  • Newer option allow from whitelist. Older browsers don’t support though
  • Warn users if taking away framing. Maybe someone is using it to frame a product. Give alternate way to show content they want to show.

CSP (content security policy)

  • If transfering header on each request, it can get large quickly
  • Doesn’t allow inline JavaScript on a website by defaut.
  • Can’t whitelist inline JavaScript in CSP 1.0. Problem because most apps do have – unless they are quite new
  • Can’t refactor everything right away
  • CSP 1.1 adds browser JavaScript API support.
  • CSP 1.1 adds puting in meta tag rather than a header. Will use as CSP from meta tag unless there already is a header.
  • CSP 1.1 also adds script-nonce (random value) and script-hash (hash of inline JavaScript in question) to allow inline JavaScript. CDN reuires hash because nonce won’t be random.
  • Can use reporting to log blocked element info
  • cspisawesome.com – good website to craft your own policy

X-XSS-Protection

  • Used to be IE specific
  • Now in Chrome too. Added a report URL mechanism
  • Looks for parameter arguments in response
  • This originally was used to break Clickjacking defensive JavaScript

X-Content-Type-Options

  • Defaults to nosniff
  • Older verisions of IE guesed content type even if specified
  • Took advantage of different content type than page author intended to make XSS attack

My take
The code example was really small. He said you could dowload the presentation to follow along but I didn’t have internet at all in this room. Plus a lot of people were taking note on paper without a device. There was was plenty of space on the slide. He could have split the line across and lines and use a decent font size.

The actual content had a lot that I didn’t know which was good. I knew about X-Frame options. The rest was new to me. I had heard about CSP 1.0 when it came out but “you can’t use it if you have any in-line JavaScript” made it a nonstarter.

[this wasn’t posted live due to lack of internet]