情報セキュリティとプロダクト品質管理への真摯な取り組み

自己紹介

AIテクノロジー推進室仙台に所属する関内(せきうち)と申します。 現在は深層学習(ディープラーニング)を利用したプロダクトの研究開発に携わっていますが、情報セキュリティを得意としておりまして、他のチームから相談を受けることも多くあります。 今回はこの情報セキュリティについてお話ししたいと思います。

情報セキュリティに興味を持ったきっかけ

2006年、Webシステムの開発を得意とする株式会社アイソリューションズ（現・株式会社プロトソリューション仙台本社）に入社しました。 Webシステムと言っても、特定企業の閉ざされたネットワーク内で動くものも多く、そういった開発案件ではさほど高いセキュリティレベルを要求されることはありませんでした。しかし、セキュアプログラミングの思想は徐々にですが着実に広まっていました。

2008年頃、社内でB2Bのオンラインショッピングモールの開発が始まりました。外部に開かれたシステムですので、悪意を持つユーザがいることを前提とした対策をしなくてはなりません。このプロジェクトで様々な脅威とその対策を検討した経験が成長につながりました。

大規模サービスの開発運用

その後、外部に出向し、プロスポーツ向けのサービスや広告サービス、B2Cのオンラインショッピングモールの開発に携わりました。 多くの人が知っている一般ユーザ向けのサービスですので、攻撃手法と保護したい情報を充分に検討し、優先順位をつけて対策することの重要性を学びました。

情報セキュリティのスペシャリストとして

2009年、この年に経済産業省の「情報セキュリティスペシャリスト試験」が創設されました。第1回試験で合格。 ただ、このことよりもセキュリティについて教えた後輩が第2回試験で合格したことの方が嬉しかったです。

情報セキュリティスペシャリスト試験は2016年をもって廃止され、「情報処理安全確保支援士」制度へと変わりました。 毎年の更新講習が義務付けられており、3年間で約15万円の維持費がかかるものの、当社では全額会社が負担してくれています。ありがたいことです。

資格取得奨励制度
情報処理安全確保支援士

情報セキュリティへの取り組み

常に知識をアップデートする

近頃の動向を見ても、10年前は話題に上らなかった脅威が登場しています。知識のアップデートは特に重要です。
以下に例を記載します。（2021年6月時点）

どのように戦うか

セキュリティ対応は、平常時の対応とインシデント対応に分けられます。
インシデント対応である「封じ込め 根絶 復旧」をまず頭に浮かべがちですが、平常時の対応も重要です。

・準備（予防）
・検知 分析
・封じ込め 根絶 復旧
・事件後の対応

これは消防署のお仕事とよく似ています。
消防署は、インシデント対応である消火作業だけではなく、防火・普及啓発・警報装置の義務付け・設備の査察といった平常時の対策にも力を入れています。

脆弱性情報の収集

JVN, JPCERT, IPA, US-CERTのフィードを購読し、最新の脆弱性情報を収集しています。
Twitterや、Googleアラート（検索語句を登録しておくと、そのキーワードを含む新着記事を自動で通知してくれるサービス）も便利です。
技術情報全般に言えることですが、自分からアクションを起こさなくても自動的に情報が入ってくる仕組みを構築できるとよいでしょう。

JVN iPedia
JPCERT CC
IPA
US-CERT Alerts

情報セキュリティは日陰者？

情報セキュリティは、利益につながらないように見えがちです。平穏な時は誰も気にしないものです。
また、うまくやりすぎると、何も仕事をしていないように見えてしまいます。
プロダクトをわざと燃やした方が仕事ぶりをアピールできるかもしれませんが、それは職業倫理上絶対にやってはいけません。
平穏な時こそ、成果指標を整備し、どんなことをしていているのかを見えるようにすることが大事です。CISOダッシュボードによる可視化ができると良いでしょう。

品質向上への取り組み

品質への対応は、情報セキュリティとほぼ同じアプローチをとることができます。
品質が安定することで、次のことが達成できます。

