T&E の専門知識は、システムのライフサイクルの開発プロセス中にシステムの長所と短所を早期に認識することにあります。

リスク管理に必要な意識

モデルとシミュレーションを検証するための経験的データ

技術的なパフォーマンスとシステムの成熟度のテスト

運用と保守の効率、適応性、存続可能性の判断

リスクを特定、管理、軽減する

リスク管理に必要な意識

モデルとシミュレーションを検証するための経験的データ

技術的なパフォーマンスとシステムの成熟度のテスト

運用の有効性、適応性、生存可能性の判断。

スポンサー組織と協力して、プログラムの取得/開発をサポートするための T&E 戦略を確立または評価します。

リスクを徹底的に管理できる T&E メソッドを提供します。

T&E プロセスと必要となる可能性のある変更を監視します。

開発テストまたは運用テストのテスト計画と手順の適合性を評価し、推奨事項を提供します。

さらに、T&E 戦略を確立お​​よび実行するための買収/開発手順の背後にある理論的根拠を理解することが期待されます。

相互運用性テストなどの T&E テストの特定のアクティビティを理解することを期待します。

このグループは、T&E 統合製品チームと呼ばれることが多く、T&E の専門家、顧客ユーザーの代表者、その他の関係者で構成されます。

T&E 戦略は生きた文書であり、チームは必要に応じて更新する責任があります。

チームは、T&E プロセスに買収戦略が含まれていること、およびシステムが使用される機能に基づいた運用要件を満たしていることを確認する必要があります。

たとえば、ルーティング ログ分析は、セキュリティ インシデント、ポリシー違反、不正行為、運用上の問題を特定するのに役立ちます。

監査とフォレンジック調査を実施します。

内部調査をサポートします。

ベースラインを確立します。

運用傾向を特定し、長期的な問題を特定します。

限られたログ管理リソースと継続的に生成されるログ データのバランスを取る必要がある

ログの生成と保存

ログの整合性、機密性、可用性を保護する必要がある

セキュリティを確保し、システムおよびネットワーク管理者はログ データを定期的かつ効果的に分析します。

ロギングの要件と目標を定義する

ロギングの要件と推奨事項は、ロギングの実装と維持に必要なリソースと詳細な分析手法とともに生成する必要があります。

オリジナルログの保護

認識されている組織のリスク軽減と、ログ管理の実行に必要なリソースと予想時間に基づいて、ログと要件を最適化します。

ログ管理の責任と役割を確立する

ログ管理アーキテクチャには、ログの生成、送信、保存、分析、処理に使用されるハードウェア、ソフトウェア、ネットワーク、およびメディアが含まれます。

ログ管理フレームワークを設計する場合は、管理フレームワークの現在および将来のニーズと、組織全体の独立したログ ソースを考慮する必要があります。

システム管理者は適切なサポートを受ける必要があります。

情報の発信、研修の実施、質疑応答の窓口の提供など、 具体的な技術ガイダンス、対応するツールやドキュメントなどを提供します。

ログ管理者の責任

ログ管理プロセス

ログソース

チャレンジ

重要な実践

Web またはアプリ上のすべてのユーザーのすべてのトランザクションをキャプチャまたは分析するように設計された Web 監視手法

リアルユーザー測定、リアルユーザーメトリクス、またはエンドユーザーエクスペリエンスモニタリング (EUM) エンドユーザーエクスペリエンスモニタリングとも呼ばれます。

パッシブモニタリング パッシブモニタリング方式

モニターモード

プロアクティブな監視 プロアクティブまたは事前対応型の監視アプローチ

実際のユーザーセッションを追跡しません

クライアントによる完全な制御が可能 クライアントを完全に制御

Microsoft System Center 運用管理ソフトウェア

値を増やす

ユーザーデータに影響するチェック漏れ、SQLインジェクション（入力検証）などの不適切なプログラミングパターン

セキュリティ インフラストラクチャの不一致: 過剰なアクセス制御または弱い暗号化構成。

セキュリティ インフラストラクチャの機能エラー: アクセス制御実施機能自体はシステムへのアクセスを制限しません。

実装プロセスにおける論理エラー: たとえば、ユーザーが料金を支払わずに注文した場合などです。

トップ25

