Nonsense. Defense is plenty fun. Anyone can find a 0-day. The principles and some methods are the same crap as Schell et al did in MULTICS security evaluation they published decades ago. Same kind of stuff Burroughs was preventing in 1961. More interesting was when the old guard tried to build something that couldn't be compromised under any circumstances. Others tried to find and master key areas of the problem. The results were very interesting although not always fun to apply given they could be tedious. Even then, trying to automate that in tooling provided a whole new level of fun to distract one from the tedium. :)

https://www.schneier.com/blog/archives/2013/12/friday_squid_...

Posted above in response to Schneier's call for INFOSEC after Snowden leaks. The title is both a parody on cryptography papers and a trick I used to make sure I can Google a link with a few, unique words. Still works haha. Anyway, that link covers both high-assurance and medium-assurance INFOSEC methods out of CompSci and Defense sectors. Skim through the titles and abstracts then come back to tell me if you still think defense is the boring part.

I mean, really, because I think people think that because "INFOSEC" as you see in mainstream is (a) bullshit or (b) boring. The real deal is constantly innovating, works more than it fails, and quite interesting. To me at least.

"To me at least."

I suppose I wasn't clear. I have fun with it too for the most part or I wouldn't be doing it. But I observe that I'm a rare duck that way.

And the unrelenting stream of bugs caused by the same fundamental root-cause issues over and over again can get old. How many times do I have to see an XSS brought on by using string concatenation on HTML? How many times do I have to see, well, any of several vulnerabilities based on string concatenation before the engineering community actually acknowledges it's a problem? That can grate on someone after a while.

Ahh, you do web applications. Then you might like my summary of state of the art for that:

https://www.schneier.com/blog/archives/2014/04/the_security_...

It's due for an update in near future with resources that a few people here shared with me. Still has lots of interesting stuff, though. Might not help in your day job as you can't dictate the stuff to management or dev team. However, you could enjoy doing it in private on FOSS project exploring those tools or improving/cloning them for others.

There's also projects that try to automate prevention of known classes of bugs. If you find some easy to use, maybe bring it to attention of your management showing they make QA more efficient & liability lower while requiring no extra costs on dev's part. Win-win.

That's an interesting perspective, but some additions:

- the client (i.e. browser), protocol, proxies, etc. are very hard to reason about. For instance, content sniffing and HTTP response splitting should not show up in a sane protocol, yet here we are. An encyclopedic knowledge of - at least - browsers bugs is required to write "secure" web sites.

- type-based safety doesn't do a lot to ensure that e.g. the same-origin policy actually protects your users (i.e. that there is not some unrelated application on the same domain-ish). The public suffix list (https://publicsuffix.org/) is essential to modern web security, and there seem to be no plans to change this.

- "The Tangled Web" is very good (or at least the first half is). It makes me happy I'm not working on the web. ;-)

"the client (i.e. browser), protocol, proxies, etc. are very hard to reason about. For instance, content sniffing and HTTP response splitting should not show up in a sane protocol, yet here we are. An encyclopedic knowledge of - at least - browsers bugs is required to write "secure" web sites."

It's true. I think you could encode a lot of that in a framework or language such as Opa or Ur/Web. What's left is a tiny checklist. Edit to say maybe not tiny but smaller.

"type-based safety doesn't do a lot to ensure that e.g. the same-origin policy actually protects your users"

There's secure, browser architectures that do that in various ways. I'm not sure about the language level. Might need to be combined. Worth thinking about. The publicsuffix website is new to me so thanks.

" It makes me happy I'm not working on the web. ;-)"

You're the second or third to recommend Tangled Web. On my reading list for if I get back into Web development. I'm sure I'll have the same reaction. You might find it funny that a prior commenter found it shocking that I hadn't read work on secure, web applications. Whereas, I originally found it shocking that people were trying to build them.

Perspective changes everything, eh? :)

Let's be honest, Summer Security Camp is far more about socializing with "our tribe" than it is about learning.

That said, understanding how the red team does things is extremely useful for formulating one's own defense.

You're right. But at times it feels like the red team has gotten so far past the blue team that it's hard to learn much from them. The red team is on unicycles juggling flaming torches while keeping three plates spinning and still successfully picking the lock while the blue team is trying to figure out how to take three steps without breaking a leg and flinging the complete contents of their wallet at the nearest brigand, which they are really good at, sometimes nailing the guy from several miles away.

Isn't DefCon supposed to be a play on words named after the defense readiness condition alert state used by the US armed forces?