カナダ
カナダ フランスフランス ドイツドイツ イギリスイギリス 米国米国 オーストラリアオーストラリア ニュージーランドニュージーランド
認証認証 ((ValidationValidation
/Certification)/Certification) 評価
評価 (Evaluation) (Evaluation)
認定認定
(Accreditation) (Accreditation)
CCRA CCRA
認証書認証書 認証書認証書
認証書認証書 認証書認証書
ギリシャギリシャ フィンランド フィンランド
イタリア イタリア オランダオランダ
ノルウェー ノルウェー スペインスペイン
認証書認証書 認証書認証書 認証書認証書
認証書認証書 認証書認証書 認証書認証書
認証書認証書 認証書認証書
イスラエル イスラエル
認証発行国
※注1トルコトルコ
認証受入国
※注2CCRA (Common Criteria Recognition Arrangement)
ISO/IEC15408 と情報セキュリティ評価・認証制度
各省庁は、セキュリティに関する信頼度の高い情報システムの構 築を図る観点から、今後の情報システムの構築に当たっては、可 能な限り、次のような方法等により、ISO/IEC15408に基づいて評 価又は認証された製品等の利用を推進するものとする。
各省庁は、セキュリティに関する信頼度の高い情報システムの構 各省庁は、セキュリティに関する信頼度の高い情報システムの構 築を図る観点から、今後の情報システムの構築に当たっては、可 築を図る観点から、今後の情報システムの構築に当たっては、可
能な限り、次のような方法等により、
能な限り、次のような方法等により、 ISO/IEC15408 ISO/IEC15408 に基づいて評 に基づいて評 価又は認証された製品等の利用を推進するものとする。
価又は認証された製品等の利用を推進するものとする。
政府調達の際には、可能な限り認証された製品を調達するか、
政府調達の際には、可能な限り認証された製品を調達するか、
システムに関するSTの評価を受けることと
システムに関するSTの評価を受けることと す す る。 る。
平成 平成 13年 13 年 3月 3 月 29 29 日 日 行政情報化推進各省庁連絡会議了承 行政情報化推進各省庁連絡会議了承
ISO/IEC15408 と情報セキュリティ評価・認証制度
政府調達における位置づけ
ISO15408に関する問合せ先
(独)情報処理推進機構 セキュリティセンター
情報セキュリティセミナー 2004
インシデント対応
1.インシデント対応とは
2.平時におけるインシデント対応の準備 3.情報セキュリティ侵害を検出する
4.インシデントに対応する
5.インシデント後
インシデント対応とは
• インシデント
情報セキュリティ分野においては (Security incident) 、情報 セキュリティリスクが発現,現実化した事象
• サービス妨害( DoS) 攻撃
• システムへの侵入
• サーバの不正中継 等
• インシデント対応
インシデントの発生に際して、それを検知し、関係組織と連
絡をとり、被害の拡大を防ぐと共に、再発を防止するための
• セキュリティポリシー等の中で手順を明記
インシデント発生時の体制、責任者、連絡先等
• 平時に行われていなければならないこと
– 定期的バックアップ
– システムの通常状態の把握
– 外部情報収集と修正プログラムの適用 – 予行演習
• 技術的手段の準備
– 情報セキュリティ侵害の検知を支援するツール – バックアップ資源
平時におけるインシデント対応の準備
情報セキュリティ侵害を検出する (1)
• 検出・認識の方法
– 既知の侵害(パターン)を検出する:シグネチャ認識 – 異常な状態を認識する
– 他者からの連絡
• ツールの利用
• 次に何をすべきか?
情報セキュリティ侵害を検出する (2) ー 異常な状態を認識する
システム異常の例
(1) レスポンスの異常な低下 (2) システムエラーの発生
(3) システムの異常停止 (4) ファイルの改ざん
(5) 存在すべきファイルの抹消や不明なファイルの存在 (6) ファイル利用量の急激な増減
(7) 本来稼動しているはずのサービスの停止 (8) 不明なプロセスの実行
(9) 本来利用できないはずのシステムユーザの利用
情報セキュリティ侵害を検出する (3) ー ツールの利用
異常検出を極力自動化
例: Tripwire による各種設定ファイルの改ざんチェック 当該ファイルのハッシュ値の比較(正常時と異常時 )
平時の準備が必要
情報セキュリティ侵害を検出する (4) ー 次に何をすべきか?
• インシデントの状態の保存 – 各種設定ファイル
– ネットワークの接続状況 – ログインユーザ
– すべてのプロセス 等
• 該当インシデントの公開情報の調査
IPA/ISEC 、 JPCERT/CC 等の利用
• 本当にインシデントかどうかの確認
• 時系列の記録の開始
インシデントに対応する
• インシデント対応手順の確認
• 報告する
– 組織体内部のコミュニケーション
あらかじめ定められた手順
– 関連組織とのコミュニケーション
参考資料: JPCERT/CC 技術メモ 関係サイトとの情報交換
http://www.jpcert.or.jp/ed/2002/ed020001.txt
インシデントに対応する (2)
• 暫定的対応と本格的対応
– 暫定的対応(被害の拡大防止):
• ネットワークの遮断/システムの停止
– 本格的対応(再発防止):
• 原因の特定
• クリーンなシステムの再構築
( 攻撃者にシステム特権を奪われたとき )
• 修正プログラムの適用
• データの復旧
インシデント後
• 報告書
– 時系列記録の整理・報告
– 今回対応のよかった点/悪かった点
• 改善する
– 改善点をセキュリティポリシーや手順書に反映・
集約
– 技術的な改善
– 組織間コミュニケーションの改善
インシデント対応の作業手順
• 1. 手順の確認
• 2.作業記録の作成
• 3.責任者、担当者への連絡
• 4.事実の確認
• 5.スナップショットの保存
• 6.ネットワーク接続やシステムの遮断もしくは停止
• 7.影響範囲の特定
• 8.渉外、関係サイトへの連絡
• 9.要因の特定
• 10.システムの復旧
• 11.再発防止策の実施
• 12.監視体制の強化
• 13.作業結果の報告
補足:不審なアクセスを検出した場合の対応
• 可能性
(a) 攻撃対象の探索を意図したアクセス、または、アタックその もの
(b) 設定ミス、操作ミスによるアクセス
(c) システムの予想外の挙動によるアクセス
• 対応
(a) すべてのアタックについて防御に成功したと判断できない場
合には、念のためシステムの稼働状況を調査し、不審な点
がないか確認
補足:外部からインシデントについての連絡を 受けた場合
(1) サイト内での調整
広報、渉外、法務などからの対応が望まれる場合は、該当部署と調整
(2) 事実関係の確認
・連絡元の主張する内容を落ち付いて確認
(対象サイト、アクセスの内容、日時等 )
・自サイトの場合システムログ等による事実関係の確認
(事実の場合、影響度によってはネットワーク接続やシステムの遮断、
停止を優先するほうがよい場合も)
(3) 連絡元への対応
・善意の連絡:事情説明、謝罪など礼を逸しない対応
・悪意の連絡:回答を避ける等の特別の対応も検討要
補足:侵入への対応
(1) ネットワークの遮断、システムの停止 (2) スナップショットの保存
(3) 被侵入システムにおける調査
(4) 他のシステムに対する影響の調査
(5) 侵入経路の特定
補足:侵入への対応 -(1)
(1) ネットワークの遮断、システムの停止 システム侵入
→・ログ改ざんのおそれ
・他システムへの攻撃元として悪用
・パケット盗聴プログラムの設置
・情報の持ち出し など
ネットワークの遮断やシステムの停止について 優先的に検討要
出典 技術メモ - コンピュータセキュリティインシデントへの対応
http://www.jpcert.or.jp/ed/2002/ed020002.txt
補足:侵入への対応 -(2)
(2) スナップショットの保存
・プロセスの稼働状況
・ネットワークの利用状況
・ファイルシステムの状況
(ファイルの最終参照時刻、 最終更新時刻、所有者、
アクセス権など )
補足:侵入への対応 -(3)
(3) 被侵入システムにおける調査
正常な状態と比較し、 相違の有無を確認 改ざんの例:
・アカウント情報の追加、変更
・ユーザ認証機構の改ざん
・プログラムのインストール、起動
・セキュリティ上の弱点を含むソフトウェアへのダウングレード
・侵入者に関する情報を出力から除外するコマンドへの置換
改ざんされていないコマンドによる調査が重要
補足:侵入への対応 -(4)
(4) 他のシステムに対する影響の調査
・攻撃用ツールの出力を保存したファイル
・侵入者による他システムへの TCP 接続の痕跡
・ルータやファイアウォールのログ
補足:侵入への対応 -(5)
(5) 侵入経路の特定 弱点のチェック
・放置していたセキュリティ上の問題、弱点はなかったか
・パスワードファイルや設定ファイル類が盗まれた形跡はないか
・見破られやすいパスワードがなかったか
・ HTTP や FTP など、公開しているサービスに設定の誤りが
なかったか などをチェック
補足:証拠保全 -(1)
• 刑事事件を視野に入れる場合は「証拠保全」
– 「証拠」となるデータを、可能な限りそのままの状態で捜 査機関にわたす
– 証拠保全=現場保全であり、不用意なログインを含め てできるだけ操作をしないことが重要
– ただし、被害拡大を防ぐための最低限の処置は行う
• ルーティング変更
• DNS 変更、ファイアウォールのフィルタ等による通信遮断
– 物理的に遮断するのは得策ではない
補足:証拠保全 -(2)
標的だけを隔離する例
• 標的サーバーへの通 信、標的サーバーから の通信だけを遮断し、
標的の状態を保全する
• ただし、標的ではない サーバーも注意が必要
– 踏み台(標的サーバー)
からの2次攻撃の可能
性有り
ドキュメント内
Copyright
(ページ 77-99)