サイバーセキュリティインシデント報告資料の作成Tips

ザ・インシデント (字幕版)
官公庁や旧公社では、上司や経営層への報告資料としてワンペーパーに情報を集約する風習があるようです。通称"ワンペ"。
「インシデント発生しているこの忙しいときに、なんでワンペつくらなあかんねん」と思いがちですが、エスカレーションは大事です。日ごろから素材を集めて有事の際に役立てたいのと、些細なミスでわき道にそれないよう、資料作成のルールは押さえておきたいものです。


あったほうがいいもの

決まったルールはありませんが、次の要素は書くがいいと思っています。

  • 概要
    • 日時
    • インシデントの種別
  • 時系列
  • 図や表(文書や箇条書きのみの報告書は避けるべき)
  • 今後の活動計画、もしくは振り返り

http://upload.wikimedia.org/wikipedia/commons/2/20/Restaurant-UML-SEQ.gif

図を描く

ネットワーク図

上がインターネット(もしくはサーバ)、下がローカル(もしくはクライアント)となるように配置します。
シーケンス図のように横向きの場合は、右がインターネット(もしくはサーバ)、左がローカル(もしくはクライアント)となるように配置します。たまに間違えます。
インシデントの報告資料では、シーケンス図を書いておけばまずは間違いはありません。ちなみにわたし、serweij/mscgen_jsというJavaScriptが気になっています。まだ使ってないけど。

機器や人物のアイコン

http://www.cisco.com/web/about/ac50/ac47/images/wmf_icons.gif
企業のもの

オープンなもの

まずは普及しているCiscoのを使えばよいと考えますが、特定企業への依存の恐れと、悪意のある攻撃者のアイコンがない..。その場合はOpenなOSAが使えます。その他は、ここがまとめてくれています

注意:Icon packsの絵を使っている人がいますが要注意。Free版は商用OKですが、HackerやComputerが含まれているPro版は有料です。

自主規制

パブリックにする資料では、CSRが求められます。差別表現のないイラストを使用しましょう。指摘されやすいこととして、目耳鼻口が描かれていること、指は5本描いてあることなどがあります。しかし社内など限定した範囲にしか流布しない資料の作成であれば、画像を探すのに時間をかけるのはやめましょう。


インシデントの報告

 3-1 アクセス元に関する情報をご記入下さい。
     IP アドレス、ホスト名など:

 3-2 インシデントの内容、発見方法、対処などについてご記入下さい。

 3-3 インシデントが発生したシステムについてご記入下さい。
     IP アドレス 又は ホスト名:
     プロトコル 又は ポート:
     関連ソフトウェア:
     ハードウェア/OS:
     発生日時:
     タイムゾーン(時間帯):

JPCERT コーディネーションセンター インシデントの報告

送信元IPアドレス

インシデントレスポンスにおける鉄則として、まず送信元のIPアドレスを調べるというのがあります。Whoisやdigの結果はテキストのままで良いので報告書に貼り付けておきましょう。

サイバー攻撃の「送信元IPアドレス」がわかったらする10のこと

ドメイン
  1. Whois検索(国やAS)
  2. DNS正引き
  3. Google検索
  4. 属性型地域型JPドメイン

JPドメイン名の種類 / JPDirect
個人的な過去の失敗から、ne.jpとad.jpの違いを理解しておくことが重要です。例えばOCNさんだったら、「ocn.ad.jpから攻撃された」と「ocn.ne.jpから攻撃された」とでは発生事象の意味が大きく異なります。

IPv4 Address Blocks Reserved for Documentation
192.0.2.0/24        TEST-NET-1                 RFC 5737
198.51.100.0/24     TEST-NET-2                 RFC 5737
203.0.113.0/24      TEST-NET-3                 RFC 5737
RFC 5735 - Special Use IPv4 Addresses

a.a.a.aとか、xxx.xxx.xxx.xxxとか、123.45.67.89といったアドレスを文書で見ることがあるがよろしくない。なおRFC 5737は、RFC 3330を更新したもの。

Documentation IPv6 Address Prefix
The prefix allocated for documentation purposes is 2001:DB8::/32
RFC 3849 - IPv6 Address Prefix Reserved for Documentation
Domain Name Reservation Considerations for Example Domains
   The domains "example.", "example.com.", "example.net.",
   "example.org.", and any names falling within those domains, are
   special in the following ways:

   1.  Users SHOULD understand that example names are reserved for use
       in documentation.
RFC 6761 - Reserved Top Level DNS Names

なおRFC 6761は、RFC 2606を更新したもの。


https://nvd.nist.gov/NVDLegacy/media/NVDLegacyMedia/images/leftbar/cve.jpg

共通識別子

この中でだと、CWEが全容を理解するのに一番むずかしいです。ViewとCategoryという概念が、CWEに包含的に定義されているためです。他にも、CCE, OVAL, OCIL, XCCDF, CPE, CAPEC, MAEC, CybOX, SWID, STIX と言った識別子が提案されていますが、まずは3つさえ覚えれば十分。

定量化/数値化が可能な要素
  • リスク
    • セキュリティのリスクは定量化が難しく、定まった算出方法も存在しない(自分で決めて良い)のですが、CISSPの考え方では定量化を推奨することになっています。
    • 脆弱性の危険度:CVSS ※注意:CVSSは算出する人によって値が異なる!
  • 経過時間
  • 参加率、報告率