radioAe6rt

My latest coincidence with identify theft and data security: we just received a letter from TD Ameritrade CEO Joe Moglia that torturously begins:

Dear Mark Petrovic,

While investigating client reports about the industry-wide issue of investment-related SPAM, we recently discovered and eliminated unauthorized code from our systems. This code allowed certain information stored in our databases, including email addresses, to be retrieved by an external source. Your information is currently included as part of our database either because you are a former client or because you had in the past applied for an account at TD AMERITRADE.

My first question is: What is unauthorized code and what does it mean to remove it? Is this a synonym for “software”, as in lines-of-code? Sounds like unauthorized code means “Trojan Horse” or virus, as the letter goes onto say that the unauthorized code was able to bypass detection by our anti-virus software and other protective systems. All reads: Windows-based financial services shop gets hacked.

My second question is: What is an external source?

What this opening paragraph says is that information about me was stolen from TD Ameritrade.

It seems sort of peculiar that the breach the letter describes was discovered while investigating (read: operating diligently on my behalf, followed by posterior-covering) the “industry-wide” (read: it’s not just us getting hacked) investment-related SPAM. One can run across network access anomalies in a lot of different ways, but specifically while investigating spam seems an odd, overly-specific segue into the disclosure of data theft. I doubt the discovery was made while investigating spam, which is sort of like saying we discovered it while thinking about email. But no matter. More information about me is now in the wild.

The letter closes with an assurance that ID Analytics, the firm brought in to assess damage, found no evidence of identity theft. And that I should keep a close eye on my credit activity. To which I can only say: thanks a lot — and no kidding.

So in December 2005, I received a similar letter from ABN-AMRO stating that tapes had been lost by DHL (read: finger pointing), the courier service, that contained my personal data. A few months ago, I received a similar letter from IBM HR – that is, that tapes with my data on them had been lost. And now TD Ameritrade steps up with this latest bit of bad news.

It’s become a full time job keeping up with who’s lost the information on my household that I entrusted to them.

[tags]td ameritrade, identify theft, data loss[/tags]

I got on a Spring+Hibernate bender recently, determined to learn a few new things about declarative transaction management and annotating entity classes using Hibernate Annotations. In the course of this work, one needs a database, and the one I’m using is embedded HSQL and happens to contain about 1M records. To populate it I elected to use Spring’s JdbcTemplate helper class.

A few minutes into the population of the database, the JVM would issue an OutofMemoryError. Hours of debugging ensued, as I made certain that my code was not holding onto references that should have been garbage-collected.

I finally accepted the fact that a heap profile was in order, so I set -XX:+HeapDumpOnOutOfMemoryError on the JVM command line. The app harness is a Jetty webapp, so the application invocation goes like this:

$ java -XX:+HeapDumpOnOutOfMemoryError -jar start.jar

When the app died for lack of memory, it wrote java_pidXXX.hprof to the current working directory. JDK6 now bundles jhat, a heap analysis tool for just this sort of occasion:

$ jdk/jdk1.6.0/bin/jhat -port 1960 -J-mx512m tmp/java_pid13056.hprof

which after considerable crunching, starts a web server on port 1960 with the results of the analysis. Toward the bottom of the output, one finds “Show instance counts for all classes (excluding platform)”, whereupon I was presented with something like 500,000 held-references to org.hsqldb.MemoryNode and org.hsqldb.Row. This was for HsqlDb v1.8.0.7, using cached tables. I’m not an expert at reading this hprof output, but from the looks of it, those two classes hold references to each other that neither releases.

So I swapped HsqlDb out and the latest Apache Derby in, and the database loads fine. I can even see in the JVM profiler output (http://www.yourkit.com) how allocated heap memory now stays within safe boundaries.

It was a good exercise tracking down this memory issue, and good that another tool could be added to the set: jhat.

Update: A user in the know on the HsqlDb forum indicated that for cached tables, this OOM error should not obtain. By using jdbc:hsqldb:data/qsodb;hsqldb.default_table_type=cached for the JDBC connection URL, I was able to confirm his assertion. Setting what I thought was the equivalent property in the Hibernate sessionFactory properties hibernate.connection.hsqldb.default_table_type=cached did not have the same effect, at least not at the time the app needed it. All these tests can be verified by examining the HsqlDb properties file theDb.properties after the app starts up.

[tags]hsqldb,derby,spring,hibernate,jhat[/tags]