Where I Am Right Now
Domains 1, 2, and 3 of the ISC2 CC are done. Security Principles, Incident Response and Business Continuity, Access Control Concepts — three modules, average score of 96%, and a set of concepts that are starting to feel less like study material and more like a working mental model.
I have also been honest with myself about where my interest sits. Defensive security is important work. But what genuinely pulls my attention is offensive security — understanding how systems fail from the outside, testing whether controls actually hold under pressure, and thinking the way an attacker thinks in order to find what defenders might have missed. That is the direction I am heading.
I am not claiming I am there yet. What I want to do here is think through what the foundation I have built actually means for that path — and why the two are not as separate as they might seem.
Why Offensive Security Still Starts With the Same Questions
There is a temptation to think that offensive security is a different discipline — more technical, more exciting, disconnected from the policy-heavy fundamentals you study early on. I do not think that is accurate.
Every penetration test, every vulnerability assessment, every security audit begins with the same core questions that Domain 1 of the ISC2 CC asked me to think about:
- What are the assets?
- What are the vulnerabilities?
- What is the likelihood a threat actor exploits them?
- What is the impact if they do?
That is risk assessment. And risk assessment is exactly what a security tester is performing when they map a target environment, identify weak points, and prioritize what to probe.
The CIA triad does not disappear when you shift perspectives either. An attacker targeting confidentiality is trying to extract data without authorization. An attacker targeting integrity is manipulating records or processes. An attacker targeting availability is disrupting access — through a denial of service, ransomware encryption, or taking down a critical service. Understanding what an attacker is trying to accomplish maps directly onto what a defender is trying to protect.
Speaking of ransomware — reading security journalism like Krebs on Security reinforces this. A recent piece on the ransomware group known as The Gentlemen noted that the group specifically targets internet-facing devices — VPNs and firewalls — as their entry point, then moves to encrypt entire networks within hours. That is a textbook availability attack at scale. The entry vector is a technical weakness; the impact is catastrophic business disruption. Both sides of that equation are things Domain 2 covered directly: what a breach looks like, how containment works, and why RTO and RPO matter when systems go down.
What Access Control Knowledge Gives a Tester
Domain 3 might be the most practically useful thing I have studied so far, specifically for the direction I want to go.
Access control concepts — least privilege, need-to-know, segregation of duties, the difference between DAC, MAC, and RBAC — are not abstract policy ideas. They represent the rules a system is supposed to enforce. When those rules are configured incorrectly, or when the gap between policy and implementation is wide, that is where vulnerabilities live.
A security tester is not randomly probing systems hoping something breaks. They are asking: where are the access controls? Are they configured correctly? Are permissions broader than they should be? Is there an account with privileges it does not need? Is there a service running under an identity that has more access than its function requires?
Those are the same questions a security administrator should be asking during an access review. The difference is the tester is asking them from outside, with the intent of proving whether the answers matter.
The Home and Small Business Starting Point
My plan is to start where my current skill level makes sense — home networks and small business environments. Not because those are easy targets, but because they represent a realistic scope for someone building practical skills responsibly.
Small business environments often have exactly the kinds of gaps that foundational knowledge surfaces: default credentials left unchanged, overly permissive network configurations, no network segmentation between guest and internal systems, accounts that were never deprovisioned when someone left. These are not exotic vulnerabilities. They are access control failures and risk management oversights — the kind that Domains 1 through 3 described from the defensive side.
Practicing in controlled environments — TryHackMe rooms, home lab setups, and properly scoped exercises — is how I intend to develop the technical side of that work. The labs I have been running through TryHackMe have given me a feel for how structured offensive exercises work: working through a defined scope, using guided tools, and thinking about what the output of a scan or enumeration step actually means for a defender.
The technical fluency is still building. But the conceptual foundation for understanding what I am looking at — and why it matters — is already there.
Responsibility Is Not Optional
One thing the ISC2 Code of Ethics made clear: acting responsibly is not a soft value. It is a professional requirement.
Offensive security only has value when it is authorized, scoped, and conducted ethically. A security tester who operates outside those boundaries is not a researcher — they are a threat actor. The distinction is entirely about authorization and intent.
Every piece of practical work I document here will be in controlled, legal environments: labs, my own systems, explicitly scoped exercises. That is non-negotiable, not because of rules, but because it is the only way to build a reputation worth having.
What This Foundation Actually Means
I spent the first phase of this certification learning how systems are supposed to be protected. The next phase is learning how to test whether that protection is real.
Those two things are the same discipline looked at from different angles. The assets, vulnerabilities, threats, controls, and consequences do not change depending on which side of the exercise you are on. What changes is the perspective — and the questions you ask first.
I am still early in this process. Domain 4 covers network security, which is where a lot of the technical groundwork for offensive work lives. That is the next focus. But the foundation is solid, and the direction is clear.