コンピューターの機密保護に欠陥があると知ったとき、それを人にどう伝えたらいいだろうか。
こんにちは、セキュリティエンジニアの一杉です。
食品ビジネス事業会社のセキュリティ担当が、セキュリティ脆弱性診断メニューのネットワーク診断を完全社内リソースで内製化した取り組みについて紹介します。
Contents
セキュリティ脆弱性診断とは
セキュリティ上の脅威となる脆弱性を調査し評価します。
脆弱性とは、OSやソフトウェア、アプリケーションにおけるプログラム不具合や設計上のミスが原因となって発生した情報セキュリティ上の欠陥をいいます。
脆弱性を悪用されるた結果、システム改ざん／システム停止／情報漏えいなど、様々なセキュリティインシデントの引き金となります。セキュリティインシデントを引き起こすと、企業としても様々な対応が求められます。つまり、レピュテーションリスクともいえます。 *1
セキュリティ脆弱性診断に期待することは、セキュリティ脅威の可視化です。可視化した脅威は評価され、システムアドミニストレータが対応すべきか否かの判断材料となります。そして、脅威に対する対策を提示します。 その結果、攻撃者からの悪意ある攻撃や、システムの設計で防止できたはずの情報漏えいなどのマイナスのリスクを抑止しします。
ネットワーク診断
セキュリティ脆弱性診断には「ネットワーク診断」「サーバ構成診断」「WEBアプリ診断」「スマートフォンアプリケーション診断」etc…など、様々な診断メニューがあります。
私は、この中から社内導入のターゲットをネットワーク診断に設定しました。
ネットワーク診断のスコープとなる対象領域については、“OSI参照モデル／TCP/IPプロトコ郡“を用い決裁者へ説明しました。
以下図の通り、トランスポート層をメインの対象領域としています。
- OSI参照モデル（Open System Interconnection：（第４層）トランスポート層 + α
- TCP/IP （Transmission Control Protocol/Internet Protocol）：（第3層）トランスポート層 + α
（「+α」部分は、ソフトウエア脆弱性や暗号アルゴリズムの危殆化なども診断対象と含めています。）
ネットワーク診断を実施する効果については、以下を期待値として社内のステークホルダへ説明しました。
システムの脆弱性を伝えたい相手は、システムアドミニストレータになります。
システムアドミニストレータ観点での”悩み”に対する回答として、ネットワーク診断の効果を文章化しました。
なぜネットワーク診断なのか？
セキュリティ脆弱性診断の内製化について、なぜ複数ある診断メニューの中からネットワーク診断を選んだかについてです。
診断担当者（本ブログの作者）が、過去のキャリアでネットワーク診断の実務経験があり、保有するスキルも含めて導入後の運用を考えた際、内製化への簡便性が最も高かったからです。導入から運用後までを想定し、実現可能性を比較し判断した結果となります。
セキュリティ脆弱性診断を導入が目的ではなく、内製化として社内リソースで完結することを目的として設定しました。
内製化に向けた取り組み
社内での内製化に向けた取り組みとして実施した内容は以下の通りです。
- セキュリティ担当内でネットワーク診断内製化の承認を得ること
- 診断環境の構築
- システムアドミニストレータへのネットワーク診断啓蒙活動
セキュリティ担当内でネットワーク診断内製化の承認を得ること
最初に取り組んだのは、「セキュリティ担当内でネットワーク診断内製化の承認を得ること」です。
制約条件となる予算の部分は、セキュリティ施策科目で承認済みのものを利用したので、リソースを要することなく完了しました。
予算を使う上で、なぜネットワーク診断の内製化なのか？については、前の章で記載したネットワーク診断における”スコープ”や”効果”、及びPoCを実施し文章化しました。
診断環境の構築
診断環境構築として準備したことは以下2つです。
- 「診断用端末」の準備
- 「診断用のネットワーク環境」の準備
１つめの「診断用端末」の準備です。
これは、診断作業を実施する端末をセットアップを意味します。ネットワーク診断に必要な各種ソフトウェアをセットアップしました。有料版、オープンソース、様々なツールを準備しました。
（端末へセットアップしたソフトウエアの例）
- Nessus Professional
- Nmap
- Mozilla Firefox
- Nikto
- Wireshark
- and more…
“Nessus Professional”は、機械的な診断パケットを投げ脆弱性を検知するために使用しています。
Nmapは、ポートスキャン目的で使用しています。また、暗号アルゴリズムの危殆化など手動精査でも使用しています。
Mozilla FirefoxやNiktoは、WEBサーバを始めとしたミドルウエアの脆弱性を確認するのに使用しています。
Wiresharkは、診断時のパケット記録を残す為に使用しています。実際の作業内容の提示を求められたときを想定し、参考までに診断開始から終了までの通信パケットを記録する用途で使用しています。
上記以外にも、端末エミュレータや通信プロトコルに応じた手動診断のための様々なソフトウエアを準備しました。
2つめの「診断用のネットワーク環境」の準備です。ネットワーク診断は、以下2つの観点での診断を実施が可能です。
- 外部犯行目線：インターネット外部からのアクセスを想定
- 内部犯行目線：イントラネット内部からのアクセスを想定
内部犯行目線は、私が端末を持って移動すれば解決できます。
外部犯行目線については問題があります。
問題：
- セキュリティ脆弱性診断で得られる結果はシステムの脆弱性であり機密情報となる
- 発信元依存で診断結果が変わるような事があれば品質不良となる
- セキュリティ脆弱性診断の通信パケットを投げる行為はクラッカーと見なされる
この問題を解決すべく社内に診断専用LANを敷設しました。
社内からインターネットへ接続する際、UTMなどで通信制御しているため、発信元を限定しない不特定多数からのインターネットアクセスとは異なるアクセス制限となります。
以下図の通り診断専用LANを敷設しました。これにより、発信元GIPも固定化することも可能となりました。
診断専用LANは、一部の限定されたメンバーのみが利用することを運用上のルールとして設定し、物理的なセキュリティとして個別で鍵が必要な部屋に診断専用LANを敷設しました。
システムアドミニストレータへのネットワーク診断実施に向けた啓蒙活動
システムアドミニストレータの主管システムへの診断を実施するために、ネットワーク診断の案内を実施しました。ポイントとして、私とシステムアドミニストレータで以下の部分についてコミュニケーションをとることに注力しました。
[ポイント]
- セキュリティ脆弱性診断に関わる対応の流れは？
- ネットワーク診断内容は？
- 対向先帯域負荷は？
- 診断作業時間は？
- 事前準備は？
セキュリティ脆弱性診断に関わる対応の流れは？
キックオフMTGから、診断完了後の対策確認まで一連の流れと必要な作業について、相互理解することを目的としました。
・事前準備としてヒアリングシートの作成が必要です。
・診断作業工数は1day+1week（ツール+手動での再現確認作業）となります。
・報告会、及び対策確認を実施する。
など、実施内容を時系列で説明しました。
ネットワーク診断内容は？
診断作業として実際に何を実施するのかを相互理解を目的としました。
以下図の通り、2つのツールと手動で再現を確認することを共有しました。
対向先帯域負荷は？
診断作業時に発生する対向先帯域負荷について、相互理解を目的としました。
診断作業時の対向先帯域負荷においては汎用的なデータとし定量的に提示ができませんでした。
理由としては以下の通りです。
- 診断ツールの設定に依存する（例：”Nessus Professional”のScanポリシー、nmapのオプション）
- システム要件（ネットワーク構成／稼働サービス,etc）に依存する
結果、対向先負荷を考察する参考値として、診断端末からの送信として発生したデータ容量（bps）を共有しました。
診断端末からのデータ容量（bps）を確認するのに、Wiresharkを使用し診断作業の時間を記録しどの作業にどの程度の通信が発生しているのかを確認しました。
参考までに、以下は診断時に発生した通信パケット推移の図となります。縦軸（パケット/秒）、横軸（時間）のグラフとなります。 PoC時にWiresharkログから診断作業時に発生する最大データ容量（bps）を算出しました。
診断作業時間は？
診断時間について、相互理解を目的としました。
診断作業は1day+1week（ツール+手動での再現確認作業）を基本とし、診断対象数（アセット）に応じて、どの程度の診断時間、及び日数の調整が必要なのかを共有しました。
事前準備は？
診断実施までにシステムアドミニストレータ側にて実施して欲しいことについて、相互理解を目的としました。
ネットワーク診断の結果は環境に依存します。診断時点の状況、及び本番環境で診断に意味を持ちます。そのために、以下のような事前準備をお願いしました。
- 監視チームへの情報共有
機械的に診断パケットを短時間で送付することへの注意喚起
診断対象先環境のアクセスログ等が大量に更新されるため
- システム情報ヒアリングシートの作成（情報：OS、サービス稼働状況（インターネット公開）、etc）
診断対象の確認、及び診断結果精査に利用するため
- ソフトウェア、パッチなど各種バージョンアップ
診断時点の状況が結果となるため
- （可能であれば）診断対象のバックアップ
最悪の場合を想定したリカバリプラン
セキュリティ脆弱性診断の実施
診断実施の部分についてです。
大まかな流れとしては、以下の通りです。
- ”Nessus Professional”により機械的に診断パケットを送信し脆弱性を検知
- ”Nmap”ポートスキャンにて、サービス応答を確認
- 上記”Nessus Professional / Nmap”から確認した脆弱性、及びサービス応答に準じ”手動+α”にて再現性を確認
また、報告書作成に必要な情報として、指摘脆弱性の危険度設定等の根拠となる情報を精査
（1）”Nessus Professional” の実施
最初に診断ツールの”Nessus Professional”を実施します。
”Nessus Professional”は、サービス応答に準じ機械的に診断パケットを送付し脆弱性を洗い出します。その結果検知した脆弱性を精査し、検知の等級を維持し、品質を保障します。
”Nessus Professional”には脆弱性を検出するプログラムがあります。これをプラグインと言います。
プラグインには、脆弱性に関する情報、修正アクションの概要、およびセキュリティ上の問題の有無を検査するアルゴリズムが含まれます。
検知したプラグインを精査し、システムに残存する機密性の欠陥を洗い出しが可能となります。
”Nessus Professional”にてネットワーク診断を実施する際は、Scan Templatesを選択します。実績としての効果測定が不十分のため、現在は既存Scan Templatesをそのまま使用しています。今後は、Credentilas情報を付加したcredentialed scanや、診断対象に応じプラグインを選択したりなど、カスタマイズを検討したいと考えています。
”Nessus Professional”の結果レポートはhtml or CSV 形式でのエクスポートができます。
CSV形式であれば様々なソフトウエアにインポートが可能なため診断結果管理などを運用するのであれば便利です。参考までにhtml形式のレポートから、検出脆弱性の見え方についてご説明します。
①：プラグインの名称です。数字部分がプラグインに一意付与されたIDです。IDをtenableのHPから検索し、当該プラグインの詳細について確認が可能です。
②：当該プラグインの説明部分です。「Synopsis／Description／Solution」が確認可能です。脆弱性の参考情報としシステムアドミニストレータに伝えるのみ有効な情報です。
③：tenableが設定したRisk、及びCVSS値です。ソフトウェアのセキュリティ脆弱性であれば、CVE番号をNVD（National Vulnerability Database）で突合しCVSS値を確認します。
④：検出結果です。実際に”Nessus Professional”のセキュリティ脆弱性スキャンパケットの応答結果となります。
（2）”Nmap”の実施
”Nmap”は、オープンソースのポートスキャンツールです。
”Nmap”を利用している理由としては、以下の通りです。
- サービス応答やソフトウェア等のバージョン情報確認
- セキュリティスキャナとしての脆弱性検知
”Nmap”には、様々なオプションが存在します。
診断精査する上での求めたい証跡を考察した結果、以下を”Nmap”実施時のオプションと設定しました。
・nmapコマンド （xxx.xxx.xxx.xxx 部分は、診断対象のIPorFQDNとなる。）
■TCP■
> nmap -p 1-65535 -A -v -sV -sS xxx.xxx.xxx.xxx -oN xxx.xxx.xxx.xxx_tcp.txt -oX xxx.xxx.xxx.xxx_tcp.xml
■UDP■
> nmap -A -v -sV -sU xxx.xxx.xxx.xxx -oN xxx.xxx.xxx.xxx_udp.txt -oX xxx.xxx.xxx.xxx_udp.xml
・nmapコマンドオプションについて
・共通のオプション
-A ： OSのバージョンをスキャン
-Pn ： 事前のPingスキャンをスキップ
（nmapでは、スキャンの前にpingでの疎通確認を行っています。
UTMなどでICMP無効化している場合”Nmap”スキャン不可となるため）
-v ： ”Nmap”バージョン情報の出力
-sV ： サービスバージョンの出力
-oN
-oX
・TCPのみのオプション
-p 1-65535 ： 全65535ポートへのスキャン -sS ： TCP SYN スキャン
・UDPのみのオプション
-sU ： UDPスキャン
以下は、オプション検討時に情報を精査中に発見した情報です。このような情報を理由しながらオプションを決定していきました。
- （参考①）「-sS」オプション
”Nmap”は、TCP 3way hand shakeを行うため診断対向先にログが残ります。
「-sS」オプションを使用すると「ステルススキャン」が可能となります。
* コマンド例）nmap -sS xxx.xxx.xxx.xxx
”Nmap”については、セキュリティ脆弱性診断内製化の作業であること。及び正しい診断結果の弊害ともなると考え「-sS」オプションは使用不可としました。
- 理由① 診断対象に診断時の証跡が残らない
- 理由② UTMで「ステルススキャン」は遮断される可能性がある
- （参考②）UDP Port Scanの 「-p」オプション
”Nmap”はプローブパケットからポート状態を判別しています。UDPプロトコルは、コネクションレス型のためポート状態が判別しにくく、スキャンの完走に時間を要します。 ポートスキャンを目的とするのであれば、”Nessus Professinal”でも実行しており、”Nmap”でポート限定（-p XXX）でのスキャンも可能なので、UDP Port Scanの 「-p」オプションは未指定としました。
（3）”手動+α”の実施
先の（1）（2）での結果をもとに手動での作業を実施します。
これには2つの目的があります。
- ツールで検知した脆弱性の再現確認を実施し誤検知の有無を確認する
- 社内のセキュリティポリシーを満たしているを確認する
「ツールで検知した脆弱性の再現確認を実施し誤検知の有無を確認する」について、説明します。
”Nessus Professional”にて、TLS1.0が有効化を検知しました。
（参考）Tenable| プラグイン：https://jp.tenable.com/plugins/nessus/104743 )
手動精査によるopensslのCLI確認にて、TLS1.2のみ応答を確認しました。
これは、先の”Nessus Professional”の結果と異なります。
このような診断ツールの結果の再現性確認を実施しながら、誤検知を抑止していきます。
内製化した効果として、診断実施者及び診断対象のシステムアドミニストレータが共に同部門だったことです。
本件であれば、システムアドミニストレータに直接ヒアリングも容易です。
続いて「社内のセキュリティポリシーを満たしているかを確認する」について説明します。
セキュリティ脆弱性とは異なる観点において、社内のセキュリティポリシーから不適合となる部分が無いかを確認します。
そのためには、社内のセキュリティポリシーを策定し公開しておく必要があります。
診断結果報告書、及び報告会
診断報告書
診断作業が完了したら、報告書を作成します。
報告書の想定読者は、システムアドミニストレータとなります。セキュリティエンジニアではありません。つまり、セキュリティの脆弱性について知見を有している人物ではないです。
報告書を作成する上で、特に注意したいのが「記載内容が明瞭である」です。
報告者は、システムアドミニストレータが対策する上で参考にする情報となります。そして、複数のシステム関係者へ共有されることも想定されます。報告書記載内容が不確実性を含むような内容では、対策要否の判断が出来ません。
結果、セキュリティの脆弱性が残存し続けるといったマイナスのリスクがあります。
品質の低い報告書では、システムアドミニストレータが求める期待度も低く、内製化した効果も満足の行く結果を得られません。
これを解決するためには必要な要素としては、以下2点に注力しました。
- セキュリティ脆弱性の危険度設定の根拠を公開すること
- セキュリティ脆弱性の再現方法を提示すること
「セキュリティ脆弱性の危険度設定の根拠を公開すること」について説明します。
危険度の判定基準として以下の通り設定しています。
CVSS値に準じた判定とEOLに準じ危険度を設定しています。
CVSS値を確認する為の一つの手段としては、”Nessus Professinal”検知レポートのCVE番号を基に、NATIONAL VULNERABILITY DATABASEやJapan Vulnerability Notesを利用しCVSS値を確認します。
また、EOLなどの構成情報による指摘については、提供元ソフトウエアベンダーのリリースノートなどで確認します。
上記の危険度判定基準と併せて、対策要否判断の付加情報としてエグゼブティブサマリー情報も併せて記載をします。 （診断結果との関連性が強く機密情報を含む内容となるため、ここへの記載は割愛します。）
続いて「セキュリティ脆弱性の再現方法を提示すること」を説明します。
報告書には【確認証跡】として記載しています。指摘している脆弱性をこの方法で確認する証跡となります。
診断結果として誤った報告をしない。は、診断することへの価値を持たせるために重要となります。
以下、報告書の例です。
TLS/SSL暗号の危殆化アルゴリズムの指摘として、”Nmap”コマンドの実施結果を記載しています。
報告会
報告会では、システムアドミニストレータに対し報告書を使用し実施します。
双方向コミュニケーションにて、診断実施者／システムアドミニストレータの相互理解に努めます。
事前に報告書を共有し、限られた時間内で報告会を完遂するように準備をします。
報告会で、相互理解に努めた箇所は以下の通りです。
・ネットワーク診断の目的
・報告書の取扱いについて
・セキュリティ対策の運用について
・免責事項
・ネットワーク診断実施概要
・総合評価
・診断結果詳細
・付録情報
・危険度の判定基準
上記内容について、双方意見を交わしながら診断対象数にもよりますが30分〜1時間で実施します。
セキュリティ脆弱性診断はやってお終いではない
セキュリティ脆弱性診断は、システムのセキュリティ脆弱性を洗い出します。つまり、セキュリティ脆弱性診断を終えたらゴールではありません。
顕在化した脆弱性について、対策を実施する必要があります。
対策については、報告会でもフォローする旨をシステムアドミニストレータに伝えます。
対策状況について、可視化するためのチェックシートを作成し対策状況をステークホルダ間で共有できる状態とします。
今後の展望
セキュリティ脆弱性診断として、現状はネットワーク診断のみ内製化が出来た状態です。そして、ネットワーク診断実績としての診断アセットについては、組織の保有しているリソースに対し充分とはいえるボリュームではありません。
「セキュリティ脆弱性診断」として、及び「ネットワーク診断」の2つの観点で今後の展望について記載します。
「セキュリティ脆弱性診断」としての今後の展望
ECサイトにて事業推進しています。ECサイト（≒WEBアプリ）の機密性／完全性／可用性は当社としてビジネスインパクトが大きいものとなります。
「WEBアプリ診断」を内製化し、恒久的に「WEBアプリ診断」を実施するような規定を策定したいです。
（例：WEBアプリにおける外部公開部分の更改が入った際には「WEBアプリ」診断を実施する。）
「ネットワーク診断」としての今後の展望
- 診断結果のナレッジを集約し、手動精査の精度を落とさず効率化を達成する
- 診断アセットを増やす
- 診断結果を集約し、診断実施状況／対策状況を管理する
- 診断のブラッシュアップ
- クレデンシャルスキャンの運用開始
- 診断の自動化
まとめ
社内にセキュリティ脆弱性診断のネットワーク診断を導入した取り組みについての紹介でした。
食品ビジネス事業会社のセキュリティ担当として『組織のミッションを達成するため、情報システム起因のセキュリティマネジメントを実施。』をセキュリティチームの目的として設定しています。
本件は、その中での活動実績の一例となります。
セキュリティチームは、目的達成のために様々なセキュリティ課題に取り組んでいます。
セキュリティチームの仲間を募集しております。
*1:レピュテーションリスクとは、企業などの評判（レピュテーション）が悪化する危険（リスク）のこと。評判リスク、風評リスクともいう。否定的な評価が広まると、企業の信用やブランド価値は短期間のうちに低下する。
