[レポート]Security-JAWS【第23回】 [AWS Security Roadshow Japan 2021] 特別拡大版 #jawsug #secjaws23 #secjaws #awscloud #AWSSecurityRoadshow

Security JAWS 第23回のレポートです。パネルディスカッション、AWS脅威の理解、閉域網でのS3アクセス制限、セキュリティガードレール立ち上げ、社内セキュリティ立ち上げ相談会などの話がありました！

#JAWS-UG

#セキュリティ

#AWS

#イベント

あしざわ

2021.11.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、東京オフィスの芦沢です。

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

Security-JAWS【第23回】 [AWS Security Roadshow Japan 2021] 特別拡大版

動画

レポート

Session1：パネルディスカッションアマゾンウェブサービスジャパン株式会社桐山隼人さんシンプレクス株式会社岸野秀昭さん株式会社ソニー・ミュージックエンタテインメント田代雄亮さん　Japan Digital Design 株式会社唐沢勇輔さん

議題1：重要データの保護について、皆様の企業にとってどんなデータ？どうやって保護してる？
- 田代さん
  - 重要データ=個人情報
  - 最低限のセキュリティはガードレールで保証
  - 海外展開ではGDPRを重視など、場合によってセキュリティのレベルを変えたりする
- 唐沢さん
  - 重要データ=法人顧客の決済データ
    - 例）オンラインレンディングによる信用スコア(2000万件ある)
  - 公開しなくてもいいデータなのでネットワークを絞り、権限分離、監視を定石通り実施
  - 分析することが目的なので、分析者の権限はある程度自由に
  - 一方でデータは簡単に外へ持っていけないようにガバナンスを設定
- 岸野さん
  - 重要データ=顧客システム内の個人情報
  - 例）口座情報など
  - どうやって守る？
  - 構築のIaC化による品質担保
  - テストコードの半自動化による品質担保
  - 端末からのデータの閲覧やデータ持ち出しには承認が必要で、簡単にデータへたどり着けないようになっている
議題2：登壇で言い残したこと
- 唐沢さん
  - そもそもクラウドで何をやりたいんだっけ？を考えてからセキュリティ要件を考えよう、ということ
    - 早めな相談はよくあるが、相談者の方の目的、ビジネス要件がクリアになっていないことが多い
  - グループ会社との取引が多いので、相談前に煮詰まっていないことが多い。
    - 二人三脚で進める意識はあるが、それにしても、、、ということが多い
- 岸野さん
  - 本編ではCCoEの話をしたが、本来は技術的な話に触れたかった
  - プロジェクトに入りこもうとする前の話をここでする
  - きっかけ
    - 外部からだとセキュリティ品質の担保をどこまでやるのか、の判断が難しい
    - だからプロジェクトに入り込んでみた
  - 以前は
    - セキュリティチーム単体で決めることは難しかった
    - 性能重視、機能制約なしで暗号化をどこまでやるかなど
  - やってみてどうか
    - プロジェクトに入り込んだことで、プロジェクトの実態に即したセキュリティ対策をすることができるようになった
    - プロジェクト内でのセキュリティな困りごとや知見をセキュリティチームへ持ち帰ることができるようになった。
- 田代さん
  - プロジェクトの立ち上がりの件数が多い（年間100件以上）のでセキュリティのレビューをやっている
    - 中に入ってやる、というところまではできていない
  - セキュリティと事業はプロジェクト毎に要件がバラバラ
    - バランスを見極めてやっている
  - 唐沢さんの「結局何やりたいんだっけ？」な話は田代さんも思うところがある。
  - 人材不足の問題をよく感じる
    - ソニーミュージック様では、セキュリティチームはもともとビジネス部門から始まったもの
    - セキュリティチームとして、ビジネスとセキュリティの橋渡し的な役割をしている
  - セキュリティチームの人材は不足しています！（再）
    - ビジネスもセキュリティも両方わかっている人が担当にならないといけない
議題3：セキュリティ人材の話
- 岸野さん
  - 今まではアプリよりもインフラレイヤーをやってきた
  - アプリレイヤーのセキュリティの知見があまりないので、アプリケーションチームの人たちに来てほしい
  - けどなかなか難しい
  - 定例会をやるなどして知見を増やしている
  - 少ない時間で知見を最大限引き出す
