ワークフローサンプル: 第553話：脆弱性緊急メールに組織的な対応

業務：脆弱性対応プロセス

「弱点のないソフトウェアはない」、、、らしい（涙）

つまり、無数のソフトウェアが組み込まれているコンピュータや通信機器は「弱点だらけ」なワケだ。それにもかかわらず、会社には沢山のコンピュータや通信機器がある。社員が使うパソコンもあれば、会社ホームページのためのサーバコンピュータもある。売上や給与を管理する業務システムだってある。。。

情シス部による「脆弱性（ぜいじゃくせい）対応」とは、カンタンに言えば「ソフトウェアの補修作業」だ。

具体的に言えば、情シス部は日頃から「IT情報サイト」や「Google Alert メール」で脆弱性情報を収集し、それが会社のコンピュータで使われているソフトウェアに関する情報であれば、「パッチの適用」や「バージョンアップ」といった作業を行うのだ。最近は「自動パッチ」や「自動更新」が行われるソフトも多くなっているとは言え、それでも「手動対応しなければならない事案」は少なくない。

なお、年に１・２度、日ごろの補修作業がキチンと行われているかのチェックをかね、専門業者によるセキュリティテスト（「脆弱性検査」という）が行われる。

課題：属人的な対応

ただ、、、今日では、凄まじい数の「攻撃方法」が毎日毎日発見されている。

古いソフトウェアに関する「攻撃方法」も毎日のように報告される。日々の補修によって「弱点」は克服されていっているハズなのだが、攻撃アイデアや攻撃力も日々向上しているのだろう。永遠に無くなりそうにない。たとえば CVE 公表される「脆弱性」は年間１万件以上にものぼる。（CVE：Common Vulnerabilities and Exposures ／脆弱性情報データベース）

もはや、情シス部が全てに目を通せる量ではない。ベテラン社員がその「嗅覚？」と「属人的な情報ネットワーク？」によって機転を利かせて対応しているのが現実だ。

うーむ、、、もう少し組織的に対処できないモノだろうか？

もっと言えば、「緊急を要する脆弱性」について誰がどのような判断をしたのか・しているのか、についてキチンと記録・共有したいものだ。たとえば「ShellShock」や「Heartbleed」といった世間を騒がせた脆弱性に、いつ誰がどのような対応をしたのか、振り返りたいと思うのだが。。。 (OpenSSL, GNU bash)

「ゼイジャクセイ、対策しろと、言われても…」（情シス川柳）

[脆弱性対応プロセス]

解決：緊急情報メールに対して組織的対応を行う

ここで紹介している業務プロセス定義（ワークフローアプリ）は、公的機関等からの「注意喚起メール」をトリガーとしています。（jpcert.or.jp 等）

すなわち、「深刻且つ影響範囲の広い脆弱性などに関する情報」がメール配信されれば、メッセージ開始イベントによってワークフローが自動的に起動される仕組みです。（平均して、週に１・２件程度）

ワークフローが開始されれば、情シス部門の担当者は『1.自組織への影響度を判断』（ヒューマン工程）を行います。そこで「影響なし」が選択された場合にはワークフローは終了します。しかし「影響あり」が選択された場合には「部内通知」（メール送信イベント）を経て『2.対策作業計画の策定』に進捗していきます。

この様なワークフローで「脆弱性対応業務」を組織的に行えば、「誰がどんな判断を行ったのか」「いま誰が対応しているのか」について、リアルタイムで社内共有することが可能となります。また「過去の脆弱性対応」についても、様々な振り返りができるようになります。（社内ソーシャルでのチャット議論も紐づけておきたいところです）

考察：体制強化以外の事前対策

迅速かつ確実にパッチが適用される「体制」を整えることは非常に大切です。しかしそれ以外にも、様々な事前対策を行うべきだと言えます。

たとえば、(1)ソフトウェアの数を減らす、(2)SaaSに移行する、といった視点で『ソフトウェアの所有』そのものを見直せば、「攻撃」を受けるポイントを減らすことができます。

また、万が一の「攻撃」があった際の被害を低減すべく『データの保有』そのものについて見直すという視点も重要です。たとえばクレジットカード情報のように、社会的要請として「非保持化」が求められるケースも少なくありません。（2018年3月までの非保持化：『クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画』経産省 2016年2月)

なお、どうしても自社運用が必要なソフトウェアについて、『アクセスしづらくする』という視点も重要です。たとえば、社内と取引先しか利用しないウェブアプリケーションなのであれば「接続元IP制限」というアクセス制限をかけておくことで第三者からの攻撃リスクを大幅に下げることができます。延いては「対策作業計画における緊急度」を下げることが可能になると言えます。

[脆弱性対応プロセス：「1.自組織への影響度を判断」画面]