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.
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.
* 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.
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.
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 :)
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).
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Those who can't do, teach. And those who can't teach? Infosec.
Before that I worked on military software
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.