この記事は、Supershipグループ Advent Calendar 2022 最終日の記事です。
はじめに
Supership CTO の @noriakiutsu こと宇都宮です。
メリークリスマス！今年も最終日に投稿を担当します。
今回は2年ぶりに復帰した舐達麻のdopeな新曲を聴きながら記事を書きました。
本年は昨年公開したクラウド移行の話にも通じるセキュリティの話です。
余談ですがGoogle Cloud Next'22 においてクラウド移行の話で登壇しました。
その内容をITmedia 様が記事にまとめてくださってます。
興味があればぜひご一読ください！
https://www.itmedia.co.jp/news/articles/2210/14/news105.html
背景
私はCTO の役割の他にSupership グループ全体のCISO も務めています。
執筆している現時点でも残念ながらセキュリティインシデントが複数発生しています。
昨年クラウド移行を意思決定し、移行プロジェクトがスタートして数ヶ月後
忘れもしない2021年12月9日
全世界に衝撃的なソフトウェアの脆弱性が報告されました。
その名は... Log4Shell（別名CVE-2021-44228)
脆弱性の内容についてはIPAセキュリティセンターから発出された情報や
Wikipediaをご覧ください。
当時の状況
インターネット上で注意喚起がされ始めた頃、Twitter などでマインクラフト上でエクスプロイトの形で攻撃が成立する動画が拡散されていましたが
事の深刻度はOSSプロジェクトのソフトウェアゆえ、情報が錯綜しており正確に把握できない状態でした。
結局この脆弱性は以下の攻撃が成立するかなり深刻なものである事が確定しました。
CVSSの深刻度評価は最高点の10です。
攻撃者はロギングされる文字列を入力することで、公開URLでホストされた悪意のあるコードを読み込ませることが可能になる。たとえデータの実行自体が無効化されていたとしても、攻撃者はURLに特定の文字列を含めることで、たとえば秘密にすべき環境変数などのデータを攻撃者のサーバーに送信できる。
この時点で頭を抱えてしまう程の事態であると捉えました。
何故ならApache Software Foundation(ASF)の支援するプロジェクトは
全世界に拡がるOSSエコシステムをほぼボランティアとして確立しており
日々恩恵を受けている我々は誰にも責任を求める事ができません。
プロジェクトに関わる世界中のボランティアの皆さんが必死に修正を試みてくださっている間、対象ソフトウェアの利用を止めない限り攻撃が続きます。かと言って対象ソフトウェアの利用を急に停止する意思決定が即可能かどうかはそのソフトウェアが担う役割によって様々です。事業で利用している場合の意思決定は非常に難しいものになるでしょう。
情報収集
Log4j の脆弱性という事で
社内で利用しているjvm言語で書かれたミドルウェア、ソフトウェアはおそらくほぼ全てが対象になってくるだろう...
という予測の元
CSIRT にはソフトウェアインベントリの収集、とりまとめを依頼する一方で
CTO の立場を利用して（この役割のスイッチが本件では有効となりました）VPoE に開発者の協力を要請、情報の抽出を最優先とするよう依頼しました。
私が事前に利用中の技術スタックを把握しているだけでもHadoop を筆頭にElasticsearch, Apache Slor, Databricks などがあり
移行が決定しているとはいえ700台以上のHadoop が対象であった場合
ログを集積するデータ基盤として利用しておりiDC内からアウトバウンドトラヒックを制限していない環境下において
悪意ある攻撃者がUser-Agentに攻撃のトリガーとなる文字列を埋め込んでおくだけでデータパイプラインが全てリモート攻撃の対象となる事を考えると本気でサービス停止を検討する段階でした。
またこの事の重大性について私とCSIRT以外は深刻に受け止められていなかった点も苦しめられる要因となりました。
インテリジェンス活動
社内の情報収集を行いつつ、脆弱性の最新情報の収集も行わなければなりません。
この際Slack に関係者を参集しましたが信頼できる情報元によるファクト以外の情報を以って
会話に入ってくるメンバーもおり収集がつかない状態になりつつあったので
一定のオーソリティのある見解の情報ソースを用いてのみ会話するようにしました。
Log4jのどのバージョンが影響を受けるのか？が最大の関心事でしたが
下記のissuecomment にあるように当事者達もかなり混乱していたようです。
応急処置
結局log4j2.x のみ影響を受ける事が確定となった段階でパブリッククラウドで利用している対象ソフトウェアについてはベンダーが配布を開始した緊急パッチの適用、またJava のバージョンアップ、WAF の適用までのオペレーションを最優先で遂行する事を指示しオンプレミス環境で利用している対象ソフトウェアについてはJava のバージョンアップを指示し応急処置を行いました。
懸念事項であった700台ものHadoopについては幸か不幸かEOLとなっている1系で稼働しており緊急度を下げました（それも...どうなんだ...）。
当然2系にバージョンアップする事が好ましいのですがソフトウェアのバージョンアップ作業に１年以上かかる見込みである事と移行計画を天秤にかけ今回は移行計画を優先する事にしました。
恒久対応
ここで本記事のタイトルである『今年のセキュリティ、今年のうちに。』に立ち返ります。
Tenable のレポートによると、5億件以上のテストから収集したデータから2022年10月1日時点で72%の組織がLog4Shellの脆弱性を依然として抱えたままでいるそうです！恐ろしい！！
またTenable CISO の談話によると
”ある時点では完全に修復されたとしても、その環境に新しい資産を追加していくと、Log4Shell に何度も遭遇する可能性があります。Log4Shell を根絶することは継続的な戦いであり、組織はこの欠陥やその他の既知の脆弱性について継続的に環境を評価することが必要です。” との事。
セキュリティ施策を先延ばしにする事は論外の上、『今年のセキュリティ、今年のうちに。』とある時点での対策まで行っていても環境評価を継続的に行わないと脆弱性は根絶できないのですね。
現在の状況
利用しているパブリッククラウドにはGuardDuty やSecurity Command Center など
驚異の検出が可能な便利機能やセキュリティを強化する各種機能が提供されていますが、
iDC内で構築しているオンプレミス環境は過去経緯からセキュリティバイデザインの概念が一切注入されていません。
ですのでDCセキュリティと称したプロジェクトを本年度立ち上げ現状把握とロードマップを組み上げるまでを短期目標として設定し現在進行中です。
プロジェクトを宣言した際、各要素を明文化してあるのですがプロジェクトの期間については以下の文章を用いています。
情報セキュリティの整備に終わりはない。プロジェクト化により優先順位を決め各期毎取り組むこと
またLog4Shellの対応に辺り、CSIRTに過大な業務量が集中した事を重く受け止め
より開発に近い立場でセキュリティに取り組むPSIRTの立ち上げを企画中です。
FIRSTが公開した「製品セキュリティインシデント対応チーム（PSIRT）成熟度ドキュメント 運用能力と成熟度レベル」で定義されているプロダクトセキュリティの理想形態からどれだけ現状がかけ離れており、どう体制を構築していくかCSIRTメンバーを中心にして組織設計を行っています。
おわりに
Log4Shellの深刻な脆弱性への社内対応までのリードタイムやエンジニアメンバーのセキュリティ感度などから鑑みて本年は特にセキュリティを強化しなければならないと意識してきました。
戦争の混乱に乗じたサイバー攻撃や情報漏洩事件が盛んに発生した印象もあります。
情報セキュリティへの取り組みは経営から見れば本当にただのコストセンターです。
正しいリスク評価の元、適切な予算をセキュリティ投資に費やしたいのですが
他の経営陣になかなか理解してもらえないのがセキュリティ経営となります。つらい。
CISO が集うインナーサークルに参加させて頂いた際、CISO ハンドブックの著者として著名な方から拝聴した言葉が印象に残っています。
セキュリティ経営を推進する秘訣は
仲良くする必要はないけど、適度な距離感でCEOと普段から会話できるようになっておくこと
という事でした。
宣伝
Supershipグループでは一緒に働いてくださる方を切実に望んでおります。
本記事を読んでご興味がある、PSIRTの活動が面白そうだ
いつかこの会社でCISOをやってやってもいいぞという方がおられましたら
以下リンクより是非弊社採用情報をご一読ください。
おまけ
今年無事。
今年も ILL-BOSSTINO のこの言葉を捧げます。
皆さま良いお年をお迎えください。