DevSecOps に対する恐怖と嫌悪

2 つのコード アナライザー、4 つの動的テスト ツール、独自のクラフト、250 のスクリプトがありました。 現在のプロセスでこれらすべてが必要というわけではありませんが、DevSecOps の実装を開始したら、最後まで実行する必要があります。

ソース。 キャラクタークリエイター: Justin Roiland と Dan Harmon。

SecDevOps とは何ですか? DevSecOps についてはどうですか? 違いは何ですか? アプリケーションセキュリティ - それは何ですか? なぜ古典的なアプローチはもう機能しないのでしょうか? これらすべての質問に対する答えを知っています 百合シャバリン の ソードフィッシュセキュリティ。 ユーリはすべてに詳細に答え、古典的なアプリケーション セキュリティ モデルから DevSecOps プロセスへの移行の問題を分析します。安全な開発プロセスを DevOps プロセスに統合し、何も壊さずに適切にアプローチする方法、主要な段階を通過する方法などです。セキュリティ テストの概要、使用できるツールとそれらの違い、落とし穴を避けるためにそれらを正しく設定する方法について説明します。

スピーカーについて: ユリ・シャバリン - 社内のチーフセキュリティアーキテクト カジキのセキュリティ。 SSDL の実装と、アプリケーション分析ツールの統合された開発およびテスト エコシステムへの全体的な統合を担当します。 情報セキュリティ分野で 7 年の経験。 ソフトウェア開発とサービスを提供するAlfa-Bank、Sberbank、Positive Technologiesに勤務。 国際会議 ZerONights、PHDays、RISSPA、OWASP で講演。

アプリケーションセキュリティ: それは何ですか?

アプリケーションのセキュリティ - アプリケーションのセキュリティを担当するセキュリティセクションです。 これはインフラストラクチャやネットワーク セキュリティには当てはまりません。むしろ、私たちが作成する内容や開発者が取り組む内容に当てはまります。これらはアプリケーション自体の欠点や脆弱性です。

方向 SDLまたはSDLC  - セキュリティ開発ライフサイクル - マイクロソフトによって開発されました。 この図は標準的な SDLC モデルを示しています。このモデルの主なタスクは、要件からリリース、運用に至る開発のあらゆる段階でセキュリティが参加することです。 Microsoft は、業界にはバグが多すぎること、さらに多くのバグがあることを認識し、それに対して何らかの措置を講じる必要があることを認識し、このアプローチを提案し、これが標準となっています。

アプリケーション セキュリティと SSDL は、一般に信じられているように、脆弱性を検出することを目的としたものではなく、その発生を防ぐことを目的としています。 時間の経過とともに、Microsoft の標準的なアプローチは改善、開発され、より深く、より詳細な調査に導入されてきました。

正規の SDLC は、OpenSAMM、BSIMM、OWASP など、さまざまな方法論で非常に詳細に説明されています。 方法論は異なりますが、一般的には似ています。

成熟度モデルでのセキュリティの構築

一番好きです ビシム  - 成熟度モデルでのセキュリティの構築。 この方法論の基礎は、アプリケーション セキュリティ プロセスをガバナンス、インテリジェンス、SSDL タッチポイント、展開の 4 つのドメインに分割することです。 各ドメインには 12 のプラクティスがあり、112 のアクティビティとして表されます。

112 のアクティビティのそれぞれには、 3つの成熟度レベル: 初心者、中級者、上級者。 12 のプラクティスすべてをセクションごとに学習し、自分にとって重要なものを選択し、それらを実装する方法を見つけて、静的および動的コード分析やコード レビューなどの要素を徐々に追加できます。 選択した活動の実施の一環として、計画を書き留め、それに基づいて冷静に取り組みます。

DevSecOps を選択する理由

DevOps は、セキュリティを考慮する必要がある一般的な大規模なプロセスです。

当初は DevOps セキュリティチェックが含まれていました。 実際には、セキュリティ チームの数は現在よりもはるかに少なく、プロセスの参加者としてではなく、要件を課し、リリースの最後に製品の品質をチェックする管理および監督機関として機能していました。 これは、セキュリティ チームが開発から背後にいて、プロセスに参加しなかった古典的なアプローチです。

