Offensive testing in healthcare and financial systems must simulate real attacks without putting patients, transactions, or sensitive data at risk. To accomplish this, the operation must combine an authorized scope, rules of engagement, threat modeling, operational security controls, and reproducible evidence—not merely run scanners or search for isolated vulnerabilities.
Red team, pentesting, and scanning are not the same thing
The type of assessment chosen determines its depth, operational risk, and expected outcome.
- Vulnerability scanning: identifies outdated versions, insecure configurations, and known vulnerabilities. It is fast and repeatable, but it produces false positives and does not prove impact.
- Pentest: tests a defined scope, such as a web application, API, mobile application, or network. The goal is to find and exploit vulnerabilities in a controlled manner.
- Red team: assesses whether people, processes, and technologies can detect and contain an objective-driven attack. It may involve applications, cloud environments, identity, social engineering, and lateral movement.
- Purple team: promotes direct collaboration between offensive and defensive teams. Each technique performed is compared against logs, alerts, and response capabilities.
For critical applications, starting with pentesting and purple team exercises is usually safer than beginning with a broad red team operation. A red team makes sense when the organization already has an asset inventory, monitoring, incident owners, and the ability to stop the exercise.
Why healthcare and finance require specific rules
Both industries hold valuable data and operate processes with little tolerance for downtime. However, the technical impact takes different forms.
Risks in healthcare systems
An exploit can affect medical records, prescriptions, laboratory results, schedules, hospital integrations, and connected devices. In addition to confidentiality, clinical integrity must be protected: changing an identifier, unit of measurement, or association between a patient and an exam can be more dangerous than simply viewing a record.
HL7 v2 and FHIR integrations deserve special attention. Among other areas, testing must verify:
- authentication and authorization by system, user, and context;
- validation of HL7 messages and FHIR resources;
- unauthorized access through identifier substitution;
- excessive exposure in search endpoints;
- separation between clinical, administrative, and financial data;
- traceability of reading, modification, and export activities;
- protection of secrets used by integration mechanisms;
- behavior when handling duplicate, delayed, or out-of-order messages.
Testing must not create fictitious patients in production without authorization, modify real clinical information, or trigger medication, billing, or care workflows.
Risks in financial systems
Financial applications must preserve the balance, beneficiary, amount, currency, order, and idempotency of transactions. An API may authenticate a user correctly and still allow fraud if it does not verify whether that user can operate a specific account or if it accepts the reuse of a request.
Priority scenarios include:
- broken authorization for accounts, wallets, or contracts;
- modification of an amount or beneficiary after an approval step;
- reuse of tokens and requests;
- idempotency failures that generate duplicate operations;
- abuse of account recovery and credential reset processes;
- circumvention of transaction limits;
- exposure of statements, documents, and registration data;
- manipulation of webhooks and callbacks;
- compromise of keys, pipelines, and cloud accounts.
Standards such as OWASP ASVS and the OWASP API Security Top 10 help structure test coverage. When cardholder data is involved, applicable PCI DSS requirements must also be included in the planning, without treating compliance as a substitute for offensive testing.
How to plan a safe offensive operation
1. Define the objective and scope
A good objective is measurable. “Test security” is vague; “assess whether a standard account can access another patient’s records” or “verify whether an attacker with leaked credentials can reach the payment environment” produces useful evidence.
The scope must list:
- authorized domains, IPs, APIs, applications, and environments;
- test identities and profiles;
- included and excluded third-party integrations;
- permitted testing hours;
- prohibited techniques;
- volume and concurrency limits;
- contacts for immediate interruption.
Any asset outside this list must be considered prohibited until formally authorized.
2. Formalize the rules of engagement
The rules of engagement, or ROE, protect the organization and the technical team. The document must establish who authorized the test, its validity period, how evidence will be handled, and stop conditions.
In healthcare and finance, actions such as denial of service, data destruction, actual ransomware, uncontrolled persistence, and exfiltration of entire databases must be prohibited by default. To demonstrate impact, accessing a minimal sample—masked whenever possible—and documenting the evidence is usually sufficient.
Stop criteria include noticeable degradation, risk to a clinical workflow, an unauthorized transaction, unanticipated access to a production secret, or the simultaneous activity of a real attacker.
3. Model threats before exploitation
Map assets, trust boundaries, user profiles, data flows, and integrations. Instead of executing a generic checklist, formulate attack hypotheses:
- How can a low-privilege user reach another data subject’s information?
- Does an integration credential allow lateral movement?
- Can a webhook be forged or replayed?
- Does the system validate authorization for each object or only in the interface?
- Does a secret stored in the pipeline grant access to the critical environment?
This approach reduces unnecessary testing and focuses effort on the paths with the greatest impact.
Execution: from the application to the infrastructure
The operation must combine manual testing and automation. Scanners help expand coverage, but business logic, authorization, and vulnerability-chaining flaws generally require human analysis.
Layers that must be assessed
- Web application: sessions, authorization, uploads, injection, content rendering, and protection against automation.
- APIs: endpoint inventory, object-level and function-level authorization, consumption limits, schema validation, and excessive exposure.
- Mobile application: local storage, communications, token protection, and improper reliance on client-side validation.
- Identity: multifactor authentication, account recovery, service accounts, privileges, and federation.
- Cloud and DevOps: permissions, secrets, public repositories, pipelines, images, and separation between environments.
- Integrations: trust between systems, message signing, certificates, queues, webhooks, and failure handling.
- Detection: alert generation, log quality, event correlation, and time to containment.
Testing must use dedicated identifiers, traffic tagging, and dedicated accounts. Collected data must be encrypted, accessible only to the authorized team, and deleted according to the agreed retention period.
How to classify and communicate findings
A vulnerability must not be prioritized solely by its CVSS score. The report must combine exploitability, exposure, required privileges, technical impact, business impact, and the presence of compensating controls. EPSS can support probability analysis for known vulnerabilities, but it does not measure business logic flaws specific to an application.
Each finding must include:
- affected asset and environment;
- preconditions and the profile used;
- reproducible steps;
- minimal evidence, without unnecessary data;
- technical and operational impact;
- justified severity rating;
- recommended remediation;
- temporary mitigation alternative;
- retesting guidance.
In healthcare, the impact assessment must consider patient safety, confidentiality, and continuity of care. In finance, it must consider fraud, transaction integrity, data exposure, and service disruption.
Checklist for hiring or approving an offensive security test
Before starting, confirm:
- [ ] Is there formal authorization signed by the appropriate person?
- [ ] Are production and staging environments clearly identified?
- [ ] Are there enough test accounts and synthetic data for the scenarios?
- [ ] Have load limits and prohibited techniques been documented?
- [ ] Have affected third parties authorized the test?
- [ ] Does the defensive team know how to validate alerts and stop the operation?
- [ ] Will evidence be encrypted and deleted within a defined period?
- [ ] Will the report assess business logic rather than only CVEs?
- [ ] Is retesting of remediations planned?
- [ ] Is there a process for addressing critical findings immediately?
The main trade-off is realism versus operational safety. Testing in production provides more accurate signals about controls and detection, but it increases risk; staging reduces impact but may conceal configuration and integration flaws. A balanced approach validates exploitation in a controlled environment and performs only minimal, previously authorized proofs in production.
How Predictor Solutions addresses this
Predictor Solutions performs risk-oriented offensive assessments of applications, APIs, cloud environments, and pipelines, with a formal scope, reproducible evidence, and recommendations tied to operational impact. In healthcare, the company’s experience includes systems and integrations using HL7 v2 and FHIR; in software engineering, it combines offensive security with development, data, cloud, and DevOps to correct the structural cause of vulnerabilities rather than merely identify them.
This work is performed by a software house based in Lavras, Minas Gerais, Brazil, which has already served 9 medium-sized and large companies. Predictor Solutions projects have generated average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and a 43% increase in profit within six months—business results that do not replace security metrics but help integrate technical remediation, operational continuity, and business priorities.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.