Network Security Consulting Blog

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…

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…

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.

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…

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…

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…

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.

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…