産総研の不正アクセス報告書から

若干書くのが怖いネタな気がしますが、公開された産総研の報告書はITインフラの運用に関わる人やその責任者は読んでおくべき文章だと思います。業務上必要だったのかが分からない点がいくつかありますが、攻撃者による情報搾取に至るまでの経緯が詳細に書かれています。批判とかではなく、他山の石として自組織に対する教訓として読んでいこうと思います。報告書は産総研の公開Webサイトでダウンロードできます。

クラウドサービスへのログイン試行

このクラウドサービスは多くの社員が使用しており、社内IPアドレスからだけではなく自宅などの社外からアクセスできたようです。そのため、攻撃者はリスト型攻撃を使用したピンポイントログインや強度の低いパスワードによるこれまたリスト型攻撃によるログイン試行を試した可能性があります。
実際、キーボードを滑らせただけのような強度の低いパスワードを使用している利用者がいた事が報告書に書かれています。クラウドサービスのログインに対するブルートフォースアタックが可能な環境であったかは不明です。

社員はこのクラウドサービスが提供するメールサービスを使用していたとのことなので、その他のシステムログインの情報をメール経由で攻撃者に知られた可能性があります。

どうするか？

これらの点からクラウドサービスのログインに施すべき点は例えば下記のようなものが考えられるでしょう。

連続したログイン失敗時にアカウントロックするなどにより、ブルートフォースアタックを封じる。
マルチファクタ認証を行い、ログインIDとパスワード以外の要素でも認証を行う。
インターネット経由でのクラウドサービスログインを禁止し、SSL-VPN等を使用して社内からのアクセスのみに制限する。

いずれも何らかのコストがかかります。直接的なコストがかからない場合でも利用者の利便性が下がります。社内のメール機能をクラウドサービスで利用している場合は利便性からインターネット経由のアクセスをしたくなるのが人情でしょう。特に産総研のような研究機関であれば出張も多いでしょうし社員からの要望も多かったのではないでしょうか。まぁメールをオンプレミスで構成していた場合でもWebメールを提供していれば環境は同等ですが・・・。

マルチファクタ認証

個人的にはマルチファクタ認証の導入がセキュリティ・コスト・利便性のバランスにとって良い選択肢だと思います。当然マルチファクタ認証の第二認証は第一認証と無関係なものを選ぶべきです。第二認証の情報をメールで伝えるような構成は無意味です。例えばSMSやトークンシステムが一般的です。

ログインID設計

一度走り始めた状態では修正が難しいのですが・・・、メールアドレスのエイリアスまたはメールアドレス自体をログインIDとすることが多いです。個人で使用するサービスの多くがそのようになっているため、利用者の心理的障壁が低いです。その分、攻撃者が必ず試すログイン情報になります。メールアドレスは名刺や論文サイト等に記載されることも多く、調べようと思えばすぐに調べられる情報です。

ログインIDを社員しか知らない情報にするだけでかなり変わるでしょう。例えば社員番号に乱数をつけたものにするような設計です。8〜10文字程度であれば利用者も覚えやすいはずです。

尚、パスワードを難解なものにするという運用ルールは経験上ほとんど意味がないはずです。例えば記号と大文字と小文字と数字を含む12文字以上とするルールの場合、例えば「!QAZ2wsx3edc」というようなキーボードを滑らせただけのパスワードでルールに適合します。パスワード変更を課したとしても、滑らせる列を一列ずらすだけで成立します。単純にそういうのをやめましょう、と訓示してもそのままにしてしまう利用者が一定数いるはずです。

業務サーバへのアクセス

クラウド上に業務サーバを構築していたようです。この業務サーバは社内サーバと連携していたのが運の尽きだったかもしれません。攻撃者はこの業務サーバにインターネットからアクセスしたようです。インターネットからのアクセスを可能とする構成が業務上必要だったかはわかりません。業務サーバから内部サーバにアクセスできるようにインターネットとの境界に設置されたファイアウォールでacceptポリシが設定されていたようです。

完全な当てずっぽうですが、この業務サーバとそのネットワーク環境はITに詳しい社員が作ったものではないのかもしれません。ファイアウォールの設計が適切でなくて外部からの踏み台にされてしまうPaaS上のサーバがあるのはありふれた話だと思います。ITインフラチームへの申請が緩い組織ではありがちに思えませんか？

非IT部門管理の業務サーバ

業務サーバから内部サーバに侵入され、致命的な自体を引き起こす直接的な原因になったのが非IT部門管理の業務サーバの存在だったようです。この業務サーバは他のサーバと異なりログイン時の送信元IPアドレス制限が行われていなかったとのことでした。これもよくある話ではないでしょうか。私も許可を得て社内システムに人力リスト型攻撃を仕掛けてログインに成功したことがあります。社内でありがちなキーワードの小文字のaを@に変えただけの単純なパスワードでした。攻撃開始から2分後にログイン成功しました。

