情報処理安全確保支援士について

2017年4月から試験が実施されている情報処理安全確保支援士。

自分は2012年だか2013年だかの情報セキュリティスペシャリスト試験に合格しているので、
今年の夏だか秋だかまでは無試験で登録できるらしいが…

登録によるメリット
・情報処理安全確保支援士を名乗れる。
※情報処理安全確保支援士は業務独占資格ではない

登録によるデメリット
・いくつかの行為に罰則(懲役/罰金)がつく。秘密保持義務違反に関しては資格失効後も罰則の対象になる。
　法律で読む情報処理安全確保支援士 - Qiita
・資格維持に3年で15万円、登録に2万円くらいかかる。

ただの名称独占資格だし維持に大金かかるし
情報処理安全確保支援士の制度ができた頃から「デメリットしかないじゃねーか」と言われてるけど
この辺りは今も変わってないみたい。

せめて資格自体の知名度や社会的ステータスが高ければ、名称独占でも登録するメリットもあるんだろうけど
この調子だと普及するまでにも相当な時間がかかるんじゃなかろうか。

維持費も高すぎるんだよなー
3年で15万円とか個人で払う気しないもんね。会社が払ってくれないと。
ひょっとして、制度で求める人物像と登録者の層が乖離しすぎるのを防ぐためにこうしているのだろうか。
つまり「政府機関や企業等における情報セキュリティ確保支援」が支援士の仕事であり、
そんなのペーパー試験に受かっただけの学生にできるわけないから維持費を高く設定して
費用を会社負担してもらえる社会人だけが登録するように誘導しよう…という腹なのかもしれない。

でもそんなの「受験資格は業務経験X年以上、職務経歴書提出必須、抜き打ち調査あり」
っていうCISSP形式みたいにしてしまえば話は早いわけで
IPAが何を考えてるのかいまいちよくわかんない。

おそらく今年中に登録のメリットが増したりデメリットが減ったりすることはないだろうし
また試験を受けるのも面倒だし、自分が支援士に登録することはないだろうな。

Mini-FilterDriverのHLK対策 -OpLock-

Microsoftがドライバのサンプルを公開していますが、
その内のひとつであるscannerに対してHLKテストなんかでIFS TestやらOpLocks Testを実施すると、
おそらく失敗します。だってOpLock対策が不十分だから。

IRP_MJ_CREATEに関してMicrosoftが公開しているドキュメントなどにあるように、
フラグ判定を2か所に追加しなければなりません。

1．Pre-CreateでのFILE_COMPLETE_IF_OPLOCKED判定
if (FlagOn(Data->Iopb->Parameters.Create.Options, FILE_COMPLETE_IF_OPLOCKED))
return FLT_PREOP_SUCCESS_NO_CALLBACK;

2．Post-CreateでのSTATUS_OPLOCK_BREAK_IN_PROGRESS判定
if (FlagOn(Data->Iopb->Parameters.Create.Options, FILE_COMPLETE_IF_OPLOCKED)
&& Data->IoStatus.Status == STATUS_OPLOCK_BREAK_IN_PROGRESS)
return FLT_POSTOP_FINISHED_PROCESSING;

ただ、実はこれだけではIFS TestはPassできてもOpLocks TestはPassできません。
検証10-8でPost-Create時にFltReadFile()が実行されるとNTFSからの応答が途絶え、
FltReadFile()が完了せずハングアップしてしまうのです・・・。
(試験も手動で中断させるまで止まったままになるし結果は当然Failed)

Microsoft製のプログラムなのにMicrosoftの試験に落ちるってどういうことなの
ハードウェアの問題なのかな？あまり深く調べてないけどもう力尽きました。

以上、職場のWindowsServer2016でなんとなくHLKテストを実施してみた時の話でした。

占いの曲

占いは精神療法と似ているのかもしれない。

お金を払ってまで占い師のもとを訪ねるのは何かしら不安や迷いのある人で、
自分は今どんな状態にあるのか？自分がどうすればいいのか？
それを誰かに教えてもらいたいと思っているはずだ。

占い師は、たとえペテンであっても何かしら教えてくれる。
訪れた人は少しだけ、悩みが薄れたように感じる。

-------------------------

Mr.Childrenの曲に『過去と未来と交信する男』という歌がある。

とある占い師が客の過去と未来を見通し、
今どうあるべきか？を占うという内容の歌である。

曲名からして電波でサイコな印象を受けるし、
初めて聴いた時には「またダーツでも投げたのかな？」と思ったものだ。

しかし、よくよく聴いてみると、この曲は消極的な応援歌なのだとわかる。

ものすごく大まかに書くと、
「今は悩んでいてもこれから良いことあるさ」
という占い師然とした内容なのだ。

つまり、この曲を聴けば、
占いに行かずとも占いに行った気分と効果を味わえるというわけだ。

-------------------------

社会人として日々苦しむエンジニアのあなた。

上司や客や営業部から無理難題を強いられ、
「最近ちょっとお給料あがってる！」→「あぁ増えてるのは残業代か・・・」
と将来を悲観しつつあるあなた。

疲れた時には、この曲を聴いてみてはいかがだろうか。




