The week before last the FBI announced that they had taken down the Coreflood bot-net of perhaps 2 million systems by taking over the command-and-control system.
This was a major event. It demonstrated that we do not simply have to tolerate the existence of hostile networks of compromised systems. It also demonstrated that law enforcement can be effective in the Internet.
Executive Assistant Director of the FBI’s Criminal, Cyber, Response and Services Branch, Shawn Henry. said, “These actions to mitigate the threat posed by the Coreflood botnet are the first of their kind in the United States and reflect our commitment to being creative and proactive in making the Internet more secure.”Communications.
Although most people were happy to see the Coreflood bot-net go, some have expressed concern about the tactics used in its recent take-down. They are concerned that these may be seen to legitimize behavior that, after decades of debate, have finally been seen to be illegitimate.
Federal prosecutors obtained a temporary restraining order allowing them to replace several identified Coreflood command-and-control (C&C) servers with their own servers, which were then used to send shutdown commands to the Coreflood malware.
One colleague responded by saying "Remote administration without permission is 'hacking.'" I will grant him his semantics without granting him his point.
The first time I said that, and I may well have been the first to do so, I said it in response to the clever child who had created an "anti-virus virus." Of course, the same things are wrong with the idea of an anti-virus virus as with any other virus. First, like any virus, the anti-virus would not have the permission or knowledge of the target system owner.
The real problem is that, independent of the intent or motive of the author, he cannot know enough about the network to predict how his virus will behave. It is difficult enough for him to predict the behavior of his program in a single system that he controls. It is almost impossible to predict its behavior in a population of hundreds of thousands of systems connected in an arbitrary network.
The Electronic Frontier Foundation technology director, Chris Palmer, said the method "is not a safe way to go about [disabling malware] and it's divergent with standard practice."
The "standard practice" that he defends is to simply take down the command-and-control servers, while leaving the bots active. This non-standard practice may not meet Mr.Palmer's test for "safe" but it meets mine for "effective."
We rightly fear the awesome power of government. The preservation of Liberty requires constant vigilance against the abuse of that power. Our colleagues who have questioned this action are right to do so. However, the existence of the question does not imply, nor should we infer, the obvious answer.
Note that in this case, the FBI did not initiate communication with arbitrary systems. It waited until the compromised systems came to it. It did not send a program. It simply sent a command in response to a request. It sent the most conservative command, that is, "shut-down," do nothing.
It is this act which offends my friends, the purists. They are offended, in part, because the executive branch has not been explicitly authorized by the legislature to so act. However, one suspects that if the executive had asked the legislature for this authority, the same, or other, "purists" would have opposed it.
Public Safety, like information security, often involves difficult ethical choices, the lesser of evils. Sometimes it even involves the use of coercion or force. Note that government is the only institution in our society that is empowered to use force.
In this instance the executive did not act unilaterally; the FBI did get a court order. These are not vigilantes. Moreover, if they can be entrusted to use force, they can be entrusted to act in the Internet in ways that are forbidden to the ordinary citizen. That the police do something does not give the citizen license to do the same thing.
I invite my anxious colleagues to rest easy. The Internet is safer and the FBI has not gone rogue.
A final word of caution. One should not infer that all bot-nets can be brought down by the same method. Those networks that use the same collaborative protocols that are used by the file sharing programs (e.g., bitTorrrent) and do not rely on out-of-band command and control will not yield to this method.
Those charged with protecting public safety and those protecting the information infrastructure will continue to be confronted with difficult ethical choices. That is why we are both called professionals and are paid the big bucks.
Tuesday, April 26, 2011
Tuesday, April 19, 2011
One More Lost Laptop
Recently an employee of British Petroleum reported "one more lost laptop." In this case the laptop contained records on 13000 victims of BP's oil spill. One does not have to be an application genius to figure out how complete and sensitive those records are or how much work they encapsulated.
Let's consider the possibility that that copy of those records was the only copy. Without even considering any damage that might arise from the disclosure, the loss of those records could be catastrophic to the subjects.
A current search of the web shows that a typical business laptop comes with 250GB of secondary storage (or 128GB of solid state storage for $150- premium). We used to run whole enterprises on that much storage.
Moreover, for $100, one can buy 4 times that much storage to carry in one's shirt pocket; that's right, one terra-byte, $100-. The cost of storage is halving every twelve months. Parkinson's Law of Storage says that data expands to fill the storage available to hold it.
The processor power of these devices is 1000 times what it was a decade ago and increasing exponentially. While "experts" have been predicting the knee in the Moore's law curve for a generation, we continue to push it out.
I now have three old laptops stacked one on top of another that I use for application and storage servers. I have three TBs of storage in my living room network. Daily I operate this network from mobile devices, one, called an iPhone, that I carry in my pocket.
Even in the office there is now a preference for laptops over desktops. Outside there is movement to more, and more mobile, devices, laptops to notebooks to netbooks to tablets to "smart-phones." Note that the only reason we continue to refer to these mobile computers as "smart-phones" is because we buy them from the phone company.
This is only likely to get better or worse, depending on your point of view. The cost per cpu cycle and per bit of storage is likely to fall by a factor of four in 3 to five years. As the price falls the number of devices sold increases and the absolute number of applications grows and the number of applications per device increases. Even the cost of software is falling as the number of copies that can be sold increases.
Five years ago we could not have imagined the applications that we use today. No more so can we anticipate the applications of five years, our planning horizon from now.
Come on guys. The risk is not about laptops. It is about CD Roms. It is about thumb-drives. It is about GBs, and then TBs on one's fingernail. It is about users who have never used a computer they could not carry. It is about powerful computers in one's pocket. It is about what one can buy for a $100-. it is about new use, uses, and users on a barely imaginable scale. All of this involves, not to say invites, risk on an a scarcely imaginable scale.
Consider the bad things that can happen to mobile systems, applications, and data that is less likely to happen to others. First, while robust, these devices can be dropped, broken, or can suffer mechanical or electronic failure. They can be lost or left. They can be stolen, usually for the property value but sometimes for the contents.
Recently we learned that ICE, Immigration and Customs Enforcement, is examining and impounding mobile devices at the borders. Ostensibly this is to look for "contraband" data, specifically child pornography. The courts have consistently held that this kind of search is "reasonable" enforcement of the borders and does not violate the Fourth Amendment prohibition against "unreasonable searches and seizures." In the twenty months of the program, ICE has "examined" more than 6000 systems.
For most of us, and while it is a growing one for frequent business travelers, this risk is dwarfed by the other risks of mobile devices. Like those, it is one to which the same applications and data are not vulnerable when done on stationary systems. It is addressed by some, but not all, of the same security measures.
For example, while loss and leakage are addressed by encryption, ICE will simply demand the key. More over, encryption offers no protection against the far more likely threat of failure or breakage.
On the other hand, not taking data or applications addresses everything except property loss. I now carry a sterile MacBook Air when I travel. No enterprise, client, personally identifiable information, intellectual property, payment system, or other sensitive data.
* Consider the following policies and practices:
* Store sensitive data only on enterprise servers.
* Prefer remote access to enterprise servers to personal, local, or portable copies.
* Save new work on mobile devices to stationary servers
* Permit portable copies only with specific management approval.
* Any portable copies on devices with full-device encryption.
* Any portable copies in encrypted file systems or databases.
* Prefer mobile devices (e.g., Blackberrys, iPads, iPhones) with remote location and remote erasure capabilities.
* Prefer client-server object-oriented databases (e.g., Lotus Notes) with end-to-end encryption by default.
Keep in mind that these are risk mitigation, not risk elimination, policies. Leakage from mobile devices is a fact of life. We cannot solve the general problem but we can address it for ourselves and our enterprises. Note that they do not mitigate the risk of loss or breakage of property.
Of course, even justifying, much less implementing, these policies and practices will not be easy. That is why we are called professionals and are paid the big bucks.
Let's consider the possibility that that copy of those records was the only copy. Without even considering any damage that might arise from the disclosure, the loss of those records could be catastrophic to the subjects.
A current search of the web shows that a typical business laptop comes with 250GB of secondary storage (or 128GB of solid state storage for $150- premium). We used to run whole enterprises on that much storage.
Moreover, for $100, one can buy 4 times that much storage to carry in one's shirt pocket; that's right, one terra-byte, $100-. The cost of storage is halving every twelve months. Parkinson's Law of Storage says that data expands to fill the storage available to hold it.
The processor power of these devices is 1000 times what it was a decade ago and increasing exponentially. While "experts" have been predicting the knee in the Moore's law curve for a generation, we continue to push it out.
I now have three old laptops stacked one on top of another that I use for application and storage servers. I have three TBs of storage in my living room network. Daily I operate this network from mobile devices, one, called an iPhone, that I carry in my pocket.
Even in the office there is now a preference for laptops over desktops. Outside there is movement to more, and more mobile, devices, laptops to notebooks to netbooks to tablets to "smart-phones." Note that the only reason we continue to refer to these mobile computers as "smart-phones" is because we buy them from the phone company.
This is only likely to get better or worse, depending on your point of view. The cost per cpu cycle and per bit of storage is likely to fall by a factor of four in 3 to five years. As the price falls the number of devices sold increases and the absolute number of applications grows and the number of applications per device increases. Even the cost of software is falling as the number of copies that can be sold increases.
Five years ago we could not have imagined the applications that we use today. No more so can we anticipate the applications of five years, our planning horizon from now.
Come on guys. The risk is not about laptops. It is about CD Roms. It is about thumb-drives. It is about GBs, and then TBs on one's fingernail. It is about users who have never used a computer they could not carry. It is about powerful computers in one's pocket. It is about what one can buy for a $100-. it is about new use, uses, and users on a barely imaginable scale. All of this involves, not to say invites, risk on an a scarcely imaginable scale.
Consider the bad things that can happen to mobile systems, applications, and data that is less likely to happen to others. First, while robust, these devices can be dropped, broken, or can suffer mechanical or electronic failure. They can be lost or left. They can be stolen, usually for the property value but sometimes for the contents.
Recently we learned that ICE, Immigration and Customs Enforcement, is examining and impounding mobile devices at the borders. Ostensibly this is to look for "contraband" data, specifically child pornography. The courts have consistently held that this kind of search is "reasonable" enforcement of the borders and does not violate the Fourth Amendment prohibition against "unreasonable searches and seizures." In the twenty months of the program, ICE has "examined" more than 6000 systems.
For most of us, and while it is a growing one for frequent business travelers, this risk is dwarfed by the other risks of mobile devices. Like those, it is one to which the same applications and data are not vulnerable when done on stationary systems. It is addressed by some, but not all, of the same security measures.
For example, while loss and leakage are addressed by encryption, ICE will simply demand the key. More over, encryption offers no protection against the far more likely threat of failure or breakage.
On the other hand, not taking data or applications addresses everything except property loss. I now carry a sterile MacBook Air when I travel. No enterprise, client, personally identifiable information, intellectual property, payment system, or other sensitive data.
* Consider the following policies and practices:
* Store sensitive data only on enterprise servers.
* Prefer remote access to enterprise servers to personal, local, or portable copies.
* Save new work on mobile devices to stationary servers
* Permit portable copies only with specific management approval.
* Any portable copies on devices with full-device encryption.
* Any portable copies in encrypted file systems or databases.
* Prefer mobile devices (e.g., Blackberrys, iPads, iPhones) with remote location and remote erasure capabilities.
* Prefer client-server object-oriented databases (e.g., Lotus Notes) with end-to-end encryption by default.
Keep in mind that these are risk mitigation, not risk elimination, policies. Leakage from mobile devices is a fact of life. We cannot solve the general problem but we can address it for ourselves and our enterprises. Note that they do not mitigate the risk of loss or breakage of property.
Of course, even justifying, much less implementing, these policies and practices will not be easy. That is why we are called professionals and are paid the big bucks.
Wednesday, April 6, 2011
Near Field Communication (NFC)
There is a new communication standard on the horizon. It is called Near Field Communication, NFC, ISO-18000-3, and you might want to spend a few minutes with the Wikipedia article on it. It has all sorts of wonderful applications. It has a number of security applications and, of course, security limitations and implications.
NFC is intended for use on mobile computers, such as "smart-phones" or PDAs, that the user will be likely to carry, like keys or a wallet, most of the time. More than a dozen implementations, mostly smart-phones, have been shipped or announced by manufacturers including Benq, Google, LG, Motorola, Nokia, Samsung, and others. Applications await sufficient numbers but payment application trials are planned for San Francisco and New York.
Proposed applications include mobile payment, smart card emulation, including EMV, transportation and theatre ticketing, electronic keys, identity documents, cryptographic key management, and dozens of others. Of course, while not requiring NFC, these same devices can be used to implement both token-based and out-of-band strong authentication.
One application of NFC is as a reader of passive RFID tags and passive emulation of RFID tags. For example, eCLOWN is a program for a Nokia NFC phone to read the RFID information on an e-passport.* As you are probably aware there is significant opposition to any use of RFID from those who fear that the value likely from such applications will not justify the leakage or other unintended consequences. This opposition is likely to include NFC. (That the ability to read this information might marginally reduce the cost of forging an e-passport is sufficient reason for some to resist the use of the technology altogether. This, in spite of the fact that an e-passport is much more difficult to forge than an ordinary one.)
The name derives from the inductive effect of the "near field," i.e., within two wave-lengths distance, of the antenna. The reliance of the technology on this effect limits its effective range to about 4cm but the "far field" effect of the antenna might leak information beyond the effective range, perhaps at a distance of a few meters. Because, unlike Bluetooth, NFC does not provide encryption, for some applications encryption such as SSL or Mime, might have to be implemented at a higher layer
NFC is low-power, 15ma, as well as near-fieled inductive, and consequently relatively low speed, 421 kbps. This is fast enough for security and financial applications but much too slow for streaming video or even surfing the web. However, it has one great advantage over competing technologies, i.e., connection setup time. While Bluetooth may take seconds to establish a peer-to-peer connection (after "pairing"), NFC takes less than a tenth of a second. (One proposed application of NFC is for pairing of Bluetooth.)
As with any technology that is vulnerable to eavesdropping and replay, NFC is weak, that is, "one-factor," authentication. Most of the security applications will require strong authentication, at least two factors and resistance to replay. To the extent that NFC is implemented on hand-held computers, a wide variety of authentication schemes will be open to application designers.
NFC signals via amplitude modulation; its ability to resist a the modification of a bit is a function of the strength of the modulation and the coding used. However, some NFC applications may have to provide encryption to resist data modification attacks.
Because NFC is low power, electronic jamming will be relatively easy. Of course, the same is true of Bluetooth. The experience with Bluetooth suggests that this is a vulnerability without a problem. However, NFC may not be suitable for applications where ultra-high availability is a requirement.
NFC devices are vulnerable to loss, along with any credentials, privileges, and capabilities associated with them. Applications should resist the use of lost devices by implementing lock-words for use of the device, remote disabling and erasure, and other security mechanisms. Abandoned NFC connections might be vulnerable to exploitation until and unless they time out. Therefore, devices and applications should be designed to time out in the minimum time adequate for the application.
Those of you that are followers of IGTV or of my blog know that I am a long time critic of the use of mag-stripe and PIN for our point-of-sale payment system. Outiside the US, EMV cards are being used to improve the system. However, progress is limited by implementations that are backward compatible with mag-stripe and PIN. Perhaps this is to be able to process the cards carried by American travelers.
Although there are trial EMV cards and merchants prepared to accept them in the US, there are no plans to deploy them widely, much less pervasively, or exclusively. This is in part because of the cost of cards and readers, and in part because they do not solve the "card-not-present" problem. It is in part because transiting the intervening payment card service providers is difficult.
Not only can NFC devices both emulate and read EMV cards, these smart devices can address the card-not-present problem for mail-order, phone order, and Internet commerce. Moreover, hand-held devices can emulate multiple cards and accounts, functioning as e-wallets and reducing the number of credentials and tokens that a consumer must carry.
Like many such technologies, Near Field Communication is inherently neither secure nor insecure. It is proposed in good faith and with high hopes for legitimate applications. However, I have now lived long enough to expect poor implementations, inappropriate uses, and unintended consequences for any novel technology. I am not without sympathy for those who fear technology in general and RFID in particular. I will be surprised if NFC is not chosen for some applications for which it will not be secure and for others where, as with mag-stripe and PIN, it will survive long after use has stressed it to the breaking point.
The "securability" and reliability of NFC applications will depend in large part on the devices on which they are implemented, that is, in the ability of those devices and their operating system software to resist application-to-application data leakage and interference. These mobile devices are already being used for financial transactions over the Internet and using graphical readers for bar codes or QR codes. However, it is clear that these systems will vary greatly in their ability to protect their applications and will rely to some degree upon their users and vendors to keep them sanitary and current. We must be prepared for the NFC technology to be blamed for any compromise with which it is even remotely associated.
Still, I am hopeful that NFC will find many security applications and "securible" implementations. I particularly hope that it will find application in the payment system, and, for example, by emulating EMV, encourage its adoption. We must design and chose carefully and apply and use conservatively. We should err on the safe side. We have to prepare diligently and advance cautiously. It will be difficult and risky and it will challenge our knowledge, skills, and abilities. That is why we are called professionals and are paid the big bucks.
* Step 2 of the instructions for using eCLOWN is "Insert the passport (crypto) key." It is silent on where to obtain this key. However, because there are many copies of the key, that will be, at best, difficult.
NFC is intended for use on mobile computers, such as "smart-phones" or PDAs, that the user will be likely to carry, like keys or a wallet, most of the time. More than a dozen implementations, mostly smart-phones, have been shipped or announced by manufacturers including Benq, Google, LG, Motorola, Nokia, Samsung, and others. Applications await sufficient numbers but payment application trials are planned for San Francisco and New York.
Proposed applications include mobile payment, smart card emulation, including EMV, transportation and theatre ticketing, electronic keys, identity documents, cryptographic key management, and dozens of others. Of course, while not requiring NFC, these same devices can be used to implement both token-based and out-of-band strong authentication.
One application of NFC is as a reader of passive RFID tags and passive emulation of RFID tags. For example, eCLOWN is a program for a Nokia NFC phone to read the RFID information on an e-passport.* As you are probably aware there is significant opposition to any use of RFID from those who fear that the value likely from such applications will not justify the leakage or other unintended consequences. This opposition is likely to include NFC. (That the ability to read this information might marginally reduce the cost of forging an e-passport is sufficient reason for some to resist the use of the technology altogether. This, in spite of the fact that an e-passport is much more difficult to forge than an ordinary one.)
The name derives from the inductive effect of the "near field," i.e., within two wave-lengths distance, of the antenna. The reliance of the technology on this effect limits its effective range to about 4cm but the "far field" effect of the antenna might leak information beyond the effective range, perhaps at a distance of a few meters. Because, unlike Bluetooth, NFC does not provide encryption, for some applications encryption such as SSL or Mime, might have to be implemented at a higher layer
NFC is low-power, 15ma, as well as near-fieled inductive, and consequently relatively low speed, 421 kbps. This is fast enough for security and financial applications but much too slow for streaming video or even surfing the web. However, it has one great advantage over competing technologies, i.e., connection setup time. While Bluetooth may take seconds to establish a peer-to-peer connection (after "pairing"), NFC takes less than a tenth of a second. (One proposed application of NFC is for pairing of Bluetooth.)
As with any technology that is vulnerable to eavesdropping and replay, NFC is weak, that is, "one-factor," authentication. Most of the security applications will require strong authentication, at least two factors and resistance to replay. To the extent that NFC is implemented on hand-held computers, a wide variety of authentication schemes will be open to application designers.
NFC signals via amplitude modulation; its ability to resist a the modification of a bit is a function of the strength of the modulation and the coding used. However, some NFC applications may have to provide encryption to resist data modification attacks.
Because NFC is low power, electronic jamming will be relatively easy. Of course, the same is true of Bluetooth. The experience with Bluetooth suggests that this is a vulnerability without a problem. However, NFC may not be suitable for applications where ultra-high availability is a requirement.
NFC devices are vulnerable to loss, along with any credentials, privileges, and capabilities associated with them. Applications should resist the use of lost devices by implementing lock-words for use of the device, remote disabling and erasure, and other security mechanisms. Abandoned NFC connections might be vulnerable to exploitation until and unless they time out. Therefore, devices and applications should be designed to time out in the minimum time adequate for the application.
Those of you that are followers of IGTV or of my blog know that I am a long time critic of the use of mag-stripe and PIN for our point-of-sale payment system. Outiside the US, EMV cards are being used to improve the system. However, progress is limited by implementations that are backward compatible with mag-stripe and PIN. Perhaps this is to be able to process the cards carried by American travelers.
Although there are trial EMV cards and merchants prepared to accept them in the US, there are no plans to deploy them widely, much less pervasively, or exclusively. This is in part because of the cost of cards and readers, and in part because they do not solve the "card-not-present" problem. It is in part because transiting the intervening payment card service providers is difficult.
Not only can NFC devices both emulate and read EMV cards, these smart devices can address the card-not-present problem for mail-order, phone order, and Internet commerce. Moreover, hand-held devices can emulate multiple cards and accounts, functioning as e-wallets and reducing the number of credentials and tokens that a consumer must carry.
Like many such technologies, Near Field Communication is inherently neither secure nor insecure. It is proposed in good faith and with high hopes for legitimate applications. However, I have now lived long enough to expect poor implementations, inappropriate uses, and unintended consequences for any novel technology. I am not without sympathy for those who fear technology in general and RFID in particular. I will be surprised if NFC is not chosen for some applications for which it will not be secure and for others where, as with mag-stripe and PIN, it will survive long after use has stressed it to the breaking point.
The "securability" and reliability of NFC applications will depend in large part on the devices on which they are implemented, that is, in the ability of those devices and their operating system software to resist application-to-application data leakage and interference. These mobile devices are already being used for financial transactions over the Internet and using graphical readers for bar codes or QR codes. However, it is clear that these systems will vary greatly in their ability to protect their applications and will rely to some degree upon their users and vendors to keep them sanitary and current. We must be prepared for the NFC technology to be blamed for any compromise with which it is even remotely associated.
Still, I am hopeful that NFC will find many security applications and "securible" implementations. I particularly hope that it will find application in the payment system, and, for example, by emulating EMV, encourage its adoption. We must design and chose carefully and apply and use conservatively. We should err on the safe side. We have to prepare diligently and advance cautiously. It will be difficult and risky and it will challenge our knowledge, skills, and abilities. That is why we are called professionals and are paid the big bucks.
* Step 2 of the instructions for using eCLOWN is "Insert the passport (crypto) key." It is silent on where to obtain this key. However, because there are many copies of the key, that will be, at best, difficult.
Tuesday, March 29, 2011
Lessons from the RSA Breach
As has already been reported on IGTV, RSA, the security division of EMC and the vendor of the SecurID two-factor authentication system and identity management services, has suffered a network breach. The limited disclosures suggest that this was a patient and resourceful attack intended to gain access to intellectual property. More specifically, RSA does not deny that at least one target was information about the SecurID system.
Whether or not this is a security problem, it has certainly been a public relations disaster. It is so bad that one government agency, that is a SecurID customer, has announced that they will switch to another product. Whether or not RSA has done the right thing in this case, it is clear that no one is happy with the way that they have handled it.
This is a case study in how difficult it is to handle a breach. The otherwise disinterested curious want full disclosure. On the other hand, the victim would like as little disclosure as possible. Customers want to know but do not want anyone else to know.
I am reminded of Franklin National Bank. A rogue trader lost about $50M dollars of the bank's money, painful but still only a fraction of the bank's capital. The bank managed to keep the loss "secret" for about ninety days. At that point, the Wall Street Journal reported it. In the next ninety days, the bank lost $2B in deposits and it failed. It could have survived the loss but was killed by the publicity.
As this case illustrates, the first concern that a victim has is to ensure that the publicity is not worse than the breach. What could be worse for a security company than to have to admit to ineffective security or a breach that reduces the effectiveness of products that they have already sold.
However, in fairness to RSA, they have other concerns. As a security company, they have an obligation to their customers to tell them about anything that diminishes the security that they think that they have purchased. They also have a responsibility to not make the situation worse by unnecessary disclosure.
They have a responsibility to cooperate with law enforcement. They want to protect the investigative process and the utility of the product of the investigation.
Now add to this that they really are not sure of the extent of the damage. The longer they delay disclosure, the more they know, the more certain they are of what they know. However, for more sophisticated and patient attacks, one may never be confident about the extent of its success or what information has been compromised.
Note that, as a target they owe a certain duty to peer target enterprises to share information that might be useful in protecting themselves. As a security company, they owe a certain duty to the security community at large to share information necessary to judge the effectiveness, or damage thereto, of the products and services that they offer.
As a vendor, they owe a duty to their customers. However, this duty may be different to those who purchase the SecurID tokens and servers and those to whom they also provide identity management and authentication services.
As security professionals, we can sympathize with this over-constrained problem. Few among us would like to be confronted with such a dilemma. None of this is to say that RSA has done the right thing or that this is not a PR disaster of epic proportions but only that we may never know enough to fairly judge what they have done. Microsoft has never divulged the details of the compromise of their development system.
If you are merely among the curious, a peer company, security professional, or prospective customer of RSA, you may never know what really happened.
You should know that:
The bad news is that RSA may never know exactly what happened; the rest of us will definitely never know.
The good news is that we know enough.
Most of us need only get over the fact that we will never know.
Most users of the tokens need not do anything.
Those of you whose principals are peer targets of RSA must talk to RSA and request a remedy. On the low side the remedy may be nothing. On the high side it may be replacement and re-enrollment of any compromised tokens. Under normal circumstances, one might have weeks to months to get this done. However, since we do not know when the breach took place, days to weeks is a safer time-frame.
A colleague of mine, one who knows this space and this company better than most, wonders that there should be any doubt, that token seeds would ever be connected to the enterprise network. Can you say hardened system?
I am uncomfortable with the expression "Advanced Persistent Threat' but the clear implication of it is that, at least for some identifiable set of enterprises, the threat environment has changed by an order of magnitude.
The heavy, not to say exclusive, reliance on perimeter security that we have used for a generation is no longer adequate. Real defense in depth must be the new order of the day. Defense in depth implies identification of the "crown jewels." It implies that the compromise of one, two, or even three or four defenses should not compromise them. It implies that no single insider can compromise them on purpose, much less by accident or error.
Since, based upon the Verizon data breach report, the time to detection of a compromise is measured in weeks-to-months, this data must be protected based on the assumption that there are compromised systems on the enterprise network. Some data must be behind an air-gap.
Systems and users that access external objects, for example, e-mail messages or web pages, may have to use application-only or locked-down systems to reduce compromise by taking bait. VPNs must terminate on the application, not on the perimeter, not on an operating system. These may be just some of the hard choices we will have to make.
Our choice is to adapt our security strategy to deal with the higher threat level or our public relations strategy to deal with the kind of breach that RSA is dealing with now. It is a difficult dilemma but that is why we are called professionals and are paid the big bucks.
Whether or not this is a security problem, it has certainly been a public relations disaster. It is so bad that one government agency, that is a SecurID customer, has announced that they will switch to another product. Whether or not RSA has done the right thing in this case, it is clear that no one is happy with the way that they have handled it.
This is a case study in how difficult it is to handle a breach. The otherwise disinterested curious want full disclosure. On the other hand, the victim would like as little disclosure as possible. Customers want to know but do not want anyone else to know.
I am reminded of Franklin National Bank. A rogue trader lost about $50M dollars of the bank's money, painful but still only a fraction of the bank's capital. The bank managed to keep the loss "secret" for about ninety days. At that point, the Wall Street Journal reported it. In the next ninety days, the bank lost $2B in deposits and it failed. It could have survived the loss but was killed by the publicity.
As this case illustrates, the first concern that a victim has is to ensure that the publicity is not worse than the breach. What could be worse for a security company than to have to admit to ineffective security or a breach that reduces the effectiveness of products that they have already sold.
However, in fairness to RSA, they have other concerns. As a security company, they have an obligation to their customers to tell them about anything that diminishes the security that they think that they have purchased. They also have a responsibility to not make the situation worse by unnecessary disclosure.
They have a responsibility to cooperate with law enforcement. They want to protect the investigative process and the utility of the product of the investigation.
Now add to this that they really are not sure of the extent of the damage. The longer they delay disclosure, the more they know, the more certain they are of what they know. However, for more sophisticated and patient attacks, one may never be confident about the extent of its success or what information has been compromised.
Note that, as a target they owe a certain duty to peer target enterprises to share information that might be useful in protecting themselves. As a security company, they owe a certain duty to the security community at large to share information necessary to judge the effectiveness, or damage thereto, of the products and services that they offer.
As a vendor, they owe a duty to their customers. However, this duty may be different to those who purchase the SecurID tokens and servers and those to whom they also provide identity management and authentication services.
As security professionals, we can sympathize with this over-constrained problem. Few among us would like to be confronted with such a dilemma. None of this is to say that RSA has done the right thing or that this is not a PR disaster of epic proportions but only that we may never know enough to fairly judge what they have done. Microsoft has never divulged the details of the compromise of their development system.
If you are merely among the curious, a peer company, security professional, or prospective customer of RSA, you may never know what really happened.
You should know that:
Six pieces of special knowledge are necessary to successfully authenticate to the RSA system:
* the (address of the) system that will accept the credential
* the user ID
* the PIN or passphrase
* the seed value
* the algorithm
* the association or bind among the first four
RSA does not know all of these things. Therefore, while a compromise of its systems might reduce the cost of attack, it cannot make it free or even trivial.
The algorithm has been reverse engineered and software that implements it is available for download.
The token is both a forgery-resistant artifact and a mechanism for resisting re-play. Knowledge of the seed lowers the cost of forgery but does not lower the cost of replay.
Since its compromise, RSA has encouraged all of its customers to monitor their authentication servers for evidence of attack against PINs and to encourage their users to employ strong PINs. This is good practice in any case but might be more important if there was reason to believe that any seeds have been compromised.
Under NDA, RSA has told some customers more. If you are a customer and if you are willing to agree not to share what they tell you, RSA may tell you more about the compromise. Note that, since you cannot discuss with others, you cannot verify everything, perhaps anything, that they tell you.
Finally, If one is using strong authentication and one is compromised, the most likely cause is that someone took bait and compromised the network.
The bad news is that RSA may never know exactly what happened; the rest of us will definitely never know.
The good news is that we know enough.
Most of us need only get over the fact that we will never know.
Most users of the tokens need not do anything.
Those of you whose principals are peer targets of RSA must talk to RSA and request a remedy. On the low side the remedy may be nothing. On the high side it may be replacement and re-enrollment of any compromised tokens. Under normal circumstances, one might have weeks to months to get this done. However, since we do not know when the breach took place, days to weeks is a safer time-frame.
A colleague of mine, one who knows this space and this company better than most, wonders that there should be any doubt, that token seeds would ever be connected to the enterprise network. Can you say hardened system?
I am uncomfortable with the expression "Advanced Persistent Threat' but the clear implication of it is that, at least for some identifiable set of enterprises, the threat environment has changed by an order of magnitude.
The heavy, not to say exclusive, reliance on perimeter security that we have used for a generation is no longer adequate. Real defense in depth must be the new order of the day. Defense in depth implies identification of the "crown jewels." It implies that the compromise of one, two, or even three or four defenses should not compromise them. It implies that no single insider can compromise them on purpose, much less by accident or error.
Since, based upon the Verizon data breach report, the time to detection of a compromise is measured in weeks-to-months, this data must be protected based on the assumption that there are compromised systems on the enterprise network. Some data must be behind an air-gap.
Systems and users that access external objects, for example, e-mail messages or web pages, may have to use application-only or locked-down systems to reduce compromise by taking bait. VPNs must terminate on the application, not on the perimeter, not on an operating system. These may be just some of the hard choices we will have to make.
Our choice is to adapt our security strategy to deal with the higher threat level or our public relations strategy to deal with the kind of breach that RSA is dealing with now. It is a difficult dilemma but that is why we are called professionals and are paid the big bucks.
Tuesday, March 22, 2011
The Internet as Infrastructure
Today, when one connects an application, system, or network to the public networks, one is adding to the "system of public works," that is to "infrastructure," of the nation and the world.
The standards for building infrastructure, such as bridges, tunnels, and dams, are different from those for other artifacts. Infrastructure must not fall of its own weight, it should not fail in normal use or under normal load, and must resist "easily anticipated abuse and misuse." A suspension bridge must not fall because a driver falls asleep and an eighteen wheeler goes over the side.
Notice that the abuse and misuse that can be easily anticipated today, is much worse than when we began the Internet. Were it not so, we might have done many things differently.
We call the resultant necessary property of infrastructure resiliency, rather than security, but the properties are related.
For any artifact, there are limits to the complexity, scale, load, and simultaneous component failures that the mechanism can be expected to survive. How many simultaneous sleepy drivers and plunging eighteen wheelers must a bridge be designed to survive.
When those limits are reached, what we want to happen is that the mechanism fail in such a way that damage is limited and the mechanism can be restored to operation as quickly as possible.
The three Great Northeastern Blackouts, of which August 14, 2003 was the latest, are examples. It is interesting that engineers see these blackouts as successes while the public and their surrogates, journalists and politicians, see them as failures.
All three were caused by multiple simultaneous and cascading component failures under conditions of heavy load. In all three cases the system failed in such a way that it was restored to a ninety percent service level in a day. While all three were spectacular and exciting, the damage was not nearly so severe as one might expect from a major ice storm.
This is the way that we would like the public networks to fail. In fact, so far, that is what we have seen. We have had massive local failures of the PSTN where it took days to weeks to restore to a ninety percent service level. Most of these were fire related and local. We have had one that was national and caused by a software change. We recovered from this one in hours.
To date, we have had a number of local failures of the Internet, all man-made (mostly caused by the infamous "cable-seeking backhoes or boat anchors"); most were accidental. We recovered from all of these in days. SQL/Slammer was man-made, malicious, and software related; it caused a noticeable drop in service for hours. However, there was not really a discontinuity of service.
It should be noted that SQL/Slammer was a homogenous attack. That is, every instance of it looked the same. This made it relatively easy to construct and deploy filters that would resist its flow while not interfering with normal traffic. However, it is fairly easy to visualize a heterogeneous attack that might overwhelm this remedy.
So, there is wide-spread concern that there might be a malicious software-based attack that would bring down the entire Internet. To some degree this is angst, an unfocused apprehension rooted in intuition or ignorance. However, it is shared by many who are knowledgeable. Their concern is rooted in the (often unidentified and un-enumerated) facts that:
* the Internet evolved; it was not designed and deployed
* switching in the network is software-based,
* operation of the components is homogenous
* operation of network management controls is in-band
* users often have default access to management controls
* the topology is both open and flat
* paths in the network are ad hoc and adaptive
* connection policy is permissive,
* most of the nodes in the network are un-trusted and a large number are under malicious control.
* access is open and cheap
* identity of both components and users is unreliable
* ownership and management is decentralized
* other
If the impact of these things on the resiliency of the Internet were as obvious prospectively as it is retrospectively, we might have done things differently. On the other hand, we might not have. A little discussion is in order.
Unlike the PSTN, the Internet is packet, rather than circuit, switched. The intent of this was to make the network more resilient in the face of node or link failures.
The routers and switches may be software running on von Neumann architecture general-purpose computers. This may make the network more resistant to component failure while making the components more vulnerable to malicious attack.
We have become accustomed to the idea that software processes are vulnerable to interference or contamination by their data, i.e., the software in the switch can be contaminated by its traffic. This exposes us to attacks intended to exploit, interfere with, or take control of switches and routers.
This may be aggravated by the fact that so many routers and switches look the same. While there are hundreds of products, most of them present controls that are operated via the Border Gateway Protocol (BGP). An attack that can take control of one might be able to take control of many.
Even most non-switch nodes in the network look the same, that is, like Windows or Unix (rather than, for example, MVS or OS/400.) These two operating systems are open, historically broken, and have a commitment to backward compatibility that makes them difficult to fix. Historically they have shipped with unsafe defaults and have been corrupted within minutes of being connected to the Internet. The result has been that there are millions of corrupt nodes in the Internet that are under the control of malicious actors.
Operation of the routers and switches (and other network nodes) is via the network itself; they can be operated from almost any node in the network. Many are hidden, if at all, only by a password, often weak or even default. Thus, it might be possible to coordinate simultaneous mis-operation of many nodes at the same time.
The Internet is open to as to user, attachment, protocol, and application. The cost of a connection to the Internet is a function of the bandwidth or load but the cost of a relatively fast persistent connection is in the tens of dollars per month, about the same as a dial connection a decade ago.
While one must demonstrate the ability to pay, usually with a credit card, the credit card may be stolen, and, depending on the provider, the name in which the connection is registered may not have to be the same as that on the credit card. In short, almost anyone can add a node to the Internet with minimal checks on their identity or bona fides. There will be bad actors.
The only thing that is required to add a new protocol or application to the Internet is that at least two nodes agree on it and that it can be composed from IP packets. Use of load-intensive protocols and applications for streaming audio and video were added to other protocols and applications with no changes to the underlying infrastructure. We have seen DoS attacks that relied upon minor changes to protocols and their use.
At least in theory, the topology of Internet is "flat," as opposed to structured or hierarchical. That is, at least in theory and with few exceptions, any node in the Internet can send a packet to any other node in the Internet. The time and cost to send a packet between any two nodes chosen at random is roughly the same as for any other pair of nodes.
Said another way, both the time and cost to send a packet are independent of distance. One implication of this is that attacks are cheap, can originate anywhere, and can attack anything attached.
Paths in the Internet are determined late, possibly on a packet by packet basis, and adapt to changes in load or control settings. The intent is that there be so many potential paths between A and B that at least one will always be available and that it will be discovered and used. While the intent is to make the network resistant to node and link failures, an unintended consequence is that it is difficult to resist the flow of attack traffic.
The original policies of the Internet were promiscuous (as opposed to permissive or restrictive); not only was any packet and flow permitted but there were no controls in place to resist them. This was essential to the its triumph over competitors like SNA and may have been necessary to its success.
While controls have been added as the scale has grown, the policy is still permissive, rather than restrictive, i.e., everything is allowed that is not explicitly forbidden.
Said another way, all traffic is presumed to be benign until shown otherwise. Attack traffic can flow freely until identified and restricted.
Finally, while most of the nodes in the Internet are untrusted, and we know that many are corrupted and under hostile control, all are given the benefit of the doubt. To date there has been little effort to identify and eliminate those that have been corrupted. Therefore there remains a possibility that these corrupt systems can be marshaled in such a way as to deny the use of network to all, or some targeted group, of users.
The Internet is robust, not fragile. It is resistant to both natural and accidental artificial events. However, To the extent that the above things are, and remain, true, the Internet, and indirectly, the nations, economies, institutions and individuals that rely upon, it are vulnerable to abuse and misuse; concern is justified, if not proportionate.
While these characteristics are pervasive and resistant to change, while they were often chosen for good reason, they are not fixed or required and can be changed. Understanding them and how they might be changed is key to making the Internet as resistant to abuse and misuse as it is to component failure or destruction.
It suggests that the network must become both less open, not to say, closed, and more structured. The management controls must be protected and taken out of band. The policy must become much more restrictive. We must identify our users and customers and hold them accountable for their traffic.
To bring the Internet to infrastructure standards, we must overcome not only inertia but also culture. Each of us must exercise our influence on our employers, clients, and vendors to move the Internet to the same standards that we expect of skyscrapers, bridges, tunnels, and dams. Since there is no one else to do it, we are called professionals and are paid the big bucks.
The standards for building infrastructure, such as bridges, tunnels, and dams, are different from those for other artifacts. Infrastructure must not fall of its own weight, it should not fail in normal use or under normal load, and must resist "easily anticipated abuse and misuse." A suspension bridge must not fall because a driver falls asleep and an eighteen wheeler goes over the side.
Notice that the abuse and misuse that can be easily anticipated today, is much worse than when we began the Internet. Were it not so, we might have done many things differently.
We call the resultant necessary property of infrastructure resiliency, rather than security, but the properties are related.
For any artifact, there are limits to the complexity, scale, load, and simultaneous component failures that the mechanism can be expected to survive. How many simultaneous sleepy drivers and plunging eighteen wheelers must a bridge be designed to survive.
When those limits are reached, what we want to happen is that the mechanism fail in such a way that damage is limited and the mechanism can be restored to operation as quickly as possible.
The three Great Northeastern Blackouts, of which August 14, 2003 was the latest, are examples. It is interesting that engineers see these blackouts as successes while the public and their surrogates, journalists and politicians, see them as failures.
All three were caused by multiple simultaneous and cascading component failures under conditions of heavy load. In all three cases the system failed in such a way that it was restored to a ninety percent service level in a day. While all three were spectacular and exciting, the damage was not nearly so severe as one might expect from a major ice storm.
This is the way that we would like the public networks to fail. In fact, so far, that is what we have seen. We have had massive local failures of the PSTN where it took days to weeks to restore to a ninety percent service level. Most of these were fire related and local. We have had one that was national and caused by a software change. We recovered from this one in hours.
To date, we have had a number of local failures of the Internet, all man-made (mostly caused by the infamous "cable-seeking backhoes or boat anchors"); most were accidental. We recovered from all of these in days. SQL/Slammer was man-made, malicious, and software related; it caused a noticeable drop in service for hours. However, there was not really a discontinuity of service.
It should be noted that SQL/Slammer was a homogenous attack. That is, every instance of it looked the same. This made it relatively easy to construct and deploy filters that would resist its flow while not interfering with normal traffic. However, it is fairly easy to visualize a heterogeneous attack that might overwhelm this remedy.
So, there is wide-spread concern that there might be a malicious software-based attack that would bring down the entire Internet. To some degree this is angst, an unfocused apprehension rooted in intuition or ignorance. However, it is shared by many who are knowledgeable. Their concern is rooted in the (often unidentified and un-enumerated) facts that:
* the Internet evolved; it was not designed and deployed
* switching in the network is software-based,
* operation of the components is homogenous
* operation of network management controls is in-band
* users often have default access to management controls
* the topology is both open and flat
* paths in the network are ad hoc and adaptive
* connection policy is permissive,
* most of the nodes in the network are un-trusted and a large number are under malicious control.
* access is open and cheap
* identity of both components and users is unreliable
* ownership and management is decentralized
* other
If the impact of these things on the resiliency of the Internet were as obvious prospectively as it is retrospectively, we might have done things differently. On the other hand, we might not have. A little discussion is in order.
Unlike the PSTN, the Internet is packet, rather than circuit, switched. The intent of this was to make the network more resilient in the face of node or link failures.
The routers and switches may be software running on von Neumann architecture general-purpose computers. This may make the network more resistant to component failure while making the components more vulnerable to malicious attack.
We have become accustomed to the idea that software processes are vulnerable to interference or contamination by their data, i.e., the software in the switch can be contaminated by its traffic. This exposes us to attacks intended to exploit, interfere with, or take control of switches and routers.
This may be aggravated by the fact that so many routers and switches look the same. While there are hundreds of products, most of them present controls that are operated via the Border Gateway Protocol (BGP). An attack that can take control of one might be able to take control of many.
Even most non-switch nodes in the network look the same, that is, like Windows or Unix (rather than, for example, MVS or OS/400.) These two operating systems are open, historically broken, and have a commitment to backward compatibility that makes them difficult to fix. Historically they have shipped with unsafe defaults and have been corrupted within minutes of being connected to the Internet. The result has been that there are millions of corrupt nodes in the Internet that are under the control of malicious actors.
Operation of the routers and switches (and other network nodes) is via the network itself; they can be operated from almost any node in the network. Many are hidden, if at all, only by a password, often weak or even default. Thus, it might be possible to coordinate simultaneous mis-operation of many nodes at the same time.
The Internet is open to as to user, attachment, protocol, and application. The cost of a connection to the Internet is a function of the bandwidth or load but the cost of a relatively fast persistent connection is in the tens of dollars per month, about the same as a dial connection a decade ago.
While one must demonstrate the ability to pay, usually with a credit card, the credit card may be stolen, and, depending on the provider, the name in which the connection is registered may not have to be the same as that on the credit card. In short, almost anyone can add a node to the Internet with minimal checks on their identity or bona fides. There will be bad actors.
The only thing that is required to add a new protocol or application to the Internet is that at least two nodes agree on it and that it can be composed from IP packets. Use of load-intensive protocols and applications for streaming audio and video were added to other protocols and applications with no changes to the underlying infrastructure. We have seen DoS attacks that relied upon minor changes to protocols and their use.
At least in theory, the topology of Internet is "flat," as opposed to structured or hierarchical. That is, at least in theory and with few exceptions, any node in the Internet can send a packet to any other node in the Internet. The time and cost to send a packet between any two nodes chosen at random is roughly the same as for any other pair of nodes.
Said another way, both the time and cost to send a packet are independent of distance. One implication of this is that attacks are cheap, can originate anywhere, and can attack anything attached.
Paths in the Internet are determined late, possibly on a packet by packet basis, and adapt to changes in load or control settings. The intent is that there be so many potential paths between A and B that at least one will always be available and that it will be discovered and used. While the intent is to make the network resistant to node and link failures, an unintended consequence is that it is difficult to resist the flow of attack traffic.
The original policies of the Internet were promiscuous (as opposed to permissive or restrictive); not only was any packet and flow permitted but there were no controls in place to resist them. This was essential to the its triumph over competitors like SNA and may have been necessary to its success.
While controls have been added as the scale has grown, the policy is still permissive, rather than restrictive, i.e., everything is allowed that is not explicitly forbidden.
Said another way, all traffic is presumed to be benign until shown otherwise. Attack traffic can flow freely until identified and restricted.
Finally, while most of the nodes in the Internet are untrusted, and we know that many are corrupted and under hostile control, all are given the benefit of the doubt. To date there has been little effort to identify and eliminate those that have been corrupted. Therefore there remains a possibility that these corrupt systems can be marshaled in such a way as to deny the use of network to all, or some targeted group, of users.
The Internet is robust, not fragile. It is resistant to both natural and accidental artificial events. However, To the extent that the above things are, and remain, true, the Internet, and indirectly, the nations, economies, institutions and individuals that rely upon, it are vulnerable to abuse and misuse; concern is justified, if not proportionate.
While these characteristics are pervasive and resistant to change, while they were often chosen for good reason, they are not fixed or required and can be changed. Understanding them and how they might be changed is key to making the Internet as resistant to abuse and misuse as it is to component failure or destruction.
It suggests that the network must become both less open, not to say, closed, and more structured. The management controls must be protected and taken out of band. The policy must become much more restrictive. We must identify our users and customers and hold them accountable for their traffic.
To bring the Internet to infrastructure standards, we must overcome not only inertia but also culture. Each of us must exercise our influence on our employers, clients, and vendors to move the Internet to the same standards that we expect of skyscrapers, bridges, tunnels, and dams. Since there is no one else to do it, we are called professionals and are paid the big bucks.
Saturday, February 26, 2011
The Internet Kill Switch
Recently in response to the activism in Egypt, President Mubarak "shut down" the Internet. While there is some question as to how effective this was, to the extent that it worked at all, it was because there were only two Internet service providers and they were creatures of the decades old "emergency" government.
Currently, prompted by fearful but impotent bureaucrats, the US Congress is considering giving a similar authority to the President of the United States. Needless to say, there is organized opposition to any such expansion of government authority.
In response to the opposition, a colleague wrote as follows:
The overt premise here is that the Internet "can be used as a weapon." While I concede that any infrastructure, indeed any artifact, can be misused, it is absurd on its face to compare such misuse to weapons like bombs and shells. The implicit assumption is that shutting it down is an effective defense. My mother called such a defense "cutting off one's nose to spite one's face."
Moreover, the analogy does not hold. One does not need the mayor to shut off the water. The water department will do it; they need no additional authority to do so. What is perhaps more important, they can be relied upon to do so in the least disruptive way. They can be relied upon to preserve as much of the capacity as possible.
Think about SQLSlammer. First it did not respect national boundaries. Second, before the governments of the world were even aware there was a problem, the network operators recognized, identified, and filtered the disruptive traffic. They did not seek permission but their judgment was so good and their action so measured that no one has ever even questioned them, much less faulted them, for this preemptive, not to say precipitous, action.
I am unable to envision any attack against, or via, the Internet where killing it is not worse than the attack. Indeed, the closest thing that we have seen to an Internet attack was the denial of service attack against Estonia. While one can imagine a politician using a kill switch in such a situation, it would be a solution at least as bad as the problem.
Most of the use of the Internet in warfare will be for intelligence gathering. Most of this will use open sources; attacks against hidden sources will be covert and low-intensity but in no case sufficient justification for shutting down the Internet. Adversaries may wish to deny one another its use in time of crisis but killing it simply plays into this.
However, what we have been taught to fear is the use of the Internet to mis-operate the controls of other infrastructure. The Congress has heard testimony that this risk is overstated but in any case, the proper defense is local to those controls, not a global shut-down.
I am unable to envision any case where the POTUS is better equipped to make decisions about the operation of the Internet than those who operate it day to day. Can you envision any case in which such a decision would not be political?
Indeed, to the extent that one believes in "Cyber War," one might ask whether a political decision by one country to "kill" the Internet might not be seen as an act of war by it's neighbors. We certainly saw the political decision by the President of Egypt to shut down the Internet as an act of oppression, not to say war, against his citizens. Indeed, it is far easier to envision such a capability being used offensively against one's own citizens than defensively against any adversary.
The Internet is designed to resist any and all attempts to shut it down. It should, can, and does survive multiple simultaneous component failures. Moreover, it is a poor respecter of national boundaries. Where would you propose to place such a control?
On the other hand, it is quite easy, particularly in light of recent events, to envision such authority being used to manipulate, intimidate, or control for political reasons. Like the USA Patriot Act, this kind of authority simply begs for misuse and abuse. For my comfort, both T and VZ are already far too willing, not to say anxious, to cooperate with the political authorities.
Before you support this proposal further, I suggest that you go to YouTube and reprise Michael Chertoff's demonstration of government crisis decision making. Instead of listening to them whine about their lack of authority, watch the process. Then ask yourself what the network operators are doing while this process is going on.
Government is the tool one uses when one wants to kill hundreds of thousands of people. It is really terrible at, for example, surgery, or other measured responses. There is a reason that we divide and limit it's powers.
Be careful what you ask for; you might get it.
* Quoted with implied permission form SANS Newsbites.
Currently, prompted by fearful but impotent bureaucrats, the US Congress is considering giving a similar authority to the President of the United States. Needless to say, there is organized opposition to any such expansion of government authority.
In response to the opposition, a colleague wrote as follows:
Editor's Note (Schultz): Opponents of giving the U.S. President the
right to shut down the Internet are like those who oppose a mayor of a city being flooded by broken water mains being given the right to shut off the water. As useful as it is, the Internet is also capable of being used as a destructive weapon, and at least to some degree it has already been used in this way numerous times. Someone must have the authority to make decisions concerning its continued operation in case it is used outright as a weapon.*
The overt premise here is that the Internet "can be used as a weapon." While I concede that any infrastructure, indeed any artifact, can be misused, it is absurd on its face to compare such misuse to weapons like bombs and shells. The implicit assumption is that shutting it down is an effective defense. My mother called such a defense "cutting off one's nose to spite one's face."
Moreover, the analogy does not hold. One does not need the mayor to shut off the water. The water department will do it; they need no additional authority to do so. What is perhaps more important, they can be relied upon to do so in the least disruptive way. They can be relied upon to preserve as much of the capacity as possible.
Think about SQLSlammer. First it did not respect national boundaries. Second, before the governments of the world were even aware there was a problem, the network operators recognized, identified, and filtered the disruptive traffic. They did not seek permission but their judgment was so good and their action so measured that no one has ever even questioned them, much less faulted them, for this preemptive, not to say precipitous, action.
I am unable to envision any attack against, or via, the Internet where killing it is not worse than the attack. Indeed, the closest thing that we have seen to an Internet attack was the denial of service attack against Estonia. While one can imagine a politician using a kill switch in such a situation, it would be a solution at least as bad as the problem.
Most of the use of the Internet in warfare will be for intelligence gathering. Most of this will use open sources; attacks against hidden sources will be covert and low-intensity but in no case sufficient justification for shutting down the Internet. Adversaries may wish to deny one another its use in time of crisis but killing it simply plays into this.
However, what we have been taught to fear is the use of the Internet to mis-operate the controls of other infrastructure. The Congress has heard testimony that this risk is overstated but in any case, the proper defense is local to those controls, not a global shut-down.
I am unable to envision any case where the POTUS is better equipped to make decisions about the operation of the Internet than those who operate it day to day. Can you envision any case in which such a decision would not be political?
Indeed, to the extent that one believes in "Cyber War," one might ask whether a political decision by one country to "kill" the Internet might not be seen as an act of war by it's neighbors. We certainly saw the political decision by the President of Egypt to shut down the Internet as an act of oppression, not to say war, against his citizens. Indeed, it is far easier to envision such a capability being used offensively against one's own citizens than defensively against any adversary.
The Internet is designed to resist any and all attempts to shut it down. It should, can, and does survive multiple simultaneous component failures. Moreover, it is a poor respecter of national boundaries. Where would you propose to place such a control?
On the other hand, it is quite easy, particularly in light of recent events, to envision such authority being used to manipulate, intimidate, or control for political reasons. Like the USA Patriot Act, this kind of authority simply begs for misuse and abuse. For my comfort, both T and VZ are already far too willing, not to say anxious, to cooperate with the political authorities.
Before you support this proposal further, I suggest that you go to YouTube and reprise Michael Chertoff's demonstration of government crisis decision making. Instead of listening to them whine about their lack of authority, watch the process. Then ask yourself what the network operators are doing while this process is going on.
Government is the tool one uses when one wants to kill hundreds of thousands of people. It is really terrible at, for example, surgery, or other measured responses. There is a reason that we divide and limit it's powers.
Be careful what you ask for; you might get it.
* Quoted with implied permission form SANS Newsbites.
Monday, September 13, 2010
What does it Mean to Say a System is Trusted?
Do not trust any computer that you cannot carry; prefer those that you can put in your pocket.
Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment.
- Robert H. Courtney
That little aphorism of Bob Courtney's has become a habitual touchstone for me. If it has not given me gravitas, it has at least kept me from appearing foolish by opining on the "security" of systems without regard to the threat or what they are being used for. It keeps me from equating the security of the application with that of the system or vice versa. It enables me to use a system for one application that is not suitable for others. It enables me to recognize when the security of a system that has served well is no longer adequate. (Many seem to get by simply saying that no system or application is secure. One can clearly get one's name in the paper by saying that. It is not particularly helpful.)
Part of the problem is that we came to the question the wrong way. In the early days of computers they were serially reused and had no shared resources. Most of the applications were not sensitive. The question simply did not arise. After a decade or so, we began to recognize that there was a small potential for information to leak from job to job because of the failure to wipe primary storage between jobs. Information left in memory by job n might be available to job n +1.
The problem really emerged with true shared-resource computing in the sixties. Even here the problem was tolerable. The systems were operated by a single enterprise, most of the users knew one another, and they shared similar goals and objectives.
By the late sixties, the size of user populations had begun to be numbered in the high tens to low hundreds and the modern question was on us. The potential for information to leak from one user to another was on us. One clear method by which it might happen was the interference of one process with another. The problem now had a name. Research began. While we thought that it was important, computer use was still so sparse that it wasn't really.
However, these were the days of Grosch's Law where we believed that shared resource systems were inevitable and the scale of sharing would continue to rise forever. We believed that one should always use the biggest computer one could afford. We believed that computers should be scaled to the enterprise. Thus, the problem of data security was framed as that of security in multi-user multi-application systems. We had framed the question in a way that made it almost impossible to talk about, much less answer. We knew that there was an objective called data security but the environment in which we wanted to talk about it was so complex that language failed us.
Tomorrow we will look at some of the attempts.
Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment.
- Robert H. Courtney
That little aphorism of Bob Courtney's has become a habitual touchstone for me. If it has not given me gravitas, it has at least kept me from appearing foolish by opining on the "security" of systems without regard to the threat or what they are being used for. It keeps me from equating the security of the application with that of the system or vice versa. It enables me to use a system for one application that is not suitable for others. It enables me to recognize when the security of a system that has served well is no longer adequate. (Many seem to get by simply saying that no system or application is secure. One can clearly get one's name in the paper by saying that. It is not particularly helpful.)
The client was a property and casualty insurance company. They had some fairly progressive programs under way but both their IT and security programs were mature and stable. We were called in because they expected that they were going to have a number of new e-commerce applications done on the public network. They wanted a security management system to ensure that these applications would be done conservatively.
The method that we used was to propose a straw-man for the management system and then refine it in ever larger meetings. One of the practices that we recommended was that connected applications be done on dedicated hardware; we wanted to be sure that these applications were free from outside interference or contamination. In an early meeting the client asked that this recommendation be changed to say that these applications be done on "trusted systems." We quickly realized that that was a better way to say what we were trying to say. It included our recommendation but was stated as an objective rather than a specific practice.
Then we discovered that the reason that they wanted it restated was because they intended to run the application on their MVS mainframe. "MVS," we said. "You trust MVS?" "No," they said, "We trust our MVS. We have had it for twenty years, we manage it scrupulously, and we trust it." The auditors nodded their heads and then we nodded ours.
Part of the problem is that we came to the question the wrong way. In the early days of computers they were serially reused and had no shared resources. Most of the applications were not sensitive. The question simply did not arise. After a decade or so, we began to recognize that there was a small potential for information to leak from job to job because of the failure to wipe primary storage between jobs. Information left in memory by job n might be available to job n +1.
The problem really emerged with true shared-resource computing in the sixties. Even here the problem was tolerable. The systems were operated by a single enterprise, most of the users knew one another, and they shared similar goals and objectives.
By the late sixties, the size of user populations had begun to be numbered in the high tens to low hundreds and the modern question was on us. The potential for information to leak from one user to another was on us. One clear method by which it might happen was the interference of one process with another. The problem now had a name. Research began. While we thought that it was important, computer use was still so sparse that it wasn't really.
However, these were the days of Grosch's Law where we believed that shared resource systems were inevitable and the scale of sharing would continue to rise forever. We believed that one should always use the biggest computer one could afford. We believed that computers should be scaled to the enterprise. Thus, the problem of data security was framed as that of security in multi-user multi-application systems. We had framed the question in a way that made it almost impossible to talk about, much less answer. We knew that there was an objective called data security but the environment in which we wanted to talk about it was so complex that language failed us.
It was at about this time, 1968 or 1969 that I first met Dr. Willis Ware of the Rand Corporation. He came to White Plains for an IBM briefing on computer security. One item on the agenda was my master work, security for IBM's Advanced Administrative System. This system was intended for 5000 users and ultimately served several times that. It was a multi-user multi-application system but it was operated in a static mode, i.e., programs could not be changed while the system was operating. Users could not program and programmers could not use.So the question of whether or not a system was secure or not had to be addressed not only in the context of sharing of arbitrary applications and data by an arbitrary number of users but there could be no assumptions about the flexibility or generality reserved to any of those users. One might well conclude that such a question excludes any useful answer but that did not keep us from trying.
I was justifiably proud of the access control for the system. It was the largest and most complete system of its kind and it worked. The operating system was hidden from the users and the access controls for users to applications ran at the application layer. Dr. Ware listened politely and then dismissed the whole effort as trivial. Years later, when we had become friends, I found that he did not even remember it. He dismissed it on the basis that it did "not address the general case, the one where any user could write and execute a program of his own choice."
Tomorrow we will look at some of the attempts.
Subscribe to:
Posts (Atom)
Posts
