If you're just entering the world of cybersecurity, you'll very quickly come across hundreds of different certifications, recommendations, and opinions. The problem is that a large number of lists on the internet come down to copying the same recommendations year after year. That's why the question of how much a particular certification will actually help you when you first sit down in front of a real system, security tool, or incident is often neglected.
This text was created from the perspective of a person who works in the field of cybersecurity every day. I'm not involved in penetration testing, malware development, or risk management at the management and board level. My area is security operations, network security, system administration, incident analysis, detections, and working with security tools. That's precisely why the certifications on this list were chosen from that point of view.
Cybersecurity is not a single profession. Within it there is network security, system security, identity management, security operations, forensics, cloud security, incident response, and many other areas. There is no single certification that will cover everything. However, there are a few certifications that represent a very solid start for a large number of future professionals.
CCNA is one of the rare entry-level certifications that simultaneously forces you into a theoretical and practical understanding of technology. That's exactly why I consider it one of the most valuable certifications for starting a career in information technology and cybersecurity.
A large number of beginners want to immediately study advanced security topics, but in doing so they skip the network fundamentals. In practice, the network is precisely the place where a large part of security events take place. Analyzing network traffic, working with firewalls, network segmentation, virtual private networks, intrusion detection and prevention systems, and analyzing suspicious communication all require a good understanding of network technologies.
CCNA covers addressing, routing, switching, wireless networks, automation, security fundamentals, and the operation of network infrastructure. A person who properly masters this material often advances much more easily toward security operations, incident analysis, and working with SIEM platforms.
One thing that rarely anyone mentions is that CCNA often develops a way of thinking that you later use in security. When you learn how a network works under normal conditions, it's much easier to recognize when something isn't normal. That's exactly where a large part of security work begins.
The certification is valid for three years and can be renewed through the Cisco Continuing Education program or by retaking the appropriate exam. From my perspective, there are few entry-level certifications that push a candidate so much to truly understand the technology, and not just the definitions. That's exactly why I still consider CCNA to this day one of the highest-quality starting points for people who want to build a career in networks or cybersecurity.
CompTIA Security+ is probably the most well-known entry-level certification in the field of cybersecurity. If you search through job ads in the security field, you'll very often come across this particular certification.
Unlike the CCNA certification, Security+ doesn't go as deep into individual technologies. Its value lies in its breadth. The candidate goes through threats, vulnerabilities, identity management, cryptography, security operations, risk management, and basic security concepts that appear in almost every security environment.
From my own experience, I can say that Security+ is one of the certifications that employers and recruiters most often recognize when it comes to entry-level security certifications. This of course doesn't guarantee a job, but it often helps a résumé get additional attention.
CompTIA also offers an interesting certification ecosystem. By passing more advanced certifications, it's possible to renew certain lower-level certifications within the same program, which can make sense in the long run for people who plan to build a career through the CompTIA certification path.
It's hard today to find an organization that doesn't use Microsoft technologies in some way. That's exactly why SC 900 represents a very useful entry-level certification for anyone who wants to work in the field of cybersecurity.
The material covers Microsoft Entra identities, Microsoft Defender security solutions, Microsoft Purview, concepts of data protection, access management, security operations, and compliance.
It doesn't go deep into individual technologies, but you get a very solid overview of the Microsoft security ecosystem. This is especially important because a large number of organizations use Microsoft Defender products to protect endpoint devices, email, identities, and the cloud.
SC 900 is not a formal prerequisite for SC 200, but it represents an excellent introduction to the Microsoft security world. An additional advantage is that Fundamentals certifications don't expire.
SC 900 is not a certification after which you'll know how to administer Microsoft security solutions. Its value lies in the fact that it provides an overview of the entire ecosystem and helps you understand how identities, data protection, security operations, and compliance are interconnected.
Cloud security is no longer a specialization reserved only for large organizations. Today, almost every company uses at least part of its infrastructure or services hosted in the cloud.
AZ 900 explains the basic concepts of cloud computing, Azure services, network architecture, resource management, security, and the shared responsibility model. These are terms that almost every cybersecurity professional will encounter sooner or later.
Although it's an entry-level certification, AZ 900 often helps you understand topics that will later be important when working with security tools, identities, access policies, and data protection in a Microsoft environment.
Beginners often underestimate the cloud because they don't see it every day like the computer on their desk or the network device in the communication cabinet. However, a large part of modern systems today is located precisely in the cloud, which is why understanding the basic Azure concepts is becoming increasingly important even for people who don't plan to work in cloud administration.
SSCP is a certification that often stands in the shadow of the more well-known CISSP certification. However, for a large number of people, SSCP is precisely the logical step between entry-level certifications and more advanced security certifications.
It's focused on system security, access management, security operations, incident response, network security, and infrastructure protection. In other words, it's closer to the everyday work of system administrators and security operations professionals.
What sets SSCP apart from some other entry-level certifications is its emphasis on the operational side of security. That's exactly why many see it as a good choice for people who work or plan to work at the intersection of system administration and cybersecurity.
Not everyone needs to follow the same certification path. Someone will build their career through Cisco, someone through Microsoft, someone through CompTIA, and someone through ISC2. The most important thing is that the chosen certification supports the direction in which you want to develop your knowledge.
When people first enter the world of cybersecurity, they often look for one perfect certification. Such a certification doesn't exist. There are only different paths of development, depending on the area that interests you.
One of the highest-quality overviews of possible certification paths can be found on Paul Jerimy's Security Certification Roadmap project. That certification path very clearly shows how broad a field cybersecurity is and how many different specializations exist within it.
One of my superiors showed it to me, and since then I've been recommending it to people who are trying to find a direction of development. Although it was created in 2024, most of the certifications shown are still relevant. Some may have changed their name or version, but the logic of career development has remained the same.
You can find the certification path at: https://pauljerimy.com/security-certification-roadmap/
The biggest mistake I see among beginners is searching for the perfect certification. Such a certification doesn't exist. There are only certifications that better or worse suit the area in which you want to develop.
If you ask me, it's much more important to understand why something works than to pass another exam. A certification can open the door to a job interview, but knowledge is what will keep you in that position and help you advance further.
And what is perhaps most important is to use the acquired knowledge for practical purposes. A certification in itself doesn't mean much if what you've learned is never applied to real systems, real problems, and real incidents.
This is of course my personal opinion based on experience. People who do penetration testing or risk management would probably put together a different list. And that's precisely one of the more interesting things in cybersecurity. There are many different paths, and not just one correct one.
One of the most common mistakes among SOC analysts is believing that the analysis is complete the moment they find an alert. In reality, an alert is not the answer. An alert is only the beginning of an investigation.
Security tools are designed to help analysts understand what is happening or what has happened on a system. They collect, correlate, and highlight events that may be security-relevant and direct attention toward activities that require further investigation. However, on their own, they rarely provide a complete picture of an incident. That is why contextual analysis remains one of the most important responsibilities of every SOC analyst.
This is precisely why two identical alerts can represent completely different situations. One may be a legitimate administrative activity, while the other may be the beginning of a serious compromise.
When an alert appears, the first question should not be how to close it. The first question should be why the rule triggered in the first place. Only when we understand the logic behind the rule can we understand what actually happened on the system.
For example, if we see an "Encoded PowerShell" alert, the mere fact that PowerShell was executed is not enough to draw a conclusion. We need to understand what was executed, who executed it, from which context, and for what purpose.
At that point, the analysis is only beginning.
Step 1 – An Alert Is Received
The first step is to review the alert and gather basic information. This includes checking the rule name, event time, user, device, data source, and severity level.
At this stage, no conclusions should be made. The goal is to understand what the system has detected.
Step 2 – Read the Rule Name
The rule name often provides the first clues about what should be analyzed.
If we see a rule called "Abnormal Parent Child Process," we immediately know that we will need to analyze the relationship between the parent process and the child process.
If we see "Encoded PowerShell," the investigation will focus on PowerShell commands and command-line arguments.
If we see "Impossible Travel," we will analyze user logins, geolocation data, and authentication events.
A good analyst first tries to understand what the rule is attempting to detect.
Step 3 – Read the Rule Description
After reading the rule name, the next step is to review the rule description.
The description explains why the alert was generated, what behavior is considered suspicious, and what the rule is actually designed to detect.
Only after understanding the rule logic can a quality investigation begin.
Step 4 – Determine the Starting Point of the Investigation
Every rule has its own starting point.
If the alert is related to a user account, login activity, multi-factor authentication events, IP addresses, and geolocation data should be analyzed.
If the alert is related to a process, the parent process, child process, command-line arguments, and execution path should be reviewed.
If the alert is related to network activity, IP addresses, domains, network connections, and destination reputation should be examined.
The rule determines where the investigation begins.
Step 5 – Gather Context
A single alert almost never provides the complete picture.
Additional alerts, related incidents, indicators of compromise, process activity, user actions, network communications, and historical events should all be collected and reviewed.
Only then can we begin to understand what actually happened.
Step 6 – Analyze Process Context
Many analysts focus solely on the process name.
That is not enough.
For example, powershell.exe by itself means very little. It is necessary to determine who launched it, when it was launched, which parent process initiated it, what commands were executed, whether network communication occurred, and whether the process is digitally signed.
It is especially important to analyze the relationship between the parent process and the child process. While processes routinely spawn other processes during normal operation, there are situations where that relationship may indicate a system compromise.
For example, if explorer.exe launches cmd.exe or powershell.exe, the behavior may be perfectly legitimate. However, if a Microsoft Office document launches powershell.exe, which then launches additional processes or establishes network communication, further investigation is required to determine whether the activity is legitimate or malicious.
Process context is often more important than the process itself. Analysts must understand why the process was executed, under what circumstances, by which user, and whether the behavior is normal for the environment being analyzed.
Step 7 – Analyze the Process Execution Path
It is very important to determine where a process was launched from.
A process executing from C:\Windows\System32 is very different from a process executing from AppData, Temp, or Downloads directories.
However, this is where one of the most common mistakes in security analysis occurs.
Activity originating from the Temp directory does not automatically indicate an attack.
During software upgrades, installations, patch deployments, and system implementation activities, it is common for files to be temporarily extracted and executed from temporary directories.
In other words, legitimate activity can sometimes look very similar to malicious activity.
Likewise, PowerShell is not malicious by itself. Cmd is not malicious by itself. Rundll32 is not malicious by itself. These are legitimate Windows tools used by both administrators and attackers.
This is why context determines whether an activity is legitimate or malicious.
For that reason, the execution path alone should never be the sole factor used to assess an incident. The entire context must be considered before drawing conclusions.
Step 8 – Verify Whether the Activity Is Legitimate
After completing the technical analysis, it is important to answer a simple question:
Did the user expect this activity?
Very often, the user provides the information needed to confirm or dismiss suspicion.
It may turn out that the activity was part of a software upgrade, an administrative task, a new system deployment, an automated process, or a legitimate business operation.
At first glance, such activities may appear identical to a compromise.
Step 9 – Draw a Conclusion
Only after gathering all relevant information can a conclusion be reached.
Is this legitimate activity? Is it a false positive? Is it suspicious activity? Is it a confirmed compromise?
Skipping investigation steps almost always leads to incorrect conclusions.
Step 10 – Apply the Appropriate Response Procedure
Once we understand what happened, we apply the appropriate response procedure.
This may involve procedures for user accounts, endpoints, malware, persistence mechanisms, lateral movement, or incident response.
A procedure is not intended to limit an analyst. Its purpose is not to encourage blind execution of steps.
A good procedure serves as a guide that ensures every analyst follows the same critical investigative steps. It helps ensure that important information, indicators of compromise, related events, and key findings are not overlooked.
Quality analysis is not a checklist of clicks performed in a SIEM or EDR platform. Quality analysis is the process of asking questions and finding answers through available data.
A good analyst constantly looks for additional context. Are there related alerts? Has the user performed unusual actions? Are there indicators of compromise? Has similar activity been observed on other systems? Is there communication with suspicious IP addresses or domains?
The difference between an operator who processes alerts and an analyst who performs investigations lies in the way they think.
An operator sees an alert and looks for a reason to close it.
An analyst sees an alert and looks for the reason it was triggered.
Every detection rule has a specific purpose and logic. If we do not understand what a rule is trying to detect, there is a high probability that we will miss important indicators of compromise or incorrectly assess the severity of an event.
Only after understanding what happened can we apply the appropriate response procedure.
The purpose of a procedure is to ensure that every analyst follows the same critical analysis steps and does not overlook important information during the investigation.
A good procedure does not tell an analyst what to think.
A good procedure ensures that the analyst asks all the right questions.
The most important skill of a SOC analyst is not knowledge of a specific tool, but the ability to understand context and connect information.
Analysis begins by reading the rule.
It continues through understanding the context.
It ends with conclusions based on evidence.
An alert is not proof of compromise.
An alert is an indicator that something requires further investigation.
Good analysis does not look for a reason to close an alert.
Good analysis looks for the reason why the alert was triggered.
Before we get to the concrete steps I'm going to lay out in this article, we need to ask ourselves a few practical questions: why do I want a job in IT at all, and then in cybersecurity specifically? As with any other job, the first question is: am I here for the right reasons? Getting into IT is not a decision made overnight, and unfortunately, the job doesn't come overnight either.
Many people hear glowing stories about this industry and make their decision based on them. The big salary and the comfortable conditions of working from home are usually the first things mentioned. Swept up by those stories, they make hasty decisions without ever asking themselves whether they will actually enjoy the work.
Some of them pay serious money for a course and realize halfway through that it's not for them. Others push through to the end purely because they've already paid, knowing full well they will never work in the field. Education in this area is painful precisely for the kind of people who fell for the polished marketing stories, and some of them can't even install a program, let alone set up a virtual machine.
It's easy to do a job you don't love when it's slow-paced and undemanding, but a job in IT or cybersecurity is anything but. When you get stuck in a job that is extremely demanding and complex, and you don't love it, it creates a whole chain of problems. The consequences hit not only you, but the people around you as well.
The complexity of this work comes from the fact that technology advances incredibly fast and demands an enormous amount of focus. The work environment is usually fast-paced and full of critical systems that require high availability, with countless important processes and businesses depending on them. On top of that, you handle a huge amount of information and data on which, at times, human lives depend, so any mistake can cause serious problems.
You often come across confessions like: "I fell for an ad for a cybersecurity course and thought I could beat the job market, but I couldn't." They are followed by questions like: is it me or the industry, should I give up, and how am I supposed to gain experience if nobody wants to give me a chance? Reading stories like these, I conclude that the people writing them are exactly the ones who didn't get into this field for the right reasons.
If you are here for the right reasons, what follows is the brutal truth about how to land your first job in IT in general, and in cybersecurity in particular. The principle is exactly the same in both cases. The steps are always the same.
Once you finally decide to head in this direction, it doesn't really matter whether you choose self-study, formal education, or a course. Everyone picks the approach that suits them best. The most important thing is to stay true to yourself.
My recommendation, though, is to enroll in university, primarily because of the traditional approach and structure. Courses are fast, often cover only general topics, and last a very short time, so they're great for scratching the surface. University isn't necessarily better, but it offers a structure that courses simply don't have.
University does take more time, but in return you gain the virtue of patience, which is absolutely essential in this line of work. There's also the free dopamine of passing exams and solving assignments, almost like completing quests in a video game. The heavy dose of mathematics is also extremely important because it trains your brain to think analytically, and traditional education ultimately offers a broader, more general foundation.
But here's the key thing: if you don't plan to study on your own in your free time on top of all that, the whole effort is pointless. In that case, you're better off not pursuing this career at all. Self-study is not an option, it's the foundation.
Google is still your best friend, even in the age of artificial intelligence. Ask yourself: am I resourceful, do I enjoy searching and digging for answers? If you don't mind when a simple troubleshooting task turns into hours of exhaustive digging through documentation, forums, and logs, feel free to keep reading.
There are various virtual events where you can get vouchers for certifications, and many of them are completely free. It just takes a bit of research. Which brings us right back to resourcefulness as a core trait.
Think about your habits at home as well: do you fix technical problems yourself, do you run a virtual machine or two? How many times have you installed an operating system on your own, and how many times have you broken your own computer while experimenting? If you recognize yourself in this, there's a good chance you will genuinely love this industry.
There are plenty of platforms offering quality CV templates, so there's no need to reinvent the wheel. Your CV must fit on a single page, have a white background, and look tidy, not like a circus. The format should be PDF, and my recommendation is to leave your photo out of it, something you can research further on your own.
Conciseness, brevity, and simplicity are the rule. Use a formal, neutral font, state your full name, a short description in a few lines, and your completed education. Anything that doesn't serve the goal, cut it out.
In my own CV, I don't list all the jobs I've had before, because they simply aren't relevant to this industry. At interviews, that left the impression of a gap in my career and, predictably, raised questions. But when I was asked about it, I didn't take it negatively; instead, I used the question to deliver a great answer.
People fear questions like that, yet psychologically, they can be turned to your advantage. An example answer: I decided to switch to this industry and didn't list jobs that aren't relevant to it, and besides, it bothered me that my CV spilled onto a second page, which wasn't aesthetically pleasing. And why is there a gap? Because I decided on a career pivot and was brave enough to head in the direction that has genuinely interested me my whole life.
After the CV, the cover letter is extremely important as well. When you're looking for your first job, your letter must be bold and direct. There's no room for lukewarm, generic phrases that an employer reads a hundred times a day.
I usually opened my letters with the sentence: "I don't know anything yet, but I'm interested in this and that, and in my free time I study the following." Everything else you write must, above all, be grounded in honesty. Always stay true to yourself, because doors are always open to individuals who embrace their uniqueness.
Let's be realistic: your first job will most likely mean working for a modest salary, or as we'd say, peanuts. Be patient and accept it, because it's your ticket into the industry. Don't think too much about the number at the beginning; instead, work hard and rack up hours of real practice.
Be prepared to be thrown into the fire from day one. Take on every challenge that comes your way until you become confident in yourself and your knowledge. That is the only way forward.
Cybersecurity is a field where you need to know a lot, so setting priorities wisely is crucial. My advice is to focus on networking fundamentals, because without them you simply can't move forward. By that I mean understanding the OSI and TCP/IP models, the difference between TCP and UDP, and how a packet actually travels from point A to point B.
Learn the essential ports and protocols by heart: 80 and 443 for HTTP and HTTPS, 22 for SSH, 53 for DNS, 25 for SMTP, 3389 for RDP, 445 for SMB. Along with that come HTTP status codes, because the difference between 200, 301, 403, 404, and 500 tells you a lot about what's happening on the web. Add to that a basic understanding of network devices: what a switch does, what a router does, and what a firewall does.
The next priority is operating systems and basic knowledge of processes, primarily Windows processes, since most business environments run on the Windows platform. Because people themselves are the biggest security risk, and they predominantly use Windows, it's important to know the processes that can easily be abused to compromise a system. You need to be able to recognize legitimate system processes like svchost.exe, lsass.exe, or explorer.exe, and understand why it's suspicious when such a process runs from the wrong path or with an unusual parent process.
That brings us to the process chain: who spawned whom, in what order, and with what arguments. When you see Word spawning PowerShell, and PowerShell downloading something from the internet, that's a story you must be able to tell at an interview. Learn where and how to find that information, for example in Windows event logs, because that is every analyst's daily bread.
Furthermore, you need to understand what hashes are and why they're useful to us. Algorithms like MD5, SHA-1, and SHA-256 are used for verifying file integrity, identifying malicious code, and storing passwords. When you can explain at an interview why the same malicious sample can always be recognized by its hash, and why MD5 is no longer a safe choice, you're already ahead of most candidates.
Then there's OSINT, the gathering of information from publicly available sources. It covers everything from advanced searches and public registries to tools for checking the reputation of domains, IP addresses, and files. The resourcefulness I wrote about earlier comes into full play here.
And finally, Linux: let this operating system be your daily prayer, because most security devices and systems run precisely on Linux or on Linux-based systems. Learn to navigate the terminal, read logs from the /var/log directory, handle commands like grep, cat, ps, and netstat, and understand file permissions. Operating systems are, I repeat, the foundation of everything, and above all of it stands one rule: be consistent.
If you'd like to know which CV template I recommend or which education I think is worth it, feel free to send me a message. I'll gladly share concrete recommendations from my own experience, and take a look at the links where I also offer my own courses. Good luck, and see you in the industry!
When people think of a home firewall, many still imagine a device that simply allows or blocks traffic between a local network and the internet. However, modern solutions have evolved far beyond that role.
Today's firewalls can analyze application traffic, perform SSL/TLS inspection, leverage threat intelligence sources, identify known attack patterns, and make security decisions based on far more than just IP addresses and ports.
As a result, technologies that were once reserved for enterprise environments are now available to anyone looking for greater visibility and control over their network, whether for learning, testing new technologies, or building a home lab.
For this comparison, I focused on three solutions that are frequently mentioned among network administrators and enthusiasts: Sophos Firewall Home Edition, OPNsense, and pfSense.
While all three products can easily handle core functions such as routing, NAT, VPN connectivity, and network segmentation, the differences become apparent when evaluating security capabilities, integrations, administration, and overall design philosophy.
Sophos Firewall Home Edition is built on the same platform used in enterprise environments. As a result, users gain access to a wide range of capabilities typically found in significantly more expensive commercial solutions.
In addition to standard traffic filtering rules, it includes IPS, web filtering, application control, SSL/TLS inspection, geo-IP filtering, protection against various network attacks, and advanced threat detection capabilities.
One particularly interesting feature is Extended Threat Feeds. Through API integrations, administrators can automatically import IOCs such as malicious IP addresses, domains, and URLs from external sources. This allows the firewall to consume data from threat intelligence platforms, custom IOC feeds, or other security systems and automatically make decisions about blocking or flagging traffic.
For users interested in automation, integrations, and modern defensive strategies, this is a highly valuable capability that is rarely seen in free home editions.
What stands out most to me is how much functionality is integrated directly into the platform. There is no need to install multiple add-ons or combine several separate components to achieve advanced security functionality.
Deployment is relatively straightforward, the administrative interface is easy to navigate, and a large number of features are available immediately after installation. Because of this, Sophos feels like a very complete solution that successfully combines ease of use with advanced security capabilities.
OPNsense represents a different philosophy.
As an open-source project, it offers users a very high level of flexibility and control. Rather than following a predefined approach, administrators decide which components they want to use and how they want to implement them.
One of OPNsense's greatest strengths is its extensive ecosystem of plugins. Tools such as Suricata, WireGuard, Zenarmor, HAProxy, and many others can be integrated into an existing environment with relative ease.
This approach enables the creation of highly customized and powerful environments tailored to specific requirements. At the same time, it requires additional time for configuration, maintenance, and understanding the various components involved.
For administrators who prefer complete control over every aspect of their infrastructure, this is often OPNsense's biggest advantage.
pfSense has long been one of the most recognizable names in the home and small business firewall space.
Its greatest strengths are platform maturity, a large user community, and extensive documentation. Almost any issue you encounter has likely been documented or solved by someone before.
From a functionality standpoint, pfSense remains a highly capable solution that can satisfy the needs of most users. It is stable, proven, and well known throughout the networking community.
That said, in recent years part of the community has gradually shifted toward OPNsense, primarily due to its more open development model and faster adoption of certain features.
When comparing security products, one question inevitably comes up: which one is the most secure?
In reality, the answer is not that simple.
Sophos has experienced several serious vulnerabilities that allowed remote code execution and other forms of system compromise. Due to its significant presence in enterprise environments, such issues often receive considerable attention from the security community.
On the other hand, both OPNsense and pfSense regularly release security updates addressing newly discovered vulnerabilities. The mere existence of CVEs says very little about the quality of a product. What matters far more is how quickly vendors respond, how transparently they communicate issues, and how easily users can apply available patches.
Another concept worth discussing is technological diversity.
When designing security architecture, the goal is not always to find a single solution capable of doing everything. Depending on requirements and available resources, there can be value in using multiple security technologies.
The reason is not only functionality but also risk reduction. If an entire infrastructure relies on a single vendor, a critical vulnerability may have a much greater impact than in an environment built on multiple technologies.
Different vendors use different development teams, security controls, and defensive approaches. A vulnerability affecting one product will not necessarily exist in another.
From an attacker's perspective, homogeneous environments are often more predictable. More diverse environments typically require additional research, adaptation, and resources to compromise successfully.
Of course, introducing additional technologies also increases operational complexity, so finding the right balance between security and manageability remains important.
All three products have their place and their audience.
OPNsense will likely appeal most to users seeking maximum flexibility and openness. pfSense remains a stable and proven platform backed by a large community and extensive documentation.
In this comparison, Sophos Firewall Home Edition stood out the most to me. The amount of functionality available immediately after deployment, ease of implementation, integrated security capabilities, and the ability to leverage threat intelligence data without additional tools left a very positive impression.
Of course, this is far from the final list of technologies I plan to explore.
One of the reasons I maintain a home lab is the opportunity to test different technologies, compare approaches from different vendors, and gain hands-on experience outside production environments.
That brings me to a question for the wider community.
What solution should I implement next in my home lab? Are there any firewalls, IDS/IPS platforms, networking tools, or security products that you believe deserve more attention than they currently receive?
Feel free to leave your suggestions in the comments. One of them might become the subject of a future technical review.
In cybersecurity, the focus is almost always on technology. Organizations invest significant resources into defensive systems, advanced firewalls, EDR platforms, threat detection systems, network segmentation, and multi factor authentication. Security assessments are performed, patches are regularly applied, and strict security policies are defined.
Despite all of this, sometimes a single click is enough.
One link. One fake login page. One attachment opened at the wrong moment.
In that moment, months of security work and significant financial investments in protection systems can be undone.
This does not mean that security technologies are ineffective. On the contrary. Their proper implementation is the foundation of any serious security strategy. The issue is that most security solutions protect infrastructure, while attackers very often target the people who operate and use that infrastructure.
Attackers use different methods to reach their objective. Sometimes they exploit technical vulnerabilities, sometimes misconfigurations, and sometimes they attempt to deceive the user.
Social engineering is a separate approach that relies on manipulating human decisions rather than exploiting technical weaknesses in systems.
In an environment where technical defenses are becoming stronger, attention is increasingly shifting toward the human element.
Why invest time in breaking into systems when it is possible to trick a user into approving access or voluntarily providing credentials.
For this reason, the human factor becomes a key entry point for attackers.
It is often assumed that users are careless or insufficiently trained. This explanation oversimplifies the real problem.
Most employees do not come to work with the intention of harming the organization. Their primary focus is performing their assigned tasks.
Accountants process invoices. Sales representatives communicate with clients. Project managers manage projects. None of them are hired to analyze technical email headers or verify sender domains.
Security teams often forget that security is their primary responsibility, but not the responsibility of most employees.
When a person receives a message that appears to come from a manager, supplier, or colleague, the decision is made within seconds. A large portion of successful attacks relies on this speed of decision making.
After an incident, the same sentence often remains.
But I thought I was talking to the CEO.
Many organizations can present records of completed security training. Employees attended presentations, confirmed participation, and completed mandatory tests.
The real question remains the same. Are they actually more capable of recognizing an attack afterwards.
The quality of training is not measured by the number of sessions delivered, but by changes in behavior in real situations.
A particular issue arises with phishing simulations. Instead of serving as a realistic assessment, they often become a tool to demonstrate that no real problem exists.
If the results are poor, explanations are sought. If click rates are high, the simulation is declared unrealistic. In some cases, campaigns are stopped early to make the results appear more acceptable.
Such an approach does not improve security. It only creates an illusion of control.
An organization that does not accept its real state does not solve the problem. It only delays the moment when an actual attacker will expose it.
One of the most common misconceptions in the industry is the belief that it is possible to build a system that cannot be compromised.
Such a system does not exist.
Every technology has limitations. Every process has exceptions. Every human can make mistakes.
Organizational maturity is not measured by whether incidents can be fully prevented, but by how quickly they are detected and how effectively they are handled.
This is precisely why security tools provide real value.
EDR is not implemented to make systems unbreachable. SIEM is not introduced to eliminate all threats. Multi factor authentication is not a guarantee of complete protection.
There is no universal solution in cybersecurity.
These systems exist to provide better visibility, higher quality data, and stronger response capabilities when incidents occur.
Security is not a state. Security is a process.
The most advanced security system will not independently analyze the context of an incident. It will not understand business impact. It will not make decisions.
Technology generates data. People turn that data into decisions.
For this reason, the human factor is both the greatest risk and the most important element of defense.
The same user who can become an entry point for compromise can also be the one who first notices suspicious activity and responds in time.
Cybersecurity is not a fight against users. It is a process in which human behavior is shaped to become part of the defensive mechanism rather than its weakness.
Technology is necessary. Processes are necessary. But at the end of every infrastructure stands a human being.
For this reason, the human factor remains one of the key challenges of modern cybersecurity.
I recently came across a program that gives you a 100% discount voucher for Microsoft certification exams, and I think more people should know about it.
👉 https://skillupwithlevelup.com/courses
Personally, I completed three courses and received two vouchers — so my best guess is that the limit is two vouchers per person. Choose your courses wisely.
This is a legitimate opportunity to get certified without spending money, as long as you're prepared and move quickly.
Have you tried this already? Drop a comment — would love to hear which certifications people are going for.
📌 Always check the prerequisites. All expert-level certifications require at least one associate-level certification before you can earn them. For example, to achieve the SC-100 (Cybersecurity Architect Expert), you must first hold SC-200, SC-300, or AZ-500. Make sure you double-check the requirements for your target certification before you enroll in the course.
Wazuh is an open-source SIEM and XDR platform that provides centralized collection, analysis, and correlation of security events from endpoints, network devices, and cloud services. Thanks to its modular architecture and combined agent-based and agentless approach, it is ideal for home labs, education, and smaller production environments.
Setting up a home SIEM is an excellent way to understand real security processes: log collection, event correlation, anomaly detection, and incident response. This guide walks through the entire process — from preparing the virtual machine to ingesting logs from endpoints and firewalls.
For the Wazuh server, a Linux distribution such as Ubuntu Server or Debian is recommended. A minimal configuration for a home lab includes:
According to Wazuh documentation, resource consumption scales linearly with the number of agents. Each agent generates its own volume of events including authentication logs, system changes, FIM entries, processes, and network activity. This means CPU, RAM, and disk requirements increase depending on the number of endpoints.
A small home lab with a few agents can run on 2–4 GB RAM, while environments with ten or more agents require additional resources to keep indexing and event processing stable.
After creating the VM in VirtualBox, VMware, or Proxmox, install the operating system and assign a static IP address so the Wazuh server is easily reachable by other devices.
Wazuh provides a simple installation script that automatically deploys Elasticsearch, Kibana, and the Wazuh server. This is the fastest and most stable method for home use.
On a fresh OS installation, run:
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash wazuh-install.sh -a
The installation takes a few minutes.
Once complete, the Wazuh dashboard is available in your browser, typically at:
https://IP-address:5601
Log in using the initial credentials generated by the installation script.
Wazuh agents collect logs from Windows, Linux, and macOS systems. On Windows, the agent is installed via an MSI installer, while Linux systems use the package manager.
In the Wazuh dashboard, open: Agents → Deploy new agent
Choose the operating system and follow the instructions.
Key parameters include:
Once installed, the agent registers automatically and begins sending logs including system events, authentications, file changes, processes, and network activity.
Wazuh can receive Syslog events from any firewall capable of sending logs to a remote Syslog server. Since Wazuh includes a built-in Syslog listener, the firewall can send logs directly to Wazuh without requiring an intermediate server.
When the firewall sends events, Wazuh stores them in:
/var/ossec/logs/archives/archives.log
The logs are stored in raw form under agent ID 000 because this is an agentless source.
If logs do not appear, enable log archiving in:
ossec.conf
<global>
<alerts_log>yes</alerts_log>
<logall>yes</logall>
<logall_json>yes</logall_json>
</global>Then restart the manager:
sudo systemctl restart wazuh-manager
If logs appear in archives.log but not in the dashboard, Wazuh needs a decoder to interpret the firewall event structure.
Add a decoder to:
/var/ossec/etc/decoders/local_decoder.xmlExample generic decoder:
<decoder name="Firewall_Generic">
<type>syslog</type>
<prematch>device_name="</prematch>
</decoder>
<decoder name="Firewall_Generic_child">
<parent>Firewall_Generic</parent>
<regex>device_name="(\S+)" timestamp="([^"]+)" log_type="([^"]+)" src_ip="([^"]+)" dst_ip="([^"]+)" protocol="([^"]+)" src_port=(\d+) dst_port=(\d+)"</regex>
<order>device_name,timestamp,log_type,src_ip,dst_ip,protocol,src_port,dst_port</order>
</decoder>Rules are added to:
/var/ossec/etc/rules/local_rules.xmlExample:
<group name="custom_firewall">
<rule id="100040" level="3">
<decoded_as>Firewall_Generic</decoded_as>
<description>Firewall Log Event</description>
</rule>
</group>Wazuh includes a built-in tool for testing decoders and rules. It is important to verify that all fields appear correctly and that the alert triggers successfully.
Run:
/var/ossec/bin/wazuh-logtestPaste a firewall log, for example:
device_name="FW" timestamp="2024-01-01T12:00:00+0100" log_type="Firewall" src_ip="1.2.3.4" dst_ip="5.6.7.8" protocol="TCP" src_port=1234 dst_port=443If everything is configured correctly:
Restart the manager afterward:
sudo systemctl restart wazuh-managerFirewall logs should now appear in the Wazuh dashboard.
A home SIEM is not just an educational project — it provides real visibility into security events occurring within your network. Wazuh is powerful enough for professional environments while remaining accessible for home labs and learning purposes.
Throughout this series, we will explore additional Wazuh configuration topics and other security products to build a sustainable and understandable security ecosystem.
Security cannot be bought in a box. Yet many organizations behave as if it can. Security software is often sold as an instant solution, but without expert handling it becomes little more than expensive shelfware.
In today’s cybersecurity landscape, tool sprawl is increasingly common — an obsessive race to buy more and more security solutions under the assumption that quantity equals protection.
Vendors present flashy dashboards and catchy acronyms, resellers promise perfect layered defenses, and executives with limited technical oversight approve purchases without understanding operational impact.
The reality is much simpler: without proper integration, skilled experts, management, and strategy, more tools frequently create less security.
Every security tool introduces additional agents, rules, logs, and alerts. Multiply that by dozens of systems and organizations often create chaos instead of visibility.
Many tools overlap in functionality, conflict with each other, or operate in complete isolation without sharing context.
In some environments, tools actively interfere with one another. Firewalls block legitimate traffic flagged elsewhere, DLP systems collide with backup solutions, and SIEM platforms fail to correlate events due to incompatible formats.
The result is reduced visibility, missed alerts, slower incident response, frustrated teams, and sometimes a dangerous false sense of security.
Security vendors frequently rely on fear, uncertainty, and doubt to drive purchases. Breach statistics and expensive “silver bullet” products are used to convince organizations that another purchase automatically means stronger protection.
This sales model works because many organizations lack strong technical leadership and trusted security advisors capable of evaluating whether tools are actually necessary or sustainable.
It is not uncommon for companies to spend hundreds of thousands of euros on products that remain unused or only partially implemented.
Cybersecurity functions as a chain where every component must communicate and support the others. If one component is misconfigured or disconnected, the entire chain weakens.
More tools mean more integrations, more maintenance, more patching, and more opportunities for misconfiguration.
Instead of coordinated defense, many organizations create fragmented and noisy environments where attackers exploit gaps between disconnected systems.
Another frequently ignored element is the end user. Security exists to protect people, yet many strategies overlook usability completely.
If tools are invasive, confusing, or poorly explained, users eventually bypass them, disable them, or unintentionally create additional risk.
Security tools are expensive for legitimate reasons including development, maintenance, and support costs. Vendors deserve profit, but profit should not outweigh responsibility.
Security should focus on education, realistic risk assessment, and alignment between technology, processes, and people.
Trusted advisors — whether internal security architects or external consultants — play a critical role in evaluating actual organizational needs and preventing unnecessary complexity.
Before purchasing another “silver bullet,” organizations should first improve the fundamentals:
Most breaches happen because of exposed systems, stolen credentials, or misconfigurations — not because the newest tool was missing.
Security starts with hygiene, not hype.
Security is not about accumulating tools. It is about making technology work together through strategy, expertise, and operational discipline.
Cyber defense is not a shopping list. More tools do not automatically mean stronger protection. Sometimes they simply create more confusion, cost, and vulnerability.
Organizations should shift their mindset from endless spending toward integration, hardening, and sustainability. That is where effective security actually begins.