エンタープライズスタックセキュリティに関しては、ソフトウェアアプリケーションが最も弱いリンクです。 の アプリケーションセキュリティの状態、2020、Forresterによると、外部からの攻撃の大部分は、ソフトウェアの脆弱性（42％）を悪用するか、Webアプリケーション（35％）を介して発生します。
開発者は、アプリケーションがより複雑になり、開発のタイムラインが短縮されるにつれて、できるだけ早く機能をリリースするよう圧力をかけられています。 差別化された魅力的なアプリケーション機能を実現するために、開発者はますますサードパーティのライブラリに依存しています。
このオープンソースコンポーネントへの移行により、 セキュリティ 企業にとってより複雑な慣行。 コンテナやAPIなどの新しいフレームワークは、アプリケーションのセキュリティをさらに複雑にします。
開発者は常に新機能をリリースするようにプレッシャーをかけられているため、組織はセキュリティが追いつかないという非常に現実的なリスクに直面しています。 セキュリティは、アプリケーションセキュリティのベストプラクティスをソフトウェア開発ライフサイクルに組み込み、それらを実装することで実現できます。
Webセキュリティテストが重要なのはなぜですか？
Webアプリケーションとその構成のセキュリティの脆弱性をテストすることが、Webセキュリティテストの目標です。 アプリケーション層の攻撃（つまり、HTTPベースのアプリケーションを標的とする）が主な標的です。
さまざまな種類の入力をWebアプリケーションに送信してエラーを引き起こし、予期しない動作をさせるのが一般的です。 これらのいわゆる「ネガティブテスト」では、システムは意図されていない動作がないか検査されます。
注意することも重要です。 Webセキュリティテスト アプリケーションに実装されているセキュリティ機能（認証や承認など）をテストするだけではありません。
また、他の機能（ビジネスロジック、入出力の検証など）が安全な方法で実装されていることをテストする必要があります。 Webアプリケーション機能への安全なアクセスが目標です。
さまざまな種類のセキュリティテストとは何ですか？
- 動的アプリケーションセキュリティテスト （DAST）。 規制上のセキュリティ評価に準拠するために、この自動化されたアプリケーションセキュリティテストは、内部向けの低リスクアプリケーションに最適です。 手動のWebセキュリティテストとDASTの組み合わせは、中リスクのアプリケーションとマイナーな変更が行われている重要なアプリケーションに最適なアプローチです。
- 静的アプリケーションセキュリティテスト （SAST）。 アプリケーションセキュリティテストへのこのアプローチは、手動と自動の両方で行われます。 アプリケーションは、実稼働環境で実行しなくても、この方法でテストできます。 さらに、開発者はソースコードをスキャンすることで、ソフトウェアのセキュリティの脆弱性を体系的に検出して排除できます。
- ペネトレーションテスト。 特に大きな変更が加えられているアプリケーションの場合、この手動のアプリケーションセキュリティテストは理想的です。 評価には、高度な攻撃シナリオを特定するためのビジネスロジックと攻撃者ベースのテストが含まれます。
- ランタイムアプリケーション自己保護（RASP）。 アプリケーションセキュリティへのこの進化するアプローチでは、攻撃の実行時に攻撃を監視し、理想的にはリアルタイムでブロックできるようにアプリケーションを計測するために、多くの技術的手法が使用されています。
アプリケーションセキュリティテストはどのように組織のリスクを軽減しますか？
Webアプリケーション攻撃の大部分
- SQLインジェクション手法
- クロスサイトスクリプティング（XSS）
- リモートでのコマンドの実行
- パストラバーサル
攻撃結果
- 制限されているコンテンツ
- 侵害されたアカウント
- 悪意のあるソフトウェアのインストール
- 収益が失われました
- 顧客は信頼を失う
- 風評被害
- だけでなく、はるかに
今日のWeb環境では、さまざまな問題が発生しがちです。 アプリケーションがどのように悪用されるかを知ることに加えて、攻撃の潜在的な結果を知ることは、企業が脆弱性に先制的に対処し、それらを正確にテストするのに役立ちます。
脆弱性の根本原因を特定した後、SDLCの初期段階で緩和制御を適用できます。 さらに、Webアプリケーションのセキュリティテストでは、これらの攻撃がどのように機能して既知の関心のあるポイントを標的にするかについての知識を利用できます。
企業のリスクを管理するには、攻撃の影響を理解する必要があります。これは、脆弱性の全体的な重大度を測定するために使用できるためです。
セキュリティテストの結果、検出された問題の重大度を判断することで、修復作業に効率的かつ効果的に優先順位を付けることができます。 重大な重大度の問題から始めて、影響の少ない問題に進むことにより、企業のリスクを最小限に抑えます。
問題を特定する前に、会社のアプリケーションライブラリにある各アプリケーションの潜在的な影響評価は、アプリケーションのセキュリティテストの優先順位付けに役立ちます。
Webセキュリティテストに注目を集めるアプリケーションのリストが確立されている場合、ビジネスに対するリスクを低減できるように、最初に企業の重要なアプリケーションを対象とするテストをスケジュールできます。
Webアプリケーションのセキュリティテスト中に確認する必要がある機能は何ですか？
Webアプリケーションのセキュリティテストでは、いくつかの機能を調べる必要がありますが、リストはすべてを網羅しているわけではありません。 それぞれの不適切な実装により、組織は深刻なリスクにさらされる可能性があります。
- アプリケーションとサーバーの構成- 欠陥は、暗号化構成、Webサーバー構成などに関連している可能性があります。
- 入力検証とエラー処理- SQLインジェクションやクロスサイトスクリプティング（XSS）など、最も一般的なインジェクションの脆弱性は、入力と出力の処理が不十分なために発生します。
- 認証とセッション管理- 脆弱性は、ユーザーのなりすましにつながる可能性があります。 強力な資格ポリシーも不可欠です。
- 承認- 垂直方向および水平方向の特権昇格を防ぐアプリケーションの機能を確認します。
- ビジネスの論理- このタイプのロジックは、ほとんどのビジネスアプリケーションに不可欠です。
- クライアント側のロジック- このタイプの機能は、JavaScriptを多用する最新のWebサイトや、他のクライアント側テクノロジ（Silverlight、Flash、Javaアプレットなど）を使用するWebサイトで一般的になりつつあります。
Webアプリケーションセキュリティのトップ10のベストプラクティス
以下は、組織がすでに実装している必要があるアプリケーションセキュリティのベストプラクティスのトップXNUMXです。
＃1あなたの資産を追跡する
自分が何を持っているかわからなければ、それを守ることはできません。
どの機能またはアプリに特定のサーバーを使用していますか？ どのWebアプリでオープンソースコンポーネントを使用していますか？
資産を追跡することは重要ではないと思いますか？ 各アプリケーション内で実行されているソフトウェアを覚えておくことは非常に重要です。700億145万人を超える顧客のデータを保護できなかったためにXNUMX億ドルの罰金を科されたEquifaxに聞いてみてください。
オープンソースコンポーネントであるApacheStrutsにパッチが適用されなかったため、信用格付け機関の顧客WebポータルのXNUMXつが侵害されました。 同社によれば、顧客ポータルが脆弱なオープンソースコンポーネントを使用していることに気付いていなかったという。
資産の追跡を開始するのが早ければ早いほど、後で発生する頭痛や災害は少なくなります。 組織が開発を拡大するにつれて、このプロセスはシーシュポスの仕事のように感じることがあります。
また、資産を分類する必要があります。ビジネスの機能にとって重要な資産とそれほど重要ではない資産に注意してください。 次に、脅威を評価し、後で修正できます。
＃2脅威評価を実行する
保護する必要があるもののリストを作成すると、直面している脅威とそれらを軽減する方法を特定できます。
ハッカーはどのようにしてアプリケーションに侵入することができますか？ どのような既存のセキュリティ対策を実施していますか？ どのような追加のツールが必要ですか？
脅威評価の一環として、これらの質問やその他の質問に答える必要があります。
ただし、享受できるセキュリティのレベルについても現実的である必要があります。 システムをどれほど安全にしたとしても、それをハッキングすることができます。 さらに、チームが長期にわたって維持できる対策について正直である必要があります。
過度にプッシュすると、セキュリティ基準と慣行が無視されるリスクがあります。 セキュリティを真剣に受け止め、急がないでください。
次の式を使用して、リスクを評価します。
リスク=攻撃の確率x攻撃の影響。
リスクは、何かが起こる確率と結果の重大度を比較したものと考えることもできます。
クジラが空から落ちてあなたを押しつぶすと壊滅的ですが、それが起こる可能性は低いです。
一方、ハイキングで蚊に刺される可能性は非常に高いですが、かゆみを伴ういくつかの隆起を超えて重大な害を及ぼす可能性はほとんどありません。
＃3パッチを常に把握する
オペレーティングシステムに最新のパッチをインストールしますか？ サードパーティのソフトウェアを使用していますか？ 遅れている可能性があります。つまり、露出しているということです。
ソフトウェアのセキュリティを確保するために実行する必要がある最も重要な手順のXNUMXつは、商用ベンダーまたはオープンソースコミュニティからソフトウェアを更新することです。
脆弱性が発見され、製品またはプロジェクトの所有者に責任を持って報告されると、セキュリティアドバイザリサイトおよびWhiteSource VulnerabilityDatabaseなどのデータベースに公開されます。
可能であれば、公開前に修正プログラムを作成してリリースし、ユーザーにソフトウェアを保護する機会を提供する必要があります。
ただし、パッチが利用可能になったときにパッチを適用しないと、セキュリティの向上によるメリットは得られません。
最新バージョンに更新すると製品が破損する可能性があることを心配している場合は、 自動化されたツール 大いに役立つことができます。 曜日を問わず、アプリケーションのセキュリティのベストプラクティスの一環として、更新とパッチ適用を優先する必要があります。
＃4コンテナを管理する
近年、コンテナは、ソフトウェア開発ライフサイクル（SDLC）全体でさまざまな環境にコンポーネントを開発、テスト、および展開するプロセスを簡素化する柔軟性により、より多くの組織がテクノロジを採用するにつれて人気が高まっています。
コンテナには、利点をもたらすセキュリティ上の利点があることが一般的に認められています。 さらに、自己完結型のOS環境のため、設計によってセグメント化されているため、リスクのレベルが低くなります。
それでも、コンテナは、分離が破られたブレイクアウト攻撃などのエクスプロイトに対して脆弱なままです。 コンテナには、コンテナ内に保存されているコードに脆弱性が含まれている場合もあります。
CI / CDパイプラインのセキュリティについては、レジストリを含め、最初から最後まで脆弱性をスキャンする必要があります。
これらのスキャンに加えて、コンテナーを操作する際のアプリケーションセキュリティのベストプラクティスには、DockerHubを使用している場合はDockerContent Trust、チームが使用している場合はShared AccessSignatureなどのツールを使用して独自のイメージに署名するなどの重要なタスクも含まれます。 Microsoft Azure.
＃5修復操作の優先順位付け
近年、脆弱性の数が増加しており、この傾向はすぐに減速する兆候を示していません。
その結果、開発者は修復に忙しくなります。 正気を保ちながらアプリケーションを安全に保つことを望んでいるチームにとって、優先順位付けは不可欠です。
脅威の評価は、脆弱性の重大度（CVSS評価）、影響を受けるアプリケーションの重要度、およびその他の多くの要因に基づいて実行されます。
オープンソースの脆弱性に関しては、オープンソースの脆弱性がプロプライエタリコードに実際に影響を与えるかどうかを知る必要があります。
製品からの呼び出しを受け取らない場合、脆弱なコンポーネントのCVSSレーティングが重要であっても、効果がなく、リスクは高くありません。
スマート戦略とは、存在する要因に基づいて最も差し迫った脅威を最初に優先し、リスクの低いものを後で使用する戦略です。
＃6暗号化、暗号化、暗号化
OWASPトップ10には、保存中および転送中のデータの暗号化が何年にもわたって含まれているため、アプリケーションセキュリティのベストプラクティスリストの要件となっています。
中間者攻撃やその他の形態の侵入は、トラフィックを適切にロックダウンできない場合に機密データを公開する可能性があります。
ときにあなたを パスワードを保存する たとえば、プレーンテキストのユーザーIDは、顧客を危険にさらします。
暗号化の基本的なチェックリストの一部として、更新された証明書でSSLを使用していることを確認してください。 HTTPSが標準になっているので、取り残されないでください。 ハッシュもお勧めします。
さらに、彼らが言うように、あなたは決して「あなた自身の暗号を転がす」べきではありません。 仕事を正しく行うための経験を持つ専任チームによってサポートされているセキュリティ製品を検討してください。
＃7特権の管理
組織内のすべての人にすべてへのアクセスを許可する必要はありません。 アプリケーションとデータには、ネットワークセキュリティのベストプラクティスとアプリケーションセキュリティのベストプラクティスに従うことで、それらを必要とする人だけがアクセスできます。
これにはXNUMXつの理由があります。 最初に行う必要があるのは、ハッカーがマーケティングクレデンシャルを使用して、財務や法務などの他のより機密性の高いデータを含むシステムにアクセスするのを防ぐことです。
ラップトップを紛失したり、電子メールに間違った添付ファイルを送信したりするなど、意図的でないものであれ、悪意のあるものであれ、内部の脅威も懸念事項です。
データへのアクセスに関して必要なデータのみを従業員に提供するという最小特権の原則は、統制が整っていない場合と比較して、露出を減らすことができます。
＃8脆弱性管理のための自動化の採用
アプリケーションのセキュリティは、特に脆弱性管理などのタスクに関して、過去数年間で開発者にとってますます重要になっています。
セキュリティの左シフトに対処するために、開発者チームは早期に頻繁にテストを行い、脆弱性の修正がより簡単で安価な開発プロセスの早い段階でセキュリティチェックをできるだけ多くプッシュしています。
膨大な量の脆弱性による扱いにくいテストプロセスを管理するために、開発者は自動化されたツールを必要としています。
独自のコードの潜在的なセキュリティの脆弱性を見つけるために、静的アプリケーションセキュリティテスト（SAST）と動的アプリケーションセキュリティテスト（DAST）を開発中に使用できます。
セキュリティホールはSASTとDASTで閉じられますが、プロプライエタリコードはコード全体の比較的小さな部分を占めます。
最新のアプリケーションの92％以上で、オープンソースコンポーネントがコードベースの60〜80％を占めています。 アプリケーションのセキュリティチェックリストでは、オープンソースコンポーネントの保護を優先する必要があります。
チームは、ソフトウェア構成分析ツールを使用して、SDLC全体で自動化されたセキュリティチェックとレポートを実行し、環境内の各オープンソースコンポーネントを特定し、アプリケーションにセキュリティリスクをもたらす既知の脆弱性があるコンポーネントを示します。
オープンソースのセキュリティ問題の自動テストを左にシフトすることで、脆弱性をより適切に管理できます。
＃9侵入テスト
自動化されたツールがセキュリティ問題の大部分を捕らえるのに役立つとしても、トップアプリケーションセキュリティのベストプラクティスリストは、侵入テストに言及しないと不完全です。
ペンと紙でテストすることで、弱点を見つけるためにアプリを突いたり、プロデュースしたりすることができます。 決心したハッカーがアプリケーションに侵入しようとした場合、優れたペンテスターは自分が実行する必要のある手順を正確に把握しています。
ハッキング会社を雇うことも、フリーランサーがBugCrowdやHackerOneなどのバグ報奨金プログラムに参加することもできます。 まだ行っていない場合、あなたの会社はバグ報奨金を後援する必要があります。
ペンテスターを雇う場合、実際の違反の結果に対処するよりも、彼らにお金を払うほうがはるかに良いです。
＃10トークンに注意する
これは簡単に保護できるものですが、多くの開発者はサードパーティのトークンを適切に保護していません。
人気のある開発者のWebサイトを検索することで、セキュリティで保護されていないトークンをオンラインで簡単に見つけることができます。 トークンの詳細を他の場所に保存する代わりに、開発者はそれらをオープンソースリポジトリに含めるだけです。
基本的なアプリケーションセキュリティのベストプラクティスは、サードパーティのトークンを適切に保護することです。 購入したトークンをコード内に置いたままにして、だれにも取ってはいけません。
基本的なプラクティスとしてのアプリケーションセキュリティのベストプラクティス
ここで概説する各ベストプラクティスは、組織の継続的な開発プロセスに統合する必要があります。 リスクを最小限に抑えないと、会社のアプリケーションとデータが危険にさらされます。 リスクを最小限に抑えるために、次の手順に従ってください。
他の人が犯しがちな間違いを回避することは、ハッカーに先んじるXNUMXつの方法であるため、攻撃の標的になりにくくなります。 完全にハッキングされない境界またはアプリケーションのセキュリティ対策はありません。
ただし、これらの基本的なベストプラクティスに従うことは、アプリケーションをハッカーにとって問題の価値がない状態に保つのに大いに役立ちます。
