DEV Community: Jahnavi Thakkar

Bridging Code and Security: Risk, Pen Testing, MITRE ATT&CK and Stapler | GCF Parul University (Part 2)

Jahnavi Thakkar — Sat, 31 Oct 2026 15:15:14 +0000

This is the second half of my one-week cybersecurity training with the Global Certification Forum (GCF) at Parul University. Part 1 covered security principles, network security and endpoint hardening: Part-1

This half has the topics I was most looking forward to, and the one lab that gave me trouble.

4. Vulnerability assessment and risk management
Threat intel was first: CVEs, security reports, news, and automated vs. ad hoc intelligence. The syllabus is clear about where they fall short. A CVE tells you a weakness exists. Whether it matters in your environment is a separate question, and that’s where risk comes in.

A vulnerability is a weakness. Risk is that weakness plus how likely it is to be exploited and how bad the damage would be. The way I remember it:

risk = likelihood x impact

The syllabus uses four severity levels: low, medium, high and extremely high.

Then pen testing, which is the part I care about most, since offensive security is where I want to end up. You start with vulnerability identification, active and passive recon, and port scanning and automation. At the end comes the report to stakeholders, with recommendations for fixing what you found. I’d have skipped over that last step before this week. It turns out a bug nobody can act on isn’t much use.

If you build software, there’s one more piece: testing an app before it ships.

5. Incident handling
This domain is dense. Monitoring with SIEM and SOAR. Forensics, including evidence handling and chain of custody. Frameworks like the Cyber Kill Chain, MITRE ATT&CK, the Diamond Model and the Pyramid of Pain. The NIST SP 800-61 response lifecycle, how GDPR, HIPAA and PCI-DSS change reporting requirements, and DR/BCP basics (RPO, RTO, hot, warm and cold standby).

The easiest thing to get wrong is telling alerts apart, so here’s the table I wish I’d had earlier:

False negatives are the worst of the four. If nothing fired, nobody’s looking.

MITRE ATT&CK was my favourite part of the domain. Thinking in tactics, techniques and procedures makes an incident read like a sequence instead of a pile of events.

Stapler on VulnHub
Outside the syllabus, I solved Stapler from VulnHub. It was challenging.

It pulls together recon, enumeration and choosing a path to follow. More than once I’d run everything I knew and nothing worked. That was frustrating, but it’s much closer to a real assessment than a guided lab, where there’s one intended answer waiting for you.

I’m writing up the full walkthrough, so no spoilers. If you’re starting boot2root machines, don’t skip enumeration, and take notes as you go.

Closing thoughts
My main takeaway is that revision wasn’t wasted time. Going through familiar topics in a structured week showed me gaps I’d have missed otherwise. The labs, the SQL injection ones in Part 1 and Stapler here, taught me more than any slide did. And “entry-level” doesn’t mean easy, because the hard part is connecting the domains.

If you’re a student thinking about security, grab the syllabus, do the labs, and write about what you learn. Writing is how I found out what I didn’t understand.

Which boot2root machine gave you the most trouble? Drop it in the comments. I’m looking for my next one.

Bridging Code and Security: SQL Injection, Hardening and Network Basics | GCF Parul University (Part 1)

Jahnavi Thakkar — Fri, 30 Oct 2026 17:01:41 +0000

Last week I did a one-week cybersecurity training at Parul University, through the Global Certification Forum (GCF). Certificate at the end. The syllabus was Pearson’s IT Specialist Cybersecurity objectives, so it’s pitched at entry-level technicians and junior analysts.

A lot of it, I’d already seen in my CSE classes. A couple of topics were new. What I didn’t expect was how many gaps showed up once I had to cover everything in five days instead of a semester.

This is Part 1, the first three of five domains. If you write code and security has only ever shown up in code reviews, this is a rough map.

The five domains:

Security Principles
Securing the Network
Securing Endpoint Devices
Vulnerability Assessment and Risk Management
Incident Handling

1. Security principles
This domain is the vocabulary. CIA triad, defense-in-depth, Zero Trust, hardening, data classification, governance. Then the frameworks: NIST CSF, ISO/IEC 27000 and the CIS Controls. They sound dry, but you’ll hear them in every real security conversation.

The attack list is long. If you write code, the ones to care about are SQL injection, input manipulation and buffer overflow. Privilege escalation and brute force aren’t far behind. Social engineering gets its own section: spear phishing, vishing, smishing, whaling, watering holes, tailgating, malicious QR codes. The syllabus also says AI and bots are making these attacks more convincing. That’s the one line I keep thinking about.

Access management (AAA, RADIUS, MFA) and encryption (symmetric vs. asymmetric, hashing, PKI, data in transit, at rest and in use) round it out.

SQL injection, from the PortSwigger labs
We did a few SQL injection labs on PortSwigger’s Web Security Academy. I knew the theory already. It didn’t really stick until I got past a login page myself.

The bug is simple. This code glues the user’s input straight into the query:

python

Vulnerable: user input is concatenated into the query