- 唐沢さん
  - セキュリティチームは3人くらい
  - プロジェクト数が多いわけではないので、なんとか回っている
  - だが、アーキテクチャまで考えられる人が不足している
  - アーキテクチャレビューしていると自分で設計したくなることが多い
  - エンジニアサイドでそこまで考えられる人が欲しい
  - 絶賛採用中です！
- 田代さん
  - ガードレール周りのチームは4人体制（全員兼務）
  - 基本的に自動化・効率化しているので、アカウントが増えても人を増やさなくて済んでいる
  - どんなところを自動化？
    - SecurityHubの設定など
    - コンテナを使っていたので短時間で対応できた
    - このあたりはDay2のセッションで話すそう
議題4：セキュリティ自動化の話
- 唐沢さん
  - 自動検知はやっているが、自動修復はやっていない
  - アカウント払い出しをCFnにしたり、それに監視設定を追加したり
  - root権限の検知などは環境払い出し時の段階で検知できるようにしている
- 岸野さん
  - 自動修復はやっていないが、SecurityHub、Config Ruleのような自動検知はやっている
  - 検知したらその場で直してもらう、という運用フローが整備されている
- 田代さん
  - 自動修復までやっている
  - SSHルールの不正等あれば自動で修復して再設定できない、までやっている
  - 自動修復をやっても問題にはなっていない
    - 事前に何度も周知しているから
    - AWSJとの定例で全アカウントオーナーに周知している
    - AWSJ立ち会いの場でで周知することで、オフィシャル感があり説得力を増しているかも？
Sli.doからの質問：社内政治的な邪魔でセキュリティ施策が実施できない時はどうする？
- 唐沢さん
  - 政治的要因でできないなら、政治的に戦う
  - 社長など上の人の力や、外部の力を使う
  - まずはその人と話すとこから
- 田代さん
  - 事故が起きた後は、話が通りやすい
  - 他社の事故でもOK
  - 事故の後はセキュリティ対策でやりたいことをまとめて提案する
- 岸野さん
  - 他社の事故や事例などを社内で共有する
  - セキュリティレベルを可視化する
- 桐山さん
  - 登壇した実績によって社内への雰囲気作りに役立てているという話もあるよ
最後に伝えたいこと
- 岸野さん
  - セキュリティについて考えた結果クラウド使おう、になることもあるよ
- 田代さん
  - 日本はセキュリティ後進国だと思われているかもだが、セキュリティ活用実績はたくさんあるぞ
- 唐沢さん
  - セキュリティ担当は孤立しがちでビジネス・IT部門と対立しがちだが同じ想いを共有できてよかった
  - クラウドはセキュリティがやりやすいということを実感

感想

セキュリティ自動化のお話がとくに印象的でした。

自動検知まではいけるが、自動修復まで実装するにはなかなかハードルは高く、社内政治をうまくやる必要があるようです。

そして、セキュリティ人材ってどこも足りてないよねって話も聞けました。

Session２：AWSを攻撃したらこうなるのでちゃんと対策しようねって話　クラスメソッド株式会社 AWS事業本部コンサルティング部シニアソリューションアーキテクト臼田佳祐さん

登壇ブログはこちら

今日のテーマ
- 脅威を理解して適切に対策してもらう
AWSの環境を攻撃されたらどうなるの？
- 色んなものへサヨナラすることになる
  - 情報
  - 資金
  - 会社の信用
攻撃の一例（ブログ）
- AWSの一般的な3層構造のアーキテクチャ
- 攻撃者がアプリケーションの脆弱性(SSRF)をついてIAMRoleの認証情報を取得
- IAMRoleがうっかりS3を見ることができる権限があった
- S3にもうっかりIAM Userの権限情報があった
- などなど
- 最終的に、、、
  - BackDoor用のユーザーの作成
  - コインマイニング用のEC2インスタンスを立てる
  - EC2に侵入してRDSの機密情報を窃取
- こんなことが十分発生しうる
- 根本の攻撃自体はアプリケーションの脆弱性だが、AWS構成自体がベストプラクティスに沿っていないかったため、最悪の結果になってしまった
  - 一つ一つは脅威ではないが、組み合わさると脅威になる
