2016年2月25日

2016年2月25日

2016年2月25日(木)

『災害』というセキュリティインシデント

 情報支援レスキュー隊 (IT DART)  代表理事 / 東北大学病院 メディカル IT センター
 佐藤 大

 
 サイバーセキュリティに対して、災害対策はリアルセキュリティの一つです。両者のアクションは、下記のようにとても似ています。
 
 事前対応 → 防災や減災(例:対応体制や手順の整備、建物の耐火耐震、避難場所整備)
 インシデントレスポンス → 災害対応(例:救助・救命や災害対策本部の運用)
 運用影響調査 → 被害状況の把握や分析(例:傷病者や被害家屋、避難者の把握)
 フォレンジック → 発生メカニズムの調査(例:原因や発生メカニズムの探求)
 サービス復旧 → 復旧・復興(例:インフラや家屋の修理、経済活動や市民活動の回復)
 
 一方でサイバーセキュリティ事案と自然災害とでは、大きく違う点があります。自然災害では根本原因の排除が不可能だということもありますが、扱う対象が人間だというのが最も重要な違いです。災害対応では、避難状況等のログが残らず、常に後追いで調査する必要があります。また証拠保全のための凍結ができず、システムは常に動き続けます。回復作業中には、各ノードから互いに矛盾する様々なクレームがあがります。
 
 最近では災害対応の支援にインターネットを活用することも多くなってきましたが、いざ技術的に支援しようとすると、IT技術者にとっては戸惑うことも多いようです。ありがちなのは、被災地で災害対応を行う支援者の苦労を減らそうと、便利なアプリの紹介やツール開発の提案をしても乗ってくれない、状況を聞きたいのに相手をしてもらえないという状況です。でも、災害対応がインシデントレスポンスに相当すると思うと、納得して頂けるんじゃないでしょうか。
 
 ちょっと想像してみてください。
 あなたが管理しているシステムで大規模な障害が発生しています。
 
 「あれ、DBのデータに論理矛盾が…」
 「管理系にVPN接続できないよー」
 「ユーザから復旧時期問合せの電話が来てます!」
 
 そうこうしている最中に、面識の無い業者がやってきました。
 
 「障害発生時も、弊社のアプリがあれば状況把握がスムーズです」
 「障害対応フローに合わせた業務管理アプリをお持ちしました」
 「現在のDBサーバのテーブル構成をお聞かせいただければ…」
 
 これはもう完全に『うるさい、帰れ』案件ですよね。
 
 あ、誤解されないように言っておきますが、支援活動への参加は大歓迎なんですよ!
 災害支援の現場である災害ボランティアセンターには、データセンターと違ってボランティアでも入れます(当たり前ですね)。たいていの災害ではひどい人手不足が発生するので、本当に歓迎されます。それに、作業効率化のためのアプリやツールの導入だって歓迎してもらえるはずです。ただそれは、災害対応中ではなく平時にじっくりと、腰を据えてやりましょう。
 
 もしも災害ボランティアとして支援する機会があったら、ツールを提案する前に、まずは自分に出来ることを手伝ってみて下さい。それは泥かきや瓦礫撤去かも知れないし、電話番や記録係かも知れません。現場には入らずに、機材や要員を集めて送り込むという支援もあり得ます。ともかくまずは『支援仲間』になること。全てはそれからです。人間だもの。
 
 『支援仲間』になった後はきっと、やることがたくさん見つかります。スタッフはほとんどが員数外で見習いで臨時なので、いろんなことが未整備のままで運用されているはずです。ちょっとした業務フローの調整や作業ルールの設定で、業務がスムーズになるかもしれません。ToDoリストや作業記録メモが共有できるだけで、作業管理やブログでの活動報告が楽になるかもしれません。電話対応の記録を一覧表にしたり、反省会を聞きながら議事メモをとるだけで、活動日誌作成がすぐに終わるかもしれません。などなど。
 
 そんなローテク支援が、割と求められています。
 

※記載内容は執筆者の知見を披露されているものであり、著作権は本人に帰属します。

2016年2月25日(木)

サイバー攻撃の攻撃者もまた「人」なり

