Zum Inhalt springen
_CORE
KI & Agentensysteme Unternehmensinformationssysteme Cloud & Platform Engineering Datenplattform & Integration Sicherheit & Compliance QA, Testing & Observability IoT, Automatisierung & Robotik Mobile & Digitale Produkte Banken & Finanzen Versicherungen Öffentliche Verwaltung Verteidigung & Sicherheit Gesundheitswesen Energie & Versorgung Telko & Medien Industrie & Fertigung Logistik & E-Commerce Retail & Treueprogramme
Referenzen Technologien Blog Know-how Tools
Über uns Zusammenarbeit Karriere
CS EN DE
Lassen Sie uns sprechen

Security & Compliance

Sicherheit ist kein Feature — es ist eine Eigenschaft.

Penetrationstests, Sicherheitsaudits, KI-Sicherheits-Guardrails. Wir schützen Ihre Systeme und Daten.

Threat Modeling

STRIDE/DREAD-Analyse, Attack Surface Mapping, Risikobewertung. Wissen, was Sie schützen und vor wem.

Threat Modeling ist keine einmalige Aktivität — es ist ein lebendiges Artefakt. Jedes System hat eine Angriffsfläche und jede Änderung formt sie um. Wir führen STRIDE-Analysen während des Architekturdesigns durch, nicht nach dem Produktions-Deployment.

Wie wir arbeiten: Wir beginnen mit einem Datenflussdiagramm — wo Daten entstehen, wie sie fließen, wo sie gespeichert werden. An jeder Trust Boundary identifizieren wir Bedrohungen mittels STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Jede Bedrohung wird über DREAD bewertet und Mitigationen werden priorisiert.

Attack Surface Mapping umfasst externe APIs, interne Services, Datenbanken, Message Broker, CI/CD-Pipelines, Drittanbieter-Integrationen. Wir kartieren auch die Supply Chain — Abhängigkeiten, Container-Images, Build-Pipeline. Ein Angreifer sucht das schwächste Glied, nicht das offensichtlichste.

Ergebnis: Ein strukturiertes Threat Model mit priorisierten Risiken, vorgeschlagenen Mitigationen und Akzeptanzkriterien. Integriert in den Backlog — Security Stories neben Feature Stories. Aktualisiert bei jeder Architekturänderung.

Tooling: Microsoft Threat Modeling Tool, OWASP Threat Dragon, Custom-STRIDE-Workshops. Für größere Systeme — automatisiertes Threat Modeling aus IaC (Terraform, Kubernetes-Manifeste).

threat-modelstriderisk
Details →

AI Security & Governance

Prompt-Injection-Prävention, Schutz vor Datenlecks, Agent Guardrails. KI unter Kontrolle.

KI-Agenten sind ein neuer Angriffsvektor. Klassische Security adressiert Authentifizierung, Autorisierung, Verschlüsselung. KI-Security fügt hinzu: Prompt Injection, Datenexfiltration über das Modell, unkontrollierte Aktionen, durch Halluzinationen verursachte Fehler. Es ist eine andere Disziplin.

Prompt Injection ist SQL Injection für die LLM-Ära. Ein Angreifer manipuliert die Eingabe, sodass der Agent sein Verhalten ändert — den System Prompt ignoriert, interne Daten preisgibt, eine unautorisierte Aktion ausführt. Wir verteidigen mehrschichtig: Input Sanitization, Output Filtering, Trennung von privilegiertem/unprivilegiertem Kontext, Canary Tokens.

Datenlecks sind ein stiller Killer. Ein auf internen Daten trainiertes Modell kann in einer Antwort sensible Informationen preisgeben. Ein Agent mit Datenbankzugriff kann Daten zurückgeben, für die der Nutzer keine Berechtigung hat. Wir lösen das mit PII-Erkennung auf dem Output, RBAC für Agentenaktionen und einem Audit Trail jeder Interaktion.

AI Governance Framework: Wir definieren, was der Agent darf und was nicht. Welche Daten er lesen kann. Welche Aktionen er ausführen kann. Wer Eskalationen genehmigt. Ein Kill-Switch für sofortige Abschaltung. Regelmäßige Red-Team-Übungen speziell für KI-Systeme.

Compliance: EU AI Act-Kategorisierung, Dokumentation von Entscheidungsprozessen, Bias-Monitoring, Erklärbarkeit. Wir bereiten Organisationen auf regulatorische Anforderungen vor, die 2025–2026 kommen.

ai-securitygovernanceguardrails
Details →

Penetration Testing

Black-Box- und White-Box-Testing, Schwachstellenbewertung, Code Review.

Ein Penetrationstest ist kein Häkchen — er ist eine Simulation eines realen Angriffs. Unsere Tester denken wie Angreifer. Sie suchen nicht nur nach bekannten CVEs, sondern nach Business-Logic-Schwachstellen, Race Conditions und Privilege-Escalation-Ketten, die automatisierte Scanner nicht finden.

Black-Box-Testing: Der Tester hat keine Informationen über das System — genau wie ein echter Angreifer. Reconnaissance, Enumeration, Exploitation. Zeigt, was ein Angreifer von außen sieht — exponierte Services, Standard-Credentials, Informationslecks in Fehlermeldungen, IDOR-Schwachstellen.

White-Box-Testing: Der Tester hat Zugriff auf Quellcode, Architektur und Konfiguration. Tiefere Analyse — sicherheitsorientiertes Code Review (Injection Flaws, Broken Auth, Insecure Deserialization), IaC-Template-Review, Secrets-Management-Analyse.

Scope und Methodik: Jeder Test hat einen klar definierten Scope, Rules of Engagement und Kommunikationsprotokoll. Wir nutzen den OWASP Testing Guide, PTES und eigene Methoden für APIs und Microservices. Der Bericht enthält einen reproduzierbaren PoC für jeden Fund.

Kontinuierliches Security Testing: Ein einmaliger Pentest reicht nicht aus. Wir integrieren DAST (Dynamic Application Security Testing) in CI/CD-Pipelines. Jedes Deploy durchläuft einen automatisierten Security-Scan. Manueller Pentest 1–2× pro Jahr für tiefgehende Analyse.

pentestvulnerabilityaudit
Details →

Zero Trust Architecture

Identität als Perimeter. mTLS, Mikrosegmentierung, Least Privilege.

Der Perimeter ist tot. Das klassische Modell „innerhalb des Netzwerks = vertrauenswürdig” funktioniert nicht in der Ära von Cloud, Remote-Arbeit und Supply-Chain-Angriffen. Zero Trust sagt: Niemals vertrauen, immer verifizieren. Jeder Request, jeder Nutzer, jedes Gerät.

Identität als neuer Perimeter: Authentifizierung und Autorisierung auf jeder Ebene. Service-to-Service-Kommunikation über mTLS (Mutual TLS) — beide Seiten weisen ihre Identität nach. SPIFFE/SPIRE für Workload Identity. Kein implizites Vertrauen zwischen Services.

Mikrosegmentierung: Netzwerkrichtlinien auf Pod-Ebene (Kubernetes NetworkPolicy, Cilium). Ein Service kommuniziert nur mit denen, mit denen er muss. Laterale Bewegung nach Kompromittierung eines einzelnen Service wird blockiert. East-West-Traffic unter Kontrolle.

Least Privilege: RBAC mit granularen Berechtigungen. Just-in-Time-Zugriff für Administratoren — Berechtigungen für 4 Stunden, nicht dauerhaft. Regelmäßige Access Reviews. Privileged Access Management (PAM) für kritische Systeme. Service Accounts mit minimalen Berechtigungen.

Implementierung: Wir behandeln Zero Trust nicht als Big-Bang-Projekt. Wir beginnen mit einer Inventur — wer kommuniziert mit wem, welche Daten fließen. Dann führen wir schrittweise Kontrollen ein: zuerst Monitoring (wir sehen, was passiert), dann Enforcement (wir blockieren, was nicht sein soll). Typischerweise 3–6 Monate bis zum Produktionszustand.

