My path into cybersecurity has been kind of messy, but I actually think that has helped me. I did not start with a perfectly planned security roadmap where every certification, lab & project was selected years in advance. I moved through communications, IT systems, Linux, networking, troubleshooting, development, game systems, local AI tooling & infrastructure because I kept finding another layer I wanted to understand.
Eventually security became the thing connecting all of those layers.
If I am responsible for a system, I do not only want to know which button makes it work. I want to know why it works, what it depends on, what it trusts, how it fails & what I would look at when it stops behaving normally.
Security makes far more sense when you understand the system underneath it.
1. I started closer to systems than security
A lot of my foundation came from communications & IT work. Troubleshooting connectivity, dealing with technical equipment, software problems, users & systems teaches you pretty quickly that the clean diagram is not the real environment.
Real systems are messy. A cable fails. A configuration is almost correct. Documentation is old. A user describes the symptom instead of the cause. Two problems happen at the same time & make each other look like one problem.
That kind of troubleshooting taught me to ask a question I still use constantly: what do I actually know?
Not what I assume. Not what should be happening. What evidence do I have right now?
2. Linux made the machine less mysterious
Linux was a big step because it forced me to interact with the operating system more directly. Processes, services, permissions, logs, filesystems, networking & configuration stopped being abstract ideas hidden behind a settings menu.
That also made security terminology easier to understand. Least privilege sounds like corporate language until you are actually dealing with users, groups & file permissions. Attack surface makes more sense when you run ss & see which services are listening. Persistence becomes much more concrete when you understand how a service starts automatically.
I think this is one of the reasons I like Linux for learning. It does not automatically make someone good at security, but it gives you a lot of opportunities to see the mechanics.
3. Networking taught me to stop thinking about one machine at a time
A perfectly configured computer can still live inside a badly designed environment.
Networking forced me to think about relationships. Who can reach this service? Which device is providing DNS? Where does this route go? Why can this machine talk to that machine? What happens if the device I trust today becomes compromised tomorrow?
Once you start thinking that way, cybersecurity stops looking like antivirus on individual computers & starts looking like a system of trust, pathways & information.
A compromised account is a key. A network path is a hallway. An exposed service is a door. Security is partly deciding where those doors should exist & who should be holding the keys.
4. Building software changed the way I look at failure
Development gave me a different perspective because suddenly I was not only administering systems. I was creating the assumptions those systems would later depend on.
A security problem can come from permissions or firewall rules, but it can also come from bad validation, unclear authority, a broken data model, unsafe defaults, dependency choices or code that assumes the client is telling the truth.
Game development has been surprisingly useful here because games are full of state, persistence, networking, authority, user input & complex systems interacting with each other. When those boundaries are sloppy, bugs appear very quickly.
It also taught me to value Git, testing & lessons-learned documentation. If I spend three hours understanding a failure & then write nothing down, I have basically agreed to pay the same price next time.
5. AI became infrastructure much faster than people talk about it
I use AI a lot, including local models & development agents. I think these tools are extremely useful, but I also think the way people talk about them sometimes skips an important step.
If an AI can only answer a question in a chat box, the risk is one thing. If it can read my repository, edit files, execute shell commands, access GitHub, call APIs or interact with a database, it is no longer just a chatbot. It is part of my infrastructure.
That changes the questions I should be asking. What can it read? What can it change? Which credentials can it reach? What happens if its reasoning is wrong? Can I review the change? Can I roll it back?
I don't think the answer is to avoid AI. I think the answer is the same as with any powerful technical tool: understand what authority you are giving it.
6. I learn far better when the problem is real
I can read about a technology for hours & understand the theory. I normally learn far more when I have to make the thing work.
That is why I keep leaning toward projects instead of only collecting courses. Build the network. Deploy the website. Configure the workstation. Break the service. Read the logs. Fix the problem. Put it in Git. Write down what happened.
The failure is often where the useful learning starts.
Build it. Test it. Understand it. Document what failed & make the next attempt better.
7. Security knowledge is useless if nobody can understand you
This has become increasingly important to me. Cybersecurity has a huge vocabulary & a lot of it exists for good reasons. Precise terms are useful when precision matters.
But if I explain a real risk to somebody & they leave the conversation without understanding what I meant, I did not communicate successfully just because every term I used was technically correct.
I would rather explain authentication as the process of proving you are the person who should have the key, then introduce the technical terminology, than throw five abbreviations at someone & expect them to keep up.
The reader is not the problem. The explanation is my responsibility.
8. Knowing security does not make you immune to mistakes
I also do not want this site to become a collection of stories where I always made the perfect decision. That is not realistic.
People make mistakes. Smart people make mistakes. Experienced people make mistakes. Social engineering works precisely because attackers try to create circumstances where the malicious action looks reasonable.
Understanding security should make us better at recognizing patterns, reducing risk & learning from mistakes. It should not turn into pretending we can never be fooled.
9. Where I am going now
I want more depth in defensive security, system hardening, network architecture, monitoring, incident analysis, automation & practical security engineering.
I also want Shimori Cyber to become evidence of that process rather than a page where I simply claim I know things. Projects should show the architecture. Writeups should show the reasoning. Failures should show what changed afterward.
There is always going to be more I do not know. I am actually fine with that. The more technical work I do, the more I realize that knowing where the gaps are is useful information too.
Keep building & keep the reasoning
I don't expect to reach a point where I can say I finished learning cybersecurity. The field changes too quickly & the systems underneath it keep changing with it.
What I can keep consistent is the process. Understand what I am trying to build. Learn enough to make it work. Test the assumptions. Investigate the failures. Improve the system & preserve the lesson.
That is what I want Shimori Cyber to represent: not perfection, but visible technical growth & stronger systems because I took the time to understand why they work.