マクニカネットワークス株式会社 セキュリティ研究センター
主席技師 凌 翔太

 
 サイバー攻撃の対策を打つ際、攻撃者目線を持つことが大事だと言われています。
 筆者はおもに以下の二つの意味があると考えています。
 1)攻撃手法を意識する
 2)攻撃者の心理を意識する
 1点目についてはかなり浸透してきており、多くの企業、組織で意識されるようになってきました。
 しかし、2点目についてはまだまだ意識されないケースが多いと感じております。
 
 ではそれぞれ見ていきたいと思います。
 
 1つ目の「攻撃手法を意識する」については、次のステップを実施する必要があります。

  1. ニュース、コミュニティなどから最新の脅威情報を集める
  2. 自分の組織がそれらの攻撃を受けた場合について、検知・対処の可否を考察する、あるいは可能であれば実際に試す
  3. 検知・対処ができないと判断した場合、対策を講じる

 
 2つ目の「攻撃者の心理を意識する」という点はここでは主にインシデントが発生した場合の対処方法について言及します。
 
 我々は脆弱性を突く攻撃、フィッシングメール、マルウェアなど「単体」の攻撃手法に着目しがちです。バラマキ型の攻撃であれば、十分なのかもしれませんが、執拗に攻撃をしかけてくるような標的型攻撃では、もう一歩攻撃者側の考えに近づく必要があります。バラマキ型攻撃と標的型攻撃の決定的な違いは、攻撃者が「手動」で行うオペレーションの量です。ランサムウェアやバンキングマルウェアのようなバラマキ型攻撃の場合、攻撃手法のほとんどはハードコーディング(あらかじめプログラミング)されており、一旦マルウェアを送り付けてしまえば、攻撃者が手動で何かをするということは極めて少ないです。その一方、標的型攻撃の場合、攻撃者は組織内に一旦侵入すると丁寧に「手動」でネットワーク内を探索し、機密情報を探し当て、窃取します。つまり、後者のほうが臨機応変な判断が行われます。
 
 具体例を挙げます。組織内に遠隔操作マルウェア(RAT)と攻撃者のサーバ(C&Cサーバ)の通信が見つかり、迅速にその通信をファイアウォールでブロックしたとします。この時点で漏えいした情報が皆無あるいは軽微であれば、これは一見防御側の勝利に思えます。果たしてそうでしょうか?攻撃者は人間です。通信がブロックされたことに気づくと反応をします。そうすると今度は細工された検知されにくいマルウェアを送りつけてくるかもしれません。1つ目のマルウェアの通信はせっかく検知できたのに、2つ目のマルウェアはそれが見つけられず、機密情報を盗まれるところまで行くかもしれません。つまり、迅速にブロックをすることが必ずしも正しいとは限りません。
 
 では、どういう対応が望ましいのでしょうか。

  1. バラマキ型攻撃かどうかを判断し、そうである場合はブロックをし、対処を完了させます。そうでない場合は次に進みます。
  2. マルウェアの通信はあえてブロックせずに被害が出ないように機密情報を含むサーバにアクセス制限を加えるなどした上で、攻撃者を観察し、TTP(※)を蓄積します。
  3. TTPが溜まりきったと判断できたら、戦略的に対処します。

※TTPとはTactics、Techniques、Proceduresの略で、攻撃者が用いる戦術、技術、攻撃の流れを指します。
 
 戦略的な対処とは次の通りです。
 攻撃者を観察することができると、どんな情報を盗もうとしているか、攻撃者がそれらの情報をどのように探すか、どういう脆弱性を突いて他の端末に侵入しようとするかというTTPがわかります。そのため、以下のような対策を打つことができます。
・同様の手法が使われた場合に検知できる態勢を構築する(ログ監視の強化など)
・狙われている情報を含むサーバへのアクセスを厳格にする。(ネットワーク分離、2要素認証、暗号化など)
・狙われているる脆弱性を持つシステムにパッチを適用する
そして、最終的に攻撃者をネットワーク内から一掃します。通信をブロックしたり、マルウェアを駆除するということです。
 
 つまり、さらなる攻撃もあらかじめ検知・防御できるようになるまでは、防御側が攻撃に気づいているということを攻撃者に悟られてはいけないということです。これは一見難しいと思われるかもしれませんが、それを可能とするソリューションは出始めており、技術的な困難さは低くなっております。
 
 すぐにとは言いませんが、少しでも上記のような運用に近づけるよう中長期的にでも意識していただければ幸いです。
 
 最後に、セキュリティ運用をマニュアル化する文化があります。これは属人的な仕事を減らし、経験が少ないセキュリティエンジニアでも運用できるようにするためには大変良いことですが、機械的な判断のみをすると、その判断ロジックを攻撃者に見破られ、悪用される可能性があります。標的型攻撃を受けた場合はぜひとも、攻撃者が狡猾な「人間」であるということを念頭に置き、有機的な判断をしてください。
 

※記載内容は執筆者の知見を披露されているものであり、著作権は本人に帰属します。