【日本語】初心者から学べるCISSP講座：CBK Domain 6

• 信頼構築の一環として、評価を得ましょう。

• 評価は定期的に行うべきです。

• 評価を行う者は、評価対象と利害関係がないことが求められます。

• 監査は、内部監査、外部監査、サードパーティ監査に分かれます。

• コンプライアンスチェックは内部的なルール順守を保証するための日常業務の一環として行われます。

• システムにおけるコンプライアンス対応の一つとして、 PCI-DSS、HIPAA、SOX、OWASP Top 10などの標準的な規格にシステム設計と実装が則ることが挙げられます。

• ログは自動的に収集され、安全に保管され続けなければなりません。

• ログの保管されているストレージには厳密なアクセス制限をする必要があります。

• ログの検索するシステムも実装したほうが良いでしょう。

• 脆弱性診断を行うチームは開発元と独立しているべきである。

• 脆弱性診断の期間は他のタスクとの並行稼働が難しいため、調べておくと良い。

• 脆弱性診断の規模感は一律ではなく、大きくなればそれだけ費用も期間も上がります。

• 脆弱性診断は攻撃にもなりうるため、事前に承認を得ておくことが大事です。

• 脆弱性診断の結果を開発アプリケーションに反映する必要もあります。

• 脆弱性診断の結果は真摯に受け止め、修正対応を心がけましょう。

• 自分の使っているコンポーネントの脆弱性が開発元から公開されるか、脆弱性診断ツールなどを利用した脆弱性診断によって、脆弱性が発見されます。

• NISTからは、SCAPという脆弱性情報の標準的は規格で公開されます。

• 自社システムに対して脆弱性検出を行う際には、ネットワーク、ウェブアプリケーション、データベースへのテストは必ず実施することを推奨いたします。

• NeccusやOpenVASは、脆弱性診断ツールで効率よくシステムの脆弱性を見つけよう。

• 基本評価基準とは、脆弱性そのものの特性を評価する基準です。

• 現状評価基準とは、脆弱性の現在の深刻度を評価する基準です。

• 環境評価基準とは、利用者を含め最終的な脆弱性の深刻度を評価する基準です。

• ペネトレーションテストの計画段階では、作業範囲の明確化と信頼できるペンテスターであるかを確認する必要があります。

• ビジネスを中断させたり、修正することはペンテストの目的ではありません。

• 知識の違いによって、 ホワイトボックス 、ブラックボックス、グレーボックスに分かれます。

• 攻撃チームと防御チームに分けて競わせることで、さらに実践的な傾向と対策を把握できるでしょう。

• 侵害攻撃シミュレーション （BAS）は、脆弱性実証のための複雑なサイバー攻撃をシミュレートする自動化ツールです。

• 悪用テストケースは、不都合な使われ方をした場合であっても、ユーザーを適切な操作に導くためのテストです。

• 攻撃の意図のない、不都合な使われ方をターゲットにします。

• システムの使用性を上げる側面もあります。

• ソフトウェアテストが適切に実施されないと、システムへの不正アクセス、アプリケーション経由での情報漏洩、ビジネスシステムの機能の停止の原因となりうる。

• プロジェクトの期間は限られているため、テストケースは効率的に消化していくことが求められます。

• ソフトウェア動作テストは、設計された事項に関して満たしているかどうかを確認する作業です。

• 静的テストとは、ウォークスルー、構文チェック、コードレビューなどの実行されていないコードへのテストです。

• 動的テストとは、HTTPリクエストを送付するなど実行中のコードに対するテストです。

• 単体テスト、結合テスト、システムテストを段階的に行う。それぞれ、詳細設計、基本設計、要件定義で決定された事項を満たしているかを確認する。

• システム個別要件に加え、ベンチマークもテストします。

• リリースすることで既存の他の一部の機能が使えなくなる可能性があるため、更新箇所以外もテストする。

• 合成トランザクションとは、動的スクリプトを利用し、実際の顧客のWebサイト利用をシミュレートするWebサイト監視です。

• テストの観点ごとにテストケースを整理する必要があります。同値分割法、境界値分析、デシジョンテーブル、状態遷移図を作成し、テストケースを洗い出します。

• テストケースに漏れがあってはいけませんが、効率的に実施するのは歓迎されます。

• オールペアテストとは、入力パラメータの各ペアの可能な離散的な組み合わせをすべて実行するようにテストケースを設計するものです。

• テストエビデンスは必ず取得し、保管しましょう。

• 欠陥の対応も、優先順位を付け効率的に行う。

• 修復するには、利害関係者の協力が必要です。

• 最も望ましいのは、故障しにくい設計をしたうえで、アプリケーションを”安全に”故障させることです。

• try catchステートメントは、tryブランチにエラーが発生する可能性のあるコードを記載し、catchブランチにエラーが発生した場合に実行されるコードを記載します。

• 倫理的社会的な影響を考え、脆弱性はむやみに公表しないでください。

• 分からなくても正答率が高いと思われる答えにフォーカスしていく力

• 各ドメインのポイントを押さえる

• 企業目標を達成するための達成するセキュリティ。

• 安全な状態などない。

• すべてはお金で説明。

• マネージャーとしての判断です。

お疲れさまでした！

英語版の証書もこちらからダウンロード可能です。