安全なプログラミング標準の開発に関する懸念と落とし穴
私は最近、一連の安全なプログラミングガイドラインを作成する責任を引き受けました。私の意図は、 OWASP開発ガイド を基礎として使用して、機密情報分類レベルに対応するいくつかのレベルの要件を提供することです。
標準が開発されるにつれて、どのような問題が発生すると予想されますか。また、事後に実際に機能しなかったものは何ですか。
最近、チームの安全なプログラミングガイドの開発で見つけたいくつかの問題：
- ガイドラインはどのように施行または奨励されますか？あなたのガイドラインに従って製品が開発されたことを保証する責任は誰にありますか？この人ができることを確認する必要があります：
- ガイドが順守されているかどうかを確認します。つまり、コードレビューとテスト結果を調べる必要があります。そしてthatは、コードレビューとテストが存在して実行される必要があることを意味します:)。
- 開発プロセスで「例外をスロー」します。彼らはノーと言う権限を必要とします、このビルドは安全ではありません、それは出て行くことができません。
- チームにセキュリティを真剣に受け止めるように促します。煩わしい管理のように聞こえますが、開発者が不機嫌にセキュリティを実行することは望ましくありません（特に、開発者が不満を持った従業員になり、セキュリティの頭痛の種が2倍になるため）。これは、アプリのセキュリティの「所有者」が開発チームの部外者である場合に特に重要です。開発プロジェクトに出向する横断的セキュリティチームがある場合。
- 上記に関連して、経営陣はセキュリティを真剣に受け止めているとどのように見られますか？そうでない場合は、従業員もそうする必要がないという社会的なヒントです。基準にコミットすることに対する報酬は何ですか？
- ガイドラインがどのように機能しているかについて、どのようなフィードバックが得られますか？あなたは本当に理解したい：
- リリース中に発見された脆弱性
- 製品に残っている脆弱性とその理由
- 難しい点：ガイドラインを順守することを意味するが、コストを正当化するのに十分なほど製品のセキュリティに影響を与えなかったことを行うのにどのくらいの時間が費やされましたか？私が見つけた最も近い測定可能な量は、「脅威モデルにないものを軽減することに時間を費やしていますか？」ですが、リスクの高いアイテムと比較してリスクの低いアイテムに多くの時間を費やすことは、もう1つの危険信号です。
- そのようなフィードバックはどのように処理されますか？問題を見つけた場合、開発者は自分で変更を加えることができますか、それともエスカレーションする必要がありますか？
@Grahamの答えは非常に良いですが、考慮すべきいくつかの追加のポイントがあります。
- プログラミング言語/テクノロジー/プラットフォームごとに異なるガイドラインのセットが必要になります。 C++コーディングガイドラインは、.NETガイドラインと多くの共通点がありますが、それ以上に共通点はありません。
- それらは、プロジェクトのコンテキスト/ニーズ/テクノロジーなどに合わせて調整する必要があります（たとえば、すべてが2要素認証イントラネット上のクライアント/サーバーであるのに対し、すべては匿名のWebベースのインターネットのみです...）
- それらは、明確なガイダンスを提供するのに十分詳細で規範的である必要がありますが、他方では、過度に具体的であると感じるべきではありません。
- コードサンプルは必須です。
- どの項目が必須で、どの項目が推奨されているがオプションであり、どれがオプションの1つにすぎないかを明確にします。 （通常、標準の
MUST/SHOULD/MAYを使用するとうまく機能します。） - @Grahamのポイントの1つに関連して、プログラマーの賛同が必要です。これは（ほとんどの場合、政治的に）慎重に行う必要があります。例えば。開発マネージャー/チームリーダーなどがレビューし、「彼らの非常に特別な状況」への適用可能性について具体的なフィードバックを提供するための「ドラフト」バージョンを提供します（全員ではありませんか？）。また、このようにして、実際に使用されている、知らなかった追加のテクノロジー（MVC、AOPなど）を発見する可能性があります。
- トレーニング！厚いファイルをデスクトップにダンプするだけでなく、開発者と一緒に要件を確認し、what意味、whyそれぞれが必要であることを説明してください。 （もちろん、これは一般的には良い考えですが、前のバイインのポイントにも役立ちます）。
- 堅実なSDLCをお持ちの場合は、これをその一部にしてください。チームが「アジャイル」で作業している場合は、これをユーザーストーリーにします。それらが機能していても、これは成果物であるというメッセージを理解する必要があります。そしてそれは必須のものです。
- あなたが持っていない SDLCを持っているなら、今すぐやってください！コーディングガイドラインをその一部にします。
"Several levels of requirements"-これらは多すぎないでください。彼らは正しいものを選択することに巻き込まれたり、本当に必要なものについてあなたと議論したり（一方が他方よりも作業が少ないため）、および/または各アイテムが必要なレベルを「議論」する傾向がありますによって...私は2（多くても3）が機能するはずだと思います、例えば「高セキュリティ」と「基本セキュリティ」。どのように行っても、どのレベルに該当するかが非常に明確であることを確認してください。- 例外の余地を作ります-つまり、状況（および補償コントロール）に基づいて、特定のプロジェクトが特定のアイテムのパスを取得することを承認します。できれば一時的です。しかし、十分に文書化されています。
- 最新の状態に保ち、頻繁に確認します。開発者や指標からのフィードバックをもとに、使用する新しいテクノロジーに対応する新しいバージョンを用意します。