ハッカーはWebアプリケーションをターゲットにしています。これを阻止するためにはどうすればよいでしょうか。まず優先順位を設定しましょう。
私たちの多くが（時には苦い経験を通じて）学んだように、優先順位を設定することは成功の基本です。
ですから、当然ながら、デジタル資産のセキュリティ保護についても優先順位の設定が基本になります。そのためには、自分が持っているもの（したがって、保護する必要があるもの）のカタログを作成する必要があります。システムに侵入しようとしているハッカーに対してどの「アタックサーフェス」が目立っているかを把握する必要があります。そして、攻撃者を締め出すために適切なツールを使用する必要があります。
幸い、こうしたことはすべて可能ですが、ちょっとした時間、労力、そして投資が必要です。
Webアプリケーションは最も一般的なアタックサーフェス
ハッカーのお気に入りのアタックサーフェスになっても不思議はありません。データ侵害に関する複数のレポートで明らかになっているように、Webアプリケーションが最優先事項です。
Forresterの2019年版「The State of Application Security」は、作成者Amy DeMartineの次の言明で始まります。「アプリケーションの弱点とソフトウェアの脆弱性は、サイバー犯罪者が外部からの攻撃を行う最も一般的な手段であり続けています。」
最新のVerizonデータ漏洩/侵害調査報告書（DBIR）によると、Webアプリケーションはレポート対象となる9業種のうち8業種において攻撃ベクトルのトップ3に入り、4業種で1位になっています。
また、SAP によると、サイバー攻撃の84%がアプリケーション層で発生し、ハッカーにとって最大のアタックサーフェスとなっています。
安全でないWebアプリケーションがハッカーに対する扉を開く
Webアプリケーションがターゲットになっても何の不思議もありません。Webアプリケーションの脆弱性を悪用できれば、攻撃者には無制限にアクセスできる可能性が生じます。「脆弱性や弱点を利用してアプリケーションを悪用する悪意のある攻撃者は、どのようなデータセキュリティやネットワーク保護を実施しても、そのアプリケーションがアクセスできるデータならアクセスが可能です」とDeMartine氏はレポートの中で指摘しています。
もちろん、オンラインでの存在感があるすべての企業がWebアプリケーションを有しています。こうしたアプリケーションはソフトウェアで構築されています。そして、ソフトウェアが完璧であることは稀だということをハッカーは知っています。また、バグやその他の脆弱性に対してパッチが発行されても、すべての組織がそれをインストールするわけではないこともわかっています。
おそらく、過去数年の最も悪名高い例として知られる2017年の大手消費者信用情報会社Equifaxに対する侵害では、約1億4,700万人の個人情報と財務情報が侵害されましたが、これは、広く利用されているオープンソースWebフレームワークであるApache Strutsの脆弱性に対する2か月前のパッチを同社がインストールしていなかったために可能になりました。
しかし、このような事件が起こってもまだ、企業に対する十分な注意喚起にはなりませんでした。2018年のSynopsysオープンソース・セキュリティ＆リスク分析（OSSRA）レポートでは、9か月後になっても、監査対象となったApache Strutsを含むコードベースの3分の1に、Equifaxに影響を及ぼしたものと同じ問題に対して依然として脆弱性が存在していることがわかりました。
ハッカーからWebアプリケーションを守る方法
ですから、最優先事項は明らかに Webアプリケーションを守ることです。
それにはさまざまな方法があります 。重要なことは、方法は1つではなく、「さまざまな方法」があるということです。この魔法の「オールインワン」ツールを採用すればアプリケーションは安全、という売り文句に騙されてはいけません。
実生活にもオンラインの世界にも、絶対的な安全はありません。しかし、ソフトウェア開発ライフサイクル（SDLC）全体にわたって適切なツールセットを導入すれば、少なくとも並外れた意欲と専門知識を持つハッカー以外からはWebアプリケーションを保護できます。
ソフトウェア・コンポジション解析でコードの内容を把握する
まず、使用しているソフトウェア・コンポーネントと、そのコンポーネントの発生元を把握しておくと役立ちます。多くの組織は自社のソフトウェアを開発していますが、OSSRAによると、ほとんど（99%）の組織がオープンソースも使用しています。
それ自体には問題はありません。オープンソースはアプリケーション開発の時間と費用を削減するために役立ちます。オープンソースは既製の「原材料」を提供してくれるので、開発者は新しいアプリケーションを作成するたびに基礎から開発し直す必要がありません。
しかし、オープンソースは他のソフトウェアと比べて特に安全なものではなく、ライセンス要件も伴います。つまり、使用しているオープンソースを把握していない組織では、既知の脆弱性に対して利用可能なパッチがあるという通知を見逃す可能性があります。また、オープンソースライセンス違反の法的トラブルに巻き込まれる可能性があります。
こうしたことすべてを回避する方法として、ソフトウェア・コンポジション解析（SCA）があります。SCAを用いて、分析とポリシーの適用を自動化することで、オープンソースのセキュリティおよびライセンス・コンプライアンスのリスクを管理できます。
SDLCの早い段階にSCAを移行することが重要であり、それによって問題の解決をより容易に、迅速に、かつ低コストに実現できます。
完全なアプリケーション・セキュリティ・ツールベルトでWebアプリケーションのセキュリティの問題を見つけて修正する
SDLCに組み込む必要があるその他のツールには、次のものがあります。
- 静的アプリケーション・セキュリティ・テスト（SAST）を利用することにより、独自開発コードの開発段階でセキュリティおよび品質の弱点を発見し修正することができます。前述のForresterレポートによると、開発段階でSASTを実装する可能性が高い企業が増えています。開発者がコードをIDEで「スペルチェック」できる新しいツールを使用すると、セキュリティ担当者がSDLCの低コストで修正しやすい段階で開発者に修正アドバイスを提供するために役立ちます。
- 動的アプリケーション・セキュリティ・テスト（DAST）は、実稼働環境をシミュレートした環境で実行中のアプリケーションをテストします。
- インタラクティブ・アプリケーション・セキュリティ・テスト（IAST）は、実行中のアプリケーションの自動テストにより脆弱性や重要データのリーケージを発見・検証します。
- ペネトレーション・テストは、ほとんどの脆弱性が捕捉され、修正されたと思われる段階になってから、開発の終了を目的に行われます。ペネトレーション・テストでは、探索的なリスク解析とビジネス・ロジックに焦点を当て、WebアプリケーションやWebサービスに潜む脆弱性を発見してエクスプロイトを試みます。
このようなさまざまなアプリケーション・セキュリティ・テストツールを展開するのは困難に思えるかもしれませんし、開発チームは遅滞が生じるのではないかと懸念するでしょう。しかし、実際には、SDLC の初期段階で脆弱性を見つけて修正する方が全体的には容易かつ低コストです。
それ以上に、Forresterが指摘するように、自動化は「セキュリティテストの採用を容易にする」ことに役立ちます。
「SDLCが自動化されていると、アプリケーションのリリース前テストの自動化は比較的容易になるため、開発チームがこの方向に進むとセキュリティ担当者は目に見えて負担の軽減を実感できます」
テストの自動化で助かるのは開発者だけはありません。最も一般的な攻撃ベクトルの攻撃に対する耐性が強化されることにより、組織全体の利益にもなります。
Continue Reading
2024 OSSRA レポート：オープンソース・コンポーネントの古いコードのリスク
Apr 17, 2024 / 1 min read
