セキュリティ会社のプログラマーは何をしますか？
クライアントシステムのセキュリティについて相談しているセキュリティ会社のことを聞いたことがあります。この分野で私が知っている人はすべてネットワークエンジニアですが、プログラマーもセキュリティに関与していることは知っています。監査/コンサルティングを行うセキュリティプログラマーは実際に何をしますか？彼らは文字通りコードベースを調べて、人々のレガシーシステムのすべての脆弱性を探していますか？私はいつもそれが彼らのやったことだと思っていましたが、これは非常に信頼性が低く、誤った安心感を与える以上のことはしていないようです。注：私は、暗号化アルゴリズムなどを作成するプログラマーについて話しているのではなく、ソフトウェアのセキュリティ監査/コンサルティングに関係しているプログラマーについてのみ話します。
率直に言って、私たちはあなたのコードベースを調べないようにしています。私たちはそれを行うためのツールを書こうとしています。
まず、理論。セキュリティはソフトウェアシステムの要件であるため、他の要件（機能、使いやすさ、アクセス可能性、パフォーマンスなど）と同様に、要件の収集から展開および保守まで、ソフトウェアエンジニアリングワークフローのすべての段階で考慮する必要があります。確かに、これは可能であり、ソフトウェアプロジェクトチームがそれを行うのを助けるためのガイダンスが存在します。私は主にiOS開発者と仕事をしていますが、「安全な開発ライフサイクル」についての私のお気に入りの説明は Microsoft Press からです。
このモデルでは、アプリケーションのセキュリティは、ユーザーから要件を引き出そうとしているときに始まります。 私たちはユーザーではなく専門家であり、セキュリティ要件を理解している場合は難しいと感じる可能性があるため、セキュリティとプライバシーの懸念を発見する必要があります。それらを表現します。また、展開時にソフトウェアがさらされるリスクと、許容できるリスクのレベルを発見する必要があります。
これらの要件を満たすことを念頭に置いてアプリケーションを設計します。これらの要件を満たし、コードレベルのセキュリティミスに関連する追加のリスクを回避することを目的としてコードを記述します。ソフトウェアをテストして、セキュリティのモデルが実際に構築したものと一致していることを確認してから、設計時に環境について行った仮定に一致する方法でソフトウェアを展開します。最後に、ユーザーがセキュリティ要件と一致する方法でソフトウェアを操作し、提示されたリスクの新しい変化にユーザー（および私たち）が対応できるようにするサポートとメンテナンスを提供します。
わかりました、理論についてはこれだけです。 practiceでは、 Geekonomics で（非技術的な方法ではありますが）非常によく説明されており、主に彼らはソフトウェア会社がやる気を起こさせる方法であり、上記のことのほとんどは起こりません。代わりに、これを取得します。開発者は：
- 彼らが契約に入札しているときに立ち会うために警備員またはギャルを雇って、彼らが警備を「得る」ことを示します。
- ソフトウェアを書く。
- リリース前にセキュリティ担当者またはギャルを雇ってソフトウェアを検証し、ステップ2で発生した多くの問題を修正します。
- 展開後に他のすべてにパッチを適用します。
つまり、ほとんどのアプリセキュリティ担当者が本当に行っているのは、あなたが言うように、バグを見つけることです。これは本当に栄光のコードレビューですが、このレビューが探している種類のバグの専門家である人々によって実行される非常に焦点を絞ったコードレビューであるため、それを行う際に外部の助けを得ることに価値があります。もちろん、それはテッティングの一般的なルールです。常に、物を作ることに関与していない誰かにテストしてもらいます。
上記を真として受け入れると、購入を決定する人々は、「有能なセキュリティ担当者」を「多くのバグを見つける」と同一視する可能性が高くなります。コンピューターに仕事を任せる人は、そうでない人よりも多くのバグを見つけるので、もちろん静的分析ツールに大きく依存し、特定のクライアントの特定の問題をコーディングするよりもツールの拡張に多くの時間を費やすことを目指します。次に、アプリのセキュリティ担当者は、コードを読むよりもコードを読むためのツールを作成する可能性が高いと結論付けます。
**警告：残っているのは個人的な意見と憶測です**
現実は壊れています。ソフトウェアセキュリティの理論は、ソフトウェアシステムに依存するリスクを特定して対応することであり、実践はできるだけ多くのバグを見つけることでした。確かに、それでもリスクは軽減されますが、副作用としてのみです。ゲームのポイントはゲームに「勝つ」よりも重要ではなくなったため、勝ちやすいようにルールが変更されました。
あなたはソフトウェア開発者としてそれについて何ができますか？元のルールでゲームをプレイします。セキュリティの重要性を理解し、彼らからベジーザスを訓練するチームの誰かを見つけてください（できれば、請負業者ではなく実際にチームに参加して、迅速な勝利ではなく長期的な結果を提供するように動機付けてください）。その人に、私の回答の冒頭で説明したエンドツーエンドのセキュリティを提供するようにチームに指示する責任を与えます。
また、その人にフォロースルーする権限を与えます。デザインがセキュリティ要件を表していない場合は、修正する必要があります。実装がセキュリティ要件を満たしていない場合、リリースしてはなりません。あなたの警備員は判決を求めることができますが、その判決に基づいて行動することを許可されなければなりません。これはセキュリティ担当者が「OMFGセキュリティが最も重要だ」と言っているように聞こえるかもしれませんが、それは私が言っていることではありません。製品が機能、ユーザビリティ、またはパフォーマンスの要件も満たしていない場合は、それをリリースしないでください。
なぜあなたはそれをしたいのですか？それはもっと安いはずです：私たちは皆、後で修正するほど欠陥が高くなるコードコンプリートテーブルを見てきました（そしておそらく安い+10の担当者のために引用されています）？さて、セキュリティ上の欠陥も欠陥です。私はゲームの実際のルールですが、それらのほとんどは、メンテナンスで修正される要件の問題です。安いですか？
さて、[〜＃〜] i [〜＃〜]を雇うためのセキュリティガンとして、それについて何ができるでしょうか？さて、私も改正ルールでプレーを拒否できることがわかりました。開発者には、リスクを減らすことがすべてであり、これはすべての段階で実行できることを伝えることができます。そうすれば、開発者がそれを実行できるように支援できます。
小規模および非常に大規模なアプリ、環境、システムなどに対してセキュリティ保証プログラムを15年間実行してきたことから、すべてが少しあると思います。私のチームには、ハードコアなコーダーである人が常に数人います。
詳細なレベルでは、その一部は非常に詳細なコードレビューになります。例として、私は現在、数百万行のコードベースに取り組んでおり、ツールを使用して発生する可能性のある問題を絞り込んでから、分類します。
（確かに、問題がリスクをもたらさない理由を修正または説明するために、開発者に引き渡します）
しかし、これは、この種のリソースを大量に消費する作業を実行するためにリスクプロファイルが理にかなっている特定の取り組みです。
はるかに標準的で、はるかに費用効果の高いのは、組織のリスクプロファイルを理解し、トップダウンでリスクに焦点を当てようとすることです。例：
- リスクアペタイト-ビジネスへの影響、脅威のモデリング
- ガバナンス-規制順守、報告など
- ポリシー-ガバナンスフレームワークが効果的であることを保証するための定義
- プロセス-技術的および人間的
- 標準-各セキュリティコントロールの定義
- 実装-ハウツー
プログラミング側は、コードレビューとカスタム侵入テストを使用して、実際には最後の2つにしか入りません。一部の組織では、重要性が非常に低くなっています。たとえば、すでに広範囲にピアレビューされている階層化されたセキュリティ制御（さまざまな暗号化タイプなど）がある場合、実装を確認することはできますが、通常、すべてを再確認することはありません。以前に行われたようなコード。
設計中にアーキテクチャ/ベストプラクティスについて漠然と議論したり、完成したプロジェクトに対して攻撃/フリッツ/例外テストスイートを実行したりする以上のことは、これまでに一度もありません。
ほとんどすべての場合、私は彼らが試みる攻撃ベクトルによってどのツールを使用するか、そして監査の1つが既存のシステムに合格した後に攻撃が実行される方法を知ることさえできます。
実際にコードを調べてレビュー/ホワイトボックステストを行うのに時間がかかるものがいくつかあると思いますが、実際にはまだそれらに遭遇していません。