Security & AI Security

Threat modeling is not a one-time activity — it’s a living artifact. Every system has an attack surface and every change reshapes it. We perform STRIDE analysis during architecture design, not after production deployment.

How we work: We start with a data flow diagram — where data originates, how it flows, where it is stored. At every trust boundary we identify threats using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Each threat is scored via DREAD and mitigations are prioritized.

Attack surface mapping covers external APIs, internal services, databases, message brokers, CI/CD pipelines, third-party integrations. We also map the supply chain — dependencies, container images, build pipeline. An attacker looks for the weakest link, not the most obvious one.

Output: A structured threat model with prioritized risks, proposed mitigations and acceptance criteria. Integrated into the backlog — security stories alongside feature stories. Updated with every architectural change.

Tooling: Microsoft Threat Modeling Tool, OWASP Threat Dragon, custom STRIDE workshops. For larger systems — automated threat modeling from IaC (Terraform, Kubernetes manifests).

AI agents are a new attack vector. Classical security addresses authentication, authorization, encryption. AI security adds: prompt injection, data exfiltration via the model, uncontrolled actions, hallucination-driven errors. It is a different discipline.

Prompt injection is SQL injection for the LLM era. An attacker manipulates input so that the agent changes its behavior — ignores the system prompt, reveals internal data, performs an unauthorized action. We defend in multiple layers: input sanitization, output filtering, privileged/unprivileged context separation, canary tokens.

Data leakage is a silent killer. A model trained on internal data may disclose sensitive information in a response. An agent with database access may return data the user is not authorized to see. We solve this with PII detection on output, RBAC for agent actions, and an audit trail of every interaction.

AI Governance framework: We define what the agent may and may not do. What data it can read. What actions it can perform. Who approves escalations. A kill-switch for immediate shutdown. Regular red-team exercises specifically for AI systems.

Compliance: EU AI Act categorization, documentation of decision-making processes, bias monitoring, explainability. We prepare organizations for regulatory requirements arriving in 2025–2026.

A penetration test is not a checkbox — it is a simulation of a real attack. Our testers think like attackers. They don’t just look for known CVEs, but for business logic flaws, race conditions, and privilege escalation chains that automated scanners won’t find.

Black-box testing: The tester has no information about the system — just like a real attacker. Reconnaissance, enumeration, exploitation. Reveals what an attacker sees from the outside — exposed services, default credentials, information leakage in error messages, IDOR vulnerabilities.

White-box testing: The tester has access to source code, architecture, and configuration. Deeper analysis — security-focused code review (injection flaws, broken auth, insecure deserialization), IaC template review, secrets management analysis.

Scope and methodology: Every test has a clearly defined scope, rules of engagement and communication protocol. We use the OWASP Testing Guide, PTES, and our own methodologies for APIs and microservices. The report includes a reproducible PoC for each finding.

Continuous security testing: A one-time pentest is not enough. We integrate DAST (dynamic application security testing) into CI/CD pipelines. Every deploy passes an automated security scan. Manual pentest 1–2× per year for in-depth analysis.

The perimeter is dead. The classic model of “inside the network = trusted” does not work in the era of cloud, remote work and supply chain attacks. Zero Trust says: never trust, always verify. Every request, every user, every device.

Identity as the new perimeter: Authentication and authorization at every level. Service-to-service communication via mTLS (mutual TLS) — both sides prove their identity. SPIFFE/SPIRE for workload identity. No implicit trust between services.

Micro-segmentation: Network policies at the pod level (Kubernetes NetworkPolicy, Cilium). A service communicates only with those it must. Lateral movement after compromise of a single service is blocked. East-west traffic under control.

Least privilege: RBAC with granular permissions. Just-in-time access for administrators — permissions for 4 hours, not permanently. Regular access reviews. Privileged Access Management (PAM) for critical systems. Service accounts with minimal permissions.

Implementation: We don’t treat Zero Trust as a big-bang project. We start with an inventory — who communicates with whom, what data flows. Then we gradually introduce controls: first monitoring (we see what is happening), then enforcement (we block what shouldn’t happen). Typically 3–6 months to production state.

Incident response is not improvised. When PagerDuty calls on a Sunday night, you need a runbook, not a brainstorming session. We build incident response processes that work under stress — clear roles, clear steps, clear escalation paths.

SIEM and detection: Central collection of security events from infrastructure, applications, and identity providers. Correlation rules for detecting known attack patterns. Anomaly detection for unknown threats. MTTD (Mean Time to Detect) under 1 hour for critical incidents.

Runbooks for top incidents: Compromised credentials, ransomware, data breach, DDoS, insider threat, supply chain compromise. Each runbook: detection → containment → eradication → recovery → post-mortem. We test with table-top exercises quarterly.

On-call processes: Rotation, escalation matrix, response SLA. PagerDuty/OpsGenie integration. Clear severity levels (SEV1–SEV4) with defined response times. War room protocol for SEV1 incidents. Communication templates for stakeholders.

Post-mortem culture: Blameless post-mortem within 48 hours after every SEV1/SEV2. Root cause analysis, contributing factors, action items with owners and deadlines. Sharing learnings across teams. Goal: the same mistake never happens twice.

Compliance is not about paperwork — it’s about processes. An ISO 27001 certificate on the wall means nothing if there is no functioning ISMS behind it. We help organizations build security processes that pass an audit and actually protect.

NIS2 readiness: The new EU directive expands the scope of regulated entities and tightens requirements. Gap analysis against NIS2 requirements, an implementation roadmap, supply chain security assessment. If you are in a regulated sector (energy, transport, finance, healthcare, digital infrastructure), NIS2 applies to you.

DORA (Digital Operational Resilience Act): For the financial sector. ICT risk management, incident reporting, digital operational resilience testing, third-party risk management. We help with gap analysis, control implementation and audit preparation.

ISO 27001: ISMS implementation from scratch or preparation for recertification. Risk assessment, Statement of Applicability, policies and procedures, internal audits. Pragmatic approach — documentation that serves a purpose, not just exists.

GDPR operationally: Data mapping, DPIA (Data Protection Impact Assessment), breach notification processes, data subject rights (access, erasure, portability). Technical measures: pseudonymization, encryption, access control, audit logging. Privacy by Design integrated into the development process.