Learning from the Enemy: Designing Your Web Service Security Architecture

gistfile1.txt

Title: Learning from the Enemy: Designing Your Web Service Security Architecture
Level: Intermediate to Advanced
Duration: 50 minutes including 10 for questions

Description:
Best practices don't matter once the enemy breaks through your security. What
matters is stopping the enemy. We'll let the enemy show us how.

You've heard of Authentication and Authorization. We'll learn why they do NOT
work with web services. We'll see that OAuth 2.0 does not answer our need.

We'll combine standard practice with lessons learned from our enemy. We don't
need perfection. Instead we'll "raise the bar" high enough that there's too
much effort needed for possible gain.

We'll build in the flexibility needed for further hardening of our web services
in the future, should attacks show that we need to. We'll examine the reasons
for each decision.

You won't see any production security code. It's too sensitive. Instead you'll
walk away with exact steps to implement for yourself, with an understanding of
what's important and why.

Additional Information:
1. This talk is based on my upcoming article in June 2016 php[architect]
   https://www.phparch.com/magazine/ (June link not up yet).
2. Platform experience: I am a new PHP speaker. However, I used to teach Cray
   Supercomputer operating system internals (assembly and octal) as Senior
   Instructor for Cray Research Software Training.

To whomever reviews this Gist: My sincere thanks.

Your engaging writing style and short, direct sentences make this an easy abstract to read. The repetition of "we'll W, we'll X, we'll Y, we'll Z" in lines 9 - 17 is a little distracting to me; you might consider swapping a couple of them for alternate phrasings.

Line 16 confuses me a bit -- into what will "we" be building that flexibility? Is the talk actually a demo of building something? If that paragraph isn't adding anything too unique, you might stick the concept of future-proofing one's security architecture into the paragraph that starts on line 12 and ditch lines 17 and 18 for the sake of brevity.

On the whole, I don't get a clear concept of the format that the talk will take. The final paragraph suggests that it'll be at least partially a list of action items and an explanation of each, but the first paragraph make it sound more like a case study of a specific breach.

It's also unclear to me what specific knowledge an attendee should come in with to get the most out of your talk. I'm afraid that labeling it "intermediate to advanced" without qualifying how you define that could scare off attendees who aren't sure if they know enough to attend. You can address this by specifying what technologies you'll assume knowledge of -- I like the format of "If you've A, B, or C, this talk will help you X, Y, and Z".

It sounds like a good talk, and the voice of your abstract leads me to expect an energetic and engaging speaker. The Cray experience you mention off-hand sounds like a talk or two in its own right -- "___ lessons from the first supercomputers" or something, applying the engineering concepts you used there to pretty much whatever topic you'd like to speak on :)