Current insights, research and stories in cybersecurity

SAP systems are the financial backbone of modern enterprises. The most critical business processes, ERP, financial accounting, human resources, the supply chain and production planning, all run on SAP. That makes SAP servers an extremely attractive target for attackers: a single successful compromise can mean access to all of an organization's sensitive data, from payroll records to bank transfers, from customer information to trade secrets. Unfortunately, what we see in the field is almost always the same picture. SAP installations are configured for functionality first, and security is addressed later or not at all.

In this article we walk through the vulnerability classes we most frequently encounter in SAP environments during our penetration tests, along with practical defense strategies for each. Our target audience is SAP/BASIS administrators and enterprise security teams. We will therefore examine both the risks and the concrete hardening steps at a technical level.

1. Default Standard Users and Static Passwords

During installation, SAP creates a set of standard users with predefined passwords. Chief among them are SAP* (the super user, whose historical default password was 06071992 or PASS), DDIC (the Data Dictionary administrator, default 19920706), EARLYWATCH (remote monitoring) and the TMSADM (Transport Management System) account found in client 000. These accounts are the first doors attackers try, because in many organizations these passwords are still at their defaults or weakly changed.

Risk: SAP* is especially dangerous. If it is deleted from the relevant user table, a hardcoded SAP* account known to the kernel can take over with a default password. This account grants fully privileged access if the profile parameter login/no_automatic_user_sapstar is not set correctly.

• Change the passwords of all standard accounts and lock the ones you can (audit their status via USR02).
• Disable the hardcoded SAP* behavior by enabling the login/no_automatic_user_sapstar = 1 parameter.
• Audit every client one by one (including 000, 001 and custom clients). Run the RSUSR003 report regularly to check standard users.
• Convert critical accounts into reference/service users via SU01 to disable interactive logon.

2. RFC and RFC Gateway Exploitation

RFC (Remote Function Call) is the core protocol that SAP systems use to talk to each other and to external applications. The RFC Gateway is the component that manages those calls, and when misconfigured it creates one of the most serious holes in an SAP environment. The real problem is that registered and started external programs can be executed through the Gateway without any control.

Risk: If the reg_info and sec_info access control lists are missing or defined too broadly, an unauthenticated attacker can register their own program through the Gateway and execute commands at the operating-system level. This is a direct path to taking over the SAP server. Trusted RFC connections (trusted/trusting), when set up incorrectly, offer a way to pivot laterally and vertically from a low-privilege system into a high-privilege one.

• Configure the reg_info and sec_info ACL files with a "default deny" logic. Whitelist only known programs and servers.
• Harden the gw/reg_no_conn_info and gw/acl_mode profile parameters, enable Gateway monitoring (SMGW).
• Set up trusted RFC connections with minimum privilege. Define the S_RFCACL authorization object strictly and avoid storing embedded user/password pairs in SM59.
• Remove unnecessary RFC destinations. Inventory SM59 regularly.

3. SAP ICM / ICMAD and Web-Component Vulnerabilities

The SAP Internet Communication Manager (ICM) is the component that handles HTTP, HTTPS and SMTP traffic for SAP systems and is SAP's web-facing surface to the outside world. In recent years serious vulnerabilities of the HTTP request smuggling and memory-corruption classes have been disclosed in this layer (the class of issues publicly referred to as "ICMAD" is an example).

Risk: Such flaws, which require no authentication, can result in session hijacking, credential disclosure and denial of service (DoS) on internet-facing SAP web applications. If the ICM faces the internet directly, the blast radius is very large.

• Apply the SAP Security Notes published for the ICM and Web Dispatcher as a priority.
• Do not expose SAP systems directly to the internet. Place a SAP Web Dispatcher and a WAF/reverse-proxy layer in front of them.
• Disable unused ICM services and unnecessary HTTP endpoints (SICF).

4. Attacks via Solution Manager and SAProuter

SAP Solution Manager (SolMan) is the central platform that manages all SAP systems, and it is typically connected to the other systems in the landscape via high-privilege RFC connections. That central position makes it a critical attack springboard. The SAProuter, meanwhile, is the component that routes SAP network traffic and is often placed in the DMZ facing the internet.

Risk: An unpatched SolMan instance, once compromised without authentication, can provide chained access to all of the satellite systems connected to it. A misconfigured SAProuter, if its saprouttab rules are loose, acts as a tunnel into the internal SAP network.

• Keep SolMan at the latest support package and Security Notes level. Restrict its management interfaces at the network level.
• Write the saprouttab rules for SAProuter on a "default deny" basis. Enforce encrypted, authenticated routing with SNC.
• Review the privileges of the RFC users between SolMan and satellite systems, and remove overly broad profiles (e.g. SAP_ALL).

5. Missing SAP Security Notes and Patch Gaps

SAP publishes security notes (SAP Security Notes) every month in a "Patch Tuesday"-like cycle. The most common fundamental problem in the field is that these notes go unapplied for months or even years. When SAP systems are managed with an "if it works, don't touch it" culture, known and publicly disclosed vulnerabilities remain open for a long time.

Risk: Ready-made exploit code is usually available for publicly disclosed vulnerabilities. The attacker's job is reduced to simply finding an unpatched target.

• Establish a regular patch cycle and track the SAP EarlyWatch Alert and System Recommendations (within SolMan) reports.
• Prioritize high-severity and critical (HotNews) notes in an emergency maintenance window.
• Where a patch cannot be applied, put compensating controls (network restriction, monitoring) in place.

6. Authorization and Segregation of Duties (SoD) Problems

SAP's authorization model is powerful but complex. Roles, profiles and authorization objects accumulate over time until they become enormous and unauditable. The most critical findings are over-privileged users and Segregation of Duties violations.

Risk: Users carrying the SAP_ALL or SAP_NEW profile have unlimited authority on the system. In SoD violations, a single user can both create a vendor and approve a payment, opening the door to internal fraud. In addition, loose definitions of powerful objects such as S_DEVELOP, S_TABU_DIS and S_RFC lead to privilege escalation.

• Remove the SAP_ALL and SAP_NEW profiles from the production environment. Identify broadly authorized users regularly with RSUSR002.
• Define an SoD conflict matrix. Audit it continuously with SAP GRC Access Control or equivalent tools.
• Adopt the principle of least privilege. Tightly restrict debugging and table-access authorizations (S_DEVELOP, S_TABU_DIS).

7. Insecure Interfaces and Unencrypted Communication

By default, SAP's two core protocols, DIAG (the client protocol between the SAP GUI and the server) and RFC, run unencrypted. DIAG uses only weak obfuscation, not real encryption.

Risk: An attacker who can sniff network traffic can decode credentials, business data and session information from DIAG/RFC sessions in clear text. Man-in-the-middle (MITM) attacks carried out on the internal network are therefore especially effective.

• Encrypt DIAG and RFC traffic end to end with SNC (Secure Network Communications).
• Enforce TLS for web traffic and disable weak cipher suites.
• Strengthen password policies (login/min_password_lng, complexity parameters) and, where possible, move to single sign-on (SSO) with multi-factor authentication.

8. Overall Defense Strategy: A Layered Approach

SAP security is not achieved with a single setting. It requires a program built from overlapping layers. Use network segmentation to place SAP systems in a dedicated security zone. Open management ports (the 32xx, 33xx, 36xx and 81xx series) only to authorized administration networks, and never position any SAP backend component so that it faces the internet directly. Run the patch cycle as an enterprise process, continuously audit the RFC and Gateway configuration, and review the authorization matrix periodically.

On top of these, add a monitoring and detection layer: enable the SAP audit log (SM19/SM20: Security Audit Log) and forward critical events (failed logon attempts, authorization changes, RFC calls) to a central SIEM. Security is not "set and forget". It is a continuously managed cycle.

