【SecurityJAWS】Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース

1. 1 2018/5/16(水) フューチャーアーキテクト株式会社 Kibana Canvasで魅せる！ AWS環境における脅威分析ユースケース

2. 2 本日、伝えたいこと  ElasticStackで構築するログ分析プラットフォーム  CloudTrailのログを参考にした脅威分析のコツ ※資料は終了後公開します

3. 3 自己紹介① 名前：日比野恒 (ひびのひさし) 所属：フューチャーアーキテクト株式会社セキュリティアーキテクト (CISSP、CISA、RISS)  AIなどの「システム高度化」により、ITリテラシーの非対称性が拡大している  IoT/コネクテッド領域など、ITが人々の生活に密接に関わるにつれ、危機感を持つようになる  オープンな技術を用いたセキュリティログの分析プラットフォーム開発に従事し、今に至る

4. 4 自己紹介② 名前：中井祐季 (なかいゆうき) 所属：フューチャーアーキテクト株式会社コンサルタント（3年目）新卒入社 2016/4 AWSとの出会い（たぶん） 2017/6ElasticStack との出会い 2016/7 初登壇 2017/10 初セキュリティ案件 2018/1 今ココ！  セキュリティ歴もAWS歴も浅いですが、よろしくお願いします。

5. 5 1. オープンSIEM構想

6. 6 オープンSIEM構想とは「オープンな技術」、「オープンな環境」でSIEMを作りたい！オープンな技術オープンな環境× 例えば、各製品のログフォーマットを正規化するためのLogstashのフィルタを公開。少ない貴重なエンジニアリソースをシェアリングして皆でオープンな技術でSIEMを構築していく等。

7. 7 保護対象システムネットワーク (多層防御) オープンSIEMカバー範囲業務視点でのセキュリティ監視に強みを発揮業務とアプリケーションに強みを持つ者の視点でセキュリティ監査を実現する。ファイアウォール IDS/IPS WAF アンチウィルスサンドボックススパムフィルタ外部脅威内部不正インスタンス/サーバ OS データ(機密) データベースアプリミドルクラウドサービス一般的な商用SIEM製品の得意領域我々の考えるSIEMの得意領域  外部からシステムを守ることを主目的としているため入り口になるネットワーク寄りの監視が得意領域

8. 8 シンプルな分析画面とすること！無駄にカッコ良いものを目指さない。分かりやすさ重視のシンプルなものを提供するのがコツ。  だれでも  いつでも  どこでも確認が可能であること【期待できる効果】  脅威検知時以外でも変化に気づくようになる。  ログから読み取れる情報に対する関心が高まる。

9. 9 ログ分析システムキッカケは意外なところから... 金融機関のマイナンバー管理のサブシステムとしてスタート！！データベース (暗号化) WebAPIPSLBFW LAN Internet 利用ユーザ (スマホ) 番号登録担当 (PC端末) 踏台 SQL監査ログAPI実行ログ認証ログ通信ログ LogstashElasticsearchKibana 【法令要件に準拠するため、業務視点での監視と監査を実現】  マイナンバーを参照するAPIは基本的に叩かれない。 →参照系APIが叩かれたら不正操作となる。  メンテナンス作業は申請ベースで厳格に行われる。 →申請外で踏台ログインや直接データベース接続されたら不正操作となる。操作録画ソフトマイナンバー SQLAPI

10. 10 お国のシステムにも導入してみた標的型サイバー攻撃を想定したセキュリティ統合管理基盤のSIEMでElasticStackを採用。 SIEMサーバログファイル (Linux) Syslog イベントログ (Windows) Filebeat Winlogbeat セキュリティ監査端末 Windowsサーバ Linuxサーバ UTM Sandbox Proxy 【監視業務】１．マルウェア検知システムの監視２．業務時間外の不正通信の監視３．許可していない外部向け通信の監視４．不正なUserAgentでのWeb通信の監視５．ファイル転送システムの不正利用の監査６．管理者によるOSへの不正ログインの監査 etc... Anti Virus Mail (MTA) File Tracefer Logstash Elasticsearch Kibana Kibana HA構成 Logstash HA構成 Elasticsearch Elasticsearch クラスタ構成

11. 11 SIEM AWS環境における導入が次々と RDSやS3に個人データを保持するシステムが増加し、不正監査をする仕組みでAWS導入。 AZ-a AZ-c Internet WebAP#01 IF#01 WebAP#02 IF#02 踏台 SIEM#01 SIEM#02JOB 利用者 IF連携システム保守者 SIEM#03AZ-d 大量個人情報の保有

12. 12 2. アーキテクチャの概要

13. 13 AWS環境であっても基本的な考え方は同じ「不正利用/なりすまし」や「不正アクセス/不正侵入」に対する技術的対策は変わらない！

14. 14 ログ分析における全体連携図ログ管理DB ログファイル性能データイベントログ Metricbeat Filebeat Winlogbeat Logstash input s3 クライアントサーバネットワークトラフィックパケットキャプチャ Packetbeat KibanaElasticsearch search Windows Linux アクセスログ SQL監査ログ VPC Flow Logs CloudTrail 操作ログ WAFログ改ざん検知認証ログ Auditbeat input cloudwatchlogs input beats Alerting セキュリティ担当 Security Machine Learning Mail EC2 アクセスログ永続性確保

15. 15 Elasticプロダクトの活用イメージ脅威分析のユースケースにおいて、Elasticプロダクトを活用するとこんな感じになる。 Kibana Elasticsearch Logstash Beats アラート性能監視グラフセキュリティ X-Pack Elastic Stack (オープンソース) 有償サブスクリプション機械学習レポート正規化保存/蓄積可視化認証/暗号化通知相関分析異常検知取り込み【全体コンポーネント構成】 Platinum Edition Gold Edition ※ 有償サブスクリプションを購入することでX-Packの有償機能とメーカーサポートを受けることが可能になります。 ※ エディションに応じて、利用できる機能およびサポートレベルが異なります。 ※ ライセンスはElasticsearchクラスタのノード数購入する必要があります。(最小3ノードから)

16. 16 【参考】有償プラグイン(X-Pack) 有償プラグインであるX-Packでは、エンタープライズ向けに6種類の製品が提供されている。 Security Monitoring Reporting Alerting Graph Machine Learning  データの変化を検知  多種多様な通知方法  ダッシュボードのレポート化(PDF等)  Alertingと組み合わせたレポートのスケジュール通知  Elasticsearchクラスタの性能情報  Kibanaの性能情報  Logstashの性能情報  データの関連性を可視化  教師無し機械学習によるデータ分析  時系列異常検知  はぐれ者検知  稀有な非構造メッセージ検知  Kibanaの認証  Kibanaの通信暗号化  AD/LDAP認証連携  API監査  ドキュメント暗号化

17. 17 【参考】ElasticStackの性能管理方法無償でElasticStackの性能管理ができるX-Pack BasicのMonitoringは使うべし！！参考URL https://www.elastic.co/jp/products/x-pack/monitoring 【Elasticsearch】 Search Rate、Search Latency、Indexing Rate、Indexing Latency、JVM Heap、CPU Utilization、Latency、Index Memory、System Load、Sement Count、GC Count、GC Duration、Request Rate、Indexing Threads、Read Threads、Cgroup CPU Performance Cgroup CFS Stats、Document Count 【Kibana】 Client Requests、Client Response Time、Memory Size、HTTP Connections、System Load、Event Loop Delay 【Logstash】 Events Received Rate、 JVM Heap、Events Emitted Rate、 CPU Utilization、Event Latency、System Load

18. 18 【参考】Beatsの採用ポイント(1/2) EC2内のログ収集にはCloudWatchLogsエージェントがあるが... エージェントログファイルイベントログ/IISログ Beats ログファイルイベントログ性能データ改ざん検知認証ログ CloudWatchLogs 【CloudWatchLogsエージェント】【Beats】 Athena (ETL) RedShift (分析) ログ管理DB Logstash Logstash Elasticsearch 【特徴】  ログ正規化を行い、Elasticsearchに出力することが出来る  ログ形式に合わせたBeatsをGo言語で自作することが出来る  ElasticsearchかLogstashにしかoutput出来ないので、S3に上げるのがメンドイｗ

19. 19 【参考】Beatsの採用ポイント(2/2) Elasticには、データの取り込みツールに「Beats」と「Logstash」の2種類がある。正しい使い分けについて良く質問をもらうので、まとめてみた。  Go言語による実装でシンプルで軽量  特定ソースからのデータ取り込み  データ保存先はLogstash/ESのみ  エージェント用途での利用  Javaベースで大量メモリ消費  多種多様なソースからのデータ取り込み  多種多様なフィルタによるデータ加工  多種多様な保存先にデータ出力

20. 20 3. 脅威分析のユースケース

21. 21 そろそろ本題に入らないとアカン！！前置きは程ほどにして、AWS環境における「外部」と「内部」の脅威対策について１．外部の脅威対策 →ハッキング攻撃対策２．内部の脅威対策 →機密データ不正取得対策

22. 22 外部からのハッキング攻撃の分析ポイント不審なIPまたは国からの不正なログイン行為やAPIの監査がポイントになる。ハッカー集団 APIs 各種AWSサービス管理コンソール Internet CloudTrailログ SQL監査ログ API実行ログアクセスログ APIサーバ攻撃通信【凡例】ログ連携 AWSAPICalls ConsoleSignIn

23. 23 内部犯行による機密情報不正奪取の分析ポイント特に、機密データに対するシステム管理者の操作の監査方法がポイントになる。踏台ログファイルイベントログ改ざん検知認証ログシステム管理者 (運用保守) SQL監査ログアクセスログ管理コンソール CloudTrailログ RDP or SSH HTTPS ⑤データ暗号鍵ダウンロード ⑥機密データアクセス SQL AWS CLI ①不正ログイン ②不正ログイン ③不正コマンド実行 ④ログ改ざん ①不正ログイン監査 ⑤不正ダウンロード監査 ⑥不正SQL監査 ②不正ログイン監査 ③不正OSコマンド実行監査 ④ログ改ざん監査

24. 24 内部犯行の特定は、ログと作業記録との突合せで！！件数だけでは判断できない認証ログ、アクセスログは作業申請との突合せで内部不正やマルウェア攻撃による潜伏行動の早期発見につなげることが出来る。システムによる管理人手による管理ログ (システムから出力) 作業記録 (人が作成) 日常的なモニタリングセキュリティ監査【システム管理者】 ①不正(ルール違反、さぼり)のチェック ②ミス(処理漏れ、誤り)のチェック【セキュリティ監査者】 ①情報漏洩や内部不正のチェック ②セキュリティ機能のチェック

25. 25 CloudTrail分析

26. 26 CloudTrailのログの分析ポイント管理コンソールへのログインやAPI操作を「いつ」・「誰が」・「どこから」実行したかを抑える。 ※Logstashのgeoip filterを用いて、送信元IPアドレスに国情報を付加しておく。 eventType AwsAPICall AwsConsoleSignIn userIdentity.type responseElements.ConsoleLogin IAMUser Root AWSService AssumedRole AwsAccount eventName Console Login CheckMfa SwitchRole Success Failure responseElements.CheckMfa Success Failure responseElements.SwitchRole Success Failure Field Name Value 【凡例】 Additional EventData.MFAUsed Yes No geoip.ip geoip.country_name userIdentity.type userIdentity.username @timestamp eventName API名 API名 ※ APIごとにイベントが存在し、大量のイベントが存在する。存在しないIAMUserでログイン施行があると「userIdentity.username 」に「HIDDEN_DUE_TO_SECRITY_REASONS」と出る。 MFAを利用したログイン行為を実施しているかのチェックに「Additional EventData.MFAUsed」を利用する。

27. 27 不正API分析画面サンプル(1/3) 秘密秘密秘密秘密秘密 When Where Who What IAMUserの実行したAWS APIコールに関するCloudTrail操作ログを分析する。絞り込む分析軸

28. 28 不正API分析画面サンプル(2/3) パターン①: 送信元IPアドレス「54.239.22.23」で絞ってみる。該当するIAMユーザは表示されなかった。イベントにはNetworkInterfaceに関するAPIが集計された。 54.239.22.23はAWSが保持しているIPアドレスで ENIに関する操作を指示するAPIがこのIPから発呼されていると推察できる。

29. 29 不正API分析画面サンプル(3/3) パターン②: IAMユーザ「alex」で絞ってみる。秘密秘密秘密自宅、会社、WiFiルータの3つの認識しているグローバルIPアドレスのみが表示された。認識していない不審な国やIPアドレスがなくひと安心 ^o^y

30. 30 不正ログイン分析画面サンプル(1/3) 秘密 AWS管理コンソールへのログインに関するCloudTrail操作ログを分析する。絞り込む分析軸

31. 31 不正ログイン分析画面サンプル(2/3) 秘密秘密イベント名「ConsoleLogin」で絞ってみた。ログインに失敗している回数が28回もいた。ログイン時にMFAを有効化していないログインが4回も出ている。多要素認証を設定していないユーザを特定してみる。

32. 32 不正ログイン分析画面サンプル(3/3) 追加でMFA利用有無を「No」で絞ってみた。間違ったIAMユーザ名で2回、alexが2回 MFAを利用しないでログインを施行している。間違ったIAMユーザのログインは「Failure」であることが分かる。秘密秘密

33. 33 番外編

34. 34 ログからアプリケーション脆弱性攻撃を検出 CLBのアクセスログからアプリの脆弱性を付いた攻撃が発生していることを検出。 Jorgeeとは、phpmyadminの脆弱性をスキャンするツールで利用されるUserAgent名。攻撃の兆候を特定。国別のアクセス数を集計し、明らかに異常に多いアクセスがある国からのアクセスについては、内容を確認し、必要な部分についてはフィルタリング等の対応を実施

35. 35 Machine Learningで異常検知 CLBの遅延時間の大きい時間帯のアクセスで異常検知し、おかしなUserAgentを発見。 DoS攻撃の検知

36. 36

37. 37 あれ？Canvasの話はしないの？？

38. 38 Kibana Canvasで魅せられなかった！ごめんなさい客寄せパンダ失格(汗)

39. 39

40. 40 Appendix

41. 41 Elasticsearch

42. 42 EC2 Discovery Pluginでクラスタを組もう AWSのSecurity Groupを認識して所属しているElasticsearchノードを探しに行く。【参考】EC2 Discovery Plugin https://www.elastic.co/guide/en/elasticsearch/plugins/6.2/discovery-ec2.html Security Group VPC ES01 ES02 ES03 Elasticsearch Cluster # export ES_JAVA_OPTS=“-Dhttps.proxyHost=<プロキシIP> -Dhttps.proxyPort=<ポート>" # /usr/share/elasticsearch/bin/elasticsearch-plugin install discovery-ec2 # vi /etc/elasticsearch/elasticsearch.yml # --------------------------------- Discovery ---------------------------------- discovery.zen.hosts_provider: ec2 discovery.ec2.groups: "<SecurityGroupID>" discovery.ec2.availability_zones: [ "ap-northeast-1a", "ap-northeast-1c" ] cloud.aws.region: ap-northeast-1 # ---------------------------------- Cloud AWS -------------------------------- cloud: aws: protocol: https proxy: host: <プロキシサーバのIPアドレス> port: <プロキシサーバのポート番号> # systemctl restart elasticsearch 【導入手順】 ※プロキシサーバ環境の場合に必要 Elasticsearch Cluster用 IAMロールを割り当てる

43. 43 EC2 Repository S3 Pluginでバックアップとリストアを簡単に！シームレスにS3 Bucketに対して、IndexのSnapshotをバックアップとリストアが可能。【参考】Snapshot And Restore https://www.elastic.co/guide/en/elasticsearch/reference/6.2/modules-snapshots.html#_repository_plugins Curator repository-s3 S3 Bucket (log-a) /backup/index # export ES_JAVA_OPTS=“-Dhttps.proxyHost=<プロキシIP> -Dhttps.proxyPort=<ポート>" # /usr/share/elasticsearch/bin/elasticsearch-plugin install repository-s3 【導入手順】 ※プロキシサーバ環境の場合に必要 Elasticsearch Index 1 2 Snapshot Curator用IAMロールを割り当てる PUT /_snapshot/my_s3_repository { "type": "s3", "settings": { "bucket": "log-a", "region": "ap-northeast-1", "base_path": "backup/index", "compress": "true", "server_side_encryption": "true" } }

44. 44 Elasticsearchノードをテンプレート化する時の考え方 Elasticsearchを導入してAMI化するとクラスタへの追加時にノードID重複となる。 EC2 CentOS 7 Java 8 Python Curator AMI EC2 CentOS 7 Java 8 Python Curator イメージ化インスタンス作成  Java導入  Curator導入  Elasticsearchは導入しない Elasticsearch Elasticsearchを設定  Elasticsearch導入  ingest plugin導入  aws cloud plugin導入  elastisearch.yml設定  jvm.options設定  X-Pack導入 Elasticsearch Cluster ES01 ES02 ES03 1 2 3

45. 45 Elasticsearchのクラスタに対するAPIアクセス KibanaとElasticsearchが別ノードの場合はロードバランサを挟む必要がある。【参考】Load Balancing Across Multiple Elasticsearch Nodes https://www.elastic.co/guide/en/kibana/current/production.html#load-balancing Elasticsearch Cluster Elasticsearch01 Elasticsearch02 Elasticsearch03 Kibana Internal-ELB TCP9200 TCP9200 # The URL of the Elasticsearch instance to use for all your queries. elasticsearch.url: “http://<Internal-ELBのFQDN>:9200" 【kibana.ymlの設定】 ※elasticsearch.urlは、URLを1つしか指定出来ない。

46. 46 Logstash

47. 47 LogstashをECSでコンテナサービス化しよう！コンテナ化することでLogstashをタスクとして実行することが可能になる。 ※Logstash 6xはMultipipeline対応しているので、そちらでもある程度いい感じに出来る。 EC2 (ビルドマシン) CentOS 7 Docker 1.12 CentOS 7 Logstash Dockerfile Image ECS ECR docker pushdocker build ECS Cluster EC2 (ECS最適化) EC2 (ECS最適化) Docker 1.12 ECS Agent Logstash Docker 1.12 ECS Agent Logstash docker pull ECS最適化AMI (ami-ab5ea9cd) 【ECS化のメリット】  障害時のエラーハンドリング  ログの量やリアルタイム性に応じた柔軟なサイジング【IAMロール】 AmazonEC2ContainerRegistryPowerUser 【IAMロール】 AmazonEC2ContainerServiceforEC2Role

48. 48 ログは全てS3を介して取り込むべしログ形式毎にフォルダを切ってS3にログを収集することで障害時のハンドリングが容易になる。ログファイルデータベースネットワーク機器イベントログ Filebeat Winlogbeat Logstash (収集) input jdbc input tcp/udp (syslog/netflow) S3 Bucket (bucket-a) /log /backup AWS各種アクセスログ Logstash (正規化) S3アクセスログ CloudFront アクセスログ ELB アクセスログ Elasticsearch input s3output s3 output es 1 2 3 input { s3 { backup_to_bucket => “bucket-a" backup_add_prefix => “backup/" delete => "true" bucket => "bucket-a" region => "ap-northeast-1" prefix => “log/log-a" interval => "5" sincedb_path => "/var/lib/logstash/sincedb" } } log-a Logstashで取り込まれた後生ログは/backupで保持される

49. 49 S3で難しいものは、泣く泣くCloudWatchLogs CloudTrailの操作ログはJSON形式だが、複数並列の[]がうまくパース出来ない問題。 S3アクセスログ CloudFront アクセスログ ELB アクセスログ CloudTrail 操作ログ RDS SQL監査ログ S3 Bucket Cloud Watch Logs Logstash (正規化) input s3 output es input cloudwatch_logs input { cloudwatch_logs { log_group => [ "CloudTrail/DefaultLogGroup" ] region => "ap-northeast-1“ codec => json } } 【参考】input cloudwatch-logs plugin https://github.com/lukewaite/logstash-input-cloudwatch-logs Elasticsearch

50. 50 Kibana

51. 51 Kibana認証と暗号化には、ELBとNginxを噛ませるデフォルトのままだとHTTP通信になるため、ELBでHTTPS(TCP443)化する。また、Nginxの認証機能を利用して、Kibanaアクセスに認証機能を追加する。 Internet ElasticsearchKibanaExternal-ELB HTTPS(TCP443) セキュリティ運用者 (SOC等) ＃送信元宛先ポート 1 NginxのSecurity Group TCP 5601 ＃送信元宛先ポート 1 セキュリティ運用者のGIP TCP 443 Security Group ＃送信元宛先ポート 1 ELBのSecurity Group TCP 8080 2 ELBのSecurity Group TCP 8081 HTTP(TCP8080) HTTP(TCP5601) ELBヘルスチェックは、Kibanaまで到達出来るパスを指定し NginxまたはKibanaの障害時に切り替わるように設計する ①通信暗号化 ②ユーザ認証

52. 52 マルチテナント環境で利用する場合は... 1つのElasticsearch Clusterに対して、テナント(ユーザ企業)ごとにKibanaを用意する。 Kibana02 Kibana01 Kibanaxx Elasticsearch Cluster Internet ユーザ企業A社 (SOC運用担当) ユーザ企業B社 (SOC運用担当) ユーザ企業Z社 (SOC運用担当) ・・・ Store ELB01 ELB02 ELBxx ・・・・・・ Elasticsearch01 Elasticsearch02 Elasticsearch03 Elasticsearch04 Elasticsearch05

53. 53 Other Settings

54. 54 Elasticsearchに必要なIAMロール { "Statement": [ { "Action": [ "ec2:DescribeInstances“ ], "Effect": "Allow", "Resource": [ "*“ ] } ], "Version": "2012-10-17“ } Elasticsearch Cluster用 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", “Resource”: “arn:aws:s3:::<S3 Bucket名>/backup/index/*“ } ] } Curator用

55. 55 Logstashに必要なIAMロール { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*“ } ] } input S3用 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:CreateCluster", "ecs:DeregisterContainerInstance", "ecs:DiscoverPollEndpoint", "ecs:Poll", "ecs:RegisterContainerInstance", "ecs:StartTelemetrySession", "ecs:UpdateContainerInstancesState", "ecs:Submit*", "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "logs:CreateLogStream", "logs:PutLogEvents“ ], "Resource": "*“ } ] } ECSクラスタ用

56. 56 elasticsearch.ymlのサンプル # ---------------------------------- Cluster ----------------------------------- cluster.name: es_cluster01 # ------------------------------------ Node ------------------------------------ node.name: node-es01 # ---------------------------------- Network ----------------------------------- network.host: 0.0.0.0 # --------------------------------- Discovery ---------------------------------- discovery.zen.hosts_provider: ec2 discovery.ec2.groups: "<SecurityGroupID>" discovery.ec2.availability_zones: [ "ap-northeast-1a", "ap-northeast-1c" ] cloud.aws.region: ap-northeast-1 # ---------------------------------- Cloud AWS -------------------------------- cloud: aws: protocol: https proxy: host: <プロキシサーバのIPアドレス> port: <プロキシサーバのポート番号> AWSとの通信にプロキシサーバを介す場合

57. 57 logstash.confのサンプル input { s3 { backup_to_bucket => “bucket-a" backup_add_prefix => “backup/" delete => "true" bucket => "bucket-a" region => "ap-northeast-1" prefix => “log/log-a" interval => "5" sincedb_path => "/var/lib/logstash/sincedb" } } filter { date { timezone => "Asia/Tokyo“ } } output { elasticsearch { hosts => [ “internal-<ELB名>-<AWSアカウント>.ap-northeast-1.elb.amazonaws.com:9200" ] index => “log-a-%{+YYYY.MM.dd}" template_name => "log-a" } }

58. 58 Dockerfileのサンプル FROM centos:7 # Ensure Logstash gets a UTF-8 locale by default. ENV LANG='en_US.UTF-8' LC_ALL='en_US.UTF-8' # timezone settings RUN cp -p /usr/share/zoneinfo/Asia/Tokyo /etc/localtime # install java1.8.0 RUN yum install -y java-1.8.0-openjdk ENV JAVA_HOME=/usr/lib/jvm/jre-1.8.0 COPY java.sh /etc/profile.d/java.sh RUN chmod +x /etc/profile.d/java.sh # install logstash COPY elastic.repo /etc/yum.repos.d/ RUN yum install -y logstash-5.5.x COPY logstash.conf /etc/logstash/conf.d/logstash.conf COPY logstash.yml /etc/logstash/logstash.yml #install plugins RUN /usr/share/logstash/bin/logstash-plugin install <plugins名> # enable systemd ENV container docker # exec logstash RUN systemctl enable logstash.service EXPOSE 5044 CMD [“/usr/sbin/init”]

【SecurityJAWS】Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース

Hibino Hisashi

【SecurityJAWS】Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース