Blogs

Ethical and Other Issues Concerning the Kraken Botnet

Something very significant from an information security point of view happened recently.

Two TippingPoint employees, Pedram Amini and Cody Pierce, reverse engineered the zombie code used in the prolific Kraken botnet. They then created what appeared to be a genuine Kraken server and waited for zombies to respond to it. Any zombies that responded could thus be identified and presumably removed from computers in which they resided.

Approximately 25,000 zombies responded, but then Amini and Pierce suddenly faced an ethical dilemma. They reasoned that the systems were already compromised; so by removing the zombie code, they were actually doing the owners (as well as the Internet as a whole) a favor.

Others, Amini and Pierce’s boss included, took an opposing point of view, reasoning that because the owner of each infected machine had not given access permission, deleting the zombie code from each compromised machine might constitute unauthorized access to a computing system, which is forbidden by several U.S. statutes. They also worried that they might accidentally cause damage to the compromised systems. Others countered by saying that failure to remove the zombie code constituted the worst ethical failure of all.

As I have said in an earlier blog entry, insufficient attention is paid to ethical issues in the information security arena.

Predictably, then, ethical issues surrounding the Kraken botnet seem to have drawn remarkably little notice, as judged by relatively few blog and newsgroup postings on this subject. But perhaps in this case the problem may not be lack of interest in ethical issues, but rather the fact that whether or not to remove Kraken zombies may not be as poignant an ethical issue as it would superficially seem to be.

Removing tens of thousands of zombies would constitute an act performed in good faith, one that would benefit not only the owners of these systems, but also the Internet as a whole.

In my mind, the risk of potential damage to these systems looms as a showstopper, however. One should not blindly perform a benevolent act—the potential benefits and downsides of every act, benevolent acts included, must be carefully weighed.

Seeing a victim of a car accident lying in the road does not justify moving that person when moving that person may endanger the victim’s life more than leaving the victim there. The same is true of infected systems.

Ideally, Amini and Pierce should be able to contact a central team or function responsible for Internet security that would then notify owners of the compromised systems and ask them whether they want to have their systems disinfected.

A number of years ago the closest thing to this function was CERT/CC. CERT/CC now has a completely different mission, and no team or function has really been capable of filling this void.

Unfortunately, then, what is most likely to happen with all the infected systems is, at least in the short run, absolutely nothing.

This is a totally unacceptable outcome, yet it is difficult to envision any other one. All this once again shows just how vulnerable the Internet is from a security standpoint and how difficult it is to improve its overall security.

Perhaps some day some high-ranking government official will wake-up to this reality and try to do something about it, perhaps by forming an incident response team for the Internet.

Meanwhile, however, we are likely to continue to have to live in frustration while botnet creators continue to act maliciously and with impunity.

Audit-related Issues

I often go to conferences in which auditing is the central theme if not, major theme. I also know many professional auditors.

From a very high level perspective, an audit function within an organization must determine whether that organization’s management is providing suitable oversight and direction, whether resources are being used responsibility and in accordance with major business and/or operational needs, whether other functions such as business units and risk management are fulfilling their purposes and if so, whether they are doing it efficiently, and whether or not fraud, waste and misuse are occurring.

In the past I have been approached with opportunities for audit positions. I’ve always turned them down, in part because I do not have auditor training, but also because I am concerned that the job of an auditor might be too repetitious for my tastes.

It appears to me that auditors spend the preponderance of their work time preparing for upcoming audits, conducting audits, writing up audit results, and working to achieve resolution concerning deficiencies and other issues identified during audits.

Even if my impressions are correct, however, the importance of the audit function is not in any way diminished. Audit provides an independent assessment of critical elements within organizations; this assessment in turn is part of a system of checks and balances that provides critical feedback so necessary in determining what needs to be corrected to make or keep an organization functioning healthily.

I also have the impression that most audit functions are not nearly as proficient as they could and should be. Why?