ちなみにYouTubeのMr.Children公式チャンネルではこの曲の動画は公開されていない。
歌詞 - 『過去と未来と交信する男』

iTunesとかで単体でも買えるかもしれないがとりあえずアルバムを買うのをお勧めする。
Wikipedia - [(an imitation) blood orange]

SMTPでレスポンス分割...？

うちの製品に、メールで情報を送信する機能がある。
つまりSMTP通信を行う機能だ。

その機能について、某大企業の担当者から問い合わせがあった。
「メールが送信できません。」

うちのユーザサポート部署のFさんが詳しくヒアリングしてくれて、
開発部にいる僕に相談しにきた。

話を聞くと、どうやらお客さんの環境はかなり特殊なようだ。
それというのも、EHLOのレスポンスをUTMが分割しているというのだ。
送ってもらったパケットキャプチャを確認してみた。

普通ならレスポンスは1度にまとめて送られてくる。
しかしそのUTMは、SMTPサーバから受け取った複数行リプライを数行ずつ
計2つのパケットに分割して送ってきていたのだ。
SMTPのレスポンスを分割するなんて、僕は聞いたことがなかった。

SMTPのレスポンスは分割され得るものなのか？
インターネットで調べてもそんな例は見当たらない。
ネットワーク系にかなり詳しい同僚も、そんなの見たことないよと言う。
(ちなみにこの同僚、某世界的大手企業から『アジアNo.1セールスエンジニア』と認定されており、同業他社からスカウトされまくる凄い人である。)
これはどうしたものだろう。

～

そのUTM、実は問い合わせてきたお客さんの会社の製品である。
なので訊いてみた。分割の根拠と理由。
するとこんな回答があった。

「RFCに分割手法が書いてある。」
「ウィルスチェックのためにリプライを解析しており、タイムアウトを防ぐべく分割して送っている。」

～

SMTPについて記述されたRFC5321なら僕は読んだことがある。
しかしレスポンス分割に関係しそうなことなんて書かれてないはずだ。
念のために改めて読んでみたが、やはりそんなことは書かれていない。
お客さんが言っているのは別のRFCなのだろうか。
だとしたらSMTP以外の規約が絡んでくるということであり、すごく面倒だな。

Fさん経由で、根拠としているRFCの番号を訊いてみた。
結果は・・・

Fさん「RFC5321だそうです。4.2章のこの部分。」

5321かよ。
そして示された部分はEHLOの複数行リプライの文法に関する記述。
要約するとこんな内容である。
「最終行以外は2XX-xxxxxxxx、最終行はハイフンをスペースに変えて2XX xxxxxxxxとせよ」
「最終行にスペースが使われてなくても対応できるようにクライアントは準備しておけ」

はい。
これは1度のリプライが複数行に及ぶ場合の文法を定義してるわけで、
どう読んでもパケット分割に対応すべしと受け取ることはできないよね。
そもそもEHLOでパケット分割を許容するならDATAコマンド風な仕様になるはずだよね。
つまり五月雨送信の終了を明示的に表す情報が必ず送られてくるべきっていう仕様。

と思ったままをFさん経由で回答すると、
お客さんは案外あっさりと納得してくれた。
なんだそりゃ。

ちなみに、分割の理由についても思うところはある。
分割されたパケットの送信間隔は1秒にも満たない。
ならば分割などという致命的なRFC違反なんかしなくても、
レスポンスはひとまずそのまま送っておいて、もし問題ありと判定したなら
以降の通信を拒否すればいいのだ。ただそれだけ。

でもこの部分、Fさんはお客さんに伝えてない。
まぁ言えないよな。言う必要ないし。

～

うちのその製品では、EHLOのレスポンス内容に関わらず
ユーザが指定した設定に従ってSMTPコマンドを実行する。
これもRFCに則った動作とはいえないが、色々と事情があったのだ。
その分、通常はこの動作がネックにならないように作り込んでおり、
このお客さん以外のすべてのユーザ環境で正常稼働している。

今回お客さんはStartTLSとSMTP認証を使っていた。
なので具体的には、
「EHLOの分割レスポンス2つ目をUTMが送信する前にSTARTTLSコマンドが実行されてるぞ！だからメール送信できないぞ！」
という問い合わせだったわけだ。

これについては上述の通り、お客さんは「UTMが悪いんじゃん！」と納得してくれた。
しかし・・・

「EHLOの分割レスポンス2つ目をUTMが送信する前にAUTHコマンドが実行されてるぞ！だからメール送信できないぞ！あとAUTHコマンドってなんだ！」
という問い合わせが翌日あった。もちろん同じお客さんである。

なぜだか知らないがこのお客さん、どうやら「じゃあStartTLS使わなければいいんじゃん！」と思ったらしい。

だからそもそも分割してんのが駄目なんだって！！！

それと少しは自分で調べてみてよ・・・。
「SMTP Auth」で調べたら、AUTHコマンドがSMTP認証のコマンドだってすぐわかるよ。。
コマンドレベルの細かい問い合わせしてくる割に知識がないんだよな。
ひょっとして新人なのかな・・・先輩にいわれて問い合わせてるだけの


そんなお話