AWSセキュリティ対策にはAWSの脅威を知る必要がある
- AWSの脅威
  - 誤った情報の公開、アクセス許可
    - 試しによくわからず使い始める、ということをしがち
    - ローカルの環境とは違って、AWSは最初から外部に公開されている環境
    - 試し使いでも理解して使い始める必要がある
  - 資金の浪費
    - 従量課金で安く使い始められるが、適切な管理がないと莫大な請求に
実際のインシデントの事例
- アクセスキー漏洩の話（ブログ）
- GitHubに乗ってから10分で漏洩
個別のセキュリティ対策
- 全内容はブログにまとられています
- IAM
  - 仕組みとして漏洩を防止
  - git-secrets（ブログ）
  - PermissinBoundary
- SecurityHub
  - セキュリティチェックが可能
  - 達成度がわかりやすい
  - ルール・リソース単位のステータス管理
  - 自動修復（要検証！）
  - 使い方のブログ
  - ログのリージョン集約も可能になった（ブログ）
- GuardDuty
  - 脅威検知
    - AWSドキュメントに検知時の対応はわかりやすく書いています
  - 初動対応例
    - IAMのクレデンシャル無効化
    - Security Groupのルール変更でEC2の隔離
    - S3パブリックアクセスの無効化
  - 運用についてのブログ
- Amazon Detective
  - 脅威検知時の調査フェーズをまるっと対応できる
  - 内部のグラフDBで関連付けしてくれる
  - 関連イベントを辿ったり。関連APIを集計&検索できたりする
  - ガッツリしたデモのブログ
- おまけ：WAF
  - CAPTCHA認証ができるようになった
まとめ
- 脅威を理解し適切に対応する
- 防御だけでは足りない
- 検知してからの対応も準備しておく
Sli.doからの質問
- 質問：本番・開発でのセキュリティ設定の違いはどう考えるべき？
  - 開発環境では緩めの権限を渡す
    - 最低限できないことはブロックしておく
  - 本番環境の時には最低限の権限
- 質問：S3のセキュリティを学ぶには？
  - AWS公式のセキュリティベストプラクティスというユーザーガイドが充実している
- 質問：自社のセキュリティの脅威を分析するには？
  - 本来は、ストライドなど脅威分析のモデルを使う
  - AWSだと加えてSecurityHubを使ったAWS観点でのアプローチができる

感想

AWSが攻撃されたらこうなるぞの説明や脅威からAWS環境を守る方法などを個別のサービスごとに説明していたり、セキュリティ初心者の私にもでもかなりわかりやすいセッションでした。

関連ブログもたくさんありますが、どれも非常によくまとまっているので、まずひととおり読むことからがスタートラインでしょうか。

最近AWS認定のSCSを取得したのですが、ここで挙げられているサービスやブログを網羅しておくと試験勉強にもかなり役立つなーとか思ったりもしました。

Session３：閉域要件におけるS3周辺ポリシーの組み合わせ方みずほリサーチ&テクノロジーズ株式会社松尾優成さん

話すこと
- 閉域用件でS3のデータ流出の防止をどう防ぐか（予防的統制観点）
- ポリシーを組み合わせてどのようにS3のデータ流出を防ぐか
話さないこと
- データ流出時の発見的統制観点
- S3 ACLやKMSの詳細設定
- S3以外のデータ流出対策
- オンプレのデータ流出対策
構成概要
- オンプレからS3に格納した情報をEC2で分析して還元する
- ユーザごとにS3バケットがあり、ユーザが増えるとS3も増える
- 閉域網でもデータは流出する、という話
- 着目するポリシー
  - IAMポリシー
  - VPCエンドポイントポリシー
  - バケットポリシー
データを保有するコンポーネント毎に流出対策を考えてみる
- 閉域用端末
- EC2
- S3
VPCエンドポイントを利用するアクセス者側で考える
- VPCe利用者（閉域用端末、EC2）のアクセス権限
  - ここからIAMポリシーについての細かい話
  - IAMポリシーのAction句は最小権限
  - Resource句にはワイルドカードを使ってる
  - なぜワイルドカードを使うのか？
    - IAMロール修正時にミスがあるとめんどくさい
    - でもIAMポリシーにワイルドカードがあると不正経路につながる
  - ワイルドカードを使いつつ、アクセス先のS3を自社アカウントに制限したい
  - こんなアップデートが
    - IAM条件キーのs3:ResourceAccountを使って特定のAWSアカウントが所有するバケットに制限できる
    - 漏洩のリスクが減る！
  - でも、社内クレデンシャルを持ち込まれると？
    - 流出してしまう
    - しかもS3データイベントがCloudTrailに記録されない（かも）
  - クレデンシャル持ち込みパターンでも漏洩を防ぐには
    - s3:ResourceAccountをVPCエンドポイントポリシーで使用すればOK
    - Deny以外にAllowも設定が必要
