いくつかの商用コンテナセキュリティサービスをNIST SP800-190ベースに、独自観点を追加して検証した話

いくつかの商用コンテナセキュリティサービスをNIST SP800-190ベースに、独自観点を追加して検証した話 2020年09月09日 NRIセキュアテクノロジーズ株式会社サイバーセキュリティコンサルティング部吉江瞬

1 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 背景/目的
01 検証の進め方 02 活動結果 03 まとめ 04

2 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. ◼吉江
瞬 ◼ @Typhon666_death ◼所属：NRIセキュアテクノロジーズセキュリティコンサルタント (野村総合研究所から2度目の出向) ◼経歴： ⚫ Managed Security Service - WAF,IDS/IPS,NGFW,FW,LB,etc ⚫ AI Service - AWS,DevSecOps,Datadog,R&D ◼コミュニティ運営 ⚫ Security-JAWS / X-Tech JAWS ⚫ JAWS-UG Tokyo / JAWS DAYS 2019 実行委員長 ⚫ OWASP Japan PR Team ⚫ JAWS SONIC 2020 実行委員長自己紹介

3 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. ◼長山
大志 ◼ @NaGym_t ◼所属：NRIデータiテックインフラエンジニア ◼経歴： ⚫ オンプレ Oracle, Linux, HPC ⚫ 仮想化 VMware ⚫ クラウド AWS ◼趣味 ⚫ マラソン ⚫ 某色塗りシューティングゲーム自己紹介

4 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. ◼石井
翔 ◼ @von_shaw1989 ◼ ishii1648 ◼所属：Latona株式会社インフラ・バックエンドエンジニア ◼経歴： ⚫ AWSインフラ構築、運用 ⚫ kubernetes構築、運用 ⚫ マイクロサービス開発 ◼コンテナ・クラウド周りが好きです。（ただ今いる会社はほぼクラウド使ってない...） ◼あと最近Goをよく書いてます。自己紹介

5 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. ◼栗山
雅紀 ◼ @mark1eins ◼所属：株式会社KSKテクノサポート ◼経歴： ⚫ 金融系システムのインフラ維持管理 ⚫ AWSインフラ構築を少しばかり ◼趣味 ⚫ ミニチュアホビー（最近は塗り専門） ⚫ 海外製のPCゲームとか自己紹介

6 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 本発表は、社内R&Dにおける、各コンテナセキュリティサービスの機能比較評価と
それまでの活動の軌跡についてである。 1.背景/目的 ◼課題 ⚫ 既存オンプレサービスをAWS上に移行してほしい要望において、コンテナアーキテクチャを採用したい考えがあった。 ⚫ AWSの責任共有モデルは理解できるが、コンテナアーキテクチャを採用と、責任範囲はどうなるのか？ ⚫ センシティブデータへのセキュリティ対策はどのように行うか？ ⚫ コンテナアプリケーションに対するセキュリティ対策はWAFのみで良いのか？ ⚫ Tripwireのような変更検知サービスはコンテナに対してどう対応したらいいのか？ ⚫ etc ◼社内R&Dプロジェクトでの起案 ⚫ コンテナセキュリティサービスへの期待 ⚫ DFIR可能なサービスやWAF利用可能なサービスも存在したので、自前で構築するより、サービス利用したかった。 ⚫ 各サービスの優劣をつけて、評価結果を踏まえ、来期予算とともにサービスを導入したい考え (2019/10月頃) ◼目標：Cloud Native Days Tokyo 2020 登壇 ⚫ CNDT2020で発表することを念頭にしてのモチベーション維持 ⚫ 各社ベンダー様との調整の末、この場でお話できる許可を頂けたことを嬉しく思います。

7 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 仮想マシン
ハードウェアホストＯＳ APP APP ハードウェアホストＯＳ APP APP ハイパーバイザゲストＯＳライブラリ仮想マシン APP APP ゲストＯＳライブラリコンテナハードウェアホストＯＳ APP APP コンテナランタイムライブラリコンテナ APP APP ライブラリ Traditional Virtualized Container 顧客への早急なサービスデリバリが求められる中で、コンテナの登場はアプリケーション開発を劇的に速くし、世界中で広く活用されるアーキテクチャとなった 1.背景/目的 ◼ Traditional： ⚫ 物理サーバー内のアプリケーションのリソース境界を定義する方法がなかったため、1つのアプリケーションがリソースのほとんどを占有し、その結果、他のアプリケーションがパフォーマンスを低下させる等のリソースに関わる問題があった。 ◼ Virtualized： ⚫ 仮想化により、物理サーバー内のリソースの使用効率が向上し、ハードウェアコストが削減できた。VM間でアプリケーションを分離でき、一定レベルのセキュリティも提供。 ◼ Container： ⚫ VMに似てるが、アプリケーション間でOSを共有するため、コンテナは軽量。基盤インフラから切り離されているため、クラウドおよびOSディストリビューション間で移植可能

8 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. アプリケーション開発者およびインフラエンジニアたちはコンテナアーキテクチャを採用することによ
り多くの恩恵を受けるようになった。コンテナ市場の規模も更に拡大が予想される。 1.背景/目的 ◼ コンテナ/マイクロサービス採用のメリット： ✓ Evolutionary design ◼ 既存のサービスに大きな変更を加えることなく、プラグインとして新しい機能を追加することが可能に！ ✓ Small Codebase ◼ マイクロサービス化により、サービスの変更/追加における影響を最小限に抑えることが可能に！ ✓ Easy to deploy ◼ CI/CDにより迅速に冪等性を保ったデプロイが可能に！これによりサービスの提供/改善スピードが上がる。 ✓ Easy to scale ◼ k8sではクラスターの機能によりスケールアウト/スケールインが容易に！ ◼ 今後の市場規模： ✓ 2018年度は約1200億円だった市場規模は2023年度には約5000億円になると見込まれる（2018年 Global Information, Inc.調べ） https://www.gii.co.jp/report/mama641957-application-container- market-by-service-container.html https://www.qnap.com/solution/qiot-containers/th-th/

9 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. Kubernetesはコンテナオーケストレーションの事実上のデファクトスタンダードなツール
1.背景/目的 ◼クラウドサービスプロバイダ(CSP)もKubernetes as a Managed Service として採用したのは言うまでもない。 ◼Kubernetes as a Managed Service を提供するCSP ◼Kubernetes採用企業事例は以下を参照 ⚫ 記載されている企業以外にも多くの企業が採用されているのは自明 ⚫ https://kubernetes.io/case-studies/ https://www.publickey1.jp/blog/17/kubernetescoreosfleetkubernetes.html https://ja.wikipedia.org/wiki/Kubernetes https://blog.docker.com/2017/10/docker-enterprise-edition-kubernetes/

10 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. コンテナの利用における運用管理の課題がKubernetesによって解消されることとなる。
1.背景/目的 ◼ コンテナの利用における運用管理の課題 ✓ 課題1：デプロイ配分、負荷分散ができない →マニフェストに記載して、複数コンテナを自動的にデプロイ！ ✓ 課題2：障害時、自動復旧ができない →kubernetesがコンテナの障害を検知して自動復旧！ ✓ 課題3：リソース不足時、オートスケールができない →マニフェストに記載することでオートスケール可能！ ✓ 課題4：ロールアウト/ロールバックができない →リビジョンを管理しているので簡単に可能！ ✓ 課題5：Secretsが管理できない →Secretsの管理が可能！ ✓ etc Master Worker kube-api-server etcd kube-scheduler CCM/KCM kube-proxy kubelet k8s components CRI (Container Runtime Interface) image service Runtime service CNI Client CNI (Container Network Interface) runtime (runC …) Pod A Container A Container B Pod B Container A Container B iptables kubectl Ingress Other packages Linux Kernel Host OS Image Registry Image A Image B Host Machine User Generated

11 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. コンテナ環境のケアすべきポイントを明確にすると、外部サービスを用いて対策するのが効率よい
1.背景/目的 ◼図は責任共有モデル ⚫ マネージドKubernetesサービス ⚫ CaaS(Containers as a Service) ⚫ Kubernetes-Based PaaS ◼Containered Workloads(Container、Pod)に対するセキュリティ対策は自前で行う必要がある。 ⚫ コンテナイメージそのもの→コンテナイメージスキャン、SAST ⚫ コンテナイメージをBuild・Ship・Runする工程(後述) ⚫ デプロイ後の対策(後述) https://thenewstack.io/ebooks/kubernetes/kubernetes-deployment-and-security-patterns/

12 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. コンテナやKubernetesを利用する環境におけるセキュリティ課題の一つとして、コンテナアプリ
ケーションのセキュアな開発パイプラインが求められる 1.背景/目的 Security by Designを前提とした、開発初期段階からセキュリティ対策の自動化を行うことにより、影響を最小限に留めることができる。 BUILD SHIP RUN OSSライセンスの妥当性イメージの改ざん既知の脆弱性マルウェアの混入ハードコーディングされたシークレット情報許可されていないベースイメージ

13 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. さらに、コンテナデプロイ後におけるセキュリティや既存のアプリケーションセキュリティに対する対
策では、従来のセキュリティ対策と異なるアプローチが必要とされる 1.背景/目的 ◼ 不適切な権限による内部の不正操作はないか？ ◼ 承認されていない不正なコンテナがないか？ ◼ 不正コードが注入されてないか？ ◼ 不法なデータ漏洩はないか？ ◼ 外部攻撃者によるリソース枯渇はないか？コンテナハードウェアホストＯＳ APP APP コンテナランタイムライブラリコンテナ APP APP ライブラリコンテナコンテナセキュリティエージェントコンテナランタイムライブラリコンテナ containerd dockerd APP APP ライブラリ shim shim runC runC BLOCK セキュリティを検討する箇所は複数存在する。 ◼ ゼロデイ対策できるか？ ◼ コンテナ間通信が不正に行われていないか？ ◼ コンテナに関するガバナンス ◼ コンテナ侵害後のDFIR(Digital Forensics and Incident Response )は可能か？

14 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. CNCFにおけるコンテナセキュリティサービスは、海外でも多くの企業が利用
1.背景/目的 ◼Cloud Native Computing Foundation (CNCF)のSecurity & ComplianceにはいくつかのコンテナやKubernetes利用者向けセキュリティツールが存在し、この市場も成熟し始めている。 ◼これらのコンテナセキュリティサービスに対して、いくつかのベンダーがディストリビューターとして名を上げ始めたのが2018年頃。 ◼2020年になった今、国内でのコンテナセキュリティサービス活用事例も多く聴くことになった。 https://landscape.cncf.io/ 2018.07(↑)と2020.07(↓)のCNCF Cloud Native Interactive Landscape

15 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 本R&Dでは、以下の達成を目的として実施する。
1.背景/目的 ◼コンテナセキュリティ技術調査・検証のアウトプットイメージとして、 ”AWSを利用したコンテナアーキテクチャ”×”コンテナセキュリティサービス”の組合せで、検証を行うことを考える。 ◼机上検証や、実際にいくつかのコンテナセキュリティサービスを選択して、実機検証も行うことを想定している。運用設計も加味した詳細な検証項目をプロジェクトの中で精査する。機能検証評価マトリクスをR&Dの中で作成

16 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 活動計画の全体像
2.検証の進め方タスク 2019/10月 11月 12月 2020/1月 2月 3月 R&D起案各社ベンダー調整 MTG 輪読検証項目作成& 環境構築 Sysdig検証 Aqua検証 Twistlock検証まとめ成果報告会 1. NIST SP800-190、CIS Docker/Kubernetes Benchmark 輪読 2. 各種サービスの検証に向けた共通検証項目作成 3. 各種サービスの検証環境準備&機能検証 4. まとめ【注意事項】いずれも検証時期に利用可能な最新バージョンの検証ライセンスにて検証を実施

17 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. ベンダー選定
2.検証の進め方 ◼ベンダー選定 ⚫ Cloud Native Days Tokyo 2019にブース出展していた国内サポート可な3社対象 • メーカー：Sysdig (サポートベンダー：SCSK) • メーカー：AquaSecurity (サポートベンダー：Creationline) • メーカー：PrismaCloud (旧Twistlock by PaloAltoNetworks) (サポートベンダー： MacnicaSolutions)

18 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 体制
2.検証の進め方 ◼ 当時の実行体制は以下の体制で実施した。野村総合研究所/NRIセキュア吉江瞬実行メンバー実行責任者前部署インフラチームメンバー長山、栗山、柳川、石井、天地当時の部長統括責任者

19 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 前提条件
2.検証の進め方 ◼ AWSで検証を実施 ⚫ VPCは２つ作成（攻撃環境とやられ環境） ◼ 基本的にコンテナについてほぼ無知のメンバーで検証開始 ⚫ 座学や輪読会、外部の勉強会を踏まえて、基礎知識の習得 • NIS SP800-190、CIS Benchmarksの輪読 • 各種勉強会への参加（お世話になりました。）勉強会名 URL Kubernetes Meetup Tokyo https://k8sjp.connpass.com/ Docker Meetup Tokyo https://dockerjp.connpass.com/ CloudNative Days Tokyo 2019 https://cloudnativedays.jp/cndt2019/ AV Tokyo 2019 http://ja.avtokyo.org/avtokyo2019 脆弱性診断ええんやで(^^) https://security-testing.doorkeeper.jp/

20 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. NIST
SP800-190 & CIS Benchmarks 2.検証の進め方 ◼NISTやCISにて、コンテナ利用におけるセキュリティガイドが無償で公開されている。 ◼各種セキュリティガイドの輪読を行うことで、コンテナセキュリティの知見を確認する。 ◼NIST：National Institute of Standards and Technology(米国国立標準技術研究所) ⚫ 科学技術分野における計測と標準に関する研究を行う米国商務省に属する政府機関 ⚫ 情報技術に関するITL(Information Technology Laboratory)がある。 ⚫ ITLは情報技術に関しての6分野(Security, Information Access, Mathematics and Computational Science, Software Testing, Netoworking Research, Statistical Engineering)の研究が行われている。 ◼SP800シリーズ：Special Publications(特別刊行物) ⚫ ITLの中でコンピュータセキュリティに関して研究を行っているCSD(Computer Security Division)が各種文書を発行しているレポート ⚫ セキュリティマネジメント、リスクマネジメント、セキュリティ技術、セキュリティの対策情報を評価する指標、セキュリティ教育、インシデント対応など、セキュリティに関して幅広く網羅された有益な文書 ◼NIST SP800-190：Application Container Security Guide(右図)として2017 年9月に刊行(Final Ver)。名前のとおり、コンテナセキュリティに関する問題、それに対する対策の推奨事項が記載されている。 ◼今回は、NIST SP800-190を輪読会にて、確認。 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf

SP800-190 & CIS Benchmarks 2.検証の進め方 ◼NISTやCISにて、コンテナ利用におけるセキュリティガイドが無償で公開されている。 ◼各種セキュリティガイドの輪読を行うことで、コンテナセキュリティの知見を確認する。 ◼CIS：Center for Internet Security ⚫ 複数の米国政府機関、企業、学術機関などが協力して、インターネットセキュリティの標準化に取り組む非営利団体 • 米国NSA(National Security Agency/国家安全保障局) • DISA(Difense Informaton Systems Agency/国防情報システム局) • NIST(National Institute of Standards and Technology/米国立標準技術研究所) • etc ◼CIS Benchmarks：セキュリティベンチマークプログラムにて、OS、ミドルウェア、NW 機器、クラウド向けのベンチマークを作成している。 ◼今回は、CIS Docker Benchmark、CIS Kubernetes Benchmarkを輪読会にて、確認。 https://www.cisecurity.org/cis-benchmarks/

SP800-190 & CIS Benchmarks 2.検証の進め方 ◼ 輪読会にて週2,3回、1時間程度の時間を取りながらチームメンバーと読み合わせ ◼ 特に3章、4章の内容を元に検証対象とするコンテナセキュリティサービスがどこまで対策できるのかを調査するため、本章をベースにリスクと対策を確認の上、検証項目を作成した。 ⚫ 3 Major Risks for Core Components of Container Technologies (リスク) ⚫ 4 Countermeasures for Major Risks (対策) ⚫ ※4.6 Hardware Countermeasures は今回がクラウド上での検証のため対象外とした。

23 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. アタックサーフェスの確認とNIST
SP800-190の項目を照らしあわせながら、機能検証評価マトリクスを作成 2.検証の進め方 ◼ 以下はBuild/Ship/RunパイプラインとKubernetesのアーキテクチャについて、NIST SP800-190の項目と照らしあわせたもの Master Worker kube-api-server etcd kube-scheduler CCM/KCM kube-proxy kubelet k8s components CRI (Container Runtime Interface) image service Runtime service CNI Client CNI (Container Network Interface) runtime (runC …) Pod A Container A Container B Pod B Container A Container B iptables kubectl Ingress Other packages Linux Kernel Host OS Image Registry Image A Image B Host Machine User Generated NIST SP800-190 Risks Image Risks Registry Risks Orchestrator Risks Runtime Risks Host OS Risks 3.1 イメージの脆弱性 3.2.1 通信暗号化 3.2.3 認証/認可 3.4.3 runtime設定 3.4.4 プロセス制御 3.5 ホストマシン脆弱性 3.3.2 データ暗号化 3.3.5 通信暗号化 3.4.2 ネットワーク制御 3.3.1 権限管理 3.3.3 コンテナ分離 3.3.4 機微レベル混在 3.2.2 古いイメージ 3.4.5 不正コンテナ Build Ship Run 3.4.1 runtime脆弱性

24 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. AWSを活用した場合における想定するコンテナアーキテクチャとして以下の6パターンを採用し、
コンテナセキュリティサービスの評価を検討する。 2.検証の進め方 ◼ 左(①④)はDocker、Kubernetesを自分達で管理する必要がある。 ◼ 右(②③⑤⑥)はAWSマネージドサービス ECR CodeBuild CodeCommit CodeDeploy CodePipeline NRI(Developer) ECS TaskA TaskA TaskB Docker TaskA TaskA TaskB ②③ECSにデプロイ ①Docker on EC2にデプロイ Proxy Proxy EKS PodA PodA PodB Proxy Proxy Kubernetes PodA PodA PodB ⑤⑥EKSにデプロイ ④Kubernetes on EC2にデプロイ Cross Instance/AZ Traffic Cross Instance/AZ Traffic 開発パイプライン ※ECS/EKSにはEC2/Fargateの2種類の起動モードがある ※AWS re:Invent 2019にてEKS on FargateがGAしたため追加 https://aws.amazon.com/jp/blogs/aws/aws-fargate/ CloudFormation EC2 Fargate

25 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 機能検証評価マトリクスをサービスごとに環境共通項目と6環境別の項目、サービス仕様や運
用観点に関する項目で作成 2.検証の進め方 ◼ 機能検証評価マトリクスの作成 ⚫ NIST SP800-190 等を読みながら作成(サービスごとに環境共通項目、6環境別) ⚫ サービスの仕様や運用観点からも、自社で活用できるかどうかを評価(フェールセーフ、AIOps等)

26 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 検証環境
2.検証の進め方 ◼ 脆弱なコンテナ環境として、SockshopとBadStoreをたて、コンテナサービスの導入、GUIで設定確認、簡易な脆弱性診断環境から攻撃を行う。 Private subnet VPC Bastion Private subnet Public subnet Public subnet Peering ZAP CSP NAT gateway User Sysdig/Twistlock GUI Console Login Docker on EC2 ECS on EC2 ECS on Fargate Kubernetes on EC2 EKS on EC2 EKS on Fargate ECR CodePipeline CloudFormation Aqua GUI Console Login

27 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. AWSへの侵入テスト許可申請
2.検証の進め方 ◼ 侵入テストのAWSカスタマーサポートポリシー、カスタマーサービスポリシーを確認 https://aws.amazon.com/jp/security/penetration-testing/ ◼ Workloads(コンテナWebアプリ)を脆弱性診断するにあたって、侵入テストに関する許可申請を行った。 ⚫ 各コンテナセキュリティサービスで検知するかどうか等検証項目にて確認 ⚫ 申請していない場合、AWSにて不正アクセスと見直される可能性があるため ◼ ツール紹介： ⚫ OWASP ZAP (WebApp脆弱性スキャナ) ：https://owasp.org/www-project-zap/ ⚫ Kubehunter (Kubernetesスキャナ) ：https://github.com/aquasecurity/kube-hunter ⚫ BadStore (やられ環境) ：https://www.vulnhub.com/entry/badstore-123,41/ ⚫ SockShop (やられ環境) ：https://microservices-demo.github.io/ Peering ZAP + ( or or )

28 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 検証項目結果報告
2.検証の進め方 ◼ 実際の機能検証評価マトリクスは以下のとおり一部拡大 NIST SP800-190ベースの評価結果以外に、各製品の運用ごとの比較結果も作成 (詳細は社内のチケット管理システムにて管理)

29 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 検証項目結果報告
3.活動結果 ◼検証時期はそれぞれ以下の1か月(全て、評価ライセンスにて実施) ⚫ Sysdig は2020/01 ⚫ Aqua は2020/02 ⚫ Twistlock は2020/03 ◼本発表で得られる製品の情報に関して、当社、メーカー、ベンダーは一切、責任を負いません。 ◼Twistlockは検証当時は、EKS on Fargateサポート対象外(現在は不明) ◼評価は大きく〇、△、×の3つ： ⚫ 〇：検証項目をクリア ⚫ △：一部の項目や環境においてクリア ⚫ ✕：検証項目をクリアできなかった(✕だからダメというわけではなく、補足は供述)

30 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. 3.1
Image Risks -3.1.1 Image vulnerabilities- ～コンテナイメージの脆弱性についてスキャンで確認できるか～ 3.活動結果 ◼検証項目 ⚫ ECRに登録したイメージのスキャンが実行できる ⚫ スキャンをまだ実施していないイメージのデプロイ前に警告が出る ⚫ 脆弱性が見つかったイメージに対してビルド・デプロイを止めることが出来る ◼Twistlock OK ◼Sysdig OK ◼Aqua OK Sysdigの ImageScan

Image Risks -3.1.1 Image vulnerabilities- ～コンテナイメージの脆弱性についてスキャンで確認できるか～ 3.活動結果 ◼検証項目 ⚫ スキャン間隔を設定できる ⚫ スキャン結果の出力項目について確認 ◼Sysdig スキャン間隔の設定不可 OSバージョンまで確認可能 ◼Aqua スキャン間隔の設定可能 OSバージョンまでは確認不可 Twistlockの ImageScan ◼Twistlock スキャン間隔の設定可能 OSバージョンまで確認可能

Image Risks -3.1.2 Image configuration defects- ～コンテナイメージのコンフィグ不備を確認できるか～ 3.活動結果 ◼検証項目 ⚫ 新しい脆弱性が見つかった場合もその脆弱性に関するイメージの評価ができる ⚫ ビルド・デプロイを許可するイメージを指定できる ⚫ SSHやtelnetなど、リモートシェルが有効になったイメージのデプロイを禁止できる ◼Twistlock sshはCustom complianceを有効にすれば可能 ◼Sysdig OK ◼Aqua OK Twistlockのカスタムコンプライアンス

Image Risks -3.1.2 Image configuration defects- ～コンテナイメージのコンフィグ不備を確認できるか～ 3.活動結果 ◼検証項目 ⚫ Dockerfile Best Practice、NIST SP800-190、PCIDSS、CIS Benchmark for Docker/Kubernetes、HIPAA、GDPR等に準拠した確認が可能か ◼Twistlock 用意されたテンプレートが豊富 Dockertfile Best Practices、CIS Benchmarkはカスタムコンプライアンスとして作成可能 ◼Sysdig 用意されたテンプレートが豊富 CIS Benchmark、HIPAAはカスタムポリシーで作成可能 ◼Aqua CIS Benchmark以外の準拠テンプレートがない準拠のためのホワイトペーパーがある Aquaのホワイトペーパー https://www.aquasec.com/resources/type/whitepaper/

Image Risks -3.1.3 Embedded malware- ～コンテナイメージに埋め込まれたマルウェアを検出できるか～ 3.活動結果 ◼検証項目 ⚫ 未知の実行可能ファイルの実行/配置を検知できるか ⚫ 予期しないポートのオープンを検知できるか ◼Twistlock いずれも不可 ◼Sysdig 振る舞い検知のため、シグネチャベースの検知はしない特定ポートが晒されたら検知可 ◼Aqua マルウェア検出は可能イメージスキャンでポートオープンの検知は不可 Sysdigの特定ポート検知設定

Image Risks -3.1.4 Embedded clear text secrets- ～コンテナイメージに埋め込まれたシークレットを検出できるか～ 3.活動結果 ◼検証項目 ⚫ シークレットや認証情報が含まれているイメージのデプロイを禁止できるか ◼Twistlock OK ◼Sysdig OK ◼Aqua OK Aquaの secrets検知

Image Risks -3.1.5 Use of untrusted images- ～信頼できないコンテナイメージが使用されてないことを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 使用するレジストリとイメージの一覧を確認できるか ⚫ レジストリを定期的にスキャンできるか ◼Twistlock OK ◼Sysdig NG ◼Aqua OK Aquaの Scan Time

Image Risks -3.1.5 Use of untrusted images- ～信頼できないコンテナイメージが使用されてないことを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 承認していないイメージのデプロイを禁止できるか ◼Twistlock OK ◼Sysdig OK ◼Aqua OK Sysdigのホワイトリスト/ ブラックリスト登録いずれも、コンテナイメージをホワイトリスト・ブラックリストに載せる運用を行う必要があるなお、AWS CodePipeline連携はできなくて、 Jenkins連携により承認してないイメージのデプロイは禁止といったことについては未検証

Image Risks -3.1.5 Use of untrusted images- ～信頼できないコンテナイメージが仕様されてないことを確認できるか～ 3.活動結果 ◼検証項目 ⚫ イメージが暗号署名されていることを確認できるか ⚫ イメージのデプロイ前にベースラインの署名を確認できるか ◼Twistlock NG ◼Sysdig NG ◼Aqua NG Image Digestsを確認できるものはあるが、それが例えば正規のNginxであることを認識できたりはしない。

Registry Risks -3.2.1 Insecure connections to registries- ～セキュアではないレジストリへの接続を確認できるか～ 3.活動結果 ◼検証項目 ⚫ レジストリへの暗号化されていないpush/pullを禁止できること ◼Sysdig 未検証 ◼Aqua 未検証 ◼Twistlock NG(registryの保護機能はない) ECRでは検証不可。プライベートレジストリでの検証を行っていないため

Registry Risks -3.2.2 Stale images in registries- ～レジストリ内の古いイメージを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 最新のタグ（latestや特定の最新バージョン）ではないイメージのデプロイを禁止できる ◼Sysdig OK ◼Aqua OK ◼Twistlock OK 使用するイメージの個別のバージョンを指定するユニークな名前を使用してイメージにアクセスする(Ex.my-app：2.3やmy-app：2.4) あるいは、イメージに「latest」タグを使用し、展開自動化でこのタグを参照するただし、このタグはイメージに添付されたラベルにすぎないので、鮮度を保証するものではない。組織が個別の名前を使用するか「latest」タグを使用するかを問わず、自動化で最新のユニークな名前を使用するか、「latest」のタグが付いたイメージが実際に使用されることを確認するプロセスを配置することが重要。

Registry Risks -3.2.3 Insufficient authentication and authorization restrictions- ～不十分な認証と認可を制限できることを確認できるか～ 3.活動結果 ◼検証項目 ⚫ リポジトリにアクセスする際、認証/認可を設定しているか確認できる ⚫ リポジトリにアクセスできるアカウントを制限できていることを確認できる ⚫ レジストリへのアクセスに関して監査ログを取得していることを確認できる ◼Sysdig 総じてNGだが… ◼Aqua 総じてNGだが… ◼Twistlock 総じてNGだが… 個々のリポジトリやレジストリ側での対応が必要となり、コンテナセキュリティサービス側で確認可能かを見たため、NGといっても、製品が悪いわけではない。AWSなら監査ログはCloudTrailで取得されるべき。

Orchestrator Risks -3.3.1 Unbounded administrative access- ～制限のない管理者アクセスを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 作業用ユーザがRBACで許可されていない操作を実行した場合にアラートを通知することができる (Docker on EC2は対象外) ◼Sysdig NG ◼Aqua Fargate環境以外はOK ◼Twistlock ECS環境以外はOK(k8sのAuditLog で確認) Twistlockの Forbidden unauthorized requests

Orchestrator Risks -3.3.2 Unauthorized access- ～不正なアクセスを確認できるか～ 3.活動結果 ◼検証項目 ⚫ パスワードだけでなく多要素認証を設定していること ◼Sysdig NG ◼Aqua NG ◼Twistlock EKS/ECS on EC2においてはMFA未設定のIAMユーザーについてのアラートは出せるが、k8sとの連携は不可 TwistlockのAWS MFAポリシー

44 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. ◼Sysdig
コンテナ間の通信確認は可能イメージ/subnet間での制御不可 namespaceでの指定は可 ◼Aqua コンテナ間の通信確認は可能イメージ/subnet間での制御不可 namespaceでの指定は可 3.3 Orchestrator Risks -3.3.3 Poorly separated inter-container network traffic- ～分離が不十分なコンテナネットワークトラフィックを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 役割の異なるコンテナ(AP, DB等)が異なる仮想ネットワーク上で稼働していることを確認できること ◼Twistlock コンテナ間の通信確認は可能イメージ/subnet間での制御は可能 namespaceでの指定は可 Twistlockのコンテナ間通信可視化

Fargate/Docker以外はどのホストでどのコンテナが稼働しているかは確認できる ◼Aqua Fargate/Docker以外はどのホストでどのコンテナが稼働しているかは確認できる 3.3 Orchestrator Risks -3.3.4 Mixing of workload sensitivity levels- ～機微レベルが混在したワークロードを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 役割の異なるコンテナ(AP, DB等)が異なるホスト上で稼働していることを確認できること ◼Twistlock NG どのホストでどのコンテナが稼働しているかは確認できる。ただし、コンテナの役割を判断できないため、APやDBコンテナが同一ホストで稼働してもアラートを上げることはできない。

NG ◼Aqua Nodeの定期的なスキャンは可能だが、切り離しまではできない 3.3 Orchestrator Risks -3.3.5 Orchestrator node trust- ～オーケストレーター側でノードを信頼できるか～ 3.活動結果 ◼検証項目 ⚫ WorkerNode上でセキュリティ侵害が発生した場合にWorkerNodeをクラスタから切り離せること ⚫ MasterNodeとWorkerNode間の通信が暗号化されていること ◼Twistlock NG 考えとしては、いずれの製品も、ネットワークトポロジーの可視化・コンテナ間の通信の可視化により、傍受されていないこと、不正な通信が行われていないかをチェックすることに重きを置いているのではないか？と考える。

ランタイムの脆弱性検知は可能デプロイ禁止といった抑制不可 ◼Aqua ランタイムの脆弱性検知は可能デプロイ禁止といった抑制不可 3.4 Container Risks -3.4.1 Vulnerabilities within the runtime software- ～脆弱なランタイムソフトウェアの検知が可能か～ 3.活動結果 ◼検証項目 ⚫ (例えば古いDockerをインストールして)ランタイムの脆弱性を検知できるか ⚫ 例えばruncに脆弱性が発見された場合 • 該当のruncで動作している全コンテナを停止する • 該当のruncが動作しているノードへのデプロイを禁止する ◼Twistlock ランタイムの脆弱性検知は可能デプロイ禁止といった抑制不可 Sysdigのランタイム脆弱性確認

OK ◼Aqua OK 3.4 Container Risks -3.4.2 Unbounded network access from containers- ～コンテナからの制限のないアクセスを確認できるか～ 3.活動結果 ◼検証項目 ⚫ コンテナネットワーク内におけるポートスキャニングや危険な通信先への接続等、ネットワーク異常を検出できること ◼Twistlock OK AquaのPortScan検知

OK ◼Aqua Serviceのコンテナ側プロセスポートのみ可能 Serviceより外側にあるネットワーク・エンティティは検出不可 3.4 Container Risks -3.4.2 Unbounded network access from containers- ～コンテナからの制限のないアクセスを確認できるか～ 3.活動結果 ◼検証項目 ⚫ ホスト側インバウンドポート、コンテナ内プロセスポートを含む適切なコンテナネットワークの自動検出 ⚫ パケットのカプセル化の有無に関らず、コンテナ・非コンテナ間の通信の流れを確認 ◼Twistlock ユーザーでポリシー設定が必要通信の流れは確認可能 SysdigのNW自動検出

OK ◼Aqua OK 3.4 Container Risks -3.4.3 Insecure container runtime configurations- ～セキュアではないコンテナランタイムのコンフィグを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 不適切な設定のコンテナランタイムを継続的に検出できる ⚫ 自動的に継続的にシステムのコンプライアンスを評価できる(CIS Benchmark Docker/Kubernetes) ◼Twistlock OK Twistlockのコンプラ評価

NG (2020/03よりLinux評価可能) ◼Aqua Linux評価可能 vShiledで実環境の設定変更orデプロイをせずに脆弱性を軽減する事ができる 3.4 Container Risks -3.4.3 Insecure container runtime configurations- ～セキュアではないコンテナランタイムのコンフィグを確認できるか～ 3.活動結果 ◼検証項目 ⚫ 自動的に継続的にシステムのコンプライアンスを評価できる(CIS Benchmark Linux) ⚫ コンプライアンスに沿って設定を強制的に書き換えることができる ◼Twistlock Linux評価可能強制書き換え不可 AquaのvShield

自動プロファイル機能はない設定したFalcoルールに沿って異常動作の検知や該当コンテナの停止が可能 ◼Aqua Linux評価可能 vShiledで実環境の設定変更orデプロイをせずに脆弱性を軽減する事ができる 3.4 Container Risks -3.4.4 App vulnerabilities- ～アプリケーションの脆弱性について確認できるか～ 3.活動結果 ◼検証項目 ⚫ 機械学習を用いてコンテナ化されたアプリを自動的にプロファイリングし、セキュリティプロファイルを構築できる ⚫ ランタイム時に、異常イベントを検知して、防止できる ◼Twistlock Linux評価可能強制書き換え不可 Sysdigの振る舞い検知無効または予期しないプロセス実行無効または予期しないシステムコール保護された構成ファイルとバイナリの変更予期しないパスとファイルへの書き込み予期しないネットワークリスナーの作成予期しないネットワーク宛先に送信されたトラフィックマルウェアの配置検知、実行検知

OK ◼Aqua OK 3.4 Container Risks -3.4.5 Rogue containers- ～不正なコンテナがないか検出/監査できるか～ 3.活動結果 ◼検証項目 ⚫ 監査ログを取得できる ◼Twistlock OK AquaのAudit ただし、環境によっては、Docker on EC2だと取れない、ECSだと取れない等は環境や設定によって起きうる。

Host OS Risks -3.5.1 Large attack surface- ～ホストOSにおけるアタックサーフェスについて確認できるか～ 3.活動結果 ◼検証項目 ⚫ ホストが特定のOSを使用しているか確認できるか ◼Twistlock ECSを除いてOK ◼Sysdig 確認することができなかった ◼Aqua OK ただし、Sysdigとしてはコンテナセキュリティプラットフォームのサービスとして、ホストOS側のアクティビティを見ることは可能とするも、一般的なサービスセキュリティのためのNISTガイドに従うことを推奨している。(企業としての戦略) ※NIST SP800-190では、NIST SP800-123 [Guide to General Server Security]を指している。 Sysdigの 3.5全般に対する対応方針

Host OS Risks -3.5.2 Shared kernel- ～共有されたカーネルから確認できるか～ 3.活動結果 ◼検証項目 ⚫ コンテナが稼働しているホストOS上でアプリケーションが実行されていないことを確認できるか • 製品の画面からホストOS上のpsコマンド相当のプロセス起動状態を確認できることただし、Aquaとしてはホストのプロセス起動状況をpsコマンドのように一覧で取得することは出来ない。NISTへの対応としては「コンテナが必要なホストのリソースにのみアクセスできるよう制限します」とある。これはコンテナからホストのリソースにアクセス出来る範囲を制限できる、ということ。ファイルアクセスはポリシーで制御出来る。 ◼Twistlock リアルタイムではなく、フォレンジック機能を使って後追い可能 ◼Sysdig OK ◼Aqua 不可？たぶん、Twistlockと同じ結果では？ Sysdigのプロセス確認

Host OS Risks -3.5.3 Host OS component vulnerabilities- ～ホストOSコンポーネントの脆弱性を確認できるか～ 3.活動結果 ◼検証項目 ⚫ 3.5.1同様のため割愛

Host OS Risks -3.5.4 Improper user access rights- ～不適切なユーザーアクセス権限を確認できるか～ 3.活動結果 ◼検証項目 ⚫ ホストOS側の監査ができるか • 製品の画面からホストマシンのログイン履歴が確認できること • 製品の画面からホストマシンのコマンド履歴が確認できること ◼Twistlock 不可 ◼Sysdig OK ◼Aqua OK Aquaのホスト側コマンド確認

Host OS Risks -3.5.4 Improper user access rights- ～不適切なユーザーアクセス権限を確認できるか～ 3.活動結果 ◼検証項目 ⚫ GUIから必要最低限のファイルシステム権限でコンテナの実行を確認できるか ⚫ GUIから各コンテナのディレクトリ一覧が参照できるか（dfコマンド相当） ⚫ GUIから各コンテナがマウントしているホストマシンのディレクトリを確認できるか ◼Twistlock 不可 ◼Sysdig OK ◼Aqua OK Sysdigで Inadvised Container Activity として検知

60 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. Others
–Vulnerability Scan for Web App & Container Orchestrator- ～疑似攻撃環境からの脆弱性診断について～ 3.活動結果 ◼ Twistlock WAF機能にて攻撃を検知/遮断 ◼ Sysdig 不可 ◼ Aqua 不可 Twistlockの WAF機能 ◼ 検証項目 ⚫ OWASP ZAP – スパイダー/動的スキャンで簡易脆弱性スキャン ⚫ kube-hunter → いずれも検出せず(攻撃クエリを投げることができなかったため)

–Digital Forensics & Incident Response- ～フォレンジック、インシデントレスポンスが可能か～ 3.活動結果 ◼ Twistlock OK ◼ Sysdig OK(システムコールまで確認可) ◼ Aqua OK SysdigのDFIR ◼ 検証項目 ⚫ フォレンジックが可能か ⚫ インシデントレスポンスが可能か

–Products 仕様- ～ライセンスのキャパシティオーバー時の動作について～ 3.活動結果 ◼ Sysdig 正常動作しないと考えられる ◼ Aqua 正常動作しないと考えられる Twistlockの Workload fluctuation ◼ Twistlock 上限を超えても製品は継続利用可 ※上限>月間平均値はOK ◼ 確認方法 ⚫ ベンダー問合せ ◼ 検証項目 ⚫ キャパシティ管理（契約絡みのサブスクリプションに関する上限こえたときの動き） https://docs.paloaltonetworks.com/prisma/prisma-cloud/19-11/prisma-cloud-compute-edition-admin/welcome/licensing

–Products 仕様- ～管理サーバ障害時のフェールセーフについて～ 3.活動結果 ◼ Sysdig エージェントは動作する ◼ Aqua エージェントは動作する ◼ Twistlock エージェントは動作する ◼ 確認方法 ⚫ ベンダー問合せ ◼ 検証項目 ⚫ 管理サーバ相当に接続できない場合の動作確認 Sysdigの場合、Sysdig Monitorが、 Aquaの場合、Aqua CSPが、 Twistlockの場合、Prisma Cloudが、何らかの不具合を起こしている場合を想定。エージェントは動作するも、イメージスキャンやログが確認できないといった動作は起きるものと考える。

–Products 仕様- ～ログの保存について～ 3.活動結果 ◼ Sysdig 最長1年等 Sysdig SaaS版だと最長10年キャプチャファイルの格納先に Amazon S3を指定可能 ◼ Aqua AquaDB(Postgres)に保存 DBサイズ限界まで出力可能ログ管理サービス(Stackdriver等) を指定可能 ◼ Twistlock 容量依存で、ファイルサイズ100MB を超えるとローテート 10ファイル分までバックアップを保持外部ストレージを指定することが不可 ◼ 確認方法 ⚫ ベンダー問合せ ◼ 検証項目 ⚫ 製品内/外でのログの保存方法や期間の確認

–Service Health Status- ～サービス提供状況について確認できるか～ 3.活動結果 ◼ Sysdig 可能 https://status.sysdigcloud.com/ ◼ Aqua CSPの監視を行う必要あり CSPから情報をあげる先のステータスは不明 Sysdigの Status確認 ◼ Twistlock 可能 https://status.paloaltonetworks.com/ ◼ 確認方法 ⚫ 管理サーバやサービスコンソールからサービス提供状態を確認できる

–AIOps- ～運用がAIで自動化されているか～ 3.活動結果 ◼ Sysdig コンテナ内のアクティビティを分析し、ランタイムの動作を自動的にモデル化、セキュリティポリシー化するような機能を予定 ◼ Aqua 実行中のコンテナの挙動をプロファイリングさせ、そのコンテナに適したランタイム保護のポリシーや FWポリシーを作成することが可能 ◼ Twistlock 機械学習をベースにしてコンテナランタイムのポリシーを自動生成 ◼ 確認方法 ⚫ ベンダー問合せ(3.4.4別途参照) ◼ 検証項目 ⚫ 面倒な運用の部分が自動化されているか各ベンダーごとにAIOpsの観点での意見は頂いたが、そのAIに関するブラックボックスな部分をどれだけ信用するか、どう管理するかは見極める必要あり。

67 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. Conclusion
～総まとめ～ 4.まとめ ◼優劣つけがたし ◼以下は個人的観点： ⚫ Sysdigはセキュリティ担当者が好みそう • コンテナの深いところまで、セキュリティ対策をしよう • システムコール含め、DF/IRが詳細に確認可能である ⚫ Aquaはアプリ開発者が好みそう • vShield機能により、すぐにアプリ改修が出来なくても仮想パッチで回避 • 他社製品も含めたインテグレーションのし易さ ⚫ Twistlock(PrismaCloud)は情シス担当者が好みそう • WAF機能あり、サーバーレス対応あり • クラウドそのものを統括的にセキュリティ管理しようとしている ◼ アプリ開発者(Dev)、セキュリティ担当者(Sec)、運用担当者(Ops)とで工数に対するアウトプットが最大化となるコンテナセキュリティサービスを選びましょう

68 Copyright （C） NRI SecureTechnologies, Ltd. All rights reserved. ◼SCSK株式会社
◼Sysdig Japan合同会社 ◼クリエーションライン株式会社 ◼Aqua Security Software, Ltd ◼マクニカソリューションズ株式会社 ◼パロアルトネットワークス株式会社 ◼GOODWITH LLC., (順不同) Special Thanks to

いくつかの商用コンテナセキュリティサービスをNIST SP800-190ベースに、独自観点を追...

いくつかの商用コンテナセキュリティサービスをNIST SP800-190ベースに、独自観点を追加して検証した話

More Decks by Shun Yoshie

Other Decks in Technology

Featured

Transcript