IT security
IT security only works if it is integrated into operations—not as an additional project, but as part of the architecture, ownership, and change process. In many organizations today, the bottleneck is less a lack of tools than a lack of consistency: identities are distributed, firewall rules grow historically, logs are there – but cannot be evaluated, and hardening is not reproducible. At the same time, the demand for verifiability is increasing: depending on the industry and supply chain, topics such as NIS2-oriented programs, BSI-related procedures, or ISO/IEC 2700x references are becoming more prevalent in practice, without automatically providing clarity. Good security work therefore primarily brings decision-making ability: What is “good enough” for the specific operation – and how does it remain stable even with patch pressure, team changes, and platform changes?

System hardening

System hardening is becoming fundamental again, particularly due to supply chain realities (images, package sources, CI): Baselines must be versionable and verifiable. If hardening is considered a standard rather than a one-time action, “drift” in operations is significantly reduced.
Authentication

Identities are the new perimeter – not as a buzzword, but because workloads, admin access, and services are constantly crossing boundaries. Clean authentication and access control reduces local exceptions and makes access auditable.
Firewall

Firewalls today are less of a “perimeter wall” and more of a policy engine: segmentation and east-west rules determine the radius of damage. Good rule sets are maintainable, testable, and closely intertwined with ownership and changes.
Monitoring

Without good telemetry, security remains a gut decision—especially with distributed systems and short release cycles. Clean logs and metrics make deviations visible and shorten the time to a reliable diagnosis.
Business relevance
Security is a business variable, even if it is implemented technically. Insecure or untraceable access creates friction: more approval loops, more exceptions, longer incident times – and ultimately higher operating costs. This is particularly noticeable in hybrid landscapes where SaaS, cloud, and on-premise interact and provider lifecycles (end of support, API changes, new default policies) regularly force adjustments. Those who establish a consistent identity model and clear security zones gain speed: changes become easier because risk and impact are more predictable.
At the same time, expectations are shifting: ransomware patterns and credential theft are commonplace, and both internally and externally, people are increasingly asking whether protective measures are not only “in place” but also effective and verifiable. This is precisely where an approach that considers system hardening, access, and observability as a coherent operating model pays off.

Trainings
Specific trainings and current topics can be found in the Comelio GmbH course catalog.
Whether in-house at your company, as a webinar, or as an open event – the formats are flexibly tailored to different requirements.
Typical misunderstandings
“We have MFA – that takes care of the issue.”
MFA is important, but it is rarely the end of the story. In practice, service accounts, SSH keys, delegations, and local exceptions remain vulnerable to attack. Modern attacks often target session tokens, misconfigurations, or privilege escalation – which is why authentication must work in tandem with clean authorization and lifecycle management (especially with new IAM patterns and short token lifetimes).
“Firewall rules are security.”
Rules without segmentation logic and ownership are primarily complexity. If zones, data flows, and responsibilities are not clear, a set of rules grows faster than its maintainability – and becomes a time trap in audits or incidents. In distributed environments, east-west policies and identity-based access are often more critical than “yet another rule on the edge.”
“Audits solve security.”
Audits are a measuring point, not a security concept. Those who do not integrate compliance checks into their operations collect snapshots – but no reliable evidence. It makes sense to regularly check baselines (e.g., CIS-oriented), prioritize findings, and treat them as a repeatable process (this is where system hardening, monitoring, and logging come together).
“Open source is inherently secure or insecure.”
Open source is neither a guarantee of security nor a risk by definition. The decisive factors are maintainability, updateability, transparency in operation, and the ability to version configurations in a traceable manner. Especially in light of current supply chain discussions, the type of license is less important than discipline in build, patch, and review processes.
Frequently asked questions about IT security
In this FAQ, you will find the topics that come up most frequently in consulting and training. Each answer is kept short and refers to further content if necessary. Can’t find your question? We are happy to help you personally.

What role does open source play in IT security?
Open source can increase transparency and auditability – but the decisive factor is operation: update capability, reproducible configuration, and clean reviews. Good results are achieved when tools are embedded in standards, logging, and ownership.
LDAP/Kerberos/SSSD: When is it really worthwhile?
As soon as multiple systems, teams, or locations are involved, central identity becomes a stability factor. SSSD helps to make logins and policies consistent and reduces local exceptions—especially in combination with clear roles and short, traceable access mechanisms.
Do I need “zero trust” if I already have a firewall?
“Zero trust” is less a product than a principle: identity, segmentation, and minimal rights. A firewall remains important, but without east-west policies, clear zones, and traceable access, the damage radius often remains too large.
What are the typical first steps when “everything has grown historically”?
It usually starts with two things: consolidating identities and establishing logging/transparency. After that, hardening and network policies can be standardized in a targeted manner because their effects and dependencies are visible.