- S3バケット：正常経路の洗い出し
  - 不正経路はいろいろあるので正常経路を洗い出したい
  - ざっくりと3パターン
    - アカウント内の他のサービス
    - パブリックアクセス
    - 他アカウント
  - バケットポリシーだけで制御する場合
    - スイッチロール時にPrincipalだとワイルドカードが使えないので、aws:useridを使用して制御（参考ブログ）
    - バケット自体のARNをResource句に指定すると設定ミスの時にrootユーザ以外でバケットを触れなくなるので注意
  - バケットポリシーだけだと煩雑なのでアクセスポイントを使うといいよ
    - 各アクセスポイントで設定、特定経路以外をDeny
    - 紹介したんだけど、実は、使いたかったけど使えなかった
      - 以前はアクセスポイント利用がARN形式のみをサポート
      - アプリケーションやミドルウェアにより使えない場合があった
      - 現在はアップデートにアクセスポイントエイリアスを使えるようになった
  - 結論、S3もバケットポリシーで特定経路以外をDenyすればOK
- ポリシー関連まとめ
  - IAMポリシー
    - s3:ResourceAccountで社外バケットへのアクセスをDeny
  - VPCeポリシー
    - aws:PrincipalAccountでクレデンシャルの持ち込みをDeny
  - バケットポリシー
    - aws:sourceVpceなどで特定経路以外をDeny
余談：発見的統制も相当な体力、な話
- CSPMの製品を導入
  - 多数のルールから適用対象、カスタマイズ対象を選定
- SecurityHubのCISベンチマークを遵守
  - ConfigやCloudWatchで通知をぽちぽち実装
全体まとめ
- NW的に閉域網でもデータ流出のリスクはある
- S3周りで気をつけたい点
  - 社外バケットへのアクセスは防げるか
  - クレデンシャルの持ち込みを対策できるか
  - 機微情報を扱うバケットはアクセス経路を限定しているか
- 課題：境界防御からの脱却を夢見る
Sli.doからの質問
- 質問：バケットポリシーの記載ミスでも5営業日かかる？
  - 緊急で即時でやってもらえる
- 質問：SecirutyHub+CSPMでコストに見合った成果はある？
  - 最初はCSPMを使って独自でやってたけど、後から社内ルールでSecurityHubを追加
  - 見合ったものがあるか、というと微妙

感想

閉域網における流出経路の流出パターンをしっかり想定できていて、すごいなと思った。

紹介されていた実際の設定事例も知見の塊。

Session４：DMMでAWSセキュリティガードレールを作ったので、開発者がAWSセキュリティをチェックする文化を広げていきたい合同会社DMM.com 西山渉さん

話すこと
- DMMでAWSecurityガードレールを構築
- AWSSecurityガードレールを支える技術
- 開発者がセキュリティをチェックする文化
第1話：DMMでAWSecurityガードレールを構築
- AWSセキュリティガードレールとは？
  - セキュリティ品質担保のための検知の話=発見的統制
- DMMについて
  - 67チーム、AWSアカウント300以上
- 要件
  - AWSへのセキュリティ脅威の検知
  - 開発者にセキュリティチェックしてもらう
- はじめに承認とるときの話
  - AWSセキュリティ設定やりたいです、すぐやっていいですか
  - だめです、各チームから承認とって各チームにやってもらってください
- DMMの目指す開発像として開発者にセキュリティチェックしてもらうがあった
- 技術選定
  - LandingZone
    - 組織マスター
    - セキュリティ
    - ログアーカイブ
- 監視体制
  - チームごとにSlackチャンネルを作って、アラートを飛ばす
  - セキュリティチームは全チャンネルに参加
- 利用サービス
  - Config Rules、Cloud Trailなどたくさん
- Config Rulesについて
  - なんでSecurityHubを使わないの？
  - 難しいアラートを除いて最低限のものだけを選定したから
