劣化にもほどがある

http://www.kb.cert.org/vuls/id/435052

では、
* Internal services that use an authentication scheme (such as a username/password) are not as likely to be affected by this issue.
* Network designs that have limited connectivity between the proxy and internal services will prevent an attacker from obtaining direct access to these services via the proxy. Administrators should consider using access control lists or firewall rules to prevent direct connections between internal servers and proxy servers.
* Administrators should configure the proxy to use the only the protocols and ports which are required for normal operation. In particular, administrators should limit the CONNECT method to only the minimum required port range (usually 443/tcp).
* When possible, router or switch access control lists should be configured to prevent HTTP proxy servers from connecting to servers using ports or protocols that they should normally use. HTTP proxy servers do not usually need to communicate with well known ports other than 80/tcp and 443/tcp.

とある内容が、

http://jvn.jp/cert/JVNVU435052/index.htmlにかかると

* 内部サービスに対して認証機能を使用する。
* 内部サーバとプロキシサーバ間で直接アクセスできないように制御をする。
* CONNECT method で許可するポート番号を必要最小限にする。 (通常は443/tcp)
* プロキシサーバからの不要な接続をルータやスイッチのアクセスコントロールリストを使い、拒否する。 (80/tcp と 443/tcp 以外を拒否するなど)

になる。すごい圧縮率だ（棒読み）。

最悪すぎてくらくらする

IPAの『当機構職員の私物パソコンからの情報流出に関するメールでのお問い合わせについて』なる文書が……。

要するに「メールが多すぎるから返事しねぇよ」という内容であるにも関わらず、それを中途半端に隠そうとして自爆してます。これ、大学出たての新人さんが書いたんだよね。で、誰のチェックもなしに公開されちゃったんだよね。

・タイトルと文章の結論が連携していない。
・ところどころ傲慢さがにじみ出ている表現が混じっているのに、正しくウィーピングされていない。
・段落設計がかなり最悪に近い。

おかしいなぁ。各省庁の外郭団体なんて文書・文章作成能力だけは潤沢なはずなのに、なんでこのレベルに留まっちゃうんだろう？

アドバイザリのUI設計ミス（JVN編）

JVNを真似して設計すると、ほとんど絶望的な品質のアドバイザリ公開サイトができあがるよシリーズ第一弾。

JVNというIPAが運用する脆弱性アドバイザリを流すサイトがあります。
が、ここに出てくるアドバイザリや推奨行動の品質が大変にヒドく、どうも組織論レベルのエラーを起こしているであろう、ということで真面目にケーススタディしてみようと思います。

　　　つーか、フィードバックかけても根本的な改善しないのだよ彼らは。

まず一発目として。アドバイザリに書かれている情報項目の取捨選択バランスがよろしくない点。UI設計とか文章論とかのレベルで問題外なのですが、なんでこんなものが出てくるのでしょうか。

よっぽど組織（権限持ってる人のなかにおばかが混じってる？）に問題があるのではなかろうかと思われる次第。

http://jvn.jp/nav/jvnhelp.htmlに「脆弱性レポートの読み方」なる項目があります。ここには、以下のように技術者や科学者なら目を疑う内容の記述が存在します。

> 公開日：YYYY/MM/DD
>
> 脆弱性情報を JVN において公開した日付(日本時間)です。同じ脆弱性について、
> ベンダ(製品開発者)や US-CERT、CPNI などから情報が公開されていても、公開日は
> 一致しないことがあります。必要に応じてベンダ情報などを確認してください。
>
> 最終更新日：YYYY/MM/DD
>
> 最後に脆弱性情報に関する更新が行われた日付(日本時間)です。それまでの
> 更新については更新履歴に記載しています。

オリジナルの日付ではなく、JVNのレポートの公開日と最終更新日だけ。なにそれ。ていうかそれは「レポート公開日」と「レポート最終更新日」だよね？　まぁこれだけなら極悪ではないのですが、JVNのレポートは一次情報が公開されてから半年後に公開、なんていう遅延が発生することも珍しくありません。1～2週間遅れならしょっちゅう。

このような形で公開日・更新日を入れることそのものは悪ではありませんが、一次情報からあきらかに遅れたタイミングで公開する「後出し」レポートの分際で『公開日』を名乗るのは、かなり恥ずかしいところです。

この手のアドバイザリでは「公開日」のような「Published date」のように読めるものを書く場合、セオリーとして、

・一次情報の公開日を記載する
・一次情報からほとんど遅れない体制が組めている場合に限り、レポートの公開日を記載する（一次情報の公開日と誤認されても問題がない状態にする）
・遅れがある場合、「レポートの公開日」であることが明示的に分かるようにする

あたりが必須になります。何が問題かっつーと、Publishedになったタイミングからどれだけ経過しているか、というのが重要なインパクトファクターなのに、アドバイザリのUI設計ミスで、それを誤認させうる点。

たぶん、
・お役所的なお約束として、レポートの提出日を明記する必要がある
・それを「公開日」とする謎の文化圏に属している
・現場に正しく権限が委譲されておらず、実務上必要な内容が上位者の阿呆な判断によってねじ曲げられている
というあたりが敗因でしょうか。真面目に調査してケーススタディすると、経営論の良質な論文が一本書けそうです。

組織論レベルの敗北なので、改善はあまり期待できないかなー。