AWS Lambda(1) : Lambdaからの戻り値取得(辞書での受け取り)

 AWS Lambdaからの戻り値を取得して表示をしてみます。Lambdaからの戻り値はjsonなので、辞書で書いておくと便利なようです。Lambdaで作成した辞書を戻り値として、それをpythonで取得をしていきます。

(1) Lambdaで関数作成

Lambdaから関数の作成を図のように行います。関数名は任意ですが、ここでは「MyFunction001」、ランタイムは「Python3.9」、アクセス権限はデフォルトの実行ロールの変更から「既存のロールを使用する」「LabRole」(これはAWS Academyの場合なので、それ以外は任意です)とします。

さらに詳細設定から、「関数URLを有効化」にチェック、認証タイプは「None」とします。これで関数の作成をクリックします。

次のような画面が作成されます。

(2) Lambdaのソースコードを編集

デフォルトでできたコードは「Hello from Lambda!」と表示されるものです。今回関数URLを有効化してあるので、そのURLにアクセスしてみます。

bodyのところに、辞書を渡してあげると都合が良さそうなので、今回は簡単な辞書を渡します。

ソースコード

実行するには、Deployを押してからURLにアクセスします。

(3) 外部プログラムから、Lambdaの戻り値を取得

今度はGoogle Colabでもどのような環境でも良いので、Lambdaの関数URLにアクセスして、情報を取得・表示します。以下のコードを作成して、実行します。ここではGoogle Colabでやっています。

ソースコード

これで、Lambdaで処理したものを外部プログラムで取得できました。

ホストログの分析3 : 推移確率行列の算出

 第1回で求めた「wls_day-07_all.csv」に対して、推移確率行列を求めていきます。まず、状態空間を何にするかを検討する必要がありますが、第2回でEnvetIDに対して頻出回数を求めました。今回もEventIDを状態空間として、時系列にどのような推移があるかをカウントし、推移確率に直していきます。

・ライブラリの利用：mpi4py

今回のプログラムは利用者が数万人ですので、一人一人の推移を確認していくと、かなりの時間がかかってしまいます。そのため、並列計算を用いて、各プロセスに計算する利用者を割り振り、計算時間の短縮をはかります。注意として、並列計算をすると各プロセスでメモリを消費するので、今回プロセス数は8で実施しました。計算時間は約1時間ほどでした。

・工夫している点：状況をファイルに書き込み

並列計算をしていると、mpi4pyではターミナルへの標準出力が途中ではされなくなってしまいます。実行の状況を確認するために、プロセス0ではファイルの書き込みを行い、どのような段階にあるかをファイルを見ることで確認できます。Linux系OSでは、「tail -f ファイル名」で更新している様子が自動更新されわかりやすいです。

最後に、各プロセスでカウントした推移をプロセス0で集約して、行和を1にすることで正規化しています。これで推移確率行列ができています。

ソースコードリンク：https://github.com/smzn/CyberSecurity_MarkovChain/blob/main/HostEventsTransition.py

ネットワークログの分析3 : 同値類の算出

 デバイス間の推移確率が求められたので、次はこの推移確率から同値類とその同値類中の中心ノードを算出していきます。利用するファイルは以下のファイルです。transition_count_non0_rate.csv

このファイルを取り込んでいきます。

この推移確率行列から、デバイスを状態として、状態を同値類に分類していきます。同じ同値類であることは、相互到達可能であることを意味します。デバイス間で相互到達可能の集合がいくつあるかを調べていきます。次の関数を利用します。

getEquivalence4(th, roop, p)関数

この関数は3つの引数(th, roop, p)を持ちますが、thは推移しているとみなすことができる閾値です。つまり、この値より推移確率が大きいとき、推移があると考えます。roopは何回で到達可能かを示す値です。pは推移確率行列です。戻り値はmodify_equivalence, class_number, reachableがあります。modify_equivalenceは同値類ごとにデバイスが分類されています。class_numberは同値類の数、reachableは状態間で推移が可能かどうかを{0,1}で表した接続行列です。

もう一つ関数を作っていきます。

getDegreeMax(equivalence, reachable)関数

これは、同値類の中で中心性のノードがどれかを計算しています。次数中心性で求めています。

今回の計算結果では、

同値類数が6964個、

最大クラス数 : 18090、

最大クラスを持つindex : 0 

最大クラスの最大次数を持つノード番号 : 6947、

デバイス名 : Comp186884

となりました。ここまでの結果で同値類数、同値類の中の中心性デバイスの情報がわかるようになりました。

全体のソースコード : https://github.com/smzn/CyberSecurity_MarkovChain/blob/main/EquivalentClass.py

ホストログの分析2 : 出現回数のカウント

 前回csvを作成しましたので、それを取り込んで各要素でどんな出現があるかを確認していきます。データに含まれている要素は、以下になります。

'UserName', 'EventID', 'LogHost', 'LogonID', 'DomainName', 'ParentProcessName', 'ParentProcessID', 'ProcessName', 'Time', 'ProcessID', 'LogonTypeDescription', 'AuthenticationPackage', 'LogonType', 'Source', 'Status', 'ServiceName', 'Destination', 'SubjectUserName', 'SubjectLogonID', 'SubjectDomainName', 'FailureReason'

この中で、取得までに時間がかかる項目は、'LogonID'、'ProcessID'、'Time'で実際やってみると24時間以上かかります。(UserName(19314s) -> 5.3時間、ProcessName(4836s) -> 1.3時間, ParentProcessID(24928s) -> 6.9時間とかかりますが、24時間以内ですので、なんとかなりそうです。)
今回はこの'LogonID'、'ProcessID'、'Time'項目以外の項目を、各要素に出現する項目の出現回数を取得して、どのような内容になっているかを確認していきます。今回は単純計算なので並列計算は使いません。

ソースコード(HostEvents_Element_Count.py)

これを実行すると、以下のようなデータが得られます。(wls_day-07_EventID.csv)

これを算出することで、どんなイベントがどのような頻度ででているかがわかります。まずは基本分析として、各要素のイベント出現回数を調査しました。