EC2の脆弱性管理を始めてみえてきたこと

第37回 総関西サイバーセキュリティLT大会 EC2の脆弱性管理を始めてみえてきたこと （あくまで個人の感想です） 2023年06月03日 chocopurin

Self-Introduction 名前：chocopurin  職業：とある企業の一般社員  主なお仕事      ITインフラ構築/維持管理 セキュア開発基盤の整備（SAST/DAST） 永遠のAWS見習い 出没歴 Nakanoshima.dev, AWSエバンジェリストシリーズ Hardening Designers Conference 2023 Micro Hardening Security-JAWS, OWASP Kansai, レトロゲーム勉強会 etc

はじめに 本日のLT内容は、フィクションとノンフィクションが 入り混じった個人の感想です。 予めご了承ください。

インフラ構成の変遷と本件の対象

Amazon Inspector v2による脆弱性管理  EC2上のサーバ群の状況を一元管理

Amazon Inspector v2による脆弱性管理 【例】2022年11月2日公開のOpenSSL（libssl3）

Amazon Inspector v2による脆弱性管理 【例】CSVレポート

EC2の脆弱性管理を始めてみたが・・・  インスタンス毎の解析結果（抜粋）

絶望感が見える化されただけだった・・・  想定数以上の要対処サーバと脆弱性    導入時からもしくは緊急時の対応以外アップデートなし 試行錯誤しながら導入して、そのまま運用フェーズに突入 手の施しようのないサーバの存在   古すぎてAmazon Inspectorエージェントを導入できない 過去の経緯から、誰も中身を知らない • •  勝手デプロイがまかり通っていた いつの間にか24時間365日稼働化 パッチ適用への恐怖心からズルズル • • 適用したら何が起こるかわからない 再起動したら立ち上がるかわからない

諦めたらそこで試合終了

できるところから止血と根治を やっていくしかない

止血と根治：サイバーセキュリティは経営課題 ● 有事による業務影響の見える化  ● トリアージ   ● 何事も自分の現状を知ることから 優先度付け リスク受容可否の判断 経営層とのバトルを恐れない    命まで取られるわけではない 数字で示せばだいたい何とかなる 何かあったら困るのは経営層自身だよ

止血と根治：既存サーバ  手の施しようのないサーバは継続利用を認めない  再開発PJに合わせて葬り去る  残す場合はリスクを受容する旨で会社としての意思決定をとる  リスクを受容するにしても、緩和策がとれないかあがいてみる • NW構成変更 • WAF導入 などなど

止血と根治：新規サーバ  サーバ構築もシフトレフト （普段のタスクをセキュリティ運用まで深堀する） 【例】  停止/再起動可能時間  冗長構成の方式  リプレース時期 企画 要件定義 設計 ⇒ パッチ適用可能時間 ⇒ メンテナンス方法 ⇒ サーバのライフサイクル 実装 ※サーバレスに移行した方がいいかもという議論は一旦置いとく テスト リリース 運用

パッチ適用への恐怖心は克服できる  パッチ適用がしんどいと思ってしまう理由   日々リリースされる脆弱性情報の量 一気に適用しようとすることによる作業の煩雑化 • • • ● 影響調査（適用可否） 作業手順作成 適用/打鍵テスト etc 適用イベント毎に発生 日頃から影響調査やパッチ適用が回る仕組みを整える   スタンバイ機の準備, 自動テストの整備 Linuxツール • •  アップデート：unattended-upgrades, dnf-automatic など (セキュリティアップデートに絞ると安定する) 再起動：cron, systemd.timer AWSサービス：Systems Manager

まとめ   EC2上に構築されているサーバ群の脆弱性管理を始めた 脆弱性管理ツールがやるのは、あくまでも次のアクショ ンの手掛かりを見える化してくれるところまで  パッチ適用の恐怖心は克服できる  サーバ構築もシフトレフト