Offensive security testing in healthcare and financial systems must simulate realistic attacks without putting patients, transactions, personal data, or operational continuity at risk. The right approach combines an authorized scope, a controlled environment, rules of engagement, manual validation, and prioritization based on both technical severity and business impact.
Why healthcare and finance require a specific approach
Healthcare and financial applications concentrate sensitive data, complex integrations, and processes in which downtime can have consequences greater than the loss of an isolated server.
In healthcare, a vulnerability can expose medical records, test results, prescriptions, wearable data, or information transmitted through HL7 v2 and FHIR. It can also affect clinical decisions if it allows information to be altered, patients to be incorrectly associated with tests, or care delivery systems to become unavailable.
In the financial sector, the main risks include fraud, balance manipulation, limit abuse, beneficiary changes, unauthorized access to banking information, API compromise, and account takeover. An apparently simple vulnerability can be combined with authentication, authorization, and business rule flaws.
In both sectors, testing must consider:
- confidentiality of personal data and sensitive personal data;
- integrity of clinical, accounting, and transactional records;
- availability of critical services;
- traceability for auditing and incident response;
- integrations with third parties, devices, and legacy systems;
- requirements under the LGPD and applicable regulatory obligations;
- systemic risk caused by identities, APIs, and supply chains.
Red team, pentesting, and vulnerability assessment are not the same thing
An automated assessment looks for vulnerable versions, insecure configurations, and known patterns. A pentest manually validates whether vulnerabilities can be exploited within a defined scope. A red team operation, in turn, assesses whether people, processes, and technologies can prevent, detect, and respond to a realistic attack chain.
For a specific financial API, a pentest may be sufficient. To determine whether an attacker can start with compromised credentials, move between environments, and reach a payment system, a red team is more appropriate.
When to choose each approach
- Vulnerability scanning: frequent monitoring of assets and known exposure.
- SAST, DAST, and dependency analysis: integration of security into the development lifecycle.
- Pentest: validation of an application, API, infrastructure, or release before production.
- Red team: assessment of complete scenarios, including identity, cloud, endpoints, authorized social engineering, and detection capabilities.
- Purple team: collaboration between offensive and defensive teams to improve controls and alerts during controlled exercises.
These practices complement one another. A red team does not replace basic remediation, vulnerability management, or secure code review.
Scope must start with impact, not tools
Before the first test, a threat model must be developed. It should identify critical assets, threat actors, trust boundaries, data paths, and the consequences of a breach.
A technically appropriate scope answers the following questions in writing:
- Which domains, applications, APIs, accounts, environments, and addresses are authorized?
- Can production be tested, or only the staging environment?
- Which techniques are prohibited, such as denial of service or modification of real data?
- How will users with different access profiles be provided?
- Who can immediately stop the exercise?
- How will evidence, credentials, and collected data be stored and deleted?
- What is the procedure for reporting a critical vulnerability?
- How will remediation retesting be performed?
The rules of engagement must also define emergency contacts, the execution window, load limits, traffic origin, and explicitly excluded systems. In production, any test with the potential to cause downtime must have formal approval, monitoring, and a rollback plan.
Offensive security testing in healthcare applications
Testing a healthcare platform must go beyond web forms. The complete data flow must be followed: registration, care delivery, integration, storage, viewing, and sharing.
Priority areas
- Access control: Can a professional view patients outside their assigned unit or scope?
- Separation between organizations: Do data from different hospitals or clinics remain isolated?
- Consent and purpose: Does the system restrict access and sharing according to the authorized context?
- HL7 v2: Do interfaces validate the origin, structure, content, and permissions of messages?
- FHIR: Do resources, operations, and searches enforce authorization by user, patient, and organization?
- SMART on FHIR and OAuth: Do tokens have appropriate audiences, scopes, and lifetimes?
- Clinical files: Are images, reports, and attachments protected against direct access and malicious content?
- Logs: Do events record relevant access without storing tokens, passwords, or unnecessary clinical data?
Authorization validation must occur on the server. Hiding a button in the interface does not prevent a direct API call from being executed. In FHIR, for example, authorizing access to an endpoint does not mean authorizing every resource or every patient returned by it.
In care delivery systems, destructive tests must use synthetic data. If production must be assessed, the team should prefer minimal and reversible proofs, avoiding any change that could interfere with diagnosis, prescription, or patient identification.
Offensive security testing in financial systems
Financial applications depend on business rules that scanners usually do not understand. Testing must therefore analyze the complete transaction, not only isolated technical vulnerabilities.
The main scenarios include:
- account takeover caused by flaws in authentication, password recovery, or session management;
- broken authorization between customers, companies, accounts, and administrative profiles;
- modification of the amount, currency, recipient, or identifier during an operation;
- transaction replay caused by idempotency failures;
- abuse of limits, discounts, chargebacks, and approval workflows;
- exposure of keys, tokens, or financial data in logs and pipelines;
- undue trust in webhooks or third-party integrations;
- bypassing multifactor authentication through alternative flows;
- race conditions capable of producing inconsistent balances or states.
When card processing is involved, the scope must consider the applicable PCI DSS requirements, especially controls over secure development, testing, segmentation, and data protection. For APIs, the OWASP API Security Top 10 helps organize risks such as broken object-level authorization, improper authentication, unrestricted resource consumption, and improper inventory management.
Safe operational methodology
A mature operation can use references such as the OWASP Web Security Testing Guide, OWASP ASVS, NIST SP 800-115, and PTES. No methodology, however, eliminates the need to adapt to the context.
A recommended workflow includes:
- Preparation: authorizations, scope, data classification, and rules of engagement.
- Mapping: assets, APIs, identities, integrations, cloud, and external attack surface.
- Threat modeling: definition of relevant objectives and attack paths.
- Validation: manual testing with controlled proofs and minimal data collection.
- Detection: verification of alerts generated in SIEM, EDR, WAF, IAM, and cloud environments.
- Containment: immediate interruption if an unforeseen impact occurs.
- Reporting: reproducible evidence, root cause, and actionable recommendations.
- Retesting: confirmation that the remediation eliminated the vulnerability without introducing regressions.
Credentials and evidence must be encrypted, accessible only to the authorized team, and deleted according to the contractual deadline. Real data should not appear in full in screenshots when a masked sample is enough to demonstrate the issue.
How to prioritize identified vulnerabilities
CVSS is useful, but it should not be the only criterion. A vulnerability with a moderate technical score may be critical if it allows a prescription to be changed, a financial approval to be bypassed, or another organization’s data to be accessed.
Prioritization should combine:
- ease of exploitation and prerequisites;
- internet exposure or required internal access;
- privileges obtained;
- volume and sensitivity of affected data;
- impact on patients, fraud, operations, and compliance;
- possibility of chained exploitation;
- existing detection, containment, and compensating controls;
- recurrence of the root cause in other components.
The report must separate the vulnerability, evidence, impact, remediation, and validation. Recommendations such as “improve security” are not actionable; the missing control and where it must be applied need to be specified.
Checklist for hiring or approving an offensive security test
- Is there formal authorization from the owner of each asset?
- Does the provider distinguish between pentesting, red teaming, and automated scanning?
- Does the plan cover APIs, business rules, identities, and integrations?
- Is there an emergency and interruption procedure?
- Will test data be synthetic or masked?
- Does the report present the root cause and reproducible evidence?
- Does the contract define confidentiality, retention, and disposal of evidence?
- Is retesting included?
- Will the defensive team evaluate telemetry and alerts?
- Will remediation be incorporated into secure development?
How Predictor Solutions addresses this
Predictor Solutions conducts offensive security as part of application engineering: it maps assets and flows, defines authorized scenarios, tests APIs and business rules, documents evidence, and supports remediation and retesting. In healthcare, its work includes systems using HL7 v2 and FHIR; in custom software, it also integrates security with cloud, DevOps, data, and architecture.
The company maintains products such as Predictor Health and Predictor AI Hospitals, bringing practical experience with clinical data, dashboards, wearables, and hospital applications. Across its broader portfolio, Predictor Solutions serves 9 medium-sized and large companies, with reported average results of R$ 1.32 million in savings per client per year, a 70% increase in productivity, and a 43% increase in profit over six months; these indicators reflect the overall project portfolio and do not replace specific security metrics.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.