主な問題は、情報セキュリティが開発とは切り離されていることです。 通常、これはある種の情報セキュリティ回路であり、2 ～ 3 つの大規模で高価なツールが含まれています。 半年にXNUMX回、チェックが必要なソースコードやアプリケーションが届き、XNUMX年にXNUMX回制作される 侵入テスト。 これらすべてが、業界のリリース日が遅れ、開発者が自動ツールによる膨大な数の脆弱性にさらされるという事実につながります。 過去XNUMXか月間の結果が整理されていないため、これをすべて分解して修理することは不可能ですが、ここに新しいバッチがあります。

当社の仕事の過程で、あらゆる分野と業界のセキュリティが、開発と同じ車輪で追いつき、開発と回転する時期が来たことを理解していることがわかりました。 アジャイル。 DevSecOps パラダイムは、アジャイル開発手法、実装、サポート、すべてのリリースとイテレーションへの参加に完全に適合します。

DevSecOps への移行

セキュリティ開発ライフサイクルで最も重要な言葉は次のとおりです。 "プロセス"。 ツールの購入を考える前に、これを理解する必要があります。

DevOps プロセスにツールを組み込むだけでは十分ではありません。プロセス参加者間のコミュニケーションと理解が重要です。

道具ではなく人がもっと重要です。

多くの場合、安全な開発プロセスの計画は、ツールの選択と購入から始まり、ツールを現在のプロセスに統合する試みで終わります。 すべてのツールには独自の特性と制限があるため、これは残念な結果につながります。

よくあるケースは、セキュリティ部門が幅広い機能を備えた優れた高価なツールを選択し、それをプロセスに統合するよう開発者に依頼した場合です。 しかし、それはうまくいきません。プロセスは、すでに購入したツールの制限が現在のパラダイムに適合しないように構造化されています。

まず、どのような結果を望んでいるのか、そしてそのプロセスがどのようなものになるのかを説明します。 これは、プロセスにおけるツールの役割と安全性を理解するのに役立ちます。

すでに使用されているものから始める

高価なツールを購入する前に、すでに所有しているものを確認してください。 どの企業にも開発にはセキュリティ要件があり、チェックやペネトレーションテストがあります。これらすべてを、誰にとっても理解しやすく便利な形式に変換してみませんか?

通常、要件は棚に置かれた紙のタルムードです。 私たちがプロセスを視察するためにある会社を訪れ、ソフトウェアのセキュリティ要件を確認してほしいと頼まれたことがありました。 この問題に対処した専門家は、長い時間をかけて次のことを探しました。

- さて、メモのどこかに、この文書が置かれているパスがありました。

その結果、XNUMX週間後に書類を受け取りました。

要件、チェックなどについては、たとえば次のページを作成してください。 合流 - 誰にとっても便利です。

すでに持っているものを再フォーマットして、それを使用して始める方が簡単です。

セキュリティチャンピオンを使用する

通常、100 ～ 200 人の開発者を抱える平均的な企業では、複数の機能を実行するセキュリティ スペシャリストが XNUMX 人いますが、すべてをチェックする物理的な時間はありません。 彼が最善を尽くしたとしても、開発が生成するすべてのコードを彼だけでチェックすることはできません。 このような場合に備えて、あるコンセプトが開発されました - セキュリティチャンピオン.

セキュリティ チャンピオンとは、製品のセキュリティに関心を持つ開発チーム内の人々です。

Security Champion は、開発チームへのエントリーポイントとセキュリティ エバンジェリストが XNUMX つにまとめられたものです。

通常、セキュリティ専門家が開発チームに来てコードのエラーを指摘すると、次のような驚くべき答えが返ってきます。

- そして、あなたはだれですか？ 初めてお会いします。 私には何も問題ありません。先輩の友人がコードレビューに「応募」してくれたので、次に進みます。

これは典型的な状況です。開発者が仕事やコード レビューで常にやり取りする先輩や単にチームメイトに対する信頼がはるかに高いためです。 セキュリティ担当者ではなく、セキュリティチャンピオンが間違いとその結果を指摘した場合、彼の言葉はより重みを持つことになります。

