「Applibot Advent Calendar 2021」 17日目の記事になります。
前日は @MuuSan さんのチームビルディングはぬるくないという記事でした!
1. はじめに
皆様こんにちは。アプリボットのサーバサイドエンジニアをやっているノディです！
気づけば12月、新たな環境に身を置き、日々様々なインプット・アウトプットに取り組んでいます。
今年のアドカレでは、昨年までの整理という意味を込め、大学でついこの前の3月まで取り組んでいた研究 について書きます。
どんな研究をしていたかを掘り下げて詳細に書こうと思いましたが、今回は研究内容だけでなく、研究の中で作ったプログラムや環境についても簡単に触れてみようと思います。
研究の詳しい内容については、末尾にあるリンクから論文を読んでもらうか直接アタックしに来てください！
2. 研究の概要
背景
大学の研究室では**『企業のセキュリティ』** という、今の仕事であるIT業界に近しい分野に関わっていました。僕が研究していたのは、マルウェアのような企業を対象としたサイバー攻撃へ対策を行った後、それでも社内ネットワークに残ってしまうリスクを定量的に分析し、新たな対策を提案するシステムです。
少し前までは、不特定多数を対象とした、いわゆる愉快犯的なマルウェアが流行っていました。これを読んでいる皆様の中にも、変なファイルをダウンロードして大変な経験をしたことのある人がいるかと思います。
ですが、現在はそんなネタ要素の強いマルウェアとは打って変わり、企業など特定の標的を悪意を持って狙うマルウェアが主流となっています。これらは金銭や情報流出などを行い企業に損害を与えるため、適切な対処をすることが必要です。
※最新のセキュリティに関する詳しい話は、IPAのサイトなどにまとめられています。
研究室では先行研究として、この攻撃を受けた際にリアルタイムで対策を提案するシステムを考案していました。しかし、対策を行ったにも関わらず被害が発生してしまうことがあります。それは、活動しているマルウェアの他に潜伏しているマルウェアが存在した場合です。この場合、見えている被害にのみ対策を行っても、後々に気がつかないところで被害が発生してしまうことが懸念されます。
研究内容
そこで僕の研究では、対策を適用した後に、残っているマルウェアの被害を叩き潰すための対策をあらためて提案しよう！ という趣旨のシステムを作っていました。
対策を提案する上で意識することが必要なのは、ガチガチなセキュリティ対策をとることが必ずしも良いとは限らないということです。例えば、影響の少ないマルウェアに対して、社内の全ネットワークの封鎖など極端な対策を行うと、業務に多大な支障が出てしまいます。対策による業務への影響と、マルウェアによる被害とを天秤にかけ、ちょうど良いバランスで対策を行うことが求められます。
対策を提案するにあたり、社内の各端末のマルウェア感染可能性 と、社内で管理されているリソース（ファイルなど）の重要度 という2つの基準に着目しました。
端末のマルウェア感染可能性
ざっくり言うと、感染してそうな端末ほどめちゃくちゃ気をつける必要があるよ！といった雰囲気です。
社内ネットワークでの感染が発覚している端末と頻繁に通信をしていた端末や、感染が発覚している端末と同じようなメールを受け取っている端末は感染している可能性が高いと考えられます。この感染可能性の算出には、下のような色々な要素を用いました。
- 受信メールの送信元アドレスとその数
- 端末が通信を行なっている対象のアドレス
- 感染が発覚している端末からの通信経路
- 開放ポート数
詳しい計算式は省きますが、これらの要素を組み合わせることで、各端末の中で優先度の重み付けを行いました。
リソースの重要性
ざっくり言うと、少人数しか触れないようなファイルとか偉い人ばかりが見ることのできるファイルは重要度高いよね！といった雰囲気です。
多くの企業では共有リソースという形で、特定個人の端末上ではなく複数の人がアクセスできる場所にファイルが存在することが多いです。それらは感染後に流出してしまう経路が多く、かつ重要なファイルが置かれることが多いため、より一層気をつけることが必要です。そのため、それらのファイルにアクセスできる社員の人数や役職などを考慮し、重み付けをしました。
これらの指標をもとに、各対策の効果を数値として表し比較しました。
マルウェアへの感染可能性が高い端末を封じ込められている、かつ重要なファイルが流出するリスクが少ない対策ほど評価が高くなるようにしました。
以上が、ざっくりとした研究の概要です！
（え？全然ざっくりじゃないって？？）
3. 実験で作ったプログラム
理論を提唱した後には、実験が欠かせませんね！
ありがたいことに、僕の所属していた研究室では非常に充実した実験環境が整っていました。
30台近くのWindowsPCや、4台のサーバを駆使して実験を行いました。
想定した実験では、社内ネットワークを想定した環境内で、1台の感染が発覚した端末と、数台の感染が発覚していない端末がいる状況下で適切な対策を提案できるかどうかを検証しました。
（当時は全PCに同時に設定を反映させるのではなく、一台一台手作業でIPアドレスや設定を行なっていました......）
提案したシステムの実験を行うにあたり、以下のような処理を行うプログラムを作成しました。
- 端末間の通信ルールを解析する
- 端末間の距離を分析する
- 端末の開放ポート数を調べる
- マルウェアを模倣したプログラム
- ルータを通過する通信を記録する
- ファイルを管理するサーバから情報を集める
- 各要素を収集し評価値を算出する
言語はPythonを使用しました。
コードは手元にないので詳細な実装は書けませんが、ざっくりとどんなことをやっていたかまとめます。
実装した処理
端末間の通信ルールを解析する
想定するネットワークではルータにおいて、どの端末がどの端末と通信できるかというルール（アクセス制御リスト）が設定されてます。実験ではルータからこれらのデータを取得し、各端末がどのような通信を行えるかを解析しました。
今回は実装しきれませんでしたが、ポートの種別による重みづけも考えていました。
端末間の距離を分析する
解析した通信ルールを用い、ある端末αから端末βまでいくつの端末やスイッチを経由するか、という基準で距離を算出しました。効率的に算出を行うため、今回の実装では端末同士が感染端末からどれくらい離れているのか、という観点ではなく、感染端末からの距離ごとに端末をグルーピングする形で対応しました。
端末の開放ポート数を調べる
ルータから各端末に向けてnmapコマンドを実行し、その結果を集計しました。
nmapコマンドとは、実行することでその端末が開放しているポートを調べることのできるコマンドです。
マルウェアを模倣したプログラム
感染端末の中で、特定のアドレスに対して断続的に通信を行うプログラムを実装しました。今回の実験ではマルウェアが攻撃者のサーバに対して情報を送信し、情報漏洩を行っていることを想定しています。
これは多くの情報漏洩を行うマルウェアに共通する特徴で、標的にバレにくいように細かい単位で長期間にわたり、データを送信し続けるという挙動をとることに基づいています。
ルータを通過する通信を記録する
上記のように、感染端末は特定の不審なアドレスに対して高頻度で通信を行っていることが考えられます。そこで実験では、一定期間内にルータを通過した全てのパケットの宛先IPアドレス、送信元IPアドレスを取集しました。
実験の際には実現できませんでしたが、virustotalというサイトを利用することでURLの脅威度を数値化することを検討していました。
ファイルを管理するサーバから情報を集める
想定する企業では、社内のファイルサーバにて共有のファイルなどを管理していました。
ファイルサーバへのアクセス制御を行うために、本実験では企業に多く採用されているMicrosoftのActiveDirectoryを導入しました。このActiveDirectoryに登録されているアクセスルールを収集し、各リソースの属性と比較をすることで、各端末がどのリソースにアクセスできるのか、どんな属性の社員がこのリソースにアクセスできるのか、といった情報を分析します。
各要素を収集し評価値を算出する
それぞれの処理によって生成された値を集め、用意した評価式を適用することで評価値を算出しました。
jsonやXMLなどを駆使しまくったコードだったため、ネストが深く非常に複雑な実装になってしまいました。
このようなプログラムを用い、検証実験を実施していました。突貫で作ったので可読性はお察しですが、アプリボットでの内定者バイトで得た知識を使って多少マシになったのでは、と思っています。
4. おわりに
以上が僕の大学4年生で研究した内容となります。
一括りにセキュリティという分野の中でも様々な観点があり、その中でより良い理論を追い求めるという体験ができたのは本当に貴重な経験だったなと、振り返って感じております。
自分の中で範囲を決めて勉強するだけでなく、広い視野で知識や経験を積んでいくことも忘れてはならないなと改めて意識した折です。
ぜひ、面白そうなテーマがあったら教えてください！
5. 発表した論文一覧
2020年11月 電子情報通信学会
2021年1月 ICISS 2021: 2021 The 4th International Conference on Information Science and Systems
[2021年3月 電子情報通信学会] (https://www.ieice.org/ken/paper/20210301MCDg/)