Thinking About Security

SOPA, Bought and Paid For

2012-01-10T13:06:00.000-08:00

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

2012-01-03T14:39:00.000-08:00

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

2012-01-02T10:38:00.000-08:00

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

2011-12-28T11:58:00.000-08:00

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.

Security is about Efficiency

2011-12-15T14:54:00.000-08:00

For the first thirty years I was in the computer security business, I often wondered what I was doing. I didn't have a product or a service. I did not have a customer. The computer was so sparse that it was not even important. Was I making a difference?

Part of me really wanted to go back to project management at which I was better than the average bear. The projects might not have made an existential difference but I knew that I had done them well. Satisfying.

Even today, I get discouraged. When I look at health care and see that safety and privacy are being used as an excuse not to automate health records, I get discouraged. When I look at the payment card industry, I get discouraged. When I look at SCADA, I get discouraged.

When I read about on-line banking being used to rip off another small business, non-profit, or municipality I get angry. I get angrier still when the courts and the regulators permit the banks to escape their fundamental responsibility to ensure that all transactions are properly authorized.

I have the good grace, not to say good sense, to be chagrined when I hear that another enterprise has been completely compromised because a user clicked on an obvious bait message, or even an artfully crafted one.

I am sad when I see that High School Harry Hacker has grown into the organized criminal of the day and is being recruited as a spy by governments all over the world. I am shamed when so-called "security researchers" publish exploits for obscure vulnerabilities rather than work-arounds for those that are being actively exploited. I am shamed when rogue hackers identify themselves as "security consultants" and claim that they are just trying to be helpful, just doing what security people do.

I feel a sense of failure when I see that US government security, the best in the world for decades, has all but fallen apart: that it mis-classifies. under vets and supervises, and over-clears. Under these circumstances Wiki-leaks is inevitable. However, Wiki-leaks might be tolerable if it were not typical, if the entire government was not such a large source of leaks of sensitive and personal information.

We security people are probably not unique among professionals for holding ourselves to very high expectations and being disappointed with our results.

In order to keep my perspective, sanity, not to mention my self respect, I have put a post-it on my bathroom mirror. I read it several times a day. It says, "We are not about perfection."

That's right. It is not my job to prevent all leaks and losses. It is not my job to make the world safe for democracy, or even the Internet safe for all applications. It is not my job to prevent all the Seven Deadly Sins, the motives for the things that we do wrong. I am not responsible for every unchecked input, much less preventing all the SQL-injection and buffer over-flow attacks that exploit them.

It is not my fault that the banking industry has consistently and persistently ignored my sage advice to confirm all changes of address to the old address and unusual transactions out-of-band, to change from mag-stripe and PIN to smart-cards, and to use strong authentication.

While I have to advocate that all Internet facing web applications should use the OWASP Enterprise Security API, I am not responsible for most failures to do so. While I am responsible for using every teaching and training hour efficiently, I should not condemn myself for failing to communicate the entire canon in an hour or not rationalizing all media coverage and political thought.

Our job is to make the world work better with us in it than it would be without us. Fortunately we have such leverage that that is not very difficult. While we do not make the world perfect, we make an existential difference.

As security professionals, we are expected to know that some losses are cheaper to tolerate than to prevent, some damage cheaper to repair than resist, that no matter what they think they want, no one really wants perfect security. We are expected to know that the cost of security curve is not linear, that to halve one's risk, one must double one's cost, that the better one's security already is, the less efficient the next dollar spent.

Our job is to ensure that all of the systems, applications, networks, and enterprises in our care get the protection that is appropriate to their sensitivity and the environment in which they operate, and that expensive security measures are reserved only for the targets that require them. Said another way, our job includes avoiding the use of inefficient measures. It is more about efficiency than effectiveness. If we prevent a loss or save the cost of a protective measure, in either case, the impact falls right through to the bottom line of the enterprise, the line called profit, the one that measures enterprise efficiency and contributes to the productivity of the economy.

Our job is to ensure that the sum of the cost of losses and the cost of security is at a minimum. That is impossible to know at any given point in time. It is a balancing act. It is not stable; it moves as the threat changes and the cost of technology falls. It takes both measurement and management to approach it over time. However, that is our job and our opportunity. That is how we make the world work better and justify our existence. If it were easy, they would give it to someone else.

Only when we rationalize our expectations of ourselves, communicate those expectations to our employers and clients, and measure ourselves appropriately against them, will we be satisfied with our jobs, appreciated as professionals, and paid the big bucks.

Security Culture for the Cloud

2011-11-21T14:07:00.000-08:00

It is difficult to miss the trend toward "outsourcing," to have things done by others that traditionally had been done by employees within the enterprise. This trend is facilitated in part by "The Cloud," the Internet and the incredible range of services, fee and free, that are offered on it.

I used the example of Stanford Health Clinic that transferred patient information to a collection agency only to have it posted to a public site on the Internet, a gross and egregious violation of the privacy of their patients.

I left you with the idea that our professionall objective is to arrive at a state in which all parties understand their roles and responsibilities and carry them out in such way as to produce the intended results.

I had decided to elaborate on that advice this week. I came up with a list of policy, technical, and legal guidance for use with out sourcing.

I was going to suggest that enterprises should have a policy that spells out its risk tolerance in general and in regard to the use of outside sources in particular. It might specify which data and applications could be outsourced and which could not. For example, it might specify that the enterprise's intellectual property and personal information should not be outsourced. It might also specify insurance coverage for any risk that exceeds the specified tolerance.

I planned to say that agreements should enumerate the laws, regulations, and contracts to which the parties are subject and all standards that they had adopted. They should also spell out any limitations such as the requirement to disclose information in response to legal service.

I was going to suggest that enterprises should prefer to do business with vendors that were part of such organizations as the Cloud Security Alliance and the Cloud Auditing Data Federation Working Group (CADF). I would have suggested that using enterprises might want to participate in the Cloud Standards Customer Council.

I would have stressed that your contract should provide for audit or for a service auditor report, I would have cautioned you about the limitations of service auditor reports, for example, that they are limited to controls asserted by the auditee and that they are as of the time of the audit.

I had planned to suggest that agreements should be service by service and application by application.

I intended to suggest that agreements should enumerate all existing controls, who is to operate them, and under what conditions. That the agreements should spell out the intended use of the controls as well as what record the use of the controls would produce. Examples of such controls include, Identification, authentication, access control, encryption, administration, provisioning, confirmations, messages, alerts, alarms, measurements, and reports.

I would have emphasized the importance of provisioning controls in The Cloud and pointed out that compromise of those controls might enable others to use services and charge them to you. I had even planned to stress that all use of such controls result in automatic out of band confirmations. I would have given a caution about error-correction and vendor over-ride controls.

Fortunately, while doing my research, and before I had embarrassed myself with all of this irrelevant advice, I came across a report in the New York Times by KEVIN SACK Published: October 5, 2011. Here is part of what I learned.

First, there was no evil here, no recklessness, not even gross negligence, just bad judgment all around. To the extent that there was any motive, it was efficiency, just getting the job done. No greed, no lust, not even sloth.

Stanford Hospital and Clinics (SHC) is a 600 bed general hospital. It is not Kaiser-Permanente or UPMC but it is a major enterprise in its community.

Multi Specialties Collection Service (MSCS) is a collection agency for medical services in the same market as SHC. It bills about $0.5M per year and employees 5-10 people. One might call the relationship asymmetric, one-sided.

The identity and role of the sender of the information is not public, but should have required significant management discretion and rare privileges to access and send it.

The receiver of the information was a contractor to MSCS. He often represented himself as an officer of MSCS and had an MSCS e-mail address. Been there, done that. He decrypted the data, put it in a spread sheet, and, among other things, gave it to an applicant for a job with him.
While SHC says the information was for "permissible hospital billing support purposes," the consultant says that it was for a "study." In any case, the information was not passed in the normal course of "collections," the service. I believe that both the sending and receiving of the information probably was outside the agreement between SHC and MSCS.

The actual posting to the public web-site, StudentofFortune.com, was by a job applicant to the consultant. He had given the applicant the spreadsheet to convert it to charts and graphics as a test of skill

The posting was a violation of the SoF Terms of Use which require the user to "represent and warrant that (they) (a) own or have sufficient rights to post (their) Contributions, on or through the Site, and (b) will not post Contributions that violate Student of Fortune or any other person’s privacy rights, publicity rights, copyrights or contract rights.

Two things seem clear. First, everyone involved has egg on their face except StudentofFortune.com. Their Terms of Use were obvious, concise, plain, and clear. One cannot register for their site without acknowledging and agreeing to them. When the violation was called to their attention they responded on a timely basis. I would gladly testify for or against any of the other parties.

Second, none of the policy, technical, or legal measures that I wanted to recommend would have prevented the breach. If asked in advance, management might well have accepted the risk that so many controls and people would fail at once, However, SHC is now the target of a $20M class action law suit and will almost certainly be penalized by the regulators. MSCS has lost a major client, has closed its web site, and is not answering its phone.

I am not sure that the penalties fit the crime but they sure are getting our attention However, to the extent that the breach impedes the urgent move to electronic health records, or even the efficient use of cloud resources, perhaps they are proportional.

I like to think that my lists above are useful, if not necessary, but they are clearly not sufficient or even the place to start. No, we are back to management and security 101. There is no substitute for training and supervision.

"Outsourcing" makes this even more important. Note that StudentofFortune.com is typical of free or low-cost collaboration "cloud services" that help our employees get their jobs done and are within the discretion of most of our employees. We are going through a major change in how we organize production and resources. It is being driven by the falling cost of information technology. As this new model matures we need to evolve a culture of personal due care, one in which people automatically ask "should I do it" rather than simply "Is it efficient?" A culture in which people automatically consult with others before they act, a culture of caution.

Security must start with our most effective controls, training and supervision. We should focus on or use our other tools only to the extent that they are more efficient. Then we will be called professionals and be paid the big bucks.

On Resistiing Phishing Attacks

2011-11-17T20:38:00.000-08:00

At Secure World in St. Louis I heard a presentation on "Cybercrime" by Brian Mize, a Special Federal Officer with the FBI. One of Brian's points was the number of such crimes that begin with a successful crafted bait e-mail message. Brian reported that more than half of crimes investigated by the St. Louis Cyber Squad, on which he serves, began with such a message.

While there were many steps in the attacks, they began with bait messages, specifically because they are so efficient. By definition, if one puts bait before a sufficient number of people, someone will take it. The interesting thing is how small that number has to be. In one group of 527 targets, one in ten took the bait.

The bad news is that only one click by one user may be sufficient to contaminate the entire enterprise. The good news is that all most all attacks against enterprises are starting in the same way.

The bait of choice no longer appeals to fear, greed, or lust. Rather it appeals to curiosity. Human beings are naturally curious; curiosity has survival value. Mass bait will be of the form "Look what Justin Bieber did." Alternately it may exploit the disaster news of the day. However, messages directed to the enterprise, while still appealing to curiosity, are much more artfully crafted. For example, the bait that compromised RSA was a pdf identified as "2011 Recruitment Plan." If this came to you from someone whose name you recognized, would you be suspicious? Would you resist it? Remember when we preferred PDFs to Word documents for safety?

The obvious defense against bait attacks is awareness training. However, as with campaigns like "Just Say No." there are fundamental limits to the effectiveness of such training. We are left with the fact that a successful attack only requires one temporary failure of our training.

I met Brian later and we agreed that we really need an effective an efficient artificial intelligence, AI, for identifying such messages. We both identify and reject one or two bait messages a day that get past our spam filters. If we can identify them, surely Google could.

However, I heard another presentation by Steve Ward, Vice President of Marketing for Invincea, speaking at Data Connectors at Bridgewater's at the end of Fulton Street. He talked about a product that took a different approach. It looked at the second step in the attack. It seems that one bites, i.e., "takes the bait," by clicking on a button. It turns out that almost all of the buttons are URLs. Steve says, even if I cannot stop everyone from biting, one might be able to cut lhe line just as they do. Only rare messages are bait but all bait messages are URLs.

The URLs link to an executable that corrupts the user's system. It effectively contaminates the network, all machines to which that machine is peer connected. In far too many enterprises, that is the entire enterprise network.

Note that contaminiation requires user privileges, perhaps ADMIN, at least the ability to create or modify an executable. Part of the problem is that users that do not require such privileges have them by default. On the other hand, we cannot limit all such privileges.

However, Steve Ward points out that controlling the process that parses the URL could prevent the contamination. His product takes an architectural approach, it installs as an application, becomes the parser for all URLs, and interprets them in a virtual machine so as to prevent contamination of the real machine. Even if a privileged user takes the bait, her machine will not be contaminated.

Efficient security relies upon layers and redundant measures. We must train users to recognize and resist bait. We must limit their privileges. We must configure their systems to resist contamination. We must layer and compartment the enterprise network to resist the spread of contamination. We must control access to sensitive data. We must monitor, detect and remediate. We must resist exfiltration of our data. Of course, it is because knowing and doing this is difficult that we are called professionals and are paid the big bucks.

FBI Proposes Alternate Network

2011-11-02T07:11:00.000-07:00

At the recent ISSA Conference in Baltimore, FBI Executive Assistant Director, Shawn Henry, proposed a "new alternate secure Internet," separate from the public Internet, to operate the nation's critical infrastructure. While there is clearly a need for better security, I am going to argue that this proposal reflects a poor understanding of both the problem and of networks.

The government is justifiably concerned about the existential vulnerability that has arisen because of the connection of infrastructure controls, i.e., supervisory control and data acquisition (SCADA), to the public networks. This connection permits at least parts of the infrastructure to be operated from any place in the world. To the extent that the controls are insecure, they can be abused or misused to cause the infrastructure to be mis-operated.

To the extent that the infrastructure itself is fragile, mis-operating it may cause damage that cannot be efficiently remedied. "Experts" have speculated that the infrastructure might be maliciously operated in such a way as to shut down our entire economy for days to weeks. Value and savings might be destroyed. Millions might starve or freeze unless we could rebuild in days what it has taken us decades to create.

However unlikely such an event, to the extent that such a vulnerability is implementation induced, rather than fundamental, it should not be tolerated. Making controls intended only for the use of a few privileged operators visible to everyone is unnecessary, in this case, reckless. It is analogous to putting a copy of the control of the autopilot for an airliner between every two seats.

However, it is specifically because the infrastructure is fragile that the controls are connected to the public networks in the first place. The operators understand that the infrastructure must be "operated;" that its continued service requires that it be monitored, adjusted, "provisioned," and configured to compensate for changes in inputs or load or the inevitable failure of components. While some of this operation is automated, some of it requires timely human intervention.

The operators of these controls have connected them to the public networks on the implicit assumption that, far bigger than the risk of connecting them would be their own inability to monitor and operate the controls on a timely basis. Few of them see their connection in the context of all the other connections. They understand that no single connection would represent a major risk; they are only just waking up to the realization that the collection constitutes an existential vulnerability.

Part of the problem in the Critical Infrastructure space is the culture. Given the sensitivity of these controls, one would expect them to be hidden behind virtual private networks and strong authentication. For reasons of convenience, for the most part they are not and that is the root of the problem.

In order to provide for around the clock, but somewhat sparse, remote monitoring and control, the operators have have connected the controls to, not just one, but to both of the public networks. While this kind of remote operation is good for the enterprise, and may even be strategic, many of the early connections were tactical, more by and for the convenience of the operators than for the enterprise.

In order to improve the chances that they can always connect when necessary, that is, compensate for any network failure, many of the controls are connected both to the public switched telephone network (PSTN) and the Internet. While they use the public wide area networks, they use them to create a limited number of relatively short point-to-point connections, for example, from the operator's home to the plant.

While the public networks permit world-wide any-to-any connectivity, and while the operators might actually monitor and operate their systems from the end of a plane trip, that is the exception, not the rule. The result is that anyone may use the public networks to send a message to any of these controls. They may be able to connect and operate the controls.

In the early days, most of these controls were purpose-built, offered only a limited command interface, and operating them required a lot of special knowledge. Even finding them would have been difficult, much less misusing them. Today, many have already been identified; most of them have graphical user interfaces and require much less special knowledge. Moreover, such intelligence as operator manuals and other documentation may be independently available in the world-wide-web.

Behind the controls, there may be operational dependencies between components such that operation of one may influence the behavior of others. For example shutting down the external power to a nuclear reactor may cause the reactor to shut down. These effects may cascade. The electrical grid is the most inter-dependent of the infrastructures and almost everything else is dependent upon it.

What might a "separate" network look like? How separate might it be? Well, it might be as separate as the two public networks are from one another. For example, it might have a separate "address space." Like these two networks, it might use different signaling, connection setup, and protocols.

On the other hand, the Internet, the digital network, originally piggy-backed for connectivity on the PSTN, the analog network. Today, for reasons of efficiency, all wide area networks share the same glass and copper fabric and most analog traffic is now encapsulated in digital. While much of that fabric is less than a decade old, it has taken us more than a century to achieve near world wide coverage. Surely a new separate network would exploit the existing fabric rather than attempt to replicate it.

For security reasons, it might be desirable for the networks to have different user populations. However, that would mean that a user of the alternate network could not use the public one. Not very likely.

The single public fabric that we use today emerged as a number of public and private networks coalesced around the Arpanet. When I first became an e-mail user, I had a list of tens of gateways and paths from the IBM network to other networks. We would use nested addresses of the form ((foo@foonet)@ibmgatewaytofoonet.com). Sometimes these addresses were two or three layers deep. An x400 or proprietary address might be nested inside an IP address or vice versa. Routing through these gateways often required a great deal of special knowledge. Gradually those gateways gave way to intelligent routing. x400 and other forms of addressing gave way to IP addressing.

The Internet is defined, and has evolved, as the collection of all networks that are connected to one another, that communicate in Internet protocols, or that are connected via gateways, think firewalls, that use that protocol. We did not set out to have one network; there was no design or intent. The Internet came about for economic reasons. The value of a network goes up with the number of potential connections. Therefore, the propensity of two networks to connect goes up with the square of their size. The unfortunate corollary to this is that, if we were able to provide a separate network, the users would respond to the economics by connecting them together again.

So for a number of cultural, technological, and economic reasons, a completely separate "alternate" network, no matter how desirable, seems unlikely. While still unlikely, a more viable alternative might be one or more virtual private networks (VPNs) exploiting the underlying fabric of the public networks.

Moreover. most of the advantages of such a network or networks can be achieved with much cheaper alternate mechanisms such as strong authentication, end-to-end encryption, and firewalls and other proxies. Even if there were hope for the kind of alternate network envisioned by Director Henry, it would still be our job to apply those mechanisms while we were waiting for it to emerge. It is also necessary to hide all of the information about the infrastructure controls that is gratuitously available to all but needed only by the few.

The status quo is the result of a large number of individual but reversible choices. It is unacceptable. It is our job to fix it. For that that we are called professionals and are paid the big bucks.

On Understanding Biometrics

2011-10-25T07:31:00.000-07:00

A decade or so ago, I had an extended dialogue with David Clark, of the Clark-Wilson Model, about biometrics. He knew that the remedy for a compromised password was to change it. Since he knew that biometrics could not be changed, he could only understand how they worked for about fifteen minutes at a time, about the same length time that I can understand the derivation of an RSA key-pair.

Unlike Passwords, biometrics do not rely upon secrecy, they do not have to be changed simply because they are disclosed. Biometrics work because, and only to the extent that, they are difficult to counterfeit.

We have all heard about the attacker who picked up a latent fingerprint in gelatin and replayed it, or the image scanner that was fooled by a photo. Good biometric systems must be engineered to resist such attacks.

While the fundamental vulnerability of passwords are replay and disclosure, the fundamental vulnerabilities of biometrics are replay and counterfeiting. These vulnerabilities are limitations on the effectiveness of the mechanism, rather than fatal flaws. What we must ask of any implementation is how does it resist replay and counterfeiting.

At a recent NY Infragard meeting there was discussion of biometrics that illustrated that this confusion persists. In this case, at least one person seemed to be convinced that the secrecy of the stored reference had to be maintained in order to preserve the integrity of the system.

This is a slightly different kind of confusion with what we know about passwords. While the fundamental vulnerabilities of passwords are replay and disclosure, the fundamental vulnerabilities of biometrics are replay and counterfeiting. These vulnerabilities are limitations on the effectiveness of the mechanism, rather than fatal flaws.

As with passwords, one cannot go from the stored reference to what one must enter. We solved the problem of disclosure of the password reference by encrypting it with a one-way transform at password choice time. At verification time we apply the same transform to the offered password and compare the encrypted versions. By definition of "one-way transform," it is not possible to go from the stored reference to the clear password.

We do not store an image of the face, the password, or a recording of the voice, Instead we store a one-way, but reproducible, transform. To make sure that the transform is reproducible, we may collect multiple samples so that we can test for reproducibility.

However, as with passwords, biometrics are vulnerable to replay attacks. While we cannot discover the biometric from the reference, we might capture an offered instance and replay it over and over.

Like passwords, biometrics may be vulnerable to brute force, attacks, but unlike passwords, they are not vulnerable to exhaustive attack, if only because it is impossible to try every possibility. While a password reference can be stored in 8 or 16 bytes, a biometric reference may be hundreds or low thousands of bytes. In an exhaustive attack against a password, each unsuccessful trial reduces the uncertainty about the correct answer; this is not be true about a brute force attack against a biometric.

For most purposes we use brute force and exhaustive as though they were synonymous but they really are not. In brute force, we submit a sufficient number or trials to succeed in finding a (false) positive. An exhaustive attack is a special case of a brute force attack in which we are trying to find one integer in a known set. The reference for a biometric is too large to be exhausted but there are many samples that will fit.

This introduces the issue of false positives. There is only one password that will satisfy the transform, it is at least one integer value away from those that do not satisfy. We key in the integer. However, we "sample" a biometric; there will be many biometric samples that will fit. Depending upon the precision of our system, it might even be possible to dupe the system, a false positive. On the other hand, it is also possible for a given sample of a valid biometric to be rejected, a false negative.

Biometric systems can be tuned so that they achieve an arbitrary level of security; we are looking for a transform that minimizes both false positives and false negatives. Unfortunately we reduce one at the expense of increasing the other. That is to say, the less likely it is for the system to permit a false positive, the more likely it is to generate a false reject. We tune the mechanism to achieve an acceptable ratio of on to the other for a particular application and environment.

My preferred biometrics are the visage, i.e., the face, and the voice. These share the advantage that they can be reconciled both by a computer and by non-expert human beings. Infants can recognize their parents, by face and voice, by the age of six months; it has survival value. Many share the experience of recognizing someone, that we have not seen in years, from one or two words, spoken over the telephone.

Until very recently, machines could not reconcile faces as fast humans, indeed fast enough for many applications. However, Google now has software that can not only authenticate an individual from an arbitrary image but identify them within seconds.

For most of the time that they have been in use, fingerprints could only be reconciled by an "expert," but we now have computers that can do it even better than the experts. In fact, recent studies using theses computers have suggested that even these experts are all too fallible. Nonetheless, non-experts can independently verify fingerprint identification.

Think about DNA. While it discriminates well, it contains so much information that it takes a long time to reconcile and the results cannot be independently verified by amateurs. To some extent we will always be dependent upon instruments and experts.

Since biometrics share a vulnerability with passwords to replay, a password plus a biometric does not qualify as "strong authentication." Therefore, the preferred role of biometrics is either as an identifier or as an additional form of evidence in a system of strong authentication, one in which another mechanism, e.g., a smart token, is used to resist replay.

Because there is only a vanishingly small chance that two samples of a biometric will be identical, any sample that matches one previously submitted could be thrown out as a possible replay.

Part of the special knowledge that identifies us as security professionals, and for which we are paid the big bucks, is that knowledge about the use, strengths, and limitations of biometrics.

Who is Responsible for Security?

2011-10-12T08:24:00.000-07:00

On September 30, 2011, SANS Institute NewsBites reported the following story:

--European Union to Introduce Liability Rules for Cloud Vendors (September 28 & 29, 2011) The European Union (EU) plans to introduce the "Binding Safe Processor Rules," which would hold vendors of cloud services in the EU liable for data security breaches. Vendors would sign up for what amounts to an accreditation. Consumers are likely to feel safer doing business with a company that is willing to stand behind its services. The rules are an update to the Data Protection Directive. The companies will be required to demonstrate their compliance with certain data protection standards for approval under the rules. Current law holds data owners responsible for data loss.

They cited two sources, SC Magazine and V3.co.UK, The Frontline.

http://www.scmagazine.com.au/News/275173,eu-cloud-vendors-liable-for-breaches.aspx

http://www.v3.co.uk/v3-uk/the-frontline-blog/2112906/eu-rules-allow-cloud-companies-legally-customer

The NewsBites editor added the following comment by me.