特権IDの一覧

rootのような特権IDの一覧をExcelにまとめるのはよくあることだと思います。便利な半面、セキュリティにおける重大なボトルネックであることは認識しておく必要があります。最低でもExcelファイルの閲覧にパスワードを仕掛けておくべきです。ただ、このパスワードをどこに保存しておくのか、というようなループする問題が発生しますが。

コストを無視した場合のベストプラクティスは特権ID管理ツールを導入することでしょう。特権IDの管理は深遠な話題なのでここまでにしておきます。

サポート切れOSの使用

非IT部門管理の業務サーバはすでにサポートが終了したOSを使用していたようです。設備系のサーバとのことなので、ソフトウェアが古いOSにしか対応していなかったとか、ベンダがこうしたことに無頓着なベンダだったとかが考えられます。サポート切れのOSを使用していたことが今回の攻撃の決め手になったわけではなさそうですが、結局既知のセキュリティホールを利用されて攻撃が成立していた可能性があります。

組織体制

各部門に情報セキュリティ担当が配置されるような体制だったようですが、必ずしも全員が情報セキュリティの知識があるとは言い難い状態だったようです。これについてはむしろ組織全体に知識のある人間を配置する方が非現実的だろうと思います。こうした研究機関や医療系の機関にありがちですが、現場の研究者の意見が非常に強く、その要望が結果的にセキュリティホールを生み出してしまうような状況を何度も見たことがあります。客員研究員といった立場の社員も多く、私物PCの接続も可能になっているケースも多いでしょう。

今回の件で体制を見直すことにはなるのでしょうが、実質的な対応はなかなか難しく、セキュリティを理由に社員の利便性低下の方向に進むのではないかと予想しています。紙ベースの申請書とか増えそうですね。

ITシステムの構築体制

こうした機関ではITシステムの構築ベンダは入札によって決められます。入札は価格一発勝負の最低価格入札か、価格点と技術提案の評点を合算した総合評価入札で行われることが多いです。技術に精通していない人間が評価者になることもよくあります。公平性や透明性を重視するという建前のもと、情報システム部門とは全く異なる部門の社員が評価者になる可能性すらあります。

さらにこれらの入札は事前に公開される調達仕様書に基づいて行われます。この調達仕様書の作成すら外部業者に委託されることも多く、システム全体の詳細を情報システム部門すら把握できていないことがあります。少なくとも調達仕様書を自分たちで書ける程度には知識を身に付けるのが体制改善には良いと思いますが、こうした調達仕様書をしっかり書くのは情報システムの構築経験や提案経験がないと難しいため、短期間でこうした文化を改善することは実質的には無理でしょう。技術評価を重視するような体制にしようとすると、公平性の観点から財務部や総務部からの反発がある可能性があります。

その他

SIEMのルール

外部から内部サーバへのアクセスを特に監視するルールをSIEMに追加するようです。SIEMとして何を使っているかは分かりません。恐らく不特定多数のアクセスが想定される公開Webサーバのようなものはセキュリティ機器のアラートベースの対応をせざるを得ないと思いますが、今回の攻撃にさらされた内部サーバは外部からの通信内容が下手すると時間すら特定可能可能なレベルだと思われるので、ホワイトリストによる通信監視を行うのだと思います。もし自動連携するような仕組みになっている場合は固定的なクレデンシャルしか使わないので気がするのでログイン失敗が一回でも発生したらアラートという体制で良いかもしれません。

こうした調整を自組織でできるか入札しないといけないかで大分フットワークが変わります。私の所属する組織も似たようなものだったので何となく事情は予想がつきます。

ログイン試行の調査

資料の末尾にログイン試行と失敗回数をグラフ化した資料が添付されています。ログイン監視が非常に有用であることが見てとれます。各サーバに対するログイン発生契機をキチンと調査して、異常と考えられるログイン試行についてはアラートを出せるようにしておきたいですね。

Windowsのドメイン環境を使用している場合はKerberos認証によりログインログが複雑化します。イベントログを読み解けるぐらいWindowsの知識があるならともかく、こうした情報の可視化は何らかのツールを利用する方が一般的でしょう。いくつか製品を使用したことがありますが、アズビルフライデー社のVisuActが個人的には良かったです。決して安価ではないのですが、パケットミラー型の監視製品のため監視対象サーバに全く負荷がかかりません。

そういうわけで結構ヒヤッとすることが多い事例でした。私も今度この件について社内で意見を求められそうです。