I recently came across an interesting article regarding the increasing problems with thieves targeting schools for identify theft.

The article mentions an incident where a hacker broke into a database at a school in El Paso, and managed to retrieve 63,000 Social Security numbers (SSNs) of students. 

This is a gold-mine for an identity thief.  SSNs can be used to get credit cards, take out loans, and generally "create" money for the thief.  Furthermore, the SSNs of young people are generally "clean", meaning they have no credit history attached, making it far easier to get credit with them.  Finally, if the SSNs used are those of very young students, it may be years before that student actually tries to use it to get credit legitimately, and thus years before the identity theft is detected. 

There have even been some experts suggesting that parents sign up their very
young children for the sort of automatic credit check services that the government recommends for adults, to try to catch these sorts of issues early.

Many would shake their heads at this, and wonder why the school in question didn't do a better job of protecting the database that was attacked. 

While this perspective is certainly legitimate, anyone who has worked in the IT security space for a decent amount of time would tell you that no matter how well protected the system, there is no such thing as perfect security.  Bugs creep in, new attacks are developed, systems are misconfigured.  A determined attacker can usually find their way in, and good information security practice can only reduce risk, not eliminate it. 

Reducing risk significantly is usually an expensive proposition, requiring high levels of specialized knowledge, and expensive hardware and software tools that many schools can't afford. Furthermore, there is usually an inverse relationship between how secure a system is, and how functional it is - the more secure, the less capabilities it has, and the harder it is to use for legitimate purposes.  IT groups are usually tasked with making things easier for their users, not harder, so security often falls to the bottom of the priority list. 

That all being said, the attacker's job would have been much harder if the El Paso school hadn't been collecting SSNs from students to begin with. 

Why were they?  I expect the answer is convenience. 

Certainly, as we move towards using information technology in all aspects of our lives, the temptation to gather more data than we might necessarily need to accomplish our goals is ever-present.  Data collection and organization is often fantastically easy these days, so why not collect it?  It might come
in handy later.

On a related note, designers of information systems often make assumptions about what data is or should be available, especially for identification and indexing purposes.  SSNs are a prime example – from the perspective of an software designer who is not well educated on security issues, the use of SSNs seems like a great idea.  Everyone has one, it's unique, and after all, it's already widely used.  Why not require this data and use it to uniquely identify students?

The answer to that question, of course, was answered for the folks in El Paso.

It behooves us to be very, very careful about the data we collect.  We need to develop an understanding of the other purposes the data might be used for, and understand, further, that we don't own the data, and are responsible to the real owners, the students, for protecting it when we do collect it. 

In the case of SSNs, if the only reason that a school is using them is to uniquely identify a student, a far better approach would be to assign each student a unique ID number when they enter the school system, completely unrelated to the student's SSN.  That number should be unique, random, and contain no "in-band" data that could be used to infer the age of the student, their location, or any other personal information about the student. 

This approach dramatically reduces the risk associated with holding that data, rather than exposing the student to risks that should more appropriately be carried solely by the school. 

While security is often at odds with functionality, there is significant room for improvement at all phases of development – especially in the design phase, where decisions about what sorts of data will be collected are properly made.  Trying to add on adequate security controls after the design is set is a losing proposition, and leads to issues that could have been avoided if more thought had been given to security through the entire development process.