A Guide for Those Just Starting Out in Security

If you’re reading this, I assume you’re either interested in a career in security, putting together a portfolio, a freshman about to start an information security program, or already a student majoring in the field.

In my case, too, when I first started in information security, I wasn’t a major in the field, so I was essentially in a position where I had to figure most of it out on my own.

I didn’t have any upperclassmen to ask for advice,

so when I searched online asking, “What should I study?”

When I searched for that, some people said to start with networking, others said to start with Linux, some said to start with the C language, and still others told me to just go ahead and install Kali Linux right away.

In the end, I learned by trial and error.

So, as someone who’s sort of a self-made man (?) in the security field, I’d like to share some things I wish I’d known when I first started, along with my experiences.

1. Information Security: What Fields Are There?

To start with what comes to mind,

Web Hacking
Network Security
Linux Security
Windows Security
Cloud Security
Malware Analysis
Reverse Engineering
DFIR
SOC
SIEM
EDR
IAM
DevSecOps
Cryptography
CTF
Bug Bounty
AWS
Kubernetes

there are these. Of course, there are many more besides these.

I’ll skip the rest since I can’t remember them all. When you first look at this, you’ll probably think:

So, what should I study first? Where should I start?

These are the questions I hear most often. My answer is simpler than you might think.

Don’t study security first—study systems first.

Because security ultimately comes down to understanding how systems work and

“What am I trusting here?”

“What happens if this is misused?”

If you try to look for abnormal behavior without knowing what normal behavior is, you’ll have a really hard time. I’ve been there. I’m speaking from experience. Please, study systems first. I didn’t want to do it either.

2. Security Is Not Just One Job

You need to understand this first.

Even if a job posting says “Security Engineer,” the actual responsibilities can vary completely from company to company.

Roughly speaking, the roles break down like this:

Offensive Security
Defensive Security
Cloud Security
Application Security
Incident Response
Threat Intelligence
Governance / Risk / Compliance

Of course, in a real company, the boundaries aren’t so neatly defined.

You might be working on AppSec one moment and then handling cloud tasks the next, or conducting penetration tests one moment and responding to incidents the next, or—even as a security engineer—you might suddenly find yourself digging into the development team’s GitHub Actions.

What if the security team is understaffed?

Congratulations.

You’ll do it all.

Still, when you’re just starting out, it’s best to pick one area to focus on.

You don’t have to be good at everything right from the start. In fact, almost no one is good at everything.

Offensive Security

This is the area that usually comes to mind first when people hear the term “white-hat hacking.”

I, too, work in this field.

My main responsibilities include the following:

Web Penetration Testing
Mobile Penetration Testing
API Security Testing
Internal Network Testing
Red Teaming
Cloud Penetration Testing
Vulnerability Research

Using a tool called Burp Suite to test the web, or

dissecting APKs,

exploring Active Directory environments,

or looking at AWS IAM settings and wondering,

“Wait, why on earth does this role have ‘AdministratorAccess’ attached to it?”

That’s the kind of job it is.

To find this field interesting, you have to enjoy asking questions like these.

“Could this feature be used in a way different from its original intent?”

In fact, what matters most in offensive security isn’t how many tools you’ve memorized, but rather this kind of shift in perspective.

For example, let’s say you’ve discovered that a device can communicate with another system under certain conditions without sufficient authentication.

Then, rather than simply saying

“It connects?”

—it doesn’t end there;

Device
   |
   v
Trusted Connection
   |
   v
Unexpected Input
   |
   v
Code Execution?

you take it a step further and ask,

“What happens if I connect this to that?”

“Did the developer even consider this use case?”

“There’s authentication, but what about authorization?”

People who often have these slightly odd(?) thoughts tend to be a good fit.

Creativity—using normal features in unusual ways—is key.

Defensive Security

This encompasses fields such as SOC, Blue Team, and Detection Engineering.

You can think of it as the side that focuses on how to detect an attack when someone launches one.

These are the main areas covered.

SIEM
EDR
Log Analysis
Threat Hunting
Detection Engineering
Incident Response

Simply put, it’s about finding the culprit by following the clues.

If you enjoyed detective shows like *Conan* when you were younger, this might actually be a good fit for you.