Quick checklist

• Have the passwords of all standard accounts (SAP*, DDIC, EARLYWATCH, TMSADM) been changed and the unnecessary ones locked?
• Is the login/no_automatic_user_sapstar = 1 parameter active on every client?
• Are the RFC Gateway reg_info/sec_info ACLs configured with "default deny"?
• Are critical and HotNews SAP Security Notes up to date, and is there a regular patch cycle?
• Have the SAP_ALL/SAP_NEW profiles been removed from production and are SoD conflicts audited?
• Are DIAG and RFC traffic encrypted with SNC, and web traffic with TLS?
• Are SAP systems isolated by network segmentation and not directly exposed to the internet?
• Is the Security Audit Log enabled and centrally monitored via a SIEM?

The Raze approach

At Raze Security we assess SAP environments not just with automated scanning but from a real attacker's perspective. From RFC Gateway exploitation to standard-account auditing, from authorization and SoD analysis to testing the external surface such as ICM, SolMan and SAProuter, we work with an SAP-specific methodology and report every vulnerability we find with concrete hardening steps. To clarify the security posture of your SAP infrastructure, explore our penetration testing service, or get in touch with us for an assessment tailored to your organization.

Contrary to what most organizations assume, KVKK compliance is not a project you complete once and shelve. It is a living process that renews itself alongside the data lifecycle, in which administrative and technical measures are inseparable. Although years have passed since Law No. 6698 on the Protection of Personal Data came into force, in the audit and advisory work we do in the field we keep seeing the same mistakes repeated. Most of these mistakes stem not from bad intent but from the belief that compliance is purely a legal-document exercise. In reality, without technical measures such as access control, encryption, logging and penetration testing, even the most perfect privacy notice remains words on paper. In this article we walk through the seven mistakes we encounter most often, each paired with the right, evidence-based approach.

1. Treating the data inventory as a one-off spreadsheet

The most common mistake is to see the personal-data processing inventory as a static table filled in once and then forgotten. In reality, organizations bring new applications online every day, add new form fields and integrate cloud services. Within a few months a gap opens between the inventory and reality, and everything from the VERBİS registration to the privacy notices falls out of date. More dangerous still are the shadow IT systems that collect data without anyone's knowledge.

The right approach: Treat the inventory as a living asset. As far as possible, periodically scan databases, file shares and cloud storage with automated data-discovery tools and classify the fields that contain personal data. Trigger manual surveys not once a year but on every significant system change. Keep the inventory relational, with data category, legal basis, retention period, recipient groups and transfer details, so that VERBİS and the privacy notices are fed from it.

2. Getting by with a generic, lawyer-template privacy notice

Generic template privacy notices downloaded from the internet or handed to every customer in the same form do not meet the expectation of specificity in Article 10 of the Law. It remains unclear which data is processed, for what purpose and on which legal basis. Transfer recipients are glossed over with vague wording. Authority decisions have found catch-all purpose statements such as "carrying out commercial activities" to be insufficient.

The right approach: Prepare the privacy notice contextually for each processing activity and each touchpoint (web form, call center, HR application, camera recording). The notice must clearly state the categories of data processed, the concrete purposes, the legal basis relied upon, the recipient groups to whom data is transferred and the retention period. Keep the duty to inform separate from explicit consent. The duty to inform always applies, whereas consent is required only in specific cases.

3. Over-relying on explicit consent and placing it everywhere

The "just in case, let's get consent" approach is one of the most misunderstood points in KVKK. Explicit consent is only one of the six legal bases in the Law, and an exceptional one. Adding consent to data that can already be processed for the performance of a contract, a legal obligation, a legitimate interest or the establishment of a right is both legally incorrect and creates risk: because explicit consent can always be withdrawn. You cannot continue to process data you declared you process on the basis of consent once the person withdraws it.

The right approach: First determine the appropriate legal basis for each processing activity. Resort to explicit consent only when no other legal basis applies (for example electronic marketing messages or the processing of special-category data). Obtain consent freely and on an informed basis, separate from other texts and approvals. Consent you make "mandatory in order to receive the service" is deemed invalid.

4. Registering with VERBİS once and never updating it

The Data Controllers' Registry Information System (VERBİS) registration is not a formality that ends with the first filing. The data categories, processing purposes, recipient groups, cross-border transfer details and technical-administrative measures declared at registration change over time. If these changes are not reflected in VERBİS, the declaration contradicts reality, and that is an administrative-sanction risk during audits.

The right approach: Position the VERBİS declaration as an output of your data inventory, update the registry when the inventory changes. Establish a periodic review schedule to track situations such as a new transfer recipient, a new cloud service or changing retention periods. Make sure the declared measures (access authorization, encryption, logging) are genuinely applied in the field.

5. Providing inadequate protection for cross-border transfers

Keeping data with a cloud provider abroad is one of the most sensitive areas of KVKK. Many organizations never assess the legal basis of the transfer when using a SaaS tool whose servers are abroad. With the new transfer regime that took effect in 2024, a tiered framework has formed: transfers to countries with an adequacy decision, transfers backed by appropriate safeguards (standard contractual clauses / SCC, binding corporate rules / BCR, undertakings) and exceptions for limited, incidental cases.

The right approach: For each cross-border transfer, first run a Transfer Impact Assessment (TIA), assess the destination country's level of protection, the provider's technical measures and the sensitivity of the data category. Document the appropriate safeguard (SCC/BCR/undertaking) and notify the Authority where required. Encrypt the transferred data end to end where possible, keep key management under your own control and evaluate data-localization options.

6. Skipping the controller / processor distinction and the DPA

When working with a payroll firm, a cloud provider or a call center, leaving the parties' roles under KVKK undefined creates a serious accountability gap. The data controller is the party that determines the purposes and means of processing. The data processor is the one that processes data on the controller's instructions. Working without making this distinction and without governing the relationship with a written contract makes it unclear who is responsible for what at the moment of a breach.

The right approach: Sign a data processing agreement (DPA) with every supplier. The DPA must clearly govern that the processor will act only on instructions, will apply minimum technical-administrative measures, the confidentiality obligation, the use of sub-processors, the obligation to notify immediately in the event of a breach, and the destruction/return of data at the end of the contract. Periodically verify suppliers' security maturity (right to audit, requesting a penetration test report).

7. Leaving the breach-notification process on paper

Many organizations have a data-breach response procedure. But that procedure does not work in a real crisis. KVKK expects you to notify the Authority as soon as possible and within 72 hours from the moment you become aware of the breach. Affected data subjects must also be notified within a reasonable time. In practice, the problem is that the bridge between the technical team that detects the breach and the legal/compliance team that will make the notification has never been built. If logging is inadequate, the scope of the breach and the number of affected records cannot even be determined within 72 hours.

The right approach: Integrate your incident response (IR) process with the KVKK notification obligation. Define with clear roles who detects the breach and how, who classifies it, when legal gets involved and who makes the notification. Build adequate logging and monitoring infrastructure so the scope of the breach can be determined quickly. Most importantly, exercise this process at least once a year with a tabletop exercise, the 72-hour clock should be tested in a drill, not for the first time during a real incident.

Quick checklist

• Is your data inventory fed by automated discovery and updated on system changes?
• Are your privacy notices contextual and specific for each touchpoint?
• Have you determined the correct legal basis for each processing activity. Do you obtain explicit consent only when it is genuinely required?
• Is your VERBİS registration in sync with the inventory and up to date?
• Have you run a TIA for cross-border transfers and documented the appropriate safeguard (SCC/BCR/undertaking)?
• Is there a signed DPA with all suppliers. Are the roles (controller/processor) clear?
• Has your breach-notification process been tested with a drill against the 72-hour target?
• Are technical measures such as encryption, access control, logging and regular penetration testing applied together with administrative measures?

