Archive

Archive for July, 2010

Penetration Testing: Part 3

I keep writing about penetration testing because few activities within information security are so subject to chicanery, incompetence and ignorance. In my previous blog posting I discussed a few ways that penetration can be improperly conducted and/or written up. I’d like to delve a bit deeper into this issue, as there are so many ways to go awry when it comes to penetration testing. Read more…

Categories: Uncategorized Tags:

Penetration Testing: Part 2

In my previous blog entry I pointed out differences between vulnerability scanning and penetration testing and explained why penetration testing is a potentially more useful and valuable activity to an information security practice. But alas, some penetration tests are done better than others in that some are more systematic and thorough. One of the problems with penetration testing today is that there are no widely accepted standards for conducting penetration tests. Some individuals and organizations that conduct such tests fall far short of being very systematic and complete. One of the most common shortfalls in penetration testing is conducting penetration tests that target only certain vulnerabilities, e.g., vulnerabilities that tools such as an out-of-the-box version of Metasploit will target, but not others that could have been targeted had additional scripts been added. Penetration testers may find that a number of exploit scripts work, but will not even attempt to determine whether other vulnerabilities are present and can be exploited. In this case the write-up of the penetration test results are likely to indicate that certain vulnerabilities can be exploited and even that unauthorized root access has been obtained because of them. The tester has in all likelihood done a great disservice to the customer, however, in that no mention of the tests that were not conducted, but that should have been conducted will appear in the write-up that follows testing. The customer will probably mitigate the most serious vulnerabilities and then assume that all is well as far as vulnerability management goes. Read more…

Categories: Uncategorized Tags:

Penetration Testing: Part 2

In my previous blog entry I pointed out differences between vulnerability scanning and penetration testing and explained why penetration testing is a potentially more useful and valuable activity to an information security practice. But alas, some penetration tests are done better than others in that some are more systematic and thorough. One of the problems with penetration testing today is that there are no widely accepted standards for conducting penetration tests. Some individuals and organizations that conduct such tests fall far short of being very systematic and complete. One of the most common shortfalls in penetration testing is conducting penetration tests that target only certain vulnerabilities, e.g., vulnerabilities that tools such as an out-of-the-box version of Metasploit will target, but not others that could have been targeted had additional scripts been added. Penetration testers may find that a number of exploit scripts work, but will not even attempt to determine whether other vulnerabilities are present and can be exploited. In this case the write-up of the penetration test results are likely to indicate that certain vulnerabilities can be exploited and even that unauthorized root access has been obtained because of them. The tester has in all likelihood done a great disservice to the customer, however, in that no mention of the tests that were not conducted, but that should have been conducted will appear in the write-up that follows testing. The customer will probably mitigate the most serious vulnerabilities and then assume that all is well as far as vulnerability management goes.

Another problem with penetration testing occurs when the penetration tester is unsuccessful in exploiting any vulnerability, so this person turns to social engineering as a last resort. I do not really have an objection if social engineering is specified as an allowable or even required activity, i.e., the statement of work requires that social engineering also be conducted as part of penetration testing activity. But being unable to exploit any vulnerabilities through technical means and then without advance permission tricking one or more users into doing or saying something that compromises security is hardly any kind of triumph at all. Remember, research studies indicate that somewhere around 70 percent of users succumb to social engineering attacks. So all a customer who orders a penetration test in which penetration testers are unable to successfully exploit any technical vulnerabilities, but then is told that one or more users fell for a social engineering ploy has paid good money to learn the obvious. The customer would have done better to use part of the money used in conducting the penetration test to instead provide anti-social engineering training for users.

Another all-too-frequent problem associated with penetration tests is poorly written write-ups after testing has been completed. Let’s face it–a fairly large percentage of the most brilliant technical staff cannot write very well. Write-ups may thus be incomplete and/or difficult to understand. Some write-ups also suggest only one mitigation measure for each exploited vulnerability, again a great disservice to the customer. An effective write-up will propose alternative solutions that are available, and will provide recommendations concerning the effectiveness and cost-benefit ratio of each solution.

All penetration testing is not equal. Some providers go farther than others, yielding information and output that is of genuine value to customers. Once again, you get what you pay for.

Categories: Uncategorized Tags:

Penetration Testing: Part 1

