ni.com is currently undergoing scheduled maintenance.
Some services may be unavailable at this time. Please contact us for help or try again later.
ソフトウェアアプリケーションのセキュリティには、開発ライフサイクル全体を通じてセキュアな考え方を追加する正式な方法論が必要です。このソフトウェア開発ライフサイクル (SDLC) は、チームの準備、ソフトウェア開発を保護するための対策の確立、ソフトウェア設計におけるセキュリティのベストプラクティスの遵守、リリース後のソフトウェアのサポートを通じて、開発開始前から始まります。このホワイトペーパーでは、NI LabVIEWチームがセキュアなソフトウェア開発フレームワークを含む正式なSDLCをプロジェクトに採用するための推奨事項について説明します。
ソフトウェア開発ライフサイクル (SDLC) は、ソフトウェア (ハードウェアに組み込まれたコードを含む) を設計、作成、および保守するための公式または非公式の方法論です。
正式にドキュメント化されているかどうかに関わらず、すべてのソフトウェアチームには開発プロセスがすでに存在します。意図的かつセキュアな開発では、脆弱性を減らし、保守性を向上させ、セキュリティ問題を解決するコストを削減するために、プロセス全体にアクティビティを追加します。脆弱性には、コードの欠陥によるバグだけでなく、セキュリティ構成設定、誤った信頼仮定、古いリスク分析による脆弱性も含まれます。
SDLCでセキュリティが早期に対処されるほど、最終的に同じレベルのセキュリティを実現するために必要な労力とコストが少なくなります。シフトレフトとして知られるこの原理は、SDLCモデルに関係なく非常に重要です。シフトレフトの原理は、LabVIEWを含むすべてのプログラミング環境に当てはまります。LabVIEWは、セキュアなアプリケーションの開発に使用できるセキュアなプログラミング環境です。完成したアプリケーションのセキュリティの多くは、開発チームが採用するSDLCに依存します。
SDLCおよびコンプライアンスに関する重要なメモ:欧州サイバーレジリエンス法 (CRA)、米国サイバーセキュリティ成熟度モデル認証 (CMMC)、英国防衛サイバー認証 (DCC) などのほとんどの規制プログラムでは、システムがこのSDLCのようなセキュアな慣行に従って設計されているという証拠が必要ですが、これらのプログラムには単なるSDLC以上のものが必要です。詳細については、それらのプログラムのドキュメントを参照してください。
このガイダンスは、主にNIST特別刊行物 800-218「セキュアソフトウェア開発フレームワーク (SSDF)」で定義されている原則と慣行に基づいています。SSDFは、セキュアなソフトウェアを開発するための技術中立的なフレームワークを提供し、米国政府のソフトウェアセキュリティ要件をサポートしていると広く認識されています。各SSDFプラクティスは、テスト、測定、自動化、エンジニアリング環境における実践的な実装に重点を置いて、LabVIEW開発チームのニーズに特に特化して解釈され、適用されています。
また、このドキュメントに記載されている推奨事項は、JKI Security SuiteやMicrosoft Security Development Lifecycle (SDL) など、確立された他のセキュアな開発フレームワークや業界のベストプラクティスと比較することで、ソフトウェアセキュリティ、リスク管理、およびソフトウェアサプライチェーン保護に対する実証済みのアプローチとの一貫性を確保しています。目的は、顧客、規制当局、政府調達プログラムにますます求められる証拠とトレーサビリティを生成しながら、サイバーセキュリティを開発プロセスに統合するための実用的なロードマップをLabVIEW組織に提供することです。
NIST 800-218で説明されているプロセスは、ソフトウェア開発のこれら4つの分野をカバーしています。
このホワイトペーパーでは、これらのトピックを使用してLabVIEW SSDFを開発します。
開発を開始する前に、チームがセキュアな開発の原則を採用し、必要なトレーニングを完了し、セキュアな開発をサポートするプロセスとツールを確立するための手順を実行することが重要です。この段階では、以下の目標を達成するために時間をかけます。
これらの要件はソフトウェア開発チームにとって汎用的なものですが、テストチームおよびLabVIEWチームに適応するにはいくつかの手順が必要です。
多くのテストチームは、会社のセキュリティチームから隔離されています。セキュリティを真剣に考えていることをセキュリティチームに理解してもらえるよう、セキュリティチームと連携して信頼関係を構築してください。セキュリティチームとミーティングを行い、開発コードの要件を理解します。作成したプロジェクトとテスト領域を示し、プロセスを順を追って説明します。テストラボがどのように動作するかを理解し、どのような制限があるかを知る上で役立ちます。他のITシステムとは異なる課題があり、セキュリティチームがその違いを把握していれば役立ちます。
また、セキュリティチームの懸念事項を理解することも重要です。どのプログラムを満たす必要があるかを把握することで、セキュリティ要件を要件まで遡ることができ、元のプログラムの目的をより適切に満たすことができます。
要件の追跡は、チームがセキュアなコードを提供するための準備において重要です。優れた追跡プロセスは、要件を保存するだけでなく、要件のトレーサビリティも提供します。チームは、ライフサイクルを通じて要件を追跡できる必要があります。
要件定義 → 設計 → 実装 → テスト → 不具合修正 → リリース
このトレーサビリティは、顧客監査、セキュリティ宣言 (CRAなど)、評価 (CMMCなど)、またはサプライヤセキュリティレビューの際に証拠となります。
GitHub課題 + プロジェクト + マイルストーンは、ほとんどの小規模チームにとって最も一般的な要件追跡アプローチです。その他の追跡オプションには、GitLab (無料および有料階層)、Azure DevOps、JIRA、およびその他のプロフェッショナルソフトウェア開発ツールが含まれます。これらのツールを使用すると、問題を作成して解決まで追跡できます。
選択したツール内で、セキュリティ要件を体系的に追跡します。各要件は、以下の基準を満たす必要があります。
要件追跡ツールを特定したら、開発にこれらのツールを使用できるようにプロセスをドキュメント化します。システムのライフサイクル全体にわたる要件追跡と問題追跡のプロセスを使用します。プロセスには、以下の手順が含まれる場合があります。
コードをモジュール化するように計画します。この手順は、個々のモジュールをテストできるため、LabVIEWで特に役に立ちます。モジュール式アーキテクチャを計画する際は、ユニットテストも計画してください。これにより、コードの品質が向上し、システムのデプロイ後であっても、更新後にコードをより迅速に検証できます。
NI Unit Test Frameworkの使用方法の詳細
他社製のテストツールは、JKIのCarayaおよびLUnit製品によってLabVIEWチームのソフトウェアテストを拡張するなど、さらなる価値を提供します。
下請け作業、他社製ソフトウェア、オープンソースコンポーネントを確認して承認するプロセスを定義します。プロセスには、CVE (Common Vulnerabilities and Exposures) などのパブリックデータベースをチェックし、使用するコンポーネントの既知の脆弱性を特定することが含まれます。
オープンソースコンポーネントを使用する場合、アプリケーションでコードを使用する前に脆弱性をスキャンする必要があります。
セキュリティ固有の役割など、チーム内の特定の役割を定義します。これらの各役割の責任とアクセス権を特定します。少なくとも、ユーザ役割 (開発者およびオペレータ) とは別に、特権アクセス (管理者) を持つ役割を定義します。
これらの役割に適用するセキュリティトレーニングを作成します。トレーニングをチームメンバーに割り当て、トレーニングの完了を確認します。これらのレコードは、認定審査で証拠として使用されます。
オンラインで利用可能なNIセキュリティトレーニングの使用を検討してください:テストシステム統合のセキュリティに関する考慮事項コース。
ISC2などの業界認定プログラムでは、低コストの導入レベルの認定を提供しています。テストチームにとってこれらのプログラムの価値は、セキュリティチームと通信するための共通言語を提供することです。
SDLCを定義した後、これを会社のリーダーに提示し、正式なサポートを受けてください。プログラムへのコミットメントを示すには、少なくともセキュリティ予算を承認するレベルで承認される必要があります。
組織として、発生する可能性のあるデータのタイプを特定し、ラベリングシステムを作成します。以下のデータタイプを考慮する必要があります。
明確なデータ管理とラベリングシステムがあれば、データの各分類に適切な制限を適用して、データを適切に保護することができます。システム開発を開始する前にこれを組織として定義しておくと、適切な管理策を適切なリスク領域に適用して時間を節約できます。既存の企業およびITラベリングシステムにマッピングすると、システム間でデータを共有する方法が簡素化されます。
セキュリティのために標準化するソフトウェアおよびドライバのバージョンと構成を特定します。LabVIEWでは、開発に使用するバージョンを指定します。インストール用にセキュア構成を確立します。『LabVIEWセキュア構成ガイド』を参照してください。その他のセキュア構成ガイドは、ni.com/securityで参照できます。
監査可能性を確保し、新しいシステムを迅速に構築するために、開発用マシンやビルド用マシンのセットアップを自動化します。ベースラインインストールを確立し、そのインストールからイメージを作成します。
開発全体でセキュリティチェックに使用するツールを確立します。潜在的なセキュリティの脆弱性を見つけるためにプログラムを実行せずにソースコードを解析するには、スタティックアプリケーションセキュリティテスト (SAST) ツールが必要です。LabVIEWグラフィカルコードには、LabVIEWコードを静的に解析するために特別に設計されたJKI Security Suiteをお勧めします。または、手動で静的コード解析を実行してセキュリティ上の問題を探すこともできます。
SASTツールは、コードの脆弱性を分析する重要なセキュリティツールの1つです。ダイナミックアプリケーションセキュリティテスト (DAST) ツールも重要で、テスト中に実行しているコードをスキャンするために使用されます。ソフトウェア構成解析 (SCA) は、オープンソースライブラリ、他社製パッケージ、ソフトウェアコンポーネントの使用を特定し、それらのコンポーネントの既知の脆弱性とライセンス問題をスキャンします。
セキュリティ上の問題のためにコードをスキャンするツールには、他にもさまざまな種類があります。プロジェクトに適したツールは、ツールセット、プロジェクトの性質、および使用するコードの種類によって異なります。セキュアな開発ライフサイクルのこの段階では、チームが使用するツールを調べて特定することが重要です。
セキュアな開発では、コードに不具合が生じた場合にチームが旧バージョンに戻せるように、複数のバージョンのソースコードを保存する必要があります。セキュアな開発を行うための組織の準備の一環として、コードを保存し、開発用にコードをチェックアウトし、ソースコードのバージョン管理を行うコードリポジトリを確立します。
コードリポジトリで分岐すると、並列開発と安定したリリースが容易になります。組織で使用するブランチタイプを定義します。これらのブランチタイプは標準的ですが、必要に応じて変更できます。
適切なセキュリティ管理を提供するリポジトリを使用してください。リポジトリがコミットファイルと変更の完全な履歴を保持し、トレーサビリティを確保していることを確認します。
コードの開発に使用するコンピュータが、基本的なサイバーセキュリティポリシーに従っていることを確認します。これらの基本的な管理策には、パスワード保護、悪意のあるコード保護、およびその他の基本的なサイバーハイジーンが含まれます。これらの基本的な管理策の例として、https://www.acquisition.gov/far/52.204-21を参照してください。
トレーサビリティのために、システムの開発に使用されたコンピュータの構成設定をキャプチャします。キャプチャする構成設定には、以下の例が含まれます。
ほとんどのセキュリティプログラムでは、チームがSSDFの一部として確立された慣行に従っていることを示す証拠が必要となります。リポジトリを確立して、証拠を追跡し、システムの開発およびデプロイ全体を通じてその証拠を更新します。システムは以下の項目を追跡します。
多くのチームは、これらのセキュリティアクティビティを実行していますが、実行したことを証明できません。コンプライアンスチームは、チームが適切なプロセスを確立していることと、それに従うことの両方を求めています。これらのドキュメントを1か所にまとめることで、監査とコンプライアンスレビューを大幅に簡素化できます。
コードを安全に開発する準備ができたら、次のタスクはソフトウェアを保護することです。この手順により、チームは開発およびリリース中にコードを安全に保つことができます。
開発プロセスにおけるソフトウェアの保護は、使用するプログラミング言語に関係なく、すべてのソフトウェアにとって重要です。LabVIEWチームがソフトウェア開発にプロフェッショナルなワークフローツールを採用する場合、それらのチームもセキュアな開発プロセスとツールを採用する必要があります。
前の段階で特定されたセキュアなコードリポジトリを使用して、コードを保存および管理します。優れたリポジトリは、ソースコードを管理するだけではありません。また、要件、ドキュメント、ビルドスクリプト、テストアーティファクト、およびリリース履歴も含まれています。リポジトリには多くのコードとサポート情報が含まれているため、セキュアなリポジトリを使用することが重要です。リポジトリが侵害されると、ソフトウェアも侵害されます。
リポジトリ内では、メインブランチは保護する必要がある重要な資産です。チームは、コードを保護するためのポリシーを定義し、それに従う必要があります。これらのポリシーには、次の例が含まれます。
リポジトリは、要件の生成から開発、製品リリースまでのトレーサビリティも提供する必要があります。リポジトリによっては、コミットに署名できるものもあります (Gitなど)。
リポジトリは、ソフトウェアの変更を記録して監査証跡を提供する必要があります。何が変更され、誰が変更し、なぜ変更され、誰が承認し、いつリリースされたのでしょうか。さらに、リリースイメージはセキュアなアーカイブにバックアップして、リポジトリが侵害された場合でもコードを取得できるようにする必要があります。
SBOMは、コードの開発に使用されるソフトウェアとコンポーネントのリストを提供します。ビルドプロセスの一部としてSBOMを生成することで、コードで使用されているコンポーネントのログを確実に取得でき、脆弱性を特定して修正するプロセスを合理化できます。
LabVIEW 2026 Q3以降では、アプリケーションビルドプロセスの一部としてSBOMを生成できます。詳細については、「スタンドアロンアプリケーションのソフトウェア部品表を生成する」を参照してください。
コード署名は、ソフトウェアが既知の組織によって作成され、リリース後に変更されておらず、配布が承認されたことをユーザが確認するためのメカニズムを提供します。LabVIEWアプリケーションでは、コード署名は実行ファイル、インストーラ、デプロイメントパッケージ、DLL、ドライバ、および更新パッケージに適用する必要があります。
ビルドプロセス中にアプリケーションに署名するには、以下の手順を実行します。また、MicrosoftのSignTool.exeを使用してソフトウェアに署名することもできます。これは、アプリケーションまたはファイルに署名する場合と同じです。
アプリケーションでは、パスワード、APIキー、証明書、トークン、暗号化キー、データベース資格情報、サービスアカウント資格情報などのシークレットが必要になることがよくあります。これらのシークレットは、システムとデータへのアクセスを提供し、ソフトウェアのライフサイクルを通じて保護する必要があります。
パスワード、APIキー、証明書、または暗号化キーをソースコード、構成ファイル、ビルドスクリプト、またはテストユーティリティに直接ハードコーディングしないでください。ハードコーディングされたシークレットはローテーションが困難で、リポジトリにコピーされる可能性があり、ソースコードレビュー、バックアップ、またはデプロイされたアプリケーションのリバースエンジニアリングを通じて露出する可能性があります。
可能な限り、セキュアなオペレーティングシステムまたはハードウェアで保護されたストレージを使用してシークレットを保存します。セキュアなストレージや保護されたストレージの例には、以下のオプションがあります。
シークレットへのアクセスを許可する場合は、最小権限の原則を適用します。シークレットにアクセスできるのは、シークレットへのアクセスを必要とするユーザ、システム、およびサービスのみです。管理資格情報はユーザ資格情報から分離し、共有アカウントはできる限り避ける必要があります。
パスワード、証明書、APIキー、暗号化キーは、組織のポリシーに従って定期的に交換する必要があります。シークレットの生成方法、格納場所、シークレットにアクセスできるユーザ、および侵害されたシークレットの無効化方法を定義するプロセスを確立します。
テストシステムは、実際のネットワーク接続、データベース、クラウドサービス、計測器を頻繁に使用します。テストチームは、テスト中にこれらのシステムにアクセスする必要があります。可能な限り、本番環境の資格情報ではなく、専用のテスト資格情報を使用してください。テスト環境を分離することで、開発および検証作業中に運用システムが危険にさらされるリスクを軽減できます。
この段階では、ソフトウェアを安全に設計、実装、テスト、および検証することに重点を置いています。このタスクを効果的に行うには、意図されたソフトウェアの使用のリスクと要件を評価し、それらのリスクに対して設計する必要があります。ベストプラクティスには、既知のセキュアなコンポーネントの再利用、開発中のテスト、開発コードの脆弱性のスキャンなどがあります。チームは、セキュアバイデフォルト設定を使用することを含め、セキュアな使用を計画します。
テストおよび測定アプリケーションは、一般的なソフトウェアアプリケーションとは異なるセキュリティの課題に直面します。LabVIEWチームは、これらの課題を理解し、アプリケーションに集中する攻撃から保護するソフトウェアを開発する立場にあります。LabVIEWには、さまざまな安全保護機能がありますが、チームは攻撃の可能性を考慮し、それに対する防御を準備する必要があります。
OWASP (Open Worldwide Application Security Project) は、セキュアなソフトウェアの構築を支援するツール、ガイド、規格を無償で提供する非営利財団です。OWASPは、コミュニティ主導型脅威モデリングガイドを提供します。このモデルには、作業範囲の決定、脅威の特定、対策と軽減の決定、作業の評価を行うための一連の手順が構造化されています。
テストチームにとっては、開発するシステムの用途と脅威を理解するための会話から始まります。この会話には、開発リーダー、テストアーキテクト、システムエンジニア、プロダクトオーナー、サイバーセキュリティ担当者、運用担当者を含める必要があります。
OWASPアプローチには、スプーフィング、改ざん、否認、情報開示、サービス拒否、権限昇格 (STRIDE) などの脅威リストが含まれます。STRIDEの脅威カテゴリは、チームがあらゆる種類の脅威を考慮するのに役立ちます。
テストチームは、ブレインストーミングセッションの経験を活かし、テスト環境での脅威がシステムにどのような影響を与えるかを具体的に検証する必要があります。
従来のサイバー脅威にこれらのテスト特有のリスクを追加すると、テストシステムに適した防御戦略を特定するのに役立ちます。脅威モデルの出力は、優先順位付けされたリスクと、それらのリスクを軽減するために必要なセキュリティ要件のセットである必要があります。これらの要件は、次のセクションで説明するシステム設計および開発作業の入力となります。定期的な脅威レビューは、時間の経過とともに新しい脅威や新たに出現する脅威を特定するのに役立ち、以前の脅威では捉えられなかった問題のレビューも含めることができます。
脅威モデルは、システムに対するリスクを特定します。次のステップは、これらのリスクを測定可能なセキュリティ要件に変換し、ライフサイクル全体にわたって実装、テスト、追跡できるようにすることです。セキュリティ要件は、機能要件と同じレベルの厳しさで処理する必要があります。
セキュリティ要件は、システムが提供する必要があるセキュリティ制御または動作を定義します。優れたセキュリティ要件とは、具体的で、測定可能で、テスト可能で、追跡可能なものです。以下の表は、いくつかの例を示しています。
セキュリティ要件には固有の識別子を割り当て、機能要件に使用される要件管理ツールを使用して追跡する必要があります。
明確に定義されたセキュリティ要件は、開発ライフサイクル全体にわたって追跡可能である必要があります。トレーサビリティは、特定されたリスクが対処されたことを示し、顧客の監査、サプライヤのセキュリティ評価、および規制レビューにおいて貴重な証拠を提供します。
テストと測定システムには、エンタープライズソフトウェアプロジェクトで見過ごされがちなセキュリティ要件があります。セキュリティ要件を作成する際は、標準のセキュリティカテゴリを使用しますが、以下のデータも考慮してください。
不正確な測定やテスト結果の破損はビジネスに重大な影響を及ぼすため、整合性のセキュリティ要件は機密性の要件と同様に重要です。
モジュール式コードは、制御されたインタフェースを持つ明確に定義されたコンポーネントに機能を分離することで、欠陥や脆弱性の影響を制限します。優れたモジュール式設計では、各モジュールは他のモジュールが必要とする機能のみを提供します。このタスクにより、エントリポイントが減り、誤用の可能性が低くなります。モジュール式コードには、テストが簡単なため、コードの更新の適用と検証が簡単であるという利点もあります。
モジュール式コードを作成する際は、最小権限の原則を考慮してください。モジュールには、その機能を実行するために必要な権限のみが必要です。たとえば、計測器通信関数は、異なるモジュールによって処理されるため、データベースにアクセスする必要はありません。データベースハンドルを計測器通信モジュールに渡さないでください。
モジュール間でデータが渡される際に、通信の信頼性を評価します。必要に応じて、別のコンポーネントからデータを受け入れる前にソースを検証します。
モジュール式コードを使用すると、セキュリティレビューが容易になります。レビューのたびにコード全体を確認するのではなく、各モジュールを個別にレビューすることができます。コードレビュー担当者は、単一のコンポーネントのセキュリティを確保するために、コードセット全体を理解する必要はありません。
また、コードモジュールはコードの再利用を簡素化します。安全に開発およびテストされたモジュールは、意図したとおりに動作すると確信して他のアプリケーションに再利用できます。
一連のベストプラクティスを確立し、そのベストプラクティスに従ってください。コードレビューでは、これらのベストプラクティスに準拠していることを確認する必要があります。ベストプラクティスの包括的なレビューはこのドキュメントの範囲外ですが、少なくとも次の領域を含める必要があります。
LabVIEWユニットテストフレームワーク (NI Unit Test Framework、JKI Caraya、またはLUnit) を使用します。これらのツールを使用すると、開発者は入力と出力を定義し、コードが正しく動作するかどうかを検証できます。これは、アプリケーション全体を実行せずに実行できるため、コード検証が簡素化されます。
ユニットテストは、モジュールを絶縁してテストできるため、高価な機器の制御などのデリケートな機能を保護します。ユニットテストは、繰り返し実行できるように設計する必要があり、コード変更時に自動的に実行されるように、連続統合 (CI) システムに統合することが理想的です。
頻繁なセキュリティレビューは、セキュリティ志向の開発文化を確立する上で重要です。レビューは、チームがセキュアなプラクティスを確立し、互いに学び合い、セキュアなプロセスを強化する方法を提供します。セキュリティレビューは、開発の前に開始され、計画されているアーキテクチャと方法を確認します。その後、コードを安全に開発するために、開発プロセス全体にわたってレビューを継続する必要があります。頻度は、開発の規模に基づいて決定する必要があります。レビューは十分な頻度で行い、重要な後工程の開発が発生する前に問題を修正する必要があります。レビューは、マージ要求、プル要求、またはその他の重要なコード統合イベントが発生するたびに行われます。大規模なプロジェクトには、追加の定期レビューが適しています。
セキュリティレビューは、チームがチェックリストからレビューを行うことで大幅に強化されます。これらのチェックリストは、組織が作成し、脅威とリスクの分析に基づいて各プロジェクトの開始時にカスタマイズする必要があります。
手動コードレビューに加えて、自動コードレビューも実行します。継続的インテグレーションおよび継続的デリバリ/デプロイメント (CI/CD) プロセスを使用する場合は、各コードチェックインでコードがスキャンされるように、取り込みプロセスにセキュリティスキャンを追加します。新たに発生したセキュリティ上の欠陥をコードの恒久的な部分になる前に検出するために、毎日または毎週実行する追加のスキャンツールを設定します。静的解析、ユニットテスト、その他のセキュリティスキャンツールを使用して、さまざまなレビュータイプを追加します。
可能な限り、最新バージョンの開発ソフトウェアドライバを使用してください。新しいセキュリティの脅威はほぼ毎日確認されており、開発者はパッチや新しいソフトウェアバージョンにセキュリティ修正を加えています。最新バージョンを使用できない場合は、ベンダから引き続きセキュリティアップデートが提供され、システムのライフサイクル期間中も提供されるソフトウェアを使用してください。
ベンダが提供する構成ガイドを使用して、ツールをセキュリティ用に構成します。
NI製品でサポートされているソフトウェアバージョンの一覧を見る
製品をリリースする前に、プロジェクトの開始時に特定された脅威とリスクに基づいてテストを実施します。このリストには、以下のテストが含まれます。
LabVIEWはグラフィカルプログラミング言語であるため、従来のセキュリティツールの中にはLabVIEWコードをテストできないものもあります。JKI Security Suiteなどのツールは、LabVIEW開発者向けに設計されたセキュリティ重視の静的解析機能を提供します。この機能は、LabVIEWコードをスキャンし、グラフィカルプログラミング言語特有のセキュリティ上の問題に合わせて調整されています。
開発チームが脅威モデルのレビュー、重大な脆弱性の解決、ユニットテストの適用と合格、静的解析の実行、SBOMの生成、コードレビューの実施、リリースパッケージへの署名を実証できなければ、リリースを承認すべきではありません。正式なリリースゲートプロセスを適用することで、プロセスが遵守され、ソフトウェアが安全であることを確認するための判断材料を経営陣に提供できます。
セキュアなソフトウェアの開発はプロセスの一部にすぎません。セキュアなアプリケーションは、正しくデプロイされなかったり、インストールおよび構成中にセキュリティ制御が削除された場合に脆弱になる可能性があります。したがって、デプロイメントプロセスは、ソフトウェアがユーザにリリースされる前に定義された手順、レビュー、および検証アクティビティを含む、セキュアなソフトウェア開発ライフサイクルの一部として取り扱う必要があります。
セキュアなデフォルト構成
アプリケーションは、セキュアバイデフォルト設定を使用してデプロイする必要があります。ユーザは通常、デフォルト設定が推奨構成であると仮定します。デフォルトで無効になっているセキュリティ重視のオプションは、システムの寿命まで無効のままになる可能性があります。
セキュアデフォルトには以下の例が含まれます。
ユーザは、セキュリティ保護を手動で有効にするのではなく、意識的にセキュリティ設定を弱める必要があります。
本番環境の強化
リリース前に、開発中には役立つものの、本番環境では不要なリスクを生じさせる開発アーティファクトや機能を削除してください。以下の基準に従ってアプリケーションを確認します。
本番システムでは、システムの操作に必要な機能のみを公開する必要があります。
アカウントおよび権限管理
システムに必要な権限を確認し、適切な役割に割り当てます。操作上の必要性がドキュメント化されていない限り、管理者権限を付与しないでください。サービスアカウントは、目的の機能を実行するために必要な権限のみで構成する必要があります。役割ベースの権限を検討する際は、以下の点を考慮してください。
システムに機密情報が保存されている場合は、アクセス制御によってその情報が適切に保護されていることを確認してください。
ネットワークセキュリティ構成
デプロイ前に、必要なネットワーク通信をすべてドキュメント化してください。システムによって作成された各接続について、以下を考慮してください。
データがネットワークの境界を越える場合、データは保護される必要があります。各データ転送では、以下の予防措置を取ってください。
テストシステムは、多くの場合、企業ネットワーク、製造ネットワーク、クラウドサービス、計測器に同時に接続されます。これらの信頼境界を理解し、ドキュメント化することは、重要なデプロイメント作業です。
シークレットおよび資格情報管理
アプリケーションでは、多くの場合、パスワード、APIキー、証明書、トークン、または暗号化キーが必要です。これらのシークレットトークンを処理する際は、以下の点に注意してください。
代わりに、以下のツールまたはテクノロジーのいずれかを使用してください。
シークレットの作成、保存、回転、バックアップ、および取り消し方法をドキュメント化します。このプロセスに従ってください。
ロギングと監査
アプリケーションは、重要な操作およびセキュリティ関連イベントを記録する必要があります。ロギングするイベントには、次の例が含まれます。
ログは、その情報を意図しない利用者にも表示される可能性があるため、パスワード、個人情報、機密情報などのシークレットがロギングされないことを確認してください。
ログは、障害のトラブルシューティング、インシデントの調査、および顧客および規制要件への準拠の証明に役立ちます。
可能であれば、アプリケーションログをWindowsイベントビューアやLinux Syslogなどのプラットフォームログメカニズムと統合して、監視、インシデント調査、コンプライアンスレポートを簡素化します。セキュアなサーバにログを送信することが保護とアクセスに役立つかどうかを評価します。
監査ログを不正アクセスや変更から保護し、ログを保持する期間を定義します。
リリース承認
ソフトウェアをリリースする前に、最終的なセキュリティレビューを行い、アプリケーションがチームのリリース要件を満たしていることを確認します。この最終レビューには、以下の事項が確認されます。
リリースプロセスでは、これらのアクティビティが完了したことを示す証拠を提示する必要があります。これらの証拠レコードは、整合性を維持するために、リリース後に改ざんされないように保護する必要があります。
コード署名とパッケージの整合性
ユーザは、リリースされたソフトウェアが予期された組織から作成されたものであり、リリース後に変更されていないことを確認する必要があります。
コード署名は、以下のすべてのソフトウェアタイプに適用する必要があります。
コード署名はソフトウェアの変更を防ぐものではありませんが、不正な変更を確実に検出し、ソフトウェアが想定された発行元に由来することを保証します。
デプロイメント検証
インストール後、デプロイされたシステムが意図した環境で安全に動作することを確認します。検証アクティビティでは、以下の機能を確認します。
セキュリティ検証は、重大な構成変更が行われたときに必ず実行する必要があります。
デプロイメントの証拠
定義されたプロセスに従ってデプロイメントが実行されたことを示す記録を保持します。これらのレコードには、以下の例が含まれます。
これらのレコードは、顧客監査、サプライヤ評価、規制レビュー、および内部セキュリティ調査において、貴重なトレーサビリティを提供します。
ソフトウェアの脆弱性とは、ソフトウェアの設計、実装、構成、または運用プロセスにおける弱点、瑕疵、または欠陥であり、システムまたはそのデータの機密性、整合性、可用性を損なうために悪用される可能性があります。脆弱性は、チームが開発したコード、またはソフトウェアで使用されているコンポーネントの1つで特定される可能性があります。脆弱性は悪意のあるアクターがシステムに損害を与える手段となるため、これらの脆弱性を修正し、影響を受けるシステムに修正を適用することが重要です。
テスト業界は、脆弱性への対応という歴史的な課題に直面しています。多くのテストプロジェクトは、単一の先行投資モデルによって資金を供給され、システムの継続的なメンテナンスのための資金は提供されません。つまり、テストチームは、セキュリティ更新を提供するだけでも、システムを更新するためのリソースを持っていません。これは、システムを最新の状態に維持するためのセキュリティ要件と直接矛盾します。
大きな課題は、更新に必要な検証の量です。ソフトウェアおよびハードウェアツールに費用がかからない場合でも、更新後にシステムが意図したとおりに動作することを確認するには、更新に非常に費用がかかります。
セキュリティ業界の変化に伴い、テスト業界も変化し始め、テストシステムのライフサイクル全体にわたって計画と資金調達を改善する必要があります。テストチームは、完全なライフサイクル管理アプローチに移行するためのいくつかの手順を実行できます。
LabVIEW、ドライバ、およびその他のソフトウェアを含むNI製品の脆弱性をni.com/securityで発表します。また、パッチはCVE (Common Vulnerabilities and Exposures) システムを介して報告されます。これらのパッチは、NIのエンジニアが開発したソフトウェアコードまたは使用するコンポーネントの脆弱性を修正する可能性があります。新しいパッチの通知は、ni.com/securityから登録できます。
SBOMは、ソフトウェアのスキャンを自動化するためにも使用できます。LabVIEWアプリケーションからSBOMを生成する場合、報告された問題がCVEデータベースでチェックされ、通知されるようにスキャンソフトウェアを設定できます。SBOMをスキャンしてCVEデータベースと照合するさまざまなソフトウェア構成解析 (SCA) ツールがあります。
エンドユーザが脆弱性を特定した場合は、その脆弱性を直接報告できます。NIソフトウェアに問題がある場合は、ni.com/securityからその旨をご連絡ください。
脆弱性レポートを真剣に考えることが重要です。ユーザから問題が報告された場合、またはソフトウェアスタックに脆弱性が報告された場合は、脆弱性を分析して影響と悪用の可能性を確認します。これらの問題は、脆弱性の性質と影響を受けるソフトウェアコンポーネントの使用方法によって影響を受けます。悪用の脅威が大きいと判断した場合は、ソフトウェアを更新してエンドユーザにパッチを発行する必要があります。
欧州サイバーレジリエンス法 (CRA) などの一部の規制では、セキュリティパッチを5年以上提供する必要があります。契約によっては、サポート契約の期間が長い場合と短い場合があります。プロジェクトの納品後に予期しない事態を避けるため、最初のプロジェクト提案でこのレベルのサポートを計画します。
脆弱性修復プロセスの一環として、脆弱性の根本原因分析を実施し、開発プロセスを改善して、今後のプロジェクトで同様の問題を排除します。
セキュアなソフトウェア開発は、プロジェクト終了時に行う独立した作業ではありません。これは、システムのライフサイクル全体にわたって統合された一連のプラクティスです。このガイドに記載されている原則を採用することにより、LabVIEWチームは脆弱性を減らし、保守性を向上させ、コンプライアンス作業を簡素化し、任せられたシステムとデータをより適切に保護することができます。セキュリティはプロセスであり、チームは時間の経過とともに成熟していきます。製品の寿命を通じてセキュリティを継続的に改善する、反復可能で持続可能なプロセスを確立するために今すぐ開始してください。
| 脅威 | セキュリティ要件 |
|---|---|
| テスト結果の不正な変更 | 適切な役割を持つ認証されたユーザのみが、保存されたテスト結果を変更できます。 |
| ネットワークトラフィックの傍受 | アプリケーションと外部システム間のすべての通信には、暗号化されたプロトコルを使用する必要があります。 |
| キャリブレーションデータの破損 | 校正データは不正な変更から保護され、すべての変更がロギングされます。 |
| 不正な機器制御 | 管理または危険な機器の操作には、認証および認可されたユーザが必要です。 |