Security-JAWS 第36回レポート #secjaws #secjaws36 #jawsug #サイバーセキュリティは全員参加

こんにちは、臼田です。

Security JAWS 第36回が開催されましたのでレポート致します。

Security-JAWS【第36回】 勉強会 2025年2月17日(月) - connpass

ちなみに今回はNISCさんのサイバーセキュリティ月間とコラボです！ハッシュタグに#サイバーセキュリティは全員参加もつけてください！

動画

後ほど

レポート

Session1: サイバーセキュリティ月間～安心・安全なサイバー空間に向けて 内閣サイバーセキュリティセンター（NISC）総括戦略ユニット戦略企画班 長谷川智美さん

• セキュリT!!!!!!!
• サイバーセキュリティ月間とは？
  • サイバーセキュリティ基本法で定められている普及啓発の取り組み
  • 毎年2/1から3/18(サイバーの日)まで開催している
• サイバーセキュリティ月間の特設サイトでは関連するイベントも確認できる
• 今年のテーマ「家庭や職場で話し合い、見直したいセキュリティ対策」
  • 主な啓発ターゲットは「ファミリー層」と「中小企業」
  • 今年は「チョコレートプラネット」さんを起用
  • セキュリTT兄弟
  • YouTubeで動画を公開したり、キックオフイベントなども実施している
  • サイバーセキュリティパンフレットもある
  • 特設サイトにあり、印刷や配布も可能
• 近時のサイバーリスク: 個人編
  • フィッシング
    • 今年も高い件数発生している
  • サポート詐欺
• 近時のサイバーリスク: 企業
  • ランサムウェア
    • 被害の半数以上が中小企業
• IPAから「情報セキュリティ10大脅威 2025」も発表された
  • 地政学的リスクに起因するサイバー攻撃が初めてランクイン
• 最近のサイバー事案
  • トレイダートレイダーの件について警察庁、NISCからも注意喚起が出ている
• 中小企業では特にどこから対策していけばいいかわからず対策が大変だったりする
  • 中小企業向けサイバーセキュリティセミナーが3/10にある
• まだまだこの取り組みの知名度は高くない
  • 公式ハッシュタグも活用してみんなで発信して欲しい
  • #サイバーセキュリティは全員参加

感想

サイバーセキュリティは常に課題なので、ぜひこの機会に身近な方含めて話しましょう！#サイバーセキュリティは全員参加をお忘れなく！

Session2: TAMとre:Capセキュリティ編 〜拡張脅威検出デモを添えて〜 アマゾンウェブサービスジャパン合同会社 技術支援本部 藤井 秀行さん

