eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
On March 14, a 20-year-old student at the University of Texas at Austin was charged by federal authorities in connection with an attack at the university, where the Social Security numbers and other personal information of approximately 55,200 people were illegally retrieved.
The attack highlights some subtle issues that all security administrators should be considering. The attacker discovered a publicly accessible Web application that allowed a user to query a database using only a Social Security number and then returned student and staff data for a person with a matching number.
At this point, harvesting the data was only a matter of data entry tedium. To fix this problem, the attacker wrote a program to automatically scan a range of Social Security number values and save returned data. During a period of just five days, the attacker made about 2.7 million queries looking for hits.
The first problem here is the way the University of Texas used peoples Social Security numbers as database key values, something very tempting for health, finance and academic institutions, which often need to collect these numbers anyway.
Legislation will force movement on this issue among IT organizations even if its security dangers dont. Californias Civil Code Sections 1798.85-1798.86 and 1786.6 mandate a number of protections on the display, transmission and use of Social Security numbers. These mandates began to take effect July 1, 2002, and will be fully in force by July 1, 2005.
The second problem was that the University of Texas application was using only the structured, guessable Social Security number as both the authentication and the lookup key; asking for a single extra piece of information, such as a last name, would have blocked this attack.
Third, this application was reachable from the outside Internet. Network layer controls that reinforce application behavior rules provide an extra layer of protection.
Finally, the attack could have been detected much more quickly if a mechanism had been in place to notice highly unusual application usage.
This last point is a subtle one. Computers are stupid creatures and will happily do what they are designed to do as fast as resource constraints will allow for as long as they are asked to do so.
In our Feb. 3 issue, I wrote about the Open Web Application Security Projects new Top Ten list of application security mistakes (see www.eweek.com/links). The document states, “Note that the vast majority of Web application attacks are never detected because so few sites have the capability to detect them. Therefore, the prevalence of Web application security attacks is likely to be seriously underestimated.”
This is a warning we need to take to heart. Do your IT systems use any kind of internal event-logging mechanism to record their actions? Are security events such as failed log-ins recorded somewhere? Are logs centralized and inspected regularly?
Note that just recording security errors isnt enough; too many things done right are a problem, too.
In author Orson Scott Cards short story “Dogwalker,” the protagonist cracks into a government database by logging in using a system administrators password. He gets busted because the G-man always deliberately fails his first log-in attempt and logs in correctly on his second try: “The system knew the pattern, thats what. Jesse H. is so precise he never changed a bit, so when we came in on the first try, that set off alarms.”
Thats effective pattern recognition.
Were not there yet, but putting systems in place to detect massive changes in typical system usage is not only feasible, its absolutely necessary. Its clear what the consequences of failure to do so can be.
West Coast Technical Director Timothy Dyck can be reached at timothy_dyck@ziffdavis.com.