Logisek

Your application runs in the cloud. Which security controls are actually being assessed?

The environment includes managed databases, cloud storage, application services, service identities and several integrations.

The cloud provider operates parts of the underlying platform.

Your organization configures and uses the services.

The exact division of responsibility depends on the service, but the assessment still needs a clear understanding of the controls relevant to your deployment.

A pe*******on test against the public application may provide valuable evidence about that application.

It may leave other important questions unanswered.

For example:

- How are permissions assigned to users and service identities?
- Which storage resources are accessible, and to whom?
- How are development and production environments separated?
- How are secrets handled?
- Which security events are available for investigation?

Some questions are best addressed through application testing. Others may require an agreed configuration review, architecture review or a combination of assessment methods.

That should be discussed before the scope is finalized.

Cloud security assessment is a broad description. Clients should understand the accounts, subscriptions, projects, services and control areas included in the work.

They should also understand what access the assessors need and how missing access will affect coverage.

At Logisek, these are important questions to bring into the scoping discussion.

The assessment method should fit the security question you need answered and the controls your organization actually manages.

An infrastructure assessment should help you understand how your environment is connected.

Your organization has:

- Employee workstations,
- Business application servers,
- Centralized identity services,
- Administrative systems,
- Separate network segments,
- External access provided to selected partners.

An assessment identifies several vulnerabilities and configuration weaknesses.

The next question is what those findings mean within that environment.

Which systems support critical operations? Where are privileged accounts used? Which network boundaries are intended to restrict access? What assumptions exist about trusted devices and users?

A weakness on an isolated test system may have different consequences from the same weakness on a system supporting an important business service.

Similarly, the significance of a configuration issue can depend on the access it provides and the controls surrounding it.

Meaningful infrastructure pe*******on testing requires enough context to assess these relationships within the authorized scope.

Before the engagement, discuss:

- The starting access assumed for the assessment,
- The identities and systems included,
- The segmentation boundaries that matter,
- The business services requiring particular attention,
- The limitations on validating potential impact.

The report should distinguish relationships demonstrated during testing from those inferred or left unassessed.

That distinction allows the client to understand both the evidence and the remaining uncertainty.

An asset list is useful for defining scope. Understanding the environment also requires examining relevant connections between those assets.

Cybercrime is borderless, and effective disruption increasingly depends on international cooperation.

The Hellenic Police Cybercrime Directorate participated in the international "KillSwitch" operation, which targeted the KillSec cybercrime group. The coordinated action resulted in arrests and searches across multiple countries, the seizure of infrastructure and encrypted data, and the disruption of systems used to support extortion activity.

The case highlights an important aspect of modern cyber defence: addressing organized cybercrime requires not only strong technical capabilities, but also cross-border coordination, intelligence sharing and coordinated law-enforcement action.

A business process can behave exactly as implemented and still create a security problem.

Consider an application that manages purchasing, approvals, refunds or customer onboarding.

The application may use current software components, validate common input formats and protect its communications correctly.

But who defines whether the business process itself is secure?

That question becomes important when the application includes:

- Different levels of approval,
- Transaction limits,
- Changes in account status,
- Several stages in a workflow,
- Actions that should require independent authorization.

BusinessLogic testing requires an understanding of what the application is supposed to allow and which conditions must remain true throughout a process.

For example, a sensitive business action may require approval from a different authorized person.

The security requirement extends beyond whether both accounts can log in successfully. The assessment needs to consider whether the application consistently maintains the intended separation of responsibilities.

Tools can support the work, but meaningful interpretation requires knowledge of the business rules.

That knowledge often comes from discussions with application owners, developers and the people who use the system.

Before commissioning an application pe*******on test, ask:

- Will the assessment include a walkthrough of important workflows?
- Who can explain the expected business rules?
- Which actions carry financial or operational consequences?
- How will the testing approach account for those consequences?

At Logisek, understanding an application’s intended behavior is part of understanding its security.

A technically valid transaction can still be an unauthorized business action. The assessment needs enough context to recognize the difference.

Cybersecurity incidents often start with a simple email, message or phone call.

A recent ENISA survey found that 74% of employees had received suspicious communications, while 39% reported phishing attempts. At the same time, 85% said they would like to improve their cybersecurity skills.

The message is clear: technology alone is not enough. Strong cyber resilience also depends on continuous awareness, practical training and employees who know how to recognize and respond to threats.

October marks European Cybersecurity Month, and it is a good reminder that the cybersecurity landscape is changing just as quickly as the technologies businesses depend on.

Artificial intelligence is already reshaping cybersecurity on both sides. It enables faster detection and analysis of suspicious activity, but it also gives attackers new ways to automate social engineering, generate convincing deepfakes and scale attacks more efficiently.

At the same time, software supply-chain risk continues to grow. Organizations increasingly rely on third-party software, APIs and interconnected suppliers, meaning that weaknesses outside the traditional perimeter can have a direct impact on security.

Looking further ahead, quantum computing is also becoming part of the cybersecurity conversation. While practical large-scale quantum attacks are not an immediate reality, organizations need to start considering long-term cryptographic resilience and the transition towards post-quantum cryptography.

Geopolitical developments add another layer of complexity, particularly for organizations operating critical infrastructure and essential services, where cyber resilience, business continuity and incident response are closely connected.

Cybersecurity is no longer only about defending individual systems. It is about continuously adapting to an environment where technology, supply chains and threat actors are evolving at the same time.

One compromised workstation. How far could an attacker go?

At Logisek, our assumed breach assessments test whether an initial foothold can lead to elevated privileges, lateral movement, and access to critical systems or sensitive data.

Your internal controls should limit the impact of a compromise. Put them to the test.

An application can authenticate every user correctly and still expose information to the wrong people.

You are planning a grey-box web application pe*******on test.

The application includes:

- Several user roles,
- Multiple customer organizations,
- Administrative and support functions,
- Records owned by different users,
- Workflows involving different levels of approval.

The login process works correctly. Multi-factor authentication is enabled. Sessions expire as expected.

Those are important controls.

But they answer only part of the security question.

Authentication establishes who a user is. Authorization determines what that user is allowed to access, change or approve.

Meaningful authorization testing requires an understanding of the relationships between users, roles, organizations, records and business functions.

Two users with the same role may still require complete separation because they belong to different customers.

A support account may legitimately access certain information while remaining restricted from changing business-critical settings.

A user’s permissions may also change as a transaction moves through different stages.

These relationships need to be reflected in the assessment.

Before testing begins, it is worth asking:

- Which roles and account relationships will be available?
- Are customer and organizational boundaries included?
- Have the expected permissions been documented?
- Will important business workflows be accessible?
- How will gaps in access affect the conclusions?

An assessment performed with one account may provide useful findings. Its conclusions must reflect the access and relationships actually examined.

When you read the final report, can you understand which authorization boundaries were assessed?

"Authenticated testing" should come with a clear explanation of whose access was tested, against which boundaries, and with what limitations.

What happens when an application is not ready for its scheduled pe*******on test?

The scope and estimated testing effort have been agreed. The engagement has a planned start date, an end date and a report delivery date.

When the work begins, however:

- The environment is unavailable or unstable,
- Required accounts cannot access the functionality in scope,
- Application errors prevent important workflows from completing,
- A necessary service or integration is not functioning.

Testing cannot proceed as planned. What happens to the agreed coverage and the reserved testing window?

At Logisek, we inform the client promptly. We explain what is preventing progress, which parts of the assessment are affected and what needs attention.

We also help with troubleshooting where needed, working with the client and the relevant technical teams so that meaningful testing can proceed.

The distinction between estimated testing effort and elapsed calendar time matters here. A period during which the environment cannot be tested does not provide the coverage that the agreed testing effort was intended to deliver.

Crucially, when these blockers prevent completion of the agreed work, we coordinate with the client to move or extend the predefined testing window. The reporting schedule is adjusted accordingly.

We do not treat the original booking as a "use it or lose it" opportunity.

Affected functionality is not quietly skipped, and the engagement is not considered complete simply because the original end date has arrived.

The client should understand what remains to be tested, what needs to be resolved and how the revised schedule supports completion of the agreed scope.

Readiness matters. So does the way a testing partner responds when the project encounters difficulties.

Our priority is to complete a suitable assessment across the agreed scope and give the client useful, well-supported results.

A schedule should help organize the work. Reaching its original end date does not establish that the work has been completed.

You are planning a grey-box web or a mobile application pe*******on test for a new application, or a major new version introducing new features and changes across the application.

The application has:

- 200+ API endpoints
- Potentially twice as many web forms, functions and user interactions
- Mobile application available on both Android and iOS, requiring platform-specific testing of the application itself, not only the backend APIs
- Multiple roles, workflows, authorization paths and business processes

The proposed effort is 5-7 days.

If the agreed scope is a full end-to-end pe*******on test of the new application or the new version as a whole, that level of effort is simply not sufficient to provide meaningful coverage across an application of this size and complexity.

And that should raise an important question: What level of end-to-end coverage can realistically be achieved in 5-7 days?

Meaningful application pe*******on testing is not simply about running tools against 200 endpoints.

It means understanding authentication and authorization models, testing different roles, exercising business workflows, validating API functionality, exploring abuse cases, testing input and file-handling mechanisms, and looking for ways individual weaknesses can be combined into realistic attack paths.

This becomes even more important when assessing a new application or a major release, where new features, modified workflows and changes across different application components can introduce new security assumptions and attack paths.

There is always a balance between time, budget, depth and coverage. The important thing is to understand that balance before the assessment starts.

A pe*******on test should not only answer: "Were vulnerabilities found?"

It should also answer: "How much of the application was actually tested, and how deeply?"

So before choosing a provider, it is worth asking:

- Did you actually discuss the testing approach, methodology, scope and expected coverage?
- Or did the decision ultimately come down to who offered the lowest price?

Because completing a pe*******on test and achieving meaningful end-to-end security assurance are not necessarily the same thing.