For example, let’s say an EDR suddenly captures a process tree like this.

powershell.exe
    |
    v
rundll32.exe
    |
    v
External Connection

Looking at this,

“Why did PowerShell run that process?”

“Who ran it?”

“Where is that IP address?”

“What files were created before this?”

then this line of inquiry might be a good one to pursue.

From an offensive perspective,

“How do I get in?”

the defensive side asks,

“How did they get in?”

Both are interesting.

Application Security

It’s one of the security roles that works most closely with developers.

It’s commonly abbreviated as “AppSec.”

The specific responsibilities vary by company, but it generally involves the following:

Secure Code Review
SAST / DAST
Threat Modeling
Dependency Security
API Security
CI/CD Security
Security Architecture

Let’s say the development team has created a new service.

In that case, AppSec would ask:

Is the authentication structure sound?

Where are permissions checked?

Where does user input go?

Are there any secrets hardcoded in the code?

Can this API be called directly from outside?

These are the kinds of things I look for.

If you love coding and have development experience, this is a field I highly recommend.

Personally, I think AppSec is a great option, especially for developers who want to transition into security.

That’s because security engineers who understand development are actually quite rare.

When a security team tells a developer,

“It’s a security risk, so please fix it,”

and

“Currently, object authorization is implemented in each resolver, so there’s a risk of omissions; I think it would be best to centralize the authorization layer,”

are two completely different things.

Developers much prefer the latter.

Of course.

Cloud Security

This field deals with the security of cloud infrastructure such as AWS, Azure, and GCP.

This is an area I personally consider to be very important these days.

I mainly look at things like this.

IAM
VPC / Network
Secrets
Kubernetes
Container Security
CloudTrail
Workload Identity
CI/CD
Cloud Security Posture

Permissions are something you see very often in cloud security.

For example, let’s say we have a structure like this.

GitHub Actions
      |
      v
OIDC
      |
      v
AWS STS
      |
      v
IAM Role
      |
      v
Production

Then the question is this:

Why can this repository have this role?

Is this possible from any branch?

Is it also possible in a pull request?

What are the limits of Role Permissions?

Since cloud environments are so heavily automated, even a single misconfigured setting can result in a significantly large blast radius.

On the other hand, if you enjoy working with infrastructure and tinkering with AWS, it’s really fun.

Personally, I find it quite fun when I’m reading through IAM policies and stumble upon a strange trust relationship,

but most people don’t find it interesting.

It’s just a matter of taste.

Incident Response / DFIR

These are the people who step in after an incident has already occurred.

For example, when suspicious network traffic is detected on a server,

an employee’s PC has been infected with malware,

or when unusual API calls are logged in an AWS account—

In those situations,

you have to figure out: “So, how much data was actually compromised?”

You need to find that out.

Initial Access
     |
     v
Execution
     |
     v
Persistence
     |
     v
Privilege Escalation
     |
     v
Lateral Movement

Where did the attacker come from,

what they did,

what they took,

and whether they moved on to other systems.

A key characteristic of this field is that logs can betray you.

Either the logs you need are missing,

the retention period for the logs has expired,

the system time is off,

or the person in charge might say,

might say, “Didn’t we reinstall that server yesterday?”

they might say.

Then I zone out for a moment.

Still, it’s fun.

Threat Intelligence

This is the field of analyzing attackers and attack campaigns.

If you’ve heard names like APT37, Kimsuky, and Lazarus a lot, they’re frequently discussed in this field.

It primarily

Threat Actor
     |
     +-- Infrastructure
     |
     +-- Malware
     |
     +-- TTP
     |
     +-- Victimology
     |
     +-- Campaign

are linked and analyzed.

It goes beyond simply

“This IP is malicious.”

—it goes beyond that to

this infrastructure has been used in previous attacks, and

the behavior patterns of this malware are similar to those in previous campaigns,

and the targeted industries are as follows.

This creates a coherent picture.

If you enjoy keeping up with the news, international affairs, and attacker TTPs, this is likely a good fit for you.

3. So, what should I really study first?

I’ve read this far, but I’m back to square one.

So, what should I actually study?

Personally, if you’re just starting out, I recommend these four things first.

