The funny thing is I quit hacking because it was easy, mostly unimaginative, and repetitive. The high-assurance systems and security fields were much more interesting. Especially the CompSci work. These are about straight-up engineering systems or security methods in ways that they'll always work given a specific threat model. Lots of good stuff came out of that field with things occasionally breaking in new ways due to immaturity of computing discipline. Yet, certain things are well understood to the point that 60's-80's era methods get 80-90% of the job done. Still unknown to most INFOSEC people in mainstream. So, don't worry when they act cocky. :)

Anyway, the market rejected that to maximize profit with buggy software and consumers wanted unnecessary complexity at a rapid pace in every aspect of computing. So, I typically recommend medium assurance solutions these days. Safe-by-default languages, interface checks (esp Design-by-Contract), usage-based testing to keep users happy, fuzz-testing to find lack of input validation, static/dynamic analysis tools, good architecture, good middleware, OS with few 0-days, and so on. These cover you mostly.

What type of apps do you build on what platforms?

EDIT to add: Link below has a link and description to lots of defense techniques that aren't boring at all. What do you think on that?

https://news.ycombinator.com/item?id=11596646

>A root cause seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security.

To expand on this, I've also noticed that "security" in enterprise-size companies tends to be a dumping ground for helpdesk+ staff -- people that can read a CVE or parrot "best practice", but not really grok the subject or think critically about it (e.g. jumping from one password to another every 3 months isn't "more secure"). It's been my experience that people in security teams can't implement the fixes to the things they complain about because if you're a security-minded dev, your career path will be in dev.

>It's not as fun to be a developer that is really into security but only have that be part of your job.

I think it would be ideal to have security as a parallel track to regular dev staff -- with their placement in the ecosystem being between dev and QA. Much like how "devops" was used as a hiring filter to have sysadmins that can at least read code, I think we should have a "devsec" group that bridges security-QA and dev.