1. One of the main reasons is that auditors too often do not possess a sufficient amount of knowledge about technology. Consequently, when audits involve use of computing systems, auditors may not be aware of critical technical issues that need to be resolved or may gloss them over, thereby allowing an organization unit to pass an audit, even though many technical and procedural deficiencies exist.
2. Auditors sometimes have incorrect or unrealistic views of technology. About seven years ago I came to the rescue of one of the best information security managers I have ever known. Her company’s audit function had decided that she had implemented intrusion detection, but not intrusion prevention throughout the enterprise. A senior auditor had attended a talk at a conference several months before the audit was conducted. Intrusion detection technology was deprecated, while intrusion prevention technology was pronounced the wave of the future. At the time, the fact that intrusion prevention technology was rather new and crude at the time, thereby introducing a significant amount of risk into IT environments, was never mentioned in this talk. I had to write a paper comparing intrusion detection and intrusion prevention capabilities and then present and defend the main points in the paper before the audit team that had rated my friend’s information security practice as unsatisfactory because of the lack of intrusion prevention capability.
3. Auditing tends to be a spot event, something that occurs at scheduled intervals, rather than a continuous process. As a result, to-be-audited groups and functions often expend Herculean effort in preparing for an upcoming audit. They are in reality “showing their best stuff,” and they have the luxury of being able to do so as a result of having time to prepare. But the way things actually work day-by-day within these groups and functions is too often completely different from the way they appear to work once an audit has become. I suspect that very senior auditors can tell when this discrepancy exists, but that many other auditors cannot.
4. The audit function too often exists as a silo with an organization. My main complaint here is from the perspective of an information security professional. In just about every audit of which I am aware, information-security findings are identified, yet too often the information security manager is not informed of the audit findings. (By the way, information security functions also too often fall prey to the “silo effect.”)

The bottom line is that the audit function is one of the most critical within organizations, but too often this function does not come close to reaching its potential. Dealing with the four issues I have raised here would go a long way in helping audit in doing so.

Comments (0)
~ : ~

Another Blow to Privacy Rights in the U.S.

A ruling by the Ninth Circuit Court of Appeals dealt yet another blow to privacy rights in this U.S. The ruling upheld giving the U.S. Customs and Border Protection Service the right to search portable computers and other types of electronic devices at U.S. borders without sufficient grounds or reasonable suspicion.

The appeal concerned a court ruling in which a person was arrested and charged with child pornography following a search without a warrant of his laptop by Los Angeles International Airport customs staff. The decision in the original trial was that the evidence was gained through unreasonable search and was thus inadmissible. This decision was subsequently overturned.

The ruling in this case has put yet another nail in the coffin of privacy rights in the U.S. Most of the erosion of these rights has occurred in the name of fighting terrorism.

The U.S. government has, for example, freely exercised the right to snoop on telephone conversations without court authorization, to obtain personal email and usage records from service providers, obtain information about individuals from banks and places of employment, and now to capriciously and arbitrarily seize personally owned computers and hold any evidence of a crime found therein against the owner.

The US Bill of Rights affords protection against unreasonable search and seizure, something that the American colonists were constantly subjected to at the hands of the British before the colonists declared independence.

Please do not get me wrong—I am not saying that the U.S. government is as abusive as were the British in the Americas in the 1760s and 1770s. Or instead, perhaps I should say that U.S. citizens and residents do not constantly face the threat of unreasonable physical search and seizure.

The problem is instead that the U.S. government can obtain just about any personal information about anyone within the U.S. at its whim and for all practical purposes does not have to justify its doing so. So why don’t more American citizens and residents complain?

The main reason is due to the difference between persons being subjected to physical search and seizure and being subjected to electronic forms of search and seizure. Physical search and seizure is highly offensive to those who must undergo this form of violation of dignity, whereas most individuals live in blissful ignorance concerning how much information about them is in the hands of the government, how the government has obtained this information, and what the government is doing with this it.

Additionally, I am by no means defending individuals who use computers in child pornography activity. In fact, I am glad that one such person has at least recently been arrested. But the ends do not justify the means. The way that the U.S. Customs and Border Protection Service gained evidence against the defendant in my estimation violated long-established protections within the U.S. Bill of Rights.

The bottom line is that privacy rights in the U.S. have eroded considerably in the last decade. We should be outraged that courts are giving our government the right to act in the same manner as totalitarian regimes.

We need to come out of our apathetic state, analyze and question what is going on, take action by writing our Congressional representatives, and vote for election candidates who champion the protection of privacy in the U.S.

Network Access Control Technology: Will it Succeed?

I recently attended the Interop Conference in Las Vegas. As I strolled around the exhibition area, I could not help notice all the booths at which Network Access Control (NAC) products were being promoted.

NAC technology is used to prevent potentially dangerous systems from being able to connect to networks. NAC tools examine various aspects concerning each system that tries to connect to a network, and then on the basis of the results, either allow or deny network access to that system. So, for example, if the user of a Windows XP system tries to connect to a network, but that system is infected by a worm, NAC technology is supposed detect the infection, sever the existing network connection, and apply a defensive measure such as denying any IP address to that system until it is healthy again.

Some NAC implementations perform tests such as determining whether a system connecting to the network has unpatched vulnerabilities, or whether it has the ability to connect using IPv6, or whether certain security-related settings are enabled, and more.

One of the first implementations of NAC technology was at the University of California at Santa Barbara. Network administrators were experiencing nightmare scenarios due to massive virus and worm infections that often started when a single infected PC connected to the network. By implementing a NAC solution, this institution was able to greatly reduce the time spent in identifying and cleaning up infected systems.

In theory, NAC technology is a wonderful idea. In reality, however, NAC is not always as ideal as it sounds. For example, false alarms comprise a frequently reported problem with many of today’s NAC products. A perfectly good system may sometimes trigger a false alarm, causing it to be locked out unjustly, resulting in user frustration, loss of productivity, and escalation of help desk-related costs.

Similarly, compromised systems sometimes pass a NAC examination or test and, accordingly, are allowed network access, even though they pose considerable risk to other machines on the network. Some NAC products are capable of performing only an initial examination or test; a system may become compromised after NAC has deemed it worthy of connecting to the network, but it is too late as far as NAC capabilities go.

Still another concern, possibly the greatest one, is what happens if someone compromises one or more NAC servers. Last fall I attended a talk at a conference at which I heard of a penetration test in which the penetration tester targeted NAC servers in a large network. By exploiting vulnerabilities in these servers, this person was able to gain root access to them; once he had root access, he locked out all the administrators of these systems from any network access whatsoever. (Humorously, the talk title included the phrase, “Self-defeating networks.)

It occurred to me that many of the problems with today’s NAC technology are the same problems as ones in today’s intrusion prevention technology, especially with respect to what happens when false alarms and missed detections occur.

One must, therefore, seriously question the continued viability of NAC technology.

On the other hand, the world of IT needs something like NAC, because allowing compromised and vulnerability-ridden systems to connect to healthy networks is one of the worst things that can happen from a security standpoint. The big question in my mind, therefore, is whether NAC technology will grow and improve in its accuracy and functionality soon enough, or whether it will stalemate because of limited acceptance.

As with just about everything else in the world of information security and IT security, only time will tell.

The Quest for Secure Software

Counts of the number of reported vulnerabilities in software products per year vary, but if you take an average of the available counts, you’ll find that approximately 2,500 vulnerabilities were reported in 2002. By 2006 this count had risen to something like 8,000.

According to several sources, the number of vulnerabilities reported in 2007 fell slightly, but it is safe to say that over the years the number of reported vulnerabilities has risen substantially.

Why?

There are simply so many software vulnerabilities to be discovered. Additionally, the number of people attempting to discover vulnerabilities has increased (because discovering vulnerabilities can lead to fame and glory, as well as large financial remuneration). Vulnerability discovery methods have improved considerably, too.

Most experts agree that the solution is to incorporate security into the programming process, one in which programmers avoid introducing bugs in their code by doing things such as allocating sufficient memory whenever programs take in input, ensuring that all state transitions are recognized and dealt with in a manner that circumvents abnormal conditions, ensuring that any elevation privileges with which one routine runs are rescinded when control is passed to the next routine, and so on.

However, whereas experts agree on what must in principle be done, they vigorously disagree on how to achieve this goal. Some possible approaches include:

1. Training undergraduate and undergraduate computer science students in secure programming methods.
2. Training programmers through courses offered by security training organizations such as SANS.
3. Offering in-house training not on a one-time basis, but rather systematically (e.g., two days every quarter).
4. Setting up a system of rewards and punishments given for the presence or lack of vulnerabilities in code produced by each developer throughout an organization.
5. Performing a manual analysis of code shortly after it is written, often through peer reviews of code.
6. Using technology that spots potential bugs in code, thereby allowing quality assurance and other staff to investigate whether or not vulnerabilities exist before the code is released to the public.
7. Subjecting alpha and beta code to vigorous security testing, thereby also enabling vulnerabilities in the code to be identified before it is released to the public.

Some of these solutions appear to be much more satisfactory than others.

I fear that one of the more unsatisfactory potential approaches is training undergraduate and graduate computer science students (approach 1).

I am not saying to withhold this kind of training. What I am saying is that although this approach is good for those who receive the training mandated by it, it is not provide a sufficiently pervasive solution because many if not most individuals who become programmers do not major in computer science, let alone ever go to college.

Holding training courses for professionals (approach 2) seems somewhat better in that a wider range of programmers can potentially be reached, but the fact that such courses generally last at the most two to five days considerably limits their usefulness. This amount of time is hardly sufficient time to reverse a lifetime of programming habits.

Additionally, think of all the vulnerable code that programmers will produce before they finally get training.

In-house training (approach 3) seems better yet, provided that an organization actually recognizes that secure programming is highly desirable and is willing to invest the needed resources, as Microsoft has in connection with its Trusted Computing Initiative (TCI).

Rewarding or punishing employees through salary increases/reductions and bonuses (approach 4) is an approach that is very likely to work, and has in fact ostensibly worked well in connection with Microsoft’s TCI. Finding bugs after they have been created, as prescribed by approaches 5, 6 and 7 above, can also work, but the fact that these solutions are post hoc renders them only partially effective.

The best way to get rid of vulnerabilities is to avoid them in the first place. I thus view approaches 5, 6 and 7 as “defense in depth” mechanisms; if used as a kind of second safety net beneath the primary net, namely using secure programming methods, they are valuable, but these solutions alone will never go very far in decreasing vulnerabilities in software.

Debating which approach to producing more secure software may be for the most part, however, a moot issue.

Any approach or combination of approaches is better than what the software industry currently uses (or better said, so often fails to use).

Security in software must start with a commitment by senior management. Without adequate backing and resources from senior management, it is extremely unlikely that vulnerabilities in software will be minimized. And until the public quits buying or starts buying less of vulnerability-ridden software, senior management will continue to have little reason to be committed to produce more secure software.

The Business Costs of Security Compromises

A significant barrier that information security professionals constantly encounter during efforts to obtain needed resources is skepticism among senior managers concerning whether serious information security breaches really do occur and if they do, whether they could occur in their particular organizations.

One of the best antidotes is to present empirical evidence concerning the cost of security compromises. Whereas horror stories and handwaving concerning the likelihood of and damage due to potential security incidents are generally ineffective, presenting empirically determined incident-related losses resulting from security compromises is more likely to convince senior management.

Obtaining the right kind of evidence, however, is not so easy. A good first source to which to obtain incident loss statistics is the annual FBI-Computer Security Institute (CSI) survey in which respondents indicate whether or not their organizations have experienced information security incidents over the last year, and if so, what the estimated financial losses are.

For example, over four years ago results of this survey showed that cumulative financial losses for 223 of 503 corporations that responded to this survey amounted to USD 455 million. At the same time, however, more recent FBI-CSI surveys have showed dwindling reported annual loss figures connected with security incidents. Furthermore, critics have also been quick to point out that the amount of reported financial loss is subjective—purely an estimate on the part of each survey respondent.

Somewhat more suitable evidence comes from surveys concerning the impact of data security compromises upon customers.

A recent study by the Ponemon Institute shows, for example, that 55 percent of participants in this study said they had been informed of more than one security compromise involving their personal data over the last two years, and eight percent said that they have been informed of four or more of such compromises.

The Ponemon Institute’s study also shows that 63 percent of the survey participants reported that the letters they received after data security compromises had occurred contained no information concerning what to do to safeguard their data afterwards. Furthermore, the majority of the respondents indicated that more than a month had transpired before they were finally informed that their personal data were compromised. At the same time, however, 98 percent of those who had fallen victim to a data security compromise actually became victims of identity theft afterwards. Most significantly, almost one out of every three individuals who were informed of a data security compromise involving their personal data have ceased doing business with the company that experienced the incident.

The overall message to commercial entities is clear—either protect customer data, or lose a large proportion of your customers.
From a senior management perspective, the most compelling data come from studies showing the relationship between information security breaches in organizations and the relationship between stock share price. The first such study of which I am aware was published seven years ago. Conducted at the University of Maryland, this study revealed that there was some evidence of a relationship between “public announcements of information security breaches” and an organization’s stock price. Interestingly, this relationship was found to be present only when information security breaches involved the compromise of the confidentiality of information.

More recently Australian analyst company Hydrasight and Colorado-based research company Enterprise Management Associates Inc. (EMA) conducted a similar study of six US companies. The results indicated that within four weeks of details concerning an information security compromise being publicly disclosed, negative responses, stock share prices fall. For the companies in the study, the average stock price plummeted by an average of five percent within a month of the disclosure of the incident, and the price remained depressed for almost one year.

From a senior management perspective, loss of stock share price is very high on the list of outcomes to be avoided. As such, being armed with empirical evidence concerning the relationship between security incidents and stock price is one of the wisest things an information security professional can do to “make the sale” to senior management. And, hopefully, more studies such as the ones conducted at the University of Maryland and Hydrasight/EMA will continue to be performed so that more such evidence will become available.

Strategies for Dealing with Latest Cyberattacks: The Need to Reinvent the Wheel

If you regularly read security-related news, you have undoubtedly seen news items regarding the growing number of targeted attacks against sensitive US government and commercial sector computing systems.

Although the attack methods have varied widely, many of them have involved sending malicious attachments to certain US government or private sector employees that, if opened, implant malicious code in the system used by the unsuspecting targeted individual. Now in control of the system it has infected, the malicious code covertly notifies the attacker that this code has control of a system. The attacker follows up by gaining backdoor access to the infected system with full privileges without leaving any indication of the activity whatsoever.

The only real common denominator is that systems keep getting broken into time-after-time.

Last year the Bush Administration reportedly became very concerned about these new, highly successful attacks. In January President Bush signed the Cyber initiative, which was intended to provide resources to major government agencies and departments in an attempt to stem the tide.

These resources have, however, been slow to get to information security programs; meanwhile, if anything, the attacks are reportedly becoming more frequent and more deadly. The relentless attacks originate from a plethora of different IP addresses (many of which reportedly are in the Peoples Republic of China), and the potential victims have ostensibly been very carefully chosen.

There is a huge paradox here, however.

A good proportion of the systems that have been broken into have been secured in accordance with general system security principles. The government agencies and departments that received miserable grades for their practices of security from Rep. Putnam of Florida not too many years ago are now receiving much better marks.

The agencies and departments are using well configured and well maintained firewalls, intrusion detection and intrusion prevention systems, virtual private networks, strong authentication and are keeping up better than ever with installing patches in systems.

Yet the successful onslaught continues.

What is becoming increasingly evident is that a new security paradigm is needed if government agencies and departments as well as the commercial arena is going to be successful in defending their systems against this new breed of attack.

New paradigms are contrived all the time, but many individuals who are in a position to do something about the problem do not know about them. Additionally, there seems to be little agreement concerning the one that is likely to work best among the individuals who are aware of these paradigms and are sufficiently competent to evaluate them.

Much of the latter problem results from lack of agreement concerning the evaluation criteria that should be used to evaluate new paradigms. The unfortunate result is that all the while information security functions within US government agencies and corporations are sticking with the “same old same old” approach to information security.

A new paradigm needs to be created soon, or if not, the most promising of existing paradigms needs to be chosen soon. Then, more importantly, the controls and infrastructure that the new paradigm calls for need to be put in place shortly afterwards.

It is well time to quit spinning wheels—the problem is simply too serious.

The Future of Endpoint Security

I recently attended the RSA Conference in San Francisco. Among the many things that I did while I was there, I visited various vendors’ booths. I could not help noticing the huge emphasis that a number of vendors were placing on endpoint security.

Endpoint security “is a strategy in which security software is distributed to end-user devices but centrally managed.” Just about everybody who knows anything about information security knows that security threats have shifted considerably over the years to the point that workstations and users are now more than ever frequently targets of attacks. The greater emphasis upon endpoint security thus makes a great deal of sense.

I also learned of a Gartner Group presentation that addressed problems resulting from Microsoft’s integration strategy. The Gartner analyst asserted that Windows workstations are in effect becoming fatter and fatter clients. What started out as a lean operating system on which a few key applications such as word processing and spreadsheet applications ran has turned out to be an enormous, complex bundle of code for which integration of software, much of it created by Microsoft itself in the name of improving security, is becoming an ever growing challenge.

What is worse is that there is apparently no end in sight for this trend, something that will increasingly exacerbate the problems that have resulted. The Gartner analyst expressed hope that Microsoft will find a way to deal with the bloated client problem. In a recent conversation over this topic a friend of mine was not nearly as optimistic. After we finished discussing this topic, it dawned on me that it is almost as if Microsoft is going to have to start over again by creating a new breed of operating systems, ones that are more similar to its early Windows systems, if it is ever going to produce a thinner, more manageable operating system that overcomes integration problems.

And if it does this, the product appeal of such software will be considerably diminished-after all, the availability of new features is what entices users to abandon versions of products that they are currently using in favor of purchasing the latest version.

Additionally, there almost certainly would be a lack of security in any hypothetical thin client Windows operating systems because of the need to drastically reduce the amount of code in them. Security-related programs — the ones that deliver endpoint security — would have to be cut out to make the client considerably thinner.

Regardless of the direction Microsoft goes with its future operating system products, one thing seems very clear to me — endpoint security, as logical as this approach is, only adds to the fat client problem. As such, I foresee the future of endpoint security as limited.

What is the alternative, then?

I think that just as Google and Yahoo offer free search services so that they can make money from advertisers, companies such as these will make free computing services available to the public. Customers will connect to a Google or Yahoo-(or perhaps even Microsoft) created operating system from extremely dumb terminals such as the ones used for Web TV access.

Users will be expected to do nothing (or perhaps nearly nothing) for the sake of security. Security will instead be supplied by the computer services provider. Talk of endpoint security will then become moot and honestly, provided that the providers build in a thorough set of well-designed, well-implemented security controls, security for end users is likely to improve drastically.

I know that I have almost certainly stepped on a few toes, and for that I apologize. Please just do not misinterpret what I have written. I am not recommending that endpoint security be scrapped. All I am saying is that endpoint security and increasingly bloated versions of Windows operating systems cannot continue to co-exist.

Stay tuned for future developments, as this issue is one of the most fascinating ones that we currently face.

Data Deduplication Technology

Data deduplication (often known as “single-instance storage” or “intelligent compression”) is a way of getting rid of redundant data by keeping only one unique copy of each piece of data on storage media such as disk drives. Every redundant copy of every piece of data is deleted and a pointer to the unique copy of the data is left in its place.

The main purpose of this technology is to save storage space. The more potential copies of a given piece of data, the greater the economy of storage is. Additionally, data deduplication can substantially reduce the amount of data that needs to go over networks when backup and restore operations occur, thereby making more bandwidth available for ongoing network operations.

Data deduplication is a relatively recent technology, one that is not very well known among IT professionals, let alone information security professionals.
What is even less known, however, is the potential that this technology has with respect to data security. Because data deduplication reduces the need to send data across networks during backup and restore operations, this technology reduces the likelihood of promiscuous capture of these data. But what is almost entirely overlooked is how data deduplication can help lower the probability of data security breaches due to system breakins and lost or stolen mobile computing devices.

Because data deduplication results in one and only one copy of every file, it reduces the number of potential targets for would-be data thieves. The more copies of a given file there are, the higher the probability that the file will fall into unauthorized hands.

Consider, for example, a user who takes home from work a laptop from work and later discovers that the laptop has been stolen. Thousands of files potentially containing sensitive information would be on a “normal” laptop, but with data deduplication, the files would instead still reside on one or more servers to which the laptop would instead have thousands of pointers to various paths on these servers.

The would-be perpetrator would have to use the stolen laptop to authenticate to the user’s network and/or server(s) to access files-a significant barrier, provided that the required authentication method were sufficiently strong.

The fact that downloaded files can and do become downloaded on workstations that access servers is a potential but very solvable problem. Good data deduplication technology includes client software that checks to ensure that any files that are downloaded in this manner are deleted after a while.
Data deduplication is by no means a panacea for risks related to data security breaches, but it provides an intriguing and potentially very effective solution. One thing seems sure-this technology will grow as those who work in the IT arena learn just how useful it can be.

And if you are an information security professional or someone who works in business continuity and disaster recovery operations, it is especially incumbent upon you to devote some time and effort to learn more about this promising new technology.