web-dev-qa-db-ja.com

脆弱性管理がセキュリティの低下または侵害につながらないようにする方法

脆弱性スキャンを実行すると、Node.jsなどの特定のバージョンが脆弱であると報告されることが多く、より高いバージョンに更新するように推奨されます。次に、TLS 1.0やSSL 3.0などの安全でないSSL/TLSプロトコルもあるので、それらを完全に無効にすることをお勧めします。私にとって、上記の推奨事項はすべて、特定のアプリケーションやホストなどに適用する必要がある変更です。

今、私は不思議に思っています、どの変更がreducedまたはcompromisedにつながらないようにすることができますか？セキュリティ？新しいNode.jsバージョンがさらに深刻な脆弱性/脆弱性を導入していないことをどのように確認できますか？変更管理はこれにどのように適合しますか？結局、Node.jsのバージョンを更新したり、安全でないTLS/SSLプロトコルを無効にしたりすることは、変更要求ですよね。

vulnerabilityvulnerability-management
2
user211245

私にとって、上記の推奨事項はいずれも、特定のアプリケーションやホストなどに適用する必要がある変更です。

その点について完全に同意し、変更管理プロセスがある場合、それらのすべての変更が通過する必要があります。

どの変更でもセキュリティの低下または侵害につながらないことをどのように確認できますか？新しいNode.jsバージョンがさらに深刻な脆弱性/脆弱性を導入していないことをどのように確認できますか？

できません。それは単なる問題またはリスクです。古いバージョンには既知のセキュリティ問題があります。つまり、問題はシステムに対してそれを使用する可能性がある攻撃者にも知られています。新しいものにはおそらく他にもありますが、誰かがそれを使用する方法を知るまで、システムは現在の攻撃に対して脆弱ではありません。

変更管理はこれにどのように適合しますか？結局、Node.jsのバージョンを更新したり、安全でないTLS/SSLプロトコルを無効にしたりすることは、変更要求ですよね。

はい、そうです。また、本番システムをアップグレードする前に、開発または本番前のプラットフォームで文書化された非回帰テストを使用して、アプリケーションが新しいバージョンで正しく動作することを注意深くテストする必要があります。そして、テストの結果は、変更管理プロセスの入力になるはずです。これはもちろん、メジャーバージョンでは必須であり、マイナーバージョンでは推奨されますが、単純なパッチではオプションです。

2
Serge Ballesta

Node.jsの例を見てみましょう。既知の脆弱性を持つバージョンのを使用しています。したがって、2つのオプションがあります。

  1. あなたが知っているバージョンを使い続ける知っているは脆弱です
  2. mayに脆弱なバージョンにアップグレードします。

正しい選択は＃2のみです。脆弱性もあるバージョンにアップグレードすることは可能ですか？絶対に！実際、バグのないソフトウェアのようなものはめったにないので、それはおそらく事実です。

ただし、未知の脆弱性が存在する可能性は、ここでは赤字です。脆弱性があることがわかっている場合（特に、脆弱性が既知である場合）は、修正することが重要です。明らかに、中途半端な修正をプッシュしたくないのですが、アップグレードに独自の脆弱性があるのではないかと単に恐れているため、既知の脆弱なバージョンに留まることは間違いなく悪い考えです。

2
Conor Mancone

私はより積極的に、決断力と回復力に焦点を当て、変化の完成を待たないでください。

継続的に改善を探すためのいくつかの領域：

ビジネス上の決定と変更管理

  • 依存関係のマッピングと理解
  • ビジネス影響評価のダイナミクス
  • 変更管理プロセスのダイナミクス
  • システムセキュリティパッチの速度
  • 失敗した変更を元に戻す機能
  • 緊急事態対応プロセス
  • 優先度の高い変更の高速トラック処理
  • ワークフロー代理割り当て
  • ワークフローのエラー
  • 例外処理

セキュリティと脆弱性のスキャン

  • 誤検知を理解してタグを付け、ノイズを減らす
  • 脆弱性データベースが最新であることを確認する
  • 脆弱性の特定
  • 新たに報告された脆弱性に対する反応
  • 探索的侵入テスト

ソフトウェア開発ライフサイクル

  • 品質管理プロセス、統合の自動化および回帰テスト
  • セキュリティレビュープロセス、自動ユニットテスト、自動侵入テスト
0
Refineo