[Editor's Note (Murray): The devil is in the details and the rules may be helpful. However, the idea that one can transfer the responsibility for protecting the data from the owner to the custodian by fiat, or any other way, is absurd on its face. The decisions about protecting the data cannot be separated from the decisions about collecting it and using it.]

While I confess I misread the details, they are where the devil is hiding. It turns out that this rule is nothing like it sounds either in its name or in this report. Instead it was sought by Amazon, Google, and others to say that EU enterprises may rely for security of their data upon service providers that are certified by an EU country as complying with these rules and without regard to location. It is a response, in part, to the fact that Europeans will not do business with US service providers because they are subject to the USA Patriot Act. They are concerned that they would be accused of improper reliance. The EU has never been happy with the idea of data on Europeans being stored in the US.

This week NewsBites reported this story:

--Stanford Hospital Pins Breach Responsibility on Third-Party Billing Contractor (October 6, 2011) Stanford Hospital & Clinics says that a data security breach that compromised the personal information of 20,000 patients is the fault of a third-party contractor. One of the patients filed a US $20 million lawsuit against Stanford following the breach disclosure last month. The data were exposed because a spreadsheet handled by a billing contractor somehow was posted to a student homework help website. The compromised information includes names, diagnosis codes and admission and discharge dates.

http://www.computerworld.com/s/article/9220626/Stanford_Hospital_blames_contractor_for_data_breach?taxonomyId=17

Now, I have to tell you, the Hospital tells a really great tale. Mind you, it does not excuse them for the breach. However it might have confused a jury if they had not attempted it to try it out in the media first.

Seems they turned the data over to a collection service, MCSC, in encrypted form. This is allowed under HIPAA rules but requires that they have security of the data as part of their agreement with the service provider.

Needless to say the collection agency, MCSC, decrypted the data. It converted it to a spread-sheet before turning it over to an "unauthorized" third party, This third party posted it, as an attachment to a request for assistance, to a site called Student of Fortune where it remained for a year. Student of Fortune is a site where students can solicit assistance with their homework assignments. It seems this third party wanted assistance with a graphical representation of the data in the spreadsheet. It would probably be unfair for one to infer that someone familiar with such a site is a recent student. There must be some truth here. You can't make this stuff up.

It seems clear that there is plenty of blame to go around here. However, the question is not blame but responsibility, ethical, legal, financial, and otherwise.

Public and private enterprises are increasingly relying upon contractors and other enterprises, "partners," to carry out duties and responsibilities that historically have been performed by employees and within the enterprise. Therefore, it is timely to revisit the question of responsibility.

Both of these stories suggest that the responsibility rests with the custodians of the data, The first story suggests that the responsibility can be assigned to the custodian by order of the state or the consent of the custodian. The second suggests that the responsibility moves with the data.

Ultimately, the legal questions raised by these stories will be decided by courts. I can hardly wait. I am a great fan of court records and decisions. While subject to error, they are much more reliable than the statements of the parties.

In Information Assurance, we have traditionally assigned protection duties and responsibilities in terms of roles, i.e., management, staff, owners, custodians, and users. We have argued that, by definition and default, the responsibility to protect the data rests with the "owner," the manager responsible for all the decisions about the data.

For example, the owner makes the decision to collect and store the data. The owner, again by definition, makes the decisions about who can use the data. The owner makes the decision as to the sensitivity of the data, how much to spend on protection and how much risk to accept. The owner's responsibility includes communicating these decisions to custodians and users.

It is difficult to see how this control and discretion can be separated from the responsibility for its exercise.

Our colleague, Bob Johnston, likes to argue that "When entrusted to process, you are obligated to safeguard." However, as a custodian I would respond by asking how much and at whose expense? Clearly a custodian would not want to spend more than the owner would and would expect to be reimbursed or compensated for what he does spend.

What is really at issue here is how we identify and select custodians, describe their duties, compensate them for those duties, what penalties they must pay for breach of those duties, and to whom. Obviously, this begins with negotiations between the owner and the custodian. I will continue to argue, both as matters of definition and practicality, that the responsibility for the results, the success, of those negotiations must start and end with the owner.

As a matter of law and good public policy, we want the responsibility in the same hands as the discretion. The alternative would permit the owner to pick the low cost service provider and then escape responsibility for any consequences. One might call that moral hazard.

Service providers are in the role of custodians of the data. Their duty is to the owner of the data, the party that pays them, not to the subjects of the data. They must be diligent in the execution of the duties that they have agreed to and for which, in part, they are being paid.

Stanford Hospital had a duty to their patients to protect the data. That duty did not go down when, for their own convenience and efficiency, they decided to give a copy to another party, a party of their choice. That they encrypted it for purpose of transfer, did not protect it from that agency, to whom they also gave the key. The agency's duty was to Stanford Health, to protect the data in accordance with their agreement, the provisions of which we are left to guess. While it is unlikely that Stanford Hospital specifically contemplated the possibility that MCSC would give a copy to a contractor, their agreement should have resisted it.

One might argue that as a collection agency, the agency owed a duty to the subjects of the data. However, it would be hard to argue that that duty relieved Stanford Health of its responsibility..

As security staff, some for the owners, some for the custodians, our role is to assist the business managers and lawyers in expressing the security requirements in such a way that all parties understand their duties and are likely to discharge them in manner that will produce the intended results. Our job does not stop there; we must go on to measure and report the results, note variances from the expected and intended, and recommend timely corrective action on a timely basis. "Timely" is before, rather than after, any breach. To the extent that this is difficult, we are called professionals and are paid the big bucks.

The Terrorists Won

2011-09-15T12:50:00.000-07:00

I know that is not a popular position and this is not a popular time to take it. I expect to take some flack for saying it. I identify with the little boy that pointed out the naked emperor, but the emperor was not a danger and the little boy had no obligation to say anything.

I have had the Principle of Proportionality on the list to talk about for a while but something always trumped it. This weekend has elevated it.

Terrorism is defined as an attempt to effect political change through fear and intimidation, usually by attacking civilians. When an act of terror produces political change out of proportion to the act, by definition, the terrorists win.

For example, the Blitz was terrorism. Dresden was terrorism. Hiroshima and Nagasaki were terrorism. The IRA bombing of London was terrorism. 9/11, as terrible as it was, barely ranks with the least of these. The Blitz did not affect the intended political change. It did not turn the British people against the war. Dresden did not achieve the capitulation of Nazi Germany. The terrorists did not win.

In response to 9/11, we have fought two major wars at a cost of more than 100 thousand lives, $1T, and our reputation as a moderate and moderating influence in the world. We are locked in those wars to the tune of $2B per week with no honorable way to withdraw. That is called disproportionate. The terrorists won.

We have betrayed our own principles. We have engaged in torture, imprisoned people without charge or trial, and spied on our own citizens. We have denied Habeas Corpus, public trials, a jury of one's peers, and surrendered the Common Law principle of "innocent until proven guilty." That is called disproportionate. The terrorists won.

We are more divided than at any time in this century. We are so divided by party that good policy is no longer politically possible. We are divided by region, religion, and origin. The terrorists would delight.

We now spend $8B a year on TSA. Of all the bad things that can happen when one gets on an airplane, this addresses only the least of them. That is called disproportionate. The terrorists won.

We have created a huge, expensive, and secret bureaucracy. There are 1000 of them for every identifiable terrorist in the world. They have built themselves a headquarters second only to the Pentagon. We did not even notice. Speaking of the Emperor's suit, no politician has the courage to question this budget. We are no more than one election from having this monstrosity, in an excess of caution or zeal, turned against the citizen. That is called disproportionate. The terrorists won.

As I write this, CNN is reporting three stories. One is about a the catastrophic flooding of the Susquehanna River, a river that is awesome even when it is not in flood. The second is about the loss of electric power to 5M people in the southwest on a day when temperatures reached 115 degrees Fahrenheit. The third is about a "specific, credible, but uncorroborated," not to mention "secret," threat, linked to Al Qaeda, and involving three "terrorists." That is called disproportionate. The terrorists won.

We have become a fearful and timid people. We are incapacitated by fear. We behave as though terrorism were an existential threat, the equivalent of thermo-nuclear war. It is sad to see the tourist in the airport, justifying the removal of her diaper as "it makes us safe." This is called disproportionate. The terrorists won.

Even when their plots that fail they win. Can you say "No shoes, no belts, no suspenders, no diapers, no liquids, no nail files?" That is called "disproportionate" not to mention "locking the barn after the horse is stolen."

At their most ambitious, the terrorists never imagined that we would afford them such disproportionate leverage. They won big time.

Of course "security" has also won. There are at least ten of us today for every one of us a decade ago. Dozens of new security and intelligence businesses have sprung up along the beltway, mostly on contract to DHS.

Proportionality is the fundamental principle of security. "Do not spend more mitigating a risk than tolerating it will cost you." A fundamental principle of our professional ethics is that we must not give unwarranted comfort or unnecessary alarm to our constituents. While I understand how difficult that balance is, I suggest to you that we have not served our constituents well over the last decade. We have not deserved the right to be called professionals or to be paid the big bucks.

Yes, I did see the photo of Presidents Bush and Obama. I did hear Renee Fleming sing Amazing Grace and the New York Philharmonic play the Resurrection Symphony. I saw the Concert from the Kennedy Center. I know that New York's Bravest are still ready to go into harm's way to protect me. I am hopeful.

However, there will be other terrrorist attacks, some successful. Hopefully these will be at the limits of our abilities, but it is simply not possible even to identify, much less deter, all the crazies. Our leaders have already set us up to see these as "failures of security," as justification for even more drastic measures. That is what government does. If what they are doing does not work, they simply do it harder.

It is our professional responsibility to ensure that America sees these attacks as the inevitable price of freedom, as the price of our values, as the price of greatness. Then we will be professionals and deserve the big bucks.

AES is Broken!

2011-08-31T13:31:00.000-07:00

That is the headline. What does it mean? Should you care?

What does it mean to say that a cryptographic algorithm is broken? Does it mean that the cost of recovering the clear-text without benefit of the key has suddenly fallen to zero? Well, that would qualify, but no, crypto does not fail that way. Does it mean that the cost has fallen to be equal to that of encrypting with the key. Clearly that would qualify, but no, it does not mean that either.

Well, how about the cost has fallen to be equal to the value of the data? How about the time required to recover the clear-text has fallen to less than the life of the data? Well, if either of those had happened, even I might agree that the algorithm was broken. However neither of those has happened either.

For a "standard" algorithm, one might claim an algorithm was broken if the cost of attack was lower than that claimed by the standard.

For example, for the Data Encryption Standard, the DES, the claim was that the cheapest attack was an exhaustive attack against the key, on average, half the time required to try all possible keys. By that standard, the DES is still not broken, low these thirty-five years later. It is true that using a bot farm, one can do a brute-force attack in days. However, for many applications, the life and value of the message are such that no one would spend even that much.

For RSA, the claim is that the cheapest attack is a function of the cost to find the factors of the product of two large primes. While finding the product of two primes is trivial, finding those two numbers knowing only the product is a problem that has challenged mathematicians for a long time.

The time required to try all the DES keys falls as the power of computers goes up but we always know what it is. Similarly, the time required to find the factors of the product of two large primes goes down as computers become more powerful. It might even get cheaper as mathematicians get smarter, but it is unlikely to drop suddenly.

AES is not a standard in the same sense as the DES or RSA. No claim is made for its strength. Rather it is a standard because an authority, NIST, says that it is. It's strength is what it is. We know that the most expensive attack is a brute force attack, but not only has no one ever asserted that there is not a cheaper attack, it has been demonstrated, at least mathematically that there are.. Said another way, by definition, one cannot ever say that it is broken. The best one can say, is "I can find a key this fast."

While some claim that ""Broken" in cryptography is the result of any attack that is faster than brute force"" that simply justifies the claim of the headline. It is not a definition that is meaningful in any sense that a laymen, or even a security professional can understand or use.

By one estimate, the time to brute force a 256 bit key is 5 x (10 )^51 years. What the authors of the paper claim is that they can do it in a mere (10)^51 years. While that may be an interesting improvement, certainly worthy of a paper, even a headline, it does not justify the use of the word "broken" in any practical sense, whatever the authors and headline writers might claim. These authors have simply established the new "standard" cost of attack for the AES.

This is a mathematical assertion that defies any other demonstration. Such an attack, begun at the big bang, would not have completed yet. We call that "strong enough" for security work.

I like cryptographers. Most are very nice people. However, like many such guilds, including security professionals, they have their own special jargon. I appreciate the fact that they do all of these heady calculations for me. However, their security advice is on a par with their medical and legal advice.

Creating a cipher that you yourself cannot break, is relatively easy. All the work is in learning enough about it to be able to predict how much work it would take a body of experts to break it. We call that effort "standardization."

Does all of this mean that our cryptography is "safe," that even nation states cannot read our encrypted data? Not. It has always been my assumption that nation states in general, and the US and Russia, in particular, can read any traffic that they wish.

I am reminded of three colleagues: Phil Zimmerman, who wrote PGP and called it "pretty good;" Adi Shamir, one of the authors of RSA, who wrote, "People do not break crypto, they bypass it;" and Brian Snow, who spent a career at NSA, and who said, "At NSA we spend as much resource on systems as on codes and ciphers."

Algorithms are the strong part of our systems, orders of magnitude stronger than we need them to be. People are the weak point and implementations are in the middle. While it might take the life of the universe to try all possible keys, one might brute force the eight character lock-word used to hide it in a day. Failing that, attackers might bug your systems, suborn your associates, or break your fingers, one after another..

Life would be wonderful it our security was determined by the height of our walls rather than by the guards at our gates, by the strongest link in our chain rather than the weakest. On the other hand, then we might not need security professionals or pay them the big bucks.

Tearing off the PCI/DSS Band-aid

2011-08-24T07:08:00.000-07:00

More than a quarter of a century ago, while I was still at IBM, I had discussions with staff at Sears, then the nation’s flagship retailer, about their forthcoming credit card. I tried to convince them to take the opportunity to force the industry to replace mag-stripe cards with smart cards. They were Sears, they had the clout, they could make it happen. They didn't and the rest is history.

Now, the nation's new flagship retailers, Wal-Mart, Target, CVS, and McDonalds are making it happen. Sears and K-Mart will come along.

Partly in response to these forward leaning merchants, Visa has announced that it will expand its Technology Innovation Program (TIP) program to the US. They will begin transitioning to EMV standard cards and infrastructure.

Some of you are aware that I have been very critical of the payment card industry for continuing to use the broken mag-stripe and PIN system. By doing so, they have put the necessary public trust and confidence in the retail payment system at risk. I am torn between "what took you so long" and "better late than never."

The EMV (EuroCard, MasterCard, and Visa) technology that Visa plans to use has been in use in the rest of the world for years. It uses a contact-less smart card, and optionally, a signature or PIN. It is already deployed in the US in some markets and the leading retailers already mentioned.

Here is an American Express EMV card that I have had for a couple of years. For reasons of backwards compatibility, it also has a mag-stripe. That is good because I can use it in EMV mode in only a limited number of places. Those places include McDonalds, CVS, Target, and Wal-Mart. it is bad because the vulnerabilities of mag-stripe and PIN will persist for years.

Many of the users of the EMV/POS readers deployed by these flagship merchants are foreign travelers to the US. These retailers have bitten the bullet but they cannot get all of the return on their investment until Americans carry EMV cards.

Therefore, these retailers have been a source of public pressure on the payment card industry to deploy this technology. Wal-Mart has been castigating the payment card issuers for more than a year now for "blocking" the use of this technology. Google Wal-Mart EMV and you can see for yourself.

Of course, "blocking" is stronger rhetoric than I am prepared to use. There is history here and business reasons why the issuers have not used EMV in the US. For example, the reason that Sears did not deploy smart cards was that the barrier to entry was too high; it was far cheaper to exploit the existing infrastructure than to replicate it.

While I understand those reasons, and to some degree am sympathetic, I have argued for some time that we cannot continue to rely on a broken technology for the security of our retail payment system. In the presence of cheaper counterfeiting technology, we have strengthened our currency, and even checks, to the point where cards are now the weak link in our system.

Notice that the merchants in this list are all nation wide chains that operate their own systems for authorizing payments. Part of the resistance in the US is rooted in the fact that most of our small and medium-sized merchants use third-party card service providers to accept card payments. These third-party providers enable them to accept any issuer;s card without having to have a separate agreement with and connection to that provider.

While it is an industry standard, EMV is also proprietary. The issuers share the exact workings, under contract and non-disclosure agreements, only within the industry. The important thing for you and I to know is that the card "signs" the transaction, without disclosing its own identity, the "credit card number," to the POS device. EMV resists skimmers and rogue or compromised POS devices. It resists replay attacks and card cloning attacks.

As with mag-stripe, in some, but not all, transactions, EMV will use PINs and signatures to resist the fraudulent use of lost or stolen cards. Because, the primary protection against the use of lost or stolen cards is disabling it after it is reported lost or stolen, PINs and signatures will not be required for all small value transactions.

For example, when I buy a Big Mac, I simply touch my card to the POS device and check the display and receipt to satisfy myself that I was charged the correct amount. No signature or PIN. If I use the same card to purchase an HDTV, I expect to enter a PIN or sign a transaction slip.

One interesting feature of EMV is that a card can be limited in the number of PIN-less transactions that it can do. An internal counter keeps track of the number of PIN-less transactions. The count is reset to zero for every PIN transaction. If the count reaches the threshold, the next transaction must involve, will prompt for, the PIN.

Because the POS device cannot capture the EMV card number, it is safe to enter a PIN into it. The PIN is only useful with the card or card number. I have long argued against "debit" card transactions where both the card number and the PIN appear in the clear at the point of sale. These are the source for many counterfeit cards.

While it is now relatively cheap to clone a mag-stripe card, knowing only the public number, this is not sufficient to clone an EMV card. Putting aside the fact that it is more expensive to write chips than stripes, cloning the EMV card requires knowledge of its secret token. It is secret for a reason, a security reason.

Another reason the issuers have resisted EMV in the US is that it does not solve the fraudulent "card not present" problem, those on-line transactions where the rogue has the card number but not the card. Most solutions to this problem involve a display and power, expensive, though not impossible, to put on a card.

Oh, I almost forgot about the PCI DSS, the Band-Aid that the issuers have been relying upon to hold their broken system together. Visa has announced that after October 1, 2012, merchants who have 75% or more of their transactions originating on EMV equipped terminals, will be exempt from compliance with DSS for any year for which that is so. This is a big incentive to those third-party card service providers, who have been one of the problems, for whom DSS compliance is so expensive. Their participation and cooperation in EMV is essential.

Some have suggested that merchants will resist replacing their POS devices. Probably true but "resist" only means that they will take their time. McDonalds did not replace their terminals, only added the EMV reader to the top. Check it out, but unless you know that you are looking for a red semicircle at the top of the device, you might miss it. The expense was not so much in this part as in installing it.

While we think of them as capital equipment, POS devices are actually consumables with a life measured in months to years. One can buy the latest feature-rich model, with built in WiFi or cellular communication, for hundreds of dollars. Most merchants buy their POS device from the card service provider who will be motivated to see them upgrade.

I wish I could tell you that everyone is going to love this technology as much as I do but I cannot. In fact, you can expect to hear all kinds of slurs about its security. After all, anything built by man can be broken by man.

For example, two weeks ago, at Black Hat, an NVP (We do not mention the names of NVPs; it feeds their narcissism.) was quoted as saying, "We think an EMV skimmer poses a serious threat, due to ease of installation, and is very difficult to detect." (Sic) First, a skimmer would be a tool, not a threat. Second, it might be easy to build and conceal, but the issue is getting the card to cough up its secret token. There is no command to ask it to do that. A cryptographer will tell you that one could simply ask it to authenticate a lot of transactions, a few million might do it, and then solve for the secret. A security person will tell you that "that will take a long time." it will take so long that it is not practical, much less efficient.

When you read these "expert remarks," remember two things. First, this is a mature technology, used and tested around the world. It is new only to the US market. Second, however vulnerable it may be, it is orders of magnitude stronger than the broken technology which it replaces.

Getting from our current system to EMV will not be without problems. Experience in Europe suggests that many problems will be related to the transition, in general, and backward compatibility to mag-stripe, in particular. Anticipating and mitigating these problems will not be easy but that is why we are called professionals and are paid the big bucks.

Mission Impossible

2011-08-17T13:18:00.000-07:00

During my last years at IBM, Wjm Van Eck, A Dutch engineering student, published his paper about reading computer screens using TV receiving equipment. The press loved it. There were TV shows on the BBC demonstrating reading screens at a show and reading a document on a word processor screen from the Scotland Yard parking lot.

Van Eck's experiment was based in part on the following:

All electronic equipment leaks
CRTs are very noisy and leak a lot
The screens of the day were character only
The signal that they leaked mimicked that of broadcast TV

On his student budget, Van Eck simply cobbled together antennas, amplifiers, and receivers and displayed the signals on a standard TV screen.

I decided to see if I could replicate Van Eck’s results. I purchased from him a replica of his experimental rig. I gave it to two engineers, one senior and one junior, in the Raleigh lab, next to the plant that manufactured 3270 terminals. They assured me that it would be a piece of cake to reproduce the experiment.

It proved to be somewhat more difficult than they anticipated. On one trip to the lab, they did manage to show me a screen that lit up like their target. At a distance of two meters, it was clear that the image on the destination screen was related to the one on the target, but the content was less than readable. As often happens with engineers, these two lost interest in the effort after they were satisfied that, given enough time and resources, they could replicate the results but long before they had actually done so.

In the more general case, in estimating the cost of attack, engineers often discount the value of their own special knowledge and skills. They think, “Everyone knows (or can do) that.” They also tend to think that if an attack is feasible, it will be used. They tend to discount the difference between feasible and practical, effective and efficient.

These are the kind of esoteric attacks from which the drama in Mission Impossible is crafted. In fact, rather than fiction, one can expect an attack to be used only if it is efficient. The set of cases in the world in which such an attack is both suitable for the intended application and environment and cheaper than all alternatives is vanishingly small.

The leakage of information via electromagnetic signals is a vulnerability without a threat, a non-problem. Not all vulnerabilities are problems, not all problems are the same size.In the generation since van Eck published his paper and the press raised the alarm, such attacks have not ranked with our other security problems, not on our radar. The vulnerability is lower now than then and the cost of attack higher.

Today, while the attack equipment may be more efficient, the cost of such an attack is still higher. Screens are now bit-mapped graphics, not character. They are low-power, quiet, LCD displays, not noisy CRTs. Their emanations do not mimic broadcast TV signals. While they still leak, all electronic equipment does, they are much quieter than those of a generation ago.

One lesson that you should take away is that unless your applications are very sensitive, your adversary a nation state, and the rest of your security so good that this is your weak link, spend your scarce security resources elsewhere. Remember that "Mission Impossible" style attacks are undertaken only against those targets that are very sensitive and that have very good security.

Another lesson is that one should not take security advice from vulnerability pimps or the popular press. Rather, one should rely upon one's colleagues, professionals who are paid the big bucks.

Viruses, iOS, and Apple

2011-07-26T09:57:00.000-07:00

About twenty years ago I used to do a presentation, based upon an early paper, in which I identified four conditions necessary and sufficient for the successful spread of a computer virus.
" A population of similar systems, capable of executing and replicating the virus;
" Sharing of vectors to carry the virus across the population;
" A way for the virus to replicate, i.e., to get itself executed, and
" And storage to hold the copy.
By restricting any one of these things, we could resist the spread of a virus. Of course, these things are all otherwise desirable. There is resistance to restricting them.

In the early nineties I attended a meeting at IBM Research. Fred Cohen, the godfather of all viruses, gave a presentation in which he observed that, in a world of application-only computers, we might still enjoy most, but not all, of the advantages of the modern computer.

I thought about this for a while. This was a way of looking at the third condition, the ability of the virus to get itself executed. The Windows operating system had a dozen ways for a program to be executed automatically. Even if we restricted all of these, the virus might still get itself executed by duping the user into "clicking on it."

We have had application-only computers for a long time. My favorite example is the ATM, the automated teller machine. I also like the arcade machines like Pac-Man.

One thing that distinguishes the application-only machine from the general purpose computer is programmability. The virus exploits the ability of the user to execute an arbitrary program of his own choice or even writing. After listening to Fred, I concluded that even if we could stamp out programming, it is so valuable that some SOB would just re-invent it.

Then, along came Apple with the iPhone and what we now know as iOS. At first Apple said "no user programs." Of course, they did not say that explicitly, They just did not provide any capability for creating one, importing it, or executing it. It did not offer an application programming interface, API, or a software development kit, SDK. Voila, an application-only virus-resistant computer.

Only a few geeks understood. Apple was offering a closed system while the geeks preferred, not to say demanded, open. Most of us did not realize that we were buying a "crippled" computer; we thought that we were buying a "smart" phone.

Gradually Apple has rehabilitated iOS. They have provided an API and SDK, both carefully crafted to maintain security. Applications run in an isolated compartment that Apple calls a "sandbox." Each application looks like an application machine to the user and hides the operating system, file system, and network from the user.

However, all four of the necessary conditions for the success of a virus are still restricted in some way or another. iPhones and iPads can be viewed as application-only computers.

Just as Fred Cohen promised, the tens of millions of users of iOS enjoy most, but not all, of the advantages of the general purpose computer. On the other hand, just as Fred predicted, they are pretty much virus free.

On the other hand, I was right too. The geeks are still trying to liberate, to "jailbreak," iOS, to restore to it all of the generality, flexibility, and capability, that Apple has "arbitrarily" denied to them, along with the inherent vulnerability from which Apple has protected them.

On July 15 Apple released an update to iOS, Version 4.3.4, to close a vulnerability exploited by the jail-breakers, one that could have been exploited by others. German authorities assert that this vulnerability had, in some form or another, existed for four years. Less than 12 hours later, a new jail-break was available. On July 5, 2011 Apple released Version 4.3.5 with a fix for that and 3 other vulnerabilities in other parsers

So far, Apple has patched the PDF parser half a dozen times. Each time the geeks have found another vulnerability. We call this strategy of late vulnerability detection and patching, the Microsoft strategy. It is likely to be about as successful for Apple as it has been for Microsoft.

All that is necessary to use this vulnerability to jail-break is to click on a crafted PDF on a web-page. How can it be that easy? It exploits an implementation-induced vulnerability, an unchecked input in the pdf parser within the Safari browser. While the jail-break PDF is overt, chosen by the user, and only Apple considers it malicious, the same vulnerability could be used to make more covert and malicious changes to an iOS device.

As we have noted here before, checking inputs is difficult. It is particularly difficult for a browser, where most inputs are legal and illegal ones difficult to enumerate. Therefore including a browser, Safari, in the operating system is inherently dangerous. Trying to parse PDFs in the OS is insane.

We have talked here before about how difficult it is to check inputs in modern systems. That is why we recommend the use of the OWASP Enterprise Security API Library for web servers. No such library exists for browsers or PDF parsers. Parsing PDF input appears to be so difficult that even adobe must issue frequent, not to say weekly, patches.

Eventually Apple is going to have to resort to a more fundamental strategy, like removing Safari from the OS. In the meantime, there are six alternative browsers for iOS. Unlike Safari, they all run as applications. Using one of these, running in its sandbox, a user could parse a rogue PDF safely.

Users who like the relatively sanitary environment of their idevices should care about a fundamental fix. Enterprises should care. Android is too open to ever be trusted. RIMM is struggling just to stay in business. On July 24, 2011 they laid off ten percent of their workforce.

The geeks will whine and complain about any fundamental fix. Steve will tell them that if they want an open system to buy a Mac, hell, even buy an Android. iOS is about as open as it is going to get. I am glad that there are more open alternatives to iOS but not nearly so glad as I am that iOS is closed.

So far this vulnerability has been used by geeks to jail-break. While it might have been used in a few narrowly targeted attacks, it has not been exploited by rogue hackers for widespread attacks.. It is a vulnerability without a threat, not a risk, not a problem. So far.

Until Apple does something more effective than patch, professionals that rely upon iOS to protect the applications and data of their principals must be on the alert for any emergent threat. While we are not happy about it, that is why we are called professionals and are paid the big bucks.

Phone Hacking?

2011-07-18T11:52:00.000-07:00

Hey, guys! It's not "phone" hacking. It is "voice-mail" hacking."

How many, besides me, have been hooked this weekend by a headline about "phone hacking" only to say, "Oh, that's what they mean. That's not what I thought they were talking about." I am still doing it. I have done it twice since I got up. Even when I understand that they are simply talking voice-mail, my brain wants to interpret "hacking" as some sophisticated access to the mailbox from the computer side. This does not even involve brute force attacks against the password from the public switched telephone network.

Now you say that I only make this mistake because I am a geek. Perhaps. On the other hand, the average consumer of news may have even less of an idea what the term "phone hacking" means, much less what they ought to do about it. Parsing the words ought to get them closer to an understanding instead of further away.

The popular press does not serve us well when they do this. What language will they use when someone really hacks a phone, like "remote code execution," over the network?

We owe it to the innocent public to identify these attacks in a manner that informs them as to how to address the vulnerability.

"There is no such corrupting lie as a problem poorly named." Using the wrong words to describe something is counter-productive, not to say, destructive. Take, for example, calling cross-site scripting and buffer over-flows "vulnerabilities" rather than "attacks." The real vulnerability is "unchecked inputs." Perhaps one reason that these vulnerabilities are not only persistent, but growing, is that by naming them wrong we obscure the remedy.

Note that the voice-mail boxes are not being hacked via the application programming interface, API, but via the user interface, the UI. Our colleague, Brian Honan, reports from across the pond, that most of these "hacks" are simply using either the default password, or an easily guessed password. Can you say 1111?

We need to describe the vulnerability in a way that helps people protect themselves. I do not use 0416 because that is my birthday. I do not use your birthday either. I do not use any date because a "dictionary" of four digit passwords is going to contain those 365 numbers and will try them right after 1111, 2222,......1234, etc.

I do not do this because I think that a four-digit password is too short; for most people it is probably just fine. However, there are only ten thousand numbers in a four digit-lock-code; on average 5000 (automated) trials should be sufficient to find yours. For most of us, that is probably adequate. It helps if your carrier limits the number of trial.

For celebrities, four digits may not be adequate. As recent events demonstrate, any of us might become a celebrity at any time. Some of us may not want to use standard voice mail and some of us should not. There are viable alternatives.

While I an not a celebrity, I do not use my phone company voice mailbox at all. All of my phone numbers are forwarded to Skype-in. Access to that voice mail box requires a Skype client, my e-mail address, and my 9 character Skype password. Blackberry users can use longer lock-codes chosen from the full character set of the alpha-numeric keyboard. Longer lock-codes do not raise our work factor very much but they raise the cost of attack dramatically.

Four thousand victims of News of the World is a problem, a few of the victims even tragic. There are probably three or four times that many victims of less organized attacks. Good practice can eliminate a large percentage of these. For the rest, there are alternatives. However, the problem is likely to persist until we name and describe the problem in a constructive manner.

FFIEC Authentication Guidance

2011-07-13T14:27:00.000-07:00

The Federal Financial Institution Examination Council, the FFIEC, has finally passed its long-awaited "new" Authentication Guidance. It was hoped that this guidance would address the account take-over attacks that have resulted in both losses to, and disputes between, the banks and their customers. Those security professionals that had hoped that the guidance would address the credential re-play that is at the heart of this problem can only be disappointed. Indeed, almost everyone is disappointed with the exception of the banks and the regulators themselves.

The language is someplace between "wishy-washy" and largely "content free." For example, it says that "institutions should use effective methods to authenticate the identity of customers and that the techniques employed should be commensurate with the risks associated with the products and services offered and the protection of sensitive customer information."

On the other hand, it is silent on the relative effectiveness of measures and makes no recommendation among them.

It dismisses token-based strong-authentication on the basis that it might be vulnerable to man-in-the-middle attacks. While that may be true, we are not seeing any such attacks. On the other hand it is resistant to the re-play attacks that we are seeing.

The Guidance suggests that we need better questions in challenge-response systems. Of course, the problem is not the resistance of the questions to guessing but how many questions there are and how quickly they leak to a key-logger. Again, it is as if the authors do not really understand the attacks.

If there is anything in the Guidance that I agree with, it is the idea of layered security. The idea is that we should not rely exclusively on the authentication, regardless of how good we think that it is. We should have policy, application controls, monitoring, timely confirmations and reconciliation, Patco and Experi-Metals both could have been a lot worse without these controls. That said, these controls mitigate the fundamental problem of credential re-play, they do not compensate for it. Moreover, the document is labeled "Authentication Guidance;" we have a right to expect that it will speak to that.

Part of the problem is that the agencies do not want to preempt the responsibility of bank management. Thus, they emphasize "risk management." They even acknowledge that the risk has changed since they published their original guidance. Banks have the fundamental responsibility to protect the customer.

Part of the problem is that the FFIEC is made up of the five Federal agencies, Office of the Comptroller of the Currency (OCC), the Federal Deposit Insurance Corporation (FDIC), The Federal Reserve Bank (FRB), The National Credit Union Administration (NCUA), and the new, Consumer Financial Protection Bureau. Each has different constituents and interests. The purpose of the council is to promote uniformity in regulation and limit institutional shopping among the regulators. Perhaps it is a little much to expect that five government agencies would ever arrive at strong guidance on anything.

However, the result is to set the bar at the lowest of all the agencies. As one of the authors put it, "The Guidance provided minimum (emphasis mine) supervisory expectations for effective authentication controls applicable to high-risk online transactions involving access to customer information or the movement of funds to other parties."

As I read the Guidance and the commentary on it, I kept coming back to the same question: "What part of 're-play' do they not understand?" Finally I scanned the document. The word does not appear. They do not understand any of it.

When they are criticized for not addressing re-play, their response is, "placing so much emphasis on what's 'missing' from the guidance detracts from regulators' intent." Perhaps. Perhaps they simply do not get it. Perhaps it is not even their job. Perhaps we expect too much of them. Perhaps it is our job.

Our job is not to debate whether or not guidance from the regulators is correct or complete. In fact, we have known since shortly after Sarbanes-Oxley that "security by compliance" encourages minimalist, not to say weak, security. No bank is going to have to change what it is doing to meet this "new" Guidance. Hopefully they will meet the requirement in spite of the Guidance, if not because of it. The Guidance sets a low bar but does not forbid high clearance.

Indeed, our job, without regard to the guidance, is to keep our principals out of the debate and to be sure that bad regulatory guidance is not used to justify weak security.

The good news is that we did not really need the Guidance to tell us what to do and now we can stop waiting for its magic. The bad news is that some management might decide to use it to justify continuing whatever they are already doing. It is our job to see that our principals do the right thing, whatever the Guidance says. It is for that that we are called professionals and are paid the big bucks.

Business as Usual........

2011-07-05T12:55:00.000-07:00

......no longer cuts it.

The cost of attack against targets of choice has fallen close to that of targets of opportunity. Patience helps and may even be necessary but not much work or access is required; the necessary special knowledge is available as a toolkit for tens of dollars. Attackers are in different legal jurisdictions and may even be agents of foreign nation states; they do not, and need not, fear detection or identification, much less prosecution.

The value of a successful attack is too high and rising. Compromised credentials may result in losses of hundreds of thousands of dollars, expensive to the banks, but a threat to the health and continuity of a small business customer. Compromised systems may result in the loss of intellectual property that threatens the health, competitiveness, and continuity of the enterprise. Can you say Google? RSA? Can you say Sony?

Too many web facing applications have unchecked inputs making them vulnerable to SQL injection and buffer overflow attacks. These attacks are resulting in the compromise of personally identifiable information (PII) and payment card information (PCI). They have become so common that many no longer make news.

While we still see bait on web sites and some spam, the most efficient bait is crafted to appeal to identified individuals and is delivered by e-mail. For many enterprises a crafted bait message may be sufficient to compromise their whole network. The bait messages that used to appeal to fear, greed, or lust now appeal to curiosity. One report had it that the bait messages addressed to RSA were labeled "2011 Hiring plan."

Accepting the bait may compromise the user's credentials, as we saw in Patco and Experi-Metals, facilitating re-play attacks. Alternatively, it may compromise a system, providing a tunnel through the perimeter and an agent on the network, as we saw in RSA.

The net of all of this is that "Business as usual" will not cut it. We must raise the state of the practice closer to the state of the art. We must raise the cost of attack and lower the value of success. We must raise the bar across the board.

Since e-mail is proving to be such an efficient attack vector and involved in so many compromises, it is a good place to start.

Awareness training is necessary but not sufficient. With a sufficiently large population of users, it is inevitable that one or more will take the bait. It is not stupidity or even carelessness. Rather it is simply human nature.

Upgrade or outsource your e-mail. Use a restrictive e-mail policy; that is, accept messages only from known sources. Ninety percent of all your traffic comes from such sources and they are limited in number. Quarantine or "red-flag" everything else. Be sure that the "from address" agrees with the origin address.

Encourage users to have personal e-mail addresses that they can access from their own mobile devices or kiosk machines provided for the purpose. Yes, it is a change in culture but not as expensive we pretend that it is.

Since unchecked inputs is obviously part of the problem, address them. Checking inputs is much harder than it looks, beyond the training, knowledge, skills, and abilities of most application programmers. That is why this problem, identified forty years ago, still persists. Therefore, application programmers should all be trained and required to use the OWASP Enterprise Security API.

Most of us still use M&M security, crisp on the outside, soft and mushy on the inside.

Assume that there is no perimeter or that there is an agent on the inside. The NSA behaves accordingly. If one has, or assumes that one has, untrusted machines on one's network, one must place place firewalls between all systems and their networks. These must implement a restrictive policy; only that traffic explicitly permitted must pass.

We must have strong authentication, credentials that cannot be re-played raise the cost of attack and reduce the value of success. More on this next week when we talk about the "new" authentication guidance from the Federal Financilaal Institutions Examination Council.

Servers must talk only in secret codes, VPNs to clients, VLANs to one another. Terminate VPNs on the applications, not on the perimeter, not on operating systems. Applications should talk only in secret codes, only to those who have the key.

Lock down every system that you can. Restrict "write" access to programs. Part of our problem is that the population of systems that can be compromised is ten times the size it needs to be. Most users do not require the discretion to execute arbitrary programs or even to install applications. Most users could get along with thin clients to apps running on servers. If a user takes bait but his system resists compromise, then no permanent harm done may be done.

Configure access control on database servers. We are relying on application servers to protect the database servers; they are not up to the task. Use a restrictive policy; even these will leak but they will raise the cost of attack over permissive one's. Most application data, personally identifiable information, payment card data, and intellectual property must be stored on object-oriented, database servers, not in flat files, not on personal systems.

We must have stronger application controls. It is absurd, for example, for an application to permit 92 transactions in a day, for hundreds of thousands of dollars, using credentials that have never been used for that purpose before, against an account that normally had a zero balance, and against which no more than one or two transactions had ever been made in a day. In addition to checked inputs and database controls, we need controls specific to the application. Application controls raise the cost of attack and reduce the value of success.

Do you really believe that your security is that much better than Sony's, that you could resist the same kind of attack? If compromised in the same way, do you have a plan to return your network to a known and trusted state? Note that this requires rigorous separation of data and programs so that you can restore programs without the loss of data.

Let me not forget monitoring, measurement, and reporting. Turning on logs is necessary but not sufficient. If one waits until after something goes wrong and looks at them only for forensic purposes, it is too late. There is software for integrating logs and for using them pro-actively to identify and resist attacks before, rather than after, they succeed.

Restrictive policies, even for e-mail, least privilege, even for users, strong authentication, stronger applications, encryption by default, and better monitoring, measurement, and reporting all round. It is time to get serious.

Many of these measures are counter-cultural. They will have some influence on the way people do their jobs. They will generate some resistance and even some resentment. We will have to change attitudes. Notice that they do not require new tools so much as changes to how we use our tools.

These are just tactics but a change of this magnitude is strategic. It is ambitious. It will require leadership, commitment, and planning. It will take time, of which we have little enough. If we are to continue to be called professionals and to be paid the big bucks, we must be able to look back two years from now and measure a marked improvement in our security posture. If you are not up to the challenge, perhaps you should update your resume. On second thought, perhaps you should consider a change in career.

RSA SecurID Update

2011-07-01T06:19:00.000-07:00

I continue to believe that the public relations surrounding the recent breach of RSA's systems is the worst since Watergate. In any case, it is far worse than the breach. Every pronouncement on their part to make it better has only raised more fear, uncertainty and doubt.

I would like to try to distill some signal from all this noise.

Let me say from the start that the sky is not falling. Fear is not justified. Strong authentication is not falling apart. SecurID is not broken. While the cost of attack for one adversary, perhaps a nation state, against some targets of choice has fallen marginally, for most SecurID users, their risk is approximately the same today as it would be had their been no breach.

As I noted in my first report on this subject, I am glad that RSA is not my client. They are truly between a rock and a hard place and the water is rising.

So there are all sorts of good reasons why RSA is less than forthcoming about their breach. First, they probably have limited knowledge about what actually happened. They do not want to compromise the investigation. They do not want to leak any information that might be useful to the perpetrator in exploiting the product of the breach. They do not want to do anything that might make a bad situation worse.

However, their lack of candor has done just exactly that.

[Of course the perpetrator of the breach probably knows what he got and how to use it. After all, RSA was a target of choice, not opportunity; if the attacker had not known what he was looking for and what he would do with it if he got it, he would not have bothered.]

The lack of candor of their customer, Lockheed-Martin, only added to the FUD. What evidence did Lockheed have that it was under attack? What evidence that it was related to the RSA breach? What was the method of attack? To what extent was the attack successful? Security professionals would like to know. Instead, after all of this, the only thing that we know with confidence is that RSA was breached by a resourceful and patient adversary. Almost all else is speculation, not to say hype.

Given the little we know, what should we do? Which among us should do it?

If you are not already using strong authentication, start. Can you say "replay attack?" Account takeover? Identity fraud? Zeus? SpyEye? Start with privileged users. Start with users at systems that you do not control. Can you say customers? Trading partners? Home workers?

While I still have a high regard for EMC and RSA security, needless to say, it is diminished. So, if you want to use token-based, you may want to consider a different vendor. I am increasingly a fan of out-of-band. I like the use of mobile devices, devices that people carry anyway, for both token-based and out-of-band. I use my iPhone for token-based with PayPal.

If you are the average SecurID user, do nothing. Your risk has not changed enough to justify the cost of any changes, let alone the cost of distributing new tokens, even free ones.

Any attack exploiting the leak and that does not involve the use of a known token ID, or at least a user ID and PIN, will be noisy. Therefore, risk averse organizations may wish to:

1. Listen. Monitor your ACE server for failed logon attempts.

2. Resist bait attacks and other "social engineering attacks seeking token IDs, user IDs and PINs. (See rule 1.)

3. Resist exhaustive attacks against PINs, for example by increasing the content. However, since the most efficient attacks against PINs will involve "social engineering," see rule 2.

The Canadian Cyber Incident Response Center published "advice," this week, further muddying the water. Their advice included a target list in the context of the RSA breach.

· high-profile international events participants (e.g., Olympics, FIFA)

· legal organizations, namely those involved in international contracts, mergers and acquisitions (e.g., Clifford Chance)

· organizations involved in international affairs, economics and finance (e.g., IMF, World Bank)

· security and defense organizations (e.g., Lockheed-Martin, Northrop-Grumman)

· natural resources and energy sector organizations (e.g., FMC, Exxon-Mobil, AramCo)

· research and development organizations (e.g.,

· information management / information technology organizations (e.g., Intel, Apple, IBM, EMC, Verisign,

· political activist groups (e.g., ACLU, the RNC)

While these are all high value targets, taken collectively, their risk did not change as a result of the RSA Breach. The list is too long and embraces far more enterprises than even a resourceful adversary is capable of getting to. For most on this list, there is safety in numbers. Having drawn the list and thereby suggesting that all on it are peer targets, the CCIRC stopped short of recommending that they all issue new tokens. Government, in an abundance of caution, has cast its net so broadly that no recommendation is possible.

You should issue new tokens if, and only if, you might be a target of choice for those who breached RSA and attacked Lockheed-Martin. You should know who you are. You do not need the CCIRC to tell you. Your risk may have changed enough to justify issuing new tokens. Expect RSA to pay for them. Still in doubt? Call me.

Whoever you decide that you are and whatever you decide to do, write it down. Professionals document their decisions and communicate them to their principals. Be prepared to be second-guessed; it goes with the job.

We need to watch for any evidence that those who breached RSA have been successful in exploiting it. One way this will show up is as evidence of efficient attacks; we should watch for this. Another way that it will show up is in sale of RSA intellectual property to others; these transactions will probably take place on the Internet and we should watch for them.

Discerning intelligence, information that we can act on, from all this noise is difficult. That is why we are called professionals and are paid the big bucks. Fortunately, for most of us, the default, doing nothing, is the right choice. Write it down.

Experi-Metal vs. Comerica Bank

2011-06-21T07:11:00.000-07:00

Last week we talked about the Patco vs. Ocean Bank dispute that arose from a "corporate account takeover." Incidentally, the media calls these ACH fraud but the role that the ACH plays is limited. While it speeds up the fraud, its rules provide for reversibility of transactions by default. The real problem is S.W.I.F.T. where the rules do not provide for reversibility by default. ACH works like checks, S.W.I.F.T. like cash.

We were hardly off the air before reports began to come out about a decision in Experi-Metal vs. Comerica Bank. While some of the facts are similar, in this final judgment, the court found for the customer. As the decision is different, and while last week's lessons still hold, there are new lessons here. We might as well, we might do well to, get them on the record.

In this case, the court has come down firmly on the side of the common law principle that banks are responsible for ensuring that transactions are properly authorized and to bear the cost of fraud.

However, what is important to us is that the trial rips open the kimono. We get to see the forensics. We get to see what we can never see in any other context. We get to see which controls were in place and which not. We get to see which ones worked and which ones failed.

As in Patco, Experi-Metal's banking credentials were compromised. However, in this case their machine was not compromised. Rather an officer responded to a bait message that appeared to come from Comerica, led them to a counterfeit of Comerica's web-site, where they compromised their credentials by using them to log on to the perpetrators system.

At one level this was simple a spoofing attack. It is not quite a man-in-the-middle attack but we have seen these. It was also a replay attack. Replay of the credentials would have been resisted by the token-based or out-of-band authentication that we discussed last week.

Press reports suggest that the criminals immediately began to transfer money, via Comerica's correspondent, JP Morgan Chase, to accounts in Russia and Estonia. After about four hours, Chase had identified the transactions as fraud candidates and notified Comerica. Comerica then disabled the compromised credentials but failed to terminate the continuing on-line session so the transfers continued for another two and a half hours.

Now, contrary to the popular and journalistic view, it is not only permissible but efficient to rely upon the controls of third parties to detect anomalous, not to say, fraudulent, activity. However, if I were the judge in this case, I would surely have asked myself why Chase was the first to recognize this activity as fraudulent.

In the early days of on-line banking, banks did not permit same-day transfers to arbitrary accounts. The destination account had to be setup in one step, confirmed in-band to the destination account, and out-of-band to the origin. Only then, perhaps several days later, could the transfers take place.

I was reminded of this while at Deloitte. A client, a private bank in Bermuda, questioned this control. The question was referred to me. It seems that some of the large depositors of this bank were asking to be able to make same-day transfers to new accounts. The bank wanted to find a way to accommodate them.

I suggested to them that there were alternative or compensating controls that they could employ, rather than the one that was then standard. For example, when a customer wanted to make a same-day transfer, the bank could involve an officer to approve and permit the transaction. The officer could confirm the transaction with the customer, out-of-band, by phone, e-mail, fax or combinations thereof. Because this is an expensive control, I suggested that the bank might want to have thresholds below which the control would not be invoked. However, clearly they should be invoked for the top ten percent of all transactions.

Indeed, if one is to believe the reports of this case, there were at least half a dozen things about this fraudulent activity that might have triggered alarms. The transactions were both numerous and novel, more than 90 transactions against an account that usually had a zero balance and had not had any in more than a year. They were same-day transfers to unconfirmed accounts. They were made using credentials that had never been used for that activity before. They represented a material portion of Experi-Metals deposits, and indeed of their net worth. They generated $5million in overdraft charges. The judge took that last one as evidence that the bank was not acting in good faith.

Part of what Chase picked up on was that, while the transactions into their accounts were Automatic Clearing House, ACH, transactions, funds for which Chase's customer was liable. Chase's customer was then forward wire transferring the funds, via S.W.I.F.T. , to foreign banks, from which recovery would not be automatic, perhaps not easy or even possible. It is not clear whether Comerica would have permitted transfers direct to such banks.

Last weeks lessons are still necessary but not sufficient. What are the new lessons here?

New lessons for the customer include always initiate connections to your bank in the same way, never by clicking on a link in an e-mail message. Always satisfy yourself that you are connected to your bank by recognizing your balance and recent activity. Be sure that the connection is properly encrypted by checking the browser "lock," the url, and, at least now and then, the SSL certificate.

An analyst at the Gartner Group has suggested that while bank controls are better now than in 2009, there is still room for improvement. New lessons in this case for banks should focus on policy, we protect and inform our customers, and back-room controls, the ones the have proved so successful in detecting credit card fraud. Their policy and controls must be based upon the assumption that, even with the best of intentions and training, some of their customer's credentials will be compromised.

We do not know how many successful corporate account takeovers have occurred, nor how most have been settled. What we do know is that more than half a dozen have resulted in suits against the banks. Perhaps that there are only a few such disputes can be taken as evidence that we are doing a better job for others than we have done for Patco, Experi-Metal, Ocean Bank, and Comerica but I would not bet on it.

We should not be as concerned with how the courts rule on these disputes, law and precedent will not make on-line banking safe, as with how well we serve our clients. It is no excuse to say that "we told them but they did not listen;" the failures in every profession say that. It is our job to ensure that our principles, banks or their customers, are not involved in such losses.

If we are to be worthy to be called professionals and get paid the big bucks, it is our job to recommend the appropriate controls and convince our principals to use them. In our professional development, we must work as much on our communication skills as on our technical ones.

Patco vs. Ocean Bank

2011-06-14T11:10:00.000-07:00

The closely watched case of Patco vs. Ocean Bank is working its way through the courts. The most recent public event in the case is the recommendation of a court-appointed magistrate. If, as seems most likely, the court adopts the recommendation, it will be very good news for the banks and bad news for small business.

Patco was the victim of a Trojan Horse attack using software called Zeus. The attack enabled the perpetrators to compromise the Patco's banking credentials and re-play them to transfer Patco's funds to themselves and even to draw funds against Patco's line of credit with Ocean Bank.

The fundamental common law principle is that banks are responsible for ensuring that transactions are properly authorized and that they must stand the cost of fraud. As individuals, we all rely upon this rule. So far, at least for consumer on-line banking, the banks have honored this obligation both for deposit and credit card transactions.

However, over time this principle has been eroded and limited by legislation, regulation, and contract, designed to encourage responsible behavior on the part of bank customers, particularly business customers.

Patco argues it did not authorize the transactions in question and that the bank should reimburse them for the losses. The bank argues that Patco's credentials were used for the transactions and that, therefore, under its agreement with the bank, Patco is liable.

Patco argues that the security mechanism offered to it by Ocean bank was inadequate for the application and environment. It seems clear, both technically and from the events in the case, that the mechanism failed. That is not in dispute. Patco argues that stronger, if more expensive, mechanisms are available, that they would have protected Patco, and that Ocean bank should have used them.

However, the magistrate finds that the mechanism chosen by the bank, i.e., UID and password with challenge-response based on three shared secrets, complies with regulation, is widely used and was agreed to by Patco. The magistrate finds that, as a matter of law, banks are not required to provide the best mechanism.

The regulation in question requires "two-factor" authentication. While this includes token-based or out-of-band authentication, which clearly resist the replay of the customer's credentials, it also includes weaker mechanisms such as challenge-response based on a set of shared secrets.

Note that challenge-response does provide some resistance to re-play, at least until all the shared secrets have been compromised. The findings suggest that the bank increased the likelihood that all three secrets would be compromised by lowering the threshold for invoking them to $1-.

Moreover, a decision that turns on Patco's agreement to the mechanism assumes that it, or any bank customer is in a position to judge whether or not the offering is secure for his purposes. I would assert that that is unlikely, that it is far more likely that the customer relied upon the bank.

There is nothing in the report to suggest whether or not, in choosing its method, the bank contemplated a key-logger attack as was used here. It is far more likely that, as Patco relied upon the bank, the bank relied upon its service provider.

As in most disputes, in this case there is plenty of blame to go around. The bank chose a weak security mechanism. Then, relying upon intuition, rather than knowledge, weakened it further by lowering the threshold. Patco did use a Zeus-contaminated machine. While the bank clearly wants its customers to resist contamination, it should have assumed that across all of its customers, at least some would be compromised.

Bad cases make bad law. I hope that this case will be settled, rather than appealed, so that it does not establish an anti-customer precedent. The common law principle is well-founded and we have an interest is preserving it.

An update to the Federal Financial Institutions Examination Council authentication guidance is expected shortly. Leaks suggest that, while the guidance will encourage improvements, banks will continue to enjoy wide latitude, including the continued use of challenge-response. Rather than looking to the FFIEC for guidance on how to improve their security, most banks seem to be hoping that whatever they are doing now will continue to be permitted.

We should not be surprised that banks want to transfer to the customer as much of the responsibility for secure on-line banking as possible. Neither should we be surprised that they prefer regulations and standards that reserve to them the greatest possible flexibility and choice. The banks should not be surprised that we will use them and their services only to the extent that we believe that we are safe when we do so.

As security professionals, we should be advising our small business clients to 1) resist Trojan Horse attacks by using a dedicated and locked-down machine for banking, 2) resist re-play attacks by preferring banks that offer either token-based or out-of-band authentication, and 3) use on-line banking to their advantage by reconciling their accounts and activity daily.

