Don Evans of the United Space Alliance is one such individual. Don just retired on June 5, 2008, and although I was unfortunately not able to attend his retirement ceremony, I would imagine that there were not many dry eyes among the attendees when all the nice things about him were being said.

Don is above all else one of the finest human beings I have ever known. He is a living embodiment of kindness, graciousness, honesty, fairness, unselfishness, and personal maturity—a true model for others to follow—yet few professionals have accomplished as much as Don has.

Don’s accomplishments include (but are by no means limited to):

• Being one of the early leaders of the information security/information assurance effort within the NASA community. He did this despite a plethora of obstacles, including political wars, bureaucratic entanglements, lack of funding, lack of staffing, and (much too often) widespread ignorance and apathy.
• Contributing significantly to the development of the Generally Accepted Security Principles (now called the Generally Accepted System Security Principles or GAISSP). These principles represent that most fundamental and important concepts in the field of information security. No one could have identified and communicated these principles better than Don.
• Helping get the CISSP certification effort started and sustaining it long afterwards. The success of CISSP certification has been phenomenal, and no one worked harder to achieve this level of success than did Don.
• Working tirelessly on conference planning committees. I honestly do not know on how many of such committees Don has served over the decades, but the number must be staggering. I remember speaking at conferences in Houston and Clear Lake, Texas in the late 1980’s, when I had not been in the field of information security all that long. One of the first things I learned was that Don was one of the major figures who organized and ran these conferences.

One thing about Don that earned my utmost level of respect was Don’s ability to remain cool and collected, no matter what the circumstances. He worked behind the scenes on his job and developed a great deal of rapport with senior management. He got what he felt was right without trying to bowl people over, but instead by treating others with unselfishness and respect for them—even those who did not deserve it.

Several years ago Don became seriously ill and almost died. Huge amounts of concern and sympathy surfaced from within the information security community and also elsewhere. Don pulled through his health crisis and now looks ultra healthy.

Predictably, Don is going to work a little bit for the NASA community while he is retired. Let’s just hope that he doesn’t work too hard-no one so richly deserves a great retirement as does Don.

Advocates of system auditing argued that enabling system auditing was essential for security in that without it, unauthorized activity was almost impossible to detect. On the other hand, detractors argued that nobody looked at system audit log data anyway, and, worse yet, enabling system auditing consumed a large amount of system resources as well as disc space.

Twenty-five years later, many things have changed.

Whereas 25 years ago intrusion detection systems (IDSs) were in their infancy and intrusion prevention systems (IPSs) were unheard of, today both types of systems are deployed in a significant percentage of information security practices in medium and large businesses and organizations. Additionally, an abundance of network security monitoring tools and utilities now exists.

Furthermore, one of the first things intruders typically do in an attempt to masquerade their dire activities is to disable system auditing and/or to erase existing audit logs. Frankly speaking, one of the least trustable pieces of evidence from a potentially compromised system is audit log data.

So the issue very much persists-should system auditing be enabled?

The current answer is yes, but the primary reason is substantially different from any reason 25 years ago.

Enabling and inspecting system auditing is now required by numerous compliance regulations and standards. The Payment Card Industry Data Security Standard (PCI-DSS) requirement 10, for example, mandates that all access to network resources and cardholder data be monitored. It would be difficult to demonstrate compliance with this requirement if auditing in systems that held cardholder data were not enabled. Similarly, section 10.10.1 in ISO/IEC 27001 requires continuous audit logging. Additionally, system auditing has become an increasingly necessary part of a defense-in-depth approach to information security.

With the sophistication of attacks rising to the level it has, it is unlikely that an abundance of clues concerning the nature of any attack is likely to be available. System audit data may be one of only a few available clues. These data can also be used in event correlation, thereby enabling individuals to discover patterns of attack activity that would not otherwise be recognizable.

Even if attackers have disabled system auditing, the fact that it has been disabled provides a valuable clue concerning a security breach.

The real issue concerning system auditing is thus currently not whether system auditing should be enabled, but rather how much auditing needs to be turned on in which particular systems. The general rule is the more there is to lose, the more auditing needs to be enabled.

Despite how critical system auditing is to information security, not everyone in the IT arena has jumped aboard the auditing bandwagon. In particular, some system administrators still oppose enabling and inspecting system auditing on the basis that audit data fill up the hard drive. And, believe it or not, to some degree these individuals have actually pulled the proverbial wool over some auditors’ eyes, something that I find to be incredible because today’s computing systems almost invariably have such huge amounts of disk space.

Furthermore, many tools and scripts that purge old audit data are widely available. Auditors would thus be well advised to quickly dismiss claims that system auditing cannot be enabled because of disk space limitations.

A final question concerns whether system auditing needs to be enabled on workstations. Workstations, after all, generally do not process or hold the kinds of valuable information that servers do. The answer to this question depends on the business and operational needs of each organization. In a very small organization with a paucity of valuable information, it might not make sense to enable auditing on workstations, even though audit data from such systems might contribute to a defense-in-depth approach in monitoring. In a much larger organization in which critical data are likely to be downloaded from servers to workstations, the opposite is likely to be true.

I’ll close by saying that if there is any doubt whatsoever, system auditing should be enabled, even on workstations, because the cost of doing so usually far outweighs the liabilities.

Large organizations such as the Computer Security Institute and ISACA and corporations such as the Big Four accounting firms are particularly likely to conduct these surveys.

No matter what the year is, results generally indicate that funding and staffing are never sufficient, that senior management is prone to overlook information security-related risk, that the cost of security breaches is growing, and that certain types of security-related technology is used more widely than others.

The fact that so much information security-related research is conducted is a good thing, but too often the way the research is conducted and the results of such research are interpreted greatly troubles me.

For example, suppose that results of a study indicate that the amount of funding for information security and the amount of security breach-related losses are inversely proportional to each other, that is, the more spending, the lower the losses, and vice versa.

Too often the conclusion drawn is that spending more money on security produces results in less financial loss due to security breaches. This conclusion may make sense to individuals who do not know about scientific research, but it is completely specious to those who do. Controlled experiments were not conducted, and as such, causative conclusions cannot be drawn, no matter how high the absolute value (positive or negative) the correlation coefficient turned out to be.

Similarly, many studies compare two or more groups of individuals, organizations, security practices, or other entities. Results typically show that one group of individuals, organizations, or security practices scored higher on one or more measures than did others.

For example, I am familiar with several studies, the results of which show those who engage in black hat activities are more anti-social and introverted than others. The problem with so many of these studies is that the subjects of these studies have been chosen by the researcher or may have pre-selected themselves by volunteering to participate in a survey that was posted on a public Web site rather than being randomly selected. As such, being able to derive valid generalizations from the results is impossible, because the results may have been due solely to selection factors.

Another gripe I have concerning much of the research conducted in the information security arena is using far too small sample sizes. Incredibly, I have seen grandiose claims based on research in which only 50 or 60 individuals were involved in a study.

Again the problem is being able to derive valid generalizations from the results.

The information security arena has some excellent certifications, but curiously none of them tap being able to adequately interpret information security-related research results, something that competent information security professionals need to be able to do. This oversight needs to be corrected-the sooner, the better.

When I speak at a conference, I generally spend a good amount of time doing social networking, but I also carefully look through the agenda for talks that might be of interest and value to me. I have listened to a few talks on cyberterrorism at several conferences I recently attended.

Despite the fact that those who presented these talks had obviously spent a good deal of time and effort in creating their vugraphs, I must admit that I was disappointed with their content. As I think back on what troubled me, however, I think that my problem is really with the concept of “cyberterrorism” more than anything else.

Any kind of terrorism, no matter what its source is, implies an attempt to wreak fear and havoc among people because of the potential for an impending, disastrous event to occur. Frankly speaking, misusing computers does not have nearly the potential for instilling fear in people as do bombs, automatic weapons, and hijacked planes crashing into skyscrapers.

So far there have been a few events that, if interpreted with some imagination, might be construed to constitute cyberterrorism. For example, in 2000 an attacker intruded into the computer network of a sewage treatment plant in Australia over a period of about two months, altering settings in computer systems that caused hundreds of thousands of gallons of sewage to leak into nearby rivers and parks. The attacker’s actions polluted the creek water to the point that the creek turned black and smelled badly, and many fish and other waterlife were killed.

To claim that this incident instilled terror in the hearts of minds of local residents or anyone else, for that matter, would be a gross exaggeration, however. The same is true of more recent reported cyberattacks against power plants in which electricity generation was allegedly disrupted.

Cyberterrorism could happen, but will it happen? And if it does, what degree of impact will it really have? The public is, after all, not generally terrified when sewage leaks occur or when electrical power generation is disrupted, let alone when many (with a few notable exceptions) natural disasters such as hurricanes and massive disasters of much greater magnitude occur.

Most organizations such as power plants have business continuity procedures that can at least to some degree lessen the impact of computer-related disruptions and outages. Additionally, most computing systems permit humans to intervene when these system fail or run abnormally. Cyberterrorism may thus be a fascinating topic, one that brings in millions of dollars to researchers who jump on the cyberterrorism bandwagon and that results in talk proposals that would otherwise be rejected being accepted at conferences, but I fear that there is much more hype than substance in this concept.

Has the cyberterrorism threat changed substantially since late 2001?

Have we really learned anything new concerning the ways in which it might manifest itself, those who might unleash it, and how we can defend ourselves against it?

I suspect that technically the answer is yes, but if this is true, it is barely true. I just hate to see the negative effect a small number of information security professionals who so avidly promote this content have on critical players such as senior management within organizations and thus ultimately upon the credibility of information security itself.

Cyberterrorism needs to be viewed more realistically and hyped much less than it currently is. Most organizations currently face far greater threats than cyberterrorism now and for the foreseeable future.

It is well time to get real and to quit talking like the proverbial Chicken Little, who lost all credibility by repeatedly crying that the sky is falling.

Benson’s postings among other things state that after the news of the massive data security breach at TJX surfaced, TJX had, announced that many of its security practices were being tightened. Benson noticed, however, that the password for employee computer access at his store was blank and that it was possible to choose a password that is identical to one’s username.

The basis for firing Benson was unauthorized disclosure of confidential information.

My first reaction when I read this news item was that it was quite foolish of Benson to risk all that he did and ultimately pay the price he did simply to expose his employer’s owner corporation for its alleged poor security practices. But then I got to thinking about the magnitude of the data security breach that TJX experienced well over a year ago and the fact that dismally poor security practices were so directly linked to this massive breach.

As part of the settlements that were reached as the result of this breach, TJX agreed to make a large number of improvements in its practice of security. What Benson appears to have uncovered and then announced was the fact that TJX is ostensibly not complying with the terms of these settlements—a potentially very serious issue. Perhaps worse yet, TJX is by its apparent failure to adequately protect its own systems could still be exposing its customers to the potential of identity theft.

One would think that after what many TJX customers went through as the result of its gigantic data security breach, there would now be a greater amount of corporate concern and conscience regarding the welfare of its customers, but apparently not.

To me, therefore, Benson is now starting to look more and more like a hero. I predict that Nick Benson will soon find another job, if he has not already done so. I would, in fact, be most happy to help him find another job, should he choose to send me his resume’.

To me, however, the bigger issue concerns the need for change within senior management at TJX, management that appears be simply not get it when it comes to information security issues.

Ugly stories about TJX and its security deficiencies are being widely circulated in the media, hurting this company’s reputation in the eyes of the public considerably. Additionally, the possibility of legal consequences in which TJX may have to pay huge fines and face even more lawsuits than it currently faces and in which officers of this corporation could also face fines and possibly even jail time is now higher than ever.

As far as my own personal behavior concerning shopping at TJ Maxx and Marshalls stores goes, I continue to refuse to use my credit card for anything I purchase at both of these stores.