・開発スピードの加速化
・コストの削減
・人材の増強

勉強会の実施

ここ数年で行った、品質やセキュリティに関する勉強会のタイトルをご紹介します。

・インシデントレスポンス概論/情報共有のトライアングル
・品質とリスクアセスメント
・AWS障害から学ぶこと
・品質の定量評価のすすめ
・リスクコミュニケーション
・自動車の安全技術に学ぶ システムの安全確保
・効果的なレビューの進め方
・情報セキュリティとセキュアプログラミング
・インシデントの収集と活用
・ソフトウェアの品質モデル
・品質とスピード、どちらをとる？
・インシデントハンドリング
・根本原因解析
・品質とコミュニケーション
・影響調査漏れとレガシーコード

タイトルのみのご紹介ですが、品質やセキュリティの確保の取り組みに共感いただければ嬉しいです。

実際に使ったことがあるツールや手法

・NIST SP800-61 インシデント対応プロセス
・ふりかえり (Retrospective)
・ポストモーテム (Project Post-Mortem)
・根本原因解析 (RCA)
・フォールトツリー解析 (FTA)
・故障モード影響解析 (FMEA)
・失敗まんだら
・ImSAFER

品質向上のアンチパターン

よくあるダメな例は、文書を作って対策したことにすることです。

・体制やマニュアルを作っただけで終わりになってしまい、インシデントを防げない・インシデントが起こったときに役立たない
・チェックリストの項目だけが増えて、チェックが形骸化する

また、人にフォーカスするのもよくありません

・責任追及や犯人探しになってしまい、真相究明がおろそかになる
・「注意します」「気をつけます」で済ませてしまう

現場に寄り添いつつ、何が起こっているのかを明らかにしましょう。

「気合と根性」で解決する時代は終わり

問題というものは頭を使って、システマティックに解決するべきだと思っています。
長時間労働や人海戦術・精神論が登場したら、それはマネジメントの失敗だと思ってほしいです。
品質やセキュリティは、設計段階やそれ以前のフェーズで作り込むのが重要です。

最後に

失敗しても全然OK!

これは修造カレンダーに書いてあった松岡修造さんの言葉です。
私は15年前、入社1ヶ月目のヒヨコの頃に、データベースを全て吹っ飛ばすという失敗をしました。コピー元とコピー先を取り違えたのが原因です。
当時の先輩が、「作業前にバックアップを取ってね」と教えてくれたことと、開発サーバだったことで大事には至りませんでした。

セキュリティの世界では、多層防御やゼロトラストのように、侵入されることを前提とした考え方があります。品質でも、ヒューマンエラーが起こることを前提にして、仕組みを整備することが大切です。
安全に失敗できる環境を用意してあげることも、チームメンバーの役割です。
シリコンバレーの安全文化にも、「素早く、繰り返し、安全に、賢く失敗せよ」というものがあります。

・Fail Fast
・Fail Quick
・Fail Often
・Fail Cheap
・Fail Smart

小さな失敗を繰り返すことで、大きな失敗を避けることができます。

セキュリティエンジニアを目指したい方へのアドバイス

物事の仕組みに興味を持ち、プログラミングの他に、OSやネットワーク・通信プロトコルの知識をつけるとよいでしょう。
これらを深く知ることで、脆弱性や攻撃手法を見たときに「これはOSI参照モデルの第n層で起きていることだな」と理解できます。
システムを漠然とした一つのものとしてとらえていると、何が起こっているかを理解できません。

実際の手法を知るには、IPAで公開している資料や、Kali Linux のようなセキュリティに特化したLinuxディストリビューションで体験することもできます。ただし、他社のサイトを攻撃することは違法ですので行わないでくださいね。

安全なウェブサイトの作り方
Kali Linux

この記事を読んで、情報セキュリティに興味を持ったり、大規模ITサービスを安全に運用してみたいと思った方がいらっしゃいましたら幸いです。