Most organizations know which systems need to be publicly accessible. A website, VPN, customer portal or another business service usually has a clear reason for being reachable from the internet. The bigger problem can be systems that nobody remembers are still accessible.

Infrastructure changes over time. A new server is deployed, a supplier is given remote access, a test environment is made available or external administration is temporarily enabled. The application is later migrated, the supplier changes or the project ends, but part of the old configuration remains. After several years, what an organization believes it has exposed to the internet and what is actually accessible may no longer be the same.

Temporary access can easily become permanent

It does not have to be a server that someone forgot about ten years ago. An administrative interface for a network device, an old VPN service, a test application or remote access that was supposed to be temporary is enough. These systems are often not part of day-to-day operations, so they can remain outside the organization’s focus for a long time. Someone uses the production application every day, while an old service can remain accessible without anyone noticing. Being accessible from the internet is not a security vulnerability by itself. Many services must be publicly available for the business to operate. What matters is whether a particular service still needs to be accessible, whether it is still being used and whether it is securely configured. A VPN that an organization uses every day has a valid reason to be exposed. An administrative interface left open after a supplier intervention probably does not.

Documentation and reality are not always the same

The same applies to test environments. A production application may be regularly maintained while an old test instance remains available on a subdomain long after a project has ended. An organization may keep its servers updated but overlook a network device that has been running for years without significant changes. From the perspective of someone looking for systems from the outside, it does not matter whether something appears in the official IT asset inventory. What matters is whether it can be reached. Even a well-maintained inventory may therefore differ from the actual environment. Documentation can lag behind changes, temporary configurations can remain active and systems that are no longer used can continue operating. These differences between documented and actual exposure are easy to miss until someone has a reason to examine them more closely.

A list of vulnerabilities is not enough

A vulnerability assessment should not end with a list of software versions and detected CVEs. A finding needs to be considered together with the exposure and role of the system on which it was identified. The same vulnerability on an internet-facing system and on a system that is accessible only from a restricted part of the internal network does not necessarily have the same priority for the organization. The same applies to the results of automated tools. A scanner may report a large number of potential vulnerabilities, but that does not mean every finding actually applies to the system or that every finding is equally important. The result may depend on the detected software version, configuration or assumptions that the tool cannot independently verify. Some findings therefore need additional validation before it is possible to determine whether a vulnerability is actually present and how much risk it represents.

Without that analysis, it is easy to fall into a cycle where scanner output becomes the entire remediation plan. The organization fixes what was reported, runs the scanner again and receives another list. The same process then starts again. A new list does not by itself show that the environment is now significantly more secure or that the most important problems were addressed first. Vulnerability management is not an attempt to make every scan return an empty result. It requires distinguishing real and applicable findings from technical noise and deciding what should actually be remediated first.

A system also does not need to contain a known critical vulnerability to present a security problem. An unnecessarily exposed service, an insecure configuration or access that should have been removed long ago can be just as relevant to the security of the environment. This is why an independent security assessment needs to answer more than what a scanner found. It should determine what is actually exposed, validate relevant findings and assess their significance in the context of the specific environment.

AresISEC, through its Vulnerability Assessment service, reviews systems, applications and infrastructure to identify security weaknesses and assess them in the context of the actual environment. The goal is not to produce the longest possible list of findings, but to determine which issues represent relevant risk and what should be addressed first.

Verify what you think you know

A useful first step can be a simple internal review. Compare the systems you believe are accessible from the internet with what is actually exposed. Check for test environments, legacy systems, supplier access and configurations that were originally intended to be temporary. If you cannot clearly explain why a particular system or service is accessible from the internet, it is worth checking whether it still needs to be.

The problem is not a service that needs to be accessible from the internet. The problem is the one nobody can explain why it is still there.

Sources:

• CISA – Internet Exposure Reduction Guidance
• NCSC – Carry out assessments by triaging and prioritising
• NCSC – Vulnerability management

When an organization starts looking more closely at how ready it really is for NIS2, the initial picture often looks quite good. There is a firewall, backups run regularly, MFA is enabled, employees receive security training, and everyone knows who to call if an incident occurs. Most of these measures were not introduced because of NIS2. They became part of normal operations over the years, and that is a good starting point.

The problem appears when the question changes from “do you have it?” to “how is it actually implemented?”. NIS2 does not reduce cybersecurity risk management to owning certain security products or having a few written procedures. It covers areas such as incident handling, business continuity and recovery, supply chain security, vulnerability management, access control, training, and assessment of the effectiveness of security measures. Two organizations may therefore tick almost every box on a basic checklist while having very different levels of readiness in practice.

