単体テストとは、開発したモジュールが単体で動くことを確認するテストです。結合テストとは、開発したモジュール同士を連結して全体動作を確認するテストです。

ペネトレーションテスト（侵入テスト）とは、ネットワークに接続されているシステムに対して侵入を試みるテストです。侵入できればあらゆる操作が可能になり、サービス自体を停止に追いやることができます。そのため、侵入にフォーカスをした試験を行うのです。計画、事前調査、脆弱性を探索、評価、攻撃、レポート作成の順番で行われます。よって正解は、「レポート作成」になります。

〇：致命的なエラーに対して影響を及ぼす可能性を計算する。

ソフトウェアテストの実施は必須ですが、そのテストによって欠陥が数多く見つかった場合には、慎重に対応する必要があります。システムに人間の忘却のような概念はないですが、今週のテスト30点の人に来週のテストで100点を取れと願いことは現実的とは言えません。

修正を行う前に、ログレビューなどテストが完了している状態で、テストから取得したデータを分析する必要があります。最初に何から実施するか、何が許容でき何が許容できないかの判断を優先する必要があります。定性的リスク分析について考え、可能性が低く影響が少ない場合は放置し、優先度の高い項目に焦点を当てることができます。よって正解は、「致命的なエラーに対して影響を及ぼす可能性を計算する。」になります。

×：すべて修正する。

多くの欠陥が見つかった場合には、その修正対応にも多くの時間がとられることが考えられます。

×：膨大な数であるため放置する。

欠陥を放置することは原則許されません。

×：すべてのエラーに対して影響を及ぼす可能性を計算する。

すべてのエラーに対して分析を行うこともまた、非常に作業量が多くなる可能性があります。

〇：単体テスト

単体テストには、制御された環境で個々のコンポーネントをテストして、データ構造、ロジック、および境界条件を検証する必要があります。 プログラマーはコンポーネントを開発した後、いくつかの異なる入力値とさまざまな状況でテストされます。 単体テストは開発の初期段階から開始することができ、通常は開発段階全体を通じて継続されます。 単体テストのメリットの1つは、開発サイクルの早い段階で問題を発見することです。個々のユニットに変更を加える方が簡単でコストがかかりません。

×：受け入れテスト

コードが顧客の要求を満たしていることを確認するために受け入れテストが行​​われるため、正しくありません。 このテストは、アプリケーションの一部または全部に適用されますが、通常は個別のコンポーネントではありません。

×：回帰テスト

回帰テストは、その機能、性能、および保護を確実にするために変更が行われた後のシステムの再テストを意味するため、正しくありません。 本質的に、回帰テストは、プログラム変更の結果として機能が意図したとおりに機能しなくなったバグを識別するために行われます。 開発者が1つの問題を修正したり、誤って新しい問題を作成したり、新しい問題を修正して古い問題を解決したりすることは珍しいことではありません。 回帰テストには、以前に修正されたバグをチェックして、それらが再出現していないことを確認し、以前のテストを再実行することが含まれます。

×：統合テスト

統合テストでは、設計仕様で概説されているようにコンポーネントが連携して動作することが確認されるため、正しくありません。 単体テストの後、個々のコンポーネントまたはユニットを組み合わせてテストし、機能、性能、および信頼性の要件を満たしていることを検証します。

〇：主たるコードの改変によるエラーを確認する。

回帰テストでは、コード変更が発生した後の欠陥の発見を行います。古いバグを含む、機能の低下または消失を探します。よって正解は、「主たるコードの改変によるエラーを確認する。」になります。

×：顧客のハードウェア上に開発したソフトウェアをインストールする。

テストではなく、リリースの一部に当たるものです。

×：障害に対面したときの検知と処理を確認する。

いわゆるトラブルシューティングであり、運用計画や手順書の運用チームへの引継ぎによって達成されます。

×：ソフトウェアのコンポーネントのインターフェースを確認する。

インターフェースに対するテストであり、内部結合試験や外部結合試験の試験項目の一部として実施されます。