The Raze approach

At Raze Security we treat KVKK compliance not as a one-off document delivery but as a continuous process in which technical and administrative measures are managed together. From building the data inventory to correctly designing the notice and consent architecture, from cross-border transfer assessments to supplier DPAs and breach-response drills, we integrate every link, supported by access control, encryption, logging and regular penetration testing. That way compliance does not stay on paper but turns into genuine security maturity.

To assess your organization's KVKK compliance maturity end to end and avoid these seven mistakes, explore our KVKK compliance solution or get in touch with us directly.

Ransomware attacks are no longer isolated, opportunistic events. They are the product of a professionalized underground economy built on division of labor. In the cases our DFIR (digital forensics and incident response) team has worked recently, we have witnessed first-hand just how mature attackers have become, both technically and operationally. In this article we share, in a field-notes tone, the trends we have distilled from the incidents we responded to heading into 2026: which entry points are being exploited and what actually makes a difference on the defensive side. Our aim is not to spread fear. It is to make the adversary's playbook legible so you can position your defenses in the right place.

Initial access: the door still opens in the same places

In the vast majority of the cases we responded to, attackers did not get in through a zero-day but through known, preventable weaknesses. The initial-access methods we see again and again in the field are:

• Phishing and social engineering: Emails with malicious attachments or links, fake login pages, and increasingly the defeat of multi-factor authentication through MFA fatigue (push bombing).
• Internet-facing RDP and VPN services: Publicly listening Remote Desktop and weakly configured VPN portals are an open invitation to brute-force and password-spraying attacks.
• Unpatched edge and VPN devices: Unpatched vulnerabilities in firewalls, VPN gateways and other perimeter devices can provide network entry without even requiring authentication. These devices are often overlooked blind spots.
• Stolen credentials: Session cookies and passwords harvested by infostealer malware are bought and sold in underground markets. An attacker who logs in with a valid account can silently bypass many layers of defense.

What these methods have in common is the initial access broker ecosystem, which has now become a specialty of its own. One actor breaks into the network, catalogs and sells the access. The ransomware operator then buys this ready-made access and moves straight to the later stages of the attack. This division of labor increases both the speed and the scale of attacks.

Double and triple extortion: no longer just encryption

Until a few years ago the only leverage of ransomware was encrypting data. If you had a solid backup, your bargaining power was high. Today the picture is different. In almost all of the incidents we see in the field, attackers exfiltrate the data before encryption and use it as a second pressure tool. In this double extortion model, even if you restore from backup the threat of leaking the stolen sensitive data stays on the table.

Triple extortion takes the pressure a step further:

• Direct pressure on third parties using customer, patient or business-partner information in the leaked data.
• Undermining the organization's online services with DDoS attacks during the negotiation process.
• Increasing reputational and compliance pressure with the threat of reporting to regulators, the press or affected individuals.

This multi-layered pressure turns incident response from a purely technical recovery operation into crisis management that requires the coordination of legal, communications and senior leadership.

RaaS and the affiliate model: crime as a franchise

The most decisive structural change in the ransomware world is the Ransomware-as-a-Service model. In this model a core team develops and operates the malware, the encryption infrastructure, the leak site and the negotiation panels. Partners called affiliates use these tools to carry out the attacks and share the proceeds at a set ratio.

This structure has two important consequences for defense. First, the technical skill threshold drops. Even actors who could not develop sophisticated malware can do serious damage with off-the-shelf tools. Second, different affiliates using the same ransomware family can exhibit very different tactics, techniques and procedures (TTPs). That is why a defensive approach focused on a single group name or a single signature falls short. Behavior-based detection becomes critical.

Encryption-less extortion: exfiltration is enough

Another notable trend is some actors skipping the encryption stage entirely. Encryption is operationally noisy and carries the risk of being detected and interrupted by a response. Instead, attackers prefer to quietly exfiltrate large volumes of data and extort with the threat of disclosure alone.

This approach underlines that backup, the cornerstone of classic ransomware defense, is not enough on its own. Even if your data is never encrypted and your systems never go down, the stolen data can be a crisis in itself. That shifts the center of gravity of defense from recovery toward prevention and data-exfiltration detection.

Lateral movement and Active Directory takeover

The goal of the attacker who has broken in is not a single machine. It is the widest possible blast radius. In the typical flow we observe in the field, after the first endpoint they access the attacker follows these steps:

1. Privilege escalation by collecting local and in-memory credentials (credential dumping).
2. Mapping high-value servers and the Active Directory infrastructure through network reconnaissance.
3. Seizing control of the identity infrastructure by obtaining Domain Admin privileges.
4. Deploying the ransomware payload to the entire fleet at once through Group Policy (GPO) or centralized software-distribution tools.

An Active Directory takeover is the line between the compromise of a single machine and the paralysis of the entire organization. That is why protecting privileged accounts, separating administration layers with a tier model, and strictly auditing Domain Admin sessions form the backbone of defense.

Targeting shifts: SMBs, the supply chain and critical sectors

As large organizations' defenses harden and high-profile attacks attract more investigative pressure, some actors have shifted their focus. The trends we observe in the field:

• SMBs: Mid-sized businesses with limited security budgets and teams stand out as relatively easy targets.
• The supply chain: Compromising a single managed service provider (MSP) or software supplier means access to many customers through it. This multiplier effect is extremely attractive to attackers.
• Healthcare and the public sector: In these sectors, where service interruption is intolerable, pressure to pay the ransom is high. That makes them priority targets.

Speed: the time from initial access to encryption is shrinking

Perhaps the most critical trend is the dramatic shortening of the attack timeline. Where we used to see an attacker dwelling in the network for weeks, today we encounter cases where the time from initial access to data exfiltration and encryption drops to hours. Automation, ready-made toolkits and purchased initial access make this speed possible.

This speed directly affects defensive strategy: you need not logs reviewed days later but real-time detection and automated response capability. It is not enough for EDR/XDR solutions to merely be installed. Alerts must be monitored 24/7 and responded to quickly. If the attacker moves within minutes, the defense has to match that tempo.

Defense: keep the fundamentals solid and the layers deep

The good news is that most of the successful attacks we see in the field happen not through exotic techniques but through neglected basic controls. Properly implemented basic hygiene makes the attacker's job much harder. The defensive layers we prioritize:

• Resilient, isolated backups: The 3-2-1 rule (three copies, two different media, one offline/air-gapped). Immutable backups and regular restore tests are non-negotiable.
• MFA everywhere: Especially on VPN, RDP, email and privileged accounts. Where possible, phishing-resistant methods (such as FIDO2).
• EDR/XDR and continuous monitoring: Early response with behavior-based detection and 24/7 SOC support.
• Network segmentation: Flat networks make lateral movement easy. Separating critical systems and management networks limits spread.
• Patch management: A fast, disciplined process that prioritizes internet-facing edge/VPN devices in particular.
• Principle of least privilege: Removing unnecessary admin accounts and strictly auditing privileged access.
• Incident response readiness: A written plan, clear roles and regular tabletop exercises so reflexes are ready at the moment of crisis.

Quick checklist

1. Inventory all internet-facing RDP, VPN and management interfaces. Shut down the unnecessary ones and put the rest behind MFA.
2. Check the patch status of edge and VPN devices. Close known critical vulnerabilities first.
3. Verify that at least one copy of your backups is offline/immutable and run a restore test.
4. Confirm that MFA is active on all privileged accounts and remote access.
5. Make sure EDR/XDR alerts are monitored 24/7 and that the response threshold is defined.
6. Reduce the number of Domain Admins in Active Directory and apply a tier model and privileged access management.
7. Segment the network. Isolate critical servers and the management network from the user network.
8. Keep your incident response plan current and run a drill at least once a year.

The Raze approach

At Raze Security we witness these trends not just by reading reports but by responding to incidents in the field ourselves. Our approach is built on turning the attacker's playbook against them: closing the most frequently exploited entry points, building a layered defense that makes lateral movement harder, and being prepared for the worst-case scenario. We turn the lessons we draw from every case we respond to into prevention and preparedness work for organizations.

If you are facing an incident or want to assess your organization's resilience to ransomware, explore our incident response service or get in touch with us directly. As the attacker speeds up, being prepared is the strongest defense.

For the first time, Türkiye has regulated cybersecurity with a dedicated, standalone law. The phones started ringing: "Does this law cover us? What do we need to do? What is the penalty risk?" In this article we walk through the framework the law introduces, who it covers and the concrete steps a company should take starting today, as an actionable roadmap, without drowning you in legal language.

Why was a separate law needed?

Until now, cybersecurity was a fragmented field scattered across KVKK, sectoral regulations (BDDK, EPDK, BTK) and various communiqués. The growing threat surface of critical infrastructure, ransomware attacks reaching a scale capable of halting public services, and the need for national coordination made a holistic and binding framework necessary. The new law aims to fill this gap: to centralize authority and clarify obligations.

1. What does the law mainly regulate?

The backbone of the law falls under three headings:

• A central authority: A central body (the Cybersecurity Directorate) is established that sets national cybersecurity policy and holds regulatory and oversight powers. This authority will determine the details through secondary legislation (regulations, communiqués), meaning you must follow not only the text of the law but also the regulations to come.
• An obligations regime: For in-scope organizations, requirements for security measures, incident notification, audit and information sharing are defined.
• Sanctions: A scale of sanctions is introduced, ranging from administrative fines to prison sentences for serious offenses. (For specific penalty amounts and terms, the current text of the law and the secondary legislation should be taken as the basis.)

2. Does this law cover me?

This is the most critical question. The scope typically consists of the following rings:

• Public institutions and organizations.
• Critical infrastructure operators: sectors such as energy, finance/banking, electronic communications (telecom), water, transport and healthcare, where an interruption would affect the social/economic order.
• Suppliers providing service/products to these organizations: Even if you are not directly critical infrastructure, if you provide them with software, cloud, consultancy or operations services you may be drawn into the obligation chain contractually.

Practical advice: Base the "we are not in scope" decision not on an assumption but on a documented applicability assessment. In an audit you need to be able to show "why you are not in scope."

3. Core obligations

The headline items for in-scope organizations:

• Take and maintain security measures: Minimum technical and administrative controls: access management, logging/monitoring, security testing, asset and risk management.
• Incident notification: Reporting cyber incidents to the competent authority within the prescribed time and format. (Requires an operational maturity similar to KVKK's 72-hour breach notification.)
• Being subject to audit: Being ready for both internal and authority-led audits. Being able to present evidence and records.
• Local/national solution and data-location preferences: Expectations toward local products and onshore data retention may arise for certain critical systems.
• Information sharing: Sharing threat intelligence and incident data for national coordination.

4. Sanctions: why should you take them seriously?

The law foresees a highly deterrent scale of sanctions: administrative fines (which in some regulations can be indexed to turnover/revenue) for organizations that do not comply, and prison sentences on the table for unauthorized activities and serious actions against critical systems. The critical point here: penalty risk is not just a "non-compliance bill". It is a multiplier that aggravates the organization's liability in the event of an incident. (The current text of the law should be taken as the basis for exact amounts and terms.)

5. Relationship with other legislation: not duplication, but layered compliance

A common misconception: "We already have KVKK and ISO 27001, this is the same thing." It is not. These are overlapping but differently purposed layers:

• KVKK protects personal data. This law targets national/critical-infrastructure security.
• ISO 27001 is a voluntary management-system framework. This law is a binding legal obligation.
• Sectoral regulations such as BDDK/EPDK continue in their own domains. The new law adds a national umbrella on top of them.

The good news: if you have an ISO 27001 or sectoral compliance foundation, you can meet a significant portion of the new obligations by mapping your existing controls, you do not start from scratch.

6. What should companies do today? (Readiness roadmap)

1. Applicability assessment: Document whether the law and the secondary legislation cover you (and your supply chain).
2. Gap assessment: Compare your existing controls with the expected obligations. Identify the gap.
3. Mature your security controls: Asset inventory, access management, logging/monitoring, regular penetration testing and vulnerability management.
4. Set up the incident response and notification process: Exercise the detect→assess→notify flow in line with the time requirements.
5. Include the supply chain: Add security and notification clauses to contracts. Assess third parties.
6. Be audit-ready: Keep policies, records and evidence in an auditable form.
7. Track the regulations: The real details will come in secondary legislation. Set up a tracking mechanism.

Quick checklist

• Have we documented whether the law covers us?
• Have we done a gap analysis against the obligations?
• Do we have a regular penetration testing and vulnerability management program?
• Is our incident-notification process defined and exercised?
• Do supplier contracts include security/notification clauses?
• Are the records and evidence to be presented in an audit ready?
• Have we designated an owner/process that tracks the secondary legislation?

The Raze approach

We treat regulatory compliance not as a "document-filing" exercise but as an auditable security program. We start with an applicability assessment and a gap analysis. We integrate penetration testing, vulnerability management and incident response capabilities into your organization. And we round it off with an audit-ready evidence chain. Explore our vulnerability management and compliance solutions or get in touch with us.

This article is for general information purposes only. It is not a substitute for legal advice. The current text of the law and the secondary legislation should be taken as the basis.

Most managers do not realize that a single decision made before signing the penetration test contract shapes the result of the test from start to finish: how much information and access you give the attacking team. On the same system, a test run with a team that knows nothing and a test run with a team that has the source code and architecture documents produce completely different results. The three approaches, black box, grey box and white box, are not alternatives to one another. Each answers a different question. Choosing the right one means focusing your budget and test time where they will produce the highest value.

The core distinction: the level of information given to the attacker

The only variable that separates the three approaches is the degree of prior knowledge and access provided to the test team. This variable forms a spectrum: at one end an actor who knows nothing and attacks from outside. At the other an auditor who knows all the internal details of the system.

• Black box: The team knows only the target's name or IP range. No internal structure, source code or account information is given.
• Grey box: The team is given limited information. Typically a standard user account, partial architecture knowledge or API documentation.
• White box: The team has the source code, architecture diagrams, configuration files and administrator-level access.

The tension between these three approaches is really a balance between two fundamental needs: realism (how realistically an attack is simulated) and coverage and depth (how many and how deep vulnerabilities can be found in a limited time).

Black box: real attacker simulation

In a black-box test the team starts with zero internal knowledge, just like an unknown attacker on the internet. It first does reconnaissance, maps open ports and services, then tries to exploit the externally visible attack surface. The greatest strength of this method is its realism: it shows most accurately what an outside-looking threat actor could really see and exploit.

Pros: The scenario closest to a real-world attack. Clearly reveals the external attack surface and visible disclosures. The results are unbiased because they do not rely on internal knowledge.

Cons: Much of the time is spent on the reconnaissance phase, which reduces depth. Vulnerabilities behind authorization layers, internal services and unreachable code paths remain blind spots. Less coverage can be tested for the same budget. A vulnerability not found does not mean it does not exist.

White box: maximum depth with source code access

In a white-box test the team accesses everything the defensive side has: source code, architecture, configurations and privileged accounts. This lets the team verify rather than guess. It can trace exploitation chains down to the exact line in the code. Combining static code analysis with dynamic testing, this approach offers the highest coverage and depth.

Pros: Surfaces vulnerabilities almost invisible in black box, such as business-logic flaws, poor use of cryptography, hidden backdoors and deep privilege-escalation paths. Every finding can be traced to its root cause. The limited time is spent on real exploitation rather than reconnaissance.

Cons: It does not simulate the knowledge level of a real external attacker, so it can be misleading about the feasibility of an attack. Sharing source code requires corporate and legal sensitivity. Because the finding density is high, the triage and prioritization burden increases.

Grey box: the balanced middle ground

Grey box stands in the middle of the spectrum and is the most frequently preferred approach in practice. The team is usually given a standard user account and partial architecture knowledge. This models the "credentials leaked or a malicious internal user" scenario. Which is the starting point of the majority of real breaches.

Pros: Without wasting time in the reconnaissance phase, it focuses directly on the post-authorization attack surface. It strikes the most efficient balance between realism and depth. For the same budget it is more likely to find more meaningful vulnerabilities than black box.

Cons: It is neither a full external attacker simulation nor white box's complete code visibility. Since the level of access given directly affects the result, defining the scope clearly from the start is critical.

The balance of cost, time and value

As the information level increases, the time the team wastes decreases. In black box a significant part of the time goes to reconnaissance, and that time may not directly translate into a vulnerability finding. In grey and white box the reconnaissance burden lightens, so the same number of days translates into more real testing work. That is, the number of vulnerabilities found per unit of cost usually increases. However, because white box requires source-code review expertise and broader analysis, it is mostly the most expensive option in terms of total effort and therefore cost. The decision is not "which is cheapest" but "where do I put my budget to reduce the highest risk the fastest."

A decision framework

To choose the right approach, start by clarifying the purpose of the test. The following ordered questions will steer you to the right option:

1. What is the goal? If you want to measure resilience to a real external attack, black box. If you want to harden the system as comprehensively as possible, white box. If you want maximum efficiency in a realistic threat model, grey box.
2. Which threat actor are you modeling? Are you worried about an anonymous external attacker, an actor with leaked credentials, or a malicious insider?
3. How critical is the system? In financial, healthcare or critical-infrastructure applications, the depth of white box is usually a necessity.
4. What is your maturity level? For an organization running its first test, grey box is a fast, high-return starting point. A mature security program needs white box.

Quick checklist

• If you want to see how resistant an internet-facing application is from the outside: black box.
• If you are testing what a threat actor could derive from publicly visible disclosures: black box.
• If you are measuring how much damage a registered user or a leaked account could do to the system: grey box.
• If you want the highest realistic coverage on a limited budget: grey box.
• If you are hardening a newly developed or highly critical application in full depth: white box.
• If you want to verify the business-logic, cryptography or authorization layer down to the code: white box.
• If regulation or compliance requires the most comprehensive review: white box.
• If you are unsure which and want a balanced start: grey box.

The Raze approach

At Raze Security we do not force any test into a single mold. We first clarify your threat model, the criticality of the system and your security maturity together with you. Then we design the scope, information level and effort according to these goals. For most organizations, a hybrid setup that starts with grey box and descends to white-box depth on critical components delivers the highest return in practice. Whichever approach you choose, our TSE Level-A approved team produces a report that traces every finding to its root cause and offers an actionable remediation roadmap.

To determine the right approach for your organization together and clarify the scope, explore our penetration testing service, or get in touch with us with your questions.

At the heart of modern applications there are no longer monolithic servers but APIs that constantly talk to each other and to mobile/web clients. This architecture brought speed and flexibility. But it also brought a brand-new attack surface that traditional security tools mostly cannot see. For an attacker, the API is the most direct door to your business logic: predictable endpoints, structured JSON responses and often weak authorization controls. In this article we walk through why APIs require a separate discipline, and the most critical items of the OWASP API Security Top 10 (2023) list with realistic exploitation scenarios and concrete defensive recommendations for each.

Why Are APIs a Separate Attack Surface?

Traditional web application security was largely designed to protect server-generated HTML, form submissions and session-based flows. APIs break most of these assumptions. The client side (mobile app, SPA, third-party integration) carries much of the business logic and sends direct, structured requests to the server. This makes it easier for the attacker to manipulate, at the request level, which object, which resource and which function they access.

Why isn't a WAF enough? Traditional WAFs are signature-based. They are good at catching syntactic attack patterns such as SQL injection or XSS. But most API vulnerabilities are business-logic and authorization problems. The request GET /api/orders/124 is technically a completely "clean" and valid HTTP request. There is nothing abnormal about it for a WAF. But if that order belongs to another user, this request is a serious data leak. Without context and identity it is almost impossible to detect authorization violations from the network layer. That is why API security must be addressed in the application itself, at the code and design level.

BOLA (API1): Broken Object Level Authorization

Broken Object Level Authorization is number one on the OWASP list, and not without reason: it is the most common and highest-impact cause of API breaches. It is the API-world equivalent of the classic IDOR (Insecure Direct Object Reference). The problem is that the endpoint authenticates but does not check whether that user owns the requested object.

Exploitation scenario: In an e-commerce application a logged-in user views their own invoice with GET /api/v1/invoices/4471. The attacker tries other IDs in turn simply by changing the number (4470, 4469...) and reaches the invoice, address and order information of other customers. IDs that increment in a counter-like fashion make it possible to "scrape" the entire database with automated tools.

Defense: On every object access, verify on the server side that the user in the session owns that resource (for example WHERE id = ? AND owner_id = current_user). Using unpredictable identifiers (UUID) helps but is not a defense on its own. The real fix is applying the authorization check centrally and consistently at every endpoint.

Broken Authentication (API2)

Authentication mechanisms are often implemented incorrectly in APIs: weak JWT validation, tokens that never expire or cannot be revoked, login and password-reset endpoints lacking brute-force protection, or flows that carry credentials openly in the request body.

Exploitation scenario: If an API accepts the JWT signature algorithm based on a value in the header coming from the client, the attacker can produce a valid token they signed themselves, by setting the alg field to none or by abusing symmetric/asymmetric key confusion, and impersonate any user. Another common scenario is the takeover of accounts by brute force due to the absence of a rate limit on the OTP or login endpoint.

Defense: Fix the algorithm on the server side in JWT validation, and use strong secret keys and short lifetimes. Add rate limiting and account lockout to all identity flows. Wherever possible, prefer a mature, audited identity standard (OAuth 2.0 / OIDC). Avoid writing authentication from scratch yourself.

BOPLA (API3): Object Property Level Authorization

Broken Object Property Level Authorization combines two older risks (Excessive Data Exposure and Mass Assignment). The problem is in access control not to the whole object but to its individual properties.

• Excessive data exposure: When returning a user object, the API puts all columns (password hash, internal roles, email) into the JSON and leaves filtering to the client. The attacker reads these fields in the raw response.
• Mass assignment: The profile-update endpoint binds the incoming JSON directly to the model. The attacker escalates their privileges by adding a "role":"admin" or "isVerified":true field to the request body.

Defense: Use an explicit allow-list approach for both incoming and outgoing data. Shape responses with DTOs/serializers that contain only the necessary fields. In the incoming request, accept only the fields the client is allowed to change.

BFLA (API5): Broken Function Level Authorization

Broken Function Level Authorization is a user being able to call functions/actions they should not access. Where BOLA deals with the "which data" question, BFLA deals with the "which operation" question.

Exploitation scenario: A normal user discovers the endpoints of an admin panel that are only hidden in the interface but not protected in the API. While GET /api/users is closed to ordinary users, endpoints such as DELETE /api/admin/users/55 or POST /api/admin/promote can be called directly because they perform no authorization check, and the attacker carries out administrative functions.

Defense: Set up authorization on a "deny by default" principle. Protect admin and privileged endpoints with role-based control in a central layer. Base security on server-side control, not on hiding menus in the client interface.

Unrestricted Resource Consumption (API4) and SSRF (API7)

Unrestricted resource consumption (API4) is the abuse of endpoints with no rate limit, pagination or size limit. By requesting thousands of records per page, repeating heavy queries, or triggering endpoints that send SMS/email, the attacker can cause both a service outage and a direct cost increase.

Server-Side Request Forgery (SSRF, API7), meanwhile, arises when the API calls, on the server side, a URL it received from the client without validating it.

Exploitation scenario: An endpoint with an "import image from URL" feature makes a request from the server to the address the user provides. The attacker can target the cloud provider's metadata service (http://169.254.169.254/) by pointing this address at it, or target services on the internal network, to obtain temporary credentials.

Defense: Apply rate limits, pagination and request size/complexity limits to all endpoints. Against SSRF, validate URLs coming from the client with a strict allow-list, block egress to internal IP ranges and, where possible, make outbound requests from a separate, restricted network segment.

A Note on REST and GraphQL

Almost all of the risks here are protocol-independent. BOLA, BFLA and BOPLA affect both REST and GraphQL APIs in the same way. However, GraphQL also brings some risks of its own: query-complexity attacks that exhaust the server by deeply nested queries calling nested relationships in a single query, and the exposure of the entire schema to the attacker when introspection is enabled. In GraphQL, it is critical to set the rate limit based on query depth and cost analysis rather than on the endpoint, to disable introspection in production and to apply authorization at the field/resolver level.

Quick checklist

• Is ownership and authorization checking performed on the server side on every object access? (BOLA)
• Does authentication rely on mature standards such as OAuth 2.0 / OIDC. Is the JWT algorithm fixed on the server?
• Are responses filtered with DTOs/serializers, and are incoming requests protected against mass assignment with an allow-list? (BOPLA)
• Are admin and privileged endpoints protected with deny-by-default role control? (BFLA)
• Are there rate limits, pagination and request-size limits on all endpoints? (Resource consumption)
• Are server-side outbound requests validated with an allow-list and access to the internal network blocked? (SSRF)
• In GraphQL, is introspection disabled in production and is query depth/cost limited?
• Is the API inventory current. Are old versions (/v1) and test endpoints exposed?

The Raze approach

API security is an area where automated scanners skim the surface but the real risk is hidden. Because vulnerabilities such as BOLA and BFLA require understanding the business logic and the authorization context. At Raze Security we base our API tests not just on tool output but on manual authorization analysis with multiple user roles, business-logic scenarios and real exploitation attempts. We treat the OWASP API Security Top 10 not as a checklist but as the starting point of an in-depth methodology.

If you want to see how your API surface could be exploited in the real world, explore our penetration testing service run by our expert team, or get in touch with us to discuss your needs.

Friday, near the end of the working day. A specialist on the accounting team receives an email from the CFO: "A strategic acquisition negotiation has finally closed, confidentiality is critical. An urgent payment must be made to the account below within today, do not share the details with anyone." The email carries the CFO's real signature block, the tone is natural, and it even arrives as a reply to a previous thread. Out of respect for authority and under pressure of urgency, the specialist initiates the payment. No firewall raises an alarm, no antivirus kicks in. Because the attacker targeted not systems but the human. This scenario is a typical example of BEC (Business Email Compromise) attacks, one of the fastest-growing categories of corporate loss.

As technical controls mature, attackers turn to the weakest and most unpredictable layer: the human. In this article we walk through the anatomy of social engineering, the psychology of persuasion behind it, and a layered approach that turns your employees from the "weakest link" into a "human firewall."

Why is social engineering so effective?

Modern organizations invest heavily in firewalls, EDR solutions, multi-factor authentication (MFA) and regular patch management. These investments genuinely narrow the technical attack surface. But no technical control can easily stop the deliberate step taken by a persuaded employee. When a user voluntarily hands over a credential, approves a payment request or runs an attachment, the attacker crosses most technical barriers with a legitimate user identity. For attackers, the human is a far cheaper target than the most expensive password to crack.

Recognizing the attack types

Social engineering is not a single technique but a broad family of attacks. The most common types:

• Phishing: Mass attacks sent to a broad audience with legitimate-looking fake emails, aimed at spreading credentials theft or malware.
• Spear phishing: Attacks prepared specifically for a particular person or department, personalized with information gathered about the victim and therefore far more convincing.
• CEO fraud / BEC: Attacks that impersonate senior management or a finance officer to request an urgent money transfer or sensitive data, and easily bypass technical filters because they usually contain no malicious link.
• Vishing (voice phishing): A method that tries to extract information or transaction approval from the victim over the phone, for example by posing as the IT support team or a bank employee.
• Smishing (SMS phishing): Attacks that direct the user to a malicious link with fake shipping, bank or campaign notifications sent via text message.
• Physical attacks: Real-world techniques such as following someone through a door as if authorized (tailgating) or leaving malware-laden USB sticks in the office environment (USB drop).
• Pretexting: The technique of gaining the victim's trust by constructing a convincing scenario and false identity, then using that trust to leak information. This construct underlies most attacks.

The psychology of persuasion: the attacker's real weapon

Social engineering attacks exploit deep-rooted psychological tendencies in human behavior. The levers attackers use most often are:

• Authority: People tend to carry out requests they believe come from a senior manager or an official institution without questioning.
• Urgency: Pressure phrases such as "immediately," "within today," "last chance" prevent the victim from stopping to think and verify.
• Scarcity: The sense of a limited opportunity or something to be lost triggers fast, careless decision-making.
• Trust: A familiar brand, a known colleague or a helpful tone lowers the victim's defenses.

These principles are not independent of one another. A successful attack usually uses several at once. In the opening BEC scenario, authority (the CFO), urgency (within today) and trust (the real signature block) all came into play together.

The new threat rising with AI and deepfakes

Artificial intelligence is changing the rules of the game in social engineering. Generative AI tools eliminate the traditional "phishing tells" such as poor grammar or odd phrasing. Flawless, fluent and target-tailored text can now be produced within seconds. Even more worrying are deepfake voice and video technologies. Fake phone calls that mimic a manager's voice or fake identities in live video conferences turn even the "I saw it with my own eyes, I heard it with my own ears" trust into a weapon. This means verification can no longer rely on a single channel (I recognized the voice, I saw the face).

Why training alone is not enough

Many organizations see social engineering as a box to be ticked by running an awareness training. But a presentation watched once a year does not permanently change the reflexes in the moment of a real attack. There is a big gap between knowledge and behavior: even though employees "know" what phishing is, they can still fall for a well-crafted attack. What's more, human behavior is never a 100% reliable control. Even the best-trained team can make a mistake on a tired, distracted or pressured day. That is why training is necessary but not sufficient on its own. It must be wrapped in layers of continuous reinforcement, measurement and technical support.

Layered defense: the way to strengthen the human

An effective defense does not place the entire responsibility on the employee's shoulders. It builds layers that support the human and limit the impact of their mistake:

1. The technical control layer: Preventing email spoofing with SPF, DKIM and DMARC, advanced email filtering, MFA and the principle of least privilege. This layer reduces the number of attacks reaching the employee and the possible impact of a successful deception.
2. The process layer: Second-channel verification (call-back) for money transfers and sensitive data requests, dual approval and clear escalation paths. A good process neutralizes the "urgent" pressure.
3. The human layer: Regular, role-based training alongside controlled simulations. Realistic phishing, vishing and physical-intrusion simulations let the employee experience a real attack in a safe environment. They turn theoretical knowledge into a lasting reflex.

The purpose of simulations is not to "catch" and punish the employee. The purpose is to measure the real weak points in the organization, target training based on this data and strengthen the reporting culture. An employee who spots and reports an attack is an alarm sensor. This behavior should be appreciated, not punished. This is exactly the turning point where the employee transforms from the "weakest link" into the "human firewall."

Quick checklist

• Has second-channel verification (call-back) been made a mandatory process for money transfers and sensitive data requests?
• Are SPF, DKIM and DMARC records correctly configured on your email domain?
• Is multi-factor authentication (MFA) active on all critical systems and remote access?
• Are regular, role-based awareness trainings delivered to employees?
• Are realistic phishing and vishing simulations run at least a few times a year?
• Is there an easy, non-punitive reporting mechanism for reporting suspicious emails and calls?
• Against deepfakes and voice fraud, are multi-channel verification rules defined so that a "familiar voice/face" is not considered sufficient on its own?
• Is physical security (tailgating, visitor management, a policy against stray USB sticks) included in your attack scenarios?

The Raze approach

At Raze Security we approach social engineering not as a one-off test or an awareness presentation but as a measurable, continuous program. With realistic phishing campaigns, targeted spear phishing, phone-based vishing and physical-intrusion scenarios, we measure your organization's real resilience in a safe environment. We report the results with concrete metrics and target training based on this data. Our goal is not to blame your employees but to transform them into your organization's strongest defensive layer.

To measure and strengthen the resilience of your organization's human layer, explore our social engineering testing service, or get in touch with us whenever you wish.

Most organizations that move to cloud infrastructure think they have largely handed security over to the cloud provider. In reality the opposite is true: the overwhelming majority of breaches on AWS, Azure and GCP stem not from a vulnerability in the provider's infrastructure but from a misconfiguration on the customer's own side. A forgotten public storage bucket, an over-broad IAM permission or a disabled log service. None of these requires an "exploit" in the classic sense. The attacker simply walks through the door already left open.

In this article we clarify the shared responsibility model and walk through the misconfigurations we encounter most often across the three major cloud providers, the risk they create and practical defenses. Our audience is cloud and DevOps teams and security managers.

The shared responsibility model: a misunderstood contract

All three providers apply a shared responsibility model. Roughly summarized: the provider is responsible for the security of the cloud (the physical data center, the hypervisor, the network backbone, the infrastructure of managed services). The customer is responsible for security in the cloud (identity and access management, data classification and encryption, network rules, operating-system patches, application security).

The responsibility boundary shifts by service type. In the IaaS model (for example EC2, Azure VM, GCE) the OS patching, network rules and access are entirely yours. In the PaaS and SaaS models the provider takes on more, but your data, your identity configuration and your access policies are always your responsibility. Not knowing this boundary is the most common cause of breaches.

1. Public storage buckets

This is the most classic and most-headlined mistake. An Amazon S3 bucket, Azure Blob Storage container or Google Cloud Storage bucket configured with the wrong permissions can be exposed to the entire internet without authentication. Backups, customer data, logs and even secret keys leak this way.

• Risk: Anonymous read/write access from the internet. Data breach, ransom and brand-reputation loss.
• Defense: Enable S3 Block Public Access account-wide on AWS. Disable the anonymous public access option on the storage account in Azure. Apply uniform bucket-level access and public access prevention in GCS. Always grant access on an IAM/SAS basis with least privilege.

2. Over-broad IAM permissions and long-lived keys

Identity is the new perimeter of the cloud. Fully privileged policies like *:*, service accounts with more permissions than needed, and long-lived access keys that are never rotated turn a single leak into a takeover of the entire environment.

• Risk: Privilege escalation and lateral movement from a single leaked key. Takeover of the whole account.
• Defense: Apply the principle of least privilege. Use IAM Roles and temporary STS credentials instead of static keys on AWS, Workload Identity Federation on GCP, and Managed Identity on Azure. Detect and remove unused permissions with AWS Access Analyzer / IAM Access Advisor, and rotate keys regularly.

3. Open security groups and management ports

Opening network rules to the entire internet with 0.0.0.0/0, especially on the SSH (22) and RDP (3389) ports, is an invitation to brute-force and automated scanning attacks. AWS Security Groups, Azure Network Security Groups and GCP firewall rules are most often left loose this way.

• Risk: Continuous brute-force on open management ports. Direct data leakage when database ports (3306, 5432, 27017) are left open to the internet.
• Defense: Put management access behind a bastion host, AWS Systems Manager Session Manager, Azure Bastion or an identity-based zero-trust network layer. Narrow the source IPs and keep databases only in private subnets.

4. Encryption and logging gaps

Two controls are often neglected together. On the encryption side, data is left exposed at rest or in transit. On the logging side, no records are kept that would see the events.

• Encryption defense: Make KMS-based encryption the default for data at rest (AWS KMS, Azure Key Vault, Google Cloud KMS). Enforce TLS in transit. On S3 reject HTTP with the aws:SecureTransport condition.
• Logging defense: CloudTrail in all regions on AWS, Activity Log and Microsoft Defender for Cloud on Azure, and Cloud Audit Logs on GCP must be enabled. Collect logs in a separate, immutable account and set alarms for anomalies. You cannot respond to an event you cannot see.

5. Privileged accounts without MFA

Protecting root or global administrator accounts with a password alone is a serious risk. The AWS root user, the Azure Global Administrator and the GCP Organization Admin accounts can be taken over with a single credential leak.

• Risk: Unlimited access over the entire tenant/account that is hard to reverse.
• Defense: Make MFA mandatory on all privileged accounts. Preferably a hardware/FIDO2 key. Never use the AWS root user for daily work. On Azure, grant elevated privileges just-in-time with Conditional Access and Privileged Identity Management.

6. Unprotected metadata service and management panels

If an application has an SSRF (Server-Side Request Forgery) vulnerability, the attacker can reach the instance metadata service (IMDS) and steal temporary credentials. This was also the core mechanism of a large-scale cloud breach in the past. Similarly, panels such as the Kubernetes dashboard or database management interfaces become a direct entry door when left exposed to the internet.

• Risk: Credential theft via SSRF. Direct takeover from open management panels.
• Defense: Enforce IMDSv2 (session-based, token-required) on all instances in AWS. Restrict access to GCP and Azure metadata endpoints at the application level. Never expose management panels publicly. Put them behind a VPN/bastion.

7. Unpatched and publicly exposed managed services

Managed databases (RDS, Azure SQL, Cloud SQL), Elasticsearch/OpenSearch clusters and container images enlarge the attack surface when not kept up to date with patches and on a private network. Being "managed" does not take the configuration responsibility away from you.

• Risk: Exploitation of known CVEs. Mass data leakage from internet-exposed clusters.
• Defense: Enable automatic patch windows, disable public access, and use private endpoints (private endpoint / VPC peering). On the container side, apply image scanning and a current base-image policy.

CSPM and process: not one-off but continuous

Even if these misconfigurations are fixed by hand once, in fast-changing cloud environments new ones constantly arise. This is where CSPM (Cloud Security Posture Management) comes in: it continuously scans the environment against standards (such as the CIS Benchmark) and reports deviations. AWS Security Hub, Azure Defender for Cloud and GCP Security Command Center provide this function natively.

Likewise, if infrastructure is defined as code (Terraform, CloudFormation, Bicep), shift security left before deployment: catch misconfigurations as early as the CI/CD stage with IaC scanning tools (Checkov, tfsec, Trivy). Stopping a mistake before it reaches production is the cheapest defense.

Quick checklist

• Block public storage access account-wide (Block Public Access / public access prevention).
• Apply least privilege. Replace static keys with role/federation-based temporary credentials.
• Close SSH/RDP and database ports to the internet. Put management access behind a bastion/zero-trust.
• Make encryption default and mandatory for all data at rest and in transit.
• Enable CloudTrail / Activity Log / Cloud Audit Logs in all regions and store them immutably.
• Enforce MFA, preferably with FIDO2, on all root and admin accounts.
• Enforce IMDSv2 on AWS. Do not expose management panels publicly.
• Enable automatic patching on managed services, use private endpoints. Scan IaC and containers in CI/CD.

The Raze approach

At Raze Security we treat cloud security not as a product but as a continuous discipline. Through configuration auditing, least-privilege design, review of the identity and network architecture and the setup of CSPM processes, we permanently reduce risks stemming from misconfiguration. In the assessments we conduct from an attacker's perspective, we find the doors left open before you notice them.

To assess the security posture of your AWS, Azure and GCP environment end to end, explore our cloud and container security service, or get in touch with us to discuss your needs.

The financial sector is among the most attractive targets in the eyes of cybercriminals. The reason is simple but brutal: a breach of a bank or fintech means, for the attacker, direct access to money, to the payment infrastructure, and to the identity and financial data of millions of people. In other sectors a data leak is a reputational problem. In finance the same event comes back immediately as a fraud chain, a regulatory sanction and operational disruption. In this article we walk through the threat landscape facing banks and fintechs, the Turkish and international regulatory framework, and the critical role of continuous security testing in this equation.

Why is finance the number-one target?

Attackers act according to return on investment, and the financial sector holds two valuable assets under one roof: money and data. While the stolen customer list of an e-commerce site loses value on the black market, stolen bank account credentials can be turned into cash instantly. What's more, financial institutions operate in a heavily digitalized, interconnected ecosystem dependent on third parties.

This widens the attack surface: mobile banking applications, internet branches, APIs, payment gateways, ATM networks, call centers and countless supplier integrations. Every connection point is a potential entry door for an attacker. In addition, financial services are expected to be uninterrupted, since even a one-hour outage causes serious financial and reputational loss, attackers use this pressure as a lever (especially in ransom and DDoS scenarios).

The threat landscape: what are you fighting?

Threats against the financial sector are not uniform. They spread across a broad spectrum, from financially motivated organized groups to advanced persistent threat (APT) actors. The prominent headlines are:

• Account takeover (ATO): Taking over customer accounts with techniques such as stolen credentials, credential stuffing and SIM swap. Weak or bypassable multi-factor authentication (MFA) makes these attacks easier.
• Phishing and BEC: Deceiving employees or customers with targeted phishing and Business Email Compromise. Fake transfer instructions are one of the vectors that produce the most expensive outcomes.
• Fraud: Abuse of real-time payment systems (for example instant transfers), authorized payment fraud steered by social engineering.
• API and open banking risks: Broken object level authorization (BOLA/IDOR), weak authentication and excessive data exposure.
• Third party and supply chain: Indirect access through payment providers, KYC services and software dependencies.
• Ransomware: Double extortion with the threat of exfiltration alongside data encryption. It directly targets operational continuity.
• DDoS: Making internet branches and payment services unavailable to both damage reputation and screen other attacks.
• ATM and payment systems: Card skimming, ATM malware and attacks on the POS/payment-switch layer.

Open banking and API security: the new front

The open banking model makes it possible to share financial data with third-party providers over APIs, with the customer's consent. While this is a powerful lever for innovation, it opens a new front from a security standpoint. APIs are now the largest attack surface of many financial institutions, and classic web application defenses alone are not enough to protect this layer.

Among the most common problems are broken object and function level authorization (a user being able to access another customer's resource), weak token management, brute-force and enumeration attacks made possible by a lack of rate limiting, and undocumented "shadow" API endpoints. Since the API integrations of banking and payment services in Türkiye are subject to a regulatory framework, these endpoints must be tested regularly for both security and compliance. API-focused threat modeling and validating the authorization logic separately at every endpoint are no longer optional.

The regulatory framework: BDDK, SWIFT, PCI DSS and KVKK

The financial sector is perhaps the most heavily regulated field. The main frameworks to comply with in Türkiye and internationally are:

• BDDK Information Systems Audit: The Banking Regulation and Supervision Agency regulates the information systems and electronic banking services of banks and related institutions. Under the communiqué on the management of information systems, independent audit, penetration testing and vulnerability management processes are expected.
• SWIFT CSP: The SWIFT Customer Security Programme defines mandatory and advisory controls (the CSCF) for institutions connected to the SWIFT network and requires an annual self-assessment/independent verification.
• PCI DSS: The Payment Card Industry Data Security Standard, applicable to every organization that processes, stores or transmits cardholder data. It requires regular vulnerability scanning and penetration testing.
• KVKK: Law No. 6698 on the Protection of Personal Data mandates technical and administrative measures for the processing and security of personal data. There is an obligation to notify the Board of data breaches.

These frameworks are not independent of one another. A well-designed security program should be set up so that a single set of controls meets multiple obligations. Compliance is not a finish line but a state that must be continuously maintained.

From compliance to cyber resilience

Meeting the checklists of regulatory requirements is necessary but not sufficient. The goal of modern financial institutions should be cyber resilience: the ability to keep critical services running when an attack occurs, to detect and contain it quickly, and to return to normal within an acceptable time. This approach abandons the assumption that "there will be no breach" and puts the question "when there is a breach, how long can we hold out?" at the center.

Operational continuity is ensured with backup and restore strategies, regular drills of incident response plans, isolation and segmentation for critical systems, and plan Bs against supplier outages. Resilience is not a control but a culture.

Continuous testing, red teaming and vulnerability management

A penetration test done once a year is not enough for a rapidly changing attack surface. Every new release, every new API endpoint and every new integration carries new, unaudited risk. That is why security testing in the financial sector must become a continuous discipline:

• Vulnerability management: A continuous cycle of scanning, prioritization and remediation. Ranking findings by business risk.
• Continuous penetration testing: Tests with manual depth, triggered by significant changes.
• Red teaming: Testing detection and response (blue team) capabilities in the field by mimicking real attacker behavior. Assessing people, process and technology holistically, beyond technical flaws.
• Social engineering tests: Measuring the human factor against phishing and BEC scenarios.

Quick checklist

1. Apply robust, bypass-resistant MFA on customer and admin accounts. Test ATO scenarios regularly.
2. Inventory all API endpoints. Detect "shadow" and undocumented endpoints and validate the authorization logic at every endpoint.
3. Map the BDDK, SWIFT CSP, PCI DSS and KVKK requirements onto a single control framework.
4. Assess third-party and supply chain risks regularly, from contract to technical audit.
5. Keep isolated, tested backups and restore drills against ransomware.
6. Have a DDoS mitigation and capacity plan ready for internet branches and payment services.
7. Test the incident response plan with tabletop exercises at least once a year.
8. Support penetration testing not as a one-off but with continuous vulnerability management and periodic red teaming.

The Raze approach

At Raze Security we know that the financial sector must manage both regulatory pressure and advanced threat actors at the same time. With our TSE Level-A approved team, by bringing together penetration testing, source code analysis, red teaming, vulnerability management, DDoS testing and social engineering tests, we offer banks and fintechs a holistic program that both maintains compliance and increases resilience against real-world attacks. Our goal, beyond ticking the checklist, is to concretely strengthen your organization's capacity to stay standing in the moment of an attack.

To assess your finance-specific needs, explore our financial services solution, or get in touch with us to address your organization's threat landscape together.