SANS Netwars 1st day

P.26

ビジネス用の連絡できる連絡先をもっておく必要がある。

壊してしまったときにrecoverしてもらうこともある。その逆も。

攻撃でマシンのモニターが壊れた→関係ないのでは？

暗号化された通信が必要（e.g. 危険度の高い脆弱性や機密内容）

インシデントレスポンスの場合、攻撃者に監視されている場合もある。

PGPがおすすめ。zipで暗号化して送信して2本目でパスワードを伝えるなど。電話なり別の手段で伝えるべき。

OWASPでも具体例を公開している。核となる部分はきちんと定義している。メールを読んでよいか。パスワードを使用してよいか。など。

→ペンティストフレームワーク

定期的にコミュニケーションを取ろう

テストを実施する曜日や時間

企業は攻撃者視点でやってほしい。仮に元社員だったらこの方法が適切とは限らない。

提供してもらった情報に基づいて診断。手探り必要ない。他の作業にあてられる。契約期間と時間を節約できる。

時間の余裕は攻撃者のほうがある。会社にドキュメントが無い場合などはBlackboxを使うかも。

診断するときに機密情報をすべてダウンロードするなどしないほうがいい。ダウンロードした段階で入手、アクセスすることをしている。

許可されていることではない。DBの場合、テーブル名は想像できて件数もわかる。でも、中身は見ていないけどおそらく推測することはできる。

確認が必要であれば管理者に連絡をして確認をしてもらう。→コミュニケーションがとても大切

紛失、破壊されたデータがあったら会社にとって致命的なものは何か考える。推測から確証に変える必要がある。

最重要データの想定と現実は異なった。想定は顧客のクレジットカード番号。実際は価格表。これを見過ごしていたかもしれない。

競合他社が価格表を入手することが致命的。不審な動きは価格表を変える（ダミーデータの場合も）。

対象を決める。取り決めと違うとは言いにくい。折り合いをつけて妥協点を見出す。

クレジットカード情報なら簡単に定義できる。難しいものこそ、会社が定める。

最良なのは診断員に全権限を付与する。日本だと診断員の権限が狭くされがち。

診断員のスコープを広げる。特定のツールやIPアドレスなど。

シンガポール政府が委託した会社が社員に何してもOKだと言っていた。アウトソーシングされている場合も、大本から許可もらうことはとても大切である。

AWSからペンテストの権限もらうことは出来る。ROEには別立ての許可をもらう。クラウド提供事業者から許可は必要。

AWSからAWSに攻撃することが許可されている場合ある。

本番環境でテストできることがベスト。本番環境が場合によってはクラッシュさせてしまう場合もある。テスト環境を持っている場合もある。本番環境とテスト環境の間での差異が問題になる。

ラップトップを送って、それにリモート接続する。先に侵入してみるという場合（ソーシャルエンジニアリングなど）もある。

組織の情報を収集する。社員や文化など。日本人がこれに長けていると思う。情報をオンラインでシェアしないことが大切。

攻撃者であれば上司に装いメール送信することも。

→十分に時間をかけて情報収集する。

Share Pointを使っているか確認すればそのツールにおける脆弱性を知ることができる。

ドキュメントのメタデータに注目する。→作者、保管パス、使用ソフト、メールアドレス、ユーザ名（→パスワード推測）

ROEに違反していなければ問題ない。許可されているあらゆる手段で診断をする。

企業で働いている人の情報、過去の情報からパスワード推測