<< June 2018 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>

テクニカルエンジニア(情報セキュリティ) 午前終了

会心の出来とは言えないが8割は確実

俺の解答
問 1〜10 エエイエエ イアイアウ
問11〜20 エアウイア アイウアエ
問21〜30 アアアイエ ウエエウイ
問31〜40 ウイウウエ イイエイア
問41〜50 イエウエア アエアエア
問51〜55 エアアアウ
ss2004 * テクニカルエンジニア(情報セキュリティ) * 10:47 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 本試験当日

とうとう本番。

目標は、合格かつ合計点2100。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 07:07 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 予想問題集 午後1 問3-1〜8


  • 無線AP(オーセンティケータ)がRADIUSサーバに認証を求めるときにはUDPを使用する。
  • MD5は認証のためのプロトコルでありかぎ交換の仕組みをもたないため、WEPキーの自動生成はできない。
  • 証明書の検証には、「ルートCAまでの証明書の署名の真正性」「各証明書の有効期限」「各証明書が失効していないか」を確認する。
  • 問3-6設問3(1)、設問と解答が不整合。「最新のパッチを適用すると問題の発生するケース」ではなく、「最新のパッチが適用されているかどうかをチェックすると」とすべき。
  • 認証スイッチでは、スイッチのポート単位に認証を行う。認証機能のないハブをカスケード接続すると、2台目以降のPC等が認証を受けずに接続できてしまう。そのため、MACアドレス制限をかける。
  • WEPのぜい弱性 ・・・ 「かぎ交換の仕組みがない」、「IVが短く暗号かぎの強度が弱い」、「かぎがAPごとに共通」。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 13:41 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 予想問題集 午後1 問2-4


  • フレームを用いたホームページの、一部のフレームを偽のページに書き換える攻撃がある(ブラウザにぜい弱性がある場合)。
  • XSSでホームページを書き換えることが可能。
  • 証明書自体の真正性は、署名のフィンガープリントを照合することで確認する。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 22:33 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 予想問題集 午後1 問1-6〜7


  • データベースに接続するアプリケーションのソース中にユーザIDやパスワードは置かない。別ファイルにし、公開ディレクトリ以外に置く。
  • データベースにアクセスするユーザは管理ユーザやオブジェクト所有者とせず、必要最小限の権限を与える。
  • DBIのprepareメソッドでSQL文のひな形(バインド変数部分を?で記述)を与え、executeメソッドでバインド変数をセットして実行する。
  • プレースホルダに代入される変数は、メタ文字がエスケープ処理され、文字列定数として与えられるので、SQLインジェクションを防止する。
  • DBソフトの名称やバージョン、テーブル構造に関するヒントを与えないために、エラーメッセージを抑制する。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 22:17 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 予想問題集 午後1 問1-1〜5


  • HTTPの基本認証(ベーシック認証)は、ユーザIDとパスワードをBase64でエンコードし、Authorizationヘッダにセットして送信する。
  • 基本認証では、ブラウザを終了させるしか、セッション情報を破棄する方法がない。
  • TKIPのIVの長さは48ビットで、WEPの場合の2倍である。
  • TKIPでは、暗号かぎを生成する際の種にMACアドレスを含むため、端末ごとに暗号かぎが異なる。
  • BOF攻撃で実行させられるコードをシェルコードという(狭義の「UNIXのシェルを起動するコード」の一般化)。
  • BOF対策のStackGuardでは、「カナリア」をリターンアドレスの前に置く。カナリアが書き換わっているときは、リターンアドレスが信用できないので、プログラムを停止する。
  • LibSafeは、標準ライブラリのBOFぜい弱性のある関数を対策済みの関数と置き換える。
  • StackGuardは再コンパイルが必要だが、LibSafeは不要。
  • クッキー中のセッションIDが漏えいしないようにするには、SSLで通信を行い(盗聴を防ぐ)、クッキーにsecure属性を設定(SSL通信時のみクッキーを送付)する。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 00:12 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) アイテック 公開模試 結果

ITEC公開模試の結果が届いた。

 得点偏差値順位判定
午前100/11073.713/704A
午後197/12075.784/697A
午後284/12066.8826/696A
総合281/35074.486/696A


午後2の評価Aはギリ(基準を見ると84点以上がAのため)。
あの程度の出来で、この順位。母集団のレベルを疑う。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 19:39 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 記述式・事例解析 第13章 情報セキュリティマネジメント

H14SS午後2問2から
設問3(1) 「ICカードを身分証とは別に作成する理由」を問う問題だが、「ICカードを偽造されると、ドアの開閉については社員番号しかチェックされず、無人による管理であるため、誰でも入室できるというリスク」という答はひどすぎる。このリスクは、身分証と別にしてもまったく改善されない。また、このリスクを改善するには、有人管理や多要素認証を導入することになり、次の設問と同じ内容になってしまうのも不適切である。
ICカードに身分証としての機能を持たせているために、会社名・所属・氏名を目に見える形で載せることになり、これがリスクになっていると考える。
すなわち、他人の入室証を入手した人間が、その入室証で入室できるエリアを推測しやすくなるからである。特に社外で紛失した場合、会社名・所属・氏名が入っている場合と、何の表記もな射場愛では、不正に使用される可能性はかなり違ってくる。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 23:33 * comments(2) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 記述式・事例解析 第10章 セキュアプログラミング


  • ";"はSQL文の区切りを示すため、SQLインジェクションでまったく新たなSQL文を追加され実行させられるおそれがある。ところで、";"のエスケープは"¥;"でよいのか?
  • 再びH18午後1問1だが、「128ビットが120ビットだからダメ」という理屈が腑に落ちない。「共通かぎの作り方から判断して」という限定がつくので、このような答にならざるを得ないが、表1の仕様では識別コードが60文字以上となっているところ、G君のコードでは実質46文字でしかないことが本質的な問題なのだと思う。
ss2004 * テクニカルエンジニア(情報セキュリティ) * 23:09 * comments(0) * trackbacks(0)

テクニカルエンジニア(情報セキュリティ) 記述式・事例解析 第9章 情報システムのセキュリティ

再びH18午後2問1

  • 設問3(2)の問題を「具体的に」というのは、「健康管理の検診結果が同じ部の人間すべてに閲覧可能になってしまう」という程度の具体性がなくていいのか。そう答えさせたければ、「例をあげよ」となるのだろうか。
  • 設問3(4)は、結局のところ、「アクセス権限が足りなかったので、権限を強めてもらった」という問題になってしまって、「権限が高い場合には書き込みができない」というMACの重要な特性を問う問題になっていない。情報処理技術者試験は、たまに教育的な問題(問題を解くことによってある技術や概念を理解させる類の問題)があるのだが、この問題はそうなっていないようだ。

ss2004 * テクニカルエンジニア(情報セキュリティ) * 22:52 * comments(0) * trackbacks(0)
このページの先頭へ