セキュリティ事故現場から見える経営リスクと対策 Vol.2

IT・IT製品TOP > Key Conductors > 江尾 一郎(ソフトバンク・テクノロジー株式会社) > セキュリティ事故現場から見える経営リスクと対策 Vol.2
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

セキュリティ事故現場から見える経営リスクと対策 Vol.2

ネットワークセキュリティ 2014/05/09

  セキュリティ事故発生要因は現場だけの問題ではない。どのように企業のセキュリティリスクを回避していくべきなのか?経営トップやその関係者が関わる中で本連載(全4回)の第2回ではセキュリティインシデントの想定から学び、どのように企業の重要なリスクに対応していくべきなのかを考えていきたいと思います。

第2回:チェックポイント

 前回の課題を掘り下げて考えてみます。あるインシデント(セキュリティ事故)発生を想定してみましょう。

1.シミュレーション

 通販事業を運営しているWebシステムから個人情報が流出したニュースを聞いた時、自社でも同様のインシデントが発生したと想定してみてください。

(A)  セキュリティ専門会社のエンジニアにも支援を受けながら、新Webシステムの設計・構築から導入作業までを終え、
  セキュリティ診断にて脆弱性を確認・是正し、ようやくサイトの公開を行いました。
(B) それから1年経過した頃に、顧客から個人情報流出した疑いの問い合わせがあったので、Web事業責任者はシステム
  部門に調査を指示しました。

システム部門からの調査報告は「特に流出の事実は確認できなかった」との簡易報告でした。さらに、詳細な報告書の要求を行った結果も新しい情報漏洩の事実はありませんでした。ただし、以下の追加情報が報告されました。

・3ヵ月以上保存されているはずのログが2ヵ月に満たない対象期間である。当初の設計では専門家の指導により6ヵ月は
 保有する方針であったが、現況に至った経緯は不明である。
・数ヵ月前に、WebサーバーのOSに脆弱性の問題があるという製品ベンダからの発表とパッチモジュールがでていた。
 情報漏洩の事実は確認できていないが、攻撃を受けた場合にその可能性は否定できない。当時エスカレーションする
 判断は難しく、パッチ適用の計画を立てたが諸事情で保留にしたままである。 
・導入当初から、パフォーマンスの問題もあり機器増強や仕様変更による公開サイトのアプリケーションの更新が随時発
 生していたが、セキュリティ診断の再診断は未実施である。

これらの報告を聞いた経営者は、すぐに専門業者への調査依頼を指示しました。(事例の続きは次回にて)

 ここまでの経緯から問題を整理してみましょう。本来のあるべき姿を想定し改善提案をまとめてみてください。
次に、経営者・事業責任者・システム部門・専門業者の各責任と役割を、各(A)・(B)の課題や問題点から見える実態とそのリスクを考えてみたいと思います。

■(A)のフェーズにおけるセキュアコーディング

 Webシステム公開時においては製造過程での品質レベルが低かったと言えます。Webアプリケーションの情報セキュリティ対策と最新動向の更新、開発チームへのトレーニング、単体検証時のソースレビューによる品質管理の徹底が必要です。ネットワークセキュリティ診断においても同様のことが言えます。サーバーの要塞化手順の確立やセキュアコーディング(脆弱性のない、安全なソフトウエア開発)による脆弱性対策によって安全なサイトの構築が実現します。これらのリスクをさらにカバーするためにPCIDSSではWAFの実装とソースコードレビューを実施することを必須としています。 

■(B)のフェーズにおける変更管理の徹底

 いくつかのプロセスが欠落していると判断できます。上記の繰り返しになりますが、診断後の品質レベルが低い場合にはなぜ品質向上の是正のアクションを起こせなったのかが課題になります。変更管理はとても重要なプロセスです。変更作業に伴うリスクを最小限に抑えながら、効果的・効率的に実現するためのIT運用管理プロセスです。機能改善やパフォーマンス向上とその納期を優先にシステムの構成変更を行えばアクセス管理(管理者権限やユーザ権限の適切な設定・変更)や構成管理(ディスク容量やバックアップ管理などへの影響確認)の各調整も必要とされます。開発環境(デフォルト設定や部外者のアカウントや作業環境)が残されていたとしたら裏口を開放しているようなものです。これには、リアクティブな活動(※1)とプロアクティブな活動(※2)サイクルが有効です。また、ITIL(※3)の部分的な導入を推奨します。取り組み方は企業規模やリスクに応じた内容で検討されるとよいでしょう。準拠レベルの導入でもある程度の効果はあります。

※1:非可用性を伴う全てのイベント、インシデント、および問題のモニタリング、測定、分析、および管理
※2:可用性のプロアクティブな計画立案、設計、および改善
※3:ITIL®とはITサービスマネジメントのベストプラクティスをまとめた、公開されたフレームワークです。
   
