8 ms·
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
by forgottenpass 11y ago
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 what I do.
That disinterest is the entire raison d'etre of I am The Cavalry. From their webpage:
No one is rising to meet these challenges. The cavalry
isn’t coming. We are the domain experts and we are the
adults in the room. It falls to us. We Are The Cavalry.
The less-charitable interpretation of this is "Hey dummies! If we all want to play red-team, who the fuck do we think is left over to fix things?"
I went to a two-hour presentation at $serious_security_conference on $my_product_domain. I was really excited to see what there was for us. We're not running webapps on racked pizza boxes, so there is a lot of topics in our systems that aren't really explored in public security literature. Instead all I got was some dummy thinking he's hot shit because he found some vulnerable systems on Shodan. I got angry enough to walk out, and then went back thinking there was probably some value to be had. 3 times.
- wyldfire 11y ago> 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.
- draw_down 11y agoWhat do you mean it's an interesting claim? It makes perfect sense to me, and I'm just a regular old web developer.
- vox_mollis 11y agoPenetration testing is legal.
- wyldfire 11y agoOh, yes, of course. I misunderstood!
- forgottenpass 11y agoNo, 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.)
- logfromblammo 11y agoRewriting 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.
- mjolk 11y ago>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.
- technion 11y agoYour 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.
- ownagefool 11y agoYou 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.
- ergothus 11y ago> 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.
- jerf 11y agoI'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.
- nickpsecurity 11y agoNonsense. 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_bl_404.html#c2902272 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.
- jerf 11y ago"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.
- nickpsecurity 11y agoThe 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 https://news.ycombinator.com/item?id=11596646
- icaruswings 11y agoHad 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
- Spooky23 11y agoThat's the paradox of security. You can be a security superstar, or a total idiot, and you may achieve the same result!
- vvanders 11y agoSame problem in IT. It's an inverse recognition problem.
- bgilroy26 11y agoI 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?
- TheCowboy 11y agoThe 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.
- deadtofu 11y agoOr promoted into management where they implode due to being introverts who can't politic well.
- kragen 10y agoJobs 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".