> people that can read a CVE or parrot "best practice", but not really grok the subject or think critically about it (e.g. jumping from one password to another every 3 months isn't "more secure")

So much this.

One place I worked had a head of security that switched us to having passwords that auto-expired every 30 days, had annoying requirements (mix of upper, lower, numbers, and special characters) and not allowing reuse of a password for 1 year. The increase in people having problems was handled by having "security questions" and self-service password resets.

My insistence that "security questions" were just unexpiring, easy-to-guess passwords was met with "But this is the standard!". Pointing out that rapid turnover of hard-to-remember passwords led people to write them down generated a similar reaction.

Your statement described my hell.

I put a lot of effort into running environments securely, and eventually, someone always decides to get a second opinion.

The only recommendation I have ever seen come from a security audit in an enterprise, is bikeshedding password lifetimes. Every time I point out "SQL Injection in the logon form" level vulnerabilities, I get directed to the "security experts", which is why I've seen password policies go from 180 days, to 90, to 30, while the mentioned issues get ignored.

People flash a PWC business card and it's seen as credential. Then they drag me to the comms room and spend all day auditing the serial numbers on individual patch leads going to desktops.

You don't need to create a term, you just need to want to hire good people and actually pay for them. With that said, as a security interested dev, I actually work in devops as it's simply the best paying job so maybe a term does need to be created, but if you actually deeply understood security, you'd probably be hiring a devsecops.

I'm also on the defensive side. I went to the last "DefCon", which you'd think expands to "Defense Conference". There was a grand total of one presentation that had defensive elements in it and I still don't recall it being dedicated to the topic.

I don't intend to go back. Great conference, don't get me wrong, I got personal enjoyment out of much of it, but it's impossible for me to professionally justify it.

Defense isn't fun enough, for anybody; neither the one defending, nor the developer who was just told the code the spent a week developing is a gaping security hole, nor the managers being asked to spend money to prevent black swans, nor the open source developers having fun developing frameworks and libraries, and on it goes. It just isn't fun.

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?

Had a good friend and colleague who made an interesting point about how/why a security role can get depressing.

What happens if your security program is really really really effective?

Answer: Nothing

That's the paradox of security.

You can be a security superstar, or a total idiot, and you may achieve the same result!

I could imagine that there would be a Peter principle situation where a successful infosec professional is given progressively more difficult responsibilities as long as nothing bad happens. Is this not the case?

The opposite could come into play at some companies where people start questioning the expense of your salary since you're never having to deal with successful attacks. It's hard to talk up what didn't happen. Then you have people always putting out fires who look like they're "getting shit done."

It often seems like a myth when you hear about that phenomenon, but then I experienced this myself in a different role myself and became a believer.

It could still be the peter principle, and that you need to better communicate your unseen accomplishments. Maybe there should be a modified peter principle, where people rise according to their ability in the job and corporate politics.

Or promoted into management where they implode due to being introverts who can't politic well.

Same problem in IT. It's an inverse recognition problem.

Jobs that involve implementing good security don't exist. That's because there are no customers for good security, because customers can't tell the difference between good security, bad security, and no security, unless they happen to get compromised. Even then, they usually don't notice. Often, they can't even tell the difference after they notice a compromise: they can tell that some of their security was bad or absent, but they can't tell what or how; so often their incident response is useless or actively counterproductive.

This information asymmetry problem means that, in a job implementing supposedly good security, an aptitude for security is not an advantage. In fact, it's a disadvantage, since that aptitude inclines you to do unprofitable things like auditing code, recommending to your customers that they scrap unsalvageable codebases, and staying up late at night patching production servers instead of ironing your suit and getting a good night's sleep before that important client meeting. Total incompetents wearing better suits will be able to bill a higher hourly rate than you do.

Because there are no customers for good security, the entire infrastructure of plausibly securable software that you would need to implement good security also doesn't exist, because the market has failed to provide funding to develop it. Big technical companies (Microsoft, Google), free-software organizations (Debian, Tor), and dedicated individuals (Bernstein, Moxie) have made significant progress, but it's nowhere near being a viable option.

By contrast, I imagine that if you "get paid to pop boxes", you can demonstrate to your customer that you succeeded at it, and you probably can't convince them that you did if you didn't. This means that aptitude and expertise are an advantage in that field. Don't get me wrong: even from this distance, I can see that you're right that the field is still full of the script kiddies who "think [they're] hot shit because [they] found some vulnerable systems on Shodan." But even they are head and shoulders above many of the high-priced security consultants on the defense side from places like Keane or Wipro.

The upshot of all of this is that if you want to secure your network, the best you can do is figure out who the expert attackers are, then convince them that it's worthwhile to secure it. But that's still nowhere near enough to get to "probably secure", much less "assuredly secure".

> that's a lot less fun than getting paid to pop boxes. I know, because that's what I do

Wow, this is an interesting claim. You do this work for a living? Are you ever concerned about getting caught? How do you get paid?

I'm assuming that covering your tracks is some sort of ever escalating cat-and-mouse-game. How do you find out about your adversaries' capabilities regarding investigation after the victim detects the problem?

EDIT: oh, oops. Double-misunderstanding. "that's what I do" meaning "harden,test,repeat" and of course some folks are legitimately paid to do pen testing.

No, I mean to say that I'm on the boring side of the line.

But penetration testing is a job that exists. People are hired to do exactly that under contractual terms with the target. (And I don't mean to imply that's the only security job in the more-rewarding/fun category.)

Rewriting someone else's code to eliminate the potential buffer overflows is a lot less glamorous and exciting than exploiting a buffer overflow to escalate user privileges, in the same way that watching a mason re-mortar an entire brick wall is less exciting than watching a ninja scale that wall, eliminate the guards in complete silence, steal the MacGuffin, and escape without a trace.

But it is steady, decently-paying work that will likely last until the singularity.

What do you mean it's an interesting claim? It makes perfect sense to me, and I'm just a regular old web developer.

Penetration testing is legal.

Oh, yes, of course. I misunderstood!