Essential Security Practices

I got the idea for essential practices from my friend and colleague, Dr. Peter Tippett.

He pointed out that one of the things that senior management looks to the security staff for is advice on where to spend the next security dollar. We each have a way of answering this. Some of us do it by the "seat of the pants:" those of you who are pilots have been taught how unreliable that is.

Some advocate 'best security practices,' but because of cost and other constraints we quit long before we get there.

Some employ formal risk assessment. However, few of us have the necessary knowledge, skills and abilities necessary to employ this expensive measure, one that is much better at justifying expenditure than telling us what to spend on.

Peter proposed essential practices as a method for answering this question. Let me explain what is meant by this expression.

I teach at the Naval Postgraduate School where my students are warriors. Since they understand the concept of "force protection," I use it to teach computer security.

In force protection, "first you dig a hole." This rule is so important that Caesar is said to have sacked generals who permitted the troops to eat or sleep before they dug a hole.

In modern warfare we call this hole a fox-hole. Fox-holes are about 0.8 effective. If the artillery shell or the grenade lands in the fox-hole, it does not help. However, if either is a "near-miss" then the hole offers protection.

Now most of you have seen the movie, Patton. You know that General Patton required that even the cooks and the doctors wear their steel pots. Again, a steel pot will not protect you from a direct hit but it improves the effectiveness of the fox-hole.

So, there are two pieces of equipment that all the troops carry into the field. The first is the steel pot and the second is the entrenching tool. Each costs about $15-. The helmet liner costs more.

What about body armor? About 0.8 effective, complements the hole and the steel pot. However, it costs not tens of dollars but hundreds. In the first Iraq War we heard stories of Mom hocking the family homestead to pay for it. However, the price has now fallen by half or more. Does it now qualify as "essential?"

So, anyone can dig a hole with available resources, It is about 0.8 effective. It complements the steel pot.

There are analogous IT security measures that:

• can be done by anyone
• with available resources
• are about 0.8 effective
• and which complement one another

For example, if a fox-hole is a primitive fortification, then an IT analogy might be a free software firewall like the one provided by Microsoft in Windows. We accept that it is limited in its effectiveness. Anti-virus software might be analogous to the steel pot. A hardware firewall that cost hundreds of dollars might, like the body armor, be questionable. However, one that costs tens of dollars and protects a SOHO network, an application server, or even an enterprise desktop probably qualifies.

In the rest of this chapter we will identify a number of qualifying IT security measures. Some will be fairly obvious, at least once they have been identified. A few will be surprising and one or two will be controversial. You will find that many will be measures that you already have in place but each of you will find one or two on the list that you have overlooked There will be some items on the list that you have considered and rejected; I will ask you to reconsider them.

Here is one of the obvious ones, changing default passwords. This one is so obvious that one really not have to call it out. However, if one reads the Verizon Data Breach Incident Report (VDBIR), one finds that there must be a very large number that have not been changed. Surely it meets the definition.

User and management awareness training may or may not qualify, depending upon how one values the time of the users and managers and how well one uses it. On the other hand, many recent breaches have relied, at least in part, on duping users.

Formal risk acceptance makes the cut. It is used when, for business reasons, management elects to accept, rather than mitigate, a risk. The risk acceptance document is written by the security staff and signed by line management. The security staff describes the risk and the reason for accepting it and a business executive, with sufficient resources and authority to mitigate the risk if he wished, signs it. Its life is the shorter of a specified duration, the tenure of the signing executive, or one year.

Explicit assignment of security roles and responsibilities and supervision to ensure that they are carried out is both effective and efficient. When people fail to do what we expect, it is far more often the result of our failure to communicate the expectation than it is a failure of motive on their part. It is essential both in the sense of our definition and in the sense of necessary.

Unique user identifiers make our list. Again, while the motivations for shared IDs have all but vanished, the Verizon Data Breach Incident Report suggests that they persist and contribute to breaches. It is ironic that the most frequently shared IDs are privileged ones (can you say "root?"), the one's where accountability is the most important.

Similarly, we should be using strong passwords, not so much because we are seeing a lot of brute force attacks, but because accountability requires that we be able to take the possibility that there the password is compromised off the table.

Anti-virus and personal firewalls would appear here on the list. We used them as examples above. However, there a few more things to say about them.

The personal hardware firewall changes the policy of the personal system from permissive to restrictive. It hides personal system vulnerabilities, some of which will never be identified, much less fixed, from the Internet. Of course, say firewall in most enterprises and the network managers go ballistic; they are certain that any firewall will break applications.

However, I give away personal firewalls as hospitality gifts. If I am your guest for the weekend, I will bring and install a Linksys. I have yet to break an application. Indeed firewalls and applications are increasingly aware of one another and configure themselves as necessary.

But ranking with AV and firewalls, I put backup. It is important because our storage is fragile and our data friable. In addition, it is a measure that protects us against those threats that we can not anticipate. We use it because computers do nothing quite so well as they make cheap, dense, portable copies of data.

Having decided to make backup copies of our data, we should encrypt the backup copies. The more copies of the data, the more persistent it is but the greater the probability that it will leak. We have also seen tens of cases in which we are unable to account for a clear-text backup copy. Most of the software that we use for backup has an encryption feature. Backup software with an encryption feature is not that much more expensive than that without it.

