プログラマーはなぜ脆弱性対策をしなければならないのか　情報セキュリティの基本的な捉え方

# おきまり
こんにちは。[CYBIRDエンジニア Advent Calendar 2017](http://qiita.com/advent-calendar/2017/cybird) 5日目担当の@pakchee こと竹本と申します。
4日目は@ntrv さんの「golang 知っておくと役立つ5つのTips」でした。こだわりのある、@ntrvさんらしい話でした。

さて、Advent Calendarとはクリマスまでのカウントダウンを楽しむ仕組みですね。
今年の嫁へのクリマスプレゼントを何にしようかまだ決まっておらず、私の中では焦りのカウントダウンも進行しております。

# はじめに
では本題に入っていきます。
QiitaではプログラミングTipsの話題が多いと思いますが、今回は手法そのものでは無く、なぜその手法が重要なのかをお伝えします。
私はCYBIRDで9年ほどエンジニアをしており、スマートフォンゲーム案件などエンタメ分野でのプログラマー、SE、マネージャーと経験して来ました。
直近2年は情報セキュリティ対策に注力し始め、経験から見えて来た事をお伝えします。
エンタメ案件のプログラムをゴリゴリ書いていた時に、知っていたら良かったなと思える話です。

さて、情報セキュリティと言われて、プログラマーが真っ先に浮かぶ事は脆弱性かと思います。
システムを開発するにあたって、脆弱性が無い事は良い事ですが、なぜ良いのでしょうか？
また、良いとは言われつつも、人命や財産に直結しないエンタメ案件では、脆弱性対策が後回しにされるケースも多いのでは無いでしょうか。
実際に私も、重要だとは感じているものの、どう考えて落とし込むべきが最初は分かりませんでした。

情報セキュリティの問題を、現場の皆さんがこうして行くべきだよねと言えるよう、今回は取っ掛かり部分をお伝えします。

# なぜこれが課題で取り組む必要があるのか
情報セキュリティ対策を行なっても直接的に売上は上がりませんせん。コストも発生し利益を圧迫します。
ではなぜ行うかと言うと「リスク」という言葉で表す事ができます。

## リスク
リスクと捉えている悪い事が現実に起きてしまう事を「顕在化」すると言います。
情報セキュリティにおけるリスクが顕在化すると何が起きるでしょうか。
影響度合いが大きな一例としては、ここ数年世の中で話題になる事が多くなった個人情報流出です。
流出により、損害賠償、企業ブランド力低下、それらをリカバリーするために工数が発生するなど、その事業は打撃を受けます。

# 影響度合いを測る3つの指標
では、皆さんが扱っているシステムにおいてこのリスクの大きさはどれぐらいでしょうか。
情報セキュリティの影響度合いを測るには3つの指標をお勧めしています。

## システムに穴はあるか（脆弱性の有無）
そもそも今回の話の取っ掛かりです。プログラマーやSEであれば真っ先に浮かぶものですね。
出来ては困る事が出来てしまう欠陥です。

## システムに守るべきものはあるか（情報資産の有無）
漏れても困らない公の情報であったり、止まっても困らないシステムはあえて守る必要は無いという事です。
その様な状況はあまり無いかもしれませんが、持っている情報によって、影響度合いが変わってきます。
特に、リスクの部分でもお伝えしましたがよく扱われて影響度合いが大きいものが個人情報です。

個人情報が流出し、損害賠償問題となるケースは増えてきていますが、その賠償額を予め算出しておくと影響度合いが明確になります。
NPO法人[JNSA](http://www.jnsa.org)から個人情報漏洩の被害価値算定基準が公開されており弊社も参考にしています。

```
想定損害賠償額　＝　基礎情報価値 [500]
　　　　　　　　　　　　　　× 機微情報度 [Max(10^x - 1 + 5^y - 1)]
　　　　　　　　　　　　　　× 本人特定容易度 [6,3,1]
　　　　　　　　　　　　　　× 情報漏えい元組織の社会的責任度 [2,1]
　　　　　　　　　　　　　　× 事後対応評価 [2,1]
```

という式で表され、ある種類の個人情報1件の賠償額が算出できます。

例えば、会員認証機能のあるシステムでメールアドレスを貯めているというケースは多いと思いますが、
このメールアドレスも個人情報に該当します。
この基準によると、メールアドレス1件の賠償額は1000円になります。
もし、10万ユーザ抱えていて全てが漏洩したら、

```
1,000円 * 100,000件 = 1億円
```

賠償額1億円です。

## システムは狙われているか（脅威の有無）
大事な情報を穴が空いたシステムで保持していても、それを狙う人がいなければ実害は無いという事です。
インターネット上に公開されているサーバと、社内からしかアクセスできないサーバでは狙われる可能性は変わってきますよね。
また、文化や国民性によっても変わって来ます。
私が運用に携わっていたシステムでは、女性をターゲットにしたサービスよりも男性をターゲットにしたサービス、日本国内よりも海外をターゲットにしたサービスの方が、チートも含めて狙われる確率は高くなっていました。

# 対策
では、この3つの指標をそれぞれ改善するにはどういった手段が取れるでしょうか。
本当に基本的な対策は以下です。

## 脆弱性
まずは脆弱性の含まれていない、OS、ミドルウェア、フレームワーク、プラグインなどを使いましょう。
ソフトウェアは時間と共に脆弱性が見つかるケースが多いです。
システム構築後はアップデートされない状態が長く続いているといったケースもあるのでは無いでしょうか。

次に、皆さんが開発したアプリケーションに脆弱性を含めない事です。
脆弱性はバグの一種です。テストする事で軽減できます。
弊社では、Androidアプリケーションに対しては[SDNA セキュアコーディングチェッカー](http://www.sonydna.com/sdna/solution/scc.html)、
Webアプリケーションに対しては[UBsecure VEX](https://www.ubsecure.jp/vex/vex)という脆弱性スキャナーを活用しています。

## 情報資産
不要な情報、特にリスクの大きい個人情報を保持しない事です。
次に保持する場合でも、万が一漏れた場合に簡単に読み取られ無いよう、ハッシュ化や暗号化など難読化して保持しておく事です。

弊社ではサービス毎の個人情報保持件数を集計し、個人情報重要度の重み付け、想定損害賠償額の算出を行なっています。

## 脅威
そのシステムに必要最低限のユーザしか辿り着けないようにしましょう。
管理ツールであれば従業員のみアクセスできれば事足りる事も多いでしょう。
配信地域が決まっているサービスであれば公開範囲を限定します。

弊社では、社外から管理ツールにアクセスする場合は、社給PCからVPN経由でのみアクセスを許可するよう制限しています。

また実際にどれぐらい脅威、攻撃されているかモニタリングするにはIDS/IPS、WAFと言った手段が有効で、弊社でも検証を進めているところです。

# どこまで対策するか
各指標改善のための対策方法は見えて来ましたが、対策そのものだけがリスクの管理方法ではありません。
リスク管理は以下の4つの方法が取れます。

## 回避
脆弱性などリスクとなるものを完全に取り去る事です。
上記で上げた対策を実施する事です。

## 軽減
部分的に対策を講じて影響度合いを下げる事です。
上記で上げた3つの指標の一部を改善し、全体の影響度を下げると言ったケースです。

## 転嫁
システムの運用をリスク含めて他社へ移管する事です。
また、サイバーリスク保険に加入すると言ったケースです。

## 受容
影響が小さいものは対策を行わず、許容範囲内とする事です。

#まとめ

- 情報セキュリティ対策は脆弱性対策だけではありません。
- 影響度合いは、　脆弱性の有無 × 情報資産の有無 x 脅威の有無　で表せられます。
- 全てを完璧に対策するのでは無く、リスクを軽減、転嫁、受容する方法もあります。

3つの指標、対策方法、リスク管理方法を通して、皆さんが扱うシステムの影響度合いと落とし所も見えて来たのでは無いでしょうか。
それにより、改めて脆弱性対策への力の入れぐらいも判断ができていれば幸いです。

# もっと知識を深めるには
今回お伝えした事は、情報セキュリティ対策の本当に取っ掛かりの部分です。
深く広く進めて行くとリスクアセスメントに繋がってきます。
体系的に学ぶには、IPAが実施している情報処理安全確保支援士（旧セキスペ）試験への挑戦をお勧めします。

# 最後に
硬い地味な話でしたね。とは言え、せっかく皆さんが世の中に提供した価値がワルモノにならないよう、気に留めてもらえれば幸いです。

さて、[CYBIRD エンジニア Advent Calendar 2017](http://qiita.com/advent-calendar/2017/cybird) 明日は、
@cy-nana-obata さんの「去年のド文系プランナー女子が進化してちょっと技術領域にも脚の小指くらいをツッコミ始めた話」
です。もっと明るい話になると思います。
楽しみですね！