The specific approach used to identify the scope of the testing effort is very dependent on the size of the task and the culture of the organization, as the following scenarios illustrate.
Hotel Chain
A small hotel chain has decided to place its Web site (the originally stated target of the testing effort) on a handful of servers, which they own and administer, at an off-site facility owned and managed by their ISP. On occasion, the Web application running at this site needs to upload new reservations and download revised pricing structures from the organization's legacy reservation processing system that resides on the corporate network. The Web application and legacy reservation system communicates via the Internet. Access to the corporate network is via the same firewall-protected Internet connection used by the
hotel chain for several other Internet services (such as employee emails and Internet browsing). Figure 3.3 illustrates this configuration.
Figure 3.3: Hotel chain configuration.
Communication between the Web site and corporate network is via a firewall. Therefore, it would not be unreasonable to restrict the scope of the Web site security-testing effort to that of the two network segments that the hotel chain administers at the ISP facility (a demilitarized zone [DMZ] and back-end Web application). On the other hand, had the communication to the legacy system been via an unfiltered direct network connection to the corporate network, it would have been hard to justify not including the corporate network in the scope (unless it was covered by another testing project). A security breach at the corporate network could easily provide a back-door method of entry to the Web site, circumventing any front-door precautions that may have been implemented between the Web application and the Internet.
Furniture Manufacturer
A medium-sized furniture manufacturer has decided to develop its own Web application in house using contracted resources. Its entire Web site, however, will be hosted at an ISP's facility that offers low-cost Web hosting-so low cost that parts of the Web application (specifically the database) will be installed on a server shared with several other clients of the ISP. Assume that the ISP is unwilling (or perhaps unable) to provide the furniture manufacturer with the schematic of its network infrastructure and that it would not appreciate any of its clients conducting their own, unsolicited security assessments. The furniture manufacturer should restrict its security-testing activities to testing the in-house- developed Web application using its own test lab. The risk of the production version being attacked physically or via a system software vulnerability would be mitigated by requiring the ISP to produce evidence that it has already tested its infrastructure to ensure that it is well defended. Ideally, some form of guarantee or insurance policy should back up this assurance.
Accounting Firm
A small accounting firm, whose senior partner doubles as the firm's system administrator, has hosted its Web site on the partnership's one-and-only file and print server. (This is a questionable decision that the security assessment process should highlight.) This server is accessible indirectly from the Internet via a cheap firewall appliance and directly from any one of the dozen PCs used by the firm's employees. Figure 3.4 illustrates this configuration.
Figure 3.4: Accounting firm configuration.
Because of the lack of any interior firewall or other devices to prohibit accessing the Web site from a desktop machine, the Web site is only as safe as the least secure PC. (Such a PC would be one that, unbeknownst to the rest of the firm, has a remote-access software package installed upon it, so the PC's owner can transfer files back and forth from his or her home over the weekend.) Such a situation would merit including all the PCs in the scope of the security assessment or suspending the security testing until an alternate network configuration is devised.
Search Engine
A large Internet search engine Web site uses several identical clusters of servers scattered across multiple geographic locations in order to provide its visitors with comprehensive and fast search results. The Web site's LAN administrator is able to provide the testing team with a list of all the network segments used by the distributed Web site, and the devices connect to these different segments.
Because of the size of this security assessment, the testing team may decide to break the assessment up into two projects. The first project would concentrate on testing a single cluster of servers for vulnerabilities. Once any vulnerabilities identified by the first project have been fixed, the second phase focuses on ensuring that this previously assessed configuration has now been implemented identically on all the other clusters.
The Test Lab
An area that is often overlooked when deciding upon what should be covered by a security- testing effort is the devices and network segment(s) used by the testing team itself to test a nonproduction version of the system. Typically, these environments are referred to as test labs. If they are connected to the production environment or to the outside world (for instance, via the Internet), they might pose a potential security threat to the organization unless they are included in the security assessment.
Test labs are notorious for having weak security. They are therefore often the target of attackers trying to gain access to another network segment using the testing lab as a stepping stone to their ultimate goal. The following are just two of the scenarios that have contributed to this reputation. Test lab machines are often reconfigured or reinstalled so frequently that normal security policies and access controls are often disregarded for the sake of convenience. For example, very simple or even blank administrator passwords might be used because the machines are constantly being reformatted, or protective software such as antivirus programs are not installed because they generate too many false alarms during functional testing and potentially skew the test results obtained during performance testing. Secondly, minimum access controls are used in order to make automated test scripts more robust and less likely to fail midway through a test because the testing tool did not have sufficient privileges.
The scope of the security assessment should therefore always explicitly state whether or not a system's associated test lab is included in the testing effort and, if not, why it has been excluded. All too often, these test labs' only line of defense is the assumption that no attacker knows of their existence; solely relying on a security-by-obscurity strategy is a dangerous thing to do.
Suspension Criteria
If, during the scoping of a security assessment, clearly defining a testing scope proves to be completely impossible, then it might be wise to temporarily suspend the testing effort until this issue can be resolved. Such a situation could have come about because the information needed to make an informed decision about the network topology could not be obtained. This could also occur because the topology that has actually been implemented appears to allow such liberal access between multiple network segments that the size of security assessment needed to ensure the security of the network would become too vast, or if it is restricted to a single segment, it could not ensure the security of the segment because of the uncertainly associated with other adjacent segments.
Alternatively, a huge disclaimer could be added to the security assessment report stating that someone else has presumably already thoroughly tested (or will soon test) these adjacent segments using the same stringent security policies that this testing project uses. This so-called solution ultimately presents a lot of opportunity for mis-communication and potential finger-pointing at a later date, but may also provide the impetus for convincing management to devote more time and energy toward remedying the situation.