Next is a practice that is clearly on the list but often over looked, time-out to a lock-word protected screen-saver. The lock-word need only be long enough to resist a guessing attack lasting minutes to tens of minutes. This simple measure greatly reduces risk on machines in public or employee-only spaces. It does not impose a burden even in secure spaces. It is an option on most popular operating system. However, the control is not always easy to find. For example on Windows 7 it is under "personalization." In Mac OS X, it is the second option in System Preferences.

A practice that is not quite so obvious is end-to-end encryption. By end-to-end, I mean client to application. I am going to argue that anyone can do it and, thanks to Netscape and Cisco/Linksys, with available resources. Yes, SSL, SSH, and IPSec are ubiquitous. All remote desktop servers include it. It is the essence of virtual private networks, VPNs, and virtual local area networks, VLANs. If a server does not support one of these, one need only put a proxy in front of it.

A related practice is to terminate VPNs on the application, not on the perimeter and not on the operating system. On the client-side, the VPN is hidden under the application name or icon. On the server-side, the application hides network and operating system vulnerabilities from the client and the encryption hides application vulnerabilities from all but authenticated users. The encryption hides the client from enterprise network users.

By policy and practice, store sensitive data, including books of account, payment card information (PCI), personally identifiable information (PII), and intellectual property (IP), on enterprise servers. Resist, with policy and controls, the creation of arbitrary copies on desktops and portable devices. Yes, I know that the users claim that they need those copies in order to get their jobs done. However, that is a service level issue. Given the speed and coverage of modern networks, this is clearly less necessary than it was last year and will be even less so next year.

Prefer application-only access to data, the need to look up an associate's e-mail address or phone number should not confer the privilege to copy the enterprise directory.

Note that if the sensitive data is on the servers, then that is where the control ought to be. First there will be fewer control points and that will reduce administrative effort. Perhaps more important, access controls on the servers are much more reliable, more resistant to bypass, than those on clients.

If one is going to use Wi-Fi, and almost everyone does, one should encrypt the air side. WPA2, the standard protocol, IEEE 802.11i-2004, is supported in all modern Wi-Fi equipment but any is better than none. The burden is in distributing the key among the using devices. The size of this burden is a function of the number of devices using the wireless network. As in any encryption scheme, the key is most vulnerable when it is being distributed. All key distribution protocols leak. but none leak nearly so much as Wi-Fi without encryption. [This use is so fundamental that the RIAA and MPAA have advocated making it a criminal offense not to use it, but that is a subject for another day.]

Dial in only using VPNs and via ISPs, never direct to the enterprise. Said another way, get rid of dial-in. The Verizon Data Breach Incident Report shows that a significant number of breaches exploit dial ports installed by or for the convenience of support personnel. That is in part because operating dial-in securely requires knowledge, skills, abilities, and resources that are beyond all but a few specialized enterprises. Yes, I understand that many of your users work from locations with no broadband access; for them dial-in may be necessary. However, that does not say that it is necessary for you to operate it. Users should dial-in to an ISP and access your applications and systems via the Internet.

Those VPNs, indeed all VPNs should terminate on the applications, not on the perimeter and not on operating systems. Encryption should always terminate on the application rather than the network perimeter or the operating system. This simplifies its use and improves its effectiveness.

Patch broadly in preference to early. Said another way, convert patching from an unplanned, to a planned activity. It turns out to be dramatically more efficient to patch most, or even many, of your systems in ninety, or even one hundred and eighty days than a few in a hours or days.

Patch wisely. In a year in which 2200 vulnerabilities were reported, roughly one in a hundred were exploited. Said another way, not all vulnerabilities are problems, not all problems are the same size. Would you not rather have patched the twenty than the 2200?

Lock down your systems. Hide the operating system and any other capability to install or modify programs. I can hear the moans from here. Most of you are professionals or para-professionals; many of you exploit such capabilities and some of you even need them. However, no executives and few managers need these privileges. Few administrative or clerical users need them. Change the default and dramatically reduce your vulnerability. Microsoft provides powerful tools for locking down systems and administering locked-down systems. Few of us use them well.

Finally, layer your defenses. As your resources grow in value and your adversaries in power, push your defenses out and push your valuables down in the ground. Between the Internet and the crown jewels, there should be several, say four, layers. Tunnels, VPNs, that bypass those layers, should lead to limited and contained privileges and capabilities.

Now that is my list. Peter’s list might be somewhat different. However, my Jesuits who taught me in prep school, taught me that, for the sake of completeness all such lists should end with “other.”

Many of these practices you may have already implemented. One or two may not apply to you. There may be other practices that qualify as essential that I have not identified. Make your own list. Order it. Work your list. Most of these things can be done in six months or so. Focus on essential practices before moving on to more expensive measures that require more expensive justification processes. In the meantime, cover those measures with risk acceptances.

These measures are so fundamental, so efficient, so “essential” that we must get them done before we even take time to consider other measures. I will argue that measures that are 0.8 effective and cost tens of dollars per seat are so efficient as to qualify as "essential." Because efficient can be defined as cheaper than all of the alternatives, including that of doing nothing, these measures qualify as efficient by two definitions.

