MeteSec started with a fairly simple realization: I understand things much better when I have to put them into words.
Reading documentation, completing a course or working through a lab can create the feeling that a topic makes sense. Sometimes it really does. At other times, you only notice the gaps when you try to explain the same subject without looking at the original material.
Writing changes the way I engage with a topic. I have to decide what the main point actually is, which details matter and how the individual pieces connect. I have to question whether I understood the reasoning or merely remembered the result. If I cannot explain something clearly, there is a good chance that I have not understood it as well as I thought.
I first became properly aware of this while writing my bachelor’s thesis. The process of researching, organizing and presenting a subject forced me to engage with it much more deeply than reading alone ever had. I have since noticed the same effect when preparing presentations, explaining something to another person or writing down a new insight in a journal.
The explanation is not just the final product of learning. It is part of the learning itself.
That idea is one of the main reasons MeteSec exists.
A Place to Make Knowledge Stick#
I spend a lot of time moving between different parts of cybersecurity. Some of that comes from professional work, some from certifications, technical labs, books, documentation, conversations and personal experiments.
The problem with learning continuously is that it becomes very easy to move straight from one subject to the next. You finish a module, understand it well enough at that moment and then continue. A few weeks later, you may still remember the general idea, but many of the connections and details have already started to disappear.
I want MeteSec to slow that process down.
When a topic genuinely changes my understanding, I want to capture what made the difference. When I discover that an assumption was wrong, I want to record what I believed before and why I changed my mind. When I work through something technical, I want to explain the reasoning rather than save only the final command, query or solution.
The purpose is not to document every hour of studying. That would quickly become noise. The purpose is to preserve the parts that are worth remembering.
A Journal, but Not a Private Diary#
MeteSec is personal, but it is not intended to be a private diary published on the internet.
I want it to provide a realistic view of an ongoing cybersecurity journey: what I am learning, what I find useful, what I struggle with and how my understanding develops over time.
A lot of career content is written backwards. Once someone has reached a certain position, their path is turned into a clean story where every decision appears intentional and every step seems to have prepared them perfectly for the next one.
Real development usually does not feel like that while it is happening.
Interests change. Some learning paths lead nowhere. Basic topics sometimes turn out to be more valuable than advanced ones. A subject that initially seems irrelevant can later explain something you have been working with for years.
I want to document the journey while it is still taking place, including the uncertainty and the changes in direction. That may also give other people in similar positions a more useful point of comparison than another finished success story.
My View of Cybersecurity#
Another reason for creating this site is that I am still developing my own understanding of what cybersecurity actually includes.
The field is often divided into separate roles and labels: engineering, offensive security, defensive security, governance, cloud, application security, incident response, identity, vulnerability management and many others.
Those categories are useful, but the underlying systems do not respect them as cleanly as job descriptions do.
A vulnerability may begin with a development decision, depend on an infrastructure configuration, be exploited through an offensive technique and only become visible through defensive telemetry. Understanding the full problem often requires knowledge from several areas.
My strongest professional background is currently in cyber defense, detection engineering and security operations. At the same time, I am deliberately expanding into offensive security, secure engineering, software security, infrastructure and other parts of the field.
I do not want to present myself as equally experienced in all of them. I am not. MeteSec should make the difference visible between subjects I know from professional experience, subjects I have tested myself and subjects I am still trying to understand.
The broader goal is to identify which knowledge actually helps connect the different parts of cybersecurity and which information is mainly noise, marketing or repetition.
More Than a Blog#
I also wanted one place that brings my work together.
Articles are only one part of that. Over time, MeteSec should also contain selected projects, public talks, certifications, technical experiments and a structured overview of my professional background.
A social-media profile is not particularly good at representing that kind of work. Posts disappear into a timeline, technical discussions are reduced to a few paragraphs and projects become isolated links without context.
A traditional CV has the opposite problem. It can list a role, technology or certification, but it cannot show how I think about a subject, what I learned from it or how one area connects to another.
This site sits somewhere between those two formats.
The CV provides the formal overview. The articles show my thinking. Projects show what I have built or tested. Public talks show the subjects I considered important enough to research, structure and present to other people.
Together, they provide a more complete picture than any one of those sections could provide on its own.
What I Plan to Publish#
The writing on MeteSec will mainly fall into a few broad areas.
There will be posts about my learning journey: subjects that changed my understanding, certifications that were more or less useful than expected and lessons that only became clear after practical experience.
There will also be commentary on current cybersecurity events, technical claims and industry discussions. I do not want to reproduce the news. I want to look at what is actually confirmed, understand the technical context and then add my own assessment.
Some articles will be technical deep dives. These will focus on subjects I have worked with, tested or deliberately researched. They may include code, detections, configurations or lab results, but the main purpose will be to explain the reasoning behind them.
Projects and talks will have their own sections. A project page should explain what problem I was trying to solve, what I built and what I learned. A talk page should preserve the topic, context and supporting material instead of letting the work disappear after the presentation is over.
Not everything I learn will become public content. The site is meant to be curated, not complete.
Writing Without Pretending#
Publishing technical content creates a temptation to sound more certain than you really are.
I want to avoid that.
There should be a clear difference between a documented fact, something I have personally tested, an interpretation based on available evidence and a personal opinion. When I am still learning a subject, I want to say so rather than write from the position of an expert I am not.
I also expect some of my views to change. A conclusion that seems reasonable today may look incomplete after more experience or better information. That is not a failure of the journal. It is part of the reason for keeping one.
The objective is not to create a permanent record of always having been right. It is to create a visible record of learning how to think more clearly.
Build. Break. Defend.#
Build, Break and Defend describe the perspective behind MeteSec.
Build is about understanding how applications, infrastructure, tools and security controls are created.
Break is about understanding how systems fail, how weaknesses become attack paths and how those failures can be explored in authorized environments.
Defend is about visibility, detection, investigation, response and building controls that work in real environments.
I currently approach that model from a defense-heavy starting point. The goal is not to force every topic into one of three boxes, but to keep asking how the different sides affect each other.
MeteSec is the place where I want to collect those connections, strengthen my own understanding and give others an honest view of the journey while it is still unfolding.
