Closed9

2025/02/17 Security-JAWS【第36回】 勉強会【イベントレポート】

issyissy

Contents

  • Session1: サイバーセキュリティ月間~安心・安全なサイバー空間に向けて
  • Session2: TAMとre:Capセキュリティ編 〜拡張脅威検出デモを添えて〜
  • Session3: Security Hub 運用のつらみ
  • Session4: ドメイン名の最強終活 〜観測環境を育てて、分析・供養している件〜
  • Session5: Security Hubの利用者調査とお悩み相談をやります!
  • Session6: [クラウドZoom相談] 当日のslido & connpassで受付けた質問に回答する枠
  • Session7: Security-JAWS 2024-2025の活動報告

※ 個人的なメモです。

issyissy

Session1: サイバーセキュリティ月間~安心・安全なサイバー空間に向けて

https://security-portal.nisc.go.jp/cybersecuritymonth/2025/

issyissy

Session2: TAMとre:Capセキュリティ編 〜拡張脅威検出デモを添えて〜

issyissy

Session3: Security Hub 運用のつらみ

  • 主な機能
    • セキュリティ基準に沿って、AWSリソースの設定状況を確認
    • 結果の統合
      • GuardDutyやInspector
      • CloudStrike Falcon、Prisma Cloud など
  • Security Hub →運用者→担当者→是正実施→運用者(是正確認)
    • 検知の確認
    • 担当者への連絡
    • 是正の確認
  • つらみ
    • 大量検知:【つらみ解決】
      • ステータスがNEWになっていると1日ごとに再通知
      • 構築中の検知
        • 構築→設定完了のタイムラグで検知
          • Security Hubインサイトで集約し、定期的に通知するように
    • 確認・連絡:【つらみ未解決】運用で対応!
      • 検知したアカウント・リソースから担当者を特定
        • タグがあれば簡単だが、なければCloudTrailなど・・
      • 検知内容と是正方法を連絡、是正されるまでリマインド
    • 認識齟齬
      • 運用チームと開発者で認識齟齬
        • 何を考えてその設定をしたのかを確認
  • 運用で大事にしていること
    • 自動化
    • 会話を重視
      • 知識レベルに差があるのでギャップを埋める
      • コミュニケーションが取りやすくなっていると心理的ストレスが減る
  • よいセキュリティ対応を!

issyissy

Session4: ドメイン名の最強終活 〜観測環境を育てて、分析・供養している件〜

  • 利用終了したドメインを手放すと・・・
    • ドロップキャッチ:ドメイン名が再登録可能になる瞬間を狙って目的のドメインを取得する行為
  • 観測分析
    • ドメイン名を保有し続けるのはコストがかかる
    • 安全に手放せるのであれば手放したほうがBetter
    • 参考資料:ドメイン名の終活について - JPAAWG 7th|Speaker Deck
    • (必須)DNSクエリログ→CloudWatch Logs→S3→Lambdaトリガーで整形→S3
    • (あったほうがいい)Webアクセスログ、メール収集
    • ケース
      • 残存する監視通信:廃止したドメインを悪用された場合に悪性ファイルや不正スクリプトが実行される可能性
      • 残存リンク:フィッシングなどに利用される。ある程度修正しても長期に観測したほうがよいケースもある。
      • コーポレートドメインのメール(機密情報を含むメールを受信など):簡単には手放せない
  • ステータスコード410 Goneを利用すれば自動化できる?
    • 元のサーバーで利用できなくなっている対象リソースにアクセスしていることを示す
    • CloudFrontは410非対応
  • 詳細はこちらを参照

issyissy

Session5: Security Hubの利用者調査とお悩み相談をやります!

issyissy

Session6: [クラウドZoom相談] 当日のslido & connpassで受付けた質問に回答する枠

  • 初心者におすすめなこれから始めようAWSのセキュリティ
  • AWS基幹システムへの攻撃はどのように防いでいますか?技術的なこと、人的なこと(内部不正防止含めて)
    • VPCにInternet Gatewayをアタッチしない
      • 外部公開されていないからGuardDutyは不要かどうか聞かれたら?
        • GuardDutyはAWSアカウントに対して包括的に検出できる
        • 外部アクセスだけがリスクではない。
        • DirectConnect経由や、作業中にウィルスに感染させてしまったといったリスクもある
        • GuardDutyほど簡単に設定できるものはないので、入れないという選択肢はないと考えている
    • Amazon VPC Block Public Access
    • エンドポイントの利用情報をどうやって可視化、一覧化している?
    • CNAPP:Cloud Native Application Protection Platform/クラウド ネイティブ アプリケーション保護プラットフォーム
    • AI-SPM/AI セキュリティ態勢管理
    • AWS Verified Access
    • 組織全体でのセキュリティレベルが定義があるはず、それに則っている
      • AWSレイヤーで担保する部分、システムで担保する部分いくつかある
      • アクセスできる人だけアクセスする設計を行うのが重要
    • 人的なこと(内部不正防止含めて)
      • 役割から外れた人への権限をはく奪、権限の見直しを継続的にやることで内部不正防止にもなる
    • セキュリティは「AWSだから」ということではない
  • 他社にて社内にクラウドセキュリティの専門チームを設けているか知りたい
    • 「クラウドセキュリティの専門チーム」はあまり聞かない。
    • CCoEの中で対応や、オンプレと合わせてというのはあるかもしれない
  • 好きなセキュリティサービスは?
    • ELB
    • xx Analyzer
    • Security Hub
    • WAF
    • GuardDuty
    • Detective
このスクラップは2025/02/27にクローズされました