また、開発者はセキュリティ専門家よりも自分のコードをよく知っています。 静的分析ツールで少なくとも 5 つのプロジェクトを使用している人にとって、すべてのニュアンスを覚えておくことは通常困難です。 セキュリティの擁護者は、自社の製品、何が何と相互作用するのか、最初に何を見るべきなのかを知っており、より効果的です。

したがって、セキュリティ チャンピオンを導入し、セキュリティ チームの影響力を拡大することを検討してください。 これはチャンピオン自身にとっても有益です。新しい分野での専門能力の開発、技術的な視野の拡大、技術スキル、管理スキル、リーダーシップスキルの向上、市場価値の向上などです。 これはソーシャル エンジニアリングの要素であり、開発チームの「目」です。

テスト段階

パラダイム20～80 20% の努力が 80% の結果を生み出すと言われています。 この 20% は、自動化できる、また自動化する必要があるアプリケーション分析の実践です。 このようなアクティビティの例としては、静的分析があります。 サスト、動的分析 - ダスト и オープンソース管理。 アクティビティ、ツール、ツールをプロセスに導入する際に通常どのような機能が使用されるか、そしてそれを正しく行う方法について詳しく説明します。

ツールの主な問題点

すべての機器に関連し、注意が必要な問題を取り上げます。 これ以上繰り返さないように、さらに詳しく分析します。

分析時間が長い。 コミットからリリースまですべてのテストとアセンブリに 30 分かかる場合、情報セキュリティのチェックには XNUMX 日かかります。 したがって、誰もプロセスを遅らせることはありません。 この特徴を考慮して結論を​​導き出します。

高レベルの偽陰性または偽陽性。 すべての製品は異なり、すべて異なるフレームワークと独自のコーディング スタイルを使用します。 コードベースやテクノロジが異なると、ツールによって異なるレベルの偽陰性と偽陽性が表示される場合があります。 それで、正確に何が入っているか見てください あなたの 企業とのために あなたの アプリケーションは良好で信頼性の高い結果を示します。

既存のツールとの統合はありません。 すでに使用しているものとの統合という観点からツールを検討してください。 たとえば、Jenkins または TeamCity を使用している場合は、使用しない GitLab CI ではなく、このソフトウェアとツールの統合を確認してください。

カスタマイズの欠如または過度の複雑さ。 ツールに API がない場合、なぜ API が必要なのでしょうか? インターフェイスで実行できることはすべて、API を通じて利用できる必要があります。 理想的には、ツールにはチェックをカスタマイズする機能が必要です。

製品開発ロードマップはありません。 開発は止まることはなく、常に新しいフレームワークや関数を使用し、古いコードを新しい言語に書き換えています。 私たちは、購入するツールが新しいフレームワークとテクノロジーをサポートしていることを確認したいと考えています。 したがって、製品が本物で正しいものであることを知ることが重要です。 ロードマップ 開発。

プロセス機能

ツールの機能に加えて、開発プロセスの機能も考慮に入れてください。 たとえば、開発を妨げることはよくある間違いです。 他にどのような機能を考慮する必要があるか、またセキュリティ チームが何に注意を払う必要があるかを見てみましょう。

開発やリリースの期限に遅れないように、 異なるルール そして違う ショーストッパー — 脆弱性が存在する場合にビルドプロセスを停止する基準 — さまざまな環境に対応。 たとえば、現在のブランチが開発スタンドまたは UAT に送られることを理解しています。つまり、立ち止まって次のように言う必要はありません。

「ここには脆弱性があるので、これ以上進むことはできません！」

この時点で、注意が必要なセキュリティ上の問題があることを開発者に伝えることが重要です。

脆弱性の存在はさらなるテストの障害にはなりません: マニュアル、統合、またはマニュアル。 一方で、開発者が安全だと判断したものを無視しないように、何らかの方法で製品のセキュリティを強化する必要があります。 したがって、私たちは時々これを行います。開発環境にロールアウトされるときに、スタンドで開発者に次のように通知するだけです。

- 皆さん、問題があるので、注意してください。

UAT 段階で再び脆弱性に関する警告を表示し、リリース段階で次のように言います。

- 皆さん、私たちは何度も警告しましたが、あなたは何もしませんでした - 私たちはこれであなたを釈放しません。

コードとダイナミクスについて話す場合、それらの機能とその機能で記述されたばかりのコードの脆弱性のみを表示して警告する必要があります。 開発者がボタンを 3 ピクセル移動したときに、そこに SQL インジェクションがあるため早急に修正する必要があると伝えた場合、これは間違いです。 今書かれていることと、アプリケーションに起こる変更だけを見てください。

特定の機能上の欠陥があるとします。つまり、アプリケーションが動作すべきではないということです。つまり、お金が送金されない、ボタンをクリックしても次のページに遷移しない、または製品が読み込まれないなどです。 セキュリティ上の欠陥 - これらは同じ欠陥ですが、アプリケーションの動作に関するものではなく、セキュリティに関するものです。

すべてのソフトウェア品質問題がセキュリティ問題であるわけではありません。 しかし、すべてのセキュリティ問題はソフトウェアの品質に関連しています。 シェリフ・マンスール、エクスペディア。

すべての脆弱性は同じ欠陥であるため、すべての開発上の欠陥と同じ場所に存在する必要があります。 したがって、誰も読まないレポートや恐ろしい PDF のことは忘れてください。

開発会社に勤めていた時、静的解析ツールからレポートを受け取りました。 私はそれを開いて恐怖を感じ、コーヒーを入れて350ページをめくり、閉じて仕事を続けました。 大きなレポートは死んだレポートです。 通常、手紙はどこにも行かず、削除されたり、忘れられたり、紛失したりするか、企業がリスクを承知していると言います。

何をするか？ 発見された確認済みの欠陥を、開発に便利な形式に変換するだけです。たとえば、Jira のバックログに入れます。 機能上の欠陥やテスト上の欠陥と同様に、欠陥に優先順位を付けて優先順位から排除します。

静的解析 - SAST

コードの脆弱性解析です。, ただし、SonarQubeとは異なります。 私たちはパターンやスタイルをチェックするだけではありません。 分析では多くのアプローチが使用されます。脆弱性ツリーに従って、 データフロー、構成ファイルを分析することによって。 コード自体に関することはこれだけです。

このアプローチの長所: 開発の初期段階でコードの脆弱性を特定するスタンドや既製のツールがまだない場合、 インクリメンタルスキャン機能: 変更されたコードのセクションと、現在実行している機能のみをスキャンします。これにより、スキャン時間が短縮されます。

コンズ - これは、必要な言語がサポートされていないことです。

必要な統合、 私の主観的な意見では、これはツールに含まれるべきです。

• 統合ツール: Jenkins、TeamCity、Gitlab CI。
• 開発環境：Intellij IDEA、Visual Studio。 開発者にとっては、まだ覚える必要がある理解できないインターフェイスを操作するのではなく、自分の開発環境の職場で見つけた必要な統合と脆弱性をすべて確認できる方が便利です。
• コードレビュー: SonarQube と手動レビュー。
• 欠陥トラッカー: Jira と Bugzilla。

この図は、静的解析の最も代表的なものの一部を示しています。

重要なのはツールではなくプロセスであるため、プロセスのテストにも適したオープンソース ソリューションがあります。

SAST オープンソースでは、膨大な数の脆弱性や複雑な DataFlow は検出されませんが、プロセスを構築する際にはそれらを使用できますし、使用する必要があります。 これらは、プロセスがどのように構築されるか、誰がバグに対応するか、誰が報告するかを理解するのに役立ちます。 コードのセキュリティを構築する初期段階を実行したい場合は、オープンソース ソリューションを使用してください。

取り組みの開始段階にあり、CI、Jenkins、TeamCity など何も持たない場合、これをどのように統合できるでしょうか? プロセスへの統合を考えてみましょう。

CVSレベルの統合

Bitbucket または GitLab をお持ちの場合は、次のレベルで統合できます。 同時バージョン システム.

イベント別 - プルリクエスト、コミット。 コードをスキャンすると、ビルド ステータスにセキュリティ チェックが成功したか失敗したかが表示されます。

フィードバック。 もちろん、フィードバックは常に必要です。 副業でセキュリティを行っただけで、それについて誰にも何も言わずに箱に入れ、月末に大量のバグを捨てたとしたら、これは正しくないし、良くありません。

コードレビューシステムとの統合

かつて、私たちは多くの重要なプロジェクトにおいて AppSec 技術ユーザーのデフォルトのレビュー担当者としての役割を果たしました。 新しいコードでエラーが特定されたか、エラーがないかに応じて、レビュー担当者はプル リクエストのステータスを「承認」または「作業が必要」に設定します。すべてが OK であるか、正確に改善が必要な部分へのリンクが設定されています。改善する必要があります。 本番環境に移行するバージョンとの統合のため、情報セキュリティテストに合格しない場合のマージ禁止を有効にしました。 これを手動のコード レビューに含め、プロセスの他の参加者がこの特定のプロセスのセキュリティ ステータスを確認しました。

SonarQube との統合

多くの人が持っています 品質ゲート コードの品質の点で。 ここでも同じです。SA​​ST ツールに対してのみ同じゲートを作成できます。 同じインターフェイス、同じ品質のゲートがあり、それのみが呼び出されます セキュリティゲート。 また、SonarQube を使用するプロセスがある場合は、そこにすべてを簡単に統合できます。

CIレベルでの統合

ここでもすべて非常に単純です。

• 自動テストと同等、単体テスト。
• 発達段階ごとに分ける: 開発、テスト、本番。 さまざまなルールのセットやさまざまな失敗条件が含まれる場合があります。つまり、アセンブリを停止するか、アセンブリを停止しません。
• 同期/非同期起動。 セキュリティテストが終了するかどうかを待っています。 つまり、ただ立ち上げて先に進んだだけで、すべてが良いか悪いかというステータスが得られます。

すべては完璧なピンクの世界です。 現実にはそんなことはありませんが、私たちは努力しています。 セキュリティ チェックを実行した結果は、単体テストの結果と似ているはずです。

たとえば、大規模なプロジェクトを取り上げ、今度はそれを SAST でスキャンすることにしました - OK。 このプロジェクトを SAST にプッシュしたところ、20 件の脆弱性が生じましたが、強い意志により、すべて問題ないと判断しました。 000 件の脆弱性は私たちの技術的負債です。 私たちは借金を箱に入れ、ゆっくりと整理して欠陥トラッカーにバグを追加します。 会社を雇うか、すべてを自分たちで行うか、セキュリティチャンピオンに協力してもらいましょう - そうすれば技術的負債は減少します。

そして、新しいコード内に新たに出現したすべての脆弱性は、ユニットまたは自動テストのエラーと同じ方法で排除する必要があります。 相対的に言えば、アセンブリが開始され、実行されましたが、XNUMX つのテストと XNUMX つのセキュリティ テストが失敗しました。 OK - 行って、何が起こったかを確認し、何かを修正し、別のことを修正し、次回実行しました。すべてが順調で、新しい脆弱性は出現せず、テストに失敗することもありませんでした。 このタスクがより深く、よく理解する必要がある場合、または脆弱性の修正が内部にある大きな層に影響を与える場合、つまりバグが欠陥トラッカーに追加され、優先順位が付けられて修正されます。 残念ながら、世界は完璧ではなく、テストが失敗することがあります。

セキュリティ ゲートの例は、コード内の脆弱性の存在と数の点で、品質ゲートに似ています。

SonarQube と統合しています - プラグインがインストールされており、すべてが非常に便利でクールです。

開発環境との統合

統合オプション:

• コミット前に開発環境からスキャンを実行します。
• 結果を表示します。
• 結果の分析。
• サーバーとの同期。

サーバーから結果を受け取ると次のようになります。

弊社の開発環境では 知性IDEA スキャン中にそのような脆弱性が検出されたことを通知する追加の項目が表示されるだけです。 コードをすぐに編集し、推奨事項を確認し、 フローグラフ。 これらはすべて開発者の職場にあり、非常に便利です。他のリンクをたどったり、追加のものを確認したりする必要はありません。

オープンソース

これは私のお気に入りのトピックです。 誰もがオープンソース ライブラリを使用しています。すべてがすでに実装されている既製のライブラリを利用できるのに、なぜ大量の松葉杖や自転車を作成する必要があるのでしょうか。

もちろんこれは真実ですが、ライブラリも人間によって書かれており、一定のリスクも伴い、定期的または継続的に報告される脆弱性もあります。 したがって、アプリケーション セキュリティには次のステップがあります。これは、オープン ソース コンポーネントの分析です。

オープンソース分析 - OSA

このツールには XNUMX つの大きなステージが含まれています。

ライブラリ内の脆弱性を検索します。 たとえば、ツールは、あるライブラリを使用していることを認識しており、 CVE または、このバージョンのライブラリに関連するバグ トラッカーにいくつかの脆弱性があります。 これを使用しようとすると、ツールはライブラリに脆弱性があるという警告を発行し、脆弱性のない別のバージョンを使用するようアドバイスします。

ライセンスの純度の分析。 このことは、ここではまだ特に一般的ではありませんが、海外で働いている場合、使用または変更できないオープンソース コンポーネントの使用に対して現地で税金を徴収されることがあります。 認可図書館の方針によれば、これはできません。 または、変更して使用する場合は、コードを投稿する必要があります。 もちろん、自社の製品のコードを公開したい人はいませんが、これから身を守ることもできます。

産業環境で使用されるコンポーネントの分析。 ついに開発が完了し、マイクロサービスの最新リリースがリリースされたという仮定の状況を想像してみましょう。 彼はそこで素晴らしい生活を送っています - XNUMX週間、XNUMXヶ月、XNUMX年。 私たちはそれを収集しません、安全性検査も行いません、すべてが大丈夫のようです。 しかし、リリースから XNUMX 週間後、突然、この特定のビルドで使用している産業環境のオープン ソース コンポーネントに重大な脆弱性が発生しました。 何をどこで使用したかを記録しなければ、この脆弱性に気づくことはありません。 一部のツールには、現在業界で使用されているライブラリの脆弱性を監視する機能があります。 とても便利です。

特徴：

• 開発のさまざまな段階に応じてさまざまなポリシーが適用されます。
• 産業環境におけるコンポーネントの監視。
• 組織内の図書館の管理。
• さまざまなビルド システムと言語のサポート。
• Docker イメージの分析。

オープンソース分析に携わる業界リーダーの例をいくつか紹介します。

無料なのはこれだけ 依存関係チェック オワスプより。 最初の段階でこれをオンにして、それがどのように機能し、何をサポートしているかを確認できます。 基本的に、これらはすべてクラウド製品またはオンプレミスですが、そのベースの背後では依然としてインターネットに送信されます。 彼らはライブラリを送信するのではなく、計算したハッシュや独自の値、およびフィンガープリントをサーバーに送信して、脆弱性の存在に関する情報を受け取ります。

プロセスの統合

ライブラリの境界制御、外部ソースからダウンロードされます。 弊社には外部リポジトリと内部リポジトリがあります。 たとえば、Event Central は Nexus を実行していますが、リポジトリ内に「重大」または「高」ステータスの脆弱性がないことを確認したいと考えています。 Nexus Firewall Lifecycle ツールを使用してプロキシを構成すると、このような脆弱性が遮断され、内部リポジトリに残らないようにすることができます。

CIへの統合。 自動テスト、単体テスト、開発段階 (開発、テスト、本番) への分割と同じレベルです。 各段階で、任意のライブラリをダウンロードして、何でも使用できますが、「クリティカル」ステータスに何か難しいものがある場合は、運用環境へのリリースの段階で開発者の注意を引く価値があるかもしれません。

アーティファクトとの統合: Nexus と JFrog。

開発環境への統合。 選択するツールは開発環境と統合されている必要があります。 開発者は、CVS にコミットする前に、職場からスキャン結果にアクセスできるか、コードをスキャンして脆弱性を自分でチェックできる必要があります。

CDの統合。 これは私がとても気に入っている素晴らしい機能で、産業環境における新しい脆弱性の出現を監視するという機能についてはすでに説明しました。 それは次のように機能します。

我々は持っています パブリックコンポーネントリポジトリ — 外部のいくつかのツールと内部リポジトリ。 信頼できるコンポーネントのみを含めるようにします。 リクエストをプロキシする際、ダウンロードされたライブラリに脆弱性がないことを確認します。 それが当社が設定し、必然的に開発と調整する特定のポリシーに該当する場合、そのファイルはアップロードされず、別のバージョンを使用するように求められます。 したがって、ライブラリに本当に重大で問題のあるものが存在する場合、開発者はインストール段階でライブラリを受け取りません。開発者には、より高いバージョンまたはより低いバージョンを使用させます。

• 構築するとき、誰も悪いことを滑らせていないか、すべてのコンポーネントが安全であるか、フラッシュドライブに危険なものを持ち込んでいないかを確認します。
• リポジトリには信頼できるコンポーネントのみがあります。
• デプロイ時に、パッケージ自体 (war、jar、DL、または Docker イメージ) をもう一度チェックして、ポリシーに準拠していることを確認します。
• 業界に参入するとき、私たちは産業環境で何が起こっているかを監視します。重大な脆弱性が現れるか、現れないかを監視します。

動的分析 - DAST

動的分析ツールは、これまでに説明されてきたものとは根本的に異なります。 これは、アプリケーションでのユーザーの作業の一種の模倣です。 これが Web アプリケーションの場合、クライアントの作業をシミュレートしてリクエストを送信し、前面のボタンをクリックし、引用符、括弧、さまざまなエンコーディングの文字などの人工データをフォームから送信して、アプリケーションがどのように機能し、処理されるかを確認します。外部データ。

同じシステムを使用して、オープンソースのテンプレートの脆弱性をチェックできます。 DAST は、どのオープンソースが使用されているかを知らないため、単純に「悪意のある」パターンをスローし、サーバーの応答を分析します。

- はい、ここには逆シリアル化の問題がありますが、ここにはありません。

これには大きなリスクが伴います。テスターが作業するのと同じベンチでこのセキュリティ テストを実施すると、不快なことが起こる可能性があります。

• アプリケーションサーバーネットワークの負荷が高い。
• 統合はありません。
• 分析されたアプリケーションの設定を変更する機能。
• 必要なテクノロジーのサポートはありません。
• セットアップが難しい。

ついに AppScan を立ち上げたとき、私たちはある状況に陥りました。アプリケーションにアクセスするのに長い時間を費やし、3 つのアカウントを取得して満足しました。最後にすべてを確認します。 私たちはスキャンを開始しました。AppScan が最初に行ったのは、管理パネルに移動し、すべてのボタンを貫通し、データの半分を変更してから、そのサーバーを完全に強制終了することでした。 メールフォーム-リクエスト。 テストを伴う開発は次のように述べています。

- みんな、冗談ですか？ 私たちはあなたにアカウントを与え、あなたはスタンドを立ち上げました！

考えられるリスクを考慮してください。 理想的には、情報セキュリティをテストするための別のスタンドを準備し、少なくとも何らかの方法で他の環境から隔離し、条件付きで管理パネルを (できれば手動モードで) チェックします。 これはペネトレーションテストであり、現時点では考慮されていない残りの作業の割合です。

これを負荷テストの類似物として使用できることを考慮する価値があります。 最初の段階では、10 ～ 15 スレッドの動的スキャナーをオンにして何が起こるかを確認できますが、実践でわかるように、通常は何も良いことはありません。

私たちが通常使用するいくつかのリソース。

注目に値する げっぷスイート はセキュリティ専門家にとっての「スイスナイフ」です。 みんなが使っていてとても便利です。 エンタープライズ版の新しいデモ版がリリースされました。 以前はプラグインを備えた単なるスタンドアロン ユーティリティでしたが、開発者はついに、複数のエージェントを管理できる大規模なサーバーを作成しています。 これは素晴らしいので、試してみることをお勧めします。

プロセスの統合

統合は非常にうまく、そして簡単に行われます。 インストールが成功したらスキャンを開始します スタンド用のアプリケーションや、 統合テストが成功した後のスキャン.

統合が機能しない場合、またはスタブやモック関数がある場合、それは無意味で役に立ちません。どのようなパターンを送信しても、サーバーは同じように応答します。

• 理想的には、独立したテストスタンドです。
• テストする前に、ログイン シーケンスを書き留めます。
• 管理システムのテストは手動のみです。

プロセス

一般的なプロセスと、特に各ツールの動作について少し一般化しました。 すべてのアプリケーションは異なります。XNUMX つは動的分析でより効果的に機能し、もう XNUMX つは静的分析でより効果的に機能し、XNUMX つ目はオープンソース分析、ペネトレーションテスト、またはまったく別のもの (たとえば、イベントなど) でより効果的に機能します。 ワフ.

すべてのプロセスには制御が必要です。

プロセスがどのように機能し、どこを改善できるかを理解するには、実稼働メトリクス、ツールからのメトリクス、欠陥トラッカーからのメトリクスなど、入手できるすべてのものからメトリクスを収集する必要があります。

どの情報も役に立ちます。 どこでこのツールまたはそのツールを使用するのが適切か、特にプロセスが滞る部分はどこなのかを、さまざまな角度から見る必要があります。 開発の応答時間を調べて、時間に基づいてプロセスのどこを改善すべきかを確認することは価値があるかもしれません。 データが多いほど、トップレベルから各プロセスの詳細まで、より多くのセクションを構築できます。

すべての静的アナライザーと動的アナライザーには独自の API、独自の起動方法、原則があるため、スケジューラーを備えているものとスケジューラーを備えていないものがあります。私たちはツールを作成しています。 AppSec オーケストレーターこれにより、製品からプロセス全体への単一のエントリ ポイントを作成し、それを XNUMX つのポイントから管理できます。

マネージャー、開発者、セキュリティ エンジニアは XNUMX つのエントリ ポイントを使用して、実行中の内容の確認、スキャンの設定と実行、スキャン結果の受信、要件の送信を行うことができます。 私たちはペーパーワークから脱却し、開発で使用されるすべてのものを人間によるものに変換しようとしています。ステータスやメトリクスを含む Confluence 上のページ、Jira やさまざまな欠陥トラッカーの欠陥、CI の同期/非同期プロセスへの統合などです。 /CD。

主要な取り組み

ツールがメインではありません。 まずプロセスをよく考えてから、ツールを実装します。 ツールは優れていますが高価なので、プロセスから始めて、開発とセキュリティの間のコミュニケーションと理解を構築できます。 安全性の観点からは、すべてを「停止」する必要はありませんが、開発の観点から、高メガ超クリティカルなものがあれば、問題から目を背けずに排除する必要があります。

製品の品質 - 共通の目標 セキュリティと開発の両方。 私たちが行うことは XNUMX つあり、すべてが正しく機能し、風評リスクや経済的損失がないことを確認することです。 そのため、当社はコミュニケーションを改善し、製品の品質を向上させるために DevSecOps、SecDevOps アプローチを推進しています。

すでに持っているものから始める: 要件、アーキテクチャ、部分チェック、トレーニング、ガイドライン。 すべてのプラクティスをすべてのプロジェクトにすぐに適用する必要はありません。 繰り返し移動する。 単一の基準はありません - 実験 さまざまなアプローチや解決策を試してください。

情報セキュリティ欠陥と機能欠陥の間には等号があります.

すべてを自動化するそれは動きます。 動かないものは何でも動かし、自動化しましょう。 何かを手作業で行う場合、それはプロセスの良い部分ではありません。 おそらくそれを見直して自動化する価値もあります。

ISチームの規模が小さい場合 - セキュリティチャンピオンを使用する.

おそらく私が話した内容はあなたには合わず、あなたは自分なりの何かを思いつくでしょう - それは良いことです。 しかし プロセスの要件に基づいてツールを選択する。 このツールは悪くて、このツールは良いというコミュニティの意見を気にしないでください。 おそらく、あなたの製品ではその逆が当てはまるでしょう。

ツールの要件。

• 低レベルの誤検知。
• 適切な分析時間。
• 使いやすさ。
• 統合の可用性。
• 製品開発ロードマップを理解する。
• ツールをカスタマイズする可能性。

ユーリのレポートは、DevOpsConf 2018 で最高のレポートの 27 つに選ばれました。さらに興味深いアイデアや実際の事例を知るには、28 月 XNUMX 日と XNUMX 日にスコルコボに来てください。 DevOpsConf 内で フェスティバルRIT++。 さらに良いことに、自分の経験を共有する準備ができている場合は、 申請書を提出する レポートは21月XNUMX日まで。

出所： habr.com