zero-trustmtlsrbac
Details →

Incident Response

SIEM, Runbooks, On-Call-Prozesse. Wenn etwas passiert, wissen Sie, was zu tun ist.

Incident Response wird nicht improvisiert. Wenn PagerDuty am Sonntagabend anruft, brauchen Sie ein Runbook, keine Brainstorming-Session. Wir bauen Incident-Response-Prozesse, die unter Stress funktionieren — klare Rollen, klare Schritte, klare Eskalationswege.

SIEM und Erkennung: Zentrale Erfassung von Security-Events aus Infrastruktur, Anwendungen und Identity Providern. Korrelationsregeln zur Erkennung bekannter Angriffsmuster. Anomalieerkennung für unbekannte Bedrohungen. MTTD (Mean Time to Detect) unter 1 Stunde für kritische Incidents.

Runbooks für Top-Incidents: Kompromittierte Credentials, Ransomware, Datenleck, DDoS, Insider Threat, Supply-Chain-Kompromittierung. Jedes Runbook: Erkennung → Eindämmung → Beseitigung → Wiederherstellung → Post-Mortem. Wir testen mit Table-Top-Übungen quartalsweise.

On-Call-Prozesse: Rotation, Eskalationsmatrix, Response-SLA. PagerDuty/OpsGenie-Integration. Klare Severity-Levels (SEV1–SEV4) mit definierten Reaktionszeiten. War-Room-Protokoll für SEV1-Incidents. Kommunikationsvorlagen für Stakeholder.

Post-Mortem-Kultur: Blameless Post-Mortem innerhalb von 48 Stunden nach jedem SEV1/SEV2. Root-Cause-Analyse, beitragende Faktoren, Action Items mit Verantwortlichen und Fristen. Learnings werden teamübergreifend geteilt. Ziel: Derselbe Fehler passiert nie zweimal.

siemincidentresponse
Details →

Compliance & Audit

DSGVO, NIS2, ISO 27001, DORA. Regulierung als Checkliste, nicht als Albtraum.

Compliance dreht sich nicht um Papierkram — sondern um Prozesse. Ein ISO-27001-Zertifikat an der Wand bedeutet nichts, wenn dahinter kein funktionierendes ISMS steht. Wir helfen Organisationen, Sicherheitsprozesse aufzubauen, die ein Audit bestehen und tatsächlich schützen.

NIS2-Readiness: Die neue EU-Richtlinie erweitert den Kreis der regulierten Unternehmen und verschärft die Anforderungen. Gap-Analyse gegen NIS2-Anforderungen, Implementierungs-Roadmap, Supply-Chain-Security-Assessment. Wenn Sie in einem regulierten Sektor sind (Energie, Transport, Finanzen, Gesundheitswesen, digitale Infrastruktur), betrifft NIS2 Sie.

DORA (Digital Operational Resilience Act): Für den Finanzsektor. ICT-Risikomanagement, Incident Reporting, Tests der digitalen operativen Resilienz, Drittanbieter-Risikomanagement. Wir helfen bei Gap-Analyse, Implementierung von Kontrollen und Auditvorbereitung.

ISO 27001: ISMS-Implementierung von Grund auf oder Vorbereitung auf die Rezertifizierung. Risikobewertung, Statement of Applicability, Richtlinien und Verfahren, interne Audits. Pragmatischer Ansatz — Dokumentation, die einem Zweck dient, nicht nur existiert.

DSGVO operativ: Datenmapping, DSFA (Datenschutz-Folgenabschätzung), Breach-Notification-Prozesse, Betroffenenrechte (Auskunft, Löschung, Datenportabilität). Technische Maßnahmen: Pseudonymisierung, Verschlüsselung, Zugriffskontrolle, Audit-Logging. Privacy by Design integriert in den Entwicklungsprozess.

gdprnis2iso27001
Details →
Security by Design