As with all controls, there will be exceptions to these rules but the exceptions should be manageable and we ought to be managing them down in both scope and number.

I understand that "anyone can do them with available resources" does not translate to "easy." Depending upon the size of the enterprise and the style of its management instituting even essential practices can still be very difficult.

The use of "Essential Practices" is a method. It is a method for allocating our scarce resources. It is a method for answering the management question, "Where should we spend our next security dollar?" It is method that characterizes us professionals, ensures our efficiency, and earns us the big bucks.

Classification and Labeling of Data

In the early days, much of computer security research was aimed at developing computers that could be relied upon to enforce the DoD scheme for restricting access to data "classified" in the national security interest. Out of this research emerged the Bell-Lapadula model, the Trusted Computer System Evaluation Criteria (TCSEC), and rules-based access control. These assumed that data is "classified," that is, labeled as to its sensitivity. The research assumed that data is "born classified," without paying much attention to who says so or why.


Data is not really born classified. Someone has to decide. Classification is an economic decision. While some people think that one is simply making a statement about an inherent property of the data, what one is really doing is making a statement about how one believes the data should be protected and at what cost. The class maps the data to a set of methods and procedures to be used to protect it. We call this mapping "policy." Since these methods have a cost, by assigning a class or a label, one says that this is how much the enterprise or the authority is prepared to spend to protect this data.

The label can be thought of as a code that the author/classifier uses to communicate to the users of the data how he, the author/classifier, wants it to be protected. For example, when one labels an object "confidential," one communicates to all custodians and users of the data that it is only to be seen by those with "need to know." When one labels it "top secret," one asserts that, among other measures, the data should be locked up when not in use.

We choose our label or class based upon the "sensitivity," a term of art, of the data. Sensitivity is a function of context and association. A single bit of data is sensitive only if one knows what it signifies. A social security number, standing by it self, may not be sensitive but the bind of a social security number to a name starts to be sensitive. As one associates date and place of birth, the names of parents, address, credit scores, and credit card numbers sensitivity increases.


Sensitivity increases along an axis from raw data, to organized and analyzed data, to conclusions or intelligence derived, to plans of action based upon the intelligence. Thus for most business enterprises, competitive intelligence, product plans, and business plans tend to be very sensitive.


The sensitivity of data is a function of its timeliness. Reuters charges a premium for data that it plans to give away for free in fifteen minutes. At the other extreme, the identity of spies remains sensitive for the life of their grandchildren. The Secrets of Ultra remained sensitive until the inventions of modern cryptography made them obsolete; we kept them secret for another twenty years just to be on the safe side. While there are exceptions, the sensitivity of data tends to decrease with age. The sensitivity of Thomas Eagleton's mental health records was decaying along a predictable curve until he ran for the US Senate. It spiked again when he was chosen to run for Vice President of the United States.


Similarly, the sensitivity also tends to increase with quantity. One credit card number is sensitive but the sensitivity of a set of such numbers goes up with the number in the set.


So to recap, the sensitivity of data is a function of context or association, age, organization and analysis, and quantity.


Today we have default sets. In the private sector these include intellectual property (IP), personally identifiable information (PII), and payment card information (PCI) that must be protected from disclosure, and the books of account that must be protected from manipulation or contamination. In law enforcement we have investigations in progress and wants and warrants. In intelligence we must protect not only the conclusions and recommendations but also the sources and methods by which they were developed. Sources and methods are among the most sensitive data we have because compromise may cost lives.


Classification decisions must be made by those who know the most about the data. For business functional data, such as accounts receivable and the payroll, that it usually the manager of the function. By default, it is the person who creates the object. We often refer to this individual as the "owner," because the role usually includes the authority and discretion to say who, and in what circumstances, can see or modify the data.


Because the decision requires judgment and experience, it is normally reserved to executives, managers, and professionals. Our job as staff is to ensure that the process of creating an object includes the step of labeling it, then to note variances and ensure that they are corrected. However, it is often difficult to identify the responsible individual,


In most organizations, the authority to classify information includes the authority to re-classify. An exception is the US National Security system, where once classified, the data must go through a rigorous declassification process applied by specialists.


In business the label should include the identity of the classifying manager or authority and a date whereon the classification expires or must be extended. Enterprise policy may require the former and limit the latter.


The objective of the system should be to ensure that all data gets the protection that it warrants but that expensive measures are reserved for only the data that needs it. Under classification may result in leakage or contamination. Over classification is inefficient.


An issue is binding the classification label to the data object. The integrity of the system relies upon the label being tamper resistant, or at least tamper evident. In ink based systems the paper binds the data and the label to the same piece of paper. Because of the mutability of electronic data, the label is part of the meta-data and the bind may not be as reliable. Closed systems like the AS/400 or Lotus Notes help. Encryption can be used to bind the label to the object in such a way that tampering with it will be evident. The integrity of the bind is checked at open time and flagged if the content and the label do not agree.


