Sensitive information - is it really secret?
This is John Heimann, Sr. Director, Oracle Global Product Security (GPS), again. In my role as manager of the GPS Security Program Management team, one of my primary concerns is ensuring that Oracle's products effectively protect sensitive customer data. More specifically, the Security Program Management team helps to ensure that Oracle product development groups consistently apply secure coding standards, tools and processes that help reduce the likelihood of exploitable security vulnerabilities in our products. Oracle product development groups have designed and implemented many security features that customers can use to protect sensitive information. My team works with product groups to help ensure that Oracle developers avoid security flaws that could allow attackers to bypass these security features and gain access to sensitive data.
In recent years, there have been a number of high profile breaches of information systems that process sensitive information associated with thousands or even millions of people. When Oracle GPS becomes aware of breaches of information systems processing sensitive data, we typically investigate the causes of the breaches. Even if the breached information system did not include any Oracle technology, analyzing root causes of a breach can allow us to help improve the design of our products, avoid certain classes of vulnerabilities, or improve the security guidance we offer to customers.
There are cases where understanding why a serious data breach was so serious require extending the breach analysis beyond the boundary of the information system. In those cases, the analysis includes how the people and systems outside the breached system use the information that was revealed. Sometimes, the analysis indicates that certain categories of data considered "sensitive" or "private" when they were defined - often in a pre-internet, or even pre-computer, era - are now used in ways that are fundamentally insecure. The fact that those types of data are now processed by internetworked computer systems simply highlights that insecurity, and makes exploitation of it easier.
As a concrete example, suppose I told you that you are required to use a system that is responsible for managing your personal identity, tax history, past credit records, ability to get future credit, and other important functions in your daily life. You will be issued a unique password to access that system, and you can NEVER change it. Contrary to typical password best practices, the password has well-known internal structure that may make components of it predictable. Moreover, you are required to give that password to banks, credit companies, utilities, the US Internal Revenue Service and other government agencies, tax preparers and accountants, and every employer you have ever worked for. Would you agree to use such a system? You probably would not, but that's exactly what we in the US are required to do with our social security numbers (SSNs). We pretend that SSNs are "private" information but given the number of people to whom we disclose SSNs, they should not be considered private.
A similar situation exists with credit card numbers. If I know your credit card number and date of card expiration, I can make purchases by phone or on the Internet that will be charged to your credit card account. You can change a credit card number on a time scale of months or years - by canceling the card and applying for a new one - but on a short term time scale a credit card number is effectively fixed and unchangeable, and you have to reveal it to hundreds of people and computer systems every month. How would anyone possibly consider that information "secret?" Note that credit cards now have three digit Card Security Codes (CSCs) printed on the back to protect against fraudulent use of credit card numbers. Merchants often ask for a CSC when a customer does not present a physical card during a purchase (e.g., when ordering something by phone or on the internet). Since the CSC number is fixed for the life of a card, can be obtained by any merchant who handles a customer's physical card, and must be disclosed any time a customer makes an internet or phone purchase, it can't be considered truly secret either. We pretend that SSNs and or credit card numbers are "private" or "secret" and have to be protected by elaborate computer security mechanisms, but in fact they have never been truly secret.
The real problem is that our social systems associated with identity and credit allow an attacker with simple knowledge of Joe Blow's SSN or credit card number to masquerade as Joe Blow and perform some privileged function, like making a purchase on Joe's account. Computers make attacks that were already in existence (like dumpster diving for credit card slips with card numbers, or paystubs with SSNs) much easier, and simply underscore the weakness in the greater system that handles the information, including people and processes as well as computers.
At one point in time, when credit card or SSN data were disclosed to a limited number of human users through manual processes, simply demonstrating knowledge of an SSN or credit card number may have been an acceptably secure means of authentication. Unfortunately for those of us who still must use SSNs and credit cards, simple knowledge of SSN or credit card number cannot now be considered a secure means of user authentication. In fact, such practice violates several basic, generally accepted principals for secure authentication. Among these principals are
data used for authentication purposes must not be widely shared or stored in multiple places
authentication data should not be difficult or impossible to change
authentication is much more secure when it involves something you have, or something you are, in addition to something you know.
Note that the weaknesses associated with SSNs and credit card numbers have been recognized for many years, and in the case of payment card information were one of the reasons for the creation of the Secure Electronic Transcation (SET) protocol in 1996. The SET protocol never became established because in the late 1990s, the rate of fraud associated with the existing process (simply giving your credit card number to a merchant) didn't justify the added expense and overhead of using SET. I suspect that over time, as more fraud associated with phone or online credit card sales occurs, people will re-examine the basic problem associated with using static credit card information and consider more sophisticated mechanisms for user authentication in payment transactions. Similarly, as identity theft becomes more common, I expect we will start to see a more complex mechanism than simple knowledge of a permanent SSN to evolve for authenticating users to potential payees.
Preventing exploitation of information by improving the security of computer systems in which that information is managed is not enough! In many cases, the information itself, and/or how it is used in social processes that include but are not limited to computer systems, needs to change before that information can be used securely. Properly planning and documenting business processes, including the definition of the information being maintained in the organization and defining what constitutes appropriate use of the information is required as a pre-requisite to defining a sound IT security strategy.