Security by Design

Sicherheit von Anfang an in die Architektur integriert — nicht als Sprint am Ende. Das Threat Model entsteht zusammen mit dem Systementwurf; Security Review ist Teil des Code Reviews.

Beispiel aus der Praxis: Firma A kümmert sich erst vor dem Go-Live um Security — 40 kritische Findings, Launch um 3 Monate verschoben. Firma B hat Security von Anfang an — Audit in einer Woche abgeschlossen, 2 geringfügige Findings, Launch pünktlich.
  • Threat Model für jedes neue System
  • Security Review als Teil des Code-Review-Prozesses
  • Automatisierte Security-Scans in CI/CD
  • Incident-Response-Runbooks
<1h
MTTD (Erkennung)
<1h
MTTR (response)
100%
Pentest-Abdeckung
0
Critical findings post-audit

Jak to děláme

1

Threat Assessment

Wir identifizieren Assets, Bedrohungen und Schwachstellen — sowohl technische als auch prozessbezogene.

2

Penetrationstests & Audit

Wir simulieren reale Angriffe, testen die Verteidigung und verifizieren die Compliance.

3

Remediation & Härtung

Wir beheben identifizierte Schwachstellen und stärken die Sicherheit von Infrastruktur und Anwendungen.

4

Monitoring & Erkennung

Wir deployen SIEM, EDR und Threat Detection für die kontinuierliche Überwachung der Umgebung.

5

Continuous Security

Regelmäßige Re-Tests, Security-Awareness-Training und Anpassung an neue Bedrohungen.

When you need security

Typical situations

  1. No threat model — You don’t know what you’re protecting or from whom. Security is intuition, not a system.
  2. AI in production without governance — LLM agents running without rules. Prompt injection, data leakage.
  3. Legacy without an audit trail — Who did what and when? We don’t know. Changes are not tracked.
  4. Compliance pressure — The regulator is knocking, the audit is in a month.

AI Security

AI agents introduce a new class of risks:

  • Prompt injection — Input manipulation that changes agent behavior.
  • Data leakage — Sensitive data in responses. The agent reveals internal information.
  • Unintended write actions — The agent deletes data, sends emails without oversight.
  • Model drift — Response quality degrades over time without measurement.

Our AI Security Framework

  1. RBAC for agents — Defined permissions for what the agent may and may not do.
  2. Input sanitization — Detection and blocking of prompt injection.
  3. Output filtering — PII detection, business logic guardrails.
  4. Audit trail — Every agent action is logged and traceable.
  5. Kill-switch — Immediate agent shutdown upon anomaly detection.

How we proceed

  1. Discovery & Threat Modeling — Infrastructure, assets, threats. Risk assessment and gap analysis.
  2. Security Audit — Penetration tests, vulnerability assessment, code review.
  3. Hardening — Zero Trust, SIEM, WAF, network segmentation, access management.
  4. Production Readiness — Security monitoring, alerting, incident response processes.
  5. Continuous improvement — Red team exercises, security culture, awareness.

Häufig gestellte Fragen

Mit einem Security Assessment — wir erfassen den aktuellen Zustand, identifizieren Risiken und schlagen eine Roadmap vor. Die ersten 20 % der Maßnahmen decken typischerweise 80 % der Risiken ab.

Ja. KI bringt neue Risiken — Prompt Injection, Datenlecks über das Modell, unkontrollierte Agentenaktionen. Klassische Security ist notwendig, aber nicht ausreichend. AI Governance definiert, was ein autonomes System tun darf.

Abhängig vom Umfang. Webanwendung: 2–5 Tage. Komplexe Infrastruktur: 2–4 Wochen. Preis ab 150K CZK.

Wenn Sie in einem regulierten Sektor sind (Finanzen, Energie, Gesundheitswesen, Transport), höchstwahrscheinlich ja. Wir helfen mit Gap-Analyse und Implementierung.

Haben Sie ein Projekt?

Lassen Sie uns darüber sprechen.

Termin vereinbaren