An effective classification and labeling system has to be baked into the culture of the enterprise or organization. Policy, methods, procedures, All members of the organization have to expect labels and must know the measures for all classes that they are likely to see in their roles. Moreover, those who create data objects must know how to classify them. Both of these things require constant reinforcement and training. Supervisors, managers, and executives must note variances between the sensitivity of the object and the label assigned and take timely corrective action.


Fifty years of electronic computing has resulted in an explosion of data, if not intelligence. Efficient, even effective information assurance requires not only that we identify the sensitivity of our data, that is, classify it, but also then communicate that judgment to all users of the data, that is, label it. We have seen at RSA and Lockheed-Martin what comes from trying to protect all data the same.


Luckily, the computer has given us powerful tools, for example, uniform and consistent processes, user identification and authentication, rules-based access control, and encryption to protect the information. In some cases, simply applying the proper label may go a long way toward ensuring that it is protected appropriately.


Many organizations have nominal classification and labeling programs that are not effective. When a client tells me that they have a program, I make a quick test. I ask a couple of executives if they would notice a mis-classified document if it hit their desk, and, if so, what they would do about it. I get unsatisfactory answers more often than not.


Because such a program must be woven into the warp and woof of the fabric of the enterprise, creating a is difficult, time consuming, and high maintenance. Of course, that is why those of us who implement classification schemes are called professionals and are paid the big bucks.

Security Architecture Principles

I would like to recommend to you some principles for security architecture, how to design security into our enterprises, networks, systems, and applications. First I have to say a little about architecture in general and security architecture in particular.

Architecture is part of design. It is that part of design that deals with:

* appearance, how things look,
* function, what they do,
* location, where things sit relative to other things, and
* materials, what they are built with.
I like to use the analogy of residential architecture because that is what most of us think about when we think architecture. The design describes what the house will look like, what kinds of rooms it will have, where they will sit relative to one another and what materials the house will be built with.

Note that the design of the house includes multiple views and documents, including a model, elevation, or perspective, a floor plan, and a list of materials and their specifications. Note that most of the materials can be specified by reference to existing standards but novel materials have to be described in detail.

Security architecture deals with how security looks to the user, security functions, such as user identification and authentication, and access control, where the functions are located and how they interact, and what components, both off-the-shelf and purpose built, they are built with.

My mentor, Harry DeMaio, likes to say that "security architecture is derivative of and dependent upon IT architecture" but then goes on to point out that if that architecture is not rigorous and well documented then that must be done before the security design can proceed. My own experience is that when I ask management about their IT architecture, they give me a list of components but cannot tell me how they are used or how they fit together, let alone show me where these things are documented. Of course the implication is that much of the design is ad hoc, not to say that it "grew like Topsy." Thus our work often starts with documenting "what is" so that we can refer to it.

We speak of "expressing" the design. Like the design of the house, our design involves multiple views and levels of detail, multiple documents and models. We can think of it as top down, one page at a time, carefully indexed and cross referenced. As the designer of a building or house uses blue-prints (still called that though they are no longer blue) we use network diagrams, stack diagrams, and access path schematics. As the building designer uses pictures, we may use screen shots, as he uses models, we may use working prototypes.

Design is an iterative process that begins with identification and documentation of requirements. Think about the residential architect. He needs to know neighborhood, family size, life style, taste, budget, etc. We need to know industry, business strategy, environment, including natural and man-made hazards, scale, required behavior, forbidden behavior, permissible and impermissble failure modes, applications, risk tolerance, cost to over come resistance, i.e. strength, organization, users, etc. Identifying and expressing security requirements is a topic for another day.


To identify all of these requirements, like the residential architect, we may use our experience, structured interviews, questionnaires, document reviews, and "strawman" documents, sample deliverables that illustrate design options and choices.

For security design these choices may include economy of logon, single point of administration, end-to-end user-to-application encryption, layered networks, limited reliance on operating systems, granular access close to the data, certificate based credentials, failure to logon (rather than to the operating system prompt).

So much for context. Let's get to the principles. First practices, then appearance, function, materials, and, finally one or two ideas on sources.

The most important practice, perhaps the most important design principle is "do it right." Do it right the first time; build for the ages as contrasted to iteratively assess and fix. Design top down by functional decomposition and iterative refinement. Plan to implement by composition from the bottom up. Prefer broad solutions, for example backup, that work across the enterprise, across multiple applications, and that address multiple risks. Prefer end-to-end encryption-based solutions that are independent of the underlying network.

Appearance. Provide a consistent presentation and interface that is predictable, intuitive, and obvious as to intent and effect. Design for ease of safe use, such that doing the right thing is easier than doing the wrong thing. Hide and encapsulate necessary special knowledge such as encryption keys. Using the system safely should require as little user effort and special knowledge as possible. Prefer simplicity, hide complexity. Design around roles and responsibilities so that users see only that which is relevant to what they are supposed to be doing. All other things equal, security should look the same across the enterprise, i.e., across applications, systems, and platforms. Correct behavior learned in one context should not cause errors in another.

