システムの脆弱性、把握してますか? これからはじめる脆弱性管理 日本仮想化技術株式会社 水野 源 [email protected] 2023/08/02 1

日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 • 設立：2006年12月 • 資本金：3,000万円 • 売上高：212,358千円（2019年7月期） • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO）・伊藤 宏通（取締役CTO） • スタッフ：8名（うち、6名が仮想化技術専門エンジニアです） • 仮想化技術に関する研究および開発 • 仮想化技術に関する各種調査・導入運用サポート • 自動化・DevOps支援 • 5G・MECに関わる研究開発 2 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団

発表者について • 水野 源 • VTJ 技術部所属 • Ubuntu JPメンバー • ubuntu.comメンバー • 日経Linuxにて「Linux 100%活用 ガイド」を連載中(連載9年目) • ←こんな本を書きました 3

本日のアジェンダ • 脆弱性対策とは • 脆弱性情報の入手 • ディストリビューションの脆弱性とは • パッケージバージョンの見かた • 脆弱性管理クラウドサービスの活用 • yamoryとは • 脆弱性スキャンの種類 • 脆弱性への対応 4

脆弱性対策してますか？ 5

脆弱性対策してますか? • どんなプログラムにもバグは存在する • セキュリティ的な脅威となるバグや設定不備などの総称 • → 脆弱性 • 現代的なシステム、サービスではとにかくセキュリティが第一 • 脆弱性は日々、新しく発見されている • これを放置すると、不正アクセス、情報流出、ランサムウェア感染など、様々 な被害に合う可能性もある • 基本的に脆弱性は放置してはいけない 6

脆弱性情報を入手するには • まず、世の中に出回っている脆弱性を知る所からはじめよう • 脆弱性は一意に特定するために、番号をつけて管理するのが基本 • 有名なところではCVEとか • https://cve.mitre.org/ • Twitter XのCVEnewとか見ておくといいかも？ • https://twitter.com/CVEnew 7

ディストリの脆弱性情報を調べよう • 直接CVEを見ても「へー、このアプリに脆弱性見つかったんだー」で終わり • すべての脆弱性を追いかける必要はない • 「自分に影響するのはどれなのか」を知るのが大事 • まず見るべきは、自分が使っているOSのパッケージの情報 • UbuntuではUSNでパッケージごとのセキュリティ通知が見られる • https://ubuntu.com/security/notices • USNのRSSフィードをSlackに登録したり、ubuntu-security-announceメーリングリス トを購読するのも有効 • CVE番号から、その脆弱性が影響するUbuntuのパッケージや、修正状態 を調べることができる • https://ubuntu.com/security/cves 8

Ubuntu Security Notices 9

Ubuntu CVE reports 10

Upstreamバージョンとパッケージバージョン • ディストリの脆弱性情報を知るにあたって重要なのが、パッケージの バージョンとセキュリティアップデートの方針 • Ubuntuのようなディストリでは、リリース後にアプリのバージョンを上 げることは基本的にしない • あるアプリのバージョン1.0.Xのパッケージが含まれてリリースされた場合、5 年後でもこのアプリのバージョンは1.0.Xのまま 11

具体例: opensslパッケージ(1) • Ubuntu 22.04 LTSのOpenSSLのバージョンは3.0.2 • バッファオーバーリードによるサービス停止の可能性がある脆弱性 CVE-2023-1255は、upstreamではOpenSSL 3.1.1で修正された • 通常であれば、このバージョンにOpenSSLをアップデートする必要がある • しかしコアなライブラリのバージョンを上げると、システムへのインパクトが非 常に大きい • そこで一般的なディストリでは、アプリやライブラリそのもののバージョンは 上げず、セキュリティ修正のみを新バージョンから「バックポート」する 12

具体例: opensslパッケージ(2) • Ubuntu 22.04リリース時(2022年4月)のパッケージバージョン • openssl_3.0.2-0ubuntu1 • 現在(2023年7月)のパッケージバージョン • openssl_3.0.2-0ubuntu1.10 • OpenSSL自体のバージョンは3.0.2のままだが、「パッケージバージョ ン」が上がっているのがわかる 13

