Ask HN: Any tips for a programmer wanting to switch into security?
I've got ~5 years experience as a business app developer with some networking / DevOps experience in there as well. 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.
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.
113 comments
[ 5.3 ms ] story [ 193 ms ] threadBe 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...
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).
The security world is divided into two groups, the “testers” and the guys that make the tests.
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
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.
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 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.)
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.
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.
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.
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.
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.
Instead defense in depth works best when the software engineers are treated as benign manifestations of hanlon's razor.
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
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.
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)
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
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.
So from a security perspective it's way easier to review/audit functional code.
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...
What does the language being a functional language have to do with it?
So it's not just about being functional.
But the money must've been really, really good.
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.
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.
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 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.
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 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.
This is a really good point. Every one will cringe when they see you coming, and that's going to drag on your career.
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.
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.
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.
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 :)
[1] https://www.intelligencecareers.gov/nsa/nsacareers.html
10 more years until Capability Based Security takes off.
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).
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 for the creds: no
* 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.
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.
https://news.ycombinator.com/item?id=26055379
Those who can't do, teach. And those who can't teach? Infosec.