Take MFA as an example. A company uses it for Microsoft 365 and VPN access, so it can quite reasonably say that multi-factor authentication is in place. But what about administrative accounts? Are there legacy systems that do not support it? Are there exceptions, and is it clear why they exist? If a compromised administrative account can still provide access to an important part of the infrastructure without an additional verification step, simply saying that the organization “has MFA” does not tell us enough about the actual risk.

Something similar happens with vulnerabilities. An organization may run a vulnerability scanner every month and keep the resulting reports. What matters much more is what happens afterwards. If the same serious finding appears for six months because nobody has assigned an owner, deadline, or remediation path, scanning exists, but the vulnerability management process clearly has a gap. Sometimes an issue cannot be fixed immediately, and that is a reality in any IT environment. In that case, the organization should understand the remaining risk, whether it can be reduced temporarily, and who made the decision to accept it.

Suppliers are another area where the real situation can easily become unclear. An organization knows who maintains its infrastructure, where its systems are hosted, and which cloud or SaaS services it uses, but that does not necessarily mean it has a good overview of supplier access and the dependencies that have developed over time. An external IT provider may have administrative accounts, an application vendor may have remote access to production, and a business-critical system may depend on a service outside the organization’s direct control. If that supplier suffers a security incident, the question is no longer only how secure the supplier is, but what their incident could mean for your own operations.

With incidents, the difference between assumed and actual readiness usually becomes visible even faster. In a smaller organization, everyone may know who to call when something goes wrong. That can work perfectly well for minor problems. During a serious incident, however, someone suddenly has to decide what to isolate, which systems need to remain available, what information must be preserved, who leads the technical response, who communicates with management, and whether the incident needs to be reported. If everything depends on one person who “knows how things work”, the plan effectively exists only while that person is available.

A backup alone does not tell you how prepared the organization is for recovery either. It may run every night for months without an error while nobody knows how long an actual recovery would take. The database may be recoverable, but the application could depend on another service that was never included in the plan. All the data may be available, but nobody has decided what needs to be restored first. Only when these questions are tested can an organization start talking about actual recovery capability rather than simply having backups.

This is why evidence in NIS2 readiness is useful for more than a future review or self-assessment. It gives the organization a much more practical answer to whether its security measures work as expected. A recovery test result tells you more than simply stating that backups exist. Records of privileged account reviews show that access is actually being reviewed. Closed vulnerability findings show that scanning leads to remediation rather than a PDF report being stored in a folder. There is no need to invent new NIS2 documentation if the appropriate evidence already exists as part of everyday operations.

The Croatian NIS2 framework also distinguishes between the documentation of security measures and their actual implementation. This matters because an organization may have a well-written procedure that nobody follows in practice, while the opposite can also be true. A security practice may have worked well for years but remain insufficiently formalized or documented. A GAP assessment should distinguish between these situations rather than treating all of them as the same “missing” requirement.

With an AresISEC NIS2 GAP Readiness Assessment, we therefore do not look only at whether a particular policy, procedure, or security technology exists. We examine how the measure is actually implemented and what can be confirmed from the available information and evidence. The objective is not to issue a certificate or provide a legal opinion that an organization is “NIS2 compliant”, but to establish a realistic picture of the current state and identify where there is a difference between what the organization considers resolved and what is actually in place.

It makes sense to perform this type of review before a formal self-assessment or another review, while there is still time to address the gaps that are found. The result does not have to be ten new policies and another security product. Sometimes an existing process needs to be improved, a technical weakness needs to be addressed, responsibility needs to be clearly assigned, or something that has been taken for granted for years finally needs to be tested.

That is why NIS2 preparation is more useful when it starts with the actual environment rather than a checklist. The question is not only whether you have a particular security measure. The question is whether you can show how it is implemented and whether it works when you actually need it.

Sources:

European Union – Directive (EU) 2022/2555 (NIS2 Directive)

Narodne novine – Croatian Cybersecurity Act, NN 14/2024

Narodne novine – Croatian Cybersecurity Regulation, NN 135/2024

If you ask most organizations today how they protect themselves from ransomware, you will often hear the same answer.

“We have backups.”

A few years ago, that was enough in many cases. Attackers encrypted the servers, the organization restored its data from backup, and business continued. Today, things are different.

Ransomware groups have long realized that the ability to recover is the biggest obstacle to a successful ransom demand, and backup is the most important part of that process. If an organization can restore its systems within a few hours, the incentive to pay quickly disappears. That is why modern attacks no longer focus only on production systems. They increasingly target backup infrastructure as well. Attackers are not just trying to encrypt your data. They are trying to take away your ability to recover it.

That is why the question is no longer whether you have backups. The real question is whether your backups can survive the attack. Many organizations only discover the difference when it is already too late. One of the most common scenarios starts in a very ordinary way. An attacker compromises a user account, expands access across the network, and eventually gains administrative privileges. From that point, user workstations are no longer the priority. The focus shifts to Active Directory, virtualization platforms, backup servers, and backup repositories. If the backup environment uses the same domain, the same administrative accounts, or sits on the same network as production systems, there is a good chance it will become part of the same incident.

At that point, the backup still exists. It is simply no longer available. In practice, this is often the difference between an incident that lasts a few hours and one that continues for days or even weeks. It is no longer unusual for attackers to spend days exploring an environment before launching ransomware. They want to understand how the network is built, where backup systems are located, whether administrators use the same credentials across the infrastructure, and whether backup copies can be deleted or encrypted. If they find those answers before launching the attack, the organization’s ability to recover quickly can disappear almost immediately. At that point, the attackers know that the pressure to pay the ransom has increased significantly. This is why backup isolation has become such an important topic.

Backup isolation is not simply about storing copies on another device or at another location. It means that compromising the production environment should not automatically mean compromising the backup environment as well. That includes separate administrative accounts, restricted network communication, dedicated privileges, multi-factor authentication for administrative access where appropriate, and, whenever possible, immutable backup copies that cannot be easily modified or deleted. The objective is not to make administration more complicated. The objective is to ensure that the last line of defense remains available when everything else has failed.

In practice, AresISEC often sees organizations investing heavily in reliable backup solutions while paying far less attention to protecting the backup infrastructure itself. Backups run successfully, reports show no errors, and everyone assumes recovery is covered. The problem only becomes visible when an attacker can reach the backup environment almost as easily as the administrators. That is not a backup software problem. It is an infrastructure design problem.

A good starting point is not another tool or another software license.  A good starting point is asking a few simple questions.

Could a compromised administrator account delete your backups?

Does the backup environment rely on the same authentication systems as production?

Could an attacker who gains access through a phishing attack eventually reach the backup infrastructure?

When was the last time you tested a full system recovery instead of restoring a single file?

And perhaps the most important question of all: how confident are you that your backups would still be available if the rest of the infrastructure were compromised?

The answers to those questions usually say far more about an organization’s resilience than a list of backup technologies ever will. This is no longer just considered good security practice. It is increasingly becoming a regulatory expectation. ISO 27001 requires organizations to implement appropriate controls for backup, restoration capability, and regular testing to support business continuity. NIS2 goes further by explicitly highlighting backup management, disaster recovery, and operational resilience as part of managing cybersecurity risk. The Cyber Resilience Act reinforces the same direction. Although it is most often discussed in the context of secure software development, its scope is much broader. Organizations developing products with digital elements will need to demonstrate that security has been considered throughout the entire product lifecycle. That includes vulnerability management, security updates, and the ability to recover reliably after a cybersecurity incident. Most provisions of the Cyber Resilience Act will apply from the end of 2027, while certain obligations, including reporting actively exploited vulnerabilities and significant incidents, apply earlier. For many organizations, backup and recovery will no longer be viewed solely as operational IT responsibilities, but also as regulatory requirements.

In the end, ransomware does not test the quality of your backup software. It tests how well your entire infrastructure has been designed. A backup that can be compromised as easily as the production environment is not your last line of defense. It is simply another system that will be lost during the same incident.

Sources:
CISA – Stop Ransomware Guide

ISO – ISO/IEC 27001 Information Security Management

European Union – NIS2 Directive

European Union – Cyber Resilience Act (Regulation (EU) 2024/2847)

Many organizations believe they are protected from ransomware simply because they have backups. On paper, that sounds reasonable. Backup jobs run, storage exists, retention is configured, and every morning someone sees the green status that everything completed successfully. That usually creates a sense of security. Until something actually happens.

The problem is that backup and recovery are not the same thing, even though many people treat them as if they are. Backup answers one question: did we save the data? It does not answer the harder one: can we bring everything back when the whole environment is under pressure? That difference becomes very clear during a serious incident. In many environments, backup is seen as a technical requirement that simply has to exist. The system shows successful backup jobs, administrators see that everything is running, and management assumes recovery is covered. But the real problems usually start when the system actually needs to be restored.

One of the common scenarios seen after ransomware incidents is that backups exist, but they can no longer be trusted. Not because the backup failed, but because the attacker reached it too. If backup infrastructure sits too close to production, uses the same access paths, or depends on the same privileged accounts, it can easily become part of the same incident. At that point, the backup technically still exists. But it no longer helps. Another issue appears when the restore works, but the system still does not. The data comes back, the application starts, but something around it no longer fits. A certificate has expired. A DNS record is missing. An integration points to an old address. The database version no longer matches. On paper, the restore was successful. In reality, the business is still down. This is the part many organizations underestimate. Recovery rarely means simply “bringing back the data”. You have to bring back everything around it too.

Time is another problem that often gets ignored until it becomes real. Restoring several terabytes of data sounds simple until you need to do it under pressure. What looks like a six-hour process on paper can easily turn into two days. And when critical systems are involved, two days are not just downtime. That means lost revenue, lost trust, and growing pressure. This is where chaos usually starts. What do you restore first? Email? Domain controllers? File servers? ERP? Most organizations do not have a clear answer until an incident forces them to decide. And that is usually where the most time gets lost.

In practice, AresISEC often sees organizations with technically healthy backup systems but no realistic understanding of what recovery would actually look like under pressure. The backup itself is usually not the problem. The real issues are access, dependencies, recovery time, and the order in which systems are brought back. That is where the real gap usually appears. A good starting point is not buying another backup solution. A good starting point is asking simple questions. How isolated is your backup from the production environment? Who has access to the backup infrastructure? How often do you test a full restore instead of only recovering single files? How long would it actually take to bring back your most critical systems? And if multiple systems fail at once, does the team know what comes first? These are not complicated questions, but they quickly show whether recovery is real or only assumed.

In many cases, small changes make the biggest difference. Separating backup access from the main environment, reducing privileges, defining recovery priorities, and testing restore processes under realistic conditions often improve resilience more than adding another tool. This also connects directly to broader security and compliance requirements. Under ISO 27001, backup and recovery are not just operational tasks. They are part of business continuity, system availability, and organizational resilience. Controls around backup protection, restoration capability, and regular testing are part of maintaining a functioning information security management system. NIS2 goes a step further. It explicitly requires measures related to backup management, disaster recovery, and crisis handling as part of operational resilience. This means recovery is no longer just a technical recommendation. For many organizations, it is becoming a regulatory expectation. In both cases, it is not enough to simply have backups. The expectation is that recovery is realistic, tested, and capable of supporting business continuity when systems fail. That is where many organizations discover the difference between what exists on paper and what actually works.

Because when things go wrong, the value of backup is not measured by whether it exists. It is measured by how quickly it gets you back to work.

Sources:

CISA – Stop Ransomware Guide

ISO – ISO/IEC 27001 Information Security Management

European Union – NIS2 Directive 

Modern applications and digital products go through more validation than ever before. Code reviews are a standard part of development, automated security checks are often integrated into deployment pipelines, and both functional and security testing are now common parts of the release process.

And yet, products that pass these checks still end up compromised.

The issue is not necessarily that security testing is missing or that development teams ignore security. More often, the problem is that security is still viewed too narrowly. The focus remains on the application or an individual feature, while real attack paths only become visible when the environment is viewed as a whole.

An application may have a secure authentication flow while still exposing excessive information through API responses. It may pass internal security checks while deployment settings expose debug information or internal paths. It may implement proper input validation while relying on integrations or services that unintentionally create additional attack paths.

This is where the difference between code security and product security becomes clear.

One of the patterns regularly seen during testing involves APIs that technically behave correctly but return more information than necessary. An endpoint provides legitimate data for a request, but also exposes internal identifiers, object relationships, or details about how services are connected. From a development perspective, the response is correct. From an attacker’s perspective, it becomes a system mapping tool.

A similar issue appears in authentication flows. Passwords are validated correctly, tokens are handled properly, and sessions behave as expected. But when multiple endpoints are combined, unintended paths begin to appear. One endpoint confirms whether a user exists, another allows excessive authentication attempts, while a third reveals additional account context. Individually, these behaviors may appear acceptable. Together, they form a practical attack path.

Configuration and infrastructure make the situation even more complex. During testing, it is common to see applications with no major issues in the code itself, while the deployment environment exposes internal information, environment variables, references to other services, or unnecessarily exposed administrative functionality.

These issues are not always caused by development mistakes. The problem is that product security does not end with the code.

In practice, AresISEC often sees applications that pass internal security reviews but still expose attack paths that only become visible when the application, its configuration, infrastructure, and usage patterns are evaluated together.

This is why product security is becoming much broader than application testing alone. The shift is increasingly reflected in regulatory requirements as well.

The Cyber Resilience Act gradually introduces security obligations for software and products with digital elements across the European Union. Most requirements will become applicable by the end of 2027, while obligations related to reporting actively exploited vulnerabilities and incidents will apply earlier. The regulation requires a structured approach to product security across the entire lifecycle, including vulnerability management, security updates, documentation, and risk assessment.

For organizations developing or maintaining digital products, security will no longer be only a technical or development concern, but also a regulatory obligation with potentially significant financial penalties. This changes how product security is viewed. Security is no longer just about validating individual components. It becomes a question of how the entire product behaves in a real environment under real conditions.

The key point is not that development teams fail to perform security testing. Most mature teams already do. The issue is that no single type of testing covers every perspective.

Real product security begins when the system is evaluated as a complete environment.

Sources:
European Union – Cyber Resilience Act (Regulation (EU) 2024/2847)

OWASP – Web Security Testing Guide

OWASP – Top 10 Web Application Security Risks

NIST – Technical Guide to Information Security Testing and Assessment (SP 800-115)

In most cases, an attack does not start with exploiting a system. It does not begin with complex tooling or advanced techniques. It starts with access. Most often through a user account that appears completely legitimate. The reason is simple. User accounts remain one of the easiest entry points. A reused password, a convincing phishing email, or a breach of a third party service can be enough. Once an attacker gains access to a user account, the first step does not look like an attack. The login happens through a standard channel. VPN, web application, cloud service. There are no obvious alerts. The activity looks like a normal user session.

At that point, the key question is not how the account was compromised, but what that account can access. In practice, this quickly becomes critical. Access to email can allow password resets for other accounts. Access to SharePoint or Drive exposes internal documents. VPN access provides entry into the internal network. Access to a ticketing system reveals how IT is structured and how issues are handled. This is not a vulnerability. It is normal business functionality. The issue begins when this access is used from an attacker’s perspective.

One of the common scenarios seen during testing starts with something simple. A user account has access to an internal document. That document contains server naming conventions, internal URLs, and references to services. From this, it becomes possible to understand how the environment is structured and identify key systems, including elements of the domain infrastructure. From there, testing becomes targeted. If naming conventions reveal patterns, systems that match those patterns are identified. If internal services are referenced, their exposure and configuration are tested. What started as a simple document becomes a way to move through the environment. Another frequent scenario involves file shares. A user has access to a directory that contains configuration files. One of those files includes a connection string or a reference to another system. At that point, it is no longer just a file. It becomes a path to further access. A third scenario, often the most impactful in practice, involves lateral movement inside the network. A compromised account with VPN access effectively places the attacker inside the internal environment. If segmentation is weak, additional systems can be reached without strong restrictions.

In these situations, it often becomes clear that a single user account has access to more systems than expected. Sometimes this includes services related to authentication or user management. Not because it was intentionally designed that way, but because access tends to accumulate over time and is rarely cleaned up. This is the point where a compromised account stops being just a user account and becomes an entry point into a much larger environment. It is important to note that in all of these scenarios nothing is “broken” in the traditional sense. Access exists, actions are legitimate, and the system behaves as designed. The issue is not that something was bypassed, but that too much is accessible.

In practice, this is exactly where AresISEC most often identifies real exposure. Not through a single critical vulnerability, but by connecting multiple smaller weaknesses that together form a practical attack path. One point that is often overlooked is that the password itself is rarely the problem. The real issue is what that password unlocks. If a single user account provides access to documents, configurations, and internal services without proper control, compromising that account becomes the starting point of a much larger issue. Security cannot be reduced to password strength or multi factor authentication alone. These are important controls, but they do not address structural exposure.

Real security begins with understanding how a system can be used in ways that were never intended.

Sources:
MITRE ATT&CK – Enterprise Matrix
Verizon – Data Breach Investigations Report