標的型攻撃と多層防御にAWS Security Hub + DeepSecurity はどうして嬉しいのか。

この記事はfreee Developers Advent Calendar 2018 15日目の記事です。 adventar.org

freee CSIRT専属エンジニアのEiji Sugiuraです。早いもので、freeeにjoinしてから1年が経過しました。

前職では、UTM*1を使ったMSSP*2を作って運用していたので、SaaS*3はどちらかというとブラックボックスとして扱っていました。それが、何の因果かSaaSのなかにどっぷり浸かっています。人生って何が起きるかわからないもんです。

自分から「セキュリティエンジニアです。」なんて名乗るのは眉唾ものだと思っています。他人からセキュリティエンジニアと呼ばれれば本物ですね。自分は果たしてどうなんだ? という点はさておき、この1年間、どんなことを考えてセキュリティを無理なく無駄なく担保しようしてきたかを、まとめておきます。

ざっくりいうと、立場は変わっても、考えることは普遍ですという話です。

攻撃と防御
AWS Security Hub + DeepSecurity
まとめ
Future Work

攻撃と防御

標的型攻撃

その昔、インターネットで報告される攻撃といえば、わかりやすく同時多発的に被害が生じるもので、愉快犯が犯人であることがほとんどでした。しかし、2010年代に入ってから、金儲けの手段として攻撃や侵入を行い、実際に利益を得る組織の存在が知られるようになりました。そうした組織は、標的型攻撃と呼ばれる洗練された手法を用いていました。

標的型攻撃に限らず、こうした攻撃手法は常に進化していて、APT*4攻撃と呼ばれる手法に変化しています。この攻撃は、7つの段階を経て行われると言われています。

最も知られているのは、標的型メール攻撃なので、それを例にとると、こんな感じです。

偵察 Reconnaissance
攻撃者は餌食となる標的を物色します。最も都合が良いのは、防御が脆くて、足がつきにくい宝物を持っている組織です。検索エンジンやSNS、メールなどから簡単に標的の情報を手に入れられるので、組織に属する人のリスト、組織構造、予定されているイベント、取引先、取引内容など、集められるものをすべて揃えておき、最も割りの良い標的を選び出します。
武器の準備 Weaponization
標的が決まったら、malwareの作成ツールやbotnetを調達し、特定の人物に開いてもらえそうなメールのタイトルと文面を推敲し、組織が利用しているセキュリティ対策製品に検知されないことを確認したmalwareを添付ファイルやリンクとして添えたメールを用意します。
輸送 Delivery
そして、メールを送付します。メールは暗号化された通信路で配送されるため、配送途中にmalwareが検知されることはありません。
侵入、展開 Exploit
組織内の誰か一人がメールを開く、もしくは開かなくてもメールを受信した時点で、パソコンのOSにmalwareが侵入します。AntiVirusには検知されません。なぜなら、検知されないことを確認済みのものを送付したからです。
潜伏 Installation
malwareは侵入したOS上で、自らをまっとうなプロセスであるかのように偽装し、OSの管理者権限を奪取します。そして、C2C serverとの通信路を確保します。
C&C->探索 Command&Control
その後は、C&C serverからの指令に従って、周囲のパソコンやネットワーク機器への侵入を試します。
目標の奪取、掃除 ActionsOnObjectives
探索の結果、取得したかった情報が見つかった場合、頃合いを見計らって奪取したら、自らの痕跡を消して攻撃は終了です。

APT攻撃は、標的型攻撃と比べて以下の点で進化しています。

明確に目的がある
攻撃者は、APT攻撃を仕事として取り組んでいるので、利益を得る、情報を手に入れる、もしくは、標的の評判を貶めるなど、明確な意図を持っています。
見つけられない
間欠的にしか動作しない。長期間潜伏する。ファイルを残さずにメモリ内にのみ存在する。既存のプロセス内で動作する。プロセス一覧に表示されない。などなど、様々な手法を凝らして、とにかく痕跡を残しません。
技術レベルが非常に高い
自ら攻撃ツールを作成できる専門家が組織として行動していると考えられています。標的側の兼務のセキュリティ担当なんて相手になりません。
粘り強いこと
うまくいかなければ別の方法を探り、ツールを自動でアップデートし、プラグインによる機能拡張を行う、なんてこともやってのけます。