We should be advising our banking clients that they can improve both their competitive and security postures by employing token-based or out-of-band authentication. In a world in which all adults and many children carry mobile computing devices, the convenience of these mechanisms is improving and the cost is falling.

Neither Patco nor Ocean Bank were well served by the security profession. We must do much better if we want to be called security professionals and get paid the big bucks.

Get Out of Jail Free

2011-05-22T14:30:00.000-07:00

Would you like a "get out of jail free card" for security professionals? It is called the risk acceptance document.

The responsibility for the protection of enterprise assets lies with line management, not with the security staff. This is essential. The discretion to allocate and use a resource comes with the responsibility to protect it. The result is that line managers have the responsibility, not to mention the budget, but the security staff may have the knowledge.

When inevitably they disagree, the line manager usually does, and ought to, win. When inevitably things go wrong, the security professional takes the blame. The risk acceptance process establishes a more appropriate balance of power.

Additionally, security managers often complain that they are unable to get management to focus on what they consider to be critical issues. Sometimes, not to say, often, it is because the security staff has not yet articulated the options in a way that management can appreciate.

The risk acceptance process is a method to get the necessary focus. In it we simply ask management to "accept the risk," to sign a document that says that the staff has presented them with the risk and that they have elected to accept it rather than to mitigate it.