〇：監査ログと監査証跡が十分な期間保存すべきである。

監査ログや監査証跡は、法廷での事実立証を裏付ける根拠として十分な期間保管しておくべきです。

✕：ログのレビューが定期的に行わないほうが良い。

ログのレビューは定期的に行い、欠陥の発見や潜在的な問題に対して感度を持つことも重要です。

✕：エラーなど結果の悪い監査ログのみレビューするべきだ。

結果の悪いログだけではなく、内部的にも処理が想定されたとおりに実行されているかにも目を配るべきです。

✕：すべてのシステムの通常運用時にもアプリケーションのトレースログを出力し、詳細な挙動を追跡する。

トレースログはアプリケーションの動作をきめ細かく出力する一方で、その量も膨大です。通常運用ではその機能がオフにされていることが一般的です。

〇：スケジュールを見直す。

単体テストとは、開発したモジュールが単体で動くことを確認するテストです。受入テストとは、開発を発注してくれたお客様に実際に使ってもらって納得してもらうテストです。単体テストの代わりに、受入テストで行うことはできません。テストとして上位互換ではなく、観点が異なるからです。よって正解は、「スケジュールを見直す。」になります。

×：作業効率のために単体テストは行わない。

単体テストを実施しないということはありません。

×：できなかった単体テスト分、受入テストの項目数を増やす。

実質単体テストで行うべき項目を受入テストとして計上しているだけで、単体テストが終わっているとは見なされません。これは、隠蔽にも近しい行為です。

×：上司に報告する。

プロジェクト管理の担当者はあなたです。

〇：権限昇格

権限昇格は、侵入後に実行することで攻撃の影響を大きくする手順です。一般的には、低い権限のアカウントで侵入し、権限昇格することで攻撃範囲を広げます。よって、攻撃対象を調査する段階で実行されるものではありません。よって、正解は「権限昇格」になります。

✕：ポートスキャン

ポートスキャンを行うことで外部からアクセス可能なサービスを列挙します。このような情報は攻撃を行うための収集されます。

✕：バナー表示される製品バージョンの確認

単純なアクセスによって製品がレスポンスを返却するとき、製品は自身の製品名やバージョンを返却することがあります。このような情報は攻撃を行うための収集されます。

✕：ディレクトリトラバーサル

Webアプリケーションなど通常はアクセスすることがないURLであっても、外部からアクセス可能なディレクトリが存在する場合もあります。このような情報は攻撃を行うための収集されます。

〇：動的テスト

動的テストとは、開発したプログラムを実際に動かして行うテストです。 静的テストと比較され、実際にプログラムを動かして確認してみる実践的なテストです。よって正解は、「動的テスト」になります。

×：静的テスト

静的テストとは、 開発したプログラムを動かさずに行うテストです。

×：ホワイトボックステスト

ホワイトボックステストとは、プログラムの中身を把握したうえで行う、プログラムの動作を確認するテストです。

×：ブラックボックステスト

ブラックボックステストとは、プログラムの中身を把握せずに予期せぬ動きをしないことを確認するテストです。

すべての組み合わせをテストケースとすると、27パターン（=3×3×3）になります。オールペアテストでは、ある2因子の組み合わせによってバグが発生することを想定し、9パターンのみ実施します。

アカウント管理のレビューにおいて、一般的に対象となるのは権限の高いアカウントです。権限の高いアカウントは、一般のアカウントに比べて高いセキュリティリスクを持っており、レビューの対象となります。

統計的な観点では「ランダムに抽出されたアカウント」も良い答えですが、統計的な目的でランダムなアカウントを調べる場合には、そのアカウントが有効であるかといった問題に焦点が当てられています。問題文の中の”セキュリティリスク”に対する関心を強調するのであれば、「高い権限を持つアカウント」が近いといえます。

アプリケーションのテストには、通常のユーザー動作をエミュレートする必要があります。 ただし、テスト環境では、ユーザーアクティビティの一般的な負荷は利用できません。 したがって、共通のユーザートランザクションのスクリプトを構築して、さまざまな形式のテストを容易にすることができます。