Operating System
Networking
Web
Programming

Seriously.

You don’t even have to install Kali Linux just yet.

You don’t even need to buy a hoodie just yet.

Linux

If you’re going to work in security, it’s a good idea to get familiar with Linux.

It’s helpful if you can at least use these commands without having to search the internet.

ls
cd
pwd
cat
grep
find
ps
ss
curl
chmod
chown
ssh
journalctl

But memorizing the commands isn’t what’s important.

You need to understand the concepts behind them.

Process
User
Group
Permission
Service
Socket
Environment Variable
Filesystem

For example, when responding to an incident, you might notice that a certain process is acting strangely.

Then you’ll naturally ask,

“Who ran this?”

"Which user’s permissions are these?"

Which port is it using?

What is the parent process?

You should be able to see these things.

Studying Linux isn’t about memorizing hacking commands.

It’s more about learning how computers work.

Network

Don’t shy away from networking either.

You’ll definitely encounter it again later.

At the very least, let’s keep these things in mind.

IP
Subnet
TCP
UDP
DNS
HTTP
TLS
NAT
Proxy
Firewall
Routing

I’m not saying you need to memorize all the routing protocols at the CCNA level.

At the very least,

Client
   |
   v
DNS
   |
   v
TCP
   |
   v
TLS
   |
   v
HTTP
   |
   v
Server

you should have a general understanding of how things work.

It’s also a good idea to open Wireshark and see what packets are actually being sent and received when you visit a website.

At first, it looks like a foreign language.

That’s normal.

You’ll get used to it as you look at it more.

Web

This is especially important if you want to do white-hat hacking.

Most modern services are connected to the web in one way or another.

Let’s start by understanding the basic structure.

Browser
   |
   v
Frontend
   |
   v
API
   |
   v
Backend
   |
   v
Database

And you should know these things as much as possible.

HTTP
Cookie
Session
JWT
CORS
Same-Origin Policy
Authentication
Authorization
REST
GraphQL

In particular, the difference between authentication and authorization is really important.

Authentication is

"Who are you?"

while authorization is

"Are you allowed to do this?"

Just because you’re logged in doesn’t mean you can view all the data.

This distinction gives rise to countless vulnerabilities.

Programming

I also get asked all the time whether you have to be a good coder to ensure security.

The answer is

It depends on the field.

If you’re doing reverse engineering or vulnerability research, you need to go quite deep.

On the other hand, if you’re a SOC analyst, you might not need to reach a developer’s level.

Still, it definitely helps to at least be able to read code and perform simple automation tasks.

I recommend starting with Python.

import requests

response = requests.get("https://example.com")

print(response.status_code)
print(response.headers)

Start with things like this.

Later, when the need arises,

JavaScript
Bash
PowerShell
C
Go

you can add more as needed.

Don’t try to learn six languages right from the start.

Seriously, don’t do it.

You won’t be able to master even one of them.

4. Want to get into white-hat hacking?

I recommend starting with web security.

You’ll see results right away, and it’s a great way to learn basic security thinking.

At first, you can focus on vulnerabilities like these.

IDOR / BOLA
XSS
SQL Injection
CSRF
SSRF
File Upload
Path Traversal
Authentication Flaws
Authorization Flaws
Business Logic Vulnerabilities

But even here, the goal isn’t just to memorize names.

For example, if you’re studying IDOR,

User A
   |
   v
Object A

this is the normal structure.

But

User A
   |
   v
Object B

what if it’s accessible?

In that case, we ask this question:

Did the server check who Object B belongs to?

It’s a good idea to get into the habit of examining the trust boundary in this way.

How do I learn Burp Suite?

When you open it for the first time, the sheer number of buttons can be a bit overwhelming.

You don’t need all of them.

In the beginning, this is all you need.

Proxy
HTTP History
Repeater
Decoder

Browse websites and examine HTTP requests.

GET /api/profile HTTP/1.1
Host: example.com
Cookie: session=...

Then, send them through the Repeater to experiment with different changes.

Parameter
Cookie
Header
Object ID
HTTP Method

In fact, you can think of learning Burp Suite as the process of learning HTTP.

