模擬試験(ドメイン6)

ドメイン6の試験です。

70%以上で合格になります。

Results

すばらしい!

まだ見ていないコンテンツがあるかも。

#1. ペネトレーションテストを適切に実施した後、最後のプロセスとして行うことは何でしょうか。

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

#2. 開発したプログラムは机上で問題ないことを確認している。しかし、実際に動かす必要があると依頼を受けた。どのようなテストを行うべきか。

〇:動的テスト

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

 

×:静的テスト

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

 

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

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

 

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

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

#3. BtoC向けのアプリケーションに対するテストを行う際に、重要な観点はどれでしょうか。

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

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

 

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

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

 

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

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

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

 

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

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

#4. ペネトレーションのテスターがブラックボックステストを行っているとき、彼らはターゲットについてどのくらいの知識を持っていますか?

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

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

 

×:すべて知っている。

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

 

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

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

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

 

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

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

#5. あなたはオープンソースを利用してアプリケーションを開発しました。テストはどうすべきでしょうか。

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

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

 

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

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

 

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

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

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

 

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

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

#6. コードレビューとは何ですか?

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

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

 

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

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

 

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

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

 

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

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

#7. 経営陣にセキュリティ報告書を提出する場合、以下のうち最も重要な要素はどれですか?

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

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

 

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

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

 

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

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

 

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

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

#8. スケジュール上、単体テストが間に合わないと分かった。プロジェクト管理の観点からどのようにするべきか。

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

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

 

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

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

 

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

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

 

×:上司に報告する。

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

#9. ペネトレーションテストを行う前に行わければならないことはどれでしょうか。

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

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

 

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

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

 

×:OSバージョンの確認

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

 

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

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

#10. セキュリティ監査、脆弱性評価、および侵入テストに関して、正しいものはどれですか?

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

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

 

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

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

 

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

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

 

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

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

#11. インターフェーステストと悪用ケーステストとの違いは何ですか?

〇:インターフェーステストは正しい状態において正しく動作することを確認する意図があります。悪用テストはエラー状態において問題が起こるかどうかを確認する意図があります。

すべてのアプリは、適切に機能し使用できるように、インターフェイステストを受けなければなりません。それらの意図的な悪用が、アプリケーションがアクセスを提供するデータの機密性、完全性、および可用性を害するエラーを引き起こす可能性があるかどうかを判断するために、誤用ケーステストを受けるべきである。

 

×:インターフェーステストはエラー状態において問題が起こるかどうかを確認する意図があります。悪用テストは正しい状態において正しく動作することを確認する意図があります。

正しい動きをすることを前提として誤った動きが見つかることはあるかもしれませんが、試験も目的という観点では文章の説明が逆になっています。

 

×:インターフェーステストはユーザービリティが適切かを確認する意図があります。悪用テストはエラーの発生するタイミングを監視します。

インターフェースはユーザービリティに限りません。サーバー間通信のAPIに対する試験でもあります。

 

×:インターフェーステストと悪用テストは本質的に同じです。

本質的には、試験の目的やその目的を達成するための環境づくりが異なります。

#12. 合成トランザクションとは何ですか?

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

#13. ソフトウェアをテストしたところ、10,000を超える欠陥が見つかりました。次のステップはどうあるべきですか?

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

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

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

 

×:すべて修正する。

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

 

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

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

 

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

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

#14. ソフトウェアテストの一環として回帰テストでは何が実施されるでしょうか。

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

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

 

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

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

 

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

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

 

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

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

#15. ペネトレーションのテスターがホワイトボックステストを行っているとき、彼らはターゲットについてどのくらいの知識を持っていますか?

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

終了