アセットの発見の設定には3つのオプションがあります：
カスタム・スキャン・テンプレートでアセットの発見を設定しないことを選択する場合、スキャンはサービス発見で開始されます。
ターゲットアセットがライブであるかどうかの判定は、追跡が困難である程大量のアセットを含む環境で、有用となる可能性があります。スキャン作業から廃れた（デッド）アセットをフィルタリングで取り除くと、スキャン時間とリソース消費量の削減に役立ちます。
アセットにコンタクトするには3つの方法があります：
潜在的なマイナス面は、ファイアウォールやその他の保護デバイスが発見接続リクエストをブロックして、ターゲットアセットがライブであるにも関わらずデッドであるように見える可能性があるということです。 ファイアウォールがネットワーク上にある場合、リクエストをブロックする可能性があります。理由は、特定基準を満たす全パケットのネットワークアクセスをブロックするよう設定されているため、またはすべてのスキャンを潜在的攻撃であると認識するためのいずれかです。どちらの場合も、スキャンログで当該アセットはDEADと報告されます。これにより、スキャンの精度が全体的に落ちる可能性があります。スキャン・エンジンをどこに配備し、スキャン・エンジンをファイアウォールとどのように連動させるかに注意を払ってください。「スキャンに適した」環境を作るをご参照ください。
1つ以上の発見方法を使用すると、結果がより正確になります。アプリケーションが1つの方法でアセットをライブであると検証できなかった場合、別の方法へと戻ります。
注意: ウェブ監査とインターネットDMZ監査のテンプレートには、これらの発見方法は含まれていません。
通常、周辺ネットワークには非常に積極的なファイアウォールルールが敷かれているため、アセットの発見の効力が鈍くなります。そこでこの種のスキャンについては、ターゲットアセットがライブであると「仮定」してスキャンの次のフェーズであるサービス発見に進むことが、より効率的であるといえます。この方法には時間がかかります。なぜなら、ライブであるかないかに関わらず、すべてのターゲットアセット上のポートについて、アプリケーションによるチェックが行われるからです。利点は、考えられ得るすべてのターゲットをチェックするため精度が高いということです。
デフォルトでは、スキャン・エンジンはECHOリクエスト（またはping）と呼ばれるメッセージタイプを含むICMPプロトコルを使用して、デバイス発見中にアセットを探し出します。ファイアウォールはpingを破棄する可能性があります。理由は、特定基準を満たす全パケットのネットワークアクセスをブロックするよう設定されているため、またはすべてのスキャンを潜在的攻撃であると認識するためのいずれかです。どちらの場合もデバイスは存在していないと推測され、スキャンログ内でDEADとして報告されます。
注意: デバイス発見にTCPとUDPの両方を選択すると、プロトコルが1つの場合より多くのパケットが送信されますので、より多くのネットワーク帯域幅が消費されます。
TCPおよび/またはUDPを、ライブホストを見つける追加/代替のオプションとして選択可能です。これらのプロトコルを利用して、アプリケーションは接続を開いてアセットがオンライン上に存在するか検証を試みます。ファイアウォールはウェブサービスをサポートするデフォルトHTTPポートであるため、多くの場合、ポート80のトラフィックを認可するよう設定されます。ポート80上に何も登録されていない場合、ターゲットアセットはスキャン・エンジン宛てに「ポートクローズ」応答を送信します。または何も応答しません。これにより、少なくともアセットがオンラインにあることとポートスキャン施行が可能であることが確立されます。どちらの場合も、スキャンログで当該アセットはALIVEと報告されます。
デバイス発見にTCPまたはUDPを選択する場合、ポート80に加えて複数のポートを必ず指定してください。これは、ターゲットアセット上で実行中のサービスおよびオペレーティング・システムにより異なります。発見スキャンおよび発見スキャン（積極的）といったデフォルトのスキャンテンプレート上のTCPおよびUDPポート設定を表示して、よく利用されるポート番号を把握することが可能です。
TCPはUDPより、ターゲットアセットからの応答取得に関する信頼性が高いです。また、UDPより多くのサービスによって利用されています。UDPは予備のプロトコルとして利用するのが良いかもしれません。なぜなら、ターゲットデバイスについても、より一般的なTCPやICMPパケットをブロックする可能性が高くなっているからです。
サイト設定内でスキャンターゲットがホスト名としてリストされている場合、アプリケーションはDNS解決を試みます。ホスト名が解決されない場合、UNRESOLVEDと見なされます。これはスキャン上の目的に合わせたもので、DEADと同等です。
UDPは、アセットの発見に関するプロトコルとしては信頼性に劣ります。なぜなら、データ統合性を保証しオーダーするTCPのハンドシェイクフィンガープリント法を組み込まないからです。TCPとは異なり、UDPポートが交信試行に応答しない場合は、通常オープンであると見なされます。
アセットの発見により、効率的に精度を上げることが可能です。また、アセットの発見を無効にすることでスキャン時間が長くなります。本アプリケーションは、アセットがライブであると確認される場合のみ、アセットをスキャンします。確認されない場合は無視して進みます。例えば、最初に50のホストがクラスCネットワーク上でライブであると確認できたら、不必要なポートスキャンは除外されるということです。
ICMPを有効化して介在ファイアウォールを設定し、アプリケーションとターゲットネットワークとの間のICMP ECHOリクエストおよび返信パケットのやり取りを有効化することは、得策であるといえます。
TCPについても、特に社内ネットワークのファイアウォールルールが厳しい場合は、必ずアセットの発見を有効化してください。UDPポートの信頼性の問題を考えると、UDPを有効化するのは行き過ぎかもしれません。UDPポートについて判定を行うには、綿密さ（精度）の価値とそれにかかる時間を秤にかけてください。
発見方法を選択していない場合、スキャンではすべてのターゲットアセットがライブであると仮定され、即座にサービス発見が始まります。
アプリケーションでアセットの発見にTCP法またはUDP法を利用している場合、特定のポートにリクエストパケットが送信されます。アプリケーションがポートにコンタクトしてポートがオープンであるという応答を受け取ると、ホストが「ライブ」であるとレポートされ、そのスキャンが行わます。
PCI監査テンプレートには、発見のための追加のTCPポートが含まれています。PCIスキャンでは、ライブ・アセットを見逃さないことが重要です。
脆弱性のチェックを実行する前に、発見されたアセットおよびスキャンされたネットワークについての特定情報を収集できます。これらの発見設定は、すべて任意です。
本アプリケーションはDNSサーバーおよびWINSサーバーに問い合わせて、スキャンされる可能性があるその他のネットワークアセットを見つけることが可能です。
Microsoft社により、NT 3.5のLAN Manager環境での名前解決のための、Windowsインターネット・ネーム・サービス（WINS）が開発されました。本アプリケーションはこの放送プロトコルに問い合わせて、Windowsワークステーションおよびサーバーの名前を見つけます。WINSは通常、必須ではありません。これは元々、NETBIOS名のIPアドレスへの変換をサポートするシステムデータベースアプリケーションとして開発されました。
本オプションを有効化してその他のネットワークアセットを発見する場合、アプリケーションはすべてのサポート対象アセットのIPアドレスを発見するためDNSサーバーおよびWINSサーバーに問い合わせを行います。これには、スキャンされたシステムのリスト内のアセットが含まれます。
注意: Whoisは、社内のl RFC1918アドレスでは機能しません。
Whoisは、所有者エンティティの名前といった、IPアドレスに関する情報を取得するインターネットサービスです。ネットワーク内でWhoisサーバーを利用できない場合、発見された各アセットについてWhoisサーバーで問い合わせなくとも、スキャン・エンジンのパフォーマンスを改善可能です。
本アプリケーションは、IPフィンガープリントと呼ばれる方法を利用して、発見されたアセットについての詳細をできる限り多く識別します。アセットのIPスタックをスキャンすることにより、アセットのハードウェア、オペレーティング・システム、さらにはシステム上で実行中のアプリケーションについてのインジケータを識別可能です。IPフィンガープリントの設定により、パフォーマンス・トライアングルの精度面に影響が出ます。
再試行設定では、IPスタックをフィンガープリントする試行をアプリケーションにより何回繰り返すかを定義します。デフォルトの再試行の値は0です。IPフィンガープリントは、アセットあたり最長1分かかります。初回にIPスタックをフィンガープリントできない場合、2回目の試行にわざわざ時間をかける価値はないかもしれません。しかし、何回でも再試行IPフィンガープリントを行うよう、設定することは可能です。
IPフィンガープリントを有効化するかどうかに関わらず、ポートスキャンからのサービスデータの分析といったその他のフィンガープリント法が、アプリケーションで使用されています。例えば、ターゲットアセット上のインターネット情報サービス（IIS）を発見することで、当該アセットがWindowsウェブサーバーであることを判定可能です。
確信度の値は0.0～1.0の範囲であり、どのアセットがフィンガープリントされているか確信度のレベルを反映しています。特定のフィンガープリントが最低確信度の値を下回る場合、そのアセットのIPフィンガープリント情報は破棄されます。アセットの発見に関連するパフォーマンス設定については、これらの設定はベストプラクティスを念頭に置いて注意深く定義されました。そのため、完全に同じとなっています。
発見されたアセットに関する情報を収集するための設定ステップ：
未認可MACアドレスを脆弱性としてレポートするためのスキャンを設定可能です。メディアアクセス制御（MAC）アドレスは、ネットワーク内の各ノードを固有に識別するハードウェアアドレスです。
IEEE 802ネットワークでは、OSI参照モデルのデータリンク制御（DLC）レイヤーは2つのサブレイヤー、すなわち論理リンク制御（LLC）レイヤーとメディアアクセス制御（MAC）レイヤーに分割されています。MACレイヤーはネットワークメディアと直接連動します。異なるタイプのネットワークメディアはそれぞれ、異なるMACレイヤーを必要とします。IEEE 802規格に非準拠でOSI参照モデルには準拠しているネットワークでは、ノードアドレスはデータリンク制御（DLC）アドレスと呼ばれます。
セキュアな環境では、特定マシンのみがネットワークに接続されている状態を確保しなければならない場合があります。また未認可MACアドレスの検出を成功させるには、特定の条件を揃えなければなりません:
アプリケーションによるMACアドレス取得のための認証スキャンの実行を有効化するには、以下のステップを行います：
コンソールに当該サイトのサイト設定パネルが表示されます。
コンソールに新規ログインボックスが表示されます。
認証資格情報（credentials）の設定の詳細については、スキャン認証資格情報（credentials）を設定をご参照ください。
認証資格情報（credentials）ページに、新規ログオン情報が表示されます。
信頼できるMACアドレスのリストを作成するには、以下のステップを行います：
Windowsインストールでのデフォルトパスは以下の通りです：
C：Program Files\[installation_directory]\plugins\java\1\NetworkScanners\1\[file_name]
Linuxでのデフォルトロケーションは以下の通りです：
/opt/[installation_directory]/java/1/NetworkScanners/1/[filename]
スキャンテンプレートで未認可MACアドレスのレポートを有効化するには、以下のステップを行います：
信頼できるMACファイルを配備しスキャナの値を設定すると、アプリケーションにより、信頼できるMAC脆弱性テストが実行されます。これを行うには、まずターゲットアセット宛てに直接ARPリクエストを行い、MACアドレスを収集します。また、セグメントを制御するルータまたはスイッチからARP表を検索します。その後、SNMPを利用してアセットからMACアドレスを検索し、NetBIOS名を利用してアセットを問い合わせ、そのMACアドレス検索します。