Technical Data Collection

Objective: To obtain information through different technical and empirical methods in order to obtain representative samples of systems and devices across the organization.

The information collected in the previous phase will be analysed to identify the systems in need of attention. A set of technical tests will then gauge their actual level of technical security, detecting existing and potential security problems that may affect the integrity, operation or performance of the systems in the organization.

Following is a list with the points to be covered during the technical collection of information.

List and Characterization of data

The information collected during the General Data Collection phase will highlight the systems, devices and applications in need of attention. An exhaustive description of each element is essential as they will be the basis of the technical analysis and results evaluation.

The minimum information that should be collected is listed next (but could be extended to other information that the data collection team may consider of interest):

Systems Characterization

• System (name, type, vendor)
• Location
• Person(s) in charge
• Software versions (OS, applications)
• State of patches and updates

Applications Characterization

• Application (name, version, vendor)
• Associated subsystems (systems the application runs in)
• Links with other applications
• Person(s) in charge
• State of patches and updates

Traffic Analysis

Traffic analysis determines the type of traffic through the organisation networks and detects possible failure points or bottlenecks in these networks.

For an optimal result of the analysis, key measure points across the network should be identified. Typically these points include:

• Segment interconnection
• Critical applications/server segments
• User segments
• Other points of interest

Each measure should be taken for a period of time so an appropriate amount of traffic is captured for later analysis. The measure time will depend on the amount of traffic the network handles per unit of time. In some networks a measure held for several minutes is enough, while in others it is necessary to take the measure for a whole day or even longer periods.

Time patterns of network use also need to be considered in order to select appropriate times to capture traffic. For instance, the capture of traffic will be different in an office network and in the network of a factory open 24 hours a day.

Captures will be taken with no filters (using a suitable protocol analyser), stored on disk in order to be replayed and analysed in the laboratory. The information can then be used in reports and statistics of use.

Systems and Applications Vulnerability Assessment

The aim of the applications and systems vulnerability assessment is to detect weak security points. Weak points are programming or configuration errors in applications and in the operating system whose vulnerability may potentially be exploited by attackers. Therefore, it is important to identify those weak points in order to eliminate them or avoid its exploitation.

Not every system has the same importance for the organization. For this reason, and also because the vulnerability assessment is time-consuming, it needs to be selective. Typical objectives of this analysis are malfunctioning systems that have an important impact in the key processes of the organization (i.e. main servers) or those whose visibility makes them more exposed to a possible attack (i.e. servers with public access from the Internet). The selection of such systems is a responsibility of the organization, with support from the assessing team.

Remote Analysis

Special attention will be paid to vulnerabilities that may be exploited remotely and therefore do not require physical presence for that, as they will pose a bigger risk. These vulnerabilities are usually linked to application ports waiting for remote connections. Therefore, the first step in the vulnerability assessment is to identify the ports in the systems that can be accessed remotely, using, for instance, port scanning.

The aim of port scanning is to find out which ports (normally TCP or UDP ) are listening in a given system, and therefore are able to receive remote connections. This information is of the utmost importance, since most of the application vulnerabilities are related to handling of remote connections. The basic technique to find out the state of a port is to attempt connecting to it and to analyse the result. Typically, there are three different states for a port:

• Open: The port is listening and ready to receive connections.
• Closed: The port is not listening.
• Filtered: There is a device (usually a firewall) that does not allow connections to the port.

There are different scanning techniques, most of them oriented to avoid detection controls in the target systems. This type of techniques may not be relevant in our case because we should have written authorisation from top management to execute the actions related to remote analysis, so there is no need to use stealth techniques except perhaps in cases where intrusion detection systems are present and could make void the test results.

Once defined the scope of the systems to be analysed, we can select its depth. That is, we decide which set of ports are going to be scanned. Obviously, a complete analysis should check the state of every TCP and UDP port. However, in some cases it could take more time than it is available, or else we have the certainty that a given device is listening in just some ports. Only then it is possible to reduce the set of ports to analyse, which will decrease the complexity and time of the scan.

Scanning the ports will provide accurate information about available ports in each system that accept remote connections. Each one of these ports is linked to a service, and consequently to an application. The next step is to find out those applications and, if possible, their versions.

Knowing the exact software installed in a system is one of the first tasks that a potential attacker will carry out, because with this information it is possible to find out the existing vulnerabilities in the remote access applications, and therefore to execute exploitation methods. The result of the execution of an exploit usually puts the system at jeopardy in the form of illegal access to data or even their destruction.

Software identification from the ports in listening state can be made using the answers (banners) that the service gives after an incoming connection. Nevertheless, since it is convenient to modify this information in order to confuse potential attackers, another way has to be found to carry out the applications identification. There are multiple tools, most of them open source, that can automate the identification of applications linked to listening ports. These tools not only recognise the banners, but also analyse the answers to certain inputs and identify, with a variable degree of accuracy, the application and version running in the system, based on differences in the implementation of the protocol among applications.

This process (scanning + identification) is the usual way a possible attacker would work, so it is important to carry it out in order to know what kind of information could be obtained by this means. However, from the point of view of security analysis, and with the aim of being certain about the accuracy of the results obtained, the identification of applications and its versions should also be carried out by traditional means such as local analysis of the systems in question.

At this point, a possible attacker could query some of the multiple online services about applications, its vulnerabilities and the exploits of a given version. Therefore, the team's job is to find out the patches or appropriate upgrades to solve the security problems of the application. In the event that there are no patches or upgrades or these cannot be deployed, alternatives to decrease the level of risk or exposure of the applications are searched.

Nowadays, the communication networks where the analysed systems are located are not plain. It is common the existence of different segments, separated by different devices and with different access policies. For that reason, the vulnerability assessment will produce different results depending on the place where it is launched from. Taking this into account, the validity of the results is assured if the analysis is executed from every possible location that could be taken by a potential attacker, thus obtaining different profiles of visibility (and of course of risk exposure) of the analysed system.

The analysis is typically executed from the following locations:

• Internet: only the public services of the organization are reached from the Internet. This analysis will determine that these and only these services are publicly accessible.
• DMZ: in the event that several DMZ segments are present in the organization, the analysis is executed from every DMZ towards the internal servers of the organization. The reason for doing this is that DMZs are a typical entry point for attackers once they have exposed a public server, so the analysis reveals the degree of visibility that internal servers have for an attacker that has already jeopardized some of the systems of the organization.
• Same Segment: scans from the same network segment where internal servers are show, without physical access to the system, both the services that the system has running and those ones that are running but are not being used due to bad administration practices or default installations.
• Internal Network: since an important amount of security incidents originates from inside the organization, it is necessary to know which services are accessible (and therefore a possible source of vulnerability) from the internal users' networks.

Local Analysis

Although it is not usually available to potential attackers, the local analysis allows us to obtain an accurate knowledge about the state of security in the system by characterizing it exhaustively.

At least, the following information should be collected:

Name
Person(s) in charge
Type of system
File systems
Memory usage
Patches and updates
Software and applications installed
Listening ports and active connections
Service Banners
Services
Boot scripts
Processes in execution
Users and passwords
Network configuration
Periodic tasks

Additionally, depending on the operating system of the analysed system, it may be necessary to collect more data, in which case an expert in that area will identify them. In Unix systems, for instance, data like tcp wrappers, suid and sgid files, NFS services or RPCs should be collected.

Configuration Review

During the technical collection of information, configuration files of key elements in the network are also reviewed. In many cases, due to the high number of devices in the network, it is not possible to carry out an exhaustive review. It is then necessary to select, in accordance with the organization representative, the key devices whose configuration will be reviewed.

This configuration review requires the participation of experts in the devices analysed, in order to identify configuration failures, more efficient configurations or alternatives that may improve the security and efficiency of the device.

A typical review includes, at least, network devices (routers, switches, bridges, etc.), security devices (firewalls, IDS/IPS, Authentication Servers), applications (web, FTP, mail servers, etc.) and any other device that may be a source of vulnerabilities and therefore of an increased risk level in the organization.

External Visibility

There is a large amount of information about organizations which is available to the public from the Internet. This information may become a key part in the design of an attack plan against the organization, because it can reveal interesting technical and organizational details that may facilitate the job of potential attackers.

Hence the importance for the organization to be conscious about the existence of this information, especially in the following aspects:

Public Addressing

Using whois services from regional registrars of the Internet (i.e. RIPE in Europe, ARIN in North America) reveals the public addressing ranges allocated to an organization, as well as postal and e-mail addresses, telephone numbers and names of contact persons inside the organization.

The organization needs have an accurate knowledge of this information in order to be sure that the data are correct and can not reveal sensitive information.

Domain Names and DNS

Every domain name belonging to the organization needs to be collected, since information about technical, administrative and billing contacts can be obtained through the domain registrar.

For each domain belonging to the organization DNS queries are made paying special attention to:

• Name Servers (NS)
• Mail Exchangers (MX)
• Known names (e.g. www, ftp)

These names correspond to servers that can be attacked, so they need to be carefully hardened against possible attacks.

Documentation Filtering

A wrong configuration in the corporate web servers may disclose internal information through the Internet. Today's web crawlers (i.e. Google) allow the user to execute sophisticate queries -for example restricted to a given domain and file type. It is always surprising the amount of information that can be obtained by this means. This type of queries need then to be executed as part of the technical data collection, to determine whether the organization is vulnerable to this kind of attacks and to identify its root cause.

Other Technical Analyses

Depending on the technical features of the organization's infrastructure, it may be necessary to execute extra tests to collect additional information. These tests should be coordinated by the evaluation team and experts on the system or application under test.