リスト型アカウントハッキングによる不正ログインへの対応方策について　メモ

総務省から「リスト型アカウントハッキングによる 不正ログインへの対応方策について（サイト管理者などインターネットサービス提供事業者向け対策集） 」がリリースされました。そちらについての思うところメモ。

【P2】

このようなリスト型攻撃から個人情報や信用情報などを守るためには、利用者において、自身のＩＤ・パスワードの管理に際して対策を実施していただく必要があることは言うまでもありません。しかし、リスト型攻撃による不正アクセスの発生やそれに伴う個人情報の漏洩は、企業のコンプライアンス上問題となり、企業の信用を損ねる恐れがある他、内部調査及び復旧のためにサービスを停止する事態になれば、多くの機会損失が発生することになるなど、サービスを提供する事業者自身の問題とも言えます。

ユーザが設定するパスワードが推測可能なものか、使い回しているかということは最終的にユーザの責任において行われるべきものだと思います。
そこでユーザにきちんと注意喚起や保護する仕組みを提供することはサービス提供側が行ってほしいことではあると思います。しかし、おんぶに抱っこをしないからといって、それが企業コンプライアンスに関わるのかというとそれは違うと思います。
この類の話をするときにボクは自動車メーカーとドライバー（運転手）の話をします。自動車メーカーはサービス提供側、ドライバーはユーザです。
調べてみると分かるのですが（たとえばこのあたりとか）自動車メーカーは安全に対して様々な技術を取り入れています。エアバッグ、歩行者障害低減ボディ、アクティブセーフティ技術などなど。
こういった安全技術が取り入れられていたとしても、ドライバーが飲酒、スピード超過など危険運転を行ってしまっては元も子もありません。

これと同じでサービス提供側とユーザで各々が担う部分があり、双方の努力と歩み寄りを行うような空気や理解を広めていかなければならないのだと思います。サービス提供側が一方的に攻められ負担を強いられるようなセキュリティではあってはならないと思うのです。

【P4】

②　パスワードを定期的に更新し、リストを陳腐化する

とありますが、複数のサイトで同一のパスワードを使い回していなければ「定期的」に変更し続ける必要はないと思います。サービスから漏えいが発生してしまったのであれば、ユーザへは漏洩が発覚したときに利用されていたパスワードを使って不正ログインできないようにするために一度変更してもらえばよいはずです。もしくは、サービス提供者の側でリセットを行い、以前使っていたパスワードとは別のものを再設定してもらうよう注意を促すほうがよいのではないでしょうか。もう少し踏み込んだサービス提供側のアクションとしては、他のサービス提供者で漏えいが発覚した際には、そちらの情報を元に注意を促したり、自サービスでパスワードのリセットなどを行うといったことも最近はちらほら行われてきているようです。

【P5】

(2)パスワードの有効期間設定

これに関しては同意できません。
パスワードの定期変更の理由として、定期変更のタイミングで被害を食い止めて、被害の拡大を防止するというものが挙げられますが、これは「情報は盗まれる。不正利用はされる。でも、され続けない。」という些細な効果しかないと思っています。ここの項目では有効期間を設定する理由として、どこからか漏えいしたID、パスワードのリストを陳腐化させるというものが挙げられているのですが、文末には

また、有効期間も一年、半年にするなど、事業者で管理している情報の価値に応じて設定することも一案です。

とあります。
仮に半年とした場合、最長で半年間は不正ログインされ続けることになりますのでリストを陳腐化することができる有効な対策とは言えないと思います。
数時間から数日で攻撃者は欲しい情報を手に入れていくことでしょう。
だからといって変更の感覚を短くすることはユーザへの負荷を高めるだけで利便性を大きく損ない、まさに本文に書いてある通り

ただし、パスワードの有効期限を短くして利用者に頻繁に変更を求めすぎると、利用者が、他人に推測されやすい簡単なパスワードを設定する傾向に陥りやすく、窃取される危険性を高めることもあるので注意を要します。

を招いてしまうことになると思います。

リストを陳腐化させることに対して敢えて、定期変更が有効であるという理由を挙げるとするならば、リスト型攻撃を行った攻撃者がリスト内の有効なアカウント（不正利用可能なアカウント）を確認した上で自分ではそれ以上のことを行わず、他者に売り渡すというパターンでしょうか。それでもやはり半年というのは悪用することにおいて十分な期間とも考えられますし、そもそも、リスト型攻撃のような分かりやすい攻撃が発生していることをサービス提供側がいち早く検知し、対処を行う仕組みを用意することのほうが必要で有効であると言えると思います。
（これについてはP11で触れられていますね。）

【P11】

②　攻撃が行われているIPアドレスからの通信を遮断する

これは有効だとは思います。
しかし、11月に起きた「GitHub」への攻撃では4万あまりにIPアドレスを使った攻撃（リスト型攻撃ではなくブルートフォース攻撃と言われている。）であるとのことですので、そういった場合は、有効性が低くなるということは理解しておく必要があると思います。巷には、リスト型攻撃対策として閾値を超えるログイン試行があった場合はその攻撃元のIPアドレスをブロックするという製品がありますが、リスト型攻撃を行われた場合、そのリストの質によっては、はその閾値以下のログイン試行は成功/失敗確認が取れるということになります。5回を閾値として6回目以降をブロックというものであればIP数 x 5回の確認は行えるということになります。また、閾値が外部から挙動をチェックすることで分かればその閾値以下ギリギリの試行を行って、別のIPに切り替えるということをすればブロックされたことを通知するようなアラートがあった場合、そのアラートは上げさせないということもできそうですね。
IPアドレスを頻繁に変えつつ試行を行っても短時間に行われれば通常よりも集中したアクセスであると検知しやすい側面があるのかもしれませんが、今後はもしかすると時間をかけたものも現れるのかもしれませんね。この辺りは攻撃者のトレードオフに対する考え方にもよるのだとは思いますが。

【さいごに】
リスト型攻撃って本当に厄介なものだなと思うわけですが、冒頭にも書いたようにサービス提供側とユーザ双方の努力と理解による歩み寄りが必要性が顕著に表れているものだなと思います。
過去にセキュリティって誰のためのものなのか？ということを考えたことがあるのですが、セキュリティって一部の専門家のためのものではなくて、脆弱性から保護することよろしく、弱い者（あるいは物、箇所）を守るためにあると思いました。とすれば、守る者と守られる者がいるわけで、つまるところ、みんなのものだと思います。みんなのものであればみんなで役割分担、当事者意識を持っていけるようなものにしていかないといけないなって心底思います。

地道でも頑張っていかないといけないなって改めて思います。