Ask HN: Any tips for a programmer wanting to switch into security?
113 comments
My advice is to stay as a software engineer, and slowly move towards secure software development. 98% of the security world is complete and utter bullshit, and no one is interested in actually securing anything. Ever wonder why EVERY bank has terrible 2FA practices? It's because they don't care. Same with law firms, hedge funds, governments, etc. Yes you can get great job security with security, but at the end of the day you simply won't be producing anything of value unless you are in the top 2% of the field.
Secure software development is different. Go make high quality software for firms that write in functional languages and use advanced methods for ensuring high code quality and safety.
Source: I did penetration testing for four years, also served in a cyber position in the military. What a giant waste of my time that whole effort was.
Secure software development is different. Go make high quality software for firms that write in functional languages and use advanced methods for ensuring high code quality and safety.
Source: I did penetration testing for four years, also served in a cyber position in the military. What a giant waste of my time that whole effort was.
I'm a burnt out security focussed software engineer of 9 years. I worked at 2 well-known Bay Area tech companies. The first 7 years were incredibly rewarding, but now I'm taking a year off the job market. At the end of my tenure, I felt like I was a few days away from being committed to an insane asylum.
Doing anything security related is amazing if you work with the right people, but more often than not the amount of snake oil and petty politics is intolerable, more so than in any normal software engineering gig.
I know a few incredibly competent ex-Uber security software engineers at Uber (disclaimer: I never worked there), who reported to Joe Sullivan, a former federal prosecutor with no technical knowhow whatsover, now facing criminal charges [1]. They're very traumatized from the incident. Trust me, this sort of sleaze is on par for the course at security orgs in major Bay Area tech companies.
[1] https://www.nytimes.com/2020/08/20/technology/joe-sullivan-u...
Doing anything security related is amazing if you work with the right people, but more often than not the amount of snake oil and petty politics is intolerable, more so than in any normal software engineering gig.
I know a few incredibly competent ex-Uber security software engineers at Uber (disclaimer: I never worked there), who reported to Joe Sullivan, a former federal prosecutor with no technical knowhow whatsover, now facing criminal charges [1]. They're very traumatized from the incident. Trust me, this sort of sleaze is on par for the course at security orgs in major Bay Area tech companies.
[1] https://www.nytimes.com/2020/08/20/technology/joe-sullivan-u...
Wow, I didn't know about the Uber cover up. Thanks for sharing.
Thanks for sharing that. Aging vulnerability researcher and reverse engineer here and it is both amazing and disheartening to see what most of security work has turned into.
Layers and layers of policies, procedures, and abstractions that mean no one is ever accountable for anything and anyone who knows the details is marginalized as being too much “in the weeds” so they’re left out of the conversation.
Layers and layers of policies, procedures, and abstractions that mean no one is ever accountable for anything and anyone who knows the details is marginalized as being too much “in the weeds” so they’re left out of the conversation.
could you list some example technologies that exhibit these issues?
CIO in financial services here. Most security activity is/will be driven be external forces. Auditors, regulators, etc. This tends to drive organizations towards “checklist” security. Real security professionals know that it’s not really about “can we check the MFA box” it’s about HOW we implement MFA. Unfortunately, that discussion gets squeezed in favor of “we have to close this finding by the next risk committee meeting...”.
> This tends to drive organizations towards “checklist” security.
I have seen the pharmaceutical manufacturing equivalent of this. No one actually cares about microbiological surveillance of drugs for animals, they are just forced to pretend to because otherwise they get in a lot of trouble.
I have seen the pharmaceutical manufacturing equivalent of this. No one actually cares about microbiological surveillance of drugs for animals, they are just forced to pretend to because otherwise they get in a lot of trouble.
Exactly this. Software development and security are basically the same thing. If you’re not writing secure software, and you don’t understand enough about network layers to secure them, then you have a lot to learn just to get your knowledge up to par with a lot of devs/arch’s/“security people”
>Software development and security are basically the same thing.
There is an entire universe worth of knowledge in the security space that has nothing to do with software development. I'd agree that 98% of the security world is "bullshit", but one of the reasons every company has such awful security is specifically because too many people think "software development" == "security", and this narrow mindedness means they end up failing to accomplish any of the security pillars that have nothing to do with software development.
There is a lot of overlap specifically with secure development and software development, but saying "software development and security are basically the same thing" is naive. I like to compare it to a company's legal team: if you're going to court over a technical topic, you definitely want some people on your legal team that have software experience and you definitely want your general counsel to be technically educated, but that doesn't mean you're just going to take a software developer and make them your general counsel. You still need an actual lawyer, because there is an entire universe of law-related knowledge that you need that a software developer doesn't know.
There is an entire universe worth of knowledge in the security space that has nothing to do with software development. I'd agree that 98% of the security world is "bullshit", but one of the reasons every company has such awful security is specifically because too many people think "software development" == "security", and this narrow mindedness means they end up failing to accomplish any of the security pillars that have nothing to do with software development.
There is a lot of overlap specifically with secure development and software development, but saying "software development and security are basically the same thing" is naive. I like to compare it to a company's legal team: if you're going to court over a technical topic, you definitely want some people on your legal team that have software experience and you definitely want your general counsel to be technically educated, but that doesn't mean you're just going to take a software developer and make them your general counsel. You still need an actual lawyer, because there is an entire universe of law-related knowledge that you need that a software developer doesn't know.
Exactly. Small stuff like having separate cloud accounts for different environments like prod and dev, enforcing MFA and password rotation, having separate ACL roles for different services with minimal permissions, basic antiphishing training, and so on are all low hanging fruit that few software engineers have the knowledge of and even fewer have the political capital to implement unless its handed down from the ops team.
Instead defense in depth works best when the software engineers are treated as benign manifestations of hanlon's razor.
Instead defense in depth works best when the software engineers are treated as benign manifestations of hanlon's razor.
I thought password rotation is considered outdated.
It is. The watershed publicity moment was in 2010, when the research paper came out.[0] It took another 6-7 years before the news percolated high enough in the political chain, and now both NIST and NCSC recommend against the outdated practices. And the infosec community had been arguing against the stupidity for what, 20+ years?
Now, there is a place for rotation - when the so called password is in reality a shared secret. (Eg. the secrets in payment gateways.) Such things need to be rotated, because the basic assumption is that they will be compromised. No matter what you do, someone will copy-paste a long-lived secret to the wrong place at some point.
0: https://www.cl.cam.ac.uk/~rja14/shb10/angela2.pdf
Now, there is a place for rotation - when the so called password is in reality a shared secret. (Eg. the secrets in payment gateways.) Such things need to be rotated, because the basic assumption is that they will be compromised. No matter what you do, someone will copy-paste a long-lived secret to the wrong place at some point.
0: https://www.cl.cam.ac.uk/~rja14/shb10/angela2.pdf
Thanks. What I find the worst about 'must not be similar to past pw' is that you have to store the pw in plain text somewhere (or at least retrievable).
An alternative to storing the pw in plain text is to ask the user to provide their current password at the same time as the new password. The password change routine can then check the current password is correct (which protects against the threat of an attacker coming across an unlocked terminal with a logged-in session and changing the password) and provides the current password against which the new password can be compared.
In my experience, security roles have more to do with the practices of risk management than anything else. With security policy and compliance roles also requiring an element of jurisprudence.
Computer Science is Security... Bruce Schneier agrees with your view: https://www.schneier.com/blog/archives/2016/06/computer_scie...
My perspective as a software engineer is that security is a much more technically challenging field that SWE. Is this true? Is security just smoke and mirrors? And why is SWE so much better remunerated?
Because so much of the function of the department is social. They create rules and communicate them. Their approval is often required on projects but they add little value otherwise. The position exists to provide cover.
Often we think security as a team in a constant battle with hackers and rival corporation forces but in reality you will mostly be spying on employees and setting policy.
Often we think security as a team in a constant battle with hackers and rival corporation forces but in reality you will mostly be spying on employees and setting policy.
It's better remunerated (to the extent that it is, obviously some people make fortunes in security) because products make money and security costs money.
As a security engineer, i dont think so. Its definitely different, and because there are less of us it makes it seem we are more specislized. However i've met tons of SWE working on hard problems that don't make sense to me, and can code circles around me. The level of technical challenge in both fields depends what you are working on. Plenty in security is also trivial.
Same for security and audit processes. Most of these are a largely pointless waste of money and time. Some are well-intentioned, but utterly impractical to the point of questioning the well-intentioned part (e.g. "all releases of all software needs to be audited").
Not to mention many auditors have minimal understanding of the stuff they check on. On a number of occasions I had to explain how the system worked to the auditor, and what's worse - they seemed to be OK with me just explaining that, without any double-checking.
That's where they need better-educated, or more capable auditors.
I used to do PCI auditing for organizations that handled credit card data. The course was a two-day joke, and they relied at the time on some stated level of prior experience.
Clearly, the class was intended to give you knowledge of what's required, and how some processes worked, but you were expected to know the security stuff first.
While I was not a huge fan of the organization, I was somewhat more satisfied when I could help the clients with reasonable analysis of their controls, and where they'd fall down (regardless of tick-box compliance.)
I used to do PCI auditing for organizations that handled credit card data. The course was a two-day joke, and they relied at the time on some stated level of prior experience.
Clearly, the class was intended to give you knowledge of what's required, and how some processes worked, but you were expected to know the security stuff first.
While I was not a huge fan of the organization, I was somewhat more satisfied when I could help the clients with reasonable analysis of their controls, and where they'd fall down (regardless of tick-box compliance.)
> 98% of the security world is complete and utter bullshit, and no one is interested in actually securing anything
As someone who did it for six years before leaving for better things, I couldn't agree more. It really is a circus that sells feelings at best.
As someone who did it for six years before leaving for better things, I couldn't agree more. It really is a circus that sells feelings at best.
From an executive management point of view, security incident insurance is often seen as cheaper and safer than investing in actual security. That often leaves compliance as the only real security emphasis.
Yep, and then when the insurer declines to cover an incident because the company neglected proper security, you do NOT want to be the person with "security" in their title.
I was in the same position as OP...subscribed to 2600 as a high schooler (maybe I'm on a list)...then after college became a software engineer w/ interest in security. Even got a Security+ certification 10 years ago. Afterwards, I learned most of the security work is policy...at least, that's what people that I knew in the field told me.
Now I'm still a software engineer and get the occasional rush when I need to fix something that our Fortify scanner picks up (rarer now, since we rely so much in frameworks nowadays)
Now I'm still a software engineer and get the occasional rush when I need to fix something that our Fortify scanner picks up (rarer now, since we rely so much in frameworks nowadays)
> EVERY bank has terrible 2FA practices? It's because they don't care.
Good point, but its more they tradeoff losses vs convenience. HSBC pushed a hardware security fob for every time you wanted to check your balance. It was a PITA until they relented. If they kept requiring the device for every log in I'd have closed my account.
Good point, but its more they tradeoff losses vs convenience. HSBC pushed a hardware security fob for every time you wanted to check your balance. It was a PITA until they relented. If they kept requiring the device for every log in I'd have closed my account.
Relevant blog post: https://www.go350.com/posts/they-want-us-to-be-compliant-not...
Good advice.
Security is a vertical that tends to attract really really smart people and people looking for a landing zone, functioning as unaccredited auditors or folks performing monk-like transcription of NIST or compliance guide. There’s no middle.
The only really technical person I know who is really happy in the space transitioned into a security-focused solution architect type role with a VAR. But he is one of those rare people who is very deep in a few tech disciplines AND loves engaging with people.
Security is a vertical that tends to attract really really smart people and people looking for a landing zone, functioning as unaccredited auditors or folks performing monk-like transcription of NIST or compliance guide. There’s no middle.
The only really technical person I know who is really happy in the space transitioned into a security-focused solution architect type role with a VAR. But he is one of those rare people who is very deep in a few tech disciplines AND loves engaging with people.
I've worked with a number of people who land in "the middle" IMO. These are application security engineers hired to staff the security teams at companies building normal b2b or b2c products. Their job is a mix of hands-on fixes in application codebases, triage of reports from external researchers, and scripting/building their own systems. They're coders who remain practical, not world-class cryptographical researchers nor spreadsheet jockeys, and they're darned useful to have in place at companies where you can't expect every developer to maintain up-to-date deep domain knowledge of the security landscape.
I've had that role twice! For me, perhaps I just haven't found the right place, it starts out as the best job I've ever had and then ends up being a terrible slog. Developers stop caring, management does the math and finds it easier to have you on staff but doing nothing really important because you keep making the dev team fix their SQL injections or XSS and they miss features and blame the fixes that you pushed for, and then you spend 90% of your time chasing dev's to update their libraries and you want to harm everyone. It's just a tough road to work if you are at all a creative developer that wants to see something you have built. I REALLY wanted to love that job but even for good companies it's very hard to find a good situation in my experience.
Same here. You're just outnumbered, and because of that you're often seen as having unreasonable requests or point of view. I don't think anybody who works in a security team is happy, it's a shit job honestly. The less you do, the happier your devs are. And at the end of the day, you look back at the years of work you've done, and there's nothing to show. No building, it was just about pushing through friction.
That’s fabulous! Seems to be a hard role to find in many companies.
[deleted]
> Source: I did penetration testing for four years, also served in a cyber position in the military. What a giant waste of my time that whole effort was.
But the money must've been really, really good.
But the money must've been really, really good.
Security jobs usually pay worse (if not much worse) than SWE of same or even lower level.
Why functional languages? I have some experience with Haskell via a class I took in uni, although we didn't go into detail re: security.
Not in infosec but probably b/c you‘d have to jump some hoops to get your code to have "side effects" with functional.
So from a security perspective it's way easier to review/audit functional code.
So from a security perspective it's way easier to review/audit functional code.
Yes in general a pure function that takes in data and returns a result without reaching out of the function itself (in general that's a side effect) is usually more secure. There are certainly exceptions to that rule, like parsing data formats however. Also most pure functional languages make you isolate side effects which makes security auditing easier. For example I was an application security engineer for both a ruby company and an elixir company, both of which I'm sure you have heard of and both had excellent developers. The ruby shop (which in general I'd say had a higher talent level) had far more security issues in the code than the elixir team. Both had vaguely similar use cases and threat modeling also. I do believe that functional programming tends to lead to more secure code.
Why was it a waste of time? If you found just 1 security flaw that could’ve resulted in a ransomware attack, wouldnt it have been worth it?
Here is an example from my career: I once found a SQL injection at a large internet company (I won't say which one) that dumped user accounts including hashed passwords, email addresses, comment history, and a ton of even more sensitive data. The management of this company did the math and said the risk of someone maybe finding it vs the cost of the dev team missing a feature deadline made the vulnerability less important to fix. The sad part is that they were proved correct. The dev team finished the feature and then merged in my fix for the injection (it was a relatively large fix involving a large constructed SQL statement and I wrote it in my off hours because I couldn't just leave it). No one found the issue and the feature landed them new business. In the end they got what they wanted, the fix and the new business, because I gave up extra hours. That's when I decided that app development better suited me.
Depends.
Security flaws are not created the same. Mostly they are hypothetical. A buffer can over flow and smash the stack, but what then?
A security flaw that costs a million dollars to find and has very little chance of being actually used is not worth finding. But when you start looking, you do ot what you will find.
Like most things, ity is a trade off
Security flaws are not created the same. Mostly they are hypothetical. A buffer can over flow and smash the stack, but what then?
A security flaw that costs a million dollars to find and has very little chance of being actually used is not worth finding. But when you start looking, you do ot what you will find.
Like most things, ity is a trade off
Thanks for sharing. Do u think reverse engineering in a certain field (e.g. Hardware or Windows applications) could be a better path?
> for firms that write in functional languages
What does the language being a functional language have to do with it?
What does the language being a functional language have to do with it?
If I had to guess, they're likely referring to the lack of side-effects in some functional languages. This makes it a bit easier to formally verify the correctness.
What's funny is that some of these languages lack types, which makes it a whole lot harder to secure.
So it's not just about being functional.
So it's not just about being functional.
got any fun Red Flag stories?
I'm a security researcher. From my vantage point:
* There's a world of difference between the work I do and the world of pentesting. Are you interested in building secure systems, researching ways to secure (or break) systems, or applying security techniques? That answer to that will probably inform the kind of security track you want to head down.
* IME, the best security engineers are diligent software engineers. Others have already said it, but: good software engineering is secure engineering, and the skills you pick up as a normal engineer who thinks a little bit harder about security will take you much further than a certificate or special training in security itself.
* There's a world of difference between the work I do and the world of pentesting. Are you interested in building secure systems, researching ways to secure (or break) systems, or applying security techniques? That answer to that will probably inform the kind of security track you want to head down.
* IME, the best security engineers are diligent software engineers. Others have already said it, but: good software engineering is secure engineering, and the skills you pick up as a normal engineer who thinks a little bit harder about security will take you much further than a certificate or special training in security itself.
Thanks for the comment. You answered my question before asking. I was looking for how best to transition but it sounds like just interest and diligence is fundamental.
Don't do it. Execs see security as pure cost, so your head will be on the block every time they need to trim the budget. There's also constant pressure to offshore it since it's not a core competency unless your company is a cybersecurity consultancy.
And as others have pointed out, unless you're top 2% you'll be running scripts until you're required to train your outsourced replacement.
And as others have pointed out, unless you're top 2% you'll be running scripts until you're required to train your outsourced replacement.
+1 being on the "build stuff to increase revenue" rather than "build stuff to decrease costs" side of the business is anecdotally a path to general developer happiness.
To business leaders, security neither drives revenue nor decreases costs; it's just something you've gotta meet the minimum bar on as cheaply as you can. That's not the team you want to be on.
I have nothing more to add than up-vote this and parent comment.
Execs don't get bonuses nor career tracks through good security. And it's hard to make a career or professional friends in the org by telling people they are doing things wrong.
And all the fantabulous security breaches we have had through the years have failed to sink a single company. Concentrate on "products that drive value" unless you already enjoy the security field and can't imagine your life without it.
A long time back, personal story: was excluded from certain exec meetings for a time after I brought up that a simple website scan showed multiple vulnerabilities, which should probably be fixed before our big upcoming pitch, so as to avoid a highly probable deface and embarrassment. Tried to fix it through email for 2 weeks before then, went public in the org as a last ditch effort to prevent damage. Only thing it damaged was my prospects in that org. They took it as an insult and not loyalty to the org.
And all the fantabulous security breaches we have had through the years have failed to sink a single company. Concentrate on "products that drive value" unless you already enjoy the security field and can't imagine your life without it.
A long time back, personal story: was excluded from certain exec meetings for a time after I brought up that a simple website scan showed multiple vulnerabilities, which should probably be fixed before our big upcoming pitch, so as to avoid a highly probable deface and embarrassment. Tried to fix it through email for 2 weeks before then, went public in the org as a last ditch effort to prevent damage. Only thing it damaged was my prospects in that org. They took it as an insult and not loyalty to the org.
> And it's hard to make a career or professional friends in the org by telling people they are doing things wrong.
This is a really good point. Every one will cringe when they see you coming, and that's going to drag on your career.
This is a really good point. Every one will cringe when they see you coming, and that's going to drag on your career.
The contacts I have that are successful professionals in security work as gun-for-hire consultants. They are contrarian, enjoy pointing out shortcomings, and, being consultants, don't have to stay after their report is delivered.
That makes a lot of sense. Good input for the OP.
This is my exact experience also as a app security engineer and the reason I now longer work in that field. If you are good, then most of the time you are the boy who cried wolf or people forget you exist. If you are bad or learning and something happens you are the fall guy for everything. It's not a job that I'd jump back into unless I had a rock solid personal reference for a company that cared about security deeply.
Thank you for sharing your experience. Needless to say, everyone's experience will be different, but, especially for security work, it is important to think about core factors in implementation: policy and psychology. If you are not associated with "winning", and are a "nagger" vs an "enabler", this diminishes prospects.
Good execs understand that security is risk management. I've found that this is better understood outside startups trying to hockey-stick. Finance in particular is a place where reasoning about risk often comes naturally to leaders.
I'll grant you that finance is an exception because risk management is the whole game. Other than that though it's just standards-based box checking.
On the other hand, companies need compliance so they pay out the ass for SIM tools they will basically never use.
I’ve worked in computer security for over 15 years as an engineer. In my case I often work closely with threat researches building infrastructure or things to make their lives easier (eg automate or detect the “easier” attacks so they can focus on the novel). I’ve had the same Internal career debate recently, in my case going back to roots. I enjoy CTFs and working with our threat researchers. With this skill set I figure out how to scale them. If I know more, can I help more? Probably.
Beyond general security it sounds more like you’re interested in the blue team side (defense). To that I’d look into things like https://cyberdefenders.org/ hack the box and other CTF work first. OSCP is nice and maybe even mandatory for pen testing (Hr) but hands on is key. From there you can figure out if certain are worth it to you. The ejpt is a cheaper starter as well.
In practice you need both technical skills and report writing skills. You have to tell a security story to technical and non technical people. The better you are at both, the further you can go. As a counterpoint, we still have a hard time finding solid security minded engineers. You can be a triple threat :)
Beyond general security it sounds more like you’re interested in the blue team side (defense). To that I’d look into things like https://cyberdefenders.org/ hack the box and other CTF work first. OSCP is nice and maybe even mandatory for pen testing (Hr) but hands on is key. From there you can figure out if certain are worth it to you. The ejpt is a cheaper starter as well.
In practice you need both technical skills and report writing skills. You have to tell a security story to technical and non technical people. The better you are at both, the further you can go. As a counterpoint, we still have a hard time finding solid security minded engineers. You can be a triple threat :)
Note: I'm a security engineer. Have been doing security work for ~15 years now.
Penetration testing is a good way to get real security experience. You'll learn pretty quickly just how vulnerable everything is and how attackers use the tools to exploit said vulnerabilities. If penetration testing is your job though know that it doesn't often pay very well. Most companies that hire "penetration testers" are really just looking for folks to run a bunch of scripts/tools against a list of IP addresses/hostnames and generate a template-based report. That is tedious, mindless work.
There's "security consulting" too which often involves at lot of actual penetration testing (not just running scripts) and that can pay pretty well but probably not as much as you'd think. The real money in security consulting is in governance work, sadly (because it's not as fun haha). There's a million companies offering "penetration testing" (even if its awful/useless) so the price for that has been driven down quite a lot of the years but companies offering consultants that can write your company's security policies and procedures are much more rare (and expensive!). That's why one pays better than the other... Even though becoming a good penetration tester requires 1000x more knowledge and experience than the skills necessary to write a policy document.
Penetration experience is important though if you want to be serious about security. I think penetration testing experience is so important that I'd say that anyone that claims to be a Chief Information Security Officer (CISO) that hasn't performed some form of penetration testing doesn't have the requisite knowledge to do the job. They're an imposter, IMHO.
At the very least learn how to use Metasploit and actually use it to successfully run a payload on something (anything). Then--rather than getting a job as a penetration tester--I'd use your software engineering skills to develop some security tools. For example, there's a huge gap in the market for open source password management tools (think CyberArk, not Hashicorp).
Penetration testing is a good way to get real security experience. You'll learn pretty quickly just how vulnerable everything is and how attackers use the tools to exploit said vulnerabilities. If penetration testing is your job though know that it doesn't often pay very well. Most companies that hire "penetration testers" are really just looking for folks to run a bunch of scripts/tools against a list of IP addresses/hostnames and generate a template-based report. That is tedious, mindless work.
There's "security consulting" too which often involves at lot of actual penetration testing (not just running scripts) and that can pay pretty well but probably not as much as you'd think. The real money in security consulting is in governance work, sadly (because it's not as fun haha). There's a million companies offering "penetration testing" (even if its awful/useless) so the price for that has been driven down quite a lot of the years but companies offering consultants that can write your company's security policies and procedures are much more rare (and expensive!). That's why one pays better than the other... Even though becoming a good penetration tester requires 1000x more knowledge and experience than the skills necessary to write a policy document.
Penetration experience is important though if you want to be serious about security. I think penetration testing experience is so important that I'd say that anyone that claims to be a Chief Information Security Officer (CISO) that hasn't performed some form of penetration testing doesn't have the requisite knowledge to do the job. They're an imposter, IMHO.
At the very least learn how to use Metasploit and actually use it to successfully run a payload on something (anything). Then--rather than getting a job as a penetration tester--I'd use your software engineering skills to develop some security tools. For example, there's a huge gap in the market for open source password management tools (think CyberArk, not Hashicorp).
Naive question from an outsider with an interest in understanding pentesting and information security (mostly out of curiosity, but also to contribute to projects with security in mind): do you think putting time into a cert like OSCP is worth it?
Not arguing about any kind of market or resume worth, but more so about the actual value provided by the path to complete that cert.
Not arguing about any kind of market or resume worth, but more so about the actual value provided by the path to complete that cert.
if you're doing it to learn: yes
if you're doing it for the creds: no
if you're doing it for the creds: no
>> The more I learn about the networking side the more interested I am in how to secure this, and I'm less interested in writing code.
Be warned, most 'security' jobs are running scripts and programs and filling out checklists. If you were interested in writing code I'd suggest books like Reversing: Secrets of Reverse Engineering or Hacking: The Art of Exploitation
That said, a good way to get into it is to find any kind of local user groups, either in industries or at colleges, and find ones that offer security classes and do capture the flag (CTF) events.
Here's one in Michigan, for example:
https://www.merit.edu/security/training/
This is a good way to get familiar with the tools you would be using and even better, a good way to meet other people in your area who might know of job openings and such.
Here are some details on CTF events:
https://cybersecurity.att.com/blogs/security-essentials/capt...
Be warned, most 'security' jobs are running scripts and programs and filling out checklists. If you were interested in writing code I'd suggest books like Reversing: Secrets of Reverse Engineering or Hacking: The Art of Exploitation
That said, a good way to get into it is to find any kind of local user groups, either in industries or at colleges, and find ones that offer security classes and do capture the flag (CTF) events.
Here's one in Michigan, for example:
https://www.merit.edu/security/training/
This is a good way to get familiar with the tools you would be using and even better, a good way to meet other people in your area who might know of job openings and such.
Here are some details on CTF events:
https://cybersecurity.att.com/blogs/security-essentials/capt...
(not OP)
Thanks for you book suggestion, would you say it's a bit dated now?
I found this: https://www.youtube.com/watch?v=3Kq1MIfTWCE&list=PLt_s8-zoCd...
It seemed like a decent introduction, I am a beginner programmer/developer (doing Odin project at the moment and only done some small projects before).
Thanks for you book suggestion, would you say it's a bit dated now?
I found this: https://www.youtube.com/watch?v=3Kq1MIfTWCE&list=PLt_s8-zoCd...
It seemed like a decent introduction, I am a beginner programmer/developer (doing Odin project at the moment and only done some small projects before).
Without knowing the book, I think that not that much has changed. There's something new every day, but just as keeping up with that is a regular task, so would be transitioning from the state presented in any book or tutorial to the practical application you are facing today. Everyone does stuff slightly differently, and by and large the attacks haven't really changed.
Memory corruption and cross-site scripting have both been around for decades and are still vulnerabilities you'll find daily in today's work. The only bugs that have actually gotten a lot better is sql-injection and password storage (not guidelines), the former with parameterized queries and the latter with hashing (even if it's frequently still plain sha1). But the principle still applies: just last week the customer put text into a json string ('''<script>data=JSON.parse("<?php echo $data;?>");</script>''') which is basically identical to an sql injection but with a different language (i.e. javascript). If you learned about sqli a decade ago, that knowledge still works today.
Memory corruption and cross-site scripting have both been around for decades and are still vulnerabilities you'll find daily in today's work. The only bugs that have actually gotten a lot better is sql-injection and password storage (not guidelines), the former with parameterized queries and the latter with hashing (even if it's frequently still plain sha1). But the principle still applies: just last week the customer put text into a json string ('''<script>data=JSON.parse("<?php echo $data;?>");</script>''') which is basically identical to an sql injection but with a different language (i.e. javascript). If you learned about sqli a decade ago, that knowledge still works today.
It’s hard to say. That video would be fine I think.
The security world is divided into two groups, the “testers” and the guys that make the tests.
The security world is divided into two groups, the “testers” and the guys that make the tests.
As a tester, I don't know what you mean. I make my own tests, like, there's nobody telling me which checklist to work down when testing a particular webpage. Or do you mean the conceptual tests, i.e. finding whole new concepts such as XSS or <insert favorite javascript library> template injection?
Edit: From a comment[1] that happened to be just below yours when I loaded the page (emphasis mine):
> If penetration testing is your job [...] run a bunch of scripts/tools against a list of IP addresses/hostnames and generate a template-based report. That is tedious, mindless work.
> There's "security consulting" too which often involves at lot of actual penetration testing (not just running scripts)
Is that the distinction you're trying to make? I happen to be in the latter category but perhaps I'm branding myself wrong when I say I'm a tester (my business card says consultant, not tester, but I also test things so I felt addressed when you said tester).
[1] https://news.ycombinator.com/item?id=26057031
Edit: From a comment[1] that happened to be just below yours when I loaded the page (emphasis mine):
> If penetration testing is your job [...] run a bunch of scripts/tools against a list of IP addresses/hostnames and generate a template-based report. That is tedious, mindless work.
> There's "security consulting" too which often involves at lot of actual penetration testing (not just running scripts)
Is that the distinction you're trying to make? I happen to be in the latter category but perhaps I'm branding myself wrong when I say I'm a tester (my business card says consultant, not tester, but I also test things so I felt addressed when you said tester).
[1] https://news.ycombinator.com/item?id=26057031
I'm not a security engineer, although I've managed security programs and triage security issues. If I were you, I'd probably start by pen testing via HackerOne. You likely won't earn much doing it, but it's an easy way to access many companies inviting you to break their systems.
Many reports on HackerOne are disclosed publicly. Reading through public reports will expose you to what application errors are most commonly found with specific reproduction steps, what tools were used to discover the issue (Burp Suite is very common), and use that as a jumping off point for what to learn and discovering where your knowledge gaps are.
Many reports on HackerOne are disclosed publicly. Reading through public reports will expose you to what application errors are most commonly found with specific reproduction steps, what tools were used to discover the issue (Burp Suite is very common), and use that as a jumping off point for what to learn and discovering where your knowledge gaps are.
The best advise about security you will ever get: Don't take security advise from software developers.
I cannot stress that enough.
I worked in the security domain from the military for about 10 years as an Army Reservist while simultaneously launching my career as a software developer in the corporate world. I have the rare experience of working in both worlds simultaneously yet separately. I have passed the Security+, CISSP, and CASP exams each on the first attempt without taking boot camps.
Taking security advise from software developers is like taking marriage advise from some guy at the bar who is looking for his fourth wife.
I cannot stress that enough.
I worked in the security domain from the military for about 10 years as an Army Reservist while simultaneously launching my career as a software developer in the corporate world. I have the rare experience of working in both worlds simultaneously yet separately. I have passed the Security+, CISSP, and CASP exams each on the first attempt without taking boot camps.
Taking security advise from software developers is like taking marriage advise from some guy at the bar who is looking for his fourth wife.
Security Engineer here… after reading through this trainwreck of a comment section it was nice to get a laugh, thanks for that.
You can see many brogrammers in so called the biggest security conference DEFCON. You'll soon find out that only top 5 percent actually know what they are doing and other 90 percent complete bullshit people who just claims themselves as security expert while not knowing how to exploit a program. It is one of the few political jobs you can get among computer science world.
Application Security Engineer here.
For a developer I would recommend the OSWE certification which takes a more code-centric approach and resources such as https://portswigger.net/web-security and The Art of Software Security Assessment book. You can also leverage your DevOps experience for learning about server, app and cloud misconfigurations and their impact on security.
The demand for network security is not as high as for appsec people and I personally don't see network security as very rewarding (intellectually and financially).
For the Pentesting route I recommend trying some HackTheBox and watching Ippsec's channel (https://www.youtube.com/channel/UCa6eh7gCkpPo5XXUDfygQQA). OSCP is fine, but it is a beginner certification and definitely not enough for getting a Pentest job.
The demand for network security is not as high as for appsec people and I personally don't see network security as very rewarding (intellectually and financially).
For the Pentesting route I recommend trying some HackTheBox and watching Ippsec's channel (https://www.youtube.com/channel/UCa6eh7gCkpPo5XXUDfygQQA). OSCP is fine, but it is a beginner certification and definitely not enough for getting a Pentest job.
Stay as a developer and practice good security in your projects. At the end if the day, it's the developers that have to implement security standards into their code.
Furthermore, certain projects tend to have more security requirements than others. So maybe keep your eyes open for those opportunities. The most security intensive project in worked on was a standalone video game where there was a global leaderboard and save points in the game. Trying to protect the leaderboard from hackers was a fun security challenge. The leaderboard needed to be protected from networked API attacks, local file manipulation, and in memory variable manipulation. It really taught me a lot.
Furthermore, certain projects tend to have more security requirements than others. So maybe keep your eyes open for those opportunities. The most security intensive project in worked on was a standalone video game where there was a global leaderboard and save points in the game. Trying to protect the leaderboard from hackers was a fun security challenge. The leaderboard needed to be protected from networked API attacks, local file manipulation, and in memory variable manipulation. It really taught me a lot.
As someone who once considered the same thing: Don't.
While security can be a fascinating field to learn about on your own, the actual work you do day to day is dull as hell, and the pay is no where near as good as what you get as a software developer.
You already have 5 years experience as a developer, if you start a security career now you'll be 5 years behind where you should be for your age, and you'll start with shitty entry level jobs that pay very little, and can also be easily outsourced to dedicated security companies anyway.
You have to be really exceptional in the field to make what an average senior software developer makes. Trust me, if you're like most software developers I know whose virtue is laziness and strive to do the most effective work with the least amount of effort, you don't want to be exceptional in the field. It takes so much time and effort and brand building, fuck it man. You're not getting any younger.
Securing networks isn't even a big deal, like anything when you're first learning it it seems super interesting but then it's just the same bullshit over and over.
My recommendation, sticking to writing code and actually building stuff as a career and do the hacking on the side as a hobby, and occasionally use what you learn in your career.
While security can be a fascinating field to learn about on your own, the actual work you do day to day is dull as hell, and the pay is no where near as good as what you get as a software developer.
You already have 5 years experience as a developer, if you start a security career now you'll be 5 years behind where you should be for your age, and you'll start with shitty entry level jobs that pay very little, and can also be easily outsourced to dedicated security companies anyway.
You have to be really exceptional in the field to make what an average senior software developer makes. Trust me, if you're like most software developers I know whose virtue is laziness and strive to do the most effective work with the least amount of effort, you don't want to be exceptional in the field. It takes so much time and effort and brand building, fuck it man. You're not getting any younger.
Securing networks isn't even a big deal, like anything when you're first learning it it seems super interesting but then it's just the same bullshit over and over.
My recommendation, sticking to writing code and actually building stuff as a career and do the hacking on the side as a hobby, and occasionally use what you learn in your career.
I was/am a software engineer who had a wonderful opportunity to join a central security team at a very large internet company focusing on security engineering.
My recommendation on switching is to latch onto any SMEs in your company who you look up to, go to their classes and brown bags, research topics and make presentations to the company, be sure to include security decisions in your architecture designs, then once there's an opportunity in their team, you will be a natural choice for the team.
If there is an opportunity for your current product development team to be a Security Champion (i.e the person primarily responsible for security in your team and liaison to your security team for issues that you are unsure of), then jump on that if possible. Security Champions are a great way to dip your toes into security without having to go all in and also for your company to build a "bench" of talent. They can use this as a career lattice rather than a strict career ladder in the engineering org. Many companies are embracing this model as they grow because security folks are hard to find, hard to retain, and hard to scale as the engineering team grows.
My recommendation on switching is to latch onto any SMEs in your company who you look up to, go to their classes and brown bags, research topics and make presentations to the company, be sure to include security decisions in your architecture designs, then once there's an opportunity in their team, you will be a natural choice for the team.
If there is an opportunity for your current product development team to be a Security Champion (i.e the person primarily responsible for security in your team and liaison to your security team for issues that you are unsure of), then jump on that if possible. Security Champions are a great way to dip your toes into security without having to go all in and also for your company to build a "bench" of talent. They can use this as a career lattice rather than a strict career ladder in the engineering org. Many companies are embracing this model as they grow because security folks are hard to find, hard to retain, and hard to scale as the engineering team grows.
Don’t. I don’t think anyone should attempt to get into security, or at least work in a security team.
First, in many stages, a company needs to move fast. This is not a cliche, if you do not move fast you die. This is what a start up is about. Even as a small business trying to grow, you might often be in a position where you constantly need new prospects, new cash flows, etc. Security is inherently about moving slow, and about friction. This is why security is badly seen by management, and it is badly seen by developers and site reliability engineers. The less you work, the happier people will be around you.
Because of that, being in a security team is often an unrewarding job where you’re moving against the courant. Your team is often understaffed, because again, you’re not producing clear value, so the overton window is shifting against you. You’re outnumbered after all, so most of what you say is unreasonable, and perhaps you team and you start forming an “us against them” mindset, as other teams are doing the same with you.
The job is also not that interesting to be honest, you spend more time reading docs and attending meetings trying to keep up, as well as trying to create connections, as your job is to cover as much ground as possible as well as creating connections so that you can convince and delegate better.
First, in many stages, a company needs to move fast. This is not a cliche, if you do not move fast you die. This is what a start up is about. Even as a small business trying to grow, you might often be in a position where you constantly need new prospects, new cash flows, etc. Security is inherently about moving slow, and about friction. This is why security is badly seen by management, and it is badly seen by developers and site reliability engineers. The less you work, the happier people will be around you.
Because of that, being in a security team is often an unrewarding job where you’re moving against the courant. Your team is often understaffed, because again, you’re not producing clear value, so the overton window is shifting against you. You’re outnumbered after all, so most of what you say is unreasonable, and perhaps you team and you start forming an “us against them” mindset, as other teams are doing the same with you.
The job is also not that interesting to be honest, you spend more time reading docs and attending meetings trying to keep up, as well as trying to create connections, as your job is to cover as much ground as possible as well as creating connections so that you can convince and delegate better.
You should check out the OSWE it’s harder for “security” people but for devs it’s a lot easier. Do that and then get the OSCP. You could also pick up a forensics course or two and network forensics course.
Experience wise I would suggest starting with incident handling in a large companies in-house blue team. Ask them about scope and duties. Try get a job where it’s a mix of the tasks within DFIR and the teams scope is wide protecting many different environments from IT to cloud etc. The more variety the more incidents the more experience you’ll get faster.
Given your previous work you’ll likely get asked to work on an app sec team. It’s not for everyone and quite close to testing for some folks. I prefer operations as it has a higher pace.
Like any tech job try to automate things people do manually from forensic analysis to security solutions.
Whatever type of team you are on don’t be a snob and look down on other teams be they security or non security. This is particularly common quite hilariously for red teams who should epitomise hacker culture. Having been on these teams I can tell you they get particularly huffy about elitism.
Also don’t look down on the role of security analyst. Mind you not all analyst roles are created equal. I’ve found though that bar a few large companies if you work for an MSSP (managed security service provider) you probably won’t get the same quality of experience unless you are on a few of their consulting teams. The issue I’ve seen is they have no remit to actually remediate the incidents they find so miss the full journey.
Most of all like anything in life enjoy it. You are choosing this.
Experience wise I would suggest starting with incident handling in a large companies in-house blue team. Ask them about scope and duties. Try get a job where it’s a mix of the tasks within DFIR and the teams scope is wide protecting many different environments from IT to cloud etc. The more variety the more incidents the more experience you’ll get faster.
Given your previous work you’ll likely get asked to work on an app sec team. It’s not for everyone and quite close to testing for some folks. I prefer operations as it has a higher pace.
Like any tech job try to automate things people do manually from forensic analysis to security solutions.
Whatever type of team you are on don’t be a snob and look down on other teams be they security or non security. This is particularly common quite hilariously for red teams who should epitomise hacker culture. Having been on these teams I can tell you they get particularly huffy about elitism.
Also don’t look down on the role of security analyst. Mind you not all analyst roles are created equal. I’ve found though that bar a few large companies if you work for an MSSP (managed security service provider) you probably won’t get the same quality of experience unless you are on a few of their consulting teams. The issue I’ve seen is they have no remit to actually remediate the incidents they find so miss the full journey.
Most of all like anything in life enjoy it. You are choosing this.
tl;dr; Take the online courses for Cloud Security is the best bang for your buck IMO.
As a Security Engineer that works on network/devops stuff at a modern Saas company. I think 90% of what I do is Cloud DevOps with a focus on Security. That could mean: making frameworks to make security easier, or advise other teams on how to secure their pieces of infra, or identifying insecure configs and pushing to get those fixed. The other 10% is understanding security risks and what designs/implementations of the infra are good/bad. Pen-testing might help with the later skill, but at ~10% it's a surprisingly small factor.
I would like to echo the points made by other posts, that there are a lot of different fields of security. Pentesting is one field, Application security is another, there's also compliance, red-team, IT-security, threat hunting, etc. The list goes on, and there are a lot of different skills you could build, certifications you could get, and areas to specialize in (or distract you from your specialization)
It does sound as if you enjoy the InfraSec/SecDevOps parts of the problem. So learning more about AWS/GCP Security in detail is probably the best way to improve your skill set in the area.
As a Security Engineer that works on network/devops stuff at a modern Saas company. I think 90% of what I do is Cloud DevOps with a focus on Security. That could mean: making frameworks to make security easier, or advise other teams on how to secure their pieces of infra, or identifying insecure configs and pushing to get those fixed. The other 10% is understanding security risks and what designs/implementations of the infra are good/bad. Pen-testing might help with the later skill, but at ~10% it's a surprisingly small factor.
I would like to echo the points made by other posts, that there are a lot of different fields of security. Pentesting is one field, Application security is another, there's also compliance, red-team, IT-security, threat hunting, etc. The list goes on, and there are a lot of different skills you could build, certifications you could get, and areas to specialize in (or distract you from your specialization)
It does sound as if you enjoy the InfraSec/SecDevOps parts of the problem. So learning more about AWS/GCP Security in detail is probably the best way to improve your skill set in the area.
I went the software developer -> security route, so maybe I can weigh in a little.
Security takes a different mind-set in some ways; not incompatible, but not necessarily there to start with. I've always been interested in how things fail, and with what might happen when it does.
Many school-mates going through CS were interested in how to build things, so their goal was achieved if things were constructed and seemed to run well. Edge cases might seem then to resemble the background noise when talking about big-O issues in an algorithm. In reality though, small gaps might lead to larger consequences.
In that way, I think security might more closely resemble QA, except that the consequences of failure have more interesting implications.
To that end, how can you incorporate security analysis into the software development work you do today? For me, it was a matter of trying to help secure our own product; from there I could bounce to some level of consulting.
Security takes a different mind-set in some ways; not incompatible, but not necessarily there to start with. I've always been interested in how things fail, and with what might happen when it does.
Many school-mates going through CS were interested in how to build things, so their goal was achieved if things were constructed and seemed to run well. Edge cases might seem then to resemble the background noise when talking about big-O issues in an algorithm. In reality though, small gaps might lead to larger consequences.
In that way, I think security might more closely resemble QA, except that the consequences of failure have more interesting implications.
To that end, how can you incorporate security analysis into the software development work you do today? For me, it was a matter of trying to help secure our own product; from there I could bounce to some level of consulting.
While maybe not really actionable advice, I've been making a slow transition in this direction over the last few years, so I'm just sharing what happened for me incase it's of use.
The networking side came from that being my background, I used to work in cellular telecom, and my role was to solve complex network problems.
The security side has been a more natural transition, and it really came for working for companies that had security problems but weren't really equipped or able to solve them. But the bit of its that luck or I don't really understand, is somehow I had developed better mental models of technical security that allowed me to break apart other proposed solutions and develop my own, which was probably just religious reading of HN security content.
This better understanding put me into a position to solve organization objectives where the skills were otherwise missing, and then the organization started asking to solve other security problems, and without really trying I've been a security SME in my previous and current role.
From a tips perspective, I think the most important tip is approaching almost any problem with the statement "I don't know what I don't know". A lot of devs can get away with brute forcing their way through tech and applying similar solutions they know to solve new problems. Such as a personal pet peeve, the number of devs who think a crypto or password hash will anonymize data. But starting with know our mental model is incomplete, and trying to figure out why, I think helps me out alot.
So the second tip is, reach out to someone who does security and get free advice for particular problems. Write a design doc and get them to review it, or just converse with them at a high level what's around to solve a particular problem. I've done complete 180's on particular choices based on just a conversation about what exists and then go and do a bunch of research.
The networking side came from that being my background, I used to work in cellular telecom, and my role was to solve complex network problems.
The security side has been a more natural transition, and it really came for working for companies that had security problems but weren't really equipped or able to solve them. But the bit of its that luck or I don't really understand, is somehow I had developed better mental models of technical security that allowed me to break apart other proposed solutions and develop my own, which was probably just religious reading of HN security content.
This better understanding put me into a position to solve organization objectives where the skills were otherwise missing, and then the organization started asking to solve other security problems, and without really trying I've been a security SME in my previous and current role.
From a tips perspective, I think the most important tip is approaching almost any problem with the statement "I don't know what I don't know". A lot of devs can get away with brute forcing their way through tech and applying similar solutions they know to solve new problems. Such as a personal pet peeve, the number of devs who think a crypto or password hash will anonymize data. But starting with know our mental model is incomplete, and trying to figure out why, I think helps me out alot.
So the second tip is, reach out to someone who does security and get free advice for particular problems. Write a design doc and get them to review it, or just converse with them at a high level what's around to solve a particular problem. I've done complete 180's on particular choices based on just a conversation about what exists and then go and do a bunch of research.
Every field of CS has a security aspect to it. Unless you are a legitimate network engineer, learn how to use the network right before learning how to break it.
I'd say start with learning how security works in the world you know. Defensive programming is a very real thing and translates to just about every other field of CS since... Its all running on code. :D
There are quite a few good defensive coding guides out there. Redhat has some really nicely put together guides for you to start learning from.
https://developers.redhat.com/articles/defensive-coding-guid...
Remember: Learning how to use a gun and becoming licensed to use the gun isnt gonna teach you nearly as much about security as learning how to build Fort Knox.
I'd say start with learning how security works in the world you know. Defensive programming is a very real thing and translates to just about every other field of CS since... Its all running on code. :D
There are quite a few good defensive coding guides out there. Redhat has some really nicely put together guides for you to start learning from.
https://developers.redhat.com/articles/defensive-coding-guid...
Remember: Learning how to use a gun and becoming licensed to use the gun isnt gonna teach you nearly as much about security as learning how to build Fort Knox.
The best is if there is a security team at your current role that needs help, which you could transfer to, or even unofficially help out.
There are lots of different types of computer security jobs. Lots are really boring compliance jobs (i mean, some people are into that, all the power to you, if that's what they like). From a corporate perspective security is all about risk management, some aspects of risk management is covering your ass, so make sure the security position aligns with what you want to actually do.
> I've read that OSCP certification
That might be a good starting place. Just be careful about relying too much on certs, about 95% of them are bullshit, they definitely don't replace real world experience, and its a major red flag to have a resume with like 10 different certs on it.
There are lots of different types of computer security jobs. Lots are really boring compliance jobs (i mean, some people are into that, all the power to you, if that's what they like). From a corporate perspective security is all about risk management, some aspects of risk management is covering your ass, so make sure the security position aligns with what you want to actually do.
> I've read that OSCP certification
That might be a good starting place. Just be careful about relying too much on certs, about 95% of them are bullshit, they definitely don't replace real world experience, and its a major red flag to have a resume with like 10 different certs on it.
Some good points in this thread though a touch overly pessimistic. For reference, I'm a security engineer.
The part of my job I enjoy the most is building things, mostly by writing code or working in AWS. If you aren't interested in writing code, I might suggest a cloud security role though if you're doing it right, that will also involve writing terraform or cloud formation or something code-like.
Pentesting is the cool field everyone wants to go into, but it also pays less than security engineering and is most often employed by consulting groups who have you repetitively testing web applications and writing reports.
All this to say, if you find cloud interesting then a cloud security role could be fun for you, and it's in high demand at the moment.
The part of my job I enjoy the most is building things, mostly by writing code or working in AWS. If you aren't interested in writing code, I might suggest a cloud security role though if you're doing it right, that will also involve writing terraform or cloud formation or something code-like.
Pentesting is the cool field everyone wants to go into, but it also pays less than security engineering and is most often employed by consulting groups who have you repetitively testing web applications and writing reports.
All this to say, if you find cloud interesting then a cloud security role could be fun for you, and it's in high demand at the moment.
I found this interesting insight in the comment section of an article about threat modeling, it may be worth considering:
https://news.ycombinator.com/item?id=26055379
https://news.ycombinator.com/item?id=26055379
I have switched from finance to security ("Next Gen" IPS Company) two years ago and sadly I have to agree with most of the comments regarding the current state of the industry.
While I have heard good things about OSCP, I think CISSP is better known and it might be easier for you to get a foothold in a security position with this certification.
Pentest can be a good place to enter the field but from my experience it gets repetitive quickly. Also, while it's a good way to understand the vulnerabilities, you seem more interested in securing/defending than offensive security. Joining a SOC team might be a good starting point.
While I have heard good things about OSCP, I think CISSP is better known and it might be easier for you to get a foothold in a security position with this certification.
Pentest can be a good place to enter the field but from my experience it gets repetitive quickly. Also, while it's a good way to understand the vulnerabilities, you seem more interested in securing/defending than offensive security. Joining a SOC team might be a good starting point.
Here’s a good resource I found that lays out a detailed approach for how to make this switch: https://danielmiessler.com/blog/build-successful-infosec-car...
I'm an SRE/blue teamer trying to move into the AppSec side (email me if you are looking for someone :D). My impression is that there is a large demand for AppSec people with development skills. Jobs pay well and seem incredibly interesting to me, too.
Security matters much more for companies in a few business domains: fintech, medical, crypto currency, and cyber security companies. Choose the right domain if you really want to learn stuff.
Start with Bug Bounty programs. You can do that while still doing what you do to make money. See if you like it and any good at it.
This will tell you in a year if you like it, make some money and take the dive, or not.
Pentesting (except for the really smart cookies) is the dumbest thing ever, nowadays. You spend a day running your scanner, 3 to PowerPoint your (low hanging fruit) findings, a half to present your PowerPoint to 'managers' who are just hackling about the rating of said findings, a couple of calls / email to try to explain the findings to the developers and on to the next. It sucks and is mainly done for compliancy reasons.
This will tell you in a year if you like it, make some money and take the dive, or not.
Pentesting (except for the really smart cookies) is the dumbest thing ever, nowadays. You spend a day running your scanner, 3 to PowerPoint your (low hanging fruit) findings, a half to present your PowerPoint to 'managers' who are just hackling about the rating of said findings, a couple of calls / email to try to explain the findings to the developers and on to the next. It sucks and is mainly done for compliancy reasons.
As a hiring manager in the security field, a tip would be to include contact details that would allow people like me to reach out and discuss opportunities :)
Perhaps look into exploit development/reverse engineering if you want the most difficult 1% top tier job in this field.
Learning exploit dev and vulnerability research on browsers and operating systems (like Project Zero’s work) is really difficult, and ends up being mostly self-taught. One good entry point into this role for people early in their career, though, is NSA’s development programs, especially CNODP and C2DP.
Yes, I agree in terms of difficulty. Are you in this space by any chance?
Or the joke:
Those who can't do, teach. And those who can't teach? Infosec.
Those who can't do, teach. And those who can't teach? Infosec.
I switched to the security industry without even realizing it when I was hired to work on IAM software. It's not pen-test security, but it's a great way to get into the industry for a software engineer.
Before that I worked on military software
Before that I worked on military software
IT security does remain fascinated with certifications. You might consider the AWS security related certifications also.
[deleted]
As someone who's worked in security at a couple of quickly-growing tech companies and is now back to a non-security engineering role, I would suggest being introspective about what you find fulfilling about software development and think about whether working in security will offer enough fulfillment to go to work every day.
At its best, security is about seeing what systems _can_ do rather than what they're intended to do. On the offensive side, this means doing research on where systems are weak or simulating attacker behavior. On the defensive side, this means deeply understanding systems in order to control their behavior and mitigate risk, building automation to avoid human fallibility, and ensuring you have the necessary visibility into your systems to detect when your defenses fail or your assumptions are violated. This type of security work can be very fulfilling, especially when finding ways to improve the security of your systems in a more usable way (or at least not-less-usable then before).
It's worth mentioning that at larger organizations, the security team typically can't accomplish their mission alone, and must collaborate with other engineering and non-engineering teams to learn what problems exist, get to a shared understanding of how important each problem is to address, and then go on to solve them. This means that at larger organizations, security can't really be successful or a fulfilling place to work without leadership that sees the value of security and is willing to prioritize and support it. Unlike software engineering teams which are likely increasing revenue, reducing cost, or doing something else more visible and valuable to company leaders, it's easy to view security as a cost to be minimized because it's value is harder to understand or compare.
At its worst, security is more a risk management process than an engineering one. There may well be legitimate business reasons for this, but it makes security much less fun to work on. There are any number of specific failure modes here, but some that come to mind: security becomes focused on scanning, testing, documenting and prioritizing problems, doing the bare minimum to address the worst problems to CYA; security is tasked with dragging an unwilling organization along a path of risk reduction that makes everyone unhappy through the process; or security is endlessly reactive to incidents and vulnerabilities that arise, and has very little time or energy to make things better.
If you can do security work at its best, it's a pretty awesome field to work in. On the other hand, from the "at its worst" perspective, software engineering looks a lot more fun. As you wade into the security field you should be aware of the organizations and types of work you pursue to ensure you'll be able to stay motivated and keep growing regardless of whether you ultimately choose security or not.
At its best, security is about seeing what systems _can_ do rather than what they're intended to do. On the offensive side, this means doing research on where systems are weak or simulating attacker behavior. On the defensive side, this means deeply understanding systems in order to control their behavior and mitigate risk, building automation to avoid human fallibility, and ensuring you have the necessary visibility into your systems to detect when your defenses fail or your assumptions are violated. This type of security work can be very fulfilling, especially when finding ways to improve the security of your systems in a more usable way (or at least not-less-usable then before).
It's worth mentioning that at larger organizations, the security team typically can't accomplish their mission alone, and must collaborate with other engineering and non-engineering teams to learn what problems exist, get to a shared understanding of how important each problem is to address, and then go on to solve them. This means that at larger organizations, security can't really be successful or a fulfilling place to work without leadership that sees the value of security and is willing to prioritize and support it. Unlike software engineering teams which are likely increasing revenue, reducing cost, or doing something else more visible and valuable to company leaders, it's easy to view security as a cost to be minimized because it's value is harder to understand or compare.
At its worst, security is more a risk management process than an engineering one. There may well be legitimate business reasons for this, but it makes security much less fun to work on. There are any number of specific failure modes here, but some that come to mind: security becomes focused on scanning, testing, documenting and prioritizing problems, doing the bare minimum to address the worst problems to CYA; security is tasked with dragging an unwilling organization along a path of risk reduction that makes everyone unhappy through the process; or security is endlessly reactive to incidents and vulnerabilities that arise, and has very little time or energy to make things better.
If you can do security work at its best, it's a pretty awesome field to work in. On the other hand, from the "at its worst" perspective, software engineering looks a lot more fun. As you wade into the security field you should be aware of the organizations and types of work you pursue to ensure you'll be able to stay motivated and keep growing regardless of whether you ultimately choose security or not.
how would you be avarage softare developer, Everyone has a different challenge :) what would you tell me about it
NSA is hiring.[1] "Capabilities Development Specialist.
Conducts comprehensive technology research to evaluate potential vulnerabilities in cyberspace systems. Detects, identifies and describes specific vulnerabilities in a system, network, component or process. Conducts software and systems engineering and software systems development in order to meet required capabilities."
[1] https://www.intelligencecareers.gov/nsa/nsacareers.html
[1] https://www.intelligencecareers.gov/nsa/nsacareers.html
Hell, even the NSA is going after the wrong overloaded definition of "capability". When every OS defaults to giving away the store to every process run by the user, you can't ever get things secure.. you can only waste billions trying.
10 more years until Capability Based Security takes off.
10 more years until Capability Based Security takes off.
Obviously security is becoming more and more important, and I'd like to focus my career toward this. In terms of talent, I'm an average Developer, and I know there are roles that focus toward knowing how to secure applications at the code level, which could be interesting, but I also would be interested in securing networks.
I've read that OSCP certification is very good for getting a role in Penetration Testing. Is PenTesting a good place to enter the field?
Any general advice would be much appreciated.