リックソフトでは、オープンソースの脆弱性管理・コンプライアンス管理ツールであるWhiteSourceを販売しています。

今やOSSライセンスを使ったソフトウェア開発は90%以上とも言われている中で、これらの管理をスプレッドシートを使い手作業で確認をしている方々に是非こちらのブログをお読みいただき、WhiteSourceのツールに興味を持っていただけたらと思っています。

本ブログはWhiteSorce社に了承を得て翻訳をしたものになります。
これから6回にわたりお届けをしていきます。

第1回目は「アプリケーションセキュリティのベストプラクティス：トップ10」です。

■アプリケーションセキュリティのベストプラクティス：トップ10

エンタープライズ全体のセキュリティを考えたときに、一番の弱点として挙げられるのがソフトウェアアプリケーションです。
Forresterのレポート『The State of Application Security, 2020』によると、外部からの攻撃の大半は、ソフトウェア脆弱性の悪用（42%）と、Webアプリケーションを介した攻撃（35%）の2つです。

※Forrester『The State Of Application Security, 2020』に基づくデータ

アプリケーションの複雑化とソフトウェア開発の短期化が進むなか、開発者には新しい機能をできるだけ早くリリースするというプレッシャーがかかっています。

このため、開発者は、他社製品と差別化された魅力的なアプリケーション機能の実現を目指して、サードパーティ製ライブラリ、特にオープンソースコンポーネントに頼ることが多くなっています。
こうしてオープンソースコンポーネントが増えたことにより、組織はセキュリティ対策の方法を変えざるを得なくなっています。

また、コンテナなどの新しいフレームワークやAPIがアプリケーションセキュリティの複雑化を助長しているという状況もあります。

新機能を継続的にリリースすることを開発者に求めれば、組織にはセキュリティを維持できなくなるというリスクがまさに現実のものとして迫ってきます。

組織がソフトウェアのセキュリティを維持するためにできることの1つが、アプリケーションセキュリティのベストプラクティスを取り入れ、現行のソフトウェア開発ライフサイクルに統合することです。

この目標に向けて、今回は、組織がすぐにでも取り入れるべきベストプラクティスのトップ10を紹介します。

【No.1 アセットの存在を把握する】

企業が何を所有しているのかを知らなければ、それを守ることはできません。

どのサーバーでどの機能またはアプリケーションを使用しているか知っていますか。
各種のWebアプリにはどのようなオープンソースコンポーネントが含まれていますか。

アセットの存在を把握することの重要性を軽視しないでください。
Equifaxの件を例に挙げると、Equifaxは、1億4,500万人分を超える顧客データを保護できず、7億ドルの支払いを命じられました。
これは、どのソフトウェアがどのアプリケーションで動いているのかを把握することがいかに大切かを教えてくれています。

この信用格付け会社で発生した情報漏えいの原因は、顧客向けWebポータルの1つで使われていたApache Strutsオープンソースコンポーネントに脆弱性の修正パッチを適用していなかったことでした。
Equifaxは、脆弱性を含むそのオープンソースコンポーネントが顧客向けポータルで使われていることを認識していなかったと説明しています。

アセットの存在を今しっかりと把握しておくことは、今後の問題や惨事の予防になります。
しかし、組織が開発を拡大するにつれて、こうした作業は際限のないものに思えるので、プロセスをできる限り自動化することが必要です。

【No.2 脅威評価を行う】

保護すべき対象の一覧ができたら、企業にとって脅威は何か、取るべき対策は何かを明確にしていきます。

ハッカーはアプリケーションにどのような経路で侵入する可能性がありますか。
攻撃の検出や予防のために導入しているセキュリティ対策がありますか。
ツールを増やしたり、別のツールに変えたりする必要はありますか。

脅威評価では、上記のような質問を始めとして、多くのことを検討する必要があります。

しかし同時に、どの程度のセキュリティを確保すべきか現実的に想定することも必要です。
利用可能なあらゆるものを使って最高レベルの保護対策を採っても、絶対に「ハッキング不可能」にすることはできません。

また、どのような種類の対策であればチームが長期間継続できるかを過度な期待をせずに考える必要もあります。
あまり多くのことを求めると、結局はセキュリティ基準や実施手順が無視されることになります。

セキュリティは、短距離走ではなく、長距離走であると心得ましょう。

リスクの評価には、以下のような基本的な計算式を使用できます。
　【 リスク = 攻撃の可能性 x 攻撃の影響 】

リスクについての考え方としては、何かが起こる確率と、それが起こったときの被害の程度を合わせて検討する方法もあります。
クジラのような大きなものが空から降ってきて、それが自分を直撃する可能性は極めて低いですが、もしそれが起これば大惨事です。

反対に、ハイキングに出掛けて蚊に刺される可能性はかなり高いですが、刺されたとしても大きな被害はありません。
せいぜい、多少の腫れとかゆみ程度です。

【No.3 パッチ適用で後れを取らない】

オペレーティングシステムに最新バージョンのパッチを適用していますか。
サードパーティ製のソフトウェアについてはどうですか。

パッチ適用が遅れているとすれば、あなたの組織は危険にさらされています。

製品ベンダーからのパッチであっても、オープンソースコミュニティからのパッチであっても、ソフトウェアにパッチを適用して更新を行うことは、ソフトウェアのセキュリティ対策として特に重要なことの1つです。

善意で発見された脆弱性は、製品やプロジェクトの管理者に報告され、その後、セキュリティ勧告やWhiteSource脆弱性データベースなどのデータベースで公開されて一般に周知されます。
公開される前に修正プログラムが作成、配布され、ユーザーにソフトウェアの安全を守る機会が与えられることが理想的です。

しかし、配布されたパッチを適用しなければ、セキュリティを改善する最終手順を実施していないことになります。

開発者は、製品に支障をきたす可能性から、ソフトウェアを最新バージョンにアップグレードすることをためらうかもしれませんが、そうした場合には自動化ツールが大いに役立ちます。
アプリケーションセキュリティのベストプラクティスの中では、更新とパッチ適用を常に優先するべきです。

【No.4 コンテナを管理する】

この数年、コンテナの人気が高まっています。
この技術の柔軟性により、構築から、テスト、デプロイまでのSDLC全体を多様な環境で行うことが容易になるため、コンテナを活用する組織が増えています。

一般的に、コンテナにはセキュリティ上のメリットがあると考えられており、このメリットがコンテナの人気を高めています。

自己完結型のOS環境があり、設計の時点から分割されているため、他のアプリケーションに対するリスクレベルは低くなります。
とはいえ、この分離性を崩してコンテナの境界を突破していく「ブレークアウト」攻撃などを仕掛けられるリスクはあります。

また、コンテナ内に保存されているコードそのものに脆弱性がある可能性もあります。

CI/CDパイプラインの全体でコンテナの使用を安全に守るには脆弱性の自動スキャンを実行します。
自社独自コードかオープンソースかを問わず、端から端まで、レジレジストリも含めたすべてを対象にスキャンをする必要があります。

こうしたスキャンに加えて、コンテナを扱う際のアプリケーションセキュリティのベストプラクティスとしては、イメージに署名をするなどの対策も重要です。
ツールとしては、Docker Hubを使っている場合はDocker Content Trust、マイクロソフトのAzureの場合はShared Access Signatureなどを使用できます。

【No.5 修正作業に優先度を付ける】

最近、脆弱性の件数は増えており、この勢いがすぐに弱まりそうな気配はどこにもありません。
開発者のスケジュールは修正作業の予定で埋め尽くされています。

目の前にある作業量を考えた場合、チームの健全な状態を保ちつつアプリケーションセキュリティを維持するには、優先順位付けが必要です。

優先順位を付けるには、脅威評価を行う必要があります。

脆弱性の重大度（CVSS評価）に基づき、影響を受けるアプリケーションの業務に対する重要性なども含めてさまざまな点を評価します。
オープンソースの脆弱性の場合は、オープンソースコンポーネント内の脆弱とされた機能を自社独自のコードが実際に使用しているかどうかも調べる必要があります。

脆弱なコンポーネントの機能が自社製品から呼び出されていなければ、CVSS評価で重大とされていても、脆弱性の影響はなく、大きなリスクにはなりません。

賢い戦略の1つは自動での優先順位付けです。
さまざまな要素を考慮して、最も切迫している脅威を最初に位置付け、リスクの低いものは後に回します。

【No.6 暗号化、暗号化、暗号化】

暗号化は、Webアプリケーションセキュリティの10大リスクをまとめたOWASP Top 10に何年もランキングされ続けています。

アプリケーションセキュリティのどのベストプラクティス集でも、デ暗号化は、Webアプリケーションセキュリティの10大リスクをまとめたOWASP Top 10に何年もランキングされ続けています。
アプリケーションセキュリティのどのベストプラクティス集でも、データを保管時、移動時を問わず暗号化することは必須とされます。

通信を適切に遮断することができなかった場合、秘密データは中間者攻撃やその他の侵害にさらされることになります。

たとえば、ユーザーIDとパスワードなど、顧客を危険にさらすような情報をプレーンテキスト形式で保存していたとしたら、そうした情報を危険にさらしていることになります。

暗号化に関する基本的なチェックリストには、SSLを最新の証明書と共に使用しているかを確認する項目も含めます。
最近、HTTPSは標準となってきているので、遅れずに対応するようにしましょう。
ハッシュ化も良い考えです。

また、よく言われているように、暗号を自作してはいけないということも覚えておいてください。
セキュリティ製品を活用します。
専門チームが存在し、確かな稼働実績のある製品を選びましょう。

【No.7 権限を管理する】

組織内のすべての人が、すべての情報にアクセスする必要があるわけではありません。

アプリケーションセキュリティのベストプラクティスとして、またネットワークセキュリティからも同じですが、アプリケーションおよびデータへのアクセスは必要とする人だけに限定します。

これには2つの理由があります。

まず、ハッカーが営業部の誰かの認証情報を使ってシステムにアクセスした場合、ほかの秘密データ、たとえば財務部や法務部のデータへのアクセスを防ぐ必要があります。
さらに、内部のからの脅威への対策にもなります。

悪意のある行為にも有効ですが、ノートPCを紛失する、誤ったファイルをメールに添付するなど、故意ではない場合にも有効な対策となります。
権限を管理し、従業員にはそれぞれが必要とするデータへのアクセスだけを許可するという最小権限の原則に従うことで、何も制御していない場合に比べて攻撃の可能性を軽減することができます。

【No.8 脆弱性管理に自動化を活用する】

最近は、アプリケーションセキュリティに関して開発者が持つ責任が大きくなってきています。

特に、脆弱性管理のような作業ではその傾向があります。
セキュリティのシフトレフトが進むにつれて、開発者チームが早期かつ頻繁にテストを実施するようになり、多くのセキュリティチェックも、脆弱性の修正が容易で低コストに済む開発の早い段階に前倒しされています。

脆弱性は大量になるので、開発者は自動化ツールを使って、肥大化するテストプロセスをうまく進める必要があります。

開発時に自社独自のコードをテストする場合は、静的アプリケーションセキュリティテスト（SAST）と動的アプリケーションセキュリティテスト（DAST）がコード内の隠れた脆弱性の発見に役立ちます。
SASTとDASTは、セキュリティホールをふさぐという意味で重要な役割を果たします。

しかし、自社独自のコードはコードベース全体の比較的少ない割合しか占めていません。

オープンソースコンポーネントは、一般的に、現在のアプリケーションの92%を超える割合で、コードベースの60%～80%を占めます。
このため、アプリケーションセキュリティのチェックリストでは、オープンソースコンポーネントのセキュリティ対策を優先事項の上位に置く必要があります。

SDLCの中で自動セキュリティチェックとレポート生成を行う場合は、ソフトウェア構成分析（SCA）ツールが役立ちます。
こうしたツールは、環境内のオープンソースコンポーネントをすべて洗い出し、アプリケーションを危険にさらす既知の脆弱性を含むコンポーネントがないかを調べます。

オープンソースセキュリティの問題を見つける自動テストをシフトレフトすることにより、脆弱性への対応を改善できます。

【No.9 侵入テスト】

自動テストは、リリース前に多くのセキュリティの問題を見つけ出すのに役立ちますが、セキュリティに関するどのベストプラクティス集でも、侵入テストの必要性に触れています。

侵入テストの実施者は、コードをくまなく調査し、アプリケーションの中に入り込んで弱点を見つけ出します。
有能な実施者は、忍耐強いハッカーがアプリケーションに侵入するときに何を試みるのかを正確に把握しています。

ハッキング対策を専門とする企業と協力することもできますが、HackerOneやBugCrowdなどのバグ報奨金制度を通じて、賞金獲得のために個人で脆弱性を探すフリーランサーを頼ることもできます。
自社製品についてまだバグ報奨金を設けていない場合は、この制度を始めることをお勧めします。

侵入テストを実施してもらうには費用がかかりますが、悪質な侵害の被害に遭うより、正義のハッカーに侵入を試みてもらう方が賢明です。

【No.10 トークンに注意する】

これはセキュリティ対策としては簡単なものですが、驚くことに、多くの開発者がサードパーティ製サービスのトークンに適切なセキュリティ対策を施していません。

残念なことに、有名な開発者Webサイトを検索すると、安全に保護されていないトークンをオンラインで簡単に見つけられます。
開発者はトークンの詳細を、安全な場所に保管するのではなく、単純にオープンソースのリポジトリに保存することがあります。

サードパーティトークンのセキュリティを適切に確保することは、アプリケーションセキュリティの基本的なベストプラクティスです。
料金を払ったトークンを、ほかの人がいつでも取れるような状態でコードの中に放置しないでください。

■まとめ

アプリケーションセキュリティのベストプラクティスを基本プラクティスとするアプリケーションセキュリティのベストプラクティスとしてここに挙げたものはいずれも、組織の継続的な開発プロセスの一部とすべきプラクティスです。

今回は、会社のアプリケーションとデータのリスクを最小限に抑えるために必要な対策のうち、本当に最低限のものだけを紹介しました。

ハッカーたちに侵入されないようにするには、多くの場合、ほかの人が犯しがちなよくあるミスを自分は犯さないように心掛けることが大切です。
それによって、「ほかよりも攻撃しにくいターゲット」になることができます。

周辺環境でもアプリケーションでも、すべてのハッキングを完全に防げるようなセキュリティ対策はありません。
ここに挙げた基本的なベストプラクティスに従うことで、攻撃しても割に合わないアプリケーションだとハッカーたちの攻撃する気をなくさせることができます。

これによって自分自身とデータを、一日一日、安全に守ることにつながります。