- アラート管理のための技術選定（AWS外）
  - 方針
    - 開発者にセキュリティをやってもらう
  - 使うツール
    - Slack（コミュニケーションツール）
    - Jira（チケット管理ツール）
    - SlackbotでSlackとJiraを連携
- DMMのチームをめぐり承認をもらう旅
  - 開発者にやってもらうための「お金」、「承認」をもらう旅
  - 各チームをどさ回り
  - 結果
    - 80チームから承認
    - 300アカウントのセキュリティ設定完了
    - 50アカウントの削除
      - やって一番よかった結果かも
    - アラート状況
      - 4500箇所をチェックし、3200個の最終チェックが完了
    - やばい設定不備
      - DBパブリック公開：20件
      - S3書き込み権限のパブリック公開：6件
    - 実際起きてた事故（SecurityHubで発見）
      - 3件！！
  - ここまでの道のりをまとめたスライドはこちら
第2話：ガードレールを支える技術
- 管理者の運用の話
- Orginizations OU
  - 80あるのでどのアカウントに入れるのかわからない
  - OU名にSlackチャンネルIDを入れて対処している（未解決）
  - SlackIDやOU名で検索できないので不便
- サービスマネージド型CloudFormationStackSets
  - 管理者権限でメンバーアカウントへ設定するためのCFnStackSet
  - 自動デプロイが便利なので寄せたい
  - でも寄せきれていない
  - グローバルリソースとリージョナルリソースに依存関係
    - Chatbot（グローバル）
    - Event Bridge（リージョン）
    - SNS（リージョン）
  - 解決してない！
- アカウント毎の例外設定
  - 例外覚えてられない
  - 解決策=すべてCI/CDに寄せてコード化
  - 組織変更が多すぎてその度にアカウントを移動させている
- CI/CD
  - OUが80あるのでテンプレート更新のたびに80回StackSetを実行している
  - 手動アップデートが辛い
  - 解決してない！
第3話：開発者がセキュリティチェックする文化
- ガードレールの要件
  - 開発者にやってほしい
- 結果=みなさん結構やってくれてる！
  - チケット状況を見てもなかなか健闘
- やってくれているからこそ議論が発生する箇所
  - Webサービスだし、80,443portの解放は当たり前だろ！
  - サービスリリースしてからやろうよ！
  - 議論を生むこの状況は大歓迎
- LandingZone構築のその先
  - 構築まではどこも同じ
  - その先が各社異なる
    - DMMでは開発者にやってもらう
  - 1年PJやって、作ったのはLanding Zoneではなく、開発者がセキュリティチェックする文化だったと気づいた
まとめ
- ガードレールを敷けた
  - 設定不備・セキュリティ侵害を発見できた
- 開発者が自発的にチェック
  - AWSレイヤーのセキュリティ自給率が高まった
質問：承認されたアカウント数は80だったが承認されなかったチームはあるのか
- あります。
- 自分たちでやります！というチーム、別の理由でできなかったチーム

感想

ガードレールを構築する過程で全チームを渡り歩くどさ回りをされていて、セキュリティを始めるということの大変さを追体験できました。

結果、不要なアカウント削除ができたり、まじでやばい設定不備やセキュリティ事故を検知&改善できていて、よかったな、と。

そして、開発者が自分でセキュリティをチェックする文化is素晴らしい

Session５：助けてください、セキュリティどうすればいいですか株式会社ゲオホールディングス竹内誠さん

ゲオの情シスどんなところ？
- 社内で使うシステムの開発運用保守
  - レンタル汎用システムは元々なかったので、内製でつくる文化がある
- コンシューマ向けは別部署
セキュリティお願いします
- 今年に入って、セキュリティ大丈夫？と偉い人から。
- 大丈夫じゃないです！（正直）
- 強化お願いします。
取り組み状況
- 基本は境界防御とエンドポイント、海外はSASE
- AWS、Azuleを使っているのでCSPMで見える化
- やったこと
  - ひたすらググる
    - 何を守るか、CSIRTなどを知識をつけた
  - ベンダーに相談
    - いろいろ提案されるが、料金の幅があり難しい
  - アセスメントの実施
    - 組織面が弱いことを指摘される