具体例: opensslパッケージ(3) • CVE-2023-1255の修正は、3.0.2-0ubuntu1.10でバックポートされた 14

具体例: opensslパッケージ(4) • つまりUbuntu 22.04では、OpenSSLのバージョン自体は3.0.2のまま だが、3.1.1の修正も含まれているので安心 • 5年間のセキュリティサポートとはこういうこと • パッケージにセキュリティ修正が当たっているかは、単純にupstream のバージョン文字列を見ただけでは判断できない • 「OpenSSL 3.0.2!? 古すぎ!!」ではない • ディストリ固有のパッチを見て判断する必要がある • 一般的なLinuxディストリビューションでは、セキュリティパッチはバックポート して適用されているため、upstreamのバージョン文字列で判定しようとしては いけないのが大原則 15

こういう事情を知らない(えらい)人がいると 16 こんな脆弱性が話題になってるので、全サーバーのOpenSSLライブラリの バージョンを調査して至急報告してください openssl_3.0.2-0ubuntu1.10です 3.0.2は問題があるので、3.1.1以上にバージョンアップしてください いえ、パッケージにセキュリティパッチが当たっているので解決済みです 全社的にバージョンアップの指示が来ているので、とにかく3.1.1以上のバー ジョンに上げないとダメです

つらい 17 ポンコツなセキュリティスキャナを導入しちゃうと、単純にバージョン文字列を比較して、こういうことを言ってきたりしてつらい。 検索ワード: gihyo.jp 盲腸

脆弱性があるのはサーバーOSだけじゃない • DockerHubからPullして使ってるコンテナの中身は？ • アプリがrequireしている外部ライブラリは？ • ルーターやファイアウォールのファームウェアは最新？ • クラウドサービスの設定は適切？ • これを全部チェックして、適切にな状態に管理できる？ • 人力ではきつい • → セキュリティスキャナや脆弱性管理サービスを活用しよう 18

脆弱性管理クラウドサービス「yamory」 19

脆弱性管理クラウドサービス「yamory」とは • オールインワンの脆弱性管理クラウドサービス • https://yamory.io/ 20

yamoryの特徴 • サーバーやコンテナ、アプリ、IT資産を登録すると、脆弱性データ ベースと突き合わせ、脆弱性をチェック • 一度情報を登録すれば、毎日定期的に脆弱性診断を行ってくれる • ルーターのファームウェアなども管理可能 • 見つかった脆弱性は、独自のスコアリングルールに基いて、自動的 に脅威度を設定 • 脆弱性の状況をメールやチャットで通知可能 • 脆弱性の修正状態の管理が可能 21

ホストスキャン • LinuxサーバーやWindowsサーバーの脆弱性をスキャンできる機能 • yamori-cliクライアントをインストールして、Cronなどで定期的に実行 • yamori-cliはインストールされているパッケージ情報などを、「アセット」として クラウドのサーバーに、マシンごとに登録する • 毎日、登録されたアセットと脆弱性データベースの照合が行われ、脆弱性が 存在した場合は通知される • スキャンはSSH越しに行うことも可能 • 複数のサーバーが存在する場合、すべてにyamory-cliをインストールして Cronの設定をするのは大変 • SSHスキャンであれば、踏み台サーバーにyamory-cliをインストールして、ス キャン対象の設定を行うだけでよい 22

ホストスキャン 23

コンテナスキャン • DockerHubなどコンテナレジストリに存在するコンテナイメージをス キャンする機能 • コンテナのイメージタグを指定することで、ホストスキャン同様に日時 でスキャンが行われる • バックエンドにはTrivyが使用されている 24

コンテナスキャン 25

アプリライブラリスキャン • アプリケーションのGitリポジトリを登録し、使用しているライブラリの 脆弱性をスキャンする • Node.jsならnpmだったり、PHPならcomposerだったり、言語ごとのパッケージ 管理システムを使ってライブラリをインストールするのが一般的 • yamoryはアプリのGitリポジトリを登録すると、こうしたパッケージ管理システ ムを検出し、インストールされるライブラリをチェックしてくれる • GitHubのDependabotのような機能 • GitHubとの連携が可能 • ダウンロードしたソースコードをスキャンすることも可能 26

クラウド設定管理(CSPM) • 現代的なインフラ構築には、AWSなどのIaaSを使うのが一般的 • クラウドのセキュリティ対策はとても大事だが…… • IAMユーザーに弱いパスワードが設定されていたり • 無駄に強い権限を持ったロールが払い出されていたり • セキュリティグループにPublicからのSSHを許可するルールが追加されていたり • など、「クラウドの設定の不備」というものがよくある • そしてこれらを人力でチェックして回るのは大変 • CSPMは、クラウドのアカウントを連携させることで、こうした不適切な設定 を洗い出し、リストアップすることができる • 新しいプロジェクトを開始したら、まずはまっさらなクラウドアカウントと yamoryを連携させてみて、初期構築前に問題点の洗い出しをしてみると いいかもしれない 27

クラウド設定管理(CSPM) 28

IT資産管理 • ルーターやファイアウォールのファームウェアを最新に保つのも大事 • だがサーバーOSと違い、ツールをインストールしての監視などが苦手 • yamory-cliがインストールできないIT資産を、半手動で管理する仕組 みがIT資産管理 • 対象のIT資産と資産を特定するための情報、ファームウェアのバージョンな どを登録することで、脆弱性のチェックが行える • 言ってみれば、今までエクセルで行っていた資産管理を、もうちょっとリッチ にやってくれる機能みたいなもの • 例えば弊社では、CiscoやYAMAHAのルーターや、Fortigateのファイ アウォールなどを管理している 29

脆弱性への対応 30

脆弱性への対応の原則 • 基本的に脆弱性は放置してはいけない • とはいえ、すべての脆弱性に対応する必要もない • 脆弱性のスコアが高い=緊急対応が必要という意味でもない • どんなに重大な脆弱性であっても、自分のシステムに対して、現実 的に攻撃が不可能なのであれば緊急度は低い • そのため脆弱性スコアを鵜呑みにしてはいけない • 大切なのは、その脆弱性がどのくらい影響するかを把握し、正しく優 先順位をつけて対応すること(トリアージ) • 正しいトリアージができないと、見つかった脆弱性は全部なくせとか言い出 す人がでてくる • そんなことをしても、意味もなく現場が疲弊するだけ 31

スコアリングと状態管理 • yamoryでは同じ脆弱性でも、対象のホストの公開状態によって脅威度を変化さ せるなど、柔軟なスコアリングシステムを採用している • 「Immediate」「Delayed」「Minor」「None」の4段階 • 見つかった脆弱性ごとに、対応状況を管理できる • 重大な脆弱性でも、インターネットに公開していないため影響を受けないホストもある • だが影響しないからといって何もしないと、脆弱性を放置しているように見えてしまう • そのような場合は、ステータスを「修正しない」や「誤検知」とするなどが可能 • 週ごとの脆弱性の対応状況の推移もグラフで確認できる • サボってたりするとすぐわかる • 新たに見つかった脆弱性や、週次のレポートは、メールなどで通知もできる 32

まとめ 33

まとめ • どんなシステムにも脆弱性はある • → ディストリの仕様も含めてちゃんと把握しましょう • 脆弱性は放置しちゃだめ • かといって、全スキャン全修正は現実的ではないし、無意味 • → 対応すべき脆弱性を正しくトリアージしよう • ハンドリングできる支援ツールを使ってみるとよいのでは • → yamoryはなかなかよさげなので、興味があったら相談に乗りますよ 34

DevOpsサポートサービス https://virtualtech.jp/devops/ DevOpsを始めたいチームのための支援サービス 開発プロジェクト • 開発環境 • GitHubリポジトリ • CI/CD • IaC (デプロイ環境) 運用チーム • 運用監視 • 脆弱性スキャン • インシデント管理 • IaC (共通インフラ) 運用をまるっとお任せしたい おまかせDevOps (かんたんDevOpsに加えて) DevOps環境の運用・改善 インフラコードの保守 発生したインシデントへの対応 DevOps人材を育成したい かんたんDevOps DevOpsの環境初期構築 インフラのコード化 DevOpsプロセスの実践手順書・支援 技術サポート