この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
Security JAWS 第9回が開催されましたのでレポート致します。
Security JAWS 【第9回】 勉強会 2018年5月16日(水) - Security-JAWS | Doorkeeper
レポート
Session1:フューチャーアーキテクト株式会社 日比野 恒さん、中井 祐季さん「Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース」
[slideshare id=97184971&doc=securityjaws20180516-180515162942]
- 伝えたいこと
- Elasticで構築する脅威分析プラットフォーム
- CloudTrailでログ分析
- 1. オープンSIEM構想
- オープンな技術、オープンな環境でSIEMを作りたい！
- LogstashのフィルタやKibanaなど共有できる情報は共有したい
- 業務メインの会社なので業務視点でセキュリティ監視に強みを発揮できる
- シンプルな分析画面を作ることを意識している
- シンプルだとわかりやすく誰でも利用できる
- 見やすくすると変化に対して気づきやすくなる
- きっかけは意外なところから
- マイナンバー管理のサブシステムとしてKibanaなどを利用して分析した
- お国のシステムにも導入した
- 最近はAWS環境でも導入している
- RDSやS3に個人データを保持するシステムが増加し、不正監査をする仕組みを導入
- 2. アーキテクチャの概要
- 3. 脅威分析のユースケース
- 外部の脅威
- 不審なIP・国からのログインやAPIを監査
- 内部の脅威
- 機密データに対するシステム管理者の操作の監視がポイント
- 不正ログイン監査・不正ダウンロード監査
- 監査ログをきちんと別の場所に出す
- 監査ログを分析する
- ログの改ざんなどを確認する
- 内部犯行の特定はログと作業記録との突き合わせで確認する！
- 機密データに対するシステム管理者の操作の監視がポイント
- 外部の脅威
- CloudTrailでのログ分析
- ポイント
- 管理コンソールへのログインやAPI操作をいつ誰がどこから実行したかを抑える
- Logstashのgeoip filterを使うことによって送信元IPアドレスに国情報を更かしておく
- MFAを使用しているかを確認したりもできる
- ログイン失敗やMFA失敗、スイッチ失敗等をよく見る
- 存在しないIAM Userからのリクエストもチェック
- いろんなグラフが作れるが、複雑にしすぎないようにする
- GeoIP、ユーザ名、イベント名等程度にしておく
- IPから分析したり、IAMユーザで絞ったりして挙動を見ることができる
- イベント名、コンソールログインで絞ってMFAの利用状況が確認できる
- ポイント
- 番外編
- CLBのアクセスログからアプリの脆弱性をついた攻撃を見ることができる
- MLでDoS攻撃を異常検知で捉えることもできる
感想
Elasticの機能を利用してオープンソースだけでも良い感じのSIEMを利用できるのはすばらしいですね！
公開された資料を参考に、是非構築してみたいです！
Session2:Imperva Japan K.K. 岩下 洋司さん「WAFシグネチャとログとAI」
[slideshare id=98271374&doc=20180516sjaws-impervajpcontents-180523130230]
- Impervaソリューション
- アプリケーションセキュリティ
- データセキュリティ
- データもやってるよ！
- AWS WAFでSecureSphereのシグネチャを提供している件
- WAFのマネージドルールを提供
- IPレピュテーションとWordPress Protection
- 元々AWS WAFのルール設定は難しくセキュリティベンダーへのニーズがあった
- 提供に至るまでの検討事項
- SecureSphereとのユーザ層の違いがあり、AWSとの思惑が合致
- SecureSphereとの違い
- 機能面
- 動的アプリケーションプロファイリング
- 相関攻撃検証エンジン
- WAFコア機能
- ルール数
- 約1/3
- 提供されるIPレピュテーションの数
- 半分くらい(見た目)
- 機能面
- Imperva慣習IPレピュテーション情報をAWS WAFへ
- 毛色の違った情報
- SecureSphere用のThreatRadar(有償)をAWS WAFへ適用
- 有用性
- 75%のIPが1つ悪いことをすると他にも悪いことをする
- WAFのマネージドルールを提供
- セキュリティ装置のアラートが多い件
- アラートはとにかくいっぱい
- 1日あたり1万以上のアラートが飛んでくる管理者の環境が多い
- みんなうんざりしている
- WAFアラートの課題傾向と解決策
- アラートが多いとSIEMで分析も限界がある
- ベンダーがアラートの絞り込みを行う
- 攻撃も複雑化している
- AIで担当者が気づかないものを検知
- 人材は不足している
- 一時切り分けの解析を自動化
- ビューを統一にして見やすくする
- アラートが多いとSIEMで分析も限界がある
- Imperva Attacks Analyticsを提供予定
- WAFは不審なリクエストを検知
- 攻撃の一連の流れを捉える為にAIを使って分析
- ざっくりいうと
- 攻撃手法で重み付けしたり
- 教師なし学習
- 距離関数
- WAFメタデータ
- 独自のThreatRadar
- などなどを組み合わせている
- 分析の流れ
- クラウドにデータを上げて前処理
- 攻撃の特徴を抽出
- 位相分析
- クラスタリング
- 学術論文もあるらしい
- 実地試験で膨大なログを適切に絞り込めていることが確認できている
- 画面に表示されるデータはあんまり変わらないけど、きちんと絞れるのは重要
- アラートはとにかくいっぱい
- ログ分析の分野に今後AIが盛んに利用されていく件
- 新しいソリューションでいろんなログをクラウド上に投げて分析するものを作っている
- DBだけでなくキャッシュやファイルサーバ等からも集める
- なんでも自動に分析されてダッシュボードに表示
- データアクセスの分析も自動的にされる
- 直感的なレポートと詳細なフォレンジック機能がつく予定
- 新しいソリューションでいろんなログをクラウド上に投げて分析するものを作っている
感想
人手をかけなくても良い感じにログの分析をしてくれるのはうれしいですね。
どこまで出来るか、という所が気になりますがリリースを待ちましょう！
Session3:株式会社NTTドコモ 守屋 裕樹さん 「JAWS DAYSで話せなかった「Security x Serverless」の話」
- ドコモにおけるAWS利用の特徴
- ドコモでは約400のAWSアカウントを運用中
- CCoEが社内にある
- 情報セキュリティ部やプロジェクトやAWSと連係
- ガイドラインやテンプレートを作成している
- SSH全開放してたり、IAMユーザが棚卸しされていなかったり、いろんな問題が発生する
- クラウドは早い簡単便利！
- でも間違った使い方も簡単にできてしまう
- ガイドラインだけでは防げない
- だって、にんげんだもの。
- クラウドはAPIがあって自動化できる、怠慢しない
- だって、くらうどだもの。
- クラウドのいいところを利用しよう
- 社内向けにScanMonsterというシステムを作った
- AWS上に構築されたシステムの自動アセスメントツール
- 自動的・継続的に監視する
- 特徴
- 各種ガイドライン・ベストプラクティス準拠
- 57のチェック項目を実装
- Availability, Logs等5つに分類している
- 自動アセスメント
- アカウント横断
- 複数アカウントを利用しているユーザも多いため同一画面で複数アカウイントのアセスメント可能
- チュートリアル完備
- チュートリアルで問題の対策案を定時
- 利用開始が簡単
- 各種ガイドライン・ベストプラクティス準拠
- 設計実装方針
- 出来るだけお金をかけない
- Trusted Advisor
- クロスアカウント出来ない
- 全体で使うのは厳しい
- AWS config Rules
- クロスアカウント出来る
- ルールを集約しても結構費用がかかる
- AWS API
- がんばればなんとかなる！
- Trusted Advisor
- Serverlessで実装
- Cognitoで認証、SPAで実装
- Lambdaでこねこね、Dynamo保存
- 出来るだけお金をかけない
- 開発のトピック
- 権限管理どうする？
- Scanする側はAssumeRoleのみ付与
- TargetのRoleを利用する
- ユーザ認証はどうやっている？
- Custom AuthorizerとCognito User Poolを組み合わせている
- バックエンドはLambda
- Serverlessの接続元制限
- API GatewayのリソースポリシーにてIPアドレス制限可能
- 今回はこれを使わないでLambdaのEvent情報から取得している
- AWS WAFを利用してIPアドレス制限
- S3のBucket Policyでも絞れる
- API GatewayのリソースポリシーにてIPアドレス制限可能
- ログ収集
- API Gateway
- CloudWatch logsで取得
- 機密情報注意
- 1024バイトを超えるものは切り捨てられる
- Lambda
- CloudWatch logsで取得
- 各言語のメソッドを利用
- 明示的に指定する
- S3
- アクセスログ/CloudTrail
- CloudFront
- S3に出す
- Cognito User Pools
- ログイン履歴、認証の履歴などは取得不可
- Lambdaを使用したワークフローで取るのが現実解
- DynamoDB
- GetItemのログは取得不可
- API Gateway
- CloudWatch logs
- コンソールで見るのは無理なので外に出すのは必須
- AWS利用料
- トータルで$0.81！
- 権限管理どうする？
- まとめ
- クラウドだからこそ利用できるセキュリティ対策
- 自動化がいい
- まずは始めてみよう！
- Serverlessはうまく使えばメリットが多い
- クラウドだからこそ利用できるセキュリティ対策
感想
構想だけじゃなくて、実装してみるのはすごく大切ですね。
資料も公開されるようなので、要チェックですね！
Session4:SecureWorks Japan 株式会社 山崎 景太さん「攻撃者視点から考えるAWS EC2セキュリティインシデントとその対応」
- いろいろNGなので簡単にだけなのであしからず
- 気になる人は参加しましょう！
- SecureWorksはRedTeamTestingサービスを提供している
- 実際に使用されている先述、テクニック、手法を駆使してサイバー攻撃のシミュレーションを行う
- 物理侵入も含めて行う
- 今日の内容
- 外部からの攻撃によって発生するインシデント
- 攻撃者の視点から考える
- ○○からの攻撃
- ケーススタディ
- 外部からの攻撃によって発生するインシデント
- EC2環境で発生する基本的なインシデント
- 外部からの攻撃に寄るインシデント発生要因
- Webアプリの脆弱性
- OSコマンド実行系の脆弱性
- アクセス制御の不備
- SSHの公開は未だに多い
- AWS管理コンソールへの不正アクセス
- パスワードが弱かったり、MFA設定してなかったり
- 外部からの攻撃には条件が必要
- しかし、この次元のインシデントは沢山発生している
- 予算不足で診断してない、開発のクオリティが低い
- 現場の理解不足
- 外部からの攻撃への対策が徹底されていればいいのか？
- そうではない
- 攻撃者の視点から考える
- 攻撃ポイント
- AWSのシステムを運用しているのは社内ネットワークとか委託先、自宅もある
- 社内端末、外注委託先端末等を乗っ取ることによりアクセスできる
- 攻撃者としては脆弱性対策されているシステムに直接攻撃しないでゆるい端末を狙う
- VPCに侵入するために
- アクセス経路を確保する
- マネジメントコンソールやSSH
- アクセスに必要な認証情報を取得する
- IAM Account
- Root Account
- SSHの証明書
- アクセス経路を確保する
- Red Team Testing Approach
- 正規運用に使用する端末を乗っ取ると
- アクセス制御のバイパス
- 送信元IPの回避
- インターネットからアクセスでいないシステムへの接続
- 踏み台へのアクセス
- 認証情報の窃取
- 端末上の認証情報窃取
- 侵入の拡大
- 他の端末への侵入
- アクセスできる範囲の拡大
- アクセス制御のバイパス
- 正規運用に使用する端末を乗っ取ると
- 攻撃ポイント
- ○○からの攻撃
- マルウェアに感染させてしまえば遠隔操作でなんでも出来る
- 認証情報はローカルファイル以外にもファイルサーバ、電子メール、グループウェア、チャット、gitからもとる
- 抜くのはファイルだけじゃなくてメモリ上の内容等もある
- 内部に侵入してからもソーシャルエンジニアリングは有効
- ケーススタディ
- EC2関連認証情報の窃取
- よくある話: パスワード管理ファイルは暗号化しているよ
- ドキュメントを開いている時に定期的にスクリーンショットを取得する
- パスワードマネージャーソフトはクリップボードにコピーされる
- クリップボードをダンプできるのでこれも盗まれる
- よくある話: パスワード管理ファイルは暗号化しているよ
- マネジメントコンソールに不正アクセスしたい
- よくある話: MFAあるから大丈夫
- AWSマネジメントコンソールのセッションタイムアウトの時間は12時間ある(設定変更可)
- MFAバイパスはセッションが切れてない状態でアクセスする
- よくある話: MFAあるから大丈夫
- ソーシャルエンジニアリング
- パスワードが分かる人にメールとかチャットで聞く
- 端末を乗っ取っているので正規のメールアドレス・チャットアカウントで聞ける
- アクセス権を申請する事もできる
- EC2関連認証情報の窃取
- Wrap Up
- インターネットからの直接的な攻撃に対して必要な対策を講じておくのは当然
- 社内ネットワークを経由すればEC2に侵入する経路は増える
- インシデントは起こる
- なにかあったときの対応体制の整備も必要
- EC2のフォレンジック用データの取得
- ディスクイメージの保全とセキュリティベンダーとの共有はオンプレより迅速
- ボリュームスナップショットを取得してセキュリティベンダーのAWSアカウントと共有
- 暗号化されていたらCMKも共有
- OS内のデータロギング
- 原則オンプレと同様にログを取得
- 誰がどこからいつ何をしたかをわかるように設定する
- 攻撃者の気持ちを知ろう
- 闇落ちは厳禁
感想
攻撃のアプローチは本当にいっぱいあって怖いですね。
多層で防御したり、インシデントに対応できるように対策したりする必要がすごくありますね！
いろんな対策を怠らないようにしましょう！
Session5:電気通信大学 手柴 瑞基さん「自動車監視のためのクラウドソリューション+α」
- SecHack365
- セキュリティのハッカソンに参加していた
- 話すこと
- AWSを活用した自動車監視
- 自動車のセキュリティをターゲットにしている
- なぜやるのか？
- 自動運転社会の実現のために多くのドライバーの運転情報を集めなければならない
- 今後つながる車が増えると様々な攻撃が出てくる
- 幅広い自動車セキュリティ
- ナビ
- 携帯回線、WiFi、Bluetooth
- USB、CD/DVD、Audio
- OBD2ポート (CAN)
- 診断用端末
- キーフォブ
- コンピュータ (ECU)
- ナビ
- プロトタイプ
- 車の情報をクラウドに集約、それを活用したサービスを提供
- メーカや保険会社から提供されることを想定
- 危険を検知したらユーザに通知する
- 運転を評価する
- 自動車に乗せるデバイス(車載器)
- RasPiでSORACOM経由でデータ送信
- CANに繋いでおく
- GPSモジュールで位置情報も取得
- 取るデータ
- 車種、イグニッション、速度、エンジン、緯度経度、バンドル舵角などなど
- アーキテクチャ
- Kinesis StreamからLambda、Elasticsearchで可視化して管理者が見る
- LambdaからはS3に溜めたりSNS経由で通知
- 運転評価はS3のデータをEC2から取っている
- 可視化サービス
- 密度マップ
- 速度・回転数ヒートマップ
- 個人の特徴が視覚化されるので異常値が分かりやすい
- 速度と回転数が異常に上がると通知が飛ぶ
- ハンドルを攻撃者が乗っ取ると危ないところでハンドルを切られる
- CANの帯域監視でDoSを検知できる
- ユーザ毎のメッセージ数を見ると異常が多いユーザがわかる
- Unityを利用して一般ユーザにわかりやすい画面を作成
- 運転評価
- 自動運転のための教師データがほしい
- 減点方式で運転を評価する
- 急加速、急停止や急ハンドル等を検知して減点する
- まとめ
- 自動運転社会のためのプロトタイプを開発した
- 2つの可視化を提供
- 収集した運転データの評価
感想
自動車のセキュリティはいろいろ考えることがありますが、情報が少なくて心配になりますね。こういった研究が進んで欲しいですね。
各メーカーさんとかもっとセキュリティについてもアピールして欲しいですね！
LT#1:株式会社NTTドコモ 神崎 由紀さん「ドコモでのインシデント事例とセキュリティに対する取り組み」
- ドコモではAWSを結構使っている
- EC2は10,000台を越えている
- 運用しているといろんな問題がある
- コスト意識が低い
- 様々なインシデント
- コスト可視化ツールを使って最適化を行っている
- インシデントについて詳細に説明する
- SESで大量のバウンスメールが発生
- EC2に不正侵入
- EC2が起動しなくなる
- IAMアクセスキー漏洩
- バウンスメールはAWSからのメールで発覚
- 殆どが検証環境
- 怪しいメールを開くなとよく言うので、担当者が気づかないことがある
- 問題点
- バウンスについて認識がない
- SESのテスト用メールアドレスを知らない
- EC2が踏み台になっている
- AWSからのメールで発覚
- 問題
- SSHフルオープン
- すごい短い時間だが攻撃された
- SSHフルオープン
- セキュリティに対する取り組み
- ドキュメントを社内に展開
- ガイドライン、デザインパターンなど
- 社内クラウド勉強会をランチタイムに行っている
- 検証環境は結構インシデントが多い
- ドキュメントだけでは防げないのでアセスメントツールは役に立つ
感想
検証環境はやられやすいので、気を抜かずにしましょう！
LT#2:クックパッド株式会社 水谷 正慶さん「セキュリティログログ分析基盤の構築 on AWS」
- ログ分析といえばSIEM
- クラウドだと送信元が動的で制御できない
- 全体構成を気軽にいじれない
- 自分たちで構築しよう
- アーキテクチャ
- ログ収集
- Logs, GuardDuty, Trail
- 各インスタンスとかはfluentd
- ログ処理
- LambdaとStream
- Graylogで後から分析できるように
- さらにLambdaで変換、アラートのトリガーを引く
- LambdaとStream
- アラート
- GHEを情報集約の基点にする
- ES出だしたりAthenaに出す
- Lambdaで発火
- VirusTotalの情報も自動で追記
- ログ収集
感想
VirusTotal等も連携するのは面白いですね！
LT#3 T3 Realize合同会社 横堀 達也さん「アセスメント指摘事項への対応をサーバレスでチャチャッとやる話 オンプレ風味」
- 偉い人からログ取得とか全部やってくれと言われた
- SSMやLogs Agent、SSM Agentで良い感じになるのでは
- ログ管理の一般的なプロセス
- ログを集めるためにはなんのために取るか決める
- 実装した構成
- オンプレもEC2もサーバレスで統合管理/ ログ取得
- SSM Agentさえ入れればいい
- Windows10でもSSM Agentが動いてしまった(サポートはされていない)
- オンプレもEC2も同じように管理できていい！
- CloudWatch Logsでフィルタ検知からメール通知できる
- 今後は可視化や相関分析したい、クライアント管理したい
- LogsのPrivateLinkはよ！
感想
Logsも含めいろんなサービスのPrivateLink欲しいですね！
さいごに
いろんなセキュリティ対策の手法や現場の話を聞くことが出来ました。
いいサービスはどんどん使って試したり、なければ作ったりといろんなチャレンジがあって参考になりますね。
ぜひいいものはシェアして良い感じに運用できるようにしたいですね！
14