The Free Dictionary defines penetration testing as “a test of a network’s vulnerabilities by having an authorized individual actually attempt to break into the network. The tester may undertake several methods, workarounds and “hacks” to gain entry, often initially getting through to one seemingly harmless section, and from there, attacking more sensitive areas of the network.” Read more…

Categories: Uncategorized Tags:

The Trials, Travail and Tribulations of Being a CISO: Part 4

I’ve been writing about the downsides of being a CISO, and I cannot close this series without discussing yet another significant downside–being expected to accomplish far too much with way too little resources. Nothing details all the possible roles that a CISO possibly must take on like ISACA’s CISM Exam Preparation Manual. Consider the following roles mentioned in this manual: Read more…

Categories: Uncategorized Tags:

The Trials, Travail and Tribulations of Being a CISO: Part 3

Part of the trials, travail and tribulations of being a CISO is dealing with difficult people. Unfortunately, the information security is likely to be part of an IT organization, and IT organizations are notorious for having a disproportionate number of technical staff members who are in essence “bulldozers.” Bulldozer personalities try to get their way by being aggressive towards others, expecting those they have bullied to fold under pressure. Read more…

Categories: Uncategorized Tags:

The Trials, Travail and Tribulations of Being a CISO: Part 2

In part 1 of this series I said that being a Chief Information Security Officer (CISO) is one of the least enjoyable jobs anyone could have. One of the main reasons is that information security policies and procedures generally are invasive and disruptive to people who are “just trying to get their jobs done.” But does a successful information security practice need to be invasive and disruptive to get the job done? I suspect that most information security professionals would say “yes” or “mostly yes.” According to prevailing opinion within information security, information security policies need to reflect the wishes and intent of executive-level management. Standards are in effect policies made more specific and tangible, most often with respect to prescribed technology settings and configurations. And at least in theory, effective CISOs are also the first line of enforcement for information security policies and standards. According to this line of reasoning, CISOs thus must not only create requirements, but they must also become policemen who determine whether or not their requirements are being met and put pressure on individuals and organizations that are non-compliant. It is a small wonder, then, that CISOs and their staff rapidly become so unpopular within their organizations.

Another view of the way that so many CISOs and information security practices in general have functioned for decades is that they push requirements out to employees and others such as contractors. But there is another approach to the problem–the “pull” approach. Proponents of this approach deliberately do not use any kind of a stick (most CISOs really do not have one, anyway, after all) and wait for people to come to them to help solve security problems that they face. So, for example, application programmers within a business unit might request a meeting with the CISO to discuss what to do after vulnerabilities in a Web application that was developed in-house were exploited, resulting in a major data security breach. According to the pull approach, the programmers as well as the business unit manager will now be highly motivated to not only reach out to the CISO and the CISO’s organization, but also to do what is necessary to prevent this kind of incident from occurring again in the future. Prior to the incident, however, people within the same business unit may have viewed information security standards as a royal pain in the, well, you know what. This latter approach is being used increasingly by some of the more progressive CISOs.

Admittedly, the pull approach is fraught with a few rather basic but very serious limitations, the most serious of which is that the CISO who puts this model in practice soon becomes a “fringe player.” Whereas an information security practice’s policies and standards should in theory permeate all aspects of an organization’s operations, the CISO instead reverts into a mode in which the information security function does not take the initiative in influencing how things work until called up to do so. There is no way that the CISO will become a major player in the organization. Yet at the same, too many CISOs become bona fide players, but they end of playing too negative of a role–that of a business inhibitor. Perhaps if the CISO backed off a bit, some people would be more likely to approach the CISO to obtain advice and answers they need, and in the process bolster the stock of the CISO within the organization, causing still others to also approach the CISO with their problems.

I’m not saying that the pull model is correct, but rather that it is worth considering. We have pushed and pushed for years, and in so doing, we have alienated many people and gotten the well-deserved reputation of being the security prevention department. Perhaps indeed it is time to shift our thinking and try another approach.

Categories: Uncategorized Tags:

The Trials, Travail and Tribulations of Being a CISO: Part 2

In part 1 of this series I said that being a Chief Information Security Officer (CISO) is one of the least enjoyable jobs anyone could have. One of the main reasons is that information security policies and procedures generally are invasive and disruptive to people who are “just trying to get their jobs done.” But does a successful information security practice need to be invasive and disruptive to get the job done? I suspect that most information security professionals would say “yes” or “mostly yes.” According to prevailing opinion within information security, information security policies need to reflect the wishes and intent of executive-level management. Standards are in effect policies made more specific and tangible, most often with respect to prescribed technology settings and configurations. And at least in theory, effective CISOs are also the first line of enforcement for information security policies and standards. According to this line of reasoning, CISOs thus must not only create requirements, but they must also become policemen who determine whether or not their requirements are being met and put pressure on individuals and organizations that are non-compliant. It is a small wonder, then, that CISOs and their staff rapidly become so unpopular within their organizations. Read more…

Categories: Uncategorized Tags:

The Trials, Travail and Tribulations of Being a CISO: Part 1

Being a Chief Information Security Officer (CISO) or the equivalent is one of the toughest jobs one can have. I know well at least a dozen people who currently serve as CISOs, and I have consulted for and sometimes given free advice to many of them and others over the years, For three and a half years I served as the CISO of the company for which I worked before I came to Emagined Security. I’m thus well acquainted with the trials, travail and tribulations of CISOs’s jobs.

In theory, the CISO’s job should not be so dreadful. The many costly data security breaches that have occurred over the last half decade or so has the attention of senior management; it is only natural for them to turn to the CISO for answers and solutions. Additionally, the number of information security-related statutes and regulations has grown substantially in the same period of time. Again, senior management and compliance and legal functions within organizations have frequently sought guidance and leadership from the CISO in their quest to conform to compliance mandates. Furthermore, the ever increasing flood of intrusions into government and commercial computers originating from countries such as China and Russia show that cyberespionage is a very serious and real threat. Although CISOs do not have all the answers, they generally have enough to make a real difference in the fight against cyberespionage. The CISO, the head of the information security function; should thus be widely perceived as a “go to” person within an organization.

Theory and practice do not always converge, however. In reality, the majority of the CISOs I know have a great deal of responsibility, but little authority. In many ways, information security practices are widely viewed as sources of trouble within their organizations, and in some cases as the “business prevention” function. Why? The CISO so often comes in and dutifully starts creating and/or revising policies and standards that cause staff in other areas within an organization to have to deal with new barriers and constraints. Application programmers, for example, have a hard enough time just cranking out code within imposed deadlines. Soon new security standards require that code that is developed in-house must be must revoke privileges when routines that run as the superuser are exited, must not rely on environmental variables, must not allow shell escapes, and so forth. In the mind of the application programmer, the CISO has put the proverbial straw on the camel’s back. The same is likely to be true for system and network administrators, Webmasters, operations staff, and others.

In previous blog entries I have discussed what I believe are success factors in the CISO’s job. One of the most important of these is knowing the business that the information security function is supposed to serve. I’ve previously argued that getting an MBA is now better than earning an MS in computer science, engineering, or industrial technology. Unfortunately, despite many calls for information security professionals to get business training, many have not heeded these recommendations. Too often CISOs instead work within their own little silo in which posters displaying the major areas of ISO/IEC 27001 or security-related control objectives from COBIT are hung in hallways. It would be far better to come out of the silo, put on a business hat, and display the front page of the Wall Street Journal and the major business objectives for the organization.

One thing to keep in mind is that “every victim participates in his victimization.” This old saying does not mean that every victim completely causes his or her own victimization, but rather that victims (often through inappropriate behavior, such as giving up or not being situationally aware) often contribute to the process of their being victimized. This saying very much applies to CISOs. Highly successful CISOs succeed because they bridge the gap between an information security practice and the business they are supposed to serve. They also have strong interpersonal skills. The CISO’s job may not be fun, but effective CISOs at least take some of the negativity out of the job by creating less barriers, constraints, and reasons for interpersonal conflict.

Categories: Uncategorized Tags:

The Trials, Travail and Tribulations of Being a CISO: Part 1

Being a Chief Information Security Officer (CISO) or the equivalent is one of the toughest jobs one can have. I know well at least a dozen people who currently serve as CISOs, and I have consulted for and sometimes given free advice to many of them and others over the years, For three and a half years I served as the CISO of the company for which I worked before I came to Emagined Security. I’m thus well acquainted with the trials, travail and tribulations of CISOs’s jobs. Read more…

Categories: Uncategorized Tags: