One can conclude that the California legislature (along with lots of other folks) believe that data stored in a database is more highly protected from "hacking" if that data is encrypted. This blind faith in encryption is caused by something I call the "encryption myth." It is the mistaken belief that encryption provides more protection than other access control mechanisms. The belief that "if it's encrypted, it's protected" just isn't true. In fact, encryption is just another form of access control--a form that is useful and appropriate in certain scenarios but inappropriate in other scenarios. The encryption myth stems from a number of misconceptions about encryption.
In my opinion, the California legislature would have fostered better practices and stronger protection had they exempted companies with appropriate and demonstrable access control mechanisms based on an exclusionary access model (i.e., everyone denied access unless explicitly allowed). No additional protection beyond that provided by the access control mechanism is derived from encrypting data that must be accessible to someone or some application.
To understand why this is true, we have to look at the attributes of data that companies store, the attributes of encryption, and the threats that are assumed to be mitigated by encryption. Then, we'll look at the requirements being levied by customers. Finally, we'll pull these concepts together and see whether encryption provides any additional value.
Attributes of Data
I've often said that it is impossible to perfectly protect data because it's impossible to prevent unauthorized access to data. This is not quite accurate. It is possible, but only if you also prevent all authorized access! Of course, data that is inaccessible to everyone is useless; it has no value, so there would be no reason to store it. As soon as you introduce the requirement that someone or something must be able to access the data, you enter the world of risk management. Risk management means reducing the risk of unauthorized access to acceptable levels, not completely removing the risk.
Stored data must be able to be accessed in a "timely" manner. For example, if an application must process millions of Social Security Numbers stored in a database, it is not feasible to ask a human to manually enter a key that can decrypt each Social Security Number. It would take too much time. Since these applications normally run without any human intervention, even requiring human intervention once is unacceptable to most companies.
Data stored on disk is never accessed by a person. It is always accessed by a program. Programs run under an electronic user ID.
Hackers access data the same way any user accesses data--through programs that run under a user ID.
Attributes of Encryption
The first and most important encryption attribute to understand is this: Having access to the key that decrypts encrypted data and access to the encrypted data is equivalent to being authorized to the clear-text data. An algebraic representation of this is "access to clear-text data = access to decryption key + access to encrypted data." A corollary to this is that once data is encrypted and stored, the key that decrypts the data is just as sensitive as the clear-text data.
Encryption is compute-intensive; it takes a relatively large amount of resource to perform the numerous mathematic operations required.
David L. Scott, in Wall Street Words: An A to Z Guide to Investment Terms for Today's Investor, defines encryption as "the manipulation of data to prevent accurate interpretation by all but those for whom the data is intended." Financial institutions use encryption to increase the security of data transmitted via the Internet.
Sounds a lot like access control, doesn't it? This illustrates that encryption is useful for protecting data as it is transmitted through a medium that has no other access control mechanism.
Consider the following scenario, loosely based on my Army National Guard, Radio/Teletype Operator experience a long time ago. It serves as an example of several attributes of encryption.
An important and sensitive message from the commander of Company A is encrypted using the day's encryption key and sent to battalion headquarters. The person sending it either destroys the original message or, if information may need to be accessed later by someone in Company A, returns it to the sender, who puts it in a safe. At battalion headquarters, the message is decrypted using the day's encryption key. It is routed to the intended recipient. The recipient reads the message and either destroys it or stores it in a safe. At the end of the day, the keys are also destroyed. This is standard military operating procedure.
Why does the military encrypt data when it is being sent from one location to another, but store it unencrypted in a safe if the data may need to be accessed again at either the sending or receiving location? Why don't they keep all data encrypted at all times until it is needed again? The short answer is that access control (i.e., the safe) provides just as much protection as encryption for data at rest (in the safe, not in transit), and the safe provides a higher level of timeliness and data accessibility.
Encryption is a useful form of access control when no other access control mechanism is available. The military uses encryption to protect messages as they are transported from the protection of one access control mechanism (Company A) to the protection of a different access control mechanism (the battalion headquarters safe). It doesn't use encryption to protect the data "at rest" (i.e., while it is or can be under the control of a different access control mechanism).
Why would the military destroy the keys each day? First, the keys are just as sensitive as the data they encrypt. Second, neither the sending nor the receiving entity needs the keys once the data arrives at its intended destination and is decrypted. Third, the longer a key is used and the greater the number of messages encrypted with that key, the more likely an attacker may be able to compromise the key and thus any messages encrypted with it.
A perfectly good encryption algorithm can be successfully attacked if multiple messages are encrypted with the same key and the contents or partial contents of one of those messages is known to the attacker. This often-overlooked attribute of encryption was used by the allies in World War II to win the battle of the Atlantic against Hitler's U-boats. The Enigma machine was a marvelous encryption engine invented by the Germans prior to World War II. However, the allies knew that several German radio operators always started the first message of the day with a known phrase like "Heil Hitler. It's a beautiful day in the fatherland." The allies were able to build a machine that took advantage of this to find each day's key settings. By the end of the war, the allies were often reading messages in England and the United States before the Germans were able to decode and read them in Berlin. This illustrates the fact that good encryption depends not only on the algorithms, keys, and lengths used, but also on the data you choose to encrypt!
Knowing that data is encrypted tells you nothing about how well the data is protected. Without knowing the algorithm, the key length, and, most importantly, how the keys are protected, one knows nothing about how well encrypted data is actually protected.
Threats Encryption Is Supposed to Mitigate
The California law isn't the only legislation driving customer requirements for encrypting data stored on disk. Auditors performing Sarbanes Oxley (SOX) "compliance" (I think "assurance" is a better term) often assert that sensitive data stored on disk must be encrypted. The Visa Cardholder Information Security Program (CISP) also requires that certain data stored on disk be encrypted while stored.
When I ask who they are trying to protect the data from, the answer I get from customers and Visa usually includes "unauthorized employees, administrators, and hackers." Often, they'll say from "determined attackers."
Customer Requirements
Customers have a few requirements of their own over and above the legislation, the primary one being that the encryption and decryption be done by the application or the operating system. Most are unable or unwilling to invest in changing all of their applications that store or retrieve data on the system and feel this is something that should be provided by the operating system.
But even if they could afford to, doing so would provide no extra protection.
Why Encryption Doesn't Provide Additional Protection
let's take the concepts we've covered to this point and see how they affect our understanding of the additional protection provided by encryption.
We have legislation intended to provide more protection of personal information and to prevent identity theft by requiring that personal information be encrypted. We have customers who can meet the spirit of the legislation only by having applications or operating systems perform the encryption. We know that once data is encrypted, the key required to decrypt it is as sensitive and valuable as the clear-text data.
If a program is going to encrypt and decrypt data automatically, it must be able to generate and/or access the encryption key, access the encrypted data, and determine when and for whom it will decrypt the data.
To determine when and for whom it will decrypt data, a program uses an access control mechanism! But doing this is no different than relying only on access control! If the data is not encrypted on disk, only those authorized to retrieve it can do so. If the data is encrypted on disk, only those authorized to retrieve it can do so. It's the access control mechanism that determines whether the user sees the data; the decryption process just takes up computing resources.
Automatic encryption performed by the OS or an application will still return clear-text data to an *ALLOBJ user. By definition, *ALLOBJ users have access to the encrypted data and the encryption key. Remember: "access to clear-text data = access to encrypted data + access to encryption key." *ALLOBJ users, therefore, have access to the clear-text data even though the data is stored encrypted.
Another argument for encryption that customers have used is "I trust my administrators and have limited the number of people with *ALLOBJ, but the encryption is required to protect against hackers that break into the system." Sorry, but if an attacker breaks into the system with an ID that doesn't have access to the key and the encrypted data, the attacker wouldn't have access to the clear-text data either. However, hackers break into systems with *ALLOBJ authority (otherwise, it's not worth the effort). As the previous paragraph shows, encrypted data is not protected against *ALLOBJ users. Therefore, encryption does not protect against hackers that break into the system.
Is there any way that encrypting data stored on disk can provide additional protection? I don't think so. Given the need for programs to be able to encrypt and decrypt information automatically, I don't see how encryption could be done without storing the key in a location accessible by the program. This is what obviates the value of encrypting the data. Like I said, if the key and the encrypted data are accessible to a program on a particular system, then any user ID with *ALLOBJ has access to them. From the equation, substituting "access to clear-text data" for the key and the encrypted data shows that the access control mechanism alone is protecting the data.
One last argument some folks use is that encrypting the data on disk provides value because if the data is ever written to tape or the equivalent, it is protected while it is on the tape. Of course, this is only true if the key is not stored on the same tape as the data. But this means the data can only be retrieved if it is restored to the same system and the key is the same at the time it is restored. But using the same key also weakens the strength of the key. To maintain optimum protection, it must be changed periodically. Now you have a situation where the data encrypted on tape will not be available to you unless you put the key on the disk (or implement a manual method for saving keys and associating them with particular backup tapes).
Encryption or Access Control?
There is very little if any value to be derived from encrypting data that resides on disk. The nature of encryption, the accessibility requirements of data, and the impracticality of requiring decryption keys entered manually by human beings all lead to the conclusion that encrypting data stored on disk provides no additional protection of the data beyond that provided by the access control mechanism.
Encryption is most useful for protecting data when it is used in the absence of any other access control mechanism--as it travels across the Internet, for example.
So what should you do if you're a California company? Perhaps hire more savvy legislators. If that's not an option, then the approach I would take is to spend the least amount of money possible to provide some form of encryption. This way, if you do suffer a breach, you can at least show that you were attempting to meet the spirit of the law. But to really protect your data, encryption alone is not the answer. Implementing access control is. And this goes for the other 49 states as well.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online