攻撃対象が無限に広がる時代の予防策

この記事のバージョンは、SD Timesに掲載されました。 SDタイムズ.この記事は更新され、ここにシンジケートされています。

‍

私たちが進歩について語るとき、一般的にはデジタルの進歩が最重要視されます。私たちは、あらゆるものをより良く、より速く、より便利に、よりパワフルに、そして、より少ない費用、時間、リスクで実現したいと考えています。しかし、毎日、コードが世界を変えているのです。 

しかし、ソフトウェアの大きな広がりには大きな責任が伴い、現実には、セキュリティの観点からそれに対処する準備が整っていないのが現状です。クラウド、家電や自動車の組み込みシステム、重要なインフラ、そしてもちろんそれらをつなぐAPIなど、ソフトウェアがもたらすリスクのあらゆる側面を考慮すると、攻撃対象はボーダーレスで制御不能なものとなっています。 

しかし、業界として、コードレベルのセキュリティに対してより全体的なアプローチを採用することは可能です。

ここでは、手元にあるツールを使って、この無限に広がる攻撃対象領域をどのようにコントロールするかを考えてみましょう。

ビジネスリスクのレベルについて現実的に考える（そして、何を受け入れるか）。

完璧なセキュリティは持続可能ではありませんが、目隠しをしてすべてが青空であるかのように装うこともできません。私たちは、組織が脆弱なコードを承知の上で出荷していることをすでに知っています。そして、明らかに、これは新機能や新製品の市場投入までの時間に基づいて計算されたリスクなのです。 

特にDevSecOpsが標準的な開発手法でないところでは、スピードのあるセキュリティは難しいものです。しかし、最近のLog4Shellエクスプロイトを見るだけで、コードの中の比較的小さなセキュリティ問題が、いかに攻撃の成功の機会を広げているかを発見し、低品質のコードを出荷するために計算されたリスクの結果が、予測よりもはるかに大きくなり得ることを知ることができる。

アクセス）コントロールフリークになることに慣れよう

クラウドストレージの設定不備によるデータ漏えいの被害は驚くほど多く、アクセス制御の誤りによる機密データ流出の可能性は、ほとんどの組織のセキュリティチームを悩ませ続けています。 

2019年、フォーチュン500社のFirst American Financial Corp.は、このことを身をもって知りました。認証ミス、つまり比較的簡単に修正できるものでしたが、銀行明細書、住宅ローン契約書、写真付き身分証明書など、8億件を超える記録が流出する事態となりました。これらの文書へのリンクは、ユーザー識別やログインを必要としないため、ウェブブラウザさえあれば誰でもアクセス可能な状態になっていました。さらに悪いことに、これらの文書には連番で記録されていたため、リンク先の番号が変わるだけで、新しいデータレコードが公開されることになりました。 

このセキュリティ問題は、メディアで取り上げられる前に社内で確認されていましたが、高リスクのセキュリティ問題として適切に分類されず、経営陣に報告して緊急に改善させることができなかったため、現在もその影響は続いています。

開発者は、認証と権限に関するベストプラクティスを自分のビルドで実行し、機密データの公開を保護するためのチェックと対策を確実に行うために、検証されたセキュリティ意識と実践的なスキルを必要としています。 

APIは、設計上、他のアプリケーションと非常におしゃべりであり、開発チームはすべての潜在的なアクセスポイントを可視化する必要があります。結局のところ、より安全なソフトウェアを提供するための探求において、未知の変数やユースケースを考慮することはできないのです。

セキュリティ・プログラムの分析：予防にどの程度重点を置いているか？

セキュリティ・プログラムの大部分をインシデント対応とその対応に割くことは理にかなっていますが、多くの組織では、セキュリティ・インシデントを未然に防ぐために利用できるすべてのリソースを活用しないことで、貴重なリスク最小化を見逃しています。

確かに、問題のあるバグの発見を支援する包括的なセキュリティツールのスタックはありますが、ほぼ50％の企業が、脆弱性があるとわかっているコードを出荷していることを認めています。しかし、クラウド、アプリケーション、API機能、組み込みシステム、ライブラリ、そして、広がり続けるテクノロジーの中で、コードを保護する必要があるという事実は、現在のアプローチでは常に一歩遅れていることを保証しています。

セキュリティバグは人間が引き起こした問題であり、ロボットにすべての修正を期待することはできません。もし、あなたの開発チームが効果的にスキルアップされていないのであれば、単に年に一度のセミナーではなく、適切な教育の積み重ねが必要であり、低品質のコードを標準として受け入れ、それに付随するセキュリティリスクを常に抱えていることになります。 

開発者の即戦力を過大評価していませんか？

開発者は、セキュアコーディングの能力について評価されることはほとんどなく、それは彼らの優先事項ではありません（多くの場合、KPIでもありません）。もし、より良い方法を示されないなら、あるいは、それが自分の成功の尺度であると言われないなら、彼らは、お粗末なセキュリティ慣行の犠牲になることはできない。 

しかし、組織内では、提供されたガイダンスが、一般的なセキュリティリスクを軽減するための準備として有効であると想定されていることがあまりに多いのです。セキュリティのベストプラクティスを適用するためのトレーニングやその意識によっては、エンジニアは、望ましい最初の防御線となる準備ができていないかもしれません（そして、ペンテスト報告書を詰まらせる無限のインジェクション欠陥を阻止する準備ができていないかもしれません）。 

理想的な状態は、複雑さを増す学習経路を完了し、その結果得られるスキルが、実世界で開発者のために実際に機能することを確認することです。しかし、そのためには、開発者のことを最初から考え、正しく使えるようにする文化的基準が必要です。もし私たちが業界として、自分たちで作り上げたこの広大なコードの風景を守るために荒野に出るのであれば、得られるすべての助けが必要です...そしてそれは、私たちが思っている以上に、目の前にあるのです。