ホワイト ボックス (構造テスト/オープン ボックス テスト) vs ブラック ボックス テスト (機能テスト/クローズ ボックス テスト)

動的テスト VS. 静的テスト 動的テストと静的テスト

手動と自動化 手動テストと自動テスト

攻撃対象領域

アプリの種類

品質

サポート技術

パフォーマンスとリソース使用率

アーキテクチャのセキュリティのレビュー

脅威モデリング -

静的ソース コード分析 (SAST) と手動コード レビュー (静的コード分析と手動コード レビュー)

静的バイナリ コード分析と手動バイナリ レビュー (静的バイナリ コード分析と手動バイナリ レビュー)

手動または自動の侵入テスト

自動脆弱性スキャン

ファズテストツール ファズテストツール

システムの動作を監視し、システム ログを分析するには、パッシブ セキュリティ テスト テクノロジを使用することをお勧めします。

ソフトウェアのメンテナンス中はパッチテストが非常に重要です

ソフトウェアのテストには限界があり、100% のテストを完了することは不可能です

テスト計画とテスト ケースは、ソフトウェア開発段階のできるだけ早い段階で作成する必要があります。

ソフトウェア セキュリティ テストは通常​​、ユニット レベルのテストで始まり、システム レベルのテストで終わります。

構造化されたテスト (「ホワイトボックス」テスト) 開封テスト

テスト ケースは、ソース コード、詳細な設計仕様、その他の開発ドキュメントから得られた知識に基づいています。

ステートメントの対象範囲 ステートメントの範囲

決定（支店）カバレッジ 決定カバレッジ

条件補償条件補償範囲、

複数条件のカバレッジ 複数条件のカバレッジ

ループ カバレッジ ループ カバレッジ

パス カバレッジ パス カバレッジ

データ フロー カバレッジ データ フロー カバレッジ

テスト ケースは、ソフトウェア製品が具体的に実行することになっている内容に基づいて定義されます。

テスト ケースの主な課題は、プログラムの使用目的と機能、およびプログラムの内部および外部インターフェイスです。

機能テストは、単体テストからシステム レベルのテストまで、あらゆるレベルのソフトウェア テストに適用する必要があります。

通常のケース 一般的な使用例

出力強制出力要件、

堅牢性 堅牢性

入力の組み合わせ 入力の組み合わせ

弱さ

高い構造範囲を提供します

動作環境 (ソフトウェア製品の意図された使用、危険な使用、または悪意のある使用) に基づいて定義されたディストリビューションからランダム データを生成します。

大量のテスト データを生成し、それを使用して特定の領域や懸念事項をカバーすることで、設計者やテスト担当者が予期しなかった単一の非常にまれな動作条件を特定できる可能性が高まります。

理由

目的

ユニット（モジュールまたはコンポーネント）レベルのテスト 単体テスト

統合レベルのテスト 統合テスト（モジュール間のインターフェースのテスト）

システムレベルのテスト システムテスト

受け入れテスト

システム テストでは、特定の環境におけるソフトウェア製品の動作が示されます。

テスト手順、テストデータ、およびテスト結果は、合否を決定できる方法で文書化する必要があります。

エンタープライズ ソフトウェア製品は複雑であり、ソフトウェア製品のテストでは一貫性、完全性、有効性を維持する必要があります。

ソフトウェアのメンテナンス作業はハードウェアのメンテナンスとは異なります。ハードウェアには予防メンテナンス手段がありますが、ソフトウェアにはありません。

変更の有効な検証が必要です

ソフトウェア検証計画の改訂ソフトウェア検証計画の改訂、

異常評価例外検証、

問題の特定と解決策の追跡 問題の特定と解決策の追跡、

提案された変更評価 変更評価をリクエストする

タスクの反復タスクの反復、

ドキュメントの更新 ドキュメントの更新

システムを使用する一般ユーザーの視点からのテストケース

システムに悪意を持った人の視点から見たユースケース。

アプリケーションが期待どおりに動作することを確認し、フォワード テスト中にエラーが見つかった場合は失敗するようにします。

アプリが無効な入力や予期しないユーザーの動作を適切に処理するようにしてください。

これは主に、アプリケーションまたはシステム開発のさまざまなコンポーネントが相互に同期しているかどうかをチェックします。

技術レベルから見ると、インターフェーステストは主に次のようなさまざまな機能を決定するために使用されます。 システムのさまざまな要素間でデータが設計どおりに転送されるかどうか。

ソフトウェアの品質を保証するために使用されます

ディスカバリー、ターゲットに関する情報収集（ディスカバリー）

ポートスキャンおよびリソース識別方法の列挙、実行

脆弱性の調査、特定されたシステムおよびリソースの脆弱性を特定する

不正アクセスを取得するために脆弱性を悪用する、悪用を試みる

経営者に報告し、報告書と安全性に関する推奨事項を経営者に提出します

ブラック ボックス テスト、理解ゼロ、ペネトレーション チームはテストの目標を理解せずにテストを行う

グレーボックステスト、テスト目標に関連するいくつかの情報を知っていることに基づいたテスト

ホワイトボックステスト、対象の本質を理解したテスト

知識0

部分的な知識

すべての知識

さまざまな電話番号にダイヤルして、利用可能なモデムを見つけます

一部の組織では今でも通信のバックアップにモデムを使用しています

戦争ダイヤルは、ファイアウォールや侵入検知システム (IDS) を回避するために設計された組織のネットワークへの侵入の一形態です。

ウォー ダイヤル攻撃には、ダイヤルイン アクセスを通じて組織の内部コンピューティングおよびネットワーク リソースにアクセスしようとする試みが含まれます。 これはハッカーにとって利便性をもたらします。

セルフテスト

カーネル層に脆弱性がある

対策: 脆弱性の範囲を可能な限り小さく保つために、環境内で適切なテストを行った後、オペレーティング システムへのセキュリティ パッチが直ちに展開されるようにします。

対策: 適切なプログラミング実践と開発教育、自動スキャナーのソース コード、 強力な言語型付けを使用してバッファ オーバーフローを禁止するための強化されたプログラミング ライブラリ

ハッカーはシンボリック リンクをリダイレクトして不正アクセスを取得します。

対策: プログラム (特にスクリプト) を作成する場合、ファイルのフルパスを避ける方法はありません。

ファイル記述子は、プロセス内で開いているファイルを表すために多くのオペレーティング システムで使用される番号であり、特定のファイル記述子番号は普遍的であり、すべてのプログラムに対して同じ意味を持ちます。

プログラムがファイル記述子を安全でない方法で使用すると、攻撃者がプログラムの特権を悪用して、プログラムに予期しない入力を提供したり、出力が予期しない場所に出力されたりする可能性があります。

対策: 適切なプログラミングの実践と開発教育、自動ソース コード スキャナー、およびアプリケーションのセキュリティ テストはすべて、この種の脆弱性を軽減する方法です。

手順を実行する前に環境脆弱性要因を排除しない

攻撃者が予期しないデータを読み書きしたり、不正なコマンドを実行したりする可能性があります。

対策: 適切なプログラミング実践と開発教育、自動ソース コード スキャナーとアプリケーション セキュリティ テスト

親プロセスが子プロセスを作成するときは、競合状態と最小限の許可に注意を払う必要があります。

不適切なファイルまたはディレクトリのアクセス許可

対策: ファイルの整合性をチェックし、予想されるファイルとディレクトリのアクセス許可もチェックします。

組織の情報セキュリティリスクの決定をサポートするために、現在の情報セキュリティ、脆弱性、危険性を定義するために使用される認識。

組織全体の情報セキュリティ監視をサポートするために使用される取り組みとプロセスは、上級リーダーによって定義された洗練された ISCM 戦略から始める必要があります。

これは、組織のリスク許容度を明確に理解した上で構築されており、企業が優先順位を設定し、組織全体のリスクの一貫性を管理するのに役立ちます。

すべての組織レベルでのセキュリティ体制の真の意味を提供する指標を含めます。

すべてのセキュリティ管理の継続的な有効性を確保します。

組織の使命/事業機能、国内法規制、ガイダンス、ガイダンス基準に基づく情報セキュリティ要件への準拠を検証します。

すべての組織の IT 資産に情報が提供され、資産セキュリティの可視化が支援されます。

組織システムと環境の変更に関する知識と管理を確保します。

脅威と脆弱性に対する認識を維持します。

連邦情報システムおよび組織の情報セキュリティ継続的監視 (ISCM)

ISCM プログラムは、事前に設定された測定指標に基づいてデータを収集するために確立されており、実装されているセキュリティ制御を通じて部分的に情報変更を悪用することが容易になります。

組織全体のリスク監視は、個別の手動プロセスや自動化されたプロセスのみに依存しても効果的に達成できません。

測定には、自動化ツールや手動手順によって生成された評価と監視から得られるすべてのセキュリティ関連情報が含まれ、意思決定とレポート要件をサポートするために有意義な情報に整理されます。

セキュリティ体制を維持または改善するには、指標は特定の目標に基づいて決定される必要があります。

メトリクスは、ミッション/ビジネスコンテキストまたは組織のリスク管理を理解するシステムレベルのデータを作成します。

測定メトリクスは、さまざまな時間およびさまざまなレベルの遅延で取得されたセキュリティ関連情報です。

セキュリティ制御の不安定性セキュリティ制御の不安定性

システム カテゴリ/影響レベル システム カテゴリ/影響レベル

重要な機能を提供するセキュリティ コントロールまたは特定の評価オブジェクト重要な機能を提供するセキュリティ コントロールまたは特定の評価オブジェクト

弱点が特定されたセキュリティ管理 弱点が特定されたセキュリティ管理

組織のリスク許容度 組織のリスク許容度、

脅威情報脅威情報

脆弱性情報

リスク評価結果リスク評価結果

報告要件通知要件

たとえば、米国連邦情報セキュリティ管理法 (FISMA 連邦情報セキュリティ管理法) は、連邦政府機関に対し、組織の情報セキュリティ システムの自己監査と独立した第三者による監査を少なくとも年に 1 回実施することを義務付けています。

情報セキュリティの専門家は、保護を提供するために法的標準に概説されている要件を理解する必要がありますが、情報システムの完全な保護やリスク管理が達成されることはほとんどありません。

情報セキュリティの専門家は、ターゲット システムに適切なレベルで適切な数の制御を取得するために、適切な範囲と調整を確保する必要があります。

コアコンピテンシーに集中し、経費を削減し、新しいアプリケーション機能をより迅速に展開するために、組織は システム、ビジネスプロセス、データ処理をサービスプロバイダーに継続的にアウトソーシングする。

組織は、アウトソーシング サービス プロバイダーの監視プロセスと管理およびアウトソーシング リスクを頻繁に更新します。

これまで多くの組織は、アウトソーシング活動を快適に行うために監査基準に関するステートメント (SAS) 70 レポートに依存してきました。しかし、SAS 70 は、システムの可用性やセキュリティではなく、財務報告に係る内部統制 (ICOFR) に重点を置いています。

SAS70 レポートは 2011 年に廃止され、SOC (Service Organization Control) レポートに置き換えられました。

彼らは組織内の作業プロセスに精通しています。

高い作業効率

最も問題のある点を正確に特定できる

これにより、監査の作業がより柔軟になり、経営者は監査のニーズを常に変更できるため、監査チームはそれに応じて監査計画を調整できます。

情報システムへのアクセスは比較的限られている

客観性を損なう利益相反が生じる可能性があります。

さまざまな情報システムを監査しており、豊富な経験を持っています

彼らは、対象となる組織内の力学や政治性を知りません。客観的かつ中立的な立場を保ちます

高コスト

NDA があったとしても、追加されたリソースを整理して作業を監督する必要があります。

組織の内部の仕組みに対する理解が不足している。

SOC 1/SOC 2 レポートとは対照的に、SOC 1 レポートでは、サービス プロバイダーが自社のシステムを説明し、財務報告に対する内部統制に関連する管理目標と統制を定義することが求められます。

SOC1 レポートは通常、ユーザーの ICOFR レポートに関係のないサービスや制御はカバーしません。

SOC1 レポートは、2011 年に多くのサービス プロバイダーによって中核的な金融処理サービスに使用され始めました。

設計と運用の有効性を対象とした一定期間のレポート 一定の期間にわたる設計と運用の有効性を対象としたレポート

原則とガイドラインでは、セキュリティ、可用性、機密性、処理の完全性、プライバシーを具体的に定義しています。