def login(conn, username, password):

    query = (

        "SELECT * FROM users WHERE username = '" + username +

        "' AND password = '" + password + "'"

    )

    return conn.execute(query).fetchone()

So the input stops being data and becomes part of the SQL. The fix is a parameterized query:

python

Safer: parameterized query

def login(conn, username, password_hash):

    query = 'SELECT * FROM users WHERE username = ? AND password_hash = ?'

    return conn.execute(query, (username, password_hash)).fetchone()

That’s what “input validation and sanitization” means in the syllabus. (It also assumes hashed passwords, which is the other half of doing this properly.) The labs are free, so just go do them.

2. Securing the network
This domain is about why common protocols are risky and what to put around them. The easy part is the pairs:

You’re also expected to know the weak spots of TCP, ARP, ICMP, DHCP, DNS, SMTP, SNMP, CDP/LLDP and syslog. The defenses are segmentation (DMZs, VLANs), NAT, firewalls, ACLs, IDS/IPS, proxies, honeypots, VPNs, NAC and cloud security groups. Wireless gets a short section too: MAC filtering, encryption standards, SSID.

The part I liked most was reading firewall and IDS logs. You’re not just collecting data. You’re asking whether it looks normal.

3. Securing endpoint devices
The most hands-on domain. It covers hardening Windows, macOS and Linux (permissions, disk encryption, CIS benchmarks), patching, compliance (PCI DSS, HIPAA, GDPR), system logs and malware removal.

The tools it names: netstat and ss for connections, nslookup for DNS, nmap and zenmap for scanning, Wireshark and tcpdump for packet capture. A few to try on a Linux machine you own:

bash

What is listening on this machine?

ss -tulpn

Which services and versions are exposed on your own host?

nmap -sV 127.0.0.1

Watch DNS traffic (needs root)

sudo tcpdump -i any port 53

One thing I didn’t know: malware can infect restore points and backups. So removal isn’t just running a scan. It’s containment, quarantine, treatment and inoculation.

What’s next
Part 2 covers vulnerability assessment, risk management, penetration testing, incident handling, and Stapler, a VulnHub machine I found properly challenging.

If a lab or resource made security click for you, drop it in the comments. I’m always looking for new ones.

Day 2 of DevOps: Git, CI/CD and Deploying a Webpage on AWS EC2

Jahnavi Thakkar — Sat, 03 Oct 2026 09:01:30 +0000

Part 2: DevOps and the Workflows Around It

The moment my webpage loaded in the browser, served from an AWS EC2 instance, the whole session finally clicked. A few hours earlier, DevOps had been a word on a slide. Now it was something I had built and deployed myself.
This is Part 2 of my hands-on cloud series from Lakshya Connect at Parul University. In Part 1, we covered AWS fundamentals: IAM for permissions, EC2 for virtual servers, and S3 for storage. Day 2 was also led by Kinjal Gandhi and moved from understanding those pieces to using them in a real DevOps workflow.

Where Does Your Application Actually Run?

The session opened with a quick cloud computing recap, and then the instructor asked a question that quieted the room: once you’ve built an application, where does it actually run?
That question is where DevOps begins. A developer writes and tests code on their own machine, and it works there. Getting it running reliably for real users is a separate problem, and when the two sides work separately, the handoff brings manual steps, delays and confusion. DevOps addresses this through collaboration, automation and faster feedback between development and operations. We also looked at the DevOps lifecycle: plan, code, build, test, release, deploy and monitor, which then feeds back into planning. It’s a loop, not a straight line.

Git and GitHub: Version Control in Practice

Git tracks changes to your code on your own machine, and GitHub hosts that code so others can review it, collaborate on it and build on it. We created a repository, added a file, committed it and pushed it to GitHub. Doing it yourself is different from reading about commits and pushes in a tutorial. What I took from it is that a commit isn’t just saving a file. It’s a recorded, reversible step in the history of a project, and that history is what makes teamwork and safe changes possible.

CI/CD: Why Automation Matters

CI/CD stands for Continuous Integration and Continuous Deployment. Code is integrated frequently, tested automatically, and deployed once it passes. The reason this matters is that manual releases are repetitive and easy to get wrong in small ways. Automating the build, test and deployment steps cuts that repetitive work and makes every release follow the same process.

From Theory to Something Actually Live

This was the most valuable part of the two days. We took the EC2 instance from Day 1 and deployed a small webpage onto it. I wrote the page, pushed it to GitHub, deployed it to the server, and opened it in a browser to see it running.
The page itself was simple, but the experience connected everything. IAM, EC2, Git and deployment stopped being separate topics and became one path from code on my laptop to an application on a cloud server. Before this, I understood each concept individually. Afterward, I understood why they exist together.

The Wider DevOps Toolset

We finished with a short overview of tools that build on these foundations:
Docker packages applications into containers so they run the same way everywhere.
Terraform enables infrastructure as code, defining cloud resources in files instead of setting them up by hand.
Kubernetes orchestrates containers at scale.
Kinjal ma’am’s point stayed with me: the tool isn’t the goal, the process is.

What I Learned Across Both Days

Cloud computing gives you somewhere to run applications, and DevOps gives you a reliable way to get them there. Day 1 taught me the building blocks of AWS. Day 2 showed me the process that moves code from a laptop into those blocks consistently.
I wish to practice Git workflows on my own projects, set up a simple CI/CD pipeline with GitHub, and maybe explore Docker before moving on to infrastructure as code with Terraform.
Thank you, Kinjal Gandhi ma’am, for a genuinely hands-on session, and thank you to Lakshya Connect and Parul University for organizing it.

Spent a few Days Learning AWS. Here’s What Stuck.

Jahnavi Thakkar — Sat, 03 Oct 2026 08:58:13 +0000

Part 1: Day 1 — Building the Cloud Fundamentals

Quick backstory before I get into this.

I’ve been knee deep in cybersecurity for a while, mostly VA&PT and CTFs, and I hit that point where everything starts feeling like homework. Not burnt-out burnt out, but close enough that I knew I needed to look at something else for a bit before I lost interest in the thing I actually like. As a third-year CSE student at Parul University, I’m used to jumping between subjects, so when I heard about a Cloud Computing and DevOps workshop happening under Lakshya Connect, taken by Kinjal Gandhi ma’am, I signed up mostly just to change the scenery in my head. Turned out to be exactly what I needed.

Understanding Cloud Computing
Day 1 was all about AWS basics, but the way it was taught made a lot of things click that I’d only half understood before.

We started with something dumb simple, actually. Where does your data go when you post a photo on Instagram or hit play on Netflix? Sounds obvious, but most of us never actually sit and think about it. Somewhere behind that one tap is computing, storage, and networking, all working together, and none of it is on your phone or laptop. That’s cloud computing: using someone else’s computers and infrastructure over the internet instead of running everything on your own hardware.

Then we got into cloud vs traditional IT, which honestly is just “buy everything yourself” vs “rent what you need, when you need it.” Traditional IT means servers, data centers, and hardware maintenance, all paid for upfront whether you use them or not. Cloud computing flips that: you switch things on when you need them, and pricing is usually based on what you actually use, though that varies by service and provider. Made a lot more sense once it was put that way.

We also went over IaaS, PaaS, and SaaS. Infrastructure as a Service, Platform as a Service, Software as a Service, basically how much of the “behind the scenes” work you’re responsible for changes depending on which one you’re using. With IaaS you’re managing more yourself; with SaaS, almost none of it. Not going to lie, this part needed a second explanation before it stuck, but it did. I used to think “the cloud” was just one big generic thing you either used or didn’t. Turns out it’s layers, and figuring out which layer you’re working at changes how much control, and how much responsibility, you actually have.

Getting Hands-On: IAM, EC2, and S3
Then came the part I actually came for.

IAM first. Identity and Access Management, boiled down to three questions: who are you, what are you allowed to do, and what can you touch. The whole idea is giving people only the access they need, nothing more, which is basically the principle of least privilege. As someone from a security background, this felt oddly familiar, and I liked that.

Then EC2, Elastic Compute Cloud, basically a computer that lives somewhere in AWS instead of on your desk, that you can spin up, shut down, and configure however you want. We went through the terms: AMI (the template your instance is built from), instance type (how much power and memory you get), key pairs (how you securely log in), and security groups (your instance’s firewall rules). Then we just… launched one. There’s something weirdly satisfying about watching your own instance come alive on the console for the first time.

Last was S3, Simple Storage Service. If EC2 is your machine, S3 is basically your storage locker: images, files, backups, whatever you need to keep around. Created a bucket, uploaded a file, done. Simple, but it made the whole thing feel real instead of just slides.

The “AHA” Moment

This is where it actually clicked for me. I’d been treating IAM, EC2, and S3 as three separate things to learn, checkboxes on a workshop agenda. Then it hit me: they’re not separate at all. If an EC2 instance needs to read or write something in an S3 bucket, it doesn’t just reach in and grab it. It needs permission, and that permission comes from IAM. You attach an IAM role to the instance, and that role decides exactly what it’s allowed to do in S3, nothing more. That was the moment the three pieces stopped being separate slides and started being one system: IAM decides who can act, EC2 is where the action happens, and S3 is where the result lives.

What I Learned on Day 1
By the end of the day, the whole picture was pretty clean in my head: cloud computing leads to AWS, AWS leads to who has access (IAM), where the computing happens (EC2), and where stuff gets stored (S3). Going in, I thought cloud services were mostly about saving money on hardware. Coming out, I understood it’s really about how responsibility and control get divided up between you and the provider, and that changes everything about how you design, secure, and pay for a system.

Needed this reset more than I realised. Thankful to Kinjal Gandhi ma’am for making it this easy to follow, and to Lakshya Connect for putting it together. Day 1 gave me the fundamentals; Day 2 moves into DevOps, where those AWS basics actually get put to work. I’ll share that next.