社内研修会を開催!~セキュリティインシデント発生!?その時どうする?~


2022年 02月 28日

今回は「とあるシステム会社」を舞台にしたストーリーをもとに、セキュリティインシデントに対する適切な対応を学び、各人のセキュリティ意識を高めていくことが目的です!

それでは本編へ……。とある日に、プロジェクトマネージャーAさんのもとにかかってきた一本の電話。それは開発したシステムにとある問題(バグ)が発見されたという「大変な事件」のはじまりでした……。。。

詳しく調査したところ、どうやらユーザーからは見えるはずのない画面(個人情報が含まれている)が見えていることが判明……!「セキュリティインシデント」の発生です……!!;0;

さてさて、ヘッドクオーターに指名されたAさんは、まずはシステムの利用者に連絡を取って状況を確認し、対応策をいくつか提案した上で、本来は「見えるはずのない画面」を、正しく「見えない状況に修正する」ことに性急に取り掛かることにします。

ちなみにヘッドクオーター(headquarters)とは、一般的には本部、司令部。またその要員のことを指します。今回はエンジニアによるシステムの調査結果や修正状況がヘッドクオーターであるAさんのもとに適宜伝えられ、またそれと同時並行してAさんは関係者と連絡を取り合い、各所で連携を取りながらこのトラブルの対応にあたっていました。本来このような問題はあってはならないことなのですが……ヘッドクオーターのもとに情報が集約され、中心となって立ち回れる状況を作ることで、もしものことが起きた場合にも、事態の早期解決を目指すことが出来るようになります。

Aさんの適切な判断と対応、そしてエンジニア達の尽力により、問題の報告を受けてからそれほど日数を置かずに、システムの修正が完了、そしてリリースとなったのでした……!

無事解決しホッと一安心……!ではありますが、他のシステムで似たような事象がないか確認しつつ、引き続き注意していきましょう……!!

最後にまとめと、10分間のワークを実施しました。聞いていて(色んな意味で)ドキドキが止まらなかった今回の研修でしたが……社員の皆さんはどのように感じられたのでしょうか?最後に、いただいたワークシートの中から一部抜粋してご紹介したいと思います。

~セキュリティ研修を受けた社員の反応・感想など~

セキュリティインシデントを防ぐために、システムの「開発フェーズ」で必要なことはなんだと思いますか?
  • 設計段階でどのユーザーがどの画面の操作/閲覧が可能か/禁止かを考慮する。実装時に抜け穴が無いかを考える。コードレビュー時にその辺りを考える。
  • 実装以前の設計レベルでのセキュリティ対策および実装後のその確認。
  • 実際に動かしてみて要件を満たしていなかったことが発覚したり、怪しい動きをした時点で先輩のエンジニアに確認を取るようにする。
  • 自動テスト・手動テストともに常に作成/実行する。手動テストに関しては、共有可能なところに明確にテスト項目をまとめてチームでレビューもする。
研修を受けて感じたこと、今後の業務に活かせそうなことはありましたか?
  • 業務中、どんな些細なことでも違和感を感じたらまず、報告連絡相談を心掛けたい。
  • 具体的な案件をもとに、避難訓練みたいにチーム内でロールプレイングをしたいと思った。
  • 個人情報にかかわりそうな部分を扱うときにはより慎重に対応しようと思いました。
  • 本当に危険なバグのテストを見落とさないよう適切なテストケースを作成できるようにしたいです。