You’re not just learning a tool; you’re learning how to analyze requests and responses.

5. Can I get a job if I participate in a lot of CTFs?

CTFs are great.

I recommend them, too.

It’s fun to use your brain, and it’s a great way to learn technical skills.

But there’s one thing you need to know.

CTF
 !=
Real-world Pentest

In CTFs, there’s a correct answer.

A flag exists somewhere.

flag{something_here}

In real-world penetration testing, there’s no such thing.

You might test all day and come up empty-handed.

And in real-world work, things like this are just as important as technical skills.

Scope
Evidence
Impact
Reproducibility
Communication
Safety
Report

You shouldn’t extract all production data just because you found a single vulnerability.

It’s even worse to wipe out a client’s database just to verify, “Does this actually work?”

Knowing how to safely demonstrate a vulnerability is also a skill.

6. Writing a good report is also a skill

When people hear “white-hat hacking,” they only think about breaking into systems.

But once you’re in the field, you end up writing a ton of documentation.

I mean, a lot.

If you hand a report to the development team

IDOR exists.

Critical.

, you’re just asking to get yelled at.

A good report must, at the very least, answer these questions.

Where is it?

Who can exploit it?

What is affected?

What is the actual impact?

How can it be reproduced?

How should it be fixed?

Ultimately, the security team’s goal is

not to boast, “I broke into this.”

It’s not about bragging.

It’s to get vulnerabilities fixed.

That’s why, surprisingly, people who are good at writing have a significant advantage.

7. What should I include in my portfolio?

Personally, I’m not a big fan of portfolios like this.

Studied Linux
Studied OWASP Top 10
Studied AWS
Studied Python

“So what did you actually do?”

That’s the question that immediately comes up.

In a portfolio, it’s better to show what you’ve built rather than just what you’ve studied.

Here’s an example:

Web Penetration Test Report
Cloud Security Lab
Threat Hunting Report
Detection Rule
Vulnerability Write-up
Secure CI/CD Project
Android Penetration Test Write-up

If you’ve studied AWS, you can easily set up an environment.

AWS
 |
 +-- IAM
 |
 +-- EC2
 |
 +-- S3
 |
 +-- CloudTrail

I intentionally configured it to be vulnerable.

Public S3
Overprivileged IAM Role
Open Security Group

Then

what issues were found
how they were discovered
what the impact would be if attacked,
how it was fixed

Then

I studied AWS.

It’s much more impactful than a single line.

A blog is also a portfolio

Personally, I highly recommend blogging to anyone studying security.

However,

What is XSS?

What is SQL injection?

If you only write posts like these, your content will easily get lost among the countless other posts.

It’s actually more interesting to write posts like this:

“Why a Single GraphQL API Exposed Another Company’s Data”

“I Didn’t Have an AWS Key, but ‘AssumeRole’ Was Logged”

“I reverse-engineered the APK and found that any app could receive the OAuth callback”

It’s good to include your thought process when explaining technical concepts.

From the interviewer’s perspective, it’s not about what this person has memorized,

but

8. Do I need to have any certifications?

It’s a plus if you have them.

Not having one doesn’t mean you can’t handle security.

A certification is just a certification.

Knowledge
Experience
Portfolio
Certification

These four are not exactly the same.

Still, from a new graduate’s perspective, they can sometimes help with resume screening or demonstrating basic knowledge, so you should prepare them based on the role you’re interested in.

However,

Does getting a certification make you a security expert?

No, it doesn’t.

It’s similar to how having a driver’s license doesn’t make you an F1 driver.

9. How should I set up my GitHub profile?

You don’t need to upload a bunch of exploit code.

In fact, a well-organized project looks much better.

security-labs/
├── web/
├── cloud/
├── mobile/
├── detections/
├── incident-response/
└── writeups/

Here’s what you should include in the README.

Goal
Environment
Threat Model
Testing Process
Findings
Mitigation
Lessons Learned

Personally, I think the “Lessons Learned” section at the end is quite important.

Rather than just saying “It worked,”

I find it more interesting to explore

is more interesting than simply saying “It was a success.”

10. Can’t I practice on the actual site?

No.

Absolutely not.

People who’ve only recently learned white-hat hacking sometimes open their school’s website or some random site and

