Frontline Education is notifying over 1.3 million people that their personal information was compromised in a data breach. The company said the incident occurred on August 14 and involved the exploitation of a vulnerability in a third-party software product to gain unauthorized access to Frontline's environment. The affected data belongs to school district staff and students.
What happened
The investigation determined that the hackers stole the personal information of both school district staff and students from the Frontline Central and School Health Management products.
The stolen data varies by individual. It may include names, Social Security numbers, dates of birth, driver's license numbers, passport and other government ID numbers, health insurance information such as Medicaid IDs, and Student IDs.
Frontline has not shared the number of potentially affected individuals. Filings with the Attorney General's Offices in Massachusetts, New Hampshire, South Carolina, Texas, and Vermont show that 1,298,917 people were affected.
How it was done
The reported entry point was a vulnerability in a third-party software product, which was exploited to gain unauthorized access to Frontline's environment. From there, data was taken from two named products that hold staff and student records.
The incident occurred on August 14 and involved the exploitation of a vulnerability in a third-party software product to gain unauthorized access to Frontline's environment.
No further technical detail about the flaw or the path between the third-party product and the record stores has been published.
What to check
If your platform holds identity documents or student and staff records behind third-party components, these checks are worth running this week.
Inventory every third-party product with network reach into your environment
Pull the list from your asset register, your vendor contracts and your egress firewall rules, then compare them. Anything appearing in traffic logs but not in the register is the gap to close first.
Confirm patch levels on edge and file transfer software
Check installed versions against vendor advisories for each appliance and managed service exposed to the internet. Treat any product more than one release behind, or past end of support, as an immediate item.
Segment the record stores from the vendor component
Review network policy, for example Kubernetes NetworkPolicy objects or security group rules, and test whether a shell on the third-party host can reach the database holding identity records. A successful connection on the database port is a failing result.
Check what identity fields you actually store
Run a schema scan or a query over columns for national identifiers, licence numbers, passport numbers and health insurance IDs. Fields kept in plaintext, or kept past their retention window, should be encrypted, tokenised or deleted.
Verify you can detect bulk reads
Look at database audit logs and application access logs for queries returning large row counts to a single session. If you cannot answer how many records a single account read last month, the logging is not sufficient.
Test your vendor incident path
Confirm you have a named contact and a notification clause for each critical supplier, then run a tabletop where a supplier reports a flaw under active exploitation. Not knowing who to call is the failure to fix.