防御する側が圧倒的に不利な状況ですね。防御側は一つも間違いを許されないのに、攻撃側は蟻のひと噛みでどこか一つでも穴を見つければ勝ったも同然というのも困ったところです。

標的型攻撃やAPT攻撃は、日本では企業や公的機関の情報漏洩ばかりに注目が集まってしまい、あまり報道されませんでしたが、2015年12月にはウクライナにおいて戦争の手段として用いられ、基幹インフラである送電網に物理的な被害が生じました。

www.wired.com https://ics.sans.org/media/E-ISAC_SANS_Ukraine_DUC_5.pdf

この攻撃は、1年後、2年後、そして今年も継続して行われている、と考えられています。

多層防御

標的型攻撃やAPTの対処策として広く知られているのは、2009年にLockheed Martinが提唱したCyber Kill Chain = 多層防御です。

多層防御の基本的な考えは、攻撃の段階全てで、まずログを記録し、その中から異常を検知することです。その上で、攻撃を直接的に止める、動作を妨害し時間稼ぎをする、情報を略取されたとして意味がわからないものに加工しておく、偽物を掴ませる、最終手段として攻撃元を破壊する、の全ての手段を用いて攻撃が成立しない状況を維持することを目指します。

例えば、標的型メール攻撃に対して、多層防御で対策を練った場合、以下のような対処が考えられます。社内LAN内のサーバが、機微なデータを保持している想定です。なお、偵察や武器を準備している段階については、一般企業では対処は難しいため省略しています。

- 攻撃段階	Discover 記録	Detect 検知	Deny 禁止	Disrupt 妨害	Degrade 矮小化	Deceive 撹乱
3. 輸送	Internet Gateway上での対策
3. 輸送	NetFlow	IPS*5	Firewall、URL Filter、WAF*6	Rate Limit
4. 侵入	PC上でのメモリアクセスでの対策
4. 侵入	EventLog	HostIPS、LogInspection	Package Update	ASLR*7		Sandbox
5. 潜伏	PC上のファイルアクセスでの対策
5. 潜伏	FileIntegrity*8	AntiMalware	FileAccessControl
6. 探索	社内LAN機器での対策
6. 探索	NetFlow	IPS	NetworkFirewall	NetworkSegmentation	RateLimit
7. 奪取	サーバ上での対策
7. 奪取	AccessLog	HostIPS、DLP	HostFirewall、FileAccessControl	ASLR		HoneyPot

これを、AWS上に構築されたサービスシステムに適用した場合を考えてみます。こちらは、S3 BucketやDatabaseに機微なデータを保持している想定です。

f:id:eiji-sugiura:20181215002300p:plain — AWSに構築したシステム

- 攻撃段階	Discover 記録	Detect 検知	Deny 禁止	Disrupt 妨害	Degrade 矮小化	Deceive 撹乱
3. 輸送	ELB周りでの対策
3. 輸送	ELB AccessLog	AWS Shield、AWS WAF	ELB Security Group	AWS WAF Rate Limit
4. 侵入	EC2 instance上でのメモリアクセスでの対策
4. 侵入	AuditLog、AccessLog	~~HostIPS~~、~~LogInspection~~	Package Update	ASLR		~~Sandbox~~
5. 潜伏	EC2 instance上のファイルアクセスでの対策
5. 潜伏	~~FileIntegrity~~	~~AntiMalware~~	FileAccessControl
6. 探索	VPC内での対策
6. 探索	FlowLog	~~IPS~~	SecurityGroup	NetworkSegmentation	RateLimit
7. 奪取	BucketやDB周りでの対策
7. 奪取	QueryLog、ObjectLog	~~ObjectIPS~~、~~DLP~~	SecurityGroup、ObjectAccessControl			HoneyPot

青字で示した部分は、AWSに用意されているサービスや機能によって対策が可能な部分です。

赤字で示した部分は、AWSでは提供されない機能です。EC2 Instance自身を守るには、別途仕組みを導入する必要があることが分かるかと思います。そして、この不足した機能をそのまま提供してくれるのがDeepSecurityだと考えています。

DeepSecurityの他にも、同様の機能を提供する製品は存在しますが、IPSやFile Integrity、Log Inspectionについては、signatureを編集することが可能な点がお気に入りです。

SIEM

多層防御を張り巡らせれば、仕事は終わりというわけではありません。

実は、多層防御では、各段階で膨大なログが発生します。例えば、WebServiceに関連するものだけに絞ったとしても、以下のように様々なログが挙げられます。

ログ種別	記載される内容
Detect Log	Firewall、WAF、IPS、AntiMalwareなど、セキュリティ上の異常を検知したことを報告するログ
Web Error Log	nginx/apacheでのエラーが記載される
Web Access Log	Layer 7のログ、nginx/apacheが出力する、AWS WAFも全てのアクセスを記録するログを出力します
Application Log	WebApplicationの動作を記録する
Flow Log	Layer4までのログ、AWSのFlowLogはNetFlow v5に相当します

Detect Logや、Error Logが発生した場合に、それらの原因を調査し、対処を行うのは、誰でも行なっていると思います。 Detect LogでWAFであるIPから一定以上の頻度で繰り返される攻撃を検知したら、IP reputationを検討するでしょうし、IPSで誤検知が判明したらsignatureを修正するといった具合です。

でも、間違いが起きる前にproactiveに対処するためには、通常運用時のログである、Access Log、Application Log、Flow Logを解析して、間違いが起きる予兆を掴み、対処を自動的に実施しなくてはなりません。

しかし、通常運用時のログは膨大です。ログを解析するためのシステムを構築して運用していくのは、かなりのコストが必要です。下手をすると、お客様向けサービスを構築する費用の半額以上をかける事態に陥りかねません。

こうした、ログを集積し、相関分析を行い、予兆を検知したら、自動的に対処を行う仕組みは、SIEM*9と呼ばれています。オンプレミスでシステムを構築している場合、SIEMの導入は、もう一つ別の高価な箱を買ってくることを意味したのですが、AWS上では箱を持ってくるのは無理そうです。

SIEMを自前で構築するとなると、AWSが提供するGuardDutyのようなサービスや、DeepSecurityのように3rd partyが提供するサービスのログを集めるところか始めなければなりません。

AWS Security Hub + DeepSecurity

で、今回何が嬉しいかというと、まずは、AWSがログを集積する箱を用意してくれた！、という点です。 AWSが提供するサービスのうち、GuardDuty、Inspector、Macieについては、Security Hubを有効化するだけで、集積してくれます。

さらに、3rd partyのログを受け付けるAPI = Findingsも用意されました。 DeepSecurityは、Findingsにeventを投げるための実装もTrendMicroが用意してくれたみたいです。

ということで、早速使ってみました。

AWS Security Hubの有効化

詳しくは、以下のサイトに記載されていますが、 Security Hubを有効化し、CISベンチマークを有効化しておきます。

dev.classmethod.jp

DeepSecurityのsubscribe

[Settings]->[Providers]で、TrendMicro DeepSecurityを[Subscribe]しておきます。

実行ロールの作成

AWS マネジメントコンソールにサインインし、IAM コンソールを開きます。
[Create Role]をクリックして、ロールの作成を開始します。
[Select Role Type] で、[AWS Service Roles] を選択して [AWS Lambda] を選択します。
[Attach Policy] で、AWSLambdaBasicExecutionRole という名前のポリシーを選択します。
Tagは今回は利用しません。
[Role Name]は、今回はlambda-ds-agent-security-hubとしました。

後で用いるので、以下の形式の[Role Arn]をメモしておきます。 arn:aws:iam::XXXXXXXXXXXX:role/lambda-ds-agent-security-hub

SecurityHubBatchImportポリシーの作成

lambdaからSecurityHubへFindingsをBatchImportするためのポリシーをAWS CLIを用いて作成します。以下の内容で、security-hub-batch-import-policy.json を作成しておきます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "securityhub:BatchImportFindings",
            "Resource": "*"
        }
    ]
}

以下を実行して、ポリシーを作成します。

aws iam create-policy --policy-name SecurityHubBatchImport \
    --policy-document file://security-hub-batch-import-policy.json

実行ロールへのSecurityHubBatchImportポリシーの追加

以下を実行して、実行ロールにポリシーを追加しておきます。

aws iam attach-role-policy --role-name lambda-ds-agent-security-hub \
    --policy-arn arn:aws:iam::XXXXXXXXXXXX:policy/SecurityHubBatchImportOnly

Lambdaの作成

修正済みのソースコードを、lambda-function.pyとして作成しておきます。

本家の実装は、以下の点の修正が必要でした。

HostAssetValueが、AntiMalwareのeventの場合は存在せず、IPSのeventの場合は数字の配列でやってくる状態だったので、ひとまずコメントアウトしています。
DeepSecurityからのeventを受け取るSNSを管理しているAWS accountと、SecurityHubを管理しているAWS accountが、別の場合にも対応できるように組まれているのですが、そのままだと動作しません。コメントアウトせずに、assume role時の例外を拾って、処理をそのまま継続しています。cross accountで処理する場合にも対応しているつもりです。
他にも、例外を捕捉していない箇所がほとんどだったので、debugしやすいように例外を捕捉してerrorの内容を出力するようにしています。

github.com

ソースコードをzip fileにまとめておきます。

zip -r ds-agent-security-hub.zip lambda_function.py

以下を実行して、Lambda関数を作成します。

aws lambda create-function --function-name DeepSecurity2SecurityHub \
--zip-file fileb://ds-agent-security-hub.zip \
--role arn:aws:iam::XXXXXXXXXXXX:role/lambda-ds-agent-security-hub \
--handler lambda_function.lambda_handler --runtime python3.6

Lambda関数の一覧から、作成したDeepSecurity2SecurityHubのDesignerを参照すると、以下のような状態となっているはずです。

f:id:eiji-sugiura:20181214222642p:plain — Lambdaが作成された

Triggerの設定

予め、DeepSecurityからSNSにeventを飛ばすように設定しておきます。
まだ、設定を行なっていない場合は、DeepSecurityのSNS設定マニュアルを参考にDeepSecurity用のIAMユーザを作成し、ACCESS KEY、SECRETを設定し、SNS topicを作成しておきます。

今回は、deepsecurity-eventという名前でSNS topicを作成しました。

そして、SNS topicからeventをLambda関数に通知するためのsubscriptionを作成します。 DeepSecurityからSNSへのeventの全体的な手順は、こちらが参考になると思います。

DeepSecurity2SecurityHubのDesignerに戻り、Triggerを追加します。左側に並んでいるTrigger一覧から[SNS]を選択し、SNS topicには、deepsecurity-eventを指定します。

f:id:eiji-sugiura:20181214222652p:plain — LambdaにTriggerが追加された

この時点でTriggerを有効化すると、以下のようなエラーがCloudWatchLogsに記録されます。

securityhub: Unknown service: 'securityhub'. Valid service names are: ....<アクセス可能なサービスが羅列される...>

これは、Lambdaが利用しているboto3が古く、securityhubに対応していないために発生するエラーです。ということで、最新のboto3を利用するためにLayerを利用します。

Lambda Layerの追加

詳しくは、こちらを参考にしていただくとして、

qiita.com

手元で以下を実行し、layerにuploadするためのboto3のzipファイルを作成します。

$ mkdir python
$ pip install -t ./python boto3
$ zip -r boto3-1.9.62.zip python

執筆時点のboto3のversionは、1.9.62でした。

Lambdaコンソールで

[Layer]を選択し、[Create Layer]で新しいLayerの作成を行います。
[Name] python-boto3、 [Description] 1.9.62、 [Compatible Runtime]には、python2.7 python3.6 python3.7を指定しておきます。
Lambda Layerの作成
先ほど作成したboto3-1.9.62.zipをuploadし、[Create]を実行します。
lambda Layerが作成された

DeepSecurity2SecurityHubのDesignerに戻り、[Layer]を選択し、[Add a layer]を実行して、python-boto3を追加します。

f:id:eiji-sugiura:20181214221235p:plain — Lambda layerが追加された！

動作確認

DeepSecurityのAntiMalware機能でReal-Time scanを有効にしていれば、EICAR文字列をテキストファイルに書き込むだけで、eventを発生させることができるので、これで動作試験を行えます。

DeepSecurityが動作しているEC2 instanceにloginし、ds-agentが動作していて、かつ、Real-Time scanが有効になっていることを確認しておきます。

$ sudo /opt/ds_agent/dsa_query -c GetComponentInfo
...
Component.AM.scan.Realtime: 1
...

以下のようにEICARを用いて、動作確認を行えます。 EICAR文字列には、"EICAR test file"で検索すると出てくる文字列をいれて下さい。

$ echo 'EICAR文字列' > test.txt

Real-Time scanが正常に動作していれば、test.txtは作成されません。 syslog出力を有効にしていれば、以下のようなログが確認できます。

Dec 14 00:16:03 ip-10-XX-YY-ZZ CEF: 0|Trend Micro|Deep Security Agent|1X.0.0.XXXX|4000000|Eicar_test_1|6|cn1=...... cn1Label=Host ID dvc=10.XX.YY.ZZ TrendMicroDsTenant=...... TrendMicroDsTenantId=..... cn2=144 cn2Label=Quarantine File Size filePath=/tmp/test.txt msg=Realtime TrendMicroDsMalwareTarget=N/A TrendMicroDsMalwareTargetType=N/A TrendMicroDsFileSHA1=CF8BD9DFDDFF007F75ADF4C2BE48005CEA317C62 act=Quarantine

もちろん、DeepSecurityのWebU/Iでもeventは確認できます。

f:id:eiji-sugiura:20181214220910p:plain — DeepSecurityでのevent表示

そして、EICARを検知したeventは、AWS Security Hubでも確認できます。

f:id:eiji-sugiura:20181214222703p:plain — Security HubにDeepSecurityのeventが表示された！

まとめ

多層防御を適用すると膨大なログが発生しますが、それを運用で回していく仕組みに使えそうなものをAWSが用意してくれたので、使ってみました。

AWS Security Hub + DeepSecurity の使い方だけであれば、以下ですでに解説されていますが、背景も含めて理解できるようにしたつもりです。

dev.classmethod.jp

Future Work

AWS Security Hub Findingsで、一覧性は確保できそうですが、まだ、統合されていないものもあります。AWS WAFのeventも集約したいなぁ。

今回は、EC2 instance構成での話でしたが、AWS + Kubernetes構成にも応用できますが、まだ足りない部分が多々あります。それについては別の機会に。

新たに開発するサービスに構想、設計段階からセキュリティを織り込んでいくのは、人であるエンジニアの仕事です。また、すでに稼働しているサービスに合わせてWAFやIPSのsignatureやparameterを調整したり、取捨選択するのも、エンジニアの仕事です。セキュリティエンジニアという職業がなくなって、エンジニア皆がセキュリティを身につけた世界が理想です。

freeeでは、一緒に働く仲間を募集しています。

jobs.freee.co.jp

CSIRTのエンジニアとして、隣で働いてもらえる人も募集中です。

www.wantedly.com

さて、明日12/16(日)は、freeeが誇るQAの達人コヤマンさんです。

*1:Unified Threat Management system: ルータにFirewall、IPS、AntiMalware、AntiSPAMなどのセキュリティを担保する機能を詰め込んだもの、アプライアンスとして提供されることが多い

*2:Managed Security Service Provider : network securityのdesign、deploy、management、incident responseを丸投げできる便利なサービス

*3:Software as a Service

*4:Advanced Persistent Threat:直訳すると、より進化し継続して行われる攻撃

*5:Intrusion Prevention System : trafficに対してsignature matchを行い不正な通信を検知する

*6:Web Application Firewall : www serverへのHTTP requestのfilteringを行う

*7:Address Space Layout Randomization