財務報告に関する内部統制 (ICOFR) を超えたものを提供します。

サービスプロバイダーとそのユーザーのニーズに基づいて、モジュール式のアプローチを使用して、 SOC2/SOC3 レポートは 1 つ以上の原則をカバーできます。

IT サービス プロバイダーがユーザーの金融システムに影響を与えないか、間接的に影響を与える場合は、SOC2 レポートが使用されます。

SOC3 レポートは通常、詳細な制御やテスト結果を公開せずに、幅広いユーザーに保証レベルを知らせるために使用されます。

1. 新入社員は利用規定 (AUP) を読み、署名する必要があります。

2. 従業員のアカウントを監査して、従業員が AUP に準拠していることを確認します。

3. 人事部門から新入社員のリストを取得し、IT 部門がシステムに開設した従業員アカウントと比較して、2 つの部門間のコミュニケーションの有効性を確保します。

4. ポリシーでは、アカウントの有効期限、パスワード ポリシー、ユーザーがアクセスできる情報の範囲も明確にする必要があります。

特権アカウントの使用に関する問題

1. 通常、各コンピュータ ユーザー アカウントにはローカル管理者権限があり、サーバー管理および保守担当者にはドメイン管理者権限が与えられますが、どちらも危険です。

2. アカウントの追加、削除、変更は厳密に管理され、文書化される必要があります。

3. 管理者アカウントの権限の階層管理を実装します。

4. 必要な場合にのみ特権アカウントを使用し、日常のメンテナンス作業には制限付きアカウントを使用します。

1. 使用されなくなったアカウントを一時停止します。

2. 人的資源省から短期および長期離職者のリストを入手します。 アカウントの状況をITシステムと照合し、長期休業している従業員のアカウントを削除します。 また、短期休職の場合はアカウントの利用を停止します。

ユーザーファイル

データベース

メールデータ

テストデータのバックアップ状況

組織が直面する可能性のある脅威のさまざまなシナリオを分析する

各シナリオですべてのミッションクリティカルなデータのバックアップをテストする計画を作成します。

自動化を活用して監査人の作業負荷を最小限に抑え、テストが定期的に行われるようにします

データ バックアップ テスト計画がビジネス プロセスに与える影響を最小限に抑え、定期的に実行できるようにします。

すべてのシステムがテストされるようにカバレッジを確保しますが、必ずしも同じテスト内でテストされる必要はありません。

結果を記録して、何がうまくいったのか、何が必要だったのかを把握できるようにする

文書化した問題を修正または改善します。

チェックリストテスト チェックリストテスト

構造化ウォークスルー テスト 構造化ウォークスルー テスト

シミュレーションテスト シミュレーションテスト

並列テスト 並列テスト

完全遮断テスト 完全遮断テスト

安全トレーニングとは、人々が特定の機能をより良く実行できるようにするためのスキルまたは一連のスキルを教えるプロセスを指します。

セキュリティ意識向上トレーニングは、人々がセキュリティ問題を認識し、より適切に対応できるようにするためのプロセスです。

情報セキュリティの文脈では、個人を操作してセキュリティ プロトコルに違反するアクションを実行させるプロセスです。

フィッシングは、デジタル通信を介したソーシャル エンジニアリングです。

ドライバーのダウンロードは、悪意のある Web サイトにアクセスするだけで引き起こされる自動攻撃です。

主要業績評価指標 (KPI) は、組織が特定の時間に特定のタスクをどれだけ効果的に実行するかを測定します。

特定のアクションまたは一連のアクションの実行に固有のリスクの尺度。

技術レポートは、自動スキャン ツールや一般的なインベントリの出力以上のものである必要があります。

優れた監査技術報告書の要素

上級リーダーへのレポートは、重要な調査結果と推奨事項に焦点を当て、簡潔で理解しやすいものにする必要があります。

リスクは定量的に説明するのが最も適切であり、リスクを定量化する 1 つの方法は、リスクを金額で表すことです。

一般的なリスク測定方法

管理レビューは定期的に実行する必要があります。そうしないと、検査リスクが事前対応型から事後対応型に変化してしまいます。

会議の頻度は、前回のレビューの決定を実行するのに必要な時間の長さと同期する必要もあります。

入力内容を確認する

管理アクション