Ask HN: Security negligence by former employer, a health insurance co.?
2 comments
This looks like terminal penny pinching. Management dreams they are competent = they are not, except in pay check deposition, running at 100% efficient.
Are they public or owned by a reporting entity? = their auditor should be advised. If private, anonymously inform their lawyers, insurers and accountants/auditors.
Not sure how they dealt with the recent ransomware, maybe just paid it? Any insurer engaged afterwards with ransomware coverage would have done a data management audit and would not tolerate the state they are in and would not cover them unless they were patched wall to wall.
with those holes, loose lips in the hackerverse will soon lead to those holes being exploited - possible ruin to business?
If they are involved with medicaid, medicare, or many private health care insurers - as they must be, hunt for a whistle blower number/button on their web site - not for $$, but for the public good. When cans of worms are opened, bodies are found and it might cost the company a lot of $$ to rectify this, as it should.
If they are involved with medicaid, medicare, or many private health care insurers - as they must be, hunt for a whistle blower number/button on their web site - not for $$, but for the public good. When cans of worms are opened, bodies are found and it might cost the company a lot of $$ to rectify this, as it should.
CISA whistleblower tipline.
Email your local congressional representative for additional guidance. Whether you support them politically, or not, they have a large staff of intelligent men and women who would love to help you.
InsCo suffered a ransomware attack in 2023 that affected some 9 million customers, mostly Medicaid recipients. Data that was compromised included the usual litany of PII: SSNs, DL numbers, addresses, DOBs, etc. Their IT infra is composed of a combination of Ruby on Rails and .NET applications. After the breach, the agency that built the Rails application was fired. In May 2024 I was brought in to lead the team responsible for upgrading the Rails app. All of us were contractors. This is what I learned about the processes they had in place, and the Rails application itself.
As of August 2024:
1. The application ran on Ruby 1.9.3, which reached EOL in 2013.
2. It used Ruby on Rails 3.1, which reached EOL in 2016.
3. The OS was CentOS7, which reached EOL in July 2024.
4. There was no containerization of applications; development and production were on bespoke AWS sandboxes. When we managed to get the application running in Docker, Docker Scout reported around 650 vulnerabilities.
5. There were no processes around secure coding practices, either automated or manual.
6. Unit tests were discouraged and flaky. I required unit tests for all PRs, but Director X reversed this decision, stating, "tests are acceptable but not encouraged." Existing tests were unreliable due to a shared test database causing data integrity issues.
7. Code reviews were discouraged. The team started using PRs, but Director X banned them, stating it made auditing harder. He preferred using text files attached to Jira issues and became angry when I requested a template.
8. Management rarely documented requests/orders and ignored explicit requests for written feedback. Issues with open questions were often left unanswered.
9. All code changes had to be approved by management before being merged to master, and all merges to master were done by management.
10. Library changes, whether minor version upgrades or changes to different libraries, also required management approval.
11. There was no production monitoring in place such as DataDog or New Relic.
12. Medicaid data was received from the State of CriticallyImportantToTheElection in an unencrypted zip of XML data and uploaded using FTP. Not even SFTP, just raw FTP.
13. The entire upgrade team was fired in early August 2024 without explanation. We were starting to make good progress, then... bam. Our GitHub access was revoked and we no longer had access to Jira or Teams. No communication was given regarding the reasons.
14. An effort to upgrade from CentOS7 to RHEL9 also failed; when I left, they were still using the outdated CentOS7.
This situation seems to reflect severe negligence, if not intentional disregard. What advice does HN have on this matter? Are there any law enforcement or regulatory agencies that might be interested? The personal data of millions remains exposed, and this data is crucial for state and federal protection efforts. At the very least, this appears to be a result of incompetence, if not malicious intent.
I’m looking to take action if possible.