Turning CenterPoint's public facts into measurable security questions
CenterPoint Energy's breach is a useful test of how security teams turn incomplete public information into a measurement plan. The company confirmed that customer information was obtained through an external-facing system in its SEC filing. A Texas Attorney General listing reported by Click2Houston records 1,062,060 affected Texans. The endpoint and root cause remain unidentified in the reviewed public record.
An attacker claimed that an API lacked authentication, rate limiting, and WAF coverage and that 7.49 million records were taken. Those assertions are not confirmed. A measurement plan should treat them as hypotheses that can be tested with internal evidence.
ZoomEye adds an external observation. A domain query returned 241 indexed matches on November 6, 2026. The HTTPS subset returned 125 and the HTTP subset returned 111. The query result gives the investigation a reproducible public scope.
Define what each metric answers
Metrics should answer a decision question. A raw asset count is useful only when it is connected to ownership, data reachability, or control status.
| Question | Metric | Decision it supports |
|---|---|---|
| How large is the public naming footprint? | Domain-matched indexed assets | Set the inventory review scope |
| How many records have an HTTPS observation? | 125 matches for the domain plus port 443 | Prioritize certificate and web-service review |
| How many records have an HTTP observation? | 111 matches for the domain plus port 80 | Find redirects, legacy endpoints, and missing owners |
| How many services can return affected data? | Count after owner and route review | Rank the investigation queue |
| How many high-priority routes lack current control evidence? | Count of open route reviews | Assign remediation and verification work |
The first three questions can be answered from public observations. The last two require internal data. Mixing them produces a number that looks precise but has no stable meaning.
Build a service-level record
Each externally visible hostname should have a service record. Include the business function, owner, environment, data categories reachable, identity types accepted, authentication method, rate limit, WAF policy, logging source, and last review date. Add links to the relevant DNS, certificate, gateway, and deployment records.
The service record should state how the conclusion was reached. An owner's confirmation is different from inference based on a page title. A configuration export is different from a screenshot of a login page. Record the evidence type and collection time.
This structure helps investigators ask whether two records describe the same application. A hostname and an internal service name rarely map one to one. A load balancer can front several applications, and one application can have several public names.
Use a review sequence
Start with the public inventory and remove records that are clearly out of scope. Next, attach owners and confirm the data each service can reach. Then review authentication, authorization, rate limiting, WAF coverage, and logging for services that can reach customer records.
After that, test only the controls that need evidence. Use approved identities and synthetic data. Verify the test against logs, not just the response. If the expected log is missing, record a telemetry exception even when the request was blocked.
The final step is remediation verification. A configuration change is not complete until the route behaves as expected and the log shows the new behavior. Keep the before-and-after evidence in the service record.
State uncertainty in the measurement
The attacker claim is not a baseline. The 7.49 million figure should be reported as an allegation. The 1,062,060 figure comes from the Texas Attorney General listing and may be updated. The 241 domain matches are public observations, not affected systems.
Those differences are not obstacles to measurement. They define what can be measured now and what must wait for better evidence. A response plan that states those limits is easier to defend than one that converts every available number into a breach metric.
CenterPoint's case offers a practical starting set: map the public estate, attach owners, identify services that can reach customer data, verify controls with logs, and preserve the source behind each conclusion. The work does not require inventing an endpoint. It requires making the unknowns explicit and assigning evidence collection to the right owners.
Top comments (0)