困っていること
- 進め方と方向性が合っているかわからない
  - CSIRT立ち上げ
  - 情報資産棚卸し
  - SOCチーム立ち上げ
  - など
  - 質疑応答的相談
    - 臼田さん
      - 何もできていない状況からここまでもってきたのはすごい
      - 対応方針は間違っていない
        
        アセスメントがとてもよかった
        
        アセスメントにお金かけられるか？が最初の壁
      - 対応の順序も適切
        
        うまくいった秘訣は政治的なところにしがらみがなかったこと（竹内さん）
    - 吉江さん
      - なんでセキュリティの話になった？
        
        なんで急にセキュリティについて聞かれたかわからない、唐突（竹内さん）
        
        元々セキュリティについてはワードレベルでは知識があった（竹内さん）
      - 進め方があっているか？の判断としてお尻が決まっているか？がある
      - SOCチームと別のチームの立ち上げ
        
        インシデントハンドリングを行う情報セキュリティチーム
        
        情報アセットマネジメントを担うチーム
      - 社内リソースでできるか確認中だが、外部委託も検討中、いズレは社内リソースでやりたい（竹内さん）
    - 大竹さん
      - メンバーはその気になっているか？
        
        自社1人+協力会社1人+ベンダーの体制でやっている（竹内さん）
    - 吉田さん
      - 情報資産の棚卸しをやっているのは偉いが、一歩先の流通経路の制御にも目を向けるといい
        
        情報資産の棚卸しはこれからやるところ（竹内さん）
      - 難しい話ではなく、まずはISMSやISOのようなところで使われるものの拡張として考えるのがリーズナブル
- AWSリソース管理について
  - 課題
    - 開発環境はセキュリティ緩めに作っているので、よくアラートが上がる
      - 開発者にアラート対応してもらうという話を聞いたので、明日からやってみる
    - 本番環境はインフラチームが作業しているのでボトルネックに、IaCの導入を進めている
  - 質疑応答的相談
    - 臼田さん
      - 開発者の方にうまくやってもらう仕組みをつくることが大事
      - DMMさんの例のようにあまりアラートを見せないようにする、など
      - どんなアラートが上がる？
        
        SG周りのアラート（竹内さん）
      - 本来はガイドラインの整備と一緒にやるもの
      - なんでそうするのか？どうするのがより良いのか？を根拠付きで出すと取り組みやすい
      - セキュリティの問題を手前に持ってくることも大切
    - 吉江さん
      - ガイドラインがないならFAQを作っていくのもいい
      - DMMさんの例のJiraのようなツールを使うと対応内容のノウハウ化が楽
      - Highはすぐやる、Middleは少し後でいいなどのルール作り
    - 吉田さん
      - やってはいけないアクションはあらかじめ縛っておく、やり方
        
        CloudTrailの無効化など
      - アラート疲れの問題
        
        IaCでセキュリティを担保すればアラートが出づらくなる
      - IaC導入がいつ終わるのか
        
        導入は終わりなき旅
        
        小さいところから始めていくことが良い
        
        すべてIaCはなかなかきつい
    - 大竹さん
      - アラート発砲の経緯って追えていますか？
        
        試行錯誤によるものだったらいいが、とりあえず開けているかも（竹内さん）
      - 開発者ーSOC間で摩擦が起きないようにサンドボックス環境を作って、そこで慣らす
      - サンドボックス環境はやられる前提でルール整備するのが良いかも
Sli.doからの質問
- 質問：進めていくしがらみとか、2人でやるのは辛くないか
  - トップダウンの依頼なのでしがらみはない
  - 人は欲しいが、セキュリティ人材が集められるとは思っていない
  - やる気のある人が来てくれたら嬉しい
- 質問：セキュリティは〜〜をしたら大丈夫、ってものではないが、偉い人への報告はどうする？
  - セキュリティ防御のサイクルができたら報告可能
    - インシデントを受ける、何を守るのか？の定期的なチェック
    - 外部からの攻撃を受けて、対応するの一連の流れ
  - 仲間を増やすアプローチができたらいいな（吉江さん）
  - 全部署横断的なタスクフォースはできないかな（大竹さん）
  - 期間限定で他チームからSOCチームに来てもらう（吉田さん）
- 質問：パネラーに質問、組織にセキュリティ担当は何人くらいいるもの？
  - 5人中1人いたら御の字（吉江さん）
  - 専任が難しい場合、兼任か兼任をローテーションすることが現実的（吉田さん）