The security staff gets to write, or at least negotiate, the content and language of a

risk acceptance document. They describe the exposure, i.e., the threat, the vulnerability, and the consequences. They describe all the alternatives that were considered, including the one that they recommend, and that of doing nothing, i.e., accepting the risk. Management either mitigates or accepts. The line manager or executive gets to make the decision but also has to accept the responsibility. The process and the document ensure that the decision is memorialized.

Doing nothing, that is, accepting the risk, is only one of the alternatives. In many cases, after reading the risk acceptance document, the business executive will elect to accept the recommendation of the security staff instead of signing the document.

One effect of doing the necessary work to write the document is to ensure that the security staff has really considered all of the significant alternatives. Another is to focus the attention of the executive on the decision that only he can make.

When is a risk acceptance indicated? One answer is any time the security staff wants line management to make a decision. However, risk acceptances may arise in the context of a change in threat, a new technology, or a new application. For example, the enterprise wants to bring a new application on line in order to exploit a new technology or business opportunity. The developer and the security staff disagree on the quantity or quality of testing.

Another context in which risk acceptance may arise is that of a decision to deviate from regulations, policy, standards, or guidelines. To some extent regulations and policy, but particularly standards and guidelines are made to be broken. However, whenever for business reasons, a decision is made not to conform, the decision should be memorialized in a risk acceptance.

Finally, risk acceptance should be used to document residual risk. Since security is never perfect, there will be breaches and losses. For example, there is the risk that a user will take bait and contaminate the network, that a privileged user will go rogue or be suborned, or that the maximum number of simultaneous component failures will be exceeded. All of these should be documented If only to protect the management of fhe application and the security staff from charges of imprudence, residual risk must be documented.

Risk acceptances should be done before, rather than after, the auditors come. Auditors tend to treat any and all variances as of equal severity. Moreover, audits are as of a point in time. Once the auditors show up, it is too late to get out of jail free.

Recently, after mentioning risk acceptance as an essential security practice, I was challenged by a professional to give examples of language for describing the risk. After agreeing to try to provide examples in this week's talk, I realized that the language is the language of risk analysis or business impact analysis, language that we should all already be skilled in using.

The expression of the risk to be accepted is that of the relative risk between the recommendation and that of doing nothing, for example, between implementing early with one level of testing and cost and implementing late with more testing and other cost.

Of course, part of the cost in both cases, is the cost of losses. As always, these costs are difficult to predict with any precision. However, executives are accustomed to making decisions with imprecise data. Doing so is a necessary skill of all executives. When doing so, it helps to know how good or bad the data is.

What the executive asks of us is to carefully document our assumptions. Of course they want an annualized loss expectancy (ALE), but they also want to see the underlying assumptions about threat rate, vulnerability, and consequences. They understand that these numbers are difficult to arrive at but they can work with them as long as they understand how you got to them.

A risk acceptance has a limited life. It dies either with the expiration of one year, the tenure of the signing executive, or some agreed to but shorter period of time. At the end of a year, the decision must be revisited. If the signing executive moves on, all of the risks that he accepted must be submitted to his successor. The new executive may follow the lead of his predecessor or may not. Often, the risk may be accepted only for the period of time required to implement an alternative.

It is not always clear which executive should sign the risk acceptance. To some extent this is a matter of enterprise policy or culture. For example, some mature enterprises have strict limits of financial discretion assigned to levels of management. In others, the discretion of a manager may be established by his budget. In some, a manager may sign anything that she is willing to take the responsibility for. I recommend that a risk can only be accepted by an executive that has the authority, discretion, and resources to implement the alternative, that is to say yes, as well as no, to your recommendation.

Said another way, a manager may not accept a risk simply because he has no other choice. By definition, he who has no other option is not the right manager..

Note that this is just the way that staff works. No one has to authorize staff to present alternatives to management; that is what they are paid to do. They do not need any special authority to ask an executive to acknowledge that they have done so. Every now and then, an executive may simply refuse to sign the document. It really does not make any difference. One simply notes when and what options were presented to whom and puts the record in the file. If he does not mitigate, by definition, he has accepted.

This brings up the idea of "completed staff work." This is the idea that says decisions are presented to executives in a document that is so complete as to be self-implementing. The alternatives are so well described that when the executive signs it, without any further staff work, everyone knows what they are expected to do.

Writing risk acceptances is difficult. If often involves negotiation to arrive at language that all can agree fairly describes the choices and their associated risk. It may involve compromises to decide who should sign. That is why we are called professionals and are paid the big bucks.

On Trusting Systems

2011-05-10T14:15:00.000-07:00

The idea of trusted systems is almost as old as shared resource computing. In fact, it arose in that context. It was all about being sure that data did not leak from one user to another or one class to another. Contamination of one user or process by another did not occur to anyone until we realized that preventing it was essential to preventing leakage. The story we told was how Roger Schell installed a Trojan Horse in Multics.

Today one issue is preventing leakage from one system to another. Our systems leak, at least in part, because they become contaminated. Contamination requires that the system do something, execute something, a program or a command. Sometimes they do this automatically as with a worm or virus. Sometimes because a user tells them to.

Another is preventing the exploitation of lost or stolen mobile devices. Of course, one way to do that is not to put sensitive data on mobile devices in the first place. On the other hand, there are applications where it might be nice to be able to put sensitive data on a mobile device if one had confidence that if it were lost or stolen the data would be safe.

What does it mean to say that a system is trusted? For a few decades I have cautioned people not to trust systems that they cannot carry and to prefer those they can put in their pockets. That recommendation relied upon the fact that such devices were shallow and simple. Ken Thompson, who received the Turing Award for writing Unix, asserted that unless one wrote it oneself, one cannot trust any computer system. Courtney argued that the question was only meaningful in the context of a specific application and environment. Peter Capek and I argued in a paper for the Irish Computer Society that, Thompson notwithstanding, we do in fact trust our systems.

I would argue that one useful test of trust is that of predictability. If for every input to the system, one can predict the output, for both the case when the system is performing correctly and the case where it is failing, that is a very useful test of trust. Of course, the more general, flexible, and functional the system, the more difficult the task of predicting. The issue is not so much a problem of getting the correct results as expressing and reconciling the prediction.

My favorite example of a trusted computer is Pac-Man. The owner of the system can trust Pac-Man. The user can also trust Pac-Man. It is single-user. It is single-application. The program is simple and obvious as to its intent. The behavior, use, and content of the machine is predictable. It is not user programmable. It is closed. The file system is hidden from the user. The operating system is hidden from the user. The user cannot insert arbitrary data or cause it to be executed. It is not connected to any network. It does not have any exposed input/output such as a disk drive or a thumb drive. It does not even have a key-board. As a result, it is stable. It does not get into unusual states. It does not have to be constantly maintained or "patched."

In computer science terms, the arcade game is an "object," an artifact that encapsulates and hides both its data and its methods.

Compare Pac-Man to your typical personal computer. Not the owner of the system, not the user, not anyone can predict what it will do, much less that it will not do forbidden things. The question is how much can we relax the properties of the arcade game before we loose trust? How much must we restrict the personal computer before we obtain necessary trust?

I trust my iPad and my iPhone. I trust iOS devices in ways that I do not begin to trust Windows systems or even OS X. First, it is an application-only machine. It is true that it can perform multiple applications but the abstraction, the "app," is of a single application at a time. Apple assures me that data cannot leak from one app to another and that an app cannot contaminate or interfere with another app.

Said another way, an app looks to me like the arcade machine. It is single user. It is simple and obvious as to its intent. The behavior, use, and content of the app is predictable. It is not user programmable. It is closed. The user cannot insert any arbitrary data, much less cause it to be executed. While the app can see its portion of the file system, it can see only its portion. The file system and the operating system are both hidden from the user. They are hidden beneath an owner chosen collection of apps, chosen from among a growing population of more than 300,000. Moreover, all of these apps and changes to them come to me from one place, a known source, Apple, in temper-evident packaging.

Unlike Pac-Man, the app can be connected to the Internet, at least as a client, but not as a server. However, the app can only access the network via an Apple provided application program interface or API. Unlike Windows or OS X, the iOS network policy is restrictive rather than permissive; one does not need an add-on firewall.

One might suggest that my trust of iOS and my iPhone or iPad relies heavily upon a trust of Apple, a level of trust that few of us have of Microsoft, IBM, or any other vendor. To some extent that is true. However, whatever trust I may place in Apple, is corroborated by four years of experience in which not one among tens of millions of users has reported a malicious program, leakage of data from one app to another, or contamination or interference of one app by another. Perhaps not quite as good as Pac-Man but sufficient for most of my purposes.

Like Pac-Man, and unlike other tablets, my iPhone and iPad do not have slots for SD storage cards or USB Ports, in part to resist data leakage or device contamination. While there is an SD card reader that can be attached to the proprietary Apple connector, its use is limited to importing photos.

Many of my peers, colleagues and contemporaries, clearly prefer more open devices. They want swappable storage. They do not want to be restricted to a single source of programs. They want to be able to write and execute their own programs. Openness has a value and some will choose it in preference to trust. To that class of users, Steve says "Get a Mac; get an Android. However, I will stick my neck out and predict that most new users will prefer trust.

Unlike Pac-Man, the iPhone or iPad can be lost or stolen. While no one wants to loose a $500 device, property loss is a measurable and acceptable risk, one that money will fix. Data loss is a different matter. Therefore, these devices have a passcode that must be provided by the user to access it. To resist brute force attacks, the passcode must be provided in ten tries, otherwise the data will be erased.

Increasingly iOS machines will be chosen by the enterprise. Apple provides features to transfer the trust from the user to their management. These include the ability to control what applications can be used and to restrict the way some, e.g., browsers, are used, by means of Encrypted Configuration Profiles. The enterprise owner may have requirements that the owner user may not. Therefore, Apple provides features like hardware encryption, remote and local wipe, encrypted backup, two-way SSL, crypto APIs, and VPNs.

I have three Windows systems. One is configured as a typical personal computer. It is configured to be used only by me, usually as an unprivileged user so as to resist unintended changes. I use it for many sensitive applications. Therefore, in order to protect myself from leakage of sensitive data, I must hide it from the Internet using a hardware firewall, resist leakage using a software firewall, and resist contamination using antivirus and anti-spam software and services.

One of the other two is configured as a file server. It is not connected to the Internet. It has no applications. The last is configured as an Internet client. It has browsers but no other applications. It has some sensitive meta-data used by the browsers but no other data. An unprivileged user cannot change any programs or store arbitrary data. Needless to say, I trust the latter two systems more than the former.

It is not by accident that Windows and Unix are our most popular operating systems. Popularity leads to low unit cost. They are open to an arbitrary number of users, device types, and applications, including legacies. This means that they have a mammoth attack surface. In order to have trust in them we must configure them in such a way as to limit that surface.

These system share the von Neumann architecture. This means that by default processes include the capability to alter their own methods, procedures, and programs. Moreover, outputs are a function not only of inputs but also of the state of the system. This makes demonstrating the system difficult. We do have other von Neumann architecture systems that are more trustable, including versions of Unix, and alternative architectures like AS/400.

We can have the trust in our systems and devices necessary to the application and the environment. We can tune trust. However, it is not free. It is achieved at the expense of openness, generality, flexibility, freedom, function, application, and programmability.

Programmability is the ultimate in flexibility. A few years ago I attended a presentation by Fred Cohen in which he pointed out that in a world of "application-only" computers, we would enjoy most, but not all, of the benefits of the general purpose computer. After thinking about it for a while, I decided that even if we could complete get rid of it, programmability is so valuable that some SOB would just invent it all over again. On the other hand, as computers get smaller and cheaper, we will decide that we do not have to have it everywhere.

Of course, trust is never absolute. I teach at the Naval Postgraduate School. It would be fair to describe NPS as a "trusted system program." However, the course that I teach is specifically about managing a population of untrusted systems. This is the job that most of us really have. We are the ones responsible for recommending the level of trust required by our applications and threat environment and identifying the strategy and architecture to achieve it. That is why we are called professionals and are paid the big bucks.

FBI Take-down of Coreflood Bot-net

2011-04-26T07:11:00.000-07:00

The week before last the FBI announced that they had taken down the Coreflood bot-net of perhaps 2 million systems by taking over the command-and-control system.

This was a major event. It demonstrated that we do not simply have to tolerate the existence of hostile networks of compromised systems. It also demonstrated that law enforcement can be effective in the Internet.

Executive Assistant Director of the FBI’s Criminal, Cyber, Response and Services Branch, Shawn Henry. said, “These actions to mitigate the threat posed by the Coreflood botnet are the first of their kind in the United States and reflect our commitment to being creative and proactive in making the Internet more secure.”Communications.

Although most people were happy to see the Coreflood bot-net go, some have expressed concern about the tactics used in its recent take-down. They are concerned that these may be seen to legitimize behavior that, after decades of debate, have finally been seen to be illegitimate.

Federal prosecutors obtained a temporary restraining order allowing them to replace several identified Coreflood command-and-control (C&C) servers with their own servers, which were then used to send shutdown commands to the Coreflood malware.

One colleague responded by saying "Remote administration without permission is 'hacking.'" I will grant him his semantics without granting him his point.

The first time I said that, and I may well have been the first to do so, I said it in response to the clever child who had created an "anti-virus virus." Of course, the same things are wrong with the idea of an anti-virus virus as with any other virus. First, like any virus, the anti-virus would not have the permission or knowledge of the target system owner.

The real problem is that, independent of the intent or motive of the author, he cannot know enough about the network to predict how his virus will behave. It is difficult enough for him to predict the behavior of his program in a single system that he controls. It is almost impossible to predict its behavior in a population of hundreds of thousands of systems connected in an arbitrary network.

The Electronic Frontier Foundation technology director, Chris Palmer, said the method "is not a safe way to go about [disabling malware] and it's divergent with standard practice."

The "standard practice" that he defends is to simply take down the command-and-control servers, while leaving the bots active. This non-standard practice may not meet Mr.Palmer's test for "safe" but it meets mine for "effective."

We rightly fear the awesome power of government. The preservation of Liberty requires constant vigilance against the abuse of that power. Our colleagues who have questioned this action are right to do so. However, the existence of the question does not imply, nor should we infer, the obvious answer.

Note that in this case, the FBI did not initiate communication with arbitrary systems. It waited until the compromised systems came to it. It did not send a program. It simply sent a command in response to a request. It sent the most conservative command, that is, "shut-down," do nothing.

It is this act which offends my friends, the purists. They are offended, in part, because the executive branch has not been explicitly authorized by the legislature to so act. However, one suspects that if the executive had asked the legislature for this authority, the same, or other, "purists" would have opposed it.

Public Safety, like information security, often involves difficult ethical choices, the lesser of evils. Sometimes it even involves the use of coercion or force. Note that government is the only institution in our society that is empowered to use force.

In this instance the executive did not act unilaterally; the FBI did get a court order. These are not vigilantes. Moreover, if they can be entrusted to use force, they can be entrusted to act in the Internet in ways that are forbidden to the ordinary citizen. That the police do something does not give the citizen license to do the same thing.

I invite my anxious colleagues to rest easy. The Internet is safer and the FBI has not gone rogue.

A final word of caution. One should not infer that all bot-nets can be brought down by the same method. Those networks that use the same collaborative protocols that are used by the file sharing programs (e.g., bitTorrrent) and do not rely on out-of-band command and control will not yield to this method.

Those charged with protecting public safety and those protecting the information infrastructure will continue to be confronted with difficult ethical choices. That is why we are both called professionals and are paid the big bucks.

One More Lost Laptop

2011-04-19T12:14:00.000-07:00

Recently an employee of British Petroleum reported "one more lost laptop." In this case the laptop contained records on 13000 victims of BP's oil spill. One does not have to be an application genius to figure out how complete and sensitive those records are or how much work they encapsulated.

Let's consider the possibility that that copy of those records was the only copy. Without even considering any damage that might arise from the disclosure, the loss of those records could be catastrophic to the subjects.

A current search of the web shows that a typical business laptop comes with 250GB of secondary storage (or 128GB of solid state storage for $150- premium). We used to run whole enterprises on that much storage.

Moreover, for $100, one can buy 4 times that much storage to carry in one's shirt pocket; that's right, one terra-byte, $100-. The cost of storage is halving every twelve months. Parkinson's Law of Storage says that data expands to fill the storage available to hold it.

The processor power of these devices is 1000 times what it was a decade ago and increasing exponentially. While "experts" have been predicting the knee in the Moore's law curve for a generation, we continue to push it out.

I now have three old laptops stacked one on top of another that I use for application and storage servers. I have three TBs of storage in my living room network. Daily I operate this network from mobile devices, one, called an iPhone, that I carry in my pocket.

Even in the office there is now a preference for laptops over desktops. Outside there is movement to more, and more mobile, devices, laptops to notebooks to netbooks to tablets to "smart-phones." Note that the only reason we continue to refer to these mobile computers as "smart-phones" is because we buy them from the phone company.

This is only likely to get better or worse, depending on your point of view. The cost per cpu cycle and per bit of storage is likely to fall by a factor of four in 3 to five years. As the price falls the number of devices sold increases and the absolute number of applications grows and the number of applications per device increases. Even the cost of software is falling as the number of copies that can be sold increases.

Five years ago we could not have imagined the applications that we use today. No more so can we anticipate the applications of five years, our planning horizon from now.

Come on guys. The risk is not about laptops. It is about CD Roms. It is about thumb-drives. It is about GBs, and then TBs on one's fingernail. It is about users who have never used a computer they could not carry. It is about powerful computers in one's pocket. It is about what one can buy for a $100-. it is about new use, uses, and users on a barely imaginable scale. All of this involves, not to say invites, risk on an a scarcely imaginable scale.

Consider the bad things that can happen to mobile systems, applications, and data that is less likely to happen to others. First, while robust, these devices can be dropped, broken, or can suffer mechanical or electronic failure. They can be lost or left. They can be stolen, usually for the property value but sometimes for the contents.

Recently we learned that ICE, Immigration and Customs Enforcement, is examining and impounding mobile devices at the borders. Ostensibly this is to look for "contraband" data, specifically child pornography. The courts have consistently held that this kind of search is "reasonable" enforcement of the borders and does not violate the Fourth Amendment prohibition against "unreasonable searches and seizures." In the twenty months of the program, ICE has "examined" more than 6000 systems.

