I Finished My Cybersecurity Cert. Here’s What I Can’t Unsee.
· Mohammad Syed
Completing a Certificate IV in Cyber Security at Canberra Institute of Technology changed how I see products, privacy and the small decisions we make online every day.
Key takeaways
- I completed a Certificate IV in Cyber Security (22603VIC) at Canberra Institute of Technology: 16 subjects spanning networks, ethical hacking, security operations, incident response, privacy and ethics.
- The biggest lesson: trust is often the attack surface. People get caught when they’re rushed or tired, not because they’re careless.
- Security is a design problem as much as a technical one, so it belongs in the first conversation about a feature.
- The five changes I’m making: MFA on the accounts that can reset everything else, treating urgent messages as a pause, sharing less data by default, keeping the boring basics consistent, and building privacy into the first sketch.
The first time I used Kali Linux in a controlled lab, I was meant to compromise a practice website.
The target was fake. The user was simulated. The feeling was very real.
I watched how quickly an ordinary interaction could become a doorway into someone’s information. A login. A click. A bit of trust in the wrong place. Once you see how much damage can begin with something so small, you start looking at the internet differently.
I thought about the people I care about. The auntie who taps a link because it looks like a delivery update. The colleague who reuses a password because they have seventeen tabs open and a meeting in two minutes. The family member who assumes an app asking for their contacts must have a good reason.
Most people are busy living their lives. That is exactly why security has to get better.
This week, I completed my Certificate IV in Cyber Security (22603VIC) at the Canberra Institute of Technology. I started the course because I build digital products and wanted to understand the security consequences of the choices we make while building them. I finished it with a much deeper respect for the people defending systems every day, and a fairly permanent inability to look at a permissions pop-up casually again.
CIT describes the qualification as technician-level training across detecting, preventing and responding to cyber threats. The course combines theory with practical work on protecting digital systems, managing security controls and responding to incidents.
The biggest lesson was simple: trust is often the attack surface.
The part that stayed with me
The Kali Linux exercises were conducted in a safe learning environment. No real people. No real systems. Even so, the experience landed hard.
Cybersecurity had felt abstract to me before I started. Firewalls, packets, logs, security policies. Important words, but words that can sit at a comfortable distance from real life.
Then I spent time looking at web vulnerabilities, ethical testing, network traffic, endpoint security and incident response. The abstract became personal. A vulnerable user does not need to be careless or unintelligent. They only need to be rushed, tired, curious, or convinced by something that looks familiar.
Scamwatch describes phishing as an attempt to impersonate a trusted person or organisation to obtain personal information. Fake emails, texts, calls and websites often create urgency precisely because urgency gets people to act before they verify.
That is why I now think about security as a design problem as much as a technical one. Good products make the safe path obvious. Good teams assume people will be busy. Good systems give users a chance to stop, check and recover.
What the course actually covered
The Certificate IV is much broader than a few hacking tools. CIT’s current course structure comprises 16 subjects, spanning the technical foundations, governance and response work required of a cyber security technician.
| Capability area | What I worked through | Why it matters when building products |
|---|---|---|
| Networks and endpoints | Network concepts, TCP/IP and OSI fundamentals, secure endpoint configuration, virtualisation and basic Linux | You cannot protect a product if you do not understand how its data and devices connect. |
| Ethical testing and web security | Ethical hacking concepts, enumeration, port scanning, traffic monitoring, WLAN risks and OWASP-aligned website vulnerability assessment | Security testing reveals weak points before someone with bad intentions finds them. |
| Security operations | Network security controls, firewalls, IDS/IPS concepts, VPNs, cryptography, risk assessment and control monitoring | Controls only matter when they are designed, configured and reviewed with intent. |
| Incident readiness and resilience | Incident-response planning, red/blue/purple-team exercises, disaster recovery and contingency planning | A tough day becomes much worse when nobody knows who owns the next decision. |
| Privacy, ethics and data | Australian cyber legislation, privacy, ethics, data analysis and research | Product decisions affect real people’s information, rights and safety. |
| Practical delivery | Scripting, automation, cloud services, collaboration and an industry-style cyber project | Security work needs clear communication and repeatable action, not heroic last-minute fixes. |
I used Cisco Packet Tracer to work through networking concepts and lab scenarios. I used virtual machines and Kali Linux to understand testing tools and ethical security practice. I worked through the kind of questions product teams should ask before a feature reaches real customers: Where could data leak? Who has access? How would we know something went wrong? Who is responsible when it does?
The course also reinforced an uncomfortable truth for anyone who builds software. Security cannot be a final sprint item that gets attached after the shiny demo. It belongs in the first conversation about data, permissions, identity and defaults.
Five changes I am making straight away
I am still learning. Cybersecurity has a funny way of showing you how much more there is to know. That said, the course moved a few things from “I should probably do that” to “why on earth have I not done this everywhere?”
1. Protect the accounts that can reset everything else
Email is the place to start. If someone gets into it, they can often reset passwords for other services. I am turning on multi-factor authentication across email, financial services, social accounts and services that store personal information. Australia’s Cyber Security Centre recommends MFA wherever possible and highlights its role in reducing password-related account compromise.
Where passkeys or authenticator apps are available, I prefer them over relying solely on SMS codes.
2. Treat unexpected messages as a pause, not a task
A message that creates urgency gets a second look from me now. I open the official app or type the organisation’s address myself rather than following a login link in a text or email. Scamwatch gives the same advice: verify through independently sourced contact details or an authenticated portal, and avoid clicking unexpected links or downloading attachments.
3. Reduce the data I hand over by default
Every permission is a trade-off. I am reviewing app permissions, privacy settings, old connected accounts and smart devices with a simple question: does this service genuinely need this data to do its job?
The Office of the Australian Information Commissioner recommends adjusting privacy settings to reduce collection and third-party sharing, understanding how long information is retained, and keeping connected devices updated.
4. Keep the boring foundations boring and consistent
Automatic updates, unique passphrases, regular backups and sensible access controls have no dramatic demo moment. They still do a huge amount of work. The Australian Cyber Security Centre’s Essential Eight frames foundational mitigation strategies as a baseline that makes it harder for adversaries to compromise systems.
A VPN can be a useful layer on an untrusted network. It does not remove the need to verify a suspicious page, message or request. Different risks need different controls.
5. Build privacy and security into the first sketch
As a product manager and builder, I am bringing security questions forward. Before deciding what a feature should collect, I want to ask whether it needs that data at all. Before shipping a convenience flow, I want to understand the downside of a weak default. Before calling something “done,” I want to know how it behaves when things go wrong.
That will make some conversations slower. It will also make the products better.
A quick word about the “dark web”
I spent time learning about the dark web too, and it is easy to turn that topic into a Hollywood story. The internet has plenty of corners most people will never see, and some are genuinely disturbing. I am going to resist putting a neat percentage on the visible internet versus everything else. Those figures get repeated without clear definitions and often blur the difference between the deep web and the dark web.
The useful takeaway is closer to home. Plenty of harm begins on the everyday internet: a convincing phishing page, an exposed credential, an old account, an app that collected too much, a rushed click. You do not need to travel to obscure corners of the web to find a reason to take your privacy seriously.
What this changes for me
I started this course hoping to become a better builder. I am leaving it with a clearer sense of responsibility.
I build AI and privacy-first products in public. That work now comes with a stronger internal checklist. More questions about data. More care around identity and access. More respect for the fact that every clean user experience sits on top of decisions someone has made about safety.
I will keep learning. There is far too much in cybersecurity to claim otherwise after one qualification. But I am no longer looking at security from the outside.
And if this post persuades one person to switch on MFA, delete an old app connection, or pause before tapping a suspicious link, then it has done something useful.