Where I Am Right Now
I've finished Domains 1, 2, and 3 of the ISC2 CC certification. Security Principles, Incident Response and Business Continuity, and Access Control Concepts — each one building on the last. The assessment scores have been solid, and more importantly, the concepts are starting to connect in a way that feels less like studying and more like actually understanding how systems are designed to work.
Now I'm thinking about what comes next, and my honest interest is on the offensive side of security. Not in the abstract — I mean I want to learn how to test systems, find weaknesses before someone else does, and help people understand where they're exposed. Ethical security testing. Penetration testing. That direction.
Before I get there, I wanted to spend some time with CISA — the Cybersecurity and Infrastructure Security Agency — because understanding what the defender's side looks like at scale is directly relevant to understanding what you're actually testing when you approach a system as an ethical tester.
What CISA Is and Why It's Worth Understanding
CISA is the U.S. federal agency responsible for protecting the nation's critical infrastructure from physical and cyber threats. It sits under the Department of Homeland Security and works across sectors — government agencies, small businesses, schools, hospitals, industrial control systems, and more.
What stands out when you spend time on the site is how much of CISA's work is about communication and coordination rather than just enforcement. They publish advisories when vulnerabilities are being actively exploited. They maintain the Known Exploited Vulnerabilities catalog — a running list of CVEs that threat actors are using right now, not just theoretically. They issue binding operational directives that require federal agencies to take specific remediation steps within defined timeframes.
For someone learning offensive security, this is useful framing. The vulnerabilities CISA is tracking aren't hypothetical. They're the ones that got through real defenses in real environments.
How the Defender's View Connects to Offensive Practice
Everything I studied in Domain 1 — the CIA triad, risk terminology, defense in depth — maps directly to what an attacker is looking for.
Confidentiality controls fail when access is misconfigured or credentials are weak. That's an attacker's entry point. Integrity controls fail when input validation is missing or someone can modify data without detection. Availability controls fail when systems aren't patched or resilience plans aren't tested. An ethical security tester is essentially asking: where does this system's defense fail, and how would a real attacker find that?
Domain 3 — access control — is especially relevant here. The principle of least privilege exists because excessive permissions create opportunity. Segregation of duties exists because no single person or process should have unchecked access. When I eventually work through penetration testing methodology, I'll be looking at exactly these things: who can access what, what's misconfigured, where privilege escalation is possible.
Domain 2 matters too. Incident response planning only works if the organization has actually tested it. Business continuity and disaster recovery plans only hold up if they reflect the real threat landscape. Part of ethical security testing is helping surface the gaps that a post-incident review would otherwise catch too late.
Where I'm Planning to Start
My plan is to focus first on home and small business security testing. The reasons are practical: small environments are manageable, the attack surface is constrained, and the concepts I've been studying in the ISC2 CC apply directly — access control, network security (Domain 4, still working through it), basic incident response.
CISA actually dedicates a section of its site specifically to small and medium businesses, which tells you something about where exposure is concentrated. Larger organizations have dedicated security teams, compliance requirements, and sometimes formal penetration testing contracts. Smaller organizations often don't. They rely on whoever set up the router still having the admin password written on a sticky note.
That's not a criticism — it's a realistic picture of where security fundamentals matter most and where someone early in their career can build genuine, useful skills in a controlled, ethical way.
What Ethical Testing Actually Means
This is worth being clear about, because it's not just a disclaimer. Ethical security testing means explicit, documented authorization before touching any system. It means operating within scope. It means reporting what you find, not exploiting it. It means understanding the legal boundaries — the Computer Fraud and Abuse Act in the U.S. exists, and ignorance of scope is not a defense.
The entire point of practicing in environments like TryHackMe — where I'm currently working at Level 4 — is to build the skill set in controlled, legal, purpose-built labs before applying it anywhere real. That foundation matters. Rushing past it to look more advanced is exactly the wrong approach.
What I'm Taking From This
The defender's perspective isn't separate from offensive security — it's the prerequisite. Understanding why access controls are designed a certain way is what tells you how they fail. Understanding incident response is what tells you what an organization's detection capabilities look like. Understanding the CIA triad is what tells you which impact matters most to a specific target environment.
CISA's work is a useful reference point because it reflects where real threats are hitting real systems. Reading their advisories isn't just background reading — it's a window into what's actually being exploited, which is exactly the knowledge an ethical tester needs to do useful work.
I'm still early in this. Domains 4 and 5 of the ISC2 CC are ahead of me, and there's a lot of hands-on practice between here and working independently on security assessments. But the direction is clear, and the foundation is solid.