I recently purchased about $40 of merchandise at a local TJ Maxx store, and when the person at the check-out counter asked me if I wanted to pay by cash or credit, I immediately replied “cash.” I then explained why, but apparently to no avail. Interestingly, the TJ Maxx employee had never heard neither of TJX’s massive data security breach nor of lax security practices within this chain of stores. I walked away wondering if the same might be true of TJ Maxx senior management.

Configuration settings that tighten security in conventional systems are often not available in mobile devices. Additionally, vendors too frequently turn their backs to vulnerabilities in their products.

A good example is Research in Motion (RIM), the vendor of BlackBerry devices. Until fairly recently, RIM virtually ignored vulnerabilities in its products. BlackBerry vulnerabilities were posted at various Web sites, but RIM did not produce patches or workarounds (or even post information about these vulnerabilities on its own Web site), even though some of the vulnerabilities were critical.

For example, a buffer overflow condition during meetings synchronization with Microsoft Exchange was discovered in BlackBerry 7230. Exploiting this vulnerability could lead to denial of service as well as other undesirable outcomes.

Similarly, a vulnerability in portable network graphics (PNG) file handling could lead to denial of service in BlackBerry Enterprise Server 4.x. Furthermore, exploit code (BBProxy) installed on a BlackBerry has to potential open a covert communications channel with RIM servers by bypassing gateway security mechanisms between the attacker and an internal network.

RIM’s original response to these serious vulnerabilities was to ignore them, and RIM was not by any means the only vendor to take this approach.

Another problem is that the arsenal of security tools (anti-virus software, anti-spyware software, personal firewalls, integrity checking software, and more) that is available on conventional computers such as PCs is usually less available in the mobile computing environment. The exception is anti-virus software, which is now available on most major mobile computing devices. Without such tools, the struggle to achieve necessary levels of security is almost impossible.

Another significant limitation concerning security in mobile computing devices is the lack of auditing capabilities in these products. Many of these devices have no auditing capabilities whatsoever, due in large part to the fact that writing audit data to disk drives consumes so much disk space, something that is generally limited in mobile computing devices.

Some of these devices have auditing functionality, but this functionality is typically meager in that audit entries are very vague and incomplete. Being able to inspect detailed audit data is a critical part of security for every system; without these data, perpetrators could engage in a wide variety of unauthorized actions without ever being noticed. Auditing functionality is thus something that needs substantial improvement in the mobile computing environment.

As I have said before, mobile computing risks are currently among the foremost of unaddressed security risks. There is only one reasonable response—to begin assessing these risks with the ultimate goal of managing them to the point that they are reduced to acceptable levels.

The problem is going to get worse over time as computing becomes increasingly mobile, so starting as soon as possible is the only reasonable strategy.

Another part of the risk equation for these devices is the fact that in most cases, obtaining mobile access means that users must connect to networks other than an organization’s own network. It is thus generally much more difficult to control devices that are connected in this manner.

Consider, for example, the issue of performing security maintenance (let alone IT maintenance in general). Suppose that a new worm that targets one or more mobile computing devices starts to spread and that installing a new patch prevents the worm from infecting these devices.

System administrators can normally readily remotely connect to devices that are connected to their organization’s network and then push the patch into these devices through remote administration tools. The same is not true of users who are on travel or who are working from home, a hotel room, or an airport, however; they will connect to networks other than their organization’s to be able to ultimately reach their organization’s network.

The likelihood that system administrators or remote administration tools will be able to connect to these devices and install the needed patch is miniscule. Consequently, the probability that mobile users’ devices will become infected is likely to be considerably higher.

Another significant security obstacle resulting from mobile computer usage is that when users are away from the office, they are less able to keep in the loop concerning security alerts regarding current incidents and threats.

If a new worm surfaces, for example, warning users concerning what to do (as well as what not to do) to avoid an infection can greatly reduce the probability that users’ computers become compromised. Employees at work in their offices can be given fliers or can view posters in the hallways or closed screen TV notices in various locations in the workplace. In contrast, when they are away from their offices, there is no reasonable way for them to receive such warnings.

Similarly, when users connect their mobile computing devices to networks that are not owned and operated by their organization, their devices are normally subjected to a different set of threats from those within the organization’s network. Whereas an organization can provide security controls of its choice in its own network, it is powerless to do so in networks it does not control. In some instances, the security risk level associated with connecting to another network can be extremely high.

Consider, for example, the many severe risks (especially the threat of unauthorized capture of cleartext information in wireless connections) that are indigenous to open networks, such as those at Starbucks coffee houses and Internet cafes.

It is also possible that mobile computing users might connect to a hostile network-a network owned and operated by computer criminals. Furthermore, there is always the danger of users connecting to open wireless networks to which they have not been granted authorized access. “Piggybacking” is illegal in only a few states in the US right now, but regardless of whether an employee of an organization who piggybacks illegally is caught, the risk of the employee having done so, being detected and identified, and having news of this activity spread in the media raises the potential for negative media exposure for that organization.

Finally, mobile users often send email to others via email servers other than the ones that their organization owns and operates. This means that their email ends up being queued and stored in email servers that are not secured in the same manner than their own organization’s email servers are, providing a prime opportunity for perpetrators seeking a path of least resistance. Additionally, business-related email is out of the control of the organization when in resides on mail servers not controlled by the organization.

Mobile computing has many advantages, ones that cannot be taken lightly, and if anything, it will continue to grow at an unprecedented rate. At the same time, however, the many risks that result from mobile computing must be considered and dealt with. Unfortunately, too many organizations are neglecting the latter.

The risk of theft or of devices being lost is one of the greatest. According to recent statistics I have seen, approximately 40 percent of mobile devices are lost or stolen within two years of their purchase.

Once when I was in a hurry to catch a flight, I somehow left my laptop at an airport security screening counter. I blissfully gathered my things (except, of course, for my laptop) and went running for the departure gate. It was not until early the next day when I was supposed to start teaching a course that I noticed that my laptop was missing.

Believe it or not, I was able to get the computer back. I asked my wife to go to the airport to retrieve it. She showed identification that indicated she had the same last name and address as myself, but giving her the computer was against the rules. Instead, the airport security guards had to mail the computer to our home address. I was lucky, but a large percentage of people who did what I did are not.

Had someone stolen my laptop, that person would not have found much information of value on it. To the best of my recollection, there was almost no personal information, nor was there any kind of proprietary information. The only things of potential value were a number of course materials that I had developed. These materials could potentially be worth something to a dishonest training outfit or person. But in too many cases, lost laptops and other mobile devices result in major data security breaches that cause major financial loss as well as severe disruption and inconvenience to individuals whose data are compromised.

Blackberries, PDAs and smartphones are more easily stolen or lost than are laptop computers, and personal and/or valuable information is increasingly being stored on them. It thus appears that we have in reality only started to see the dire implications resulting from lost and stolen mobile computing devices.

At the level of mobile computing users who own their own devices, I honestly doubt that much (if anything) can be done about the risk of their devices being lost or stolen. The good news at least is that if they lose their own devices or if the devices are stolen, they usually will have lost only a piece of hardware, not personal and valuable information.

The same is not true for lost or stolen devices owned by corporations and government agencies, however, so introducing risk intervention measures here makes considerable sense.

Strangely, these entities often do little if anything to address mobile computing risk. One recent study showed that 68 percent of all companies surveyed have done nothing to make mobile devices more secure.

In short, the world sits on proverbial time bombs when it comes to many issues—world peace, the price of oil, global warning, and much more. It appears that another such time bomb is mobile computing risk, and the problem is bound to become far worse.

What I fear is that the gap between what is needed to secure mobile computing environments and the present, lamentable lack of controls has gotten so large that the problem is already far out of control.

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.

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.

]]> http://www.high-tower.com/blogs/gschultz/audit-related-issues/feed/