and think, “Should I try to see if I can do an SQLi?”

There are cases like this.

Unauthorized security testing can lead to real legal problems.

Practice should be done in an authorized environment.

PortSwigger Web Security Academy
Hack The Box
TryHackMe
CTF
Local Lab
Bug Bounty Program

A bug bounty program doesn’t mean you can test just anything.

Read the scope first.

In security, the habit of not reading the scope is really bad.

It will cause problems even in the real world.

11. What kind of work will I actually be doing once I get a job?

You might have a slightly idealized view of security roles.

0-day
APT
Exploit Development
Reverse Engineering

You might think you’ll be doing things like this every day, but the reality is...

Why did this alert fire?

Who owns this server?

Is this IP expected?

Can we close this ticket?

Why does this IAM role have admin?

Can the dev team reproduce this?

When can this patch be deployed?

You’ll be asking questions like this much more often.

Security is a much more operational role than you might think.

And you have to interact with people a lot.

The development team.

The infrastructure team.

Legal team.

Executive leadership.

Customers.

More than you might think

“I just want to talk to computers.”

It doesn’t work out very well.

I’m sorry.

12. Things That Change as You Gain Experience

At first, you usually think like this:

“Can I figure this out?”

After a while,

you start to wonder, “If I can get past this, how far can I go?”

That’s what you start to ask yourself.

Later still,

“Wait, why was this structure built like this?”

I find myself wondering.

Find Vulnerability
       |
       v
Understand Impact
       |
       v
Understand Root Cause
       |
       v
Fix Architecture

Personally, I think this shift is quite significant.

The more senior I become, the more time I spend trying to understand why these problems keep occurring, rather than just finding a single vulnerability.

And when I see a developer who adds a single line of an `if` statement to fix a vulnerability,

I find myself muttering to myself, “Ah… that’s not right…”

to myself.

13. So, how should you study during the first six months?

It varies from person to person, but if you’re starting from scratch, here’s what I recommend.

1–2 months

Linux
Networking
HTTP
Python
Git

During this period, you don’t need to worry about becoming a skilled hacker.

Focus on understanding how computers work.

Months 3–4

If you’re interested in white-hat hacking,

Burp Suite
Web Security
Authentication
Authorization
API Security
OWASP

study these topics.

PortSwigger Web Security Academy is also really good.

It’s free.

It’s free, yet it’s quite well-designed.

Let’s give it a try.

5 months

I’m starting to figure out which field I like.

Pentesting
AppSec
Cloud Security
Blue Team
DFIR

It’s okay if I haven’t decided yet.

You won’t know until you try.

6 months

Try seeing a small project through to the end.

This is important.

Build Lab
    |
    v
Test
    |
    v
Analyze
    |
    v
Write Report
    |
    v
Publish

It’s more important to actually see a small project through to the end

Coming Soon

is far better than

it’s much better to complete even one small project all the way through.

Finally,

When you first start studying security, everyone around you seems like a monster.

Some people solve CTF problems in just a few minutes,

some have CVEs,

some reverse-engineer malware,

some are great with AWS,

and some are hacking into every Active Directory they come across.

Then, all of a sudden, I start to feel anxious.

Do I have to do all of that, too?

No.

Absolutely not.

Security is just too broad a field.

It’s hard for one person to be good at everything.

There’s a lot I don’t know, too.

Ultimately, you just have to take it one step at a time.

And personally, the skill I think is most important for new hires or people just starting to study security is, surprisingly, the ability to admit when you don’t know something and to dig into it until you fully understand it.

When a new technology emerges,

I don't know this.
      |
      v
How does it work?
      |
      v
What does it trust?
      |
      v
What happens if that trust fails?

just follow this sequence.

Security is, after all, pretty much a repetition of this process.

It’s not necessarily true that someone who memorizes a lot of tools is automatically good at it,

nor does having a flashy Kali Linux terminal make you good.

It’s about being curious about how systems work,

and when others ask,

“Isn’t this how it’s supposed to be used?”

“But do we really have to use it this way?”

and take a moment to think about it.

Personally, I think people like that tend to stick around in this field for quite a while.

Well, at least that’s how it was for me.