Active Scanner Deployment: Physical


The first step in implementing a strategy for deploying physical scanners is to select a central location to which all scanners will report in the future. In the case where there may be multiple central reporting servers, select a location with the most hosts on the local network, and preferably one that has unfettered network access to other major locations. Verify that there is sufficient bandwidth available to support a schedule structured using the method previously discussed. Then, follow this iterative process:
  1. Perform test scanning and remediation reporting on the local network where the reporting server is installed or is on another less critical network. A 24-bit classless inter-domain routing (CIDR) block would be sufficient.
  2. Review the report results and any unexpected impact on the environment.
  3. Adjust the system and scan parameters to compensate. Be sure that any adjustments you make are scalable to hundreds or even thousands of networks once the deployment proceeds.
  4. Add as many similar network ranges in the local office as possible, one at a time.
  5. Repeat the previous steps to validate the reports and impact on the environment. Adjust accordingly.
While waiting for a few cycles of this activity to complete in the local area, plan and coordinate the next phase of scanning over the WAN to other offices in the scope of your scanning strategy. These are offices that will not receive equipment but have the capacity to be scanned through their WAN connection without impact to operations. Again, repeat the evaluation and refinement process and update the scanning standards documentation accordingly.
As the expansion of scanning begins outside of the local office, begin generating and refining the management reports. At this stage, management will become quite curious about the results of the new system. Be sure that the reports are reconcilable and that questions about their content can be addressed. If the pre-acquisition testing has been done properly, this should be easily done with possibly minor assistance from the vendor. Having an executive sponsor who is willing to preview these reports before they go to a wider audience can help identify discrepancies and questions earlier.
At this point, as much as 75 percent of the initial zone of scanning should be deployed and processes beginning to take firm, repeatable shape. The next zone of deployment should then be planned by selecting another major office with as many good connections to other target offices. Then, repeat the gradual expansion process discussed in the previous steps.

Deployment Methods | Vulnerability Management



There are many ways to deploy a system, and what is needed for the operating environment will possibly affect the solution chosen. In some ways, this is related to architecture, as discussed earlier in this chapter. But, there are other considerations to be made related to how you will deploy a system. In this section, we will discuss the major issues affecting deployment.
The goal in the approach to deployment is to achieve maximum effectiveness in the shortest period of time with the least investment. Following is the basic deployment strategy to achieve this:
  1. Establish a foothold with maximum access to target systems.
  2. Test processes on a small scale and refine.
  3. Expand deployment by adding targets until the foothold is 75 percent deployed.
  4. Simultaneous to item 3, create and refine management reports at all levels.
  5. Take additional steps in other locations.
We will review each of these steps for active physical scanners, active virtual scanners, passive analyzers, and agents.

Access Control



Access control is an essential feature of any application. Depending on the infrastructure standards, it is valuable to insist on an external authentication mechanism. Roles and access rights likely will have to be defined in the VM system but external authentication should be possible.

Active Directory

Active Directory® is one of the most commonly used authentication mechanisms for Windows systems. Later versions support lightweight directory access protocol (LDAP) and LDAP over SSL for directory loading. Kerberos and NTLM are common options for authentication. Since Active Directory capabilities are so common in the corporate environment and standards are available to interface with other systems, this is a good choice. However, any LDAP directory service should work. There are two common approaches to Active Directory integration.
One method synchronizes directory information periodically, looking for additions and deletions. A copy of the directory entries is stored in the VM database for quick reference to access privileges. This is the most common and compatible approach that will use LDAP. Usually, special credentials have to be created to log into the directory system and retrieve the basic information about the users. Using LDAP also affords the system the option of portability to other directory services platforms.
Later, when a user attempts to log into the VM system, the credentials supplied by the user are sent to the authentication system using NTLM or Kerberos. Once the credentials are accepted, the VM system will apply the privileges stored in the VM database for that user.
A second approach is to natively integrate with Active Directory using the Active Directory in Application Mode (AD/AM) capability that comes with Windows .Net erver 2003. This enables the VM application to have its own instance of a directory service with schema extensions and built-in attributes but still participate in the security structure of the Active Directory domain. Naturally, the services that support this capability must run on a Microsoft-technology-based server. This provides a tightly integrated directory product for Microsoft-directory-committed organizations. A significant advantage of this approach is that Active Directory groups can be used to grant privileges in the VM system rather than creating an internal set of roles or user groups. The disadvantage is that you may be committed to the Active Directory platform.

RADIUS and TACACS+

In a more network-centric environment, RADIUS is a very common protocol option. It is an old method typically used for dial-in systems. However, the protocol is no less useful for network equipment. With RADIUS and TACACS+ , however, the user ID must be entered into the VM system since no directory service is provided. This user ID must exactly match that which is expected by the authentication server. The most significant difference between RADIUS and TACACS+ is the use of UDP versus TCP, respectively. TCP has the security advantage of being able to communicate with an authenticating source without spoofing since there is a handshake process in the protocol.
Some vendors of network authentication products go so far as to support RADIUS, LDAP, Kerberos, TACACS+, and other methods. These authentication products are able to effectively “glue” together various authorities and protocols, allowing a variety of methods to be employed.
Changing from one authentication method to another can be difficult, depending on the implementation. To avoid complications in the future, select a method from the beginning and stay with it.

Authorization

Authorization capabilities should be able to meet the various roles you have planned for operations. This is one key reason that requirements must be defined prior to beginning the RFP process. One of those requirements is a definition of who will perform what functions and what capabilities are needed. Role-based access control is the mechanism that will have to be vetted during the selection process. You should consider some of the following capabilities:
  • Separation by network: Some users will be permitted only to take actions against certain networks. Local IT personnel in Mumbai should not be able to examine any vulnerability reports for Chicago, for example. Scan parameters should not be modifiable by anyone except the VM administrator.
  • Actions: Closer to the definition of a role, there are the specific activities to be performed, such as defining a network or administering IP ranges.
  • Running reports: Many people are likely to be able to perform this function. Being able to generate a report is fundamental.
  • Conducting a scan: Few people should be able to conduct a scan. Active scanning capabilities are potentially disrupting to operations, and therefore should remain in the custody of those who are qualified to assess the impact on the network and the need for current audit results.
  • Maintaining the health of the overall system and available audit parameters: The parameters of audits should rarely be tampered with unless extensive testing has been done. Adding TCP ports or additional checks can impact the entire scanning schedule. Only a few people should be able to make changes to this. These people likely have a combination of security and compliance roles.
A good way to document authorization requirements is with a permissions grid. This grid should indicate the capabilities across the top and the roles down the side. See Table 1 for an example. Where a particular function can be performed, a “Y” or “N” is indicated. If access type is specified, then an “R” and/or a “W” are specified for “Read” and “Write,” respectively.
Table 1: Permissions Grid Example 
ROLE/CAPABILITY
REPORT
SCAN
SCHEDULE
MAINTENANCE
PARAMETERS
System administrator
N
N
Y
Y
R
Local IT
Y
N
N
N
N
Regional security manager
Y
N
N
N
N
Global security
Y
Y
Y
N
RW
Global compliance
Y
N
N
N
R

Popular Posts