®Offensive security / Infrastructure & IaaS pentesting
An infrastructure can consist of individually well-maintained systems and still allow unwanted access paths. Within the approved scope, OTOKO® tests external and internal infrastructure as well as IaaS environments for which the customer is responsible. Identities, configuration and network boundaries are considered together, so that technical observations turn into assessable risks and concrete measures.
Services in detail
Analysis, integration and documented handover
Your brief for OTOKO®
The work packages are derived from your current situation. Your team knows the agreed scope, the required involvement and the results that should be available at handover.
Addresses, systems, accounts and permitted starting points are defined. Production dependencies and excluded components are part of the approval. The test only begins once there is a shared understanding of the permitted scope.
Documented scope and agreed rules of engagement.
The test examines which actions are actually possible from the agreed starting point. Identities and network boundaries are assessed in context. Evidence is limited to the approved scope and to what is necessary for the assessment.
Verifiable findings on reachable systems and permissions.
Cloud accounts, virtual systems and access for which the customer is responsible are tested against the agreed target. Requirements from the platform operator and rights to affected third-party systems must be clarified in advance.
Context-based assessment of the cloud configuration examined.
Technical results are turned into clearly reasoned improvements. Responsibilities and dependencies are factored into the prioritization. A retest examines the agreed changes on the updated version.
Overview of measures and documented verification.
Planning & implementation
A test from the internet answers different questions than a test with a regular internal account. Together, we determine which scenario is to be considered and what permissions exist at the start. The permitted scope is derived from this starting situation. Systems, addresses and identities are documented; shared services and third-party systems require particular attention. This planning ensures that unclear responsibilities do not unintentionally push the investigation beyond the approval granted.
Operating conditions are also part of the preparation. Points of contact, time windows and abort criteria are defined. Changes to systems, load tests or further-reaching measures are not implicitly part of every penetration test. They must explicitly match the agreed procedure. The results then state the actual starting position and the version tested. This makes the results easier to interpret: a vulnerability observed with administrative rights already in place means something different from one demonstrated from an unprivileged starting point.
Network segmentation alone does not describe every possible access route. User accounts, service accounts and administration paths can create other connections between systems. Within the approved framework, the test therefore examines whether technical boundaries and roles actually enforce the intended model. Individual configuration errors are assessed in relation to their impact. A finding is meant to show why it is relevant to your environment and what prerequisites exist for the demonstrated access.
In IaaS environments, the boundary with the provider is an additional factor. Resources and configuration for which the customer is responsible can be the subject of the investigation; this does not automatically approve shared platform services as well. Necessary rights and requirements are clarified before the test. Connected sites and applications can also be affected. Planning therefore brings together those responsible for cloud and infrastructure, so that the test remains transparent and its impact can be controlled within the agreed framework.
The result separates confirmed findings, notes and areas not tested. Evidence describes the necessary prerequisites and the observed impact. It is meant to enable assessment without collecting unnecessarily sensitive data. Management and technical teams receive a suitable presentation; particularly relevant observations are addressed through the agreed reporting channels. This turns a penetration test into more than an export of technical alerts: those responsible can decide which measures to implement first.
Several teams can be involved in remediation, for example identity management, network operations and application support. Recommendations are therefore discussed together with their dependencies. The retest focuses on the changed version as agreed and documents whether the specific finding can still be demonstrated. Success-based payment can be arranged for a suitable, clearly defined target through Result as a Service. The permitted test scope remains binding and is not extended by a financial incentive.
Illustrative project scenario
A company connects internal systems to an IaaS environment. Within the approved scope, required and unwanted access paths from defined roles are tested. Results are prioritized together with those responsible for network and cloud, and retested in a targeted way after changes.
Before you start
The suitable approach is determined based on protection needs and operational risk. Time windows, permitted methods, points of contact and abort criteria are agreed in writing beforehand.
No. Rights to third-party systems and requirements from the platform operator must be clarified separately. Only the explicitly authorized scope is tested.
No. Such procedures require an explicit agreement and suitable preparation. They cannot be inferred from the term pentesting alone.
A report with the scope, confirmed findings, evidence, impact, limitations and prioritized measures. An agreed retest evaluates the specific fixes.
Related services
Infrastructure & IaaS pentesting with OTOKO®
Name the affected systems and the goal of your request. In the first consultation, we jointly define scope, preconditions and the next steps.
Discuss Infrastructure & IaaS pentesting