• 何が起こったかよくわからなかったぜ…(詳しくは動画で
• Amazon GuardDutyの拡張脅威検出について紹介
• re:Inventで発表されたセキュリティサービスも紹介
• AWS Security Incident Response
  • お客様のインシデントレスポンスを支援する新しいサービス
  • Amazon GuardDuty/AWS Security Hubと連携して検出事項についてサービス側でトリアージする
  • 自動で優先順位付けして即時対応が必要なインシデントを特定する
  • サービスからユーザーに通知することもある
  • インシデントを一元管理してお客様とAWSが一元となって対応するプラットフォームの役割もある
  • AWS Customer Incident Response Team(CIRT)がお手伝いしてくれる
  • お任せのサービスではない
  • 現状英語のみ
• AWS Organizations関連
  • ルートユーザーアクセスの中央管理
    • AWS Organizationsの管理者はメンバーアカウントのルートユーザー認証情報をそもそも削除することでMFAやパスワードの管理が不要になる
    • メンバーアカウントのルートユーザーMFA必須可は2025/03/24から開始されるので代替としてこの機能を利用するといい
    • ロックされたS3の復旧などは別機能がある
  • リソースコントロールポリシー(RCPs)
    • 組織内のリソースに対する権限のガードレール
    • 組織外からのアクセス禁止を一律でできる
    • これまであったSCPsは組織内のプリンシパルに対する制御ができる
    • RCPsはリソースに対して制限をかけられる
    • SCPsとRCPsはお互い補完する立場
  • 宣言型ポリシー
    • VPCのパブリックアクセスを禁止する、といったポリシーをアタッチできる
    • 決められたポリシーが用意されており、すぐに適用できる
    • 禁止時にはカスタマイズ可能なメッセージを設定できる
    • 2025年2月時点ではEC2/EBS/VPCについてのポリシーのみサポート
    • VPC Block Public Accessの強制や利用するAMIの強制など
  • 各ポリシーの比較
    • 大きな違いはリソースコントロールポリシーはリソースに付与する
    • 宣言型ポリシーはAPIに依存せず強制できる
• Amazon GuardDutyで拡張脅威検出機能が発表された
  • 高度な多段階の攻撃を検出できる
  • これまでは1つ1つの単発の脅威を検出するだけだった
  • 今回のアップデートで一連の攻撃を「攻撃シーケンス」としてまとめて表示できる
  • おさらい
    • Amazon GuardDutyはワンクリックで有効化できて自動で各種ログを収集分析して脅威を検出できる
  • デモ
    • 一覧から脅威タイプで拡張脅威検出の結果だけ表示できる
    • IAMユーザーのクレデンシャル漏洩の可能性がある検出
    • AttackSequenceの新しいFinding Types
    • 関連している検出をシグナルとして並べてくれる
    • MITERに当てはめた表示もある
    • シグナルが時系列になっていて何が起きているか確認できる
  • 参考: インシデント調査はAmazon Detectiveが本職では？
    • そのとおりです
    • Amazon GuardDutyは初動の対応
    • Amazon Detectiveで深堀り調査

感想

今回も素晴らしいアップデートがたくさんありました。拡張脅威検出はちょーべんりなので皆さん使っていきましょう！

Session3: Security Hub 運用のつらみ 木村情報技術株式会社 SRE部 中原加寸美さん

• Security Hub
  • 機能は主に2つ
    • セキュリティ基準のチェック
    • 結果の統合
• 現在の運用状況
  • ある程度運用が回っている
  • 検知したら運用者が受け取って、担当者に通知して是正してもらう
  • 自チームの役割
    • セキュリティ通知の運用
    • AWSセキュリティガバナンスの管理
    • 社内のセキュリティ推進
    • セキュリティインシデント対応
• つらみ
  • 3つに分けて話す
  • 大量検知のつらみ
    • ステータスがNEWになっていると1日ごとに再通知される
    • 自動化して解決した
    • StepFunctionsワークフローでステータス変更自動化
    • Power Automate for desktopによるメール取り込みを使ったリスト化
    • 構築中のリソースの検知
    • 構築から設定完了までのタイムラグで検知される
    • Security Hubのインサイトで結果を集約して定期的に通知を行うように設定した
  • 確認連絡のつらみ
    • 確認
      • 検知したアカウント、リソースから担当者を確認する
        • タグが付いていないとCloudTrailやConfigから操作者を確認している
      • 手順書などから対象の是正方法を確認する
      • 一定期間以上是正されていないリソースがないかを確認する
    • 連絡
      • 検知内容と是正方法を連絡
      • リスクも伝える
      • 完了連絡をもらって検知がなくなることを確認
  • 認識齟齬のつらみ
    • 運用チームと開発者で認識の齟齬がある
    • 例
      • 開発者に是正を依頼して完了連絡を受けたが再度検知した
      • Security Hubが想定する是正方法ではなかった
    • 何を考えてその設定をしたのか話さないとわからない場合がある
• 運用で大事にしていること
  • 自動化できるところは自動化
    • 人力には限界がある
    • 費用・時間ともに機会がやったほうが効率がいい、ミスがない
  • 会話しながら運用を回す
    • 相手もわかっているだろう…になっていませんか？
    • 会話が大事な理由
      • 是正に入ってもらいやすい
        • リスクを説明すると必要な作業と認識してもらう
        • こちらから発信すると相談を受けやすくなる
        • 納得感を持って作業にあたってもらえる
      • 知識分野に差があることが認識できる
        • Security Hubの検出内容はインフラ寄りなのでインフラ側の知識が必要
        • フォローにも入りやすい
      • 心理的なストレスが減る
        • 相手とコミュニケーションを取りやすくすることで心理的ストレスを減らすことができる
        • 話しかけづらい人にならないように話しかけたい
• まとめ
  • 自動化と会話だいじ
  • よいセキュリティ対応を！

感想

セキュリティの運用にコミュニケーションは大事ですね！あとは文化や雰囲気も。がんばりまっしょい！

Session4: ドメイン名の最強終活　〜観測環境を育てて、分析・供養している件〜 NTTコミュニケーションズ株式会社 イノベーションセンター 平木康介さん

• なぜ利用終了したドメイン名を観測分析するのか？
  • 利用終了したドメイン名の終活のため
  • 使い終わったドメイン名を無邪気に手放すとドロップキャッチされるリスクがある
    • 手放したドメインが悪用される可能性がある
    • ドコモ口座でも事例があった
    • NTT Comでは2023年12月より利用終了した独自ドメイン名を永年保有している
  • 一方で実際にどのようにアクセスを受けているかわからなかった
  • これを分析してみる
  • 観測して適切に手放せるならそうしたほうがいいかも
  • ドメイン名の終活についても参考に

https://speakerdeck.com/mikit/domeinming-nozhong-huo-nituite-jpaawg-7th

• 観測環境
  • 要件
    • DNSクエリログ、Webアクセスログ、メールの収集
  • 設計方針
    • AWSで観測し、NTT Comの全社データ基盤で分析保管を行う
    • マネージドサービス、サーバレスを活用してセキュアな環境とする
  • Amazon Route 53, CloudFront, SESで各種ログを取得
    • JSON化してS3に保存してデータ基盤と連携
  • 構成の詳細
    • エンジニアブログに詳細がある
• 分析結果
  • 定期的なIPアクセス
    • 忘れ去られた定期通信のリスク
      • 企業のシステムが特定のドメインにアクセスしていたとする
      • 第三者にドロップキャッチされたあと定期的な通信から不正スクリプト実行につながる可能性も
    • 実際にそうした通信を検出した
      • 逆引きすると自社サービスが想起される文字列を発見
      • アクセスしているパスを見ると監視の通信だと予測
      • 無事見つけて供養できた
        　- 教訓
        　 - 不要な通信は担当者とコンタクトが取れるうちに消す
• 気づかない残存リンクの危険性
  • 信用を失ったりシステム侵害のリスクがある
  • リンクが残っている場合にそこを踏む一般ユーザーや社員がいたら、フィッシングサイトなどに誘導される可能性がある
  • 実際に見つけた通信
    • WikipediaのRefererではパスがわからない
    • Google Dorksで残存リンクを発見
    • 無事供養
  • 教訓
    • Webページとして使っていたドメインは残存リンクがあって然るべき
    • Wikipediaであれば編集機能で削除する
    • そうでなければサイト管理者に連絡をして削除してもらう
    • しばらく観測したほうがいい
• コーポレートドメインのメール分析(経過報告)
  • 情報漏洩のリスク
    • 会社の信用を失う、経済的損失のリスクがある
    • 犯罪者は機微情報を喉から手が出るほど欲している
  • 分析
    • 利用終了して3年以上経過しても機密情報を含むメールを受信していて簡単に手放せない
    • 広告が多いが、脅威情報や故障連絡などもある
    • 製品のアラートや脆弱性管理システム、更にはお客様の情報を含むものもある
• コスト
  • AWS利用料金は月2万円未満
  • Route 53が50%を占めている
  • DNS Zoneがほとんど
  • CloudFrontはコンテンツを置かないことでコストを抑えている
• まとめと今後
  • 終活を促進したい
  • 供養を自動化できないか？
  • ステータスコード410 Goneを使ってみたい
    • サーバー所有者がそのリンクへのリモートリンクを削除することを望んでいるステータス

感想

永代供養は大事ですね。ドメインを取る時からこのことを考えたいですね。

Session5: Security Hubの利用者調査とお悩み相談をやります！ Security-JAWS運営メンバー

あとで資料を公開します！

Security Hubのアンケートに是非ご協力をお願いします！

https://bit.ly/sjaws-securityhub-survey-2025

Session6: [クラウドZoom相談] 当日のslido & connpassで受付けた質問に回答する枠 Security-JAWS運営メンバー

初心者におすすめなこれから始めようAWSのセキュリティ

これを読んで

https://business.ntt-east.co.jp/content/cloudsolution/ihcm_column-04.html

AWS基幹システムへの攻撃はどのように防いでいますか？技術的なこと、人的なこと、両方お聞きしたいです

• 基幹ということは外部に公開されていない？
  • もし公開されているなら、公開しないようにするところから
• ASMのように公開しているエンドポイントを管理しているか？
  • CNAPP周りのソリューションでも最近できたりするが、あまり現実的に利用できる気はしない
• 生成AIも利用していたりするとより大変
  • Bedrock Guardrailsだけでも足りない
  • 生成AIだと主語が大きい
  • それぞれアプローチは違う
• 例えばS3のエンドポイントを使う上で一覧化するとかはあり
• 機密性の管理をきちんとやっていく
• AWS Verified Accessを使う場合も最小限のアクセスを意識
• 長期間利用するなら、担当者が変わったら権限を剥奪するなどをちゃんとやる
• 重要なアクションは1人でできないように職務分掌をする

他社にて社内にクラウドセキュリティの専門チームを設けているかが知りたい

• 知らないかも

月並みな質問ですが好きなセキュリティサービスをご教示ください

• 詳しくは動画で！

Session7: Security-JAWS 2024-2025の活動報告 Security-JAWS運営メンバー

• Doorkeeperからconnpassにプラットフォームを移行したよ
  • みんなメンバー登録してね
• 2024/01
  • AWS Builders Flashに寄稿しました
• 2024/02
  • サイバーセキュリティ月間中にSecurity-JAWS開催
  • AWSセキュリティのベストプラクティスに関する利用実態調査のレポートの韓国版公開
• 2024/03
  • BSides Tokyo 2024でレポートの結果を共有
  • mini Security-JAWS開始
• 2024/04
  • NW JAWSとコラボ
• 2024/05
  • 通常回開催
• 2024/06
  • AWS re:Inforce 2024にて登壇
  • JAWS-UG Chibaと共同でre:Cap開催
  • AWS Summit 2024でコミュニティステージでの登壇
• 2024/07
  • AWS re:Inforce 2024 re:Cap登壇
• 2024/08
  • 通常回開催
• 2024/09
  • とある海豹とコラボワークショップ
• 2024/11
  • 通常回開催
• 2024/12
  • SecHack365出展
• 2025/02
  • 通常回開催
  • 脅威モデリングワークショップ実施

まとめ

今回もたくさんの内容がありましたね。Security Hubのアンケートについてはぜひ皆さんご協力お願いします！