良く知らない単語の意味を聞かれた場合には、仲間外れを探すことでその正答率を高めることができます。例えば、「許可されてはならない偽のユーザートランザクション」、「レコードを改ざんするためのユーザーの行動」、「ポリシー違反に使用された攻撃者によるスクリプト処理」は、暗に不正なアクセスというグループに属します。

〇：包括的にまとめられたエグゼクティブサマリー

経営者への報告書がどれほど技術的に包括的であっても、情報量を多くすることは必ずしも望まれません。ITセキュリティ専門家は、データ漏洩による企業のリスクは、上級管理職が理解し優先順位をつけなければならない多くの懸念の一つに過ぎないことを理解しなければなりません。Cレベルのエグゼクティブは、多くのリスクに気を配らなければならず、よく知られていない高度な技術的脅威が適切に分類するのが難しい場合があります。 つまり、ITセキュリティ専門家の主な仕事は、リスクを管理に合った方法でできるだけ短く要約することです。

×：脅威、脆弱性、および発生する可能性のリスト

経営陣に報告する際に最も重要な要素ではないため、間違っています。 このようなリストは包括的なセキュリティレポートにとって不可欠ですが、経営幹部に提供することは、巧みな幹部要約がなければ効果的な行動を起こすことはまずありません。

×：予想される有害事象の確率および影響の包括的なリスト

経営陣に報告する際に最も重要な要素ではないため、間違っています。このようなリストは技術レポートでは重要ですが、リスク軽減の目標を達成するためには要約が重要です。

×：技術的に包括性を満たすための、脅威、脆弱性、および発生する可能性のリスト、予想される有害事象の確率および影響の包括的なリスト、そしてその要約書

管理者に報告する際に最も一般的で重大な障害となるものが記述されているため、間違っています。

〇：主要で利用されている複数の利用法を選別し、対象ブラウザ上で動作するかを確認するべきである。

BtoC向けのサービスであれば、対象となるユーザーをより多くのサポートすべきであると考えられます。よって正解は、「主要で利用されている複数の利用法を選別し、対象ブラウザ上で動作するかを確認するべきである。」になります。

×：ある特定のブラウザ上で動作するかを確認すればよい。

特定のブラウザでは、動作しないユーザーケースがリリース後に起きてしまうかもしれません。

×：最もセキュアなブラウザ上で動作するかを確認する。

セキュアであればブラウザの動きが制限されて、最も制限された中での動作を行うことが期待できます。

しかし、現実にはブラウザバックや端末など、ブラウザの仕様もまた様々です。

×：OS標準のブラウザ上で動作するかを確認する。

ブラウザはOS標準のものだけでありません。現実的にもエンドユーザーは気に入ったブラウザをアプリストアからダウンロードして利用しています。

〇：OSSTMMを参考にしながらテストする。

OSSTMM（Open Source Security Testing Methodology Manual）とは、オープンソースのペネトレーションテストの標準です。オープンソースは基本無料で驚くような機能を持ったものがたくさんあります。無料で誰でも使えることから信頼が低い見方があります。しかし、ちゃんとリスクを理解していればこれほど素晴らしいものはありません。そこで、オープンソースに対するテスト標準を作り、信頼を担保しようとしているのです。よって正解は、「OSSTMMを参考にしながらテストする。」になります。

×：オープンソースは開発時点で十分にテストされているため、テスト工程は省略できる。

オープンソースであっても自組織に合わせたテストをする必要があります。

×：開発者の連絡先を確保し、開発者ともにテストを実施する。

オープンソースの開発者に問い合わせても、こういった対応はおそらくスルーされるでしょう。

オープンソースの開発者のほとんどは善意で実施しているため、組織からの更なる追及に対しては図々しさを覚えるかもしれません。

×：他組織から完了済みテストの共有を依頼する。

他の組織から機密に当たる可能性のあるテスト結果をもらうという工程には無理があります。

ホワイトボックスソフトウェアテストでは、テスターはプログラムのソースコード、データ構造、変数などに完全に知っている状態で行います。