For most of us, and while it is a growing one for frequent business travelers, this risk is dwarfed by the other risks of mobile devices. Like those, it is one to which the same applications and data are not vulnerable when done on stationary systems. It is addressed by some, but not all, of the same security measures.

For example, while loss and leakage are addressed by encryption, ICE will simply demand the key. More over, encryption offers no protection against the far more likely threat of failure or breakage.

On the other hand, not taking data or applications addresses everything except property loss. I now carry a sterile MacBook Air when I travel. No enterprise, client, personally identifiable information, intellectual property, payment system, or other sensitive data.

* Consider the following policies and practices:
* Store sensitive data only on enterprise servers.
* Prefer remote access to enterprise servers to personal, local, or portable copies.
* Save new work on mobile devices to stationary servers
* Permit portable copies only with specific management approval.
* Any portable copies on devices with full-device encryption.
* Any portable copies in encrypted file systems or databases.
* Prefer mobile devices (e.g., Blackberrys, iPads, iPhones) with remote location and remote erasure capabilities.
* Prefer client-server object-oriented databases (e.g., Lotus Notes) with end-to-end encryption by default.

Keep in mind that these are risk mitigation, not risk elimination, policies. Leakage from mobile devices is a fact of life. We cannot solve the general problem but we can address it for ourselves and our enterprises. Note that they do not mitigate the risk of loss or breakage of property.

Of course, even justifying, much less implementing, these policies and practices will not be easy. That is why we are called professionals and are paid the big bucks.

Near Field Communication (NFC)

2011-04-06T12:10:00.000-07:00

There is a new communication standard on the horizon. It is called Near Field Communication, NFC, ISO-18000-3, and you might want to spend a few minutes with the Wikipedia article on it. It has all sorts of wonderful applications. It has a number of security applications and, of course, security limitations and implications.

NFC is intended for use on mobile computers, such as "smart-phones" or PDAs, that the user will be likely to carry, like keys or a wallet, most of the time. More than a dozen implementations, mostly smart-phones, have been shipped or announced by manufacturers including Benq, Google, LG, Motorola, Nokia, Samsung, and others. Applications await sufficient numbers but payment application trials are planned for San Francisco and New York.

Proposed applications include mobile payment, smart card emulation, including EMV, transportation and theatre ticketing, electronic keys, identity documents, cryptographic key management, and dozens of others. Of course, while not requiring NFC, these same devices can be used to implement both token-based and out-of-band strong authentication.

One application of NFC is as a reader of passive RFID tags and passive emulation of RFID tags. For example, eCLOWN is a program for a Nokia NFC phone to read the RFID information on an e-passport.* As you are probably aware there is significant opposition to any use of RFID from those who fear that the value likely from such applications will not justify the leakage or other unintended consequences. This opposition is likely to include NFC. (That the ability to read this information might marginally reduce the cost of forging an e-passport is sufficient reason for some to resist the use of the technology altogether. This, in spite of the fact that an e-passport is much more difficult to forge than an ordinary one.)

The name derives from the inductive effect of the "near field," i.e., within two wave-lengths distance, of the antenna. The reliance of the technology on this effect limits its effective range to about 4cm but the "far field" effect of the antenna might leak information beyond the effective range, perhaps at a distance of a few meters. Because, unlike Bluetooth, NFC does not provide encryption, for some applications encryption such as SSL or Mime, might have to be implemented at a higher layer

NFC is low-power, 15ma, as well as near-fieled inductive, and consequently relatively low speed, 421 kbps. This is fast enough for security and financial applications but much too slow for streaming video or even surfing the web. However, it has one great advantage over competing technologies, i.e., connection setup time. While Bluetooth may take seconds to establish a peer-to-peer connection (after "pairing"), NFC takes less than a tenth of a second. (One proposed application of NFC is for pairing of Bluetooth.)

As with any technology that is vulnerable to eavesdropping and replay, NFC is weak, that is, "one-factor," authentication. Most of the security applications will require strong authentication, at least two factors and resistance to replay. To the extent that NFC is implemented on hand-held computers, a wide variety of authentication schemes will be open to application designers.

NFC signals via amplitude modulation; its ability to resist a the modification of a bit is a function of the strength of the modulation and the coding used. However, some NFC applications may have to provide encryption to resist data modification attacks.

Because NFC is low power, electronic jamming will be relatively easy. Of course, the same is true of Bluetooth. The experience with Bluetooth suggests that this is a vulnerability without a problem. However, NFC may not be suitable for applications where ultra-high availability is a requirement.

NFC devices are vulnerable to loss, along with any credentials, privileges, and capabilities associated with them. Applications should resist the use of lost devices by implementing lock-words for use of the device, remote disabling and erasure, and other security mechanisms. Abandoned NFC connections might be vulnerable to exploitation until and unless they time out. Therefore, devices and applications should be designed to time out in the minimum time adequate for the application.

Those of you that are followers of IGTV or of my blog know that I am a long time critic of the use of mag-stripe and PIN for our point-of-sale payment system. Outiside the US, EMV cards are being used to improve the system. However, progress is limited by implementations that are backward compatible with mag-stripe and PIN. Perhaps this is to be able to process the cards carried by American travelers.

Although there are trial EMV cards and merchants prepared to accept them in the US, there are no plans to deploy them widely, much less pervasively, or exclusively. This is in part because of the cost of cards and readers, and in part because they do not solve the "card-not-present" problem. It is in part because transiting the intervening payment card service providers is difficult.

Not only can NFC devices both emulate and read EMV cards, these smart devices can address the card-not-present problem for mail-order, phone order, and Internet commerce. Moreover, hand-held devices can emulate multiple cards and accounts, functioning as e-wallets and reducing the number of credentials and tokens that a consumer must carry.

Like many such technologies, Near Field Communication is inherently neither secure nor insecure. It is proposed in good faith and with high hopes for legitimate applications. However, I have now lived long enough to expect poor implementations, inappropriate uses, and unintended consequences for any novel technology. I am not without sympathy for those who fear technology in general and RFID in particular. I will be surprised if NFC is not chosen for some applications for which it will not be secure and for others where, as with mag-stripe and PIN, it will survive long after use has stressed it to the breaking point.

The "securability" and reliability of NFC applications will depend in large part on the devices on which they are implemented, that is, in the ability of those devices and their operating system software to resist application-to-application data leakage and interference. These mobile devices are already being used for financial transactions over the Internet and using graphical readers for bar codes or QR codes. However, it is clear that these systems will vary greatly in their ability to protect their applications and will rely to some degree upon their users and vendors to keep them sanitary and current. We must be prepared for the NFC technology to be blamed for any compromise with which it is even remotely associated.

Still, I am hopeful that NFC will find many security applications and "securible" implementations. I particularly hope that it will find application in the payment system, and, for example, by emulating EMV, encourage its adoption. We must design and chose carefully and apply and use conservatively. We should err on the safe side. We have to prepare diligently and advance cautiously. It will be difficult and risky and it will challenge our knowledge, skills, and abilities. That is why we are called professionals and are paid the big bucks.

* Step 2 of the instructions for using eCLOWN is "Insert the passport (crypto) key." It is silent on where to obtain this key. However, because there are many copies of the key, that will be, at best, difficult.

Lessons from the RSA Breach

2011-03-29T06:48:00.000-07:00

As has already been reported on IGTV, RSA, the security division of EMC and the vendor of the SecurID two-factor authentication system and identity management services, has suffered a network breach. The limited disclosures suggest that this was a patient and resourceful attack intended to gain access to intellectual property. More specifically, RSA does not deny that at least one target was information about the SecurID system.

Whether or not this is a security problem, it has certainly been a public relations disaster. It is so bad that one government agency, that is a SecurID customer, has announced that they will switch to another product. Whether or not RSA has done the right thing in this case, it is clear that no one is happy with the way that they have handled it.

This is a case study in how difficult it is to handle a breach. The otherwise disinterested curious want full disclosure. On the other hand, the victim would like as little disclosure as possible. Customers want to know but do not want anyone else to know.

I am reminded of Franklin National Bank. A rogue trader lost about $50M dollars of the bank's money, painful but still only a fraction of the bank's capital. The bank managed to keep the loss "secret" for about ninety days. At that point, the Wall Street Journal reported it. In the next ninety days, the bank lost $2B in deposits and it failed. It could have survived the loss but was killed by the publicity.

As this case illustrates, the first concern that a victim has is to ensure that the publicity is not worse than the breach. What could be worse for a security company than to have to admit to ineffective security or a breach that reduces the effectiveness of products that they have already sold.

However, in fairness to RSA, they have other concerns. As a security company, they have an obligation to their customers to tell them about anything that diminishes the security that they think that they have purchased. They also have a responsibility to not make the situation worse by unnecessary disclosure.

They have a responsibility to cooperate with law enforcement. They want to protect the investigative process and the utility of the product of the investigation.

Now add to this that they really are not sure of the extent of the damage. The longer they delay disclosure, the more they know, the more certain they are of what they know. However, for more sophisticated and patient attacks, one may never be confident about the extent of its success or what information has been compromised.

Note that, as a target they owe a certain duty to peer target enterprises to share information that might be useful in protecting themselves. As a security company, they owe a certain duty to the security community at large to share information necessary to judge the effectiveness, or damage thereto, of the products and services that they offer.

As a vendor, they owe a duty to their customers. However, this duty may be different to those who purchase the SecurID tokens and servers and those to whom they also provide identity management and authentication services.

As security professionals, we can sympathize with this over-constrained problem. Few among us would like to be confronted with such a dilemma. None of this is to say that RSA has done the right thing or that this is not a PR disaster of epic proportions but only that we may never know enough to fairly judge what they have done. Microsoft has never divulged the details of the compromise of their development system.

If you are merely among the curious, a peer company, security professional, or prospective customer of RSA, you may never know what really happened.

You should know that:

Six pieces of special knowledge are necessary to successfully authenticate to the RSA system:

* the (address of the) system that will accept the credential
* the user ID
* the PIN or passphrase
* the seed value
* the algorithm
* the association or bind among the first four

RSA does not know all of these things. Therefore, while a compromise of its systems might reduce the cost of attack, it cannot make it free or even trivial.

The algorithm has been reverse engineered and software that implements it is available for download.

The token is both a forgery-resistant artifact and a mechanism for resisting re-play. Knowledge of the seed lowers the cost of forgery but does not lower the cost of replay.

Since its compromise, RSA has encouraged all of its customers to monitor their authentication servers for evidence of attack against PINs and to encourage their users to employ strong PINs. This is good practice in any case but might be more important if there was reason to believe that any seeds have been compromised.

Under NDA, RSA has told some customers more. If you are a customer and if you are willing to agree not to share what they tell you, RSA may tell you more about the compromise. Note that, since you cannot discuss with others, you cannot verify everything, perhaps anything, that they tell you.

Finally, If one is using strong authentication and one is compromised, the most likely cause is that someone took bait and compromised the network.

The bad news is that RSA may never know exactly what happened; the rest of us will definitely never know.

The good news is that we know enough.

Most of us need only get over the fact that we will never know.

Most users of the tokens need not do anything.

Those of you whose principals are peer targets of RSA must talk to RSA and request a remedy. On the low side the remedy may be nothing. On the high side it may be replacement and re-enrollment of any compromised tokens. Under normal circumstances, one might have weeks to months to get this done. However, since we do not know when the breach took place, days to weeks is a safer time-frame.

A colleague of mine, one who knows this space and this company better than most, wonders that there should be any doubt, that token seeds would ever be connected to the enterprise network. Can you say hardened system?

I am uncomfortable with the expression "Advanced Persistent Threat' but the clear implication of it is that, at least for some identifiable set of enterprises, the threat environment has changed by an order of magnitude.

The heavy, not to say exclusive, reliance on perimeter security that we have used for a generation is no longer adequate. Real defense in depth must be the new order of the day. Defense in depth implies identification of the "crown jewels." It implies that the compromise of one, two, or even three or four defenses should not compromise them. It implies that no single insider can compromise them on purpose, much less by accident or error.

Since, based upon the Verizon data breach report, the time to detection of a compromise is measured in weeks-to-months, this data must be protected based on the assumption that there are compromised systems on the enterprise network. Some data must be behind an air-gap.

Systems and users that access external objects, for example, e-mail messages or web pages, may have to use application-only or locked-down systems to reduce compromise by taking bait. VPNs must terminate on the application, not on the perimeter, not on an operating system. These may be just some of the hard choices we will have to make.

Our choice is to adapt our security strategy to deal with the higher threat level or our public relations strategy to deal with the kind of breach that RSA is dealing with now. It is a difficult dilemma but that is why we are called professionals and are paid the big bucks.

The Internet as Infrastructure

2011-03-22T14:10:00.000-07:00

Today, when one connects an application, system, or network to the public networks, one is adding to the "system of public works," that is to "infrastructure," of the nation and the world.

The standards for building infrastructure, such as bridges, tunnels, and dams, are different from those for other artifacts. Infrastructure must not fall of its own weight, it should not fail in normal use or under normal load, and must resist "easily anticipated abuse and misuse." A suspension bridge must not fall because a driver falls asleep and an eighteen wheeler goes over the side.

Notice that the abuse and misuse that can be easily anticipated today, is much worse than when we began the Internet. Were it not so, we might have done many things differently.

We call the resultant necessary property of infrastructure resiliency, rather than security, but the properties are related.

For any artifact, there are limits to the complexity, scale, load, and simultaneous component failures that the mechanism can be expected to survive. How many simultaneous sleepy drivers and plunging eighteen wheelers must a bridge be designed to survive.

When those limits are reached, what we want to happen is that the mechanism fail in such a way that damage is limited and the mechanism can be restored to operation as quickly as possible.

The three Great Northeastern Blackouts, of which August 14, 2003 was the latest, are examples. It is interesting that engineers see these blackouts as successes while the public and their surrogates, journalists and politicians, see them as failures.

All three were caused by multiple simultaneous and cascading component failures under conditions of heavy load. In all three cases the system failed in such a way that it was restored to a ninety percent service level in a day. While all three were spectacular and exciting, the damage was not nearly so severe as one might expect from a major ice storm.

This is the way that we would like the public networks to fail. In fact, so far, that is what we have seen. We have had massive local failures of the PSTN where it took days to weeks to restore to a ninety percent service level. Most of these were fire related and local. We have had one that was national and caused by a software change. We recovered from this one in hours.

To date, we have had a number of local failures of the Internet, all man-made (mostly caused by the infamous "cable-seeking backhoes or boat anchors"); most were accidental. We recovered from all of these in days. SQL/Slammer was man-made, malicious, and software related; it caused a noticeable drop in service for hours. However, there was not really a discontinuity of service.

It should be noted that SQL/Slammer was a homogenous attack. That is, every instance of it looked the same. This made it relatively easy to construct and deploy filters that would resist its flow while not interfering with normal traffic. However, it is fairly easy to visualize a heterogeneous attack that might overwhelm this remedy.

So, there is wide-spread concern that there might be a malicious software-based attack that would bring down the entire Internet. To some degree this is angst, an unfocused apprehension rooted in intuition or ignorance. However, it is shared by many who are knowledgeable. Their concern is rooted in the (often unidentified and un-enumerated) facts that:

* the Internet evolved; it was not designed and deployed
* switching in the network is software-based,
* operation of the components is homogenous
* operation of network management controls is in-band
* users often have default access to management controls
* the topology is both open and flat
* paths in the network are ad hoc and adaptive
* connection policy is permissive,
* most of the nodes in the network are un-trusted and a large number are under malicious control.
* access is open and cheap
* identity of both components and users is unreliable
* ownership and management is decentralized
* other

If the impact of these things on the resiliency of the Internet were as obvious prospectively as it is retrospectively, we might have done things differently. On the other hand, we might not have. A little discussion is in order.

Unlike the PSTN, the Internet is packet, rather than circuit, switched. The intent of this was to make the network more resilient in the face of node or link failures.

The routers and switches may be software running on von Neumann architecture general-purpose computers. This may make the network more resistant to component failure while making the components more vulnerable to malicious attack.

We have become accustomed to the idea that software processes are vulnerable to interference or contamination by their data, i.e., the software in the switch can be contaminated by its traffic. This exposes us to attacks intended to exploit, interfere with, or take control of switches and routers.

This may be aggravated by the fact that so many routers and switches look the same. While there are hundreds of products, most of them present controls that are operated via the Border Gateway Protocol (BGP). An attack that can take control of one might be able to take control of many.

