Agent Architecture | Vulnerability Management

Agents typically execute one or more services in the background of a system with system privileges sufficient to carry out their purposes. These services normally consume very little CPU resources except when requested to perform a major task. Usually, at least two services are running at any given time with other active services, depending on the architecture of the product. Vulnerability assessment agents are inextricably linked to the audit of the target, whereas appliances can be used for more than one audit method.

As shown in Figure 1, one service listens on the network for configuration and assessment instructions from a controlling server. This same service or an additional service may be used to communicate assessment results back to the server. The second service is one that performs the actual vulnerability assessment of the local host and, in some cases, adjacent hosts on the network.

Figure 1: Agent architecture.

The basic kinds of agents include the following:

• Autonomous: They do not require constant input and operation by another system or individual.
• Adaptive: They respond to changes in their environment according to some specified rules. Depending on the level of sophistication, some agents are more adaptive than others.
• Distributed: Agents are not confined to a single system or even a network.
• Self-updating: Some consider this point not to be unique to agents. For VM, this is an important capability. Agents must be able to collect and apply the latest vulnerabilities and auditing capabilities.

A VM agent is a software system, tightly linked to the inner workings of a host, that recognizes and responds to changes in the environment that may constitute a vulnerability. VM agents function in two basic roles. First, they monitor the state of system software and configuration vulnerability. The second function is to perform vulnerability assessments of nearby systems on behalf of a controller. By definition, agents act in a semiautonomous fashion. They are given a set of parameters to apply to their behavior, and carry out those actions without further instruction. An agent does not need to be told every time it is to assess the state of the current machine. It may not even be necessary to instruct the agent to audit adjacent systems.

Unlike agents, network-based vulnerability scanners are typically provided detailed instructions about when and how to conduct an audit. The specifics of each audit are communicated every time one is initiated. By design, agents are loosely coupled to the overall VM system so they can minimize the load and dependency on a single server.

The method of implementation involves one or more system services along with a few on-demand programs for functions not required on a continuous basis. For example, the agent requires a continuous supervisory and communication capability on the host. This enables it to receive instructions, deliver results, and execute audits as needed. Such capabilities take very little memory and few processor cycles.

Specialized programs are invoked as needed to perform more CPU-intensive activities such as local or remote network audits. These programs in effect perform most of the functions found in a network vulnerability scanner. Once completed, the information gathered is passed onto the supervisory service to be passed back to the central reporting and management server.

The detection of local host vulnerabilities is sometimes carried out by performing an audit of all configuration items on the target host in a single, defined process during a specific time window. An alternative approach is to monitor the configuration state of the current machine continuously. When a change is made, the intervening vulnerability assessment software evaluates the change for vulnerabilities and immediately reports the change to the management server. This capability is intertwined today in the growing end point security market. The detection of configuration changes and added capability of applying security policy blurs the relationships among end point protection, configuration compliance, and vulnerability audit. This combination will ultimately lead to tighter, more responsive security.

Hardware: The Appliance Model

The hardware appliance model is exactly that: hardware with built-in software to perform the desired vulnerability scans. The devices are typically placed throughout a network and report back to a central server. The scanning appliances are usually complete but simple computer systems. A typical design has an operating system (OS), supporting software modules, and the specialized code written by the developers to perform scans and communicate results. Some vendors use open-source tools and others will use a commercial OS and components.

One major advantage of a hardware-based system is that the vendor will have in-depth knowledge about the configuration of the host. The vendor takes responsibility for the maintenance and stability of that configuration. Any failure of the software to perform as advertised should be addressed in the client–vendor relationship.

In deployment, the hardware approach has the disadvantage of having to be shipped to the location and installed by someone who may not be qualified to do so. In most cases, however, deployment is not so complex. If the local technologist can configure a typical host computer, he or she can configure a vulnerability scanner. If you are uncertain about the capabilities of local personnel, then you may be well-advised to preconfigure the device and provide simple installation instructions.

In most designs, each scanner will report back to a central server. The vulnerability and compliance information collected will be transmitted back to the server for analysis and reporting. Devices will also receive assessment instructions over the network. Those instructions may be delivered by polling, on-demand connection, or through reverse polling. The impact of these strategies will be minimal but important, depending on your network security architecture.

Polling is the process of taking a poll of the vulnerability scanners associated with a central server. Each scanner is typically contacted through a TCP port with special authentication methods that keep the entire conversation encrypted. The devices that are polled may be only those for which the server has a job prepared or in progress. The server checks the status to see if any data is available or if the unit is ready to accept a job. This approach can be cumbersome but has the advantage of only requiring a connection originating from the server. In some cases, not all scanners are polled unless there is scheduled work that can result in not knowing the status of a scanner until that time. Most vendors that poll will poll all scanners. Figure 1 illustrates the simple polling approach.

 
Figure 1: The simple polling approach.

Reverse polling is the process whereby each scanner contacts the server on a regular basis. Should there be a job scheduled for the scanner, it would then be provided. The same strong authentication and encryption methods apply. The scanner will send the results of the scan back to the central server either during the scan or at the conclusion, depending on the software designer’s choice. This approach has the added advantage of allowing the scanner to complete a local job even if the connection with the server is lost. The scan results may simply be cached until a connection can be re-established.

Reverse polling also has an advantage when deployed in a secure zone where in-bound communications to the scanner may be undesirable in order to limit possible external connections. This is also a disadvantage should the scanner be deployed outside the organization’s boundaries because accommodations must be made in the security infrastructure for connections from the scanner.

Compliance and Governance | Vulnerability Management

Eventually, the progress in remediation has to be monitored by someone to maintain good governance. In an organization of less than 10,000 hosts, it is often sufficient for this individual to be the person responsible for scanning. However, in larger organizations, it is preferable to have a compliance group perform this function. Additionally, Compliance would monitor the configuration and operation of the system on a regular basis.

Figure 1 shows how the compliance organization uses the current operations documentation, process documentation, and scan results to verify compliance. These three pieces of data have an important relationship. Operations documentation tells the compliance group what activities were undertaken by the VM group. Compliance should verify that VM activities are conducted in accordance with policy.

 

Figure 1: Compliance data flow.

Process documentation defines in unambiguous detail the steps to perform the VM function. It is against this documentation that the compliance function will verify the operations activities and supporting output documents. The process documentation itself should be checked against policy to assure conformity. In some cases, this step is not necessary in the compliance monitoring function because compliance may be a part of the creation of the VM process. In that case, an external audit is occasionally warranted.

Finally, the scan results data is detailed in reports from the vulnerability scans. These reports should reflect the level of compliance achieved by each IT group responsible for remediation. Later, we will discuss in some detail the content of these reports and their relevance in a mature, successful VM program.

1 System Audit

Another critical step in the governance of VM is auditing. During an annual audit of security mechanisms, it is advantageous to have an external party review the configuration and operation of the system. The elements of any audit should include the following:

• Process: Auditors should verify that there are no critical flaws in the scanning, remediation, and verification processes. The auditor should provide recommendations on improvements.
• Scope: With an understanding of the structure and application of existing network segments, auditors must verify that a complete and appropriate set of targets is scanned. Depending on the program charter and policy, the list of targets may include vendors or business partners. In addition to existing targets, it is important to recognize that organizations, systems, and networks are dynamic. Changes to the environment will change the scope of scan targets. Processes and configurations of scanners should be sufficient to adapt to this changing environment.
• Training of operators: Those working on the technical details of the system must be sufficiently well-versed in its operation. Not only must they understand operations, they also have to understand how vulnerabilities work, the threats associated with them, and the risks posed to a company realizing those threats. Knowledge of operating systems, networks, protocols, and various relevant applications is highly desirable.
• Policy alignment: Do the VM operations align with current policy? As we discussed earlier, VM processes are derived from policy, which is derived from program charter or business objectives. Over time, policy can drift and no longer meet the program requirements. This is not through negligence but a natural tendency of individuals to adapt to a changing environment without the perspective of overall impact to the program charter.

As circumstances gradually change in networks and systems to respond to the changing business environment, the business needs will no longer be reflected in the policy. For example, the business may typically sell its products through personal sales contacts. Therefore, there are no policies regarding proper use of encryption or handling of customer financial data. Then, they discover untapped markets that are accessible online. The current policy may state that electronic payment data must be exchanged through bank transfers and not through company systems. However, in the newly adopted online sales model, customers provide payment information, which is handled by company computer systems. Now, numerous vulnerability and compliance issues in encryption, network design, and system configuration arise. Since the policy has never been amended, it is difficult to discover and remediate compliance problems in these systems. Furthermore, the systems in question may be out of scope for VM altogether.