この記事は NEXTSCAPE Advent Calendar 2020 の 7 日目の記事です。
この記事について
Azure Security Center の Azure Defender for Storage について触ってみました。
Azure Security Center の Azure Defender for Storage は Azure Storage を保護/脅威の検出をするサービスになります。
その中に、Blob Storage 内のファイルをスキャンしてマルウェアファイルを検知する仕組みが搭載されています。
今回、このマルウェア検知の部分を簡単に触ってみたので、どのようなサービスなのかをざっくりと捉えていただければと思います。
要約
伝えたいことを簡単にまとめてしまうとこのような感じです
- セットアップは簡単、LogicApp とも簡単に連携できるのでワークフローの自動化も容易い
- マルウェア検知されるまで結構1時間以上タイムラグある
- アーカイブされたマルウェアファイルは検知出来ない
- 現状、簡易的なマルウェア検知の仕組みとして捉えておく感じが無難
基本的な情報とか
今回初めてこの機能に触れる前に知っておいた方が良いことをいくつか並べておきます
マルウェアのハッシュ評価分析について
まずはじめに、どのような分析をしているのか理解しておきましょう。
Azure Security Center の Azure Defender for Storage によるマルウェア検知は、マルウェアのハッシュ評価分析を用いた仕組みになっています。
これは、ファイルのハッシュ値と既知のマルウェアファイルのハッシュ値を比較する形になっています。
実際にファイルをスキャンしている訳ではないので、中身はマルウェアでもファイルのハッシュ値が既知のハッシュ値にない場合は検知できずスルーされます。
既知のハッシュ値はおそらく Azure 全体のセキュリティ部門がアップデートしているものと思われます。
Azure Security Center の費用
この指標で料金が発生する。
ソースの種類 | FREE レベル | STANDARD レベル |
---|---|---|
ストレージ - サブスクリプション内の選択的ストレージ アカウントを保護する | 利用できません | 10K のトランザクションにつき ¥4.482 |
無駄な費用を抑えるために
ストレージアカウント単位となるため、マルウェア検出以外の用途も兼ねているストレージアカウントでは不要な課金が発生してしまう可能性があるので、マルウェア検出専用のストレージアカウントを用意したほうが良さそうです。
アプリケーションログなどのファイルや、明らかに無害なファイルが溜まっているストレージアカウントなどはマルウェア検知の対象外となるように ストレージアカウント分けるような構成にしましょう。
(出来ればコンテナ単位で保護対象を設定出来ると嬉しいけど)
トランザクションの意味の理解が曖昧でちゃんと確認したほうがいいのですが、1ファイルにつき1回チェックすると1トランザクションくらいの感覚でした。なんとなくイメージ通りの範疇内という感覚です。
そのためそこまで高い値段のサービスでは無さそうですが、導入し始めてしばらくの間は Azure コスト分析等でどれくらいのお金がかかっているかを確認しておきましょう。(本サービスに限らず全てに言えることです)
マルウェア検知を有効にする手順
一番簡単なやり方は、ストレージアカウントの「セキュリティ」から Azure Defender for Storage を有効にするだけです。
Azure Security Center からの設定方法などは下記ドキュメントを参照ください
Azure Defender を設定する
マルウェア検知のアラート
Azure Security Center の Storage 関連のアラート一覧は下記に掲載されています。
Azure Storage のアラート
このアラート一覧の内、マルウェア検知で使われるアラートは下記になります。
アラート | 説明 | 意図 (詳細) | 重大度 |
---|---|---|---|
Potential malware uploaded to a storage account (マルウェアがストレージ アカウントにアップロードされた可能性) | マルウェアを含んだ BLOB が、ストレージ アカウント内の BLOB コンテナーまたはファイル共有にアップロードされた可能性があることを示します。 このアラートは、ウイルス、トロイの木馬、スパイウェア、ランサムウェアのハッシュなど、Microsoft の脅威インテリジェンスの機能を活用したハッシュ評価分析に基づいています。 原因としては、攻撃者が意図的にマルウェアをアップロードするケースと、正当なユーザーが意図せず悪意のある BLOB をアップロードしてしまうケースが考えられます。 | 横移動 | 高 |
実際に試してみた
今回の検証の主なポイント
- マルウェアファイルを Blob にアップロードして検知したアラートを LogicApp に連携してみる
- Azure Security Center の自動ワークフロー設定を通じて LogicApp と連携させる
- 今回はアラートを受けてメール/チャット通知するパターンでやってみました
- マルウェアファイルは EICAR ファイルを使用
構成図
自動ワークフローの設定
Step1. トリガーされる Logic Apps を作成する
マルウェア検知をしたらトリガーされるワークフローを設定しておく。
あらかじめ ASC トリガーのコネクタ(When an Azure Security Center Alert is created or triggered
)が定義された LogicApps を作成しておく必要がある。
中身のアクションは空のままで良いので、このトリガーを選択した状態で Logic Apps を保存する。
Step2. Azure Security Center にてワークフローの自動化を行う
先ほど作成した LogicApp に自動ワークフローを関連付けます。
Step3. LogicApp に自動化したいワークフローのアクションを定義する
ここは通常の LogicApp の作成フェーズになります。
そのため詳細は割愛します。
マルウェア検知に使うファイル
EICAR というテストファイルを使用する。
セキュリティソフトのテストに使用される一般的なファイルらしい。
- 提供しているサイト
プレーンなファイルやアーカイブされたファイルなど4パターン提供されている。
今回は4パターンそれぞれのファイルを使ってみました。
eicar.com
と eicar.com.txt
はプレーンなただのテキストファイルで、eicar_com.zip
と eicarcom2.zip
はプレーンなファイルをアーカイブしたものです。
これにより、スキャナーがアーカイブ内のマルウェアを検知できるかを確かめることが出来ます。
これらのファイルを Azure Security Center で保護した Blob Storage にアップロードすればマルウェア検知される様子を確認することが出来ます。
(余談)作業用PCのセキュリティソフトが EICAR に反応してしまったので Cloud Shell から Blob にアップロードしたよ
私の場合、テストファイルをダウンロードしようとするとセキュリティソフトが反応してまってダウンロードできなかったので、Cloud Shell 内でダウンロードして、Blob にアップロードする方法で進めました。
ちょっとした Azure 操作のために Cloud Shell はとても便利です。
Azure CLI (Bash) で EICAR ファイルを取得して Blob にアップロードするコマンドのイメージ
mkdir work_dir
cd work_dir
wget https://secure.eicar.org/eicar.com
wget https://secure.eicar.org/eicar.com.txt
wget https://secure.eicar.org/eicar_com.zip
wget https://secure.eicar.org/eicarcom2.zip
azcopy cp . "[対象のコンテナから取得した SAS URL]" --recursive=true
[対象のコンテナから取得した SAS URL]
は Storage Explorer などで取得する。
検知させてみた結果
実際にマルウェア検知をさせて LogicApp に連携させてワークフローの自動化をさせる、というパターンは達成できました。
参考までに、検証の中で得られたアラート内容や課題等を共有します。
実際に通知されたアラートの JSON
マルウェア検知させた際の Azure Security Center が生成したアラートの JSON の中身はこのような内容が詰まっています。
この JSON を LogicApp 側でパースして自動ワークフローを作成することが出来ます。
{
"VendorName": "Microsoft",
"AlertType": "Storage.Blob_MalwareHashReputation",
"ProductName": "Azure Security Center",
"StartTimeUtc": "2020-12-01T03:14:32.104Z",
"EndTimeUtc": "2020-12-01T03:14:32.104Z",
"TimeGenerated": "2020-12-01T04:29:11.2303752Z",
"ProcessingEndTime": "2020-12-01T04:29:11.2303752Z",
"Severity": "Medium",
"Status": "New",
"ProviderAlertStatus": null,
"ConfidenceLevel": null,
"ConfidenceScore": null,
"ConfidenceReasons": null,
"IsIncident": false,
"SystemAlertId": "xxxxxxxxxxxxxxxxxxx_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"CorrelationKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=",
"Intent": "LateralMovement",
"AzureResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/mystorageaccount/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"WorkspaceId": null,
"WorkspaceSubscriptionId": null,
"WorkspaceResourceGroup": null,
"AgentId": null,
"CompromisedEntity": "mystorageaccount",
"AlertDisplayName": "Potential malware uploaded to a storage blob container",
"Description": "Someone has uploaded potential malware to your Azure Storage account 'mystorageaccount'.",
"Entities": [
{
"$id": "3",
"ResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroups/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"Type": "azure-resource"
},
{
"$id": "4",
"Address": "xx.xx.xx.xx",
"Location": {
"CountryName": "United States",
"City": "San Jose"
},
"Type": "ip"
},
{
"$id": "5",
"SourceAddress": {
"$ref": "4"
},
"Protocol": 6,
"Type": "network-connection"
}
],
"ExtendedLinks": null,
"RemediationSteps": [
"• Remove the malicious blob from your storage account.\r\n• Limit access to your storage account, following the 'least privilege' principle: https://go.microsoft.com/fwlink/?linkid=2075737.\r\n• Revoke all storage access tokens that may be compromised and ensure that your access tokens are only shared with authorized users.\r\n• Ensure that storage access tokens are stored in a secured location such as Azure Key Vault. Avoid storing or sharing storage access tokens in source code, documentation, and email."
],
"ExtendedProperties": {
"Alert Id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"Azure AD user": "N/A (Azure AD authentication was not used)",
"User agent": "AzCopy/10.5.1 Azure-Storage/0.10 (go1.13; linux)",
"Client IP address": "xx.xx.xx.xx",
"Client location": "Azure Data Center: West Us",
"Authentication type": "Shared access signature (SAS)",
"Investigation steps": "{\"displayValue\":\"View related storage activity using Storage Analytics Logging. See how to configure Storage Analytics logging and more information\",\"kind\":\"Link\",\"value\":\"https:\\/\\/go.microsoft.com\\/fwlink\\/?linkid=2075734\"}",
"Operations types": "PutBlob",
"Service type": "Azure Blobs",
"Container": "mycontainer",
"Blob": "EICAR/EICAR.file",
"Malware description": "File was identified as malicious, MalwareFamily = Virus:DOS/EICAR_Test_File",
"Detection source": "Team Cymru",
"MD5 hash": "44D88612FEA8A8F36DE82E1278ABB02F",
"Threat report": "{\"displayValue\":\"View report\",\"kind\":\"Link\",\"value\":\"https:\\/\\/interflowwebportalext.trafficmanager.net\\/reports\\/DisplayReport?callerIdentity=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&reportCreateDateTime=2020-12-01T04%3a29%3a11&reportName=MSTI-TS-EICAR-File.pdf&tenantId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&urlCreateDateTime=2020-12-01T04%3a29%3a11&token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=\"}",
"Threat report summary": "The European Institute for Computer Antivirus Research (EICAR) and the Computer Antivirus Research Organization (CARO) jointly developed a standard test file protocol called the “EICAR test file” which allows users to test their antivirus solution. The EICAR file is completely benign; however, when scanned, compliant antivirus solutions report the file in the same way as an actual malicious file. This does not mean that the computer is infected with malware, but rather it shows that the computer’s antivirus is functioning as expected.",
"Potential causes": "This alert indicates that a blob containing potential malware has been uploaded to your storage account.\r\nPotential causes:\r\n• An attacker has gained access to the storage account and has intentionally uploaded a malicious blob.\r\n• A legitimate user has unintentionally uploaded a malicious blob.\r\n• A legitimate user is performing tests on the system (e.g. penetration testing).",
"resourceType": "Storage"
},
"ResourceIdentifiers": [
{
"$id": "2",
"AzureResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroups/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
"Type": "AzureResource"
}
],
"AlertUri": "https://portal.azure.com/#blade/Microsoft_Azure_Security/AlertBlade/alertId/xxxxxxxxxxxxxxxxxxx_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/subscriptionId/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroup/mystorageaccount/referencedFrom/alertDeepLink/location/centralus"
}
分かりやすそう/使えそうな項目抜粋
私視点でパッと見て役立ちそうな項目をピックアップ
項目名 | 内容 | 例 |
---|---|---|
StartTimeUtc | Blob ファイルがアップロードされた時刻 | 2020-12-01T03:14:32.104Z |
TimeGenerated | マルウェア検知した時刻 | 2020-12-01T04:29:11.2303752Z |
Severity | 脅威度 | Medium |
Status | ステータス | New |
AzureResourceId | Storage Account のリソースID | /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/resourceGroups/my-rg/providers/Microsoft.Storage/storageAccounts/mystorageaccount |
AlertDisplayName | アラートの表示名 | Potential malware uploaded to a storage blob container |
ExtendedProperties/User agent | User agent(※今回の検証では azcopy を使用してアップロードした) | AzCopy/10.5.1 Azure-Storage/0.10 (go1.13; linux) |
ExtendedProperties/Blob | Blob のファイル名(パス) | EICAR/EICAR.file |
ExtendedProperties/Client IP address | アップロード元の IP アドレス | xx.xx.xx.xx |
ExtendedProperties/Client location | アップロード元のロケーション(※今回の検証は CloudShell 環境からアップロードした) | Azure Data Center: West Us |
AlertUri | 本アラートのリンク | https://portal.azure.com/#blade/Microsoft_Azure_Security/AlertBlade/alertId/(アラートID)/subscriptionId/(サブスクID)/resourceGroup/(リソースグループ名)/referencedFrom/alertDeepLink/location/centralus |
検証して分かった事、注意点など
Blob にアップロードしてから検知まで1時間くらいかかるっぽい
すぐにアラート検知が求められるような要件では、Azure Security Center のマルウェア検知以外の仕組みを検討したほうが良さそうです。
今回検知させてみた例
- アップロード時刻
- 2020/12/06 12:48
- 検知した時刻
- 2020/12/06 13:40
Azure Security Center 側のスキャンタイミングはこちらではコントロールできません。
今後のアップデートや Azure Security Center スキャンのタイミング次第では1時間以内に検知される可能性もあるかもしれないけれど、現状1時間以上かかるものとして考えたほうが良いです。
これは今後のアップデートに期待です。
アーカイブされたファイルの検知はできない
テストファイル | 検知できたか |
---|---|
eicar.com | 検知出来た |
eicar.com.txt | 検知出来た |
eicar_com.zip | 検知出来なかった |
eicarcom2.zip | 検知出来なかった |
今回マルウェア検知が出来たのはプレーンなファイルのみで、zip などにアーカイブされたファイルは検知できなかった。
Azure Security Center 側の仕組みとして、アップロードされたファイル自体をスキャンしているわけでなく、ファイルのハッシュ値など使って Azure 内の既知のマルウェア情報と突合しているような感じなので、アーカイブされたファイルの中身までは分からない様子。
アーカイブされたファイルのスキャンが求められる場合は、アーカイブされたファイルのスキャンが可能なセキュリティソフトのスキャン環境を用意するなどして、独自に自動化の仕組みを検討する必要がありそうです。
Azure Security Center および Azure Defender for Storage 有効化してからマルウェア検知のスキャンが行われるようになるまで 1,2時間ほど反映待ち時間がある?
この検証に初めて取り掛かり始めてから、もろもろのセットアップ完了直後に EICAR 関連のファイルをアップロードしてしばらく待っていたが、2時間程度たっても通知が来ませんでした。
けれど、その間色々触ったりしてたら通知が来るようになった、というよくあるやつに遭遇したっぽいというお話です。(もちろん私の勘違いの可能性もあります)
これは大した問題でもないので、サブスクリプションで ASC 有効化直後や ATP 有効化直後はすこし時間を置くくらいの気持ちを持っておけば良いという話です。
まとめ、所感
簡易的なマルウェア検知の仕組みとしては Azure Security Center のマルウェア検知を使うことはアリだと思います。
特別なスキャン環境も構築する必要が無く、また LogicApp との連携がしやすいため、とても簡単に構築できるのですぐに導入できるのも嬉しいです。
ただ、ファイルがアップロードされてからマルウェア検知されるまでのタイムラグが結構あるため、普段私たちが使用している一般的なウイルスソフトのような挙動をイメージしていると、アレ期待していたのとちょっと違うなみたいな、と言った印象を受けるかもしれません。
現時点ではかっちりした要件には応えられそうにないケースもあるので、簡易的な保険として考えて気楽に導入/運用する形から始めてみてから考えるというやり方も良いかなと思います。