今回も、ITセキュリティ最大のイベントであるRSAカンファレンスに参加する機会を得た。完全なリモート開催であった2021年とは異なり、2022年はオンサイトでの開催がなされ、参加者から喜びの声が多く聞かれた。最終的な参加人数の公式発表はまだないが、開催前には2万人超える参加者を予定しているとのことであった。
RSAカンファレンスの参加には、最低でも2回のワクチンを打っているか、48時間以内の陰性証明が条件となっており、事前に「SafeSpaces」というアプリを利用してワクチン接種証明書の提示・審査が必要になるなど感染対策を施した体制で行われた。
本稿では元エンジニアのコンサルタントの視点で、RSAカンファレンスのポイントをまとめる。
2022年RSAカンファレンステーマ「Transform」
今年のRSAカンファレンステーマは「Transform」で、これには、以下のようなメッセージが込められている。
あらゆるもののデジタル化が進む中で、もはやセキュリティは裏方ではなく、ビジネスが成長する上で欠かせないインフラ基盤の一部となった。サイバーセキュリティは変化の絶えない世界であり、誰もが安心してつながれるように成長し、進化し、力を合わせ続け、共に変化しよう。
Keynoteの中でも、破壊や崩壊、混乱（Disruption）に対応するために、Change（変化）ではなく、抜本的な変革（Transform）が必要であると述べていた。これはパンデミックという破壊的な要因への対応として、1年という従来ではありえない速度でワクチン開発が行われた変革になぞらえている。攻撃手法の巧妙化や、デジタル化が加速する中で、セキュリティに生じる混乱にも、変革が起こせるチャンスとして捉えていくべきとのメッセージとして受け取った。
RSA Conferenceの会場「Moscone Center」
余談ではあるが、開催地であるサンフランシスコでは街中をケーブルカーが走っており、会場のMosconeと、Fisherman’s Wharfという港をつないでいる。
筆者はFisherman’s Wharf近辺のホテルであったことからこのケーブルカーを利用したのだが、今もなお現役の手動運転ケーブルカーでは最古のものとのことだ。実際に運転している様を見ると身の丈はありそうなレバーにて加減速を調整し、終着駅から折り返し運転をする際には、車両を回転台の上に置き、駅員が体重をかけ、手動で車両の方向転換をしていた。
こうしたレトロな文化と、最先端のセキュリティカンファレンスが同居していることに町の魅力を感じた。サンフランシスコを訪れる機会があった際には是非体験いただきたい。
Conferenceのハイライト
RSAカンファレンスでは400を超えるセッションがあり、どれも興味深い内容であったが、以降では筆者の厳選したテーマを紹介していく。
①Building an Enterprise-scale DevSecOps Infrastructure: Lessons Learned
アジァイル開発モデルの素早いリリースに対し、セキュリティを充足させていくには、セキュリティも開発プロセスに統合していくべきである。このモデルを大企業に当てはめた場合に、多くのチームが、異なる技術を使っているため、最適化された情報ソースやセキュリティスキャナを使用するなどそれぞれが独自の方向性に進んでしまう。
DevSecOpsを組織として、全体最適化するための解決策とステップを紹介する。
■解決策
- ・統一されたスキャナの提供
- 実施内容：汎用的にプラグインできる製品を選定し、すでに使用されている開発ツール(CI/レポジトリ)と統合する
- 実施効果：開発プロセスの中で自然に利用できる環境の配備、ライセンスの最適化
- ・リポジトリ/プロジェクトと製品、チームの紐づけ
- 実施内容：開発に使われる資材（コードやDockerイメージなど）をチームや製品に紐づけマッピングする
- 実施効果：資材のセキュリティ対応の抜け漏れをなくし、チーム・製品単位でセキュリティ成熟度合いが明らかになる
- ・統合されたGUIの提供
- 実施内容：スキャンの情報や脆弱性情報を統合し、深刻度、修正方法、誤検知、リスク受容可否などの情報ソースを集約する
- 実施効果：開発者自身が提供された情報に基づいて行動をできるようにする
■対策ロードマップ
- ・いますぐ
- - 企業レベルでのDevSecOpsのアプローチに合意する
- - 既存のセキュリティスキャナのライセンス情報をまとめる
- - ベースとなるセキュリティスキャナや情報ソースを設定する
- ・1か月-2か月
- - 選択したツールを様々な開発環境に統合する
- - セキュリティ対応を促す担当者を特定し、定期的なフィードバックの仕組みを作る
- ・半年
- - 修正期限や優先順位に関するプロセスを策定する
- - セキュリティ文化を定着させるため開発者にトレーニングを提供する
②CI/CD: Top 10 Security Risks
アプリケーション開発を取り巻く構成要素は膨大で、CI/CDはそれをわかりやすくするためのエコシステムである。このエコシステムを保護するにあたり、実施すべき対策や、優先順位を決められるよう、攻撃に利用されるリスクのトップ10をまとめている。
概要として、CI/CDは開発環境として捉えられ対策が不十分となることや、またシステム間の接続が複雑なことに起因するリスクが多くみられた。システム上に配置されている情報の重要性や、CI/CDシステムの特長であるシステム間連携が多数あることを考慮し、適切なセキュリティ対策を実施していくことが大切である。
実際の講演はケースごとにどのリスクが当てはまるかを紹介するものであったが、ここではトップ10の簡単なまとめを記す。
■Top 10 Risks
- Risk1:不十分なフロー制御
- リスク：CI/CDプロセス内のシステム(CSM/CIなど)への一部アクセスを取得した攻撃者が悪意、または脆弱性のあるコードや、バイナリ、パッケージをパイプラインに流し込む能力を持つ
- 対策：承認ルールや、アカウントの制限、オリジンとの不整合の検証を実施する等
- Risk 2:不十分なID/アクセス管理
- リスク：CI/CDパイプラインはソースの管理から展開まで、関連するシステムの様々なレイヤにIDが存在し、膨大な量となることから管理が不十分となる
- 対策：ID管理の徹底（最小限の権限付与、ID棚卸し）、ローカルIDや共有IDを極力作成しないこと、外部IDの制御等
- Risk 3:依存関係の悪用
- リスク：アプリケーション開発に外部パッケージの利用は不可欠であり、その膨大さや、依存関係の複雑さから悪意、または脆弱性のあるライブラリ組み込まれてしまう
- 対策：信頼するソースのみ利用することや、パッケージの検証、インストールスクリプトが機密情報にアクセスできないことを確認する等
- Risk 4:ビルドパイプラインの悪用
- リスク：ソース管理システムにアクセスできる攻撃者が、悪意のあるコード/コマンドをビルドパイプラインに流し、ビルドプロセスを操作（構成ファイルの書き換えなど）する
- 対策：機密情報を持つパイプラインはCIシステムでトリガーすることや、パイプライン実行前の構成ファイルの検証や保護など、ソース管理システム/CI両者にまたがった等
- Risk 5:不十分なRBAC設定
- リスク：パイプラインを実行するノードは機密性の高い制御を実行するため、アクセスする必要のあるコード、シークレット、環境変数、ホストなどそれぞれに対するアクセス制御がなされていないと攻撃者に利用される
- 対策：各パイプラインとステップにおいて、必要なシークレットにのみアクセスさせることや、パイプライン実行ユーザには最小限のOSアクセスに制御する等
- Risk 6:不十分なクレデンシャル管理
- リスク：CI/CD環境は、相互通信及び認証する複数のシステムから成り立っており、クレデンシャル（認証情報）が点在しているため、攻撃者に狙われやすい
- 対策：コードにクレデンシャルが含まれないこと、クレデンシャル使用できる条件の設定(IP、ユーザ)、定期的なローテーション等
- Risk 7:不十分なセキュリティ設定
- リスク：CI/CDのシステムは、特性上構成するシステムの全てのレイヤの中で、一つでもセキュリティ欠陥があることで全体に波及していく可能性がある
- 対策： CI/CDを構成するアプリケーション、NW、OSと全てのレイヤでセキュリティ設定を実施する
- Risk 8:管理されていない3rd Partyサービス
- リスク：CIやSCMなどの資産にアクセス可能なサードパーティサービスも攻撃対象範囲に含まれる
- 対策：リソースアクセス前の承認、継続的なアクセス権の確認、不要となったサービスのアクセス権の削除等
- Risk 9:不十分なアーティファクトの検証
- リスク：複数のステップ、複数の投稿者で構成されたパイプラインは、アーティファクト(バイナリ/パッケージ)の改ざん可能なポイントが多く存在する
- 対策：署名や、検証ソフトウェアによる整合性の確認等
- Risk 10: 不十分なロギング/監視
- リスク：エンジニアリング環境に近く、通常のOA環境やサーバ環境と異なり、可視化が十分になされていない傾向がある
- 対策：適切なログソースを特定し、ログ出力と共に一元管理、分析、アラートを実施する仕組みが必要である。
■まとめ：マインドセットの転換が必要
エンジニアのエコシステムの変化により、エンジニアリング環境は攻撃対象の大きな部分を占めるようになった。アプリケーションセキュリティはコードを保護することを超えていて、コードからデプロイに至るまで、すべてのシステムとプロセスに対して包括的な傘を構築する必要がある。
まずはサードパーティを含むエコシステムの全体像をマッピングし、攻撃対象領域を理解する。そして、上記Top10のリスクを踏まえ攻撃者の視点に立った分析が実施できるようになる。
③Are Low-Code and No-Code Tools a Security Risk?
ローコード、ノーコード開発とは、従来までの文字列によるコーディングの代わり、視覚的な画面部品やロジック部品を組み合わせることでアプリケーションを開発する手法である。予測によると2024年までには65%のアプリケーションがローコードになると言われており、従来の開発がなくなるわけではないが、より簡単にシステムが作れるということで、技術的な知識がないチームもソリューションを構築し始めるようになるだろう。
そのようなローコード、ノーコードのセキュリティの考え方としては、「Contained」か「Connected」のラベル付けをするとシンプルに考えやすい。
- Contained：すべての処理がコンポーネント内で行われるもの。サービス内で完結するため、セキュリティの対策はSaaSと同じ考え方で良い。
- Connected：他のサービスと直接つながりデータと送受信を行われるもの。サービス同士の接続部分にリスクがあり、可視性、認証/認可、コンプライアンス、アクセス制御の観点で評価をしていくべきである。
■対策ロードマップ
- ・いますぐ
- -ローコード、ノーコードのアプリケーションを特定する
- ログの確認や、ヒアリングによりどこで誰が使っているかを把握する
- -Containedか、Connectedかラベル付けをする
- アプリケーションにラベルを分けし、大まかに評価が必要な場所を特定する
- ・1-3か月目
- -ローコード、ノーコードのコアプラットフォームを評価する
- プラットフォームにて可能なことの把握、セキュリティ対策の姿勢を評価する
- -Connectedラベルのプラットフォームのリスク評価する
- 可視性、認証/認可、コンプライアンス、アクセス制御などシステム間連携に必要なポイントのリスク評価を行う
- -OWASP Top 10（Low-Code/No-Code Security Risks）のガイドラインを利用する
- 上記評価にあたり、確認観点のサポートとして利用する
- ・6か月
- -ローコード、ノーコードに対するポリシーを策定する
- こうして使ってほしい、もし難しいのであれば相談してほしいというレベルでガードレールを設ける
- -Connectedラベルのプラットフォームの可視化をし続ける
- プラットフォームは常に変化していくため、セキュリティ対応姿勢を継続的に確認する
④Code Blue! Medical Devices Under Attack
統計によると2028年までに全世界で500億台のIoT医療機器が普及すると言われている。一方で、医療分野はデータ漏洩に伴う損失額が11年連続で最も高くなっている。またコストだけでなく、医療機器が攻撃されることで医療提供の遅延につながり、患者の命を奪うケースも出てきてしまうことになる。そのため医療はセキュリティの重要性の高い分野と言える。医療分野での脅威についてケーススタディを交え説明する。
■ケーススタディ1（モニタリングシステム）
- モニタリングシステムは、患者のバイタルや血圧、酸素濃度などのレベルを測定するベットサイドモニタと、この機器から情報を受け取るセントラルモニタシステムにて構成される。
- 講演ではGE Dash 3000というベットサイドモニタを用いたケースを紹介しており、この機器の通信トラフィックを見てみると、UDPにて、患者の特定が可能なデータを、暗号化なしで、ブロードキャストアドレスに送信をしている。
- そのため、ネットワーク上の機器であれば誰であろうと情報を取得することができる。また、通信先であるセントラルモニタシステムにて受信データの検証もなされないため、攻撃者が改変したパケットを送信することで、心拍数を全く別のものとするデモを紹介していた。
■ケーススタディ2（輸液ポンプ）
- 技術進歩により輸液ポンプもスマート化されており、薬剤の投与量はシステム制御されている。講演では、輸血ポンプのInfusomat Large Volume Pumpと、4つのポンプシステムを格納可能なドッキングステーションであるSpaceStation with SpaceComの実機を用い、遠隔操作による薬剤の過剰・過小投与の実例を見せた。
- ドッキングステーションには組み込みLinuxが使用されており、認証及び、データのサニタイズが不十分な状態で文字列を渡してしまうことにより、リモートでルートアクセスできるようになってしまう脆弱性を利用している。
ケーススタディから、医療機器それぞれのNW観点（どのようなプロトコルを用い、トラフィック、受付ポートとなっているのか）や、OS/Firmware観点（どのようなOS、脆弱性をもっているのか）を可視化、理解することが大切であることを学べる。
病院という公共性の高い施設にて、攻撃者がNWに侵入するのは難しくなく、また、医療機器は多くの独自技術から成り立っており、7~10年と長期的に使用されていることから、既知の脆弱性に対応できていない可能性が高い。
これらのリスクに対する解決策、ロードマップを下記に示す。医療やIoTの分野であってもセキュリティの基本となるNW分離や、暗号化、パッチ適用などの基礎を徹底していく必要がある。
■解決策
- ・セキュアコーディングプラクティスへの対応(認証強化・データ・通信の暗号化・セキュリティアセスメントによるリスクの検出)
- ・パッチ適用の簡素化(仮想パッチなど)
- ・ネットワーク分離
- ・ベンダ指標、ガイドライン(FDA･CISA)への対応
- ・潜在的な脅威を常に認識する(脅威動向のモニタリング等)
■ロードマップ
- ・いますぐ
セキュリティリスクの洗い出し、緩和策、リカバリープランの検討 - ・3か月
セキュリティ強化施策実施（特にレガシーシステムなど） - ・6か月
侵入テストなどを含む積極的なセキュリティテスト - ・1年
結果のレビューとステークホルダーのアクションプラン再考
おわりに
今年のテーマは「Transform」であったが、パンデミックや、紛争、記録的なインフレなどビジネスを取り巻く状況はよりダイナミックに変化していると感じる。
ビジネスの変化するスピードに乗り遅れることなく対応していくには、デジタル化によりビジネス戦略に変革を起こすことが必要であり、そのために新しい技術も積極的に取り入れて行くことが不可欠になってきている。新しい技術を取り入れることは、同時に新しいリスクが生まれることを意味するため、デジタル化と、セキュリティはセットで考えていく必要がある。
また、セキュリティへの脅威動向としても、ツールの作成、エクスプロイト、窃取した情報の販売、利用がそれぞれ分業化されつつあり、ダークマーケットが成熟してきている。ランサムウェアの被害額・件数は右肩上がりであり、Log4jなど新しい脆弱性を利用する亜種も見られるなど、攻撃の巧妙化・高度化が進んでいる。
こうした状況化において、セキュリティ対策をTransformしていくためには、どう考え、どう行動していくかも改めて見つめ直すことが求められる。都度脅威に対応していくのではなく、将来を見据え、脅威動向や技術動向、ライフサイクル、ガバナンスなど広い視野を持って総合的に計画を立案していくことが必要である。
セキュリティというテーマは企業への脅威として取られがちだが、戦略を定めきっちりとした対応を取っていくことで、安心を提供し、顧客に対する信頼の証とすることも可能である。今後はデジタル化と合わせ、セキュリティ戦略を定め、武器にしていくことで、変化への対応力と競争力強化を確固たるものにできるのではないだろうか。