〇：公表されている情報以外は何も知らない。

ブラックボックステスト（ゼロ知識）では、攻撃者は公開されている情報以外に組織についての知識を持っていません。外部の攻撃者が行うことに焦点が当てられています。よって正解は、「公表されている情報以外は何も知らない。」になります。

×：すべて知っている。

ホワイトボックステストとは、プログラムの中身を把握したうえで行う、プログラムの動作を確認するテストです。

×：製品マニュアルを保持し、特権アクセスを保持している。

グレーボックステストとは、ある程度のペンテスターに攻撃者は限られた知識しか与えず行うテストです。

ホワイトボックステストやグレーボックステストに当たります。

×：ベンダーがアクセス可能なレベルの情報を保持している。

ブラックボックステストでは、攻撃者は原則情報を得ていません。

〇：対象組織への攻撃承認

計画段階で攻撃対象となる組織に許可を得ておく必要があります。テストとはいえ、攻撃に近しい行為を取ります。実施中には、対象のシステムの更新もできませんから、承認を得ていなければなりません。また、侵入するシステムについてきわめて詳細に理解する必要があるため、その情報自体が外部に漏れ出ないようにしなければいけません。また、侵入に成功した場合には、危険な状態であることがわかります。レポート作成まで待たずに一報するなど取り決めが必要です。よって正解は、「対象組織への攻撃承認」です。

×：対象組織の設計書の共有

必要に応じて実施します。設計書はさまざまありますが、詳細設計書やプログラム設計書など、詳細に至る設計書は基本的には提示せず、そのサービスの利用方法や基本的なサーバの構成について共有する程度になることが一般的です。

×：OSバージョンの確認

原則しません。ペネトレーションテストは、その攻撃の調査から実施することが一般的です。特にOSバージョンをペネトレーションのテスターに知らせるケースはほとんどありません。

×：利用する攻撃ツールの展開

ペネトレーションの対象となるシステムを所持している組織から攻撃ツールを展開することはまずありません。これ自体が、攻撃の手法を限定する行為であり、現実的なテストにならないためです。

〇：コーダーのコーディングが完了した後、他のコーダーによってレビューすること。

スタティックコードレビューでは、作成者の目には明らかにならなかった点を軽減するために、別のエンジニアによって行われるレビューです。よって正解は、「コーダーのコーディングが完了した後、他のコーダーによってレビューすること。」になります。

×：コーダーが互いのコーディングを見て並行して作業するようにすること。

エクストリームプログラミング（XP、extreme programming）とは、2人1組で話し合いながら柔軟にプログラム開発する方法です。コードレビューではありません。

×：チェックイン前に適切なトランザクション処理が適用されていることを確認すること。

データベースのコミットメントに関する記述です。

×：適切な質疑応答が存在することを確認すること。

適切な質疑応答があるかどうかは、コードレビューの中で実施される一部かもしれませんが、コードレビュー自体の説明ではありません。

〇：脆弱性評価は、取り組むべき弱点の優先順位付けに役立ちます。

内部または第三者による脆弱性評価の最も重要な側面は、企業が有するすべての潜在的な脆弱性を列挙し、是正措置を優先させることができることです。

×：第三者によるセキュリティ監査は、規制が要求する場合にのみ必要です。

一部の組織が独立したレビューを要求されなくても、しばしば見過ごされていたかもしれない軽い弱点を見つけることに役立ちます。

×：脆弱性評価と侵入テストは本質的に同じです。

脆弱性評価はすべての弱点を列挙し、その対策が適切に優先されるようにするため、間違っています。 侵入テストは、実世界の攻撃者が目標を達成するために与えられた弱点を悪用する可能性を調べることを目指しています。

×：内部評価はほとんど価値がありません。

エンタープライズセキュリティの内部監査は通常十分ではないため、第三者のレビューと連携して実施すると非常に有益です。ただし、しばしば見過ごされていたかもしれない軽い弱点を見つけることに役立ちますので、ほとんど役に立たないというほど悪いものでもありません。