終わりなき攻撃対象領域の時代における予防

本記事は SD Times に掲載された記事の転載です。内容を更新し、こちらで配信しています。

‍

進歩について語るとき、通常、デジタル技術の発展が議論の最前線にあります。私たちは、より良く、より速く、より便利で、より強力なものを求め、それをより少ないコスト、時間、リスクで実現したいと考えています。多くの場合、こうした「不可能」な目標も最終的には達成されます。数年と複数のバージョンを要し、機能設計の変更を もう一度だけ 求められたら反乱を起こしかねない開発チームの努力が必要かもしれませんが、コードは日々、世界を変え続けています。

しかし、ソフトウェアの大きな拡大には大きな責任が伴います。現実には、セキュリティの観点からそれに対処する準備ができていません。ソフトウェア開発はもはや孤立した作業ではありません。クラウド、家電や自動車の組み込みシステム、重要インフラ、そしてそれらすべてをつなぐAPIに至るまで、ソフトウェアがもたらすあらゆるリスクを考慮すると、攻撃対象領域は境界を失い、制御不能な状態にあります。

すべてのコード行を熟練のセキュリティ専門家が細かくチェックするような魔法のような時代は期待できません。 スキルギャップはすぐには埋まらないでしょう。しかし、業界全体として、コードレベルのセキュリティに対してより包括的なアプローチを採用することは可能です。

手元にあるツールを使って、この無限に広がる攻撃対象領域をどのように管理できるかを探ってみましょう。

ビジネスリスクのレベル（および許容範囲）を現実的に捉える

完璧なセキュリティは持続可能ではありませんが、目隠しをしてすべてが順調であるかのように振る舞うことも同様です。組織が脆弱なコードを意図的にリリースしていることは周知の事実であり、これは明らかに、新機能や新製品の市場投入までの時間を優先した計算されたリスクです。

スピードを重視したセキュリティは、特にDevSecOpsが標準的な開発手法となっていない場所では困難な課題です。しかし、最近の Log4Shellの脆弱性 を見れば、コード内の比較的小さなセキュリティ問題が、いかに攻撃の成功につながる機会を生み出したかがわかります。品質の低いコードをリリースするという計算されたリスクの結果は、当初の予測をはるかに超える可能性があるのです。

（アクセス）コントロールの鬼になる

驚くほど多くの高コストなデータ侵害が、クラウドストレージ環境の不適切な設定によって引き起こされています。アクセス制御のミスに起因する機密データ漏洩の可能性は、多くの組織のセキュリティチームを悩ませ続けています。

2019年、フォーチュン500企業であるFirst American Financial Corp. は この教訓を痛感しました。比較的簡単に修正できたはずの認証エラーが、銀行取引明細書、住宅ローン契約書、写真付き身分証明書を含む8億件以上の記録の漏洩につながりました。ドキュメントのリンクにはユーザー識別やログインが不要で、Webブラウザさえあれば誰でもアクセスできる状態でした。さらに悪いことに、リンクには連番が振られていたため、番号を少し変えるだけで新しいデータレコードが露出してしまう仕組みでした。

このセキュリティ問題は、メディアで報じられる 前に内部で特定されていました。しかし、それを高リスクのセキュリティ問題として適切に分類できず、緊急の修正のために経営陣へ報告しなかったことが、現在も対応が続いているような事態を招きました。

不適切なアクセス制御が現在 OWASP Top 10 の筆頭に挙げられているのには理由があります。それは極めてありふれた問題だからです。開発者は、認証や権限に関するベストプラクティスを実践し、機密データの漏洩を防ぐためのチェック体制を構築するために、検証済みのセキュリティ意識と実践的なスキルを身につける必要があります。

APIの性質上、この問題は特に重要かつ厄介です。APIは設計上、他のアプリケーションと頻繁に通信を行うため、開発チームはすべての潜在的なアクセスポイントを可視化しておく必要があります。結局のところ、未知の変数やユースケースを考慮しなければ、より安全なソフトウェアを提供することはできないのです。

セキュリティプログラムを分析する：予防にどれだけ重点を置いているか？

セキュリティプログラムの大部分がインシデント対応や事後対策に割かれるのは理にかなっていますが、多くの組織は、セキュリティインシデントを未然に防ぐために利用可能なリソースをすべて活用できておらず、リスク最小化の貴重な機会を逃しています。

確かに、問題のあるバグを発見するための包括的なセキュリティツール群は存在しますが、企業の約50%が脆弱性を認識したままコードをリリースしていると認めています。時間の制約、ツールセットの複雑さ、報告に対応できる専門家の不足などが、実質的に「計算されたリスク」となって積み重なっています。しかし、クラウド、アプリケーション、API機能、組み込みシステム、ライブラリ、そして絶えず拡大するテクノロジー環境全体でコードを保護しなければならない現状では、現在のアプローチのままでは常に後手に回ることになるでしょう。

セキュリティバグは人間が引き起こす問題であり、すべてをロボットに任せて解決できるわけではありません。開発チームに対して、単なる年1回のセミナーではなく、適切な教育の積み重ねといった効果的なスキルアップの機会を提供できていなければ、低品質なコードが標準化され、それに伴うセキュリティリスクを常に抱え続けることになります。

開発者の準備状況を過大評価していませんか？

開発者がセキュアコーディング能力を評価されることは稀であり、それが優先事項（多くの場合、KPIですらありません）になることもありません。より良い方法が示されず、それが成功の指標であると伝えられていないのであれば、不適切なセキュリティ慣行の責任を開発者だけに負わせることはできません。

しかし、組織内では、提供されたガイダンスによってエンジニアチームが一般的なセキュリティリスクを軽減できるようになったと過信されていることがあまりにも多いのが現状です。トレーニングの内容やセキュリティのベストプラクティスを適用する意識によっては、彼らは理想的な「第一の防衛線」として機能する準備ができていない可能性があり、その結果、ペネトレーションテストのレポートがインジェクション攻撃の欠陥で埋め尽くされることになります。

理想的な状態とは、難易度が段階的に上がる学習パスを修了し、そのスキルが現実の開発現場で実際に機能することを検証することです。しかし、これには開発者の視点を最初から考慮し、適切に権限を与えるという文化的な基準が必要です。私たちが業界として、自ら作り上げた広大なコードの領域を守るために荒野へ挑むのであれば、あらゆる助けが必要となります。そして、私たちが気づいている以上に、その助けはすぐ目の前にあるのです。