http://www.itsmf-japan.org/aboutus/itil.html

 大きな組織では縦割りの組織となり、役割を明確に分担することにより生産性を重視し効率の良い結果を生みますが、反面役割以外の対応に関しては専門外・担当外ということでスムーズな対応が困難な状況を見受けます。
 今回の事例でシステム部門がなぜ負のスパイラルに陥ったかを想定してみてください。前回の「インシデントの要因の本質を探る」を見返していただきたいと思います。また、セキュリティインシデントには、ゼロデイ攻撃という防ぎようのないケースも昨今多発してきております。インシデントレスポンスの体制が必要とされます。

                  — 関係者と揃って議論しましょう! —

 実際に、社内訓練としてインシデントレスポンスの演習(20分間の時間の制約、背景とリソースを設定、役割も本来のミッションと違うかたを選出)をしてみると視点を変えた良い意見がでてくると思います。  

2.PCIDSSをテンプレートにしてチェックしてみる

■(1)アセスメントによる改善

 PCIDSSの要求事項(参考)はチェックシートに使えます。検討・検証することも有効な方策として推奨します。クレジットカード情報を個人情報や機密データと置き換えて考えてみてください。

 条件設定(保管期間や実施回数など)は環境によるリスク度合いで変更してください。要求事項を照らし合わせていくだけでも、上記例の(A)(B)の課題と問題を具体的な要求事項で確認及び解決できる糸口をつかむことができます。最初から緻密さや厳格さを追求するのではなく、認証基準の各レベルを理解し、徐々にレベルアップしていく手順により円滑な導入をお勧めします。
 例えば、あるシステムをリニューアルしなければなりません。そこでRFP(Requset For Proposal)作成時やリスクアセスメント時に要件1〜12に即してギャップ分析、自己診断を行います。
 監査という重苦しい体制下の現状把握も重要ですが、短い期間での定期的な見回り(チェック)体制も早期発見の重要な管理体制です。年次などの重点的なアセスメント実施と月例での限定的な範囲からでもよいと思います。環境が変わったことによるリスクの変化に気が付く重要な機会にもなりえます。全社員が普段から監査に関わり、相互チェックで組織・人を強くする良い機会にもなります。
 例えば、ログの保有期間に関しては「PCIDSS要件3.1(データ保管と廃棄に関するポリシーを作成する。)」により、インシデント(事故)を想定して調査を始めます。必要なデータ保有期間など、環境の変化に応じたポリシーの見直しを行い、システム拡張などの構成変更が発生する場合は対策実施が必要となります。突発的な機器障害などでディスクや機器の廃棄手順のミスなどが起こる可能性があります。特に、ログの保存容量の変化が著しい場合は要注意です。モニタリングによる異変のキャッチと管理担当者の管理権限の制限は厳密な管理が必要です。
 「PCIDSS要件10.1(※1)」では、人事異動の多い時期と重なりアクセス管理が徹底されていないことがよくあります。対象者と条件の食い違いが発生し、権限の高いアカウントが放置され悪用されるケースも起こりうることですので防止しなければなりません。参考情報サイトとして、IPAJPCERTなどの公的サイトは必ずチェックし活用しましょう。

※1 システムコンポーネントへのすべてのアクセス(特に、ルートなどの管理権限を使用して行われたアクセス)を
各ユーザにリンクするプロセスを確立する。
■(2)ギャップを解消させる

 一般論として予防可能な行動としては、経営陣(ここでは事業責任者)の職務は、リソースの配分です。「どこにどのようなリスクが残っている」のかを認識できれば、現場部門への調整で解決できることは多々あるはずです。リソースの問題が大きくのしかかっていたことによる無理な状況はどの組織・プロジェクトに発生するものです。各プロジェクトの予算を調整できる立場のものが状況を把握のためにネガティブな情報を集め、配分調整を行えば解決することはしばしばあります。
 品質管理に問題を抱えたまま開発・運用を遂行しているプロジェクトでは、インシデントが発生するまで無理する可能性は十分あります。まじめなリーダーはなおさらです。Webアプリケーションの開発チームのセキュリティ対策のスキル要員不足と再診断の追加予算を、後々のインシデントで発生するコストを考えれば経営判断での調整がインシデントを未然に防ぐ重要判断となります。現場責任者も計画変更依頼やリソース不足の補充を経営陣にしっかりと説明する責任があります。
 これらを円滑に改善するための推奨方法として、依存関係のない少ないメンバーをコーディネーターとして登用すること及びこれらの問題点を疑問点としてエグゼクティブレポートにあげていくことにより、互いに冷静な立場でディスカッションできるかと思います。レポートもA3横一枚で起承転結型の4項目(1.現状の実績(数値・グラフ)、2.目標との差異、3.課題・問題点、4.経営へのお願い)に箇条書きでまとめ10〜15分以内で報告します。
 
 次回(第3回目)のテーマは、ビッグデータ解析(セキュリティ編)です。現場に潜入し、ログ調査や相関分析に関する話題から取り上げたいと思います。  

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30007268


IT・IT製品TOP > Key Conductors > 江尾 一郎(ソフトバンク・テクノロジー株式会社) > セキュリティ事故現場から見える経営リスクと対策 Vol.2

このページの先頭へ

キーマンズネットとは
某セキュリティ事業会社にて、日本最大のセキュリティ監視センターの設立後、運用責任者として従事。その後、大手通信事業のCIO補佐官、自ら設置した日本初のセキュリティインシデント対応サービスの総責任者を歴任。現在はソフトバンク・テクノロジーにてセキュリティのコンサルティングおよび事業のサービス展開を行っている。

ページトップへ