Infosec's Jerk Problem (2013)

141–142 of 142 posts

Re: Infosec's Jerk Problem (2013)

#141

Post by s_q_b » Mon, May 02, 2016, 10:43 AM UTC

mettamage wrote: post #136

s_q_b wrote: post #24

What is extremely frustrating is the rise of "cyber security" Masters degrees. The vast majority of these people have never written a single line of code. They don't understand security, because they can't understand the underlying logic in the code. They just write documentation to meet certain outside standards, and have no idea what I'm talking about when I talk about our security posture. They genuinely think tha…

Well if that's the case, then times are changing ;) I study at the VU University of Amsterdam and took a couple of courses from the security master track. I had to use libnet to create my own custom TCP/IP packets, libpcap to listen to incoming packets (tcpdump for debugging). Obviously, I did a SQL injection, cross site request forgery, cross site scripting and debugged malware with IDA Pro and later (when it was sa…

Yes, times are changing. These universities offer far less while churning out Masters' degrees. No company I have ever worked for in this area had cybersecurity degrees that could code. Ever.

I work for the National Satellite Operations Facility (NSOF.)

Neither my boss nor the three dozen or so "cybersecurity" folks with whom I've worked have ever written a line of code.

Also, everything you said in the first two paragraphs I either already knew from actual networking security courses, or are trivial. SQL Injection, CSRF, and dynamic executable analysis are unfortunately... Not the most modern techniques... Might as well teach naked buffer overflows.

That said, it's a decent basis. And far far better than what's emphasized on this side of the pond (Mostly policy and automated scanners.)

If what you're saying is truly reflective of "cyber" degrees across the EU, here it's far worse.

It's very frustrating to explain a DNS tunnel to these people, much less how to find a zero day in Cisco IOS.

Occasionally you'll get a hobbyist with some Python or C under their belts, but the vast majority of these "cyber" guys really should just read a book on Kali Linux and sing campfire songs in class for the rest of the year.

Right now these degree programs are turning out graduates that think running Nessus makes them a security god.

Things may well be different in Europe (I'm not going to lie, the Trident and PIN projects sound pretty cool), but it's a nightmare over here.

If you're ever in DC, look me up, we'll have lunch, I'll give you a tour of the facility, and I can introduce you to the cyber guys, and let you draw your own conclusions.

That's a pretty open invitation by the way. Any devs, start up folks or "cyber" people (that won't freak out my girlfriend) are welcome to crash in our guest room for a night or two, if you're in DC for a conference or something.

Re: Infosec's Jerk Problem (2013)

#142

Post by kragen » Tue, May 10, 2016, 8:33 PM UTC

forgottenpass wrote: post #19

One of the root causes seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security. It's not as fun to be a developer that is really into security but only have that be part of your job. Even if it's all you do, if your days are just "analyze, document, harden, repeat," that's a lot less fun than getting paid to pop boxes. I know, because that's w…

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".

Post reply on HN