|An intrusive third-party : SC Magazine : Blog : Home|
First Published: SC Magazine September 2004
When meeting and discussing with clients their security assessment requirements, it is import to observe the language used to describe the various stages of the future engagement.
Some clients will refer to ‘passive’ and ‘active’ phases of testing, while others will refer to ‘non-intrusive’ versus ‘intrusive’. Although it is easy to make one-to-one comparisons between the two nomenclatures, there are a number of nuances that can be a source of misinterpretation. Failure to clarify the language, and consequently the purpose and objectives of each assessment stage, can result in a failure to deliver upon expectations.
The reference to ‘intrusive’ in a security assessment can mean anything from being observable above and beyond normal day-to-day network traffic, through to having a noticeable effect on an organisations network traffic or hosted services (such as denial of service attempts). Obviously, it is critical to clarify just how intensive any testing is going to be, and to agree at the start of the engagement the bounds of the intrusive stage.
While the same applies to ‘active’ testing, I have found that the most frequent difference between ‘active’ and ‘intrusive’ testing is directly linked to the actual exploitation of vulnerabilities and hacking into systems. In general, clients who refer to ‘intrusive’ testing wish to partake in a full ethical hacking experience.
Things are seemingly more clear-cut between the references to ‘passive’ or ‘non-intrusive’ assessment stages.
To most of my clients, ‘passive’ refers to information gathering techniques that will not require any direct access between the consultants “attacker” host and their organisations Internet services – and is largely limited to the listing and categorisation of leaked information (e.g. domain registration records, newsgroups and web-cache searching).
‘Non-intrusive’ tends to refer to any data exchange or security test that is not likely to be noticed a detected, and is not commonly referred to as an attack. This type of testing is the most subjective. It is highly dependant upon the consultants’ estimation of the background Internet traffic “noise” level for the client, and what constitutes a real attack.
In many cases there are multiple ways of obtaining the same security information and some of these may bridge the divide between ‘intrusive’ and ‘non-intrusive’. It is for this very reason that pre-engagement consultation is required to agree upon the final testing methodology.
A classic example is the Zone Transfer. It is generally accepted by the security community that DNS systems allowing zone transfers to unrestricted Internet hosts pose a security risk. Therefore, testing to see if a DNS server allows zone transfers is a valid security check.
To carry out a zone transfer, a remote host must connect to the DNS server and construct a specific request to initiate the process. For many organisations, any unauthorised attempt to carry out a zone transfer should be seen as (or likely to lead to) an attack. Thus, from a security assessment perspective, the process of checking for this vulnerability is seen as ‘intrusive’ and part of an ‘active’ testing plan.
However, there exist an increasing number of websites that make available online tools that can be used to conduct sophisticated security checks. These online tools offer free (and anonymous) services such as full analysis of DNS server configuration, mail server configuration, and extensive port scanning or banner checking facilities.
Therefore, in the context of conducting a ‘passive’ test, a consultant can test for (and carryout) zone transfers without directly connecting to the organisations DNS servers. This is important as not only has the line become blurred between ‘passive’ and ‘intrusive’ testing, but it is important to note that these facilities are available to any person over the Internet.
I believe that the use of these online tools is a valuable part of any ‘passive’ security assessment stage as by using them two purposes are served. Firstly, these tools are so common, that any valuable information they provide (whether perceived as an attack or not) must be analysed and included in an authoritative security report. Secondly, it is highly likely that these tools will be used against an organisation for pre-attack reconnaissance and it is important that the organisation understand how to prevent or respond to them.
Because of these ambiguities in nomenclature and the various methods of carrying out tests during a security assessment, it is vital that both the security consultant and the organisations technical team fully agree upon the scope and method of testing. In most cases the onus is upon the security consultants to communicate the significance of different testing methods and the context in which the security information can be obtained.
(1) When reviewing a Request for Proposal (RFP) or similar document, ensure that the terminology and expectations are clearly defined.
(2) Before starting a security assessment, ensure that all sides fully understand the scope and consequences of any ‘intrusive’ or ‘active’ testing. Be clear when discussing the objectives of the assessment.
(3) Discuss the perspective the deliverables (such as final reports) should have.
(4) Ensure that any deliverables elaborate upon the scope and type of testing conducted.
(5) Clearly identify the source or methods used to obtain the security information.