The techniques involved in conducting preliminary research and infor-mation analysis can be found in various chapters throughout this book.
Here I discuss the subject purely from the perspective of comprehension and planning.
PROJECT PLANNING AND WORKFLOW 19
Preliminary intelligence gathering can broadly be categorized into the areas in the following list. Given that your goals usually (though not neces-sarily) revolve around gaining access to corporate or government facilities, the sort of intelligence you gather must further and support these ends:
• Human Intelligence (HUMINT) – intelligence gathered directly from human sources;
In general, HUMINT refers to privileged, although not necessarily classified or formally confidential, information obtained from insiders under false pretences. The act of gathering such information is referred to as social engineering and it’s an important enough subject to be treated on its own (see Chapter 4). The skilled use of human intelligence gathering will give the operating team a considerable edge when penetrating any organization.
• Signals Intelligence (SIGINT) – intelligence gathered through the use of interception or listening technologies;
Breaching site-wide wireless networks from outside the target core is a form of SIGINT that you might consider using during the preliminary phase. However, in general, this is likely to be secondary to other forms of intelligence gathering in the preliminary phase (unless the target has extremely insecure or exposed communications). After physical security borders have been crossed (referred to as moving from PRIME to CORE), signals intelligence becomes more important as network links and short-range wireless technologies become available.
• Open Source Intelligence (OSINT) – intelligence that draws on infor-mation from public sources;
These sources are most likely to be found either on or via the Internet. Employee information, for instance, is particularly useful when engaging in pretexting and other forms of social engineering.
• Imagery Intelligence (IMINT) – intelligence gathered through rec-orded imagery, i.e. photography.
If possible, photographs of the target site and possibly staff should be acquired in the preliminary phase, depending on the nature of the engagement. The value of good photographic intelligence can-not be understated and its benefit will become increasingly apparent throughout this book. Historically, IMINT also refers to satellite intel-ligence; however satellite imagery is a cross over between IMINT and OSINT as far as it extends to Google Earth and its equivalents.
Determining Risk
Ultimately, it is the team leader’s responsibility to determine what con-stitutes an acceptable level of project risk. If the team leader feels the level of risk is too high then the RoE should be reassessed or the test
20 PLANNING YOUR PHYSICAL PENETRATION TESTS
should not be carried out. Risk in physical penetration testing can be expressed in a number of ways but can be broadly categorized into the following areas, which are linked and overlapping – no risk exists in a vacuum – contractual, operational, legal and environmental risks. Enthu-siastic project managers will notice this provides you with a convenient acronym – COLE.
• Contractual Risks – Contractual problems usually occur when the testing company has bitten off more than it can chew and the team’s ability to deliver the assignment falls short of its contractual obliga-tions. This is a common but avoidable problem. To put it another way, because an inadequately prepared and poorly trained team has been unable to complete an assignment does not necessarily mean that the client is secure. This is a common thread throughout all spheres of vulnerability assessment, but particularly in physical pen-etration testing as failures tend to be more apparent. Never take an assignment that you don’t believe you can complete or that cannot be completed.
• Operational Risks – These are inadvertent or unforeseen problems during the execution of a test that, at best, lead to difficulty completing the assignment and, at worst, to an aborted mission. Operational risks are usually predictable with a little forethought and are, therefore, avoidable. Examples include:
• Communications breakdown due to human or technical failure.
• Inexperienced team members misinterpreting instructions or goals.
• A failure to assess correctly the difficulty of achieving an initial milestone leading to subsequent meltdown.
• Legal Risks – A project may incur direct or indirect legal risk.
Team members may be put in a position that could directly lead to their arrest. This may happen when an overly enthusiastic security guard circumvents procedure and directly involves law enforce-ment; when someone believes a team member is acting suspiciously and calls the police; or when team members are directly appre-hended by the police, for example, during a night-time penetration exercise.
During a black box test, the scope may be operationally exceeded, sometimes catastrophically. An example of this is penetrating the wrong facility or business. Don’t laugh; this happens, particularly in shared premises. Imagine the embarrassment of hacking the wrong wireless network or of hearing that a team member (possibly lack-ing in basic math), has climbed through the wrong window into a neighboring business’s board room. At the very least, this may involve explaining to a judge that you accidentally broke into the wrong building. Such mistakes are invariably expensive.
PROJECT PLANNING AND WORKFLOW 21
• Environmental Risks – These are physical hazards your team may encounter during testing that can directly affect the health and safety of team members. Such risks vary widely depending on the engagement but consider, as a minimum, the inherent dangers of the following:
• working at night or in the dark;
• working near large bodies of water;
• working in the presence of machinery or high voltage;
• climbing and falling;
• being attacked by guard dogs;
• working in extremes of heat or cold;
• climbing barbed or razor wire or electric fencing;
• confronting armed security.
A team leader should never knowingly put his people in harm’s way.
A number of sites, in North America and elsewhere, make use of armed security. In such circumstances, there is an inherent risk of injury or death to any personnel assigned to the operating team. The liability involved for all parties is tremendous. Personally, I do not recommend accepting work in circumstances where firearms are routinely issued to security staff; they may be brought to bear before individuals have an opportunity to identify themselves.
One of the problems inherent in physical penetration testing is achieving a realistic assessment of the client’s exposure. An operating team is limited in time and scope; an attacker is not. Environmental risks further impinge on your ability to gauge the vulnerability an organization faces because clients will be unwilling to sign off on tests they perceive as carrying a possibility of harm to the tester, which in turn may result in the client being sued.
Writing a Test Plan
Having completed the previous steps, you are now in a position to draft the test plan. In the example shown in this section, I have kept the language deliberately loose to ensure maximum compatibility with your own project management methodologies.
The test plan is divided into three sections that detail the agreed upon engagement plan from different viewpoints or layers of resolution:
• Strategic – This is a very high-level view of the project that details the goals, assets, team members, potential COLE risks, and necessary
22 PLANNING YOUR PHYSICAL PENETRATION TESTS
equipment. An outline of the project background and history can also be included here.
• Tactical – Given the strategic goals, this section creates a list of milestones or mini-goals and the order in which you believe they should be completed.
• Operational – This section defines in detail what is required to complete each milestone and how its completion will affect the engagement as a whole.
It’s far more illustrative at this stage to look at an example test plan and see how this theory is applied. As you can see, a testing plan does not need to be huge. Actually, it is best to keep it as short and clear as you can.