安全なソフトウェア開発環境の作成
[編集]既存のフレームワークへの拡張に関する論文に私のコンセプトに含まれる分析とフレームワークを完成させました。このスレッドの情報はすべて役に立ちました。興味のある方のために、ドキュメントの抽出され短縮されたバージョンへの直接リンクを以下に示します。このサイトは継続的な議論の場ではないかもしれませんが、私は常に批判的なレビューと印象に開いています。
http://www.levii.com/images/documents/secure%20development%20environments.docx
安全なソフトウェア開発の領域内のセキュリティについて論じるホワイトペーパー[完全な開示：これは修士論文です]に取り組んでいますが、安全なソフトウェアエンジニアリングのベストプラクティスと標準は十分に公開および文書化されています。足りないのは、これらのほとんどがソフトウェア作成自体のドメインで排他的に扱われ、それが作成された環境を完全に見落とすか、または光沢を失うことです。
DISAエンクレーブSTIG、付録A、およびソフトウェア開発、テスト、本番用に分離されたセキュリティゾーンの概念を知っており、そのような環境を作成する個人的な経験があります...監査フレームワークですが、不足しているように見えます（ISO27001またはNIST800-53と同様）およびコミュニティで公開されているベストプラクティスガイド。
このstackexchangeの質問があります： ソフトウェアアーティファクトでのデータ損失保護 と私は、主題を非常に簡単に議論するいくつかのSANS.orgホワイトペーパーにも出くわしました。しかし、業界全体のベストプラクティス、フレームワーク、またはプロセスに関して私が持っている基本的な質問を見落としているようです。
したがって、ITセキュリティコミュニティに対して私が持っている質問は次のとおりです。
1.）これらのタイプの分離について説明している参考文献を知っていますか？
2。）もちろん、ポリシーを設定する必要があります。ネットワークアーキテクチャに技術的なソリューションなどがあります。これらの基準は何ですか（または私が行ったようにしていますか...基準にしてください）個人的な経験と逸話的な知識）？
3。）「ビッグ3」ISMS標準（ISO27000、NIST800、FIPS140）のうち、特にこのような環境に拡張するのが最も適していると思いますか？ない場合、検討する必要がある別のセットはありますか？
もちろん、私はコミュニティがこの件について言わなければならない他のことを絶対に受け入れます。私はいくつかの商用製品を見てきました...もちろん、彼らはツール、テクニック、プロセスに関する多くの情報を提供することに消極的です。
これは OpenSAMM Open Software Assurance Maturity Model の要素の1つです。ガバナンスの観点からは、開発、テスト、本番環境を適切に分離することが不可欠です。
この分離がないと、次のようないくつかの重要なリスクがあります。
- テストされていないコードへの変更は、実稼働環境でデータを非常に簡単に削除または破損したり、システムを破壊してサービスを拒否したりする可能性があります
- 本番環境またはテスト環境へのアクセス権を持つ開発者は、システム制御を妨害して、詐欺を犯したり、システムを妨害したり、不正アクセスを取得したりする可能性があります。
規制産業の企業は、この分離を監査規則（金融サービスなど）の下で実施する傾向がありますが、ほとんどの産業はこれを優れた慣行として推奨しています。
米国では、 このページ にリストされているCMMI-DEVも適切であり、ほとんどのSDLCプログラムは、安全なソフトウェア開発環境を義務付けているか、少なくとも推奨しています。
ISO27001：2005にも適用される要素がありますが、それらはまだ十分に正式化されていないと思います。
免責事項として、私は情報学部の大学院生でもあり、このトピックに関する私の研究を公平に行っています。私の調査の大部分は、適切なフレームワークの不足ではなく、セキュリティの概念に関する根本的な誤解であると指摘しています。少なくとも、私が携わったすべてのプロジェクト（民間部門と公共部門）で何が起こるかは、非技術者が技術リーダーに割り当てられるか、非セキュリティ担当者がシステムの公式監査人に割り当てられることです。これらのシナリオで発生するのは、Tripwire、HIPS（McAfeeの特別ブランド）、アンチウイルスシステム、暗号化ドライブで発生する自動バックアップなどのセキュリティ制御が強化されているため、開発サイクルが「遅れている」ように見えることです。これを境界線の役に立たないSTIGSおよび他のチームが保護を確実にしていると考える他の技術的制御と組み合わせる。
簡単なサイドバーとして、STIGSは次の理由で役に立ちません。
1）POAMを記述してSTIGを完全に無視できます
2）完全にSTIGされたボックスは、STIGされていないボックスと同じ速さで壊れることがあります。
したがって、基本的にこのシナリオで発生するのは、開発/テストチームが、パフォーマンスとアプリケーションのパフォーマンスに影響を与えているとリーダーシップに不満を言うことです。これらの問題に関する技術的な背景がない人に雪を降らせることは「簡単」なので、セキュリティコントロールを削除するためにPOAMを作成するために割り当てられるチームのメンバーが1人か2人いることがよくあります。そうは言っても、フレームワークを適切に配置したい場合、それは時間を犠牲にし、開発チームの「フラストレーション」を犠牲にする必要があります。
環境を保護するという点で最も重要なことは、チームの全員が意図的であろうと意図的でなくても脅威である可能性があることです。したがって、最初に、これらのタイプの個人が実行できる被害のレベルを最小限に抑える必要があります。これは、60〜90日ごとに（たとえば）ジョブローテーションの概念が有効になる場所です。チームにポジションの切り替えを強制することにより、環境に新しい目がもたらされ、ユーザー名とパスフレーズ（パスワードではなくパスフレーズに注意）の組み合わせを更新する必要があるため、理論的にセキュリティが向上します。こうすることで、チームの堅牢性も向上します。これは、人々が簡単に退屈することがないため、視野を広げ続けることができるためです。私がDBAを原子力発電所の新しい物理的な警備員にしたり、技術的な立場や彼らが特別に訓練された分野に置いたりしているのではないことを思い出してください。
チームが作業するシステム（個々のワークステーション）を保護するという点では、これは標準のウイルス対策+マルウェア対策+ HIPS/HIDS（本当に重要な場合のみ）です。追加の注意手順として、すべての光学ドライブを取り外し、すべてのUSBポートをはんだ付けします。これが、USBポートに挿入されたものを再フォーマットする外部システムから管理されるインストールソフトウェアでは実用的でない場合でも、光学ドライブを無効にします。
チームが働くネットワークの面で。開発者がヒットできるIPアドレスの確立されたホワイトリストを用意します。これにより、小さなjarを介してFTPサーバーをセットアップし、ファイルをホームシステムに転送することができなくなります。プロキシーであるサイトへのアクセスを無効にすることも非常に重要です。プロキシーであるサイトには、環境で何をしているのかを隠そうとするビジネスがないからです。構成ファイルがパブリックWebサーバーに配置されていないこと、および開発者がこれらのシステムにアクセスできないことを確認してください。
結局のところ、すべてのシステムを最新の状態に保ち、さまざまなベンダーを使用して、1つのシステムの侵害が他のすべてのシステムに影響を与えることを防ぎます。
スティグとは
STIGはセキュリティ文書の難解な部分である可能性があるため、それらについて説明します。これらが見つかる場所の例： Windows 7 STIG
これは、特定のタイプのアプリケーションのデフォルト設定内に見られる一般的な既知の攻撃ベクトルおよび/または弱点の段階的なチェックリストです。このチェックリストのセキュリティを強化することにより、セキュリティが強化される可能性があります。これに対する対策は、操作に必要な特定のチェックを無効にするPOAMを記述することです。それらは、無数のアプリケーションタイプ（Oracleなどの特定のタイプやデータベースなどの一般的なタイプ）のために存在します。
Enclave STIGが必ずしもフレームワークと等しくない理由への応答
飛び地のSTIGを読みましたが、表面上は一種のガイドのように見えますが、それでもチェックリストにすぎない一連のSTIGを遵守する必要があります。また、レビューが出ると、BSDなど、監査フレームワークが考慮していないすべてのことを失敗します。 BSDにはGoldDisk（そのスキャンツール）がないため、それを実行するすべてのシステムは、（OSが脆弱である可能性がある）すべてに対して完全に脆弱であると見なされます。これで、特定のアーキテクチャと、無効にする必要がある一連のポートが提供されることに同意します。ただし、これをフレームワークとは呼びません。これは、何よりもセキュリティ設計パターンでの失敗した試みの詳細です。これは、システムにすべてのSTIGを実装してCIAを維持し、システムを意図したとおりに機能させることは数学的に不可能であるためです。