16
Subdomains exposed in public DNS/CT
An outside-in read of Northwind Health's public attack surface, with each technical observation mapped to the obligation it bears on under India's Digital Personal Data Protection Act. No intrusive testing — only what is already visible to the open internet.
What to fix. Every row names a specific host and a concrete remediation — a change the engineering team can action this sprint.
What it bears on. Each observation is mapped to the DPDP obligation it is evidence for — so the compliance gap is legible, not buried in a scanner dump.
A secondary host, sftp.northwindhealth.in, runs a 2013-era stack (Apache 2.4.6 · OpenSSL 1.0.2k) carrying dozens of known vulnerabilities — while a support-ticketing system, a developer project server, and pre-production environments sit openly reachable on the same domain. This is the strongest available argument that "reasonable security safeguards" (DPDP §8(5)) are not yet demonstrable across the estate.
Northwind's public footprint spans 16 subdomains — and several are not customer-facing: a support-ticketing system (OTRS), a developer project server (Tuleap), operations and staging/pre-production hosts, all reachable from the open internet. The main application runs a current web server but ships a 2014-era JavaScript library (jQuery 1.11.2); a file-transfer host runs software that reached end-of-life around 2013. A wildcard TLS certificate spans hosts that appear to include a cardholder-data environment. None of this required a login or an intrusive probe to see — which is precisely why it also describes what an attacker, or a regulator asking "what safeguards can you demonstrate," would see first.
| Technical observation | DPDP obligation it bears on | Owner | Severity |
|---|---|---|---|
| sftp.northwindhealth.in — Apache 2.4.6 + OpenSSL 1.0.2k (EOL ~2013), 23 critical / 46 high version-matched CVEs across the estate | §8(4)–(5) — appropriate technical measures & reasonable security safeguards. Unpatched, end-of-life software is the canonical example of a safeguard not being maintained. | DEV — upgrade / decommission | CRITICAL |
| otrs · tuleap · operations · techhelp — internal support, dev-project and ops systems reachable in public DNS/CT | §8(4) — technical & organisational measures / access control. Support and ops tooling commonly processes personal data; public reachability is an access-control question for counsel. | DEV + POLICY | HIGH |
| *.northwindhealth.in wildcard cert — a single wildcard certificate spans hosts that appear to include a cardholder-data environment | §8(5) — key-scope / safeguard boundary. A shared key across a payment-adjacent boundary widens blast radius; relevant to both DPDP safeguards and PCI scope. | DEV — split cert scope | MEDIUM |
| health.northwindhealth.in — historical URLs (public archives) reference configuration / version paths | §8(4) — information disclosure minimisation. Leaked config/version detail lowers attacker cost; evidence the surface is not minimised. | DEV — scrub / rotate | HIGH |
| staging · stagingup — pre-production environments visible in public DNS/CT | §8(4) — environment separation. Staging often holds copies of production personal data; public exposure is a data-minimisation question. | DEV + POLICY | LOW |
Owner is the division that fixes each item: DEV ships a technical change; POLICY is a determination for counsel (is this personal data, is the exposure lawful, what does the client's DPDP notice say). Several are both — which is exactly why a technical audit alone, or a legal review alone, leaves the gap half-closed.
An outside-in scan produces the observable, dateable evidence — what is exposed, what version it runs, which CVEs it carries — and re-runs it on a schedule so the picture stays current as the surface drifts and new CVEs land.
Whether an exposed system processes personal data, whether a safeguard is "reasonable," what the client's DPDP notice and contracts require — these are legal determinations. The evidence is only actionable once counsel characterises it.
A scanner hands a client 109 findings and no priorities. A lawyer without the technical read is arguing compliance in the abstract. Together, this document becomes a DPDP-readiness plan — a fix list for the engineers and an obligation map for the record.