Place controls close to the resources, e.g., on the server, but place operation of the control close to the special knowledge required for its safe operation. For example the control for enrolling users should be in the hands of the user's manager while that for granting access to a resource should be in the hands of the owner or manager of the resource. Place control where the effect of its operation can be observed. The operator of a control should be able to observe the effect of its operation. Prefer localized function and data; the fewer things that must operate correctly to produce the safe result the better. Distribute functions and data only as required for reliability, availability, and performance. Separate controls from their use and user. For example, the operating system of a server should be hidden from users of the server.

Include audit trail in your design. An audit trail should enable you to know the current state of the system, how it got that way, and what it looked like in the past. It should enable one to fix accountability for all use, content, and behavior of the system to the level of a single individual

Localize security function. Prefer single services for naming of resources, users, and groups, authenticating users, and controlling access across a domain, e.g. network or organization. Similarly, prefer a single service for encrypting data and managing keys.

Structure and layer networks, for example into public, i.e., peer with the Internet and the PSTN, private, i.e., user and application, trusted, i.e.,trusted-system to trusted-system. and control, i.e., privileged operator to system controls. Isolate the layers from one another using firewalls, proxies, and encryption, e.g., vLANs and VPNs. Prefer short segments and limited to segment-to-segment traffic, i.e., a balance between the two.

Prefer robust materials from trusted sources in tamper-evident packaging. Prefer materials that have been evaluated by third parties against industry or government standards. Prefer single-use to multi-use components. Prefer hardware to software for process-to-process isolation. Prefer virtual-machine to virtual-machine isolation to operating-system-process to operating-system-process isolation. Said another way place more reliance on hyper-visors than operating systems. Prefer industry-standard, public, and mature encryption mechanisms and products, e.g., SSL, SSH, and IPSec; avoid RYI.

Finally, we come back to "do it right." Use the right material for the application. Use materials as they are intended to be used. Do not bend to fit. Do not break interfaces, that is, do not exploit knowledge that you may have about what is behind the interface.

Now, you might think that is a lot to absorb at one time. On the other hand, once enumerated, the principles are pretty straight forward. Many of them you abide by much of the time without thinking about them. For those of us who participate in the design of organizations, networks, applications, or products they can go a long way to earning us the warrant of professional and the big bucks.

SOPA, Bought and Paid For

SOPA, H.R.3261, The Stop Online Piracy Act, is a long and complicated act. While I am not a lawyer, I flatter myself that I am literate. However, I do not pretend to fully appreciate this law.

A cursory reading suggests that it pretends to be aimed at "foreign (DMCA) infringing (internet) sites." It burdens and punishes US enterprises directly with the intent of indirectly punishing the so-called "foreign infringing sites. Since most of the sales of these foreign sites are to parties outside the US, they are not likely to be punished very much.

The television advertising that urges support of this law, suggests that it is about resisting "international piracy." It even suggests that on-line piracy is the moral equivalent of piracy on the high seas. One is led to conclude that this is a national, or at least cyber, security issue, justifying a dramatic increase in the police powers of the state.

If you are an Internet service provider (ISP), an Internet search engine provider, a payment network service, or an internet advertising service, the law requires you to identify agents to accept legal orders on your behalf and to provide both controls and operators to filter access or revenue to "foreign infringing sites." As users of all of these services, American citizens will be forced to bear the cost. If you use a foreign site, so censured, for any purpose, you may be unable to access it.

Surprise! This law is sponsored, written, and supported by the publishing industry, the RIAA and the MPAA, Sony, and Nintendo, in a last ditch effort, a futile attempt, to shore up their broken business model.

Throughout history, every time there was an advance in technology that reduced the cost of copying, the authorities have used it to reduce their own cost while attempting to maintain their prices and control. When the end-users of their content have used the same technology to force a change in prices, the authorities have cried foul. They have "screamed like stuck pigs," which is, I suggest, an apt metaphor.

Of course, that has happened many times throughout history and multiple times in the last century. It happened with movable type, the linotype, and the photo-offset press. It happened with magnetic tape recording. It happened with the plain-paper dry-process photo copiers and scanners. It happened with the general purpose digital computer. Let's not forget VHS and MP3 players. The publishers have tried to outlaw all of these. Each time, the publishers have exploited the technology but tried to use the law to resist its use by others.

Every time, their strategy has failed. Every time the price of their product has fallen to the point where it approximates the marginal cost of using the technology to exploit them. That is why one no longer pays $20- for an album but $0.99 for the tracks that one wants. The irony is that the value of their rights actually increase because their sales increase and the illegal copying decreases.

Said another way, Piracy is a service and pricing problem. For example, I stopped looking for free down-loads the day I got iTunes. I use bitTorrent and FrostWire because they are fast, as much as 30 times as fast as ftp, not to access illegal content. Quite candidly, I think that it is a tragedy that collaborative networking has been so tainted by its abuse and misuse that we do not use it for legitimate purposes.

To the extent that this law and these controls, are used to enforce court orders and injunctions they would be limited in their potential for abuse. However, the Department of Justice, the Attorney General. is authorized to use them as part of his police powers.

Of course, it is appropriate that this expansion of power is really to the publishers under the DMCA. After all, they wrote the law, and they have paid for it. As citizens, we should be very suspicious when the interest of the money coincides with those of the politicians, the "control freak" politicians, those who believe that legislation can ensure that hammers hit only nails.

Is it reasonable to believe that this increase in power will not be abused by those who have already abused the power that they have? Not only have the publishers used their power to punish arbitrarily and capriciously, but they have used their power to "take down" pages that they have no rights over but whose content offended them. Noting that they have abused their power to take down pages, do we really want to empower them to take down entire domains.

Note that the role of domain registrars is merely to create the bind between a name and an address, a role similar to that of the Post Office or the publisher of the phone directory. Why not pass a law that the Post Office cannot accept mail that contains DMCA contraband.

The proposed law transfers the burden of proof from the state to the citizen. Penalize first, decide, if at all, later. The law provides no defenses from and remedies for such abuses by either the state or the copyright holder. According to the MPAA and the RIAA, there is no such right as "fair use" merely a defense of fair use.

To the extent that the cost and burdens of this law was to be borne by the publishers and their customers, it might be defensible. However, the law places the cost and burdens on the providers of unrelated services and their customers.

Like the USA Patriot Act, this law, the intended purposes of this law are likely to be dwarfed by the unintended consequences. Law is a blunt instrument, one that we should resort to only when all else fails. Moreover, this specific law is particularly blunt. Without due process, it permits entire sites to be taken down because of any infringing use.

The House Committee with jurisdiction has published a list of tens of industry supporters of the Bill. While roughly half are publishers, there are some that would be subjects of the law. There is also a great deal of popular opposition. I went to YouTube to find the ad promoting the bill but found only videos opposing it. However, while the race is not always to the swift and the legislation is not always to the RIAA and the MPAA, that is how the smart money bets.

I have tried to be measured in my response to this proposed law, I have tried not to "view with alarm." That said, I am much less sanguine now then when I began my research. If you think that I have failed, I invite you to visit YouTube where the proposal is covered with vitriol. I particularly commend to you the speech by Cory Doctorow at the Chaos Computer Conference.

As a citizen, I find this law obnoxious and its sponsors greedy and corrupting. As an information security professional, I expect some, not to say much of its burden to fall on us. But, of course, that is why we are called professionals and are paid the big bucks.

World View

In the nineties I attempted to mediate an on-line dispute between college students and system administrators that was taking place on American campuses. The students felt that system administrators were over-reacting, exceeding their authority, indeed violating their civil and human rights, in response to trivial and innocent behavior.

The students had grown up in a world of cheap single-user computers, a world in which the boundaries of the system were clear, hard, and embraced nothing that did not belong to its user. The primary applications were trivial, mostly games, and the rules of the game were implicit in the game; it the game would do it, then it was legal, even ethical. One could not cheat at Pac-Man. There was no problem that could not be solved by pressing ctl-alt-del, system reset, a control that would return the system to a known and stable state.

The administrators had grown up in a world of expensive shared-resource computers, a world in which the boundaries of the user's space were obscure, soft, and where most of the addressable resources did not belong to the user. Applications included those that were essential to the health and continuity of the enterprise; their legal and ethical use required judgment, prudence, and care. Misuse or abuse harmed others; it often destabilized the system and took time and other scarce resources to return it to a stable state.

The students believed that the system was there to support their learning, learning by exploring the world, including the system. The administrators saw such exploration as threatening, rude, and dangerous. The students saw their exploration as innocent and, to the extent that ethics involves how we treat others, as an-ethical. The administrators saw the the issue as about the effect on others and essentially ethical.

When the administrators observed what they identified as forbidden behavior, they responded, usually by revoking the system privileges of the students. The students saw any attempt by the administrators to impose order and discipline as an abuse of authority; they needed the system to complete their assignments. Restricting their privileges was the ethical equivalent of denying them access to the library, or even he cafeteria.

Needlessness to say, mediating the conversation between these two groups was neither fruitful or satisfying. Not only did they have different ideas about how the world works, they had conflicting, not to say irreconcilable, views of how the world works.

While I was sympathetic to the administrators, world views are. They are neither correct or incorrect, good or bad; they just are. They tend to be generational. The little nuns that taught me were certain that if I could write a pretty Palmer Method hand and add long columns of numbers, I would be guaranteed a living for life. While I was guaranteed a living for life, and while it was based in large part on their efforts, it had little to do with what they believed to be important.

The current generation, one that our colleague, Jim Beeson, CISO, GE Capital Americas, calls the "digital natives," comes to us with yet another world view. For them, the purpose of the network of computers is to facilitate sharing and collaboration, what the media likes to call "social networking." Not only will they sacrifice enterprise security, but their own personal privacy, to this view.

According to a report from the Threat Research group at Cisco, "seven out of 10 young employees frequently ignore IT policies and 67 percent feel the IT policies on social media and personal device usage are outdated and need to be modified to 'address real-life demands for more work flexibility.'"

Like the system administrators of the 90s, young security managers project the world view of their generation onto the next. In their view Facebook, Twitter, bitTorrent, and user-owned devices look threatening, opportunities to leak and contaminate.

However, there is a difference between the way things appear and how they really are, between things that look threatening and things that really are. Most of the students in my tale really were benign even though their behavior matched a threat profile that the administrators recognized. While FaceBook and user-owned devices appear threatening, they may not represent a risk. However, their users do have a different and persistent view and with it different attitudes and behavior.

The security managers often respond to what they see as threatening by resisting the technology and the world view of the young. What they ought to do is identify and restrict access to the sensitive data and applications as close to them as possible. What they ought to do is layer and compartment the network.

I do not use Facebook or Twitter, not so much because I see them as threatening as because I value my privacy more highly than the young seem to do. I have a less trusting world view. In its light I make different choices. Whatever their choices, they carry responsibilities. For example, one of the responsibilities that they are learning the hard way is that they must resist cyber-bullying. It is up to us to help them learn how nice people behave in the world that they are creating. To the extent that the past is a guide, it will not last a generation.

It is up to us to achieve our enterprise security objectives in spite of the persistence of the new world view. It is for that we are called professionals and are paid the big bucks.

Security is about Trust

At an RSA Conference in 1997. Jim Barksdale, then CEO of Netscape and late of FedEx, pointed out that if airline safety had remained constant at 1937 levels, the year the DC-3 (C47, Dakota) came on-line, and traffic had risen to 1997 levels, we would be killing people at the rate of two 747's per day. He then asked, "Would you fly?"

His point was not simply that there is an essential level of safety for the acceptance and use of a technology but that there is a necessary level of public trust and confidence that must be sustained. Damage that trust and confidence and the technology will not be used.

Moreover, public trust and confidence is fragile and difficult to sustain. My favorite example is atomic energy. In the late forties and early fifties, proponents of atomic power argued that it would be too cheap to meter. It did prove to be more expensive than that but that is not the reason that we do not use more of it. It is not that it is not safe, or even that its safety is difficult to measure. We continue to burn fossil fuels though they are far more dangerous than atomic energy and we count the bodies in hundreds per year.

Rather it is that Three-Mile Island destroyed the necessary public trust and confidence. Three decades later we have still not succeeded in repairing it. We were getting close when a once in a thousand year event took place at Fukishima. As a result Germany, that gets 23% of its energy from nuclear power, shut down six plants and has announced that it will decommission all of its plants over the next decade. While Germany asserts that it can do this while becoming an energy exporter and reducing its carbon emissions, result of this decision, this, at least arguably disproportionate, response, is that its use of toxic fossil fuels would increase.

I have argued that information technology is different. First, the public does not see IT as being as intrinsically dangerous as energy or transportation. Second, because, just as they "feel" safer in an automobile than on an airplane, they "feel" safer in IT, in part because, as in the automobile, they enjoy some local control. We get a pass that we did not earn.

That said, both the government and the media clearly believe that the public is too complacent about IT. Every breach or compromise is widely reported. Both vulnerability and threat are expressed in hyperbolic, not to say alarming, terms like "Cyber War" and even "Cyber Pearl Harbor." While electronic transactions are demonstrably safer than the same transactions in paper, activity like identity theft, that originates mostly in paper, is blamed on IT. Security and safety are used to resist efficient, not to say necessary and urgent, automation of paper health care records. While the US spends more on international intelligence gathering than the rest of the world combined, activity of others is viewed with alarm and both capability and motive are inferred.

On the other hand, the financial condition of small business, non-profits, and municipalities is being damaged by fraudulent use of their on-line banking credentials. We continue to use mag-stripe and PIN for retail payments, an application for which they were never intended and clearly are not safe. We are spending billions of dollars per year to resist "spam" and malicious code. The software industry continues to ship code with implementation-induced vulnerabilities, doing it over and over rather than doing it right the first time. (Safe software is no more difficult than safe airliners; they do a better job.) The number of records reported breached exceeds the number of people. There is a consensus that controls between the public networks and other infrastructure make those controls vulnerable to misuse and abuse. All of these things erode public trust and confidence. Since we do not know where the breaking point is, we need to err on the safe side.

I do not expect a total melt-down like "Three-mile Island." (Pun intended.) Rather, I expect that use of IT will be resisted at the margins, used less than might be efficient. Health care is the "poster child" for this concern. While it is true that the organization of this industry makes automating it difficult, security and safety concerns, the public's lack of trust, have made it nigh impossible. Those responsible for automating it know that at least part of the public is fearful and would prefer that they fail.

Let me return to Jim Barksdale's analogy to aviation. Like the computer, the airplane began as an expensive toy for a few. They even had their hackers, amateurs who learned by experimentation, those who pushed the envelope of performance, safety, and ethics. As the computer grew up to be "information technology" the plane grew up to be "aviation." Boy did it grow up. My colleague, Dr. Peter Tippett, suggests that in the sixty years from 1937 to 1997, aviation safety improved one thousand fold. Planes are ten times safer than in 1937. Even those DC-3s still operating, and yes there are some, are ten times safer.

We got another ten-fold improvement from better flight procedures and pilot training. Peter says, think check-list. A 1937 pilot would say "Real pilots do not use check-lists." The 1997 pilot would say all pilots, professional or amateur, use check-lists. One might call this "professionalization." After only fifty years our hardware and software now have the controls that we need to resist leakage, preserve integrity, and provide transparency and accountability. Even though our professional associations develop and publish check lists, we are not as professional at using these controls as their existence would suggest.

Finally, we got a ten fold improvement from the timely reporting and sharing of intelligence. From weather to navigation, to traffic, to maintenance, to accident reports. We have a formal system in place, not only for sharing, but in some cases to ensure receipt and compliance. In part because we do not trust one another, and particularly because we do not trust government, in information assurance, we do not share well and question much of what we see.

I confess that I admire the air transport industry, I look to them when people tell me how difficult safe and secure IT is. I hold up their performance as a standard to which we should aspire. We should emulate engineering that produces planes that can be operated safely. In aviation, safety does not yield to schedule or even profit. Think B-787 and the 3 year slip.

We should emulate their training, experience, and professionalism, from pilots to mechanics to those who serve our comfort and safety in the cabin. They have earned and conserve our trust.

We should emulate their collection and use of timely intelligence, a use which manages to get safety information to everyone that can use it while not unnecessarily alarming the public.

As in efficiency, as in infrastructure, everything that we do, or fail to do, increases or decreases necessary public trust and confidence, fragile confidence, maintained at a cost, and which, if broken, we may not be able to repair or replace. It is for this that we are called professionals and are paid the big bucks.

Security is about Infrastructure

When I began in computers it was really fun. I was hired as a "boy genius" at IBM Research. We had the best toys. I had my own IBM 650. I was paid to take it apart and put it together again. How great is that? I got to work with Dr. Albert Samuels who was programming the IBM 704 to play checkers. My colleague, Dick Casey, and I programmed the 650 to play Tic-Tac-Toe. We had to use it on third shift but we even had a third of an IBM 705 where we installed the first Autocoder in Poughkeepsie. I drove my transistor radio with a program on the IBM 1401.

That was just the beginning. For fifty years I have had the best toys. I have three PCs and a MacBook Air. I am on my fifth iPhone, and my fourth iPad. I carry my fifty years of collected music and photographs, an encyclopedia, a library, and a dozen movies in my pocket. It just keeps getting better. It is more fun than electric trains.

One of my favorite toys was the IBM Advanced Administrative System, AAS, five IBM 360/65s and a 360/85. It was so much fun that I often forgot to eat or even go home at night. However, on AAS one of my responsibilities was to manage the development of the access control system. It was great fun to do and fun to talk about. Serious people came to White Plains to hear me. I was invited to Paris, Vienna, Amsterdam, London, Helsinki, and Stockholm to talk about my fun and games, about how we provided for the confidentiality, integrity, and availability of our wondrous system.

However, as seems to happen to us all, I grew up, and finally old. My toys, fun, and games became serious. Some place along the way, most of the computers in the world were stitched together into a dense fabric, a network, into a world-wide web. While still entertaining, this fabric had become important. It supports the government, the military, industry, and the economy.

Without any plan or intent, driven mostly by a deflationary spiral in cost and exploding utility, the fabric had become infrastructure, part of the underlying foundation of civilization. It had become peer with water, sewer, energy, finance, transportation, and government. Moreover, it had become THE infrastructure, the one by which all of the others are governed, managed, and operated.

We build infrastructure to a different standard than toys or anything else not infrastructure. Infrastructure must not fall of its own weight. It must not fall under the load of normal use. It must not even fall under easily anticipated abuse and misuse. In order to prevent erroneous or malicious operation, the controls for infrastructure are reserved to the trained operators and from the end users.

No special justification is required for this standard. The Romans built their roads, bridges, and aqueducts, such that. with normal maintenance, they would last a thousand years. And so they have. The Hoover Dam and the Golden Gate Bridge were built to the same standard. With normal maintenance, and in the absence of unanticipated events, they will never fail. (They may be decommissioned but they will not fail.) No one quibbled with Henry Kaiser over the cost or schedule for the dam.

However, our fabric was not driven by design and intent but by economics. No technology in history has fallen in price and grown in power as fast as ours. While we tend to think of it in terms of its state at a point in time. it continues to grow at an exponential rate. Its importance can hardly be appreciated, much less over-stated.

Given the absence of design and intent, it is surprisingly robust and resilient. While not sufficient for all purposes to which we might wish to put it, it is sufficient for most. With some compensating design and intent, it can be made sufficiently robust for any application.

One word on "easily anticipated abuse and misuse." On September 12, 2001, what could be easily anticipated had changed forever.

As security people, we are responsible for the safe behavior, use, content, configuration, and operation of infrastructure. As IT security people, we are responsible for the only international infrastructure, the public networks. As users, we are responsible for not abusing, misusing, or otherwise weakening it.

Note that ours is the only infrastructure that, at least by default, contains weak, compromised, or even hostile components and operators. It is the only one that, by default, has controls intended for the exclusive use of managers and operators right next to those for end users. Our infrastructure also, by default, connects and exposes the controls of other infrastructure to most of our unprivileged users. It is our job to compensate fro and remediate these conditions.

Our roles, responsibilities, privileges, and special knowledge give us significant leverage over, and responsibility for the infrastructure of our civilization. Everything that we do, or fail to do, strengthens or weakens that Infrastructure. That is why we are called professionals and are paid the big bucks.