On the Real Risk of Thumb-drives
The first disk drive that I ever saw was the size and weight of a refrigerator and gave off as much heat. It would hold one megabyte. It was so expensive that it was far more likely to be used for tables than for files or databases. At the same time, the storage medium of choice was punched paper, cards or tape. A gigabyte in punched cards would fill a railroad box car.
The first hard drive that I bought was 10mb and cost me $3000 at IBM employee price. I thought I would never use it up. One can now buy a terabyte in a cigar box for $115 (I kid you not!) and for $50 one can buy 320GB that will fit in one's shirt pocket.
This week I bought an 8GB micro-SDHC card. It is the size of my fingernail. I paid $18 plus $4 shipping and handling although it could have been sent first class mail for less than a $1. A great portion of the cost is in the transaction, not the materials nor even the technology.
I thought that the SD card, the size of a postage stamp, was as small as a storage device would ever get. Smaller than that, one can hardly label or keep up with. However, the devices in which the storage is used are getting smaller and thus the microSD.
About every decade or so, as storage gets smaller, denser, and cheaper, managers began to worry that its very existence will encourage data theft. One could carry a 2400' reel of tape in one's overcoat or send out half a dozen in the waste paper basket. Multiple diskettes could be carried in a shirt pocket. Said another way, it has been a long time since the weight or the volume of the data was a deterrent to its theft.
However, we are going through the panic again. This time it is "USB drives." For example, a recent press release said "Lumension’s 2008 Annual Report and Threat Predictions for 2009 finds removable media as “the leading cause of data breaches…."
Dr. Peter Tippett reports, "It is endless talk among very large company CIO’s and CSO/CISOs that I speak with every week.. I think the driver is that everyone has a small case that happened in their shop, or that they heard about among their peers.... Then they have a “wouldn’t it be horrible if” worst case scenario they dream up relative to their own data.. And voila! It is the worst thing."
The other hand, in the 500 cases that Verizon reports on in its Data Breach Report, there were no cases in which thumbdrives (or other small portable media) played more than an incidental role. In no case did it appear necessary to the success of the breach, much less was it “causal.”
Even DoD leadership has been panicked by ‘thumb drives.’ Rather than control access to the data, they are trying to resist the technology. They no longer permit, at least as a matter of policy, portable digital media inside secure computing facilities, only paper. In some commands they do not permit the use of thumbdrives on (user owned) laptops attached to their networks. Anyone else see the irony here?
Now we all understand the limits of such controls. Modern storage is now so dense that one can conceal and carry an entire database inside any body cavity. (Yes, in certain extreme instances, authorities do search body cavities; this is usually law enforcement, not security, and in no case is it routine.) One can no more resist leakage by resisting media, digital or analog, than one can resist the use of computers, networks, or, for that matter, paper. The economics are simply against it. We pay extra for small and dense.
The way to resist data leakage is to restrict access to the sensitive, proprietary, or personally identifiable information, near the source (e.g., at the database server) and hold people accountable for its use. It is difficult to do but it is orders of magnitude more efficient than chasing the new tiny media de jour. It is far easier to control what data is copied than to control where it is copied or what happens to the copy. Data access control is media independent. Said another way, it works for all media, including the network, now and in the future, not just the one that one that is topical.
When I was a small boy and first went out to play without supervision, my mother said, “Son, never ever take thumbdrives from strangers.” When I got a little older, my daddy said, “Son, never ever put your thumbdrive in a strange machine.” I assume that someone cautioned my sister not to let anyone put their thumbdrive in her machine.”
The real risk of portable media is not data leakage but system contamination.
Saturday, July 17, 2010
Wednesday, May 19, 2010
Encryption by Default
A recent survey was reported as follows:
Pasted from www.computerworld.com/s/article/9176889/Survey_Gov_t_agencies_use_unsafe_methods_to_transfer_files?taxonomyId=17>
Stephen Northcutt, writing as an editor of SANS Newsbites, observes:
In another context this week I was reminded of a lesson I learned a long time ago, "One must make the desired behavior at least marginally easier than the wrong behavior." Almost by definition, "harder to do it right" is too hard.
Twenty years ago we were very concerned that user credentials would be compromised in the network. Today with activity more than a 1000 times what it was twenty years ago, credentials are compromised at the end points, not in the network. The reason is that for data in motion we use encryption. We use SSL. Thanks to Netscape, we use it by default.
When we say our prayers at night we should say, "Thanks for Netscape." Netscape understood that encryption in the World Wide Web was essential, like brakes on a car, not optional. They made it standard, not a separately priced feature. It was included in the function and price of the server. Thinking back on my time at IBM, I have often thought that had IBM invented SSL, they might well have priced it as an option and it would have failed. The way we price things often influences how we think of them and how we use them.
Even though the software is not separately priced, SSL has to be turned on and, at the level of its current default use, it has a significant cost. Nonetheless, we use it pervasively and users have come to expect it. We use it by default. If either party expects it, the other party can hardly avoid it.
Note that the problem addressed by the survey is identified as "file transfer," much of which is not even done in the network but on portable media, on what we used to call the "sneaker net." Much of it is ad hoc, with no standard procedures. Management has not told employees how to transfer data, much less how to do it securely.
The data leaks in dozens of ways. It leaks when users make gratuitous copies and then loses them. It leaks when backup copies fall off the back of the truck. It leaks when hackers compromise servers. It leaks through the user interface of ftp servers and other ways too numerous to enumerate. The user does not even contemplate most of these leakage modes and believes that the ones that he does contemplate are too rare to worry about.
Stephen Northcutt points out that PGP can be used to resist most of these leaks. Even simpler tools like passwords on .doc and .pdf files would resist many of them. PKZip and sftp are powerful tools to help us. However, most of these solutions require user involvement and a high level of user knowledge, not to mention judgment and initiative.
The solution to the problem includes making using encryption on all data easier than not, to make the encryption of data at rest the default, not the exception. It includes providing encryption by default across enterprises. It includes resisting gratuitous copies at the end points, even where the use requires that the data must be in the clear. It includes management direction and automated procedures to implement that direction.
A tall order you say? Suppose I told you that encryption by default is routine, automagic, in many enterprise and government domains and even across domains? True. Just for an example, Lotus Notes protects files and databases at rest, by default, using encryption. Even if one makes a gratuitous copy of the file on one's laptop or thumb-drive, it is encrypted. Notes provides for automatic safe exchange across domains. It provides for automatic key management that is transparent to the users. Obtaining copies of these files and databases in the clear requires both privileges and work. In this environment, it is easier to do it the right way. Indeed, it is so easy that many, not to say most, users do not even know that it is happening.
Though I believe that it is under-sold and under-appreciated, I am not here to sell Lotus Notes. I use it merely as an example of "encryption by default." I believe that encryption by default should be the standard in all government agencies and most private enterprises, and that we have at least one successful model of how to achieve it.
IDG News Service - Employees at many U.S. government agencies are using unsecure methods, including personal e-mail accounts, to transfer large files, often in violation of agency policy, according to a survey.
Pasted from www.computerworld.com/s/article/9176889/Survey_Gov_t_agencies_use_unsafe_methods_to_transfer_files?taxonomyId=17>
Stephen Northcutt, writing as an editor of SANS Newsbites, observes:
I agree that too many people use insecure means to move data; disagree the root cause is no access to encryption.
A lot of people have access to encryption for email at work and yet consistently send data in the clear. We discuss this in the class I author and teach, and I think we as a community are becoming numb to the dangers we face from the Internet. Pretty Good Privacy (PGP) has been around almost 20 years now. In the early days, when you went to conferences, they had PGP signing parties and almost all the security professionals I interacted with had PGP and a key. Now, almost nobody seems to use it outside of FIRST, AV Research and similar enclaves...(stephen@sans.edu).
In another context this week I was reminded of a lesson I learned a long time ago, "One must make the desired behavior at least marginally easier than the wrong behavior." Almost by definition, "harder to do it right" is too hard.
Twenty years ago we were very concerned that user credentials would be compromised in the network. Today with activity more than a 1000 times what it was twenty years ago, credentials are compromised at the end points, not in the network. The reason is that for data in motion we use encryption. We use SSL. Thanks to Netscape, we use it by default.
When we say our prayers at night we should say, "Thanks for Netscape." Netscape understood that encryption in the World Wide Web was essential, like brakes on a car, not optional. They made it standard, not a separately priced feature. It was included in the function and price of the server. Thinking back on my time at IBM, I have often thought that had IBM invented SSL, they might well have priced it as an option and it would have failed. The way we price things often influences how we think of them and how we use them.
Even though the software is not separately priced, SSL has to be turned on and, at the level of its current default use, it has a significant cost. Nonetheless, we use it pervasively and users have come to expect it. We use it by default. If either party expects it, the other party can hardly avoid it.
Note that the problem addressed by the survey is identified as "file transfer," much of which is not even done in the network but on portable media, on what we used to call the "sneaker net." Much of it is ad hoc, with no standard procedures. Management has not told employees how to transfer data, much less how to do it securely.
The data leaks in dozens of ways. It leaks when users make gratuitous copies and then loses them. It leaks when backup copies fall off the back of the truck. It leaks when hackers compromise servers. It leaks through the user interface of ftp servers and other ways too numerous to enumerate. The user does not even contemplate most of these leakage modes and believes that the ones that he does contemplate are too rare to worry about.
Stephen Northcutt points out that PGP can be used to resist most of these leaks. Even simpler tools like passwords on .doc and .pdf files would resist many of them. PKZip and sftp are powerful tools to help us. However, most of these solutions require user involvement and a high level of user knowledge, not to mention judgment and initiative.
The solution to the problem includes making using encryption on all data easier than not, to make the encryption of data at rest the default, not the exception. It includes providing encryption by default across enterprises. It includes resisting gratuitous copies at the end points, even where the use requires that the data must be in the clear. It includes management direction and automated procedures to implement that direction.
A tall order you say? Suppose I told you that encryption by default is routine, automagic, in many enterprise and government domains and even across domains? True. Just for an example, Lotus Notes protects files and databases at rest, by default, using encryption. Even if one makes a gratuitous copy of the file on one's laptop or thumb-drive, it is encrypted. Notes provides for automatic safe exchange across domains. It provides for automatic key management that is transparent to the users. Obtaining copies of these files and databases in the clear requires both privileges and work. In this environment, it is easier to do it the right way. Indeed, it is so easy that many, not to say most, users do not even know that it is happening.
Though I believe that it is under-sold and under-appreciated, I am not here to sell Lotus Notes. I use it merely as an example of "encryption by default." I believe that encryption by default should be the standard in all government agencies and most private enterprises, and that we have at least one successful model of how to achieve it.
Wednesday, May 12, 2010
Security in "The Cloud"
Plus ça change, plus c'est la même chose.
When T.V. Learson was leading IBM, he was asked by a customer whether his IT should be centralized or decentralized. Learson responded that whatever way he was currently organized he should change it. Said another way, "What goes around, comes around."
In the early days of shared resource computing, the computer and most of the data resources were owned by the enterprise. "Data security," as we called it then, meant that what the enterprise said it intended, what it intended it did. We tried to help them think about it by suggesting the properties of the data that the enterprise most wanted to conserve. In some proportion of one to the others, the enterprise wanted the data to exhibit confidentiality, integrity, and availability.
To the extent that Grosch's Law described the economics, i.e., efficiency increased with scale, the economics favored centralization. Similarly, protection and control was also centralized. The risk was information leakage. The control of interest was Data Access Control, usually implemented as an optional process of the operating system.
In some cases use was metered and cost allocated but often cost was simply absorbed by the enterprise. This was in part because the meters and metrics of cost and value were immature. Metering and cost allocation were expensive and often had perverse effects on usage and uses.
At some point, Grosch's Law gave way to Moore's Law. Efficiency began to favor the small. When the scale of computing changed, it was not so much that data in the glass house moved to departmental and personal systems, although copies clearly did, as that data in departmental paper files got sucked in to the departmental and personal system, increasing the number of electronic records. At the same time, all computers were being connected to the Internet, making them and their data more vulnerable to attack by outsiders.
At about the same time as the scale was changing, we went from talking about "data security" to "information assurance," reflecting a shift in priority from confidentiality to integrity. Protection and control moved from centralized to distributed. The risk shifted to system contamination with malicious code. While we still used data access control, we relied more upon control of access to systems and applications. Other controls of interest included anti-virus, firewalls, and cryptography.
At this writing, we are discussing what security means in "cloud" computing. The name, cloud, for this style of computing comes form the cloud symbol that we used in network diagrams to represent that which was not known or beneath the level of abstraction at which we were working.
NIST defines cloud computing as "a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources" (e.g., networks, servers, storage, applications, software, and other services) "that can be rapidly provisioned and released with minimal management effort or service provider interaction."
However useful one may find the definition, some examples may help to appreciate the concept. The earliest emergent examples really define the cloud. Perhaps the most important of these is the Domain Name Service (DNS). E-mail and the World Wide Web are also on the list. Note that these are collaborative services, instantiated by the cooperation of many edge processes. For most users, their cost is included in the cost of their connection.
An early example is Hotmail, an advertising supported personal e-mail service. A more recent competitor to Hotmail is gmail from Google. As a personal service gmail is ad supported but Google also offers a service to "outsource" corporate e-mail. Instead of operating its own e-mail servers, an enterprise contracts with Google.
E-mail is an example of an application level service Dropbox is an example of a private file service in the cloud. Carbonite is an example of a backup service. IBM and EMC offer segment level storage backup. Indeed, they will operate an enterprise's entire storage network for them. Amazon offers a complete web storefront Think about almost anything that is hidden behind a standard service interface; it is available as a service in the cloud.
Those of us who were around in the days of "shared resource computing" think "what goes around…." In this analysis, the "cloud" is simply another shared resource computer. After all, it looks the same to the end users. At some level or another cloud service protect what they offer from contamination, leakage, or loss.
However, it is really not quite, indeed nowhere near, that simple. The cloud is really not just a computer or use. Rather it is an abstraction, a model for looking at computers and computing. It is on the same list as serial re-use, time-sharing, host-guest, and client-server. However, unlike these, cloud computing is not designed and implemented top-down but emergent from the bottom up.
The computing resources may include any combination of connectivity, computing capacity, instantiated processes, servers, storage, and services, including software (SaaS) and application services. While the resources are rapidly, and usually automagically, allocated and provisioned, use is metered and cost is allocated.
Security in the cloud turns not only on the axis of centralization v decentralization but also on one of scale, and on another of organization. Let's think about the last first.
In the cloud, the services are used by multiple users or organizations but owned by none of them. While most of the data may belong to the users, the hardware, software, and many of the controls are owned and operated by another enterprise, the service provider.
Each organization's interest in the security of the data is different. For example, the owner of the data may rank confidentiality, integrity, and availability, in that order, might prefer that the data disappear before leaking. The service provider, on the other hand ranks availability, integrity, and confidentiality, would prefer that the data leak than that he not be able to deliver it when it is asked for. One can easily imagine a scenario in which the service provider has so many copies of the data that he cannot erase them all on demand, perhaps not ever.
Users of the T-Mobile smart phone, the Sidekick were offered a service to backup the names, phone numbers, calendars, to-do lists, and other data that they had stored in their phones. This service was implemented by an enterprise ironically named Danger. However, it was offered to the user by T-Mobile under the T-Mobile brand. That there was a second enterprise involved was not apparent to most users.
Danger had a server crash. The service was clearly down and user's data was at least temporarily unavailable, perhaps lost altogether. To complicate matters, Danger was in the process of being acquired by Microsoft.
The story had a happy ending. In less than a week, Microsoft/Danger recovered the data and made it available on a new server. However, it illustrates another aspect of the cloud that impacts security; that is, you may not know with whom you are doing business or upon whom they rely.
The abstraction, The Cloud, hides the fact that it, the cloud, is a mechanism for combining, composing, and connecting (other cloud) resources to provide services with those properties, i.e., on-demand, easily and rapidly provisioned, that are described in the NIST definition of the cloud. A cloud application may reside in a cloud virtual machine, using cloud connectivity, cloud storage, cloud data, and even other cloud applications. Each of these resources may be offered by a different vendor and components my be added or subtracted on the fly. The service level agreements (SLAs) for these resources are probably "best efforts," the default service level for most information technology.
This is potentially a security nightmare for both buyers and sellers. Of course, a proper understanding of the problem is an essential step to a solution. More on this later.
When T.V. Learson was leading IBM, he was asked by a customer whether his IT should be centralized or decentralized. Learson responded that whatever way he was currently organized he should change it. Said another way, "What goes around, comes around."
In the early days of shared resource computing, the computer and most of the data resources were owned by the enterprise. "Data security," as we called it then, meant that what the enterprise said it intended, what it intended it did. We tried to help them think about it by suggesting the properties of the data that the enterprise most wanted to conserve. In some proportion of one to the others, the enterprise wanted the data to exhibit confidentiality, integrity, and availability.
To the extent that Grosch's Law described the economics, i.e., efficiency increased with scale, the economics favored centralization. Similarly, protection and control was also centralized. The risk was information leakage. The control of interest was Data Access Control, usually implemented as an optional process of the operating system.
In some cases use was metered and cost allocated but often cost was simply absorbed by the enterprise. This was in part because the meters and metrics of cost and value were immature. Metering and cost allocation were expensive and often had perverse effects on usage and uses.
At some point, Grosch's Law gave way to Moore's Law. Efficiency began to favor the small. When the scale of computing changed, it was not so much that data in the glass house moved to departmental and personal systems, although copies clearly did, as that data in departmental paper files got sucked in to the departmental and personal system, increasing the number of electronic records. At the same time, all computers were being connected to the Internet, making them and their data more vulnerable to attack by outsiders.
At about the same time as the scale was changing, we went from talking about "data security" to "information assurance," reflecting a shift in priority from confidentiality to integrity. Protection and control moved from centralized to distributed. The risk shifted to system contamination with malicious code. While we still used data access control, we relied more upon control of access to systems and applications. Other controls of interest included anti-virus, firewalls, and cryptography.
At this writing, we are discussing what security means in "cloud" computing. The name, cloud, for this style of computing comes form the cloud symbol that we used in network diagrams to represent that which was not known or beneath the level of abstraction at which we were working.
NIST defines cloud computing as "a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources" (e.g., networks, servers, storage, applications, software, and other services) "that can be rapidly provisioned and released with minimal management effort or service provider interaction."
However useful one may find the definition, some examples may help to appreciate the concept. The earliest emergent examples really define the cloud. Perhaps the most important of these is the Domain Name Service (DNS). E-mail and the World Wide Web are also on the list. Note that these are collaborative services, instantiated by the cooperation of many edge processes. For most users, their cost is included in the cost of their connection.
An early example is Hotmail, an advertising supported personal e-mail service. A more recent competitor to Hotmail is gmail from Google. As a personal service gmail is ad supported but Google also offers a service to "outsource" corporate e-mail. Instead of operating its own e-mail servers, an enterprise contracts with Google.
E-mail is an example of an application level service Dropbox is an example of a private file service in the cloud. Carbonite is an example of a backup service. IBM and EMC offer segment level storage backup. Indeed, they will operate an enterprise's entire storage network for them. Amazon offers a complete web storefront Think about almost anything that is hidden behind a standard service interface; it is available as a service in the cloud.
Those of us who were around in the days of "shared resource computing" think "what goes around…." In this analysis, the "cloud" is simply another shared resource computer. After all, it looks the same to the end users. At some level or another cloud service protect what they offer from contamination, leakage, or loss.
However, it is really not quite, indeed nowhere near, that simple. The cloud is really not just a computer or use. Rather it is an abstraction, a model for looking at computers and computing. It is on the same list as serial re-use, time-sharing, host-guest, and client-server. However, unlike these, cloud computing is not designed and implemented top-down but emergent from the bottom up.
The computing resources may include any combination of connectivity, computing capacity, instantiated processes, servers, storage, and services, including software (SaaS) and application services. While the resources are rapidly, and usually automagically, allocated and provisioned, use is metered and cost is allocated.
Security in the cloud turns not only on the axis of centralization v decentralization but also on one of scale, and on another of organization. Let's think about the last first.
In the cloud, the services are used by multiple users or organizations but owned by none of them. While most of the data may belong to the users, the hardware, software, and many of the controls are owned and operated by another enterprise, the service provider.
Each organization's interest in the security of the data is different. For example, the owner of the data may rank confidentiality, integrity, and availability, in that order, might prefer that the data disappear before leaking. The service provider, on the other hand ranks availability, integrity, and confidentiality, would prefer that the data leak than that he not be able to deliver it when it is asked for. One can easily imagine a scenario in which the service provider has so many copies of the data that he cannot erase them all on demand, perhaps not ever.
Danger had a server crash. The service was clearly down and user's data was at least temporarily unavailable, perhaps lost altogether. To complicate matters, Danger was in the process of being acquired by Microsoft.
The story had a happy ending. In less than a week, Microsoft/Danger recovered the data and made it available on a new server. However, it illustrates another aspect of the cloud that impacts security; that is, you may not know with whom you are doing business or upon whom they rely.
The abstraction, The Cloud, hides the fact that it, the cloud, is a mechanism for combining, composing, and connecting (other cloud) resources to provide services with those properties, i.e., on-demand, easily and rapidly provisioned, that are described in the NIST definition of the cloud. A cloud application may reside in a cloud virtual machine, using cloud connectivity, cloud storage, cloud data, and even other cloud applications. Each of these resources may be offered by a different vendor and components my be added or subtracted on the fly. The service level agreements (SLAs) for these resources are probably "best efforts," the default service level for most information technology.
This is potentially a security nightmare for both buyers and sellers. Of course, a proper understanding of the problem is an essential step to a solution. More on this later.
Sunday, March 28, 2010
Rockefeller-Snowe and Security Credentials
Legislation working its way through Congress may impose requirements for credentials on information assurance practitioners and professionals.
Two editors of SANS Newsbites responded as follows:
I responded to them:
A dialogue between John Pescatore and myself follows:
Two editors of SANS Newsbites responded as follows:
[Editor's Note (Pescatore): Since software engineering is still an oxymoron, there really are no meaningful software developer or IT system architect certifications. So, trying to say IT security professionals need certification will be good for the companies that will sell such certifications but really does not make sense from the point of any improvement of security.
(Paller): Cisco and NSA and SANS are compiling the available body of knowledge on what works and what doesn't work in security engineering.
They will be doing a workshop in June for people who will be hiring security engineers and architects.
I responded to them:
I agree with John that “software engineering” is an oxymoron. I argue that the application of engineering principles to software is very beneficial but very rare.
I agree with Alan that those same principles can be usefully applied to security and I commend his and any efforts to encourage it.
However, it seems to me that the certification requirements in the Rockefeller-Snowe Bill are more akin to the certification of security professionals that we have been engaged in for the last twenty years.
I would not be so dismissive of these programs as John is. Whatever else has resulted from these programs, they have had a huge impact on the documentation and spread of security principles and other knowledge. While this may be more arguable, they have also encouraged the professionalism of the practice of security.
It seems reasonable to me that agreement on the principles should come before certification or licensing. However, practice precedes either and continues even in their absence. Thousands of years of practice of engineering preceded its codification and licensing. Since we do not have the freedom to wait, we should encourage all three activities in parallel.
A dialogue between John Pescatore and myself follows:
John: Hi, Bill – I blogged on this in a bit more detail at , where I summarized:
That’s not to say there is no value in security certification as one element in evaluating security personnel.
Bill: The justification of legal requirements for minimum credentials in a professional practice go way beyond evaluating individual members of the practice.
John: But turning it into a requirement tends to make it set the height of the bar just at that level – that would not be a good thing.
Bill: Perhaps. Would you argue that the requirements for a medical license or a CPA are static? The federal government has been requiring credentials for aviation since 1917. Would you argue that the “height of the bar” is still at the 1917 level. I can testify from my own knowledge that the requirements for the CISSP are not static. When I qualified the program tested only for knowledge. Today one is tested for different knowledge as well as the skill to apply that knowledge.
John: My major issue is that there are no federal requirements for IT architect certification or software developer certification or database administrator certification. That is because certifications in those fields are largely meaningless, because software is *not* an engineering discipline yet. This is why GASP and the like, and the Security System Engineering Capability Maturity model and the like (I had involvement in the early 1990s with that one) really didn’t go anywhere. The Brits have had several certification programs that really haven’t done much to advance the state of the practice, either.
Bill: Agreed.
John: So, to have an federal information security certification requirement really is not going to be meaningful. It will just turn into a boon for certification programs.
Bill: I might agree that the field is not sufficiently mature for a federal requirement or even that the federal government should be involved in any credentialing program. On the other hand, their credentialing program in aviation has been very successful. Security operation of IT is at least as mature as the operation of airplanes in 1917.
I do not agree that credentialing programs benefit only the programs. The practice of engineering and medicine were both dramatically advanced by the credentialing programs that established minimum entry requirements to their practice.
John: Requiring training and education and job experience is so, so, so much more valuable in this kind of thing that requiring certification. This is pretty standard advice I give at Gartner to clients trying to evaluate security consulting personnel.
Bill: I grant you that certification is not sufficient for evaluation of professionals without granting that there are no benefits to minimum standards. Whether or not those benefits are sufficient to justify their requirement at law is another issue. Licensing of professional engineers was a reaction to infrastructure failure. Licensing of physicians and lawyers was a reaction by the competent minority to rampant incompetence. I do not argue that the practice of security is peer with these professions. I do argue that they were advanced by their requirements for credentials.
I think that the inclusion of credentialing in Rockefeller-Snowe is a reaction to the public perception that we are building infrastructure and that our efforts are simply not good enough. I am not sure that the remedy will be effective, much less that it is justified but I am satisfied that It will not make things worse. They certainly will not "set the bar" at today's level.
Monday, March 22, 2010
It works!
That's right. Security works. Your enterprise security program works.
Consider the following question. What part of the attacks that hit your perimeter does it resist?
a) None of them
b) Few of them
c) Enough of them
d) Most of them
e) All of them
Most of you said "c" or "d." We call that "working."
A few of you may argue that only "e" can be called working, to which I respond, "Be careful what you ask for, you might get it."
Do you know how to resist even more attack traffic? If that were the only objective, of course you do. You do not do it because resisting attack traffic is not the only objective. Even resisting "most attacks" involves at least slowing, if not rejecting, some legitimate traffic. It may also involve tolerating a resourceful attack.
Said another way, within the tough choices that face you, the security perimeter is doing what you intend. We call that "working."
Security is a hard problem; there are no perfect solutions. It requires the exercise of informed judgment. That is why we are called professionals and are paid the big bucks. Such as we are and given the conditions that we face, we do the best we can. That is called "working."
Consider the following question. What part of the attacks that hit your perimeter does it resist?
a) None of them
b) Few of them
c) Enough of them
d) Most of them
e) All of them
Most of you said "c" or "d." We call that "working."
A few of you may argue that only "e" can be called working, to which I respond, "Be careful what you ask for, you might get it."
Do you know how to resist even more attack traffic? If that were the only objective, of course you do. You do not do it because resisting attack traffic is not the only objective. Even resisting "most attacks" involves at least slowing, if not rejecting, some legitimate traffic. It may also involve tolerating a resourceful attack.
Said another way, within the tough choices that face you, the security perimeter is doing what you intend. We call that "working."
Security is a hard problem; there are no perfect solutions. It requires the exercise of informed judgment. That is why we are called professionals and are paid the big bucks. Such as we are and given the conditions that we face, we do the best we can. That is called "working."
Wednesday, February 24, 2010
The Worst Case Scenario
At the direction of the board of directors, the IT staff of a national property and casualty insurance company developed a backup and recovery contingency plan (as contrasted to a business continuity plan.) They found themselves in a bind between the board, who said the plan cost too much, and the auditors who said that it was inadequate.
Many of us have been there and I was called in to assist, i.e. to "consult." I was not terribly surprised by what I found. It seems that every time the staff thought that they had a plan the auditors would identify another case in which it would not work. The staff would add a new capability to address the new case.
The board tended to look less at the capabilities than the total cost. Admittedly, the board of a property and casualty company looks at the cost a little differently than might a bank or a manufacturer. The insurers ask themselves, how much insurance must I write to cover that cost? How much coverage would I offer for that amount if it was paid to me as a premium. How much coverage could I buy for that much money? They could not even judge the capability in the plan but they "knew" that its cost was too high.
Of course, the problem was in the failure to properly identify the objectives of the plan. Allowing the auditors to hypothesize cases clearly was not working. No matter the plan, they were always clever enough to come up with a new case in which it would not work.
A plan that can deal with the "worst case" has infinite cost. What case then? What case must the backup and recovery plan of a national property and casualty insurer deal with?
We concluded that such a company would have to recover from any disaster that both it and the majority of its policy holders survived. Certainly it has an obligation to recover from the destruction of its own premises. It must survive a community disaster like an earthquake. It must survive a regional disaster like Katrina. Of course, these are far short of the "worst case," short of thermo-nuclear war or the end of the world. Of course, the scope of the event was not the only thing that had to be agreed upon but also the expected rate.
Finally, IT had to agree with the business as to the mean-time-to-recovery and the point of recovery for each application. The faster one wants the application back, the more one can expect to pay. The closer one wants to recover to the point of failure, e.g. close of business on the day before the event, the more one can expect to pay. More on these on another day.
While these things are difficult to agree upon, such agreements are essential to an effective and efficient plan. They are necessary to being able to satisfy both the auditors and the directors.
Many of us have been there and I was called in to assist, i.e. to "consult." I was not terribly surprised by what I found. It seems that every time the staff thought that they had a plan the auditors would identify another case in which it would not work. The staff would add a new capability to address the new case.
The board tended to look less at the capabilities than the total cost. Admittedly, the board of a property and casualty company looks at the cost a little differently than might a bank or a manufacturer. The insurers ask themselves, how much insurance must I write to cover that cost? How much coverage would I offer for that amount if it was paid to me as a premium. How much coverage could I buy for that much money? They could not even judge the capability in the plan but they "knew" that its cost was too high.
Of course, the problem was in the failure to properly identify the objectives of the plan. Allowing the auditors to hypothesize cases clearly was not working. No matter the plan, they were always clever enough to come up with a new case in which it would not work.
A plan that can deal with the "worst case" has infinite cost. What case then? What case must the backup and recovery plan of a national property and casualty insurer deal with?
We concluded that such a company would have to recover from any disaster that both it and the majority of its policy holders survived. Certainly it has an obligation to recover from the destruction of its own premises. It must survive a community disaster like an earthquake. It must survive a regional disaster like Katrina. Of course, these are far short of the "worst case," short of thermo-nuclear war or the end of the world. Of course, the scope of the event was not the only thing that had to be agreed upon but also the expected rate.
Finally, IT had to agree with the business as to the mean-time-to-recovery and the point of recovery for each application. The faster one wants the application back, the more one can expect to pay. The closer one wants to recover to the point of failure, e.g. close of business on the day before the event, the more one can expect to pay. More on these on another day.
While these things are difficult to agree upon, such agreements are essential to an effective and efficient plan. They are necessary to being able to satisfy both the auditors and the directors.
Thursday, February 11, 2010
Subscribe to:
Posts (Atom)
Posts