Even most non-switch nodes in the network look the same, that is, like Windows or Unix (rather than, for example, MVS or OS/400.) These two operating systems are open, historically broken, and have a commitment to backward compatibility that makes them difficult to fix. Historically they have shipped with unsafe defaults and have been corrupted within minutes of being connected to the Internet. The result has been that there are millions of corrupt nodes in the Internet that are under the control of malicious actors.

Operation of the routers and switches (and other network nodes) is via the network itself; they can be operated from almost any node in the network. Many are hidden, if at all, only by a password, often weak or even default. Thus, it might be possible to coordinate simultaneous mis-operation of many nodes at the same time.

The Internet is open to as to user, attachment, protocol, and application. The cost of a connection to the Internet is a function of the bandwidth or load but the cost of a relatively fast persistent connection is in the tens of dollars per month, about the same as a dial connection a decade ago.

While one must demonstrate the ability to pay, usually with a credit card, the credit card may be stolen, and, depending on the provider, the name in which the connection is registered may not have to be the same as that on the credit card. In short, almost anyone can add a node to the Internet with minimal checks on their identity or bona fides. There will be bad actors.

The only thing that is required to add a new protocol or application to the Internet is that at least two nodes agree on it and that it can be composed from IP packets. Use of load-intensive protocols and applications for streaming audio and video were added to other protocols and applications with no changes to the underlying infrastructure. We have seen DoS attacks that relied upon minor changes to protocols and their use.

At least in theory, the topology of Internet is "flat," as opposed to structured or hierarchical. That is, at least in theory and with few exceptions, any node in the Internet can send a packet to any other node in the Internet. The time and cost to send a packet between any two nodes chosen at random is roughly the same as for any other pair of nodes.

Said another way, both the time and cost to send a packet are independent of distance. One implication of this is that attacks are cheap, can originate anywhere, and can attack anything attached.

Paths in the Internet are determined late, possibly on a packet by packet basis, and adapt to changes in load or control settings. The intent is that there be so many potential paths between A and B that at least one will always be available and that it will be discovered and used. While the intent is to make the network resistant to node and link failures, an unintended consequence is that it is difficult to resist the flow of attack traffic.

The original policies of the Internet were promiscuous (as opposed to permissive or restrictive); not only was any packet and flow permitted but there were no controls in place to resist them. This was essential to the its triumph over competitors like SNA and may have been necessary to its success.

While controls have been added as the scale has grown, the policy is still permissive, rather than restrictive, i.e., everything is allowed that is not explicitly forbidden.

Said another way, all traffic is presumed to be benign until shown otherwise. Attack traffic can flow freely until identified and restricted.

Finally, while most of the nodes in the Internet are untrusted, and we know that many are corrupted and under hostile control, all are given the benefit of the doubt. To date there has been little effort to identify and eliminate those that have been corrupted. Therefore there remains a possibility that these corrupt systems can be marshaled in such a way as to deny the use of network to all, or some targeted group, of users.

The Internet is robust, not fragile. It is resistant to both natural and accidental artificial events. However, To the extent that the above things are, and remain, true, the Internet, and indirectly, the nations, economies, institutions and individuals that rely upon, it are vulnerable to abuse and misuse; concern is justified, if not proportionate.

While these characteristics are pervasive and resistant to change, while they were often chosen for good reason, they are not fixed or required and can be changed. Understanding them and how they might be changed is key to making the Internet as resistant to abuse and misuse as it is to component failure or destruction.

It suggests that the network must become both less open, not to say, closed, and more structured. The management controls must be protected and taken out of band. The policy must become much more restrictive. We must identify our users and customers and hold them accountable for their traffic.

To bring the Internet to infrastructure standards, we must overcome not only inertia but also culture. Each of us must exercise our influence on our employers, clients, and vendors to move the Internet to the same standards that we expect of skyscrapers, bridges, tunnels, and dams. Since there is no one else to do it, we are called professionals and are paid the big bucks.

The Internet Kill Switch

2011-02-26T07:32:00.000-08:00

Recently in response to the activism in Egypt, President Mubarak "shut down" the Internet. While there is some question as to how effective this was, to the extent that it worked at all, it was because there were only two Internet service providers and they were creatures of the decades old "emergency" government.

Currently, prompted by fearful but impotent bureaucrats, the US Congress is considering giving a similar authority to the President of the United States. Needless to say, there is organized opposition to any such expansion of government authority.

In response to the opposition, a colleague wrote as follows:

Editor's Note (Schultz): Opponents of giving the U.S. President the
right to shut down the Internet are like those who oppose a mayor of a city being flooded by broken water mains being given the right to shut off the water. As useful as it is, the Internet is also capable of being used as a destructive weapon, and at least to some degree it has already been used in this way numerous times. Someone must have the authority to make decisions concerning its continued operation in case it is used outright as a weapon.*

The overt premise here is that the Internet "can be used as a weapon." While I concede that any infrastructure, indeed any artifact, can be misused, it is absurd on its face to compare such misuse to weapons like bombs and shells. The implicit assumption is that shutting it down is an effective defense. My mother called such a defense "cutting off one's nose to spite one's face."

Moreover, the analogy does not hold. One does not need the mayor to shut off the water. The water department will do it; they need no additional authority to do so. What is perhaps more important, they can be relied upon to do so in the least disruptive way. They can be relied upon to preserve as much of the capacity as possible.

Think about SQLSlammer. First it did not respect national boundaries. Second, before the governments of the world were even aware there was a problem, the network operators recognized, identified, and filtered the disruptive traffic. They did not seek permission but their judgment was so good and their action so measured that no one has ever even questioned them, much less faulted them, for this preemptive, not to say precipitous, action.

I am unable to envision any attack against, or via, the Internet where killing it is not worse than the attack. Indeed, the closest thing that we have seen to an Internet attack was the denial of service attack against Estonia. While one can imagine a politician using a kill switch in such a situation, it would be a solution at least as bad as the problem.

Most of the use of the Internet in warfare will be for intelligence gathering. Most of this will use open sources; attacks against hidden sources will be covert and low-intensity but in no case sufficient justification for shutting down the Internet. Adversaries may wish to deny one another its use in time of crisis but killing it simply plays into this.

However, what we have been taught to fear is the use of the Internet to mis-operate the controls of other infrastructure. The Congress has heard testimony that this risk is overstated but in any case, the proper defense is local to those controls, not a global shut-down.

I am unable to envision any case where the POTUS is better equipped to make decisions about the operation of the Internet than those who operate it day to day. Can you envision any case in which such a decision would not be political?

Indeed, to the extent that one believes in "Cyber War," one might ask whether a political decision by one country to "kill" the Internet might not be seen as an act of war by it's neighbors. We certainly saw the political decision by the President of Egypt to shut down the Internet as an act of oppression, not to say war, against his citizens. Indeed, it is far easier to envision such a capability being used offensively against one's own citizens than defensively against any adversary.

The Internet is designed to resist any and all attempts to shut it down. It should, can, and does survive multiple simultaneous component failures. Moreover, it is a poor respecter of national boundaries. Where would you propose to place such a control?

On the other hand, it is quite easy, particularly in light of recent events, to envision such authority being used to manipulate, intimidate, or control for political reasons. Like the USA Patriot Act, this kind of authority simply begs for misuse and abuse. For my comfort, both T and VZ are already far too willing, not to say anxious, to cooperate with the political authorities.

Before you support this proposal further, I suggest that you go to YouTube and reprise Michael Chertoff's demonstration of government crisis decision making. Instead of listening to them whine about their lack of authority, watch the process. Then ask yourself what the network operators are doing while this process is going on.

Government is the tool one uses when one wants to kill hundreds of thousands of people. It is really terrible at, for example, surgery, or other measured responses. There is a reason that we divide and limit it's powers.

Be careful what you ask for; you might get it.

* Quoted with implied permission form SANS Newsbites.

What does it Mean to Say a System is Trusted?

2010-09-13T11:03:00.001-07:00

Do not trust any computer that you cannot carry; prefer those that you can put in your pocket.

Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment.
- Robert H. Courtney

That little aphorism of Bob Courtney's has become a habitual touchstone for me. If it has not given me gravitas, it has at least kept me from appearing foolish by opining on the "security" of systems without regard to the threat or what they are being used for. It keeps me from equating the security of the application with that of the system or vice versa. It enables me to use a system for one application that is not suitable for others. It enables me to recognize when the security of a system that has served well is no longer adequate. (Many seem to get by simply saying that no system or application is secure. One can clearly get one's name in the paper by saying that. It is not particularly helpful.)

The client was a property and casualty insurance company. They had some fairly progressive programs under way but both their IT and security programs were mature and stable. We were called in because they expected that they were going to have a number of new e-commerce applications done on the public network. They wanted a security management system to ensure that these applications would be done conservatively.

The method that we used was to propose a straw-man for the management system and then refine it in ever larger meetings. One of the practices that we recommended was that connected applications be done on dedicated hardware; we wanted to be sure that these applications were free from outside interference or contamination. In an early meeting the client asked that this recommendation be changed to say that these applications be done on "trusted systems." We quickly realized that that was a better way to say what we were trying to say. It included our recommendation but was stated as an objective rather than a specific practice.

Then we discovered that the reason that they wanted it restated was because they intended to run the application on their MVS mainframe. "MVS," we said. "You trust MVS?" "No," they said, "We trust our MVS. We have had it for twenty years, we manage it scrupulously, and we trust it." The auditors nodded their heads and then we nodded ours.

Part of the problem is that we came to the question the wrong way. In the early days of computers they were serially reused and had no shared resources. Most of the applications were not sensitive. The question simply did not arise. After a decade or so, we began to recognize that there was a small potential for information to leak from job to job because of the failure to wipe primary storage between jobs. Information left in memory by job n might be available to job n +1.

The problem really emerged with true shared-resource computing in the sixties. Even here the problem was tolerable. The systems were operated by a single enterprise, most of the users knew one another, and they shared similar goals and objectives.

By the late sixties, the size of user populations had begun to be numbered in the high tens to low hundreds and the modern question was on us. The potential for information to leak from one user to another was on us. One clear method by which it might happen was the interference of one process with another. The problem now had a name. Research began. While we thought that it was important, computer use was still so sparse that it wasn't really.

However, these were the days of Grosch's Law where we believed that shared resource systems were inevitable and the scale of sharing would continue to rise forever. We believed that one should always use the biggest computer one could afford. We believed that computers should be scaled to the enterprise. Thus, the problem of data security was framed as that of security in multi-user multi-application systems. We had framed the question in a way that made it almost impossible to talk about, much less answer. We knew that there was an objective called data security but the environment in which we wanted to talk about it was so complex that language failed us.

It was at about this time, 1968 or 1969 that I first met Dr. Willis Ware of the Rand Corporation. He came to White Plains for an IBM briefing on computer security. One item on the agenda was my master work, security for IBM's Advanced Administrative System. This system was intended for 5000 users and ultimately served several times that. It was a multi-user multi-application system but it was operated in a static mode, i.e., programs could not be changed while the system was operating. Users could not program and programmers could not use.

I was justifiably proud of the access control for the system. It was the largest and most complete system of its kind and it worked. The operating system was hidden from the users and the access controls for users to applications ran at the application layer. Dr. Ware listened politely and then dismissed the whole effort as trivial. Years later, when we had become friends, I found that he did not even remember it. He dismissed it on the basis that it did "not address the general case, the one where any user could write and execute a program of his own choice."

So the question of whether or not a system was secure or not had to be addressed not only in the context of sharing of arbitrary applications and data by an arbitrary number of users but there could be no assumptions about the flexibility or generality reserved to any of those users. One might well conclude that such a question excludes any useful answer but that did not keep us from trying.

Tomorrow we will look at some of the attempts.

Are you a target of "Advanced Persistent Threat" Sources or Attacks

2010-08-25T12:20:00.000-07:00

"Advanced Persistent Threat" (APT) is a term of art. It was coined by the USAF to label an attack pattern that they had identified and that they thought was emanating from a nation state. It came into the security jargon when it was used to describe an extended and resourceful attack reported by Google.

These attacks are "advanced" in the sense that they are coordinated and multi-phased. The phases begin with target selection and vulnerability identification, through domain contamination and information ex-filtration, to intelligence analysis and exploitation.

These attacks are also advanced in the sense that there are knowledge, skills, and abilities specific to each phase; no single individual is likely to be expert in all phases. One guy crafts the bait while another selects the malicious code. The attacks are advanced in that the threat source brings together the necessary experts and coordinates their activity across phases and time.

The attack is persistent in the sense that it continues through all the necessary phases, and the threat source is persistent in the sense that it will invest whateever time and resource in necessary for success.

While the term really refers to an attack, rather than a threat, to the extent that the attack has a rate and a source, it implies a "threat."

Is this something that you need to woory about? Is your enterprise a target?

The short answer is that if you are a Fortune Five Hundred enterprise with intellectual property, you are probably a target of choice of one or more nation states. If you are a financial services company or a payment card industry service provider, you are a target of choice for organized and resourceful criminal enterprises.

This is not to say that the rest of us might not be targets of opportunity for these threat sources, but only that their attacks against us are not persistent or continuing. Individuals may be "victims" of payment card fraud but it is the enterprise that is the "target."

It would be nice if one could detect such attacks early. Then one could at least determine whether or not one was currently under attack. However, the attacks usually begin with low intensity activities such as vulnerability probes or the distribution of bait messages. While intensive probes are easy to recognize, the same probes spread across enough time may not be obvious. If bait messages are not difficult to detect, they will not work at all. In fact, they will be as artfully crafted as necessary for them to work. There will also be a "sufficient" number of them that one or more victims will take the bait. Only after the bait has been taken are the other phases of the attack triggered. While it is somewhat easier to automate the detection of these later phases of the attack, it may also be only after some data has leaked and some systems compromised.

Note that while the compromise of your intellectual property may be a threat to the health and continuity of your enterprise, the consequences may not be limited to your enterprise. They may include damage to the vitality and growth of our economy and, perhaps, even to "homeland security." In this light, "best efforts" or "hit and miss" security is not good enough.

"Defense in depth" must be the order of the day; push your defenses up and out and your resources in and down. We can no longer afford an enterprise architecture that relies primarily on perimeter protection such that one person clicking on a bait message compromises the entire defense.

Electro-magnetic Emanations

2010-08-03T12:58:00.000-07:00

During my last years at IBM, Wjm Van Eck published his paper about reading screens using TV receiving equipment. The press loved it. There were TV shows on the BBC demonstrating reading screens at a show and reading a document from outside Scotland Yard.

Van Eck's experiment was based in part on the following:

· The screens of the day were character only
· They were CRT
· The CRTs were noisy and
· the noise mimicked standard broadcast TV signals

Van Eck simply cobbled together antennas, amplifiers, and receivers and displayed the signals on a standard TV screen.

I decided to see if I could replicate Van Eck’s results. I purchased from him a replica of his experimental rig and gave it to two engineers, one senior and one junior, in the Raleigh lab next to the plant that manufactured 3270 terminals. They assured me that it would be a piece of cake to reproduce the experiment.

It proved to be much more difficult than they anticipated. On one trip, they did manage to show me a screen that lit up like the one that they were trying to read at a distance of two meters. It was clear that the image on the destination screen was related to the one on the origin screen but the content was less than readable. As often happens with engineers, these two lost interest in the effort after they were satisfied that, given enough time and resources, they could replicate the results but long before they had actually dome so.

In the more general case, in estimating the cost of attack, engineers often discount the value of their own special knowledge and skills. They think, “Everyone knows (or can do) that.” The also tend to think that if an attack is feasible, it will be used.

These are the esoteric attacks from which Mission Impossible is crafted. In fact, one can expect an attack to be used only if it is efficient. The set of cases in the world in which such an attack is both suitable for the intended application and environment and cheaper than all alternatives is vanishingly small.

The leakage of information via electromagnetic signals is a vulnerability without a threat, a non-problem. Not all vulnerabilities are problems, not all problems are the same size.

Of course, today the cost of attack is even higher. Screens are bit-mapped graphics, not character. They are LCD, not CRT. Their emanations do not mimic broadcast TV signals. While they still leak, they are much quieter than those of a generation ago. Unless your applications are very sensitive, your adversary a nation state, and the rest of your security so good that this is your weak link, Spend your security resources elsewhere. Remember that Mission Impossible style attacks are undertaken only against those targets that are very sensitive and that have very good security.

"Data leaks! Get over it."

2010-07-17T08:39:00.001-07:00

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.

Encryption by Default

2010-05-19T10:44:00.000-07:00

A recent survey was reported as follows:

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.

Security in "The Cloud"

2010-05-12T10:42:00.000-07:00

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.