1  政府認証基盤(GPKI)

引越しをしてしばらく経ったし、オンラインで在留届を出そうと思って外務省のサイトにアクセスし、入力ページに移動してみると、Firefox3 が例によってオレオレ証明書警告を出してきた。

政府機関なのによろしくないなと思ったが、よく見てみると、政府認証基盤(GPKI) と言う日本政府共通の認証局を利用したものらしい。 証明書の取得方法では、きちんと『自己署名証明書をフィンガープリントを確認してからインストールするように』という方法が記載されている。

それではと自己署名証明書をダウンロードしようとするが、このダウンロードの https サイト自体が自己署名証明書である。ではまぁ書かれている通りにフィンガープリントを確認すればいいのかとフィンガープリントの確認ページを開くが... これも同じドメインであり自己署名証明書サイト。 これ、いったいどこでこの証明書・フィンガープリントの妥当性を確認すればいいんだろう…。

しかしどこかで聞いたことがあるような気がしてググッて見ると、正しく例によって 2002年には類型の問題が 高木浩光氏のレポートで指摘されている。 せめて fingerprint だけでもブラウザ標準の証明書でサインされたSSLサイトで配布するなり、もしくはブラウザに最初からインストールするようには出来ないんだろうか。

1  Debian の PermitRootLogin が yes なのは意図的らしい

Debian lenny の openssh-server で、/etc/ssh/sshd_config の default では PermitRootLogin yes になっていた。今時 ssh での root login が有効になっているのはどうかと思ったんだが、/usr/share/doc/ssh-client/README.Debian には

この設定は upstream の default に従っている。(中略) root での ssh login を禁止しても su で root になれるアカウントがある限り、攻撃者は簡単にそこから root 権を奪取できるんだから安全性は向上しないよ。
これはバグじゃないからデフォルト設定が間違ってるなんていうバグレポートを送ってくるなよ! (超訳)

とある。言われてみればその通りではあるんだが、まぁ知られたユーザ名 (root) で brute force attack を喰らっても嬉しくないので私は no にしておく。

1  POP over SSL で証明書の多くがオレオレである理由

それにしても、上のオレオレ事業者たちは、なぜ普通にサーバ証明書を買わないのだろうか？高木浩光＠自宅の日記 - APOP終焉で「POP over オレオレSSL」の撲滅運動が可能に

VeriSign がサポートしていないからでは? GeoTrust ではクイックSSLプレミアム等がサポートしているけど、最大手の VeriSign では基本的に Web 用 SSL証明書しか販売してない。使っちゃいけないということでは無いはずだけれど、公式なサポートが無いものはビジネスではかなり使いにくい。

2  POP over SSL は必ずしも公式な証明書が必要なわけではないが

そもそも不特定多数のユーザ対不特定多数のWebサーバという図式の HTTPS と違い、POP over SSL (や、MUA→MTA/MSA間の SMTP over SSL) の場合、公式認証局の証明書である必要自体は無い。証明書が正しいことを確認出来さえすれば、それを一度インストールしてしまえば問題が無いからだ。つまりは例えば Fingerprint が印刷された紙でも郵送するなり、正式な証明書を用いた https のサイトに証明情報と手順を出しておけば済む。と言うわけで POP over SSL に関して言えば「オレオレ証明書」が必ずしも悪とは限らない。

もちろん例として挙げられているような「証明書のチェックを無視する」と言うのは DNS poisoning や Man in the middle attack に対して無力なのでやるべきではない。また一般ユーザのレベルを考えれば、多少でも手順を省くために公式な証明書を使うのはよいアイディアなのは確かである。しかし VeriSign がサポートしていない現時点ではなかなか難しいだろうし、そもそも残念な事に大多数のユーザは今も over SSL や APOP どころか平文 POP3 を使っているというのが現実だったりするので、まずはそのあたりから始めないとなんともならないのではなかろうか。

まぁ POP over SSL を使っても peer to peer で暗号化されるわけでは無いので、どこまで注力すべきかというのは(パスワードの暗号化をのぞけば)微妙な気もしているが。

1  GadgetTrak: Track stolen gadgets such as an iPod, PSP, USB Flash drive and digital camera

ガジェットを盗まれた際に、それを探しだす手掛かりを与えてくれるサービス。

When your gadget is stolen, you login to the GadgetTheft web site and turn on tracking for that device (you can set up several devices in one account). The next time your gadget is plugged in, GadgetTheft will attempt to recover the computer's IP address, location, Windows username, and computer name, among a few other tidbits. Recover stolen gadgets with GadgetTheft - Lifehacker

USB ストレージとして認識された際の「自動実行」機能を利用して、デバイスが繋がれた Windows PC の情報等をサーバに送って閲覧可能にするというものらしい。機能としてはまんまスパイウェアなわけなのだが、「自分以外の第三者が使う」目的で持っているものじゃ無く、あくまで悪意の第三者が所有者の意図しないところで使うわけなので、まぁいいのかな。

そういえば先日のスラッシュドットに似たような話の記事があった。

自宅のコンピュータすべてに SETI@home をインストールしている彼は、妻のラップトップ PC が盗まれたときに何をすればいいか分かっていました。 そう、サーバに記録される IP アドレスを監視するのです。スラッシュドット ジャパン | SETI@home で発見したものは……

むしろ自分のPCにこうしたものを入れておくのは保険としてありなのかも。特に企業ではそれなりにニーズがありそうな気がする。

ちなみに au の GPS 付き携帯電話でも、紛失時や盗難時にデバイスをロックすると同時に GPS によって位置情報の参照も出来る「ケータイ探せて安心サービス」と「安心ロックサービス」と言うのを 4月から提供するらしい。皆さんも面白そうなデバイスを道で拾っても、無闇に自分の環境に繋いだりいたしませぬようご注意を。

1  ネットゲームの個人情報入りHDDがデータセンターで 紛失

コメントで書こうと思ったらブラウザが落ちて萎えたのでこっちで。最近の大手ならば ISMS ないし関連BSやISO/IECの取得をしているデータセンタも少なくないし、耐震規準などは普通に建物に対して設定されているため、公的な安全規準が全く無いと言うことはない。ISMS では入退室管理や監視カメラの設置基準も認定審査の対象になるから、取得されていればそれなりに信頼の規準には出来る。

国内の十数ヵ所程度のデータセンタを見ている限りでは、それなりの大手ならばあまりいい加減な運用はしていないように見える。特に個人情報保護がうたわれて情報流出が頻繁になった昨今では、入退室はかなり厳しく現地スタッフのアテンドを必須にするところが多いし、物品の持ち込み持ち出しも相当厳しくチェックされる。コロケーションやハウジングブースでは個々の貸与先別に施錠管理されているのが普通なので、最低でもこの程度のレベルを満たしているところを選ぶべきではあるし、そうした先を見付けるのはさほど難しくないだろう。古い建物を改装したタイプだと、窓がそのまま残っていたりするのは防犯上宜しくない気はするが、こちらの指摘で対策してくれたところもあった。

ただ海外のデータセンタ、特に米国大手と比べると防犯に対する備えは弱いとは思う。単純にそこまで凶悪なケースを想定していないだけなのだろうが、警備員がほぼ非武装でしかも年配の人が多いというだけでもちょっとどうかと思うところは多い。またインフラ切断時のバックアップ体制が比較的大きくないのも実情。日本では現実にこれが問題になることは殆んど無いとは思うが。あと欧米だと日本以上にいい加減なデータセンタが多いのもまた事実でもあるか。

1  セキュリティは設計時から考慮すべき、Microsoftがデベロッパーに呼びかけ

今日の「お前が言うなお前が」そのいち

2  ソフト開発者が造った飛行機には乗ることができない--オラクル幹部がパッチ偏重を批判

今日の「お前が言うなお前が」そのに

1  企業における情報化投資額の売上額比

特定業種(情報サービス産業)のやつを調べてたりしたけど、恐ろしく小さい。
0.5%未満のところが最も多く、4%未満までで回答企業の8割強を占めてた…。

セキュリティ対策費は企業規模や業種でかなり違うので何とも言いがたいが、基本的に(特にSMEでは)現状では未だに潜在ニーズでしかなく、リスク啓蒙(金銭込みの話)を絡めてやらないと売れないと言うのが現状だと思う。なんせ直接的には利益を生まない部分なのだから。

更に一方で専任の担当者どころか詳しい社員すらいない中小企業が多いことを考えると、ややこしいことを言わずに「これを買えばあらゆる安全」的なもので無いと駄目というのもある。実際にあまり技術的に詳しいスペックをあげても、そもそも営業に行く人自体が理解出来ていなかったりする。

最終的にはアウトソーシングがお互いに取って一番良い手であることは少なくないが、いかんせんそうした企業にとってはセキュリティと言う言葉の対象になるのが基幹業務である事も多いので難しい所。ともあれ Web やメールサーバといったレベルならばちゃっちゃとホスティングに出してしまえ、とは思う。

1  SSHに対するブルートフォース攻撃への対策

sshd へのパスワード総当たり攻撃は今年の前半くらいから非常に増えていて、「実際に guest や test などのアカウント名を乗っ取られた」と言うケースも実はそこそこの頻度で聞いている。仕事では既に防御スクリプトを仕込んでいるサーバもあるが、無防備なサーバに実際にどれくらいの攻撃が来ているのか、ログを見てみた。

2  存在しないユーザへの攻撃

sshd へのアクセスが失敗すると、少なくとも FreeBSD や Debian では /var/log/auth.log にメッセージが残る。上が存在しないユーザ、下が存在するユーザへの総当たり攻撃ログの例

Nov 8 11:29:47 example sshd[81317]: Failed password for invalid user jiseitai from 211.93.0.248 port 59039 ssh2
Nov 8 11:29:47 example sshd[81317]: Failed password for root from 211.93.0.248 port 59039 ssh2

これを ruby のワンライナーで名前の部分だけ切り出してみる。以下で使ったのは某所サーバの 11月分のログ。

# grep -c invalid /var/log/auth.log
18125
# ruby -e '
names = Array.new
File.open("/var/log/auth.log").each do |line|
  if /invalid user (\w+) from/ =~ line then
    names.push $1
  end
end
puts names.uniq.join(", ")' > list
# wc list
    1   8367   68752

8,367種類のアカウント名で、約18,000回もアタックしてきているようだ。

3  攻撃元 IP アドレス

上記の ruby ワンライナーを少し変えて ip アドレスを抽出してみる。

# ruby -e '
ips = Hash.new(0)
File.open("/var/log/auth.log").each do |line|
  if /Failed password for .+ from ([0-9\.]+) port/ =~ line then
    ips[$1] += 1
  end
end
ips.sort{|a,b| b[1]<=>a[1]}.each do |ip, count|
  puts "#{count} - #{ip}"
end'

という感じで。先の攻撃は見てみると 50 IP Addresses から来てるようだ。100件越えが 17件で、うち 1,000件越えが以下の 4件

5,272 - 219.240.75.45 (HANANET-HIGHBAN-MANTECH, Hananet Korean - hanaro.com)
3,387 - 211.93.0.248 (UNICOM, China United Telecommunication Corp. - cnuninet.com)
3,134 - 64.251.25.85 (INFOLINK-BLK-100, Infolink Information Services Inc. - infolink.com)
2,609 - 8.3.7.89 (LVLT, Level 3 Commucations, Inc. - level3.com)

whois で調べてみると、韓国、中国、米国という見事に典型的な攻撃元になっている。

4  総当たり攻撃を防御するスクリプトや仕組み

こうした攻撃を防衛するには、例えば sshd の待ち受け port を標準の 22/tcp から変更したり、knockd を使って port を閉じたり、または ssh のパスワードによる認証を切ってしまう方法がある。しかしどれもユーザに通知なり利用形態の変更を強いるため、大勢で使っている場合には多少導入し辛い。と言うことでサーバ側で攻撃アクセスのみを拒否する仕組みがあると便利なことも多い。

原理としては基本的に上記のようなログから 攻撃元の IP アドレスを抜き出して deny するものと、フロー制御的に短時間に複数回数の ssh アクセスがあった場合に deny する方法がある。

maxlogins.pl

FreeBSD 用となっているが hosts.allow に追加する形なので Linux あたりでも使えそう。ログに複数回の ssh login failure があると IP アドレスを deny に追加する

sshdfilter

これも原理は似たようなもので、libwrap の代わりに iptables を使うのが異なる点。当然 *BSD では使えないけど、ipf に書き換えればいい気もする。

Blocking repeated failed login attempts via SSH

これも似たようなもの。

ipt_recent

これは Linux iptables の ipt_recent モジュールを使って一定時間内の同一 IP アドレスからの繰り返しアクセスを拒否する仕組み。

ログ解析を使うものは、当然リアルタイムの対応はできないし、ある程度の頻度でログのスキャンを行う必要があるのでログの肥大化には気をつけた方がいいだろう。

5  SSH brute force 攻撃からサーバを守る - まとめ

最初に挙げた春山さんのものと結局たいして変わらないわけだが一応書いとく。

1. 特定IPアドレスのみからのアクセスを許可し、他は全拒否する
2. sshd の listen port を 22/tcp から他の任意の port に変更する
   • sshd.conf の Port 22 を 22 以外の任意の数字に変更
   • もしくはport 22 に knockd を使う
3. パスワードによる認証を禁止する (PasswordAuthentication no, ChallengeResponseAuthentication no)
4. 総当たり攻撃の防御スクリプトを導入する
   • ログから攻撃を検知し、libwrap や iptables, ipf 等で拒否
   • iptables の機能を使って同じIP空の連続アクセスを自動拒否

ちなみに ssh での root login を許可 (PermitRootLogin yes) し、しかもパスワード認証可能になっているのは、現時点では激しくお勧め出来ない。当然ながら telnet はそもそも起動しないか IPアドレスでアクセス元を絞ること。

1  tdyary 2.0.2 の CSRF 対策

tdiary 2.0.2 に CSRF 対策が入ったようで、debian package も上がってきていたので update しておいた。tdiary で CSRF を下手に食らうと変な plugin を読み込まされて任意のコードを実行、なんて事も起こりかねないのか。

対策内容は

1. POSTメソッドの要求
2. Referrer check
3. 固定的な hidden key

で、1 && (2 || 3) の組み合わせらしい。Referer は送らないユーザ・ブラウザもいるので微妙な気がするが、Referer を送らない人は 3 を使うと言う選択肢があるから大丈夫、と言うことか。
3 は通常はランダムな session id ないしそれ用の one time token にするもので、static な値の hidden key って見られたら終りじゃないんだろうかと思ったんだけど、この hidden key は http basic 認証通過後のユーザじゃないと基本的に見られないから大丈夫と言うことなのだろう。tdiary は元々セッション管理的な機能が無いからこうしたのかな。

1  ACCS事件でoffice氏に有罪判決

事件についてはACCS不正アクセス事件テンプレ参照。

アクセスはプログラムの脆弱（ぜいじゃく）性を利用したもので、管理者は想定もしていなかった。...(中略)... 高度情報通信社会の健全な発展を阻害することは明らかだ

判決理由の半分は「見せしめに処罰してやる」という公言に見える。所詮、裁判官は法律の専門家であって技術の素人なので、「アクセス制限されている」かどうかは技術的ではなく観念的に判断される、と言う結論が出たと言えるか。office たんには是非控訴して頂き、もう少しましな判例を引き出して貰いたい。

2  ノーガード戦法とか言うネタを未だに書いている人がいるようだ

ところでこの判決に

ノーガード戦法でも OK と言うお墨付き

とか言う頭の悪いコメントを付けてる人がいる。まぁネタだと思うが。当然ながら皆が office たんのように自爆してくれるわけではないので、普通は誰にも警告して貰えないまま、何千何万件と個人情報が悪意の匿名攻撃者に漏れ続けるだろう。そして個人情報保護法の漏洩対策義務違反で訴えられると。

それにしても腹立たしいのは、ACCS がこの事件後ずっと「私は被害者」「インターネットの秩序を守ろう」「ACCSが啓蒙をする」みたいな立場で偉そうに喋っている事だな。"

1  オレオレ証明書

CA のサインが無いのに「信頼して貰って構わないよ」とか言ってる証明書を「オレオレ証明書」と呼ぼう、とかそういう話。言い得て妙な名称。

最近はその手の話で高木氏が 小学生にセキュリティ警告を無視させる埼玉県 でツッコミまくりで面白い。しかし高木氏は文章ひとつで記載されている相手の印象を上げ下げする技術に長けているなぁ。見習いたくはないけど。

2  SSL の役割

オレオレ証明書クイズ。SSL は基本的には通信内容を第三者に読まれないようにする事が目的。そのために

1. 通信内容を暗号化する
2. 暗号化通信の相手が現在通信中のIP/ドメインである事を証明する

と言うことをしている。証明書が正しくないとしても 1. は満たされるので、通信は暗号化される。しかし 2. の「相手が第三者ではない」と言う保証がなくなるので、通信先が乗っ取られていたり、成りすましされたりする可能性は否定できなくなる。と言うわけで「信頼できる証明元(主にはブラウザに初めから入っているもの)から送信元の正当性が証明されている」事は安全な通信には必須だったりする。もちろん自分で建てた SSL サーバを自分で使う、等の場合には予め自分の証明が自分で出来るので、ブラウザに証明書を登録しておけば良い。

とは言え SSL の役割というのは所詮は上記の通り「通信の秘匿」なので、通信先のサイトが XSS を受けていたりサーバ自体が乗っ取られていたりと言う事象には対処できないし、紛らわしいドメインやブラウザの脆弱性などを回避することも出来ない。そもそものWebサイトが詐欺をしていたりと言う事も回避できない(身元は割れているだろうから証明書がないよりはまし)。まぁ万能ではないけど無いと安全ではないよ、と言う感じか。

3  OreSign

で、この日記で何が書きたかったかというと OreSign に CA やって欲しいなー、と言いたかっただけだという。

1  __alloc_pages: 0-order allocation failed (gfp=0xf0/0)

朝起きてみたら、どうもこのサーバの HTTP に繋がらない。幸い ssh での接続は出来たので、login して見てみると dmesg に

__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
VM: killng process ......

が大量に出ている。どうやら何かのプロセスが暴走したか何かで swap を含めてメモリを食い尽してしまったようだ。

但し殆んどのプロセスは一度 kill された後に自動復旧していて、死んだままになっているのは bind9, apache, mysql 程度らしい。ともあれ bind9 無しでは何も出来ないのでその場で start させておく。

2  原因判明?

幸い、snmpd 経由で CPU, memory, bandwidth, I/O usage, num of processes の他に、apache や mysqld のプロセス数も定期記録していたものが残っていた。そこから状況を見るに、メモリを食い尽す直前の apache, mysqld の process 数がバーストしているのが見て取れる。これらが同時にバーストすると言うことは、apache 経由でmysql 処理を必要とする cgi に高い負荷がかかった可能性がある。

と言うことでログファイルを調べてみると、MovableType の mt-comments.cgi に DoS 的な POST アクセスがあり、これによって MT の rebuild が際限無く発生し、apache と backend の mysqld を巻き込んで死んだのが直接原因のようだ。

3  apache process 99%

改めて apache を起動しようとするが、どうも 80 番 port が上がってこない。apache process を見てみると %CPU が 99.8 になっていて、全く起動してこないようだ。ちなみにこの apache は apache 1.3.31-4 。lock file も出来てないところを見ると、本当に初期の段階で死んでいるっぽい。なのでまず設定ファイル httpd.conf を疑ってみる。あれこれしてみると VirtualHost の設定を全て取り除くとうまく動くようだ。しかしもちろんこのままでは実用にならない。

しばらく見ていくと、

<VirtualHost yoosee.net>

のように VirtualHost Directive を名前ベースで宣言していると駄目で、

NameVirtualHost *:80
...
<VirtualHost *:80>
ServerName yoosee.net

のように受けておけば暴走せずに起動することが分かった。恐らくは apache 側のバグだろうが、とりあえずこれで動くし設定的にも不具合ではないのでこれで復旧しておく。やれやれ。

4  問題のサイトの方

荒らしコメントが連続投稿されているのが問題なのは明らかなので、とりあえずその IP を ban しておく。mt-comments.cgi へのアクセス数を個別に制御したいんだが、mod_tsunami では VirtualHost 単位でしか出来ないのだよな。何かよい module はないだろうか。コメント数もやたら多い(1500以上…)ので、一度 close して記事を分離した。少しは落着くだろうか。

1  FreeBSD QandA 2255

cron 等から起動されるバッチ処理の中で ssh を利用したいのですが、ログインを自動化するにはどうすればよいですか?

と言うもの。丁度ほぼ似たようなことをやりたかったので参考にさせて頂く。内容は

1. ファイル転送専用の鍵をパスフレーズ無しで作る
2. public key の先頭に command オプション等を追加し、特定のコマンドのみ実行可能にする
3. public key を相手先サーバの authorized_keys に登録
4. cron 等で定期実行

と言った感じ。恥ずかしながら command と言うオプションを知らなかった...

2  RSSH - Restricted Secure SHell

これを知る前は、実はこの RSSH を使おうと思っていたのだが、今回は条件に合わず見送った。簡単に言うと scp と sftp のみを許可する ssh と言ったところ。某所で使っていたのだが、言うほど便利では無い気がする。それと WinSCP では裏側で ssh コマンドを投げているので rssh では使えなかったりと、今一つ使い勝手に欠けるんだよな。

3  RSA と DSA

ところで今だと RSA と DSA はどちらを使った方がいいのかな? 昔は putty のサイト辺りで DSA じゃなく RSA を使えと言う Recommendation があったんだけど、これは DSA の imprementation が悪い場合と言う限定条件下だしなぁ。RSA は素因数分解で DSA は離散対数か。と言われても強度差なんてわからん...

1  各所クラック

mozilla.gr.jp 、namazu.org 、 ruby-lang.org 、nurs.or.jp あたりが続々とクラックされた模様。どこがどんな原因で、と言うのはまだちゃんと分かっていないみたいだけど、cvs pserver の穴という噂もあるようだ。もじら組の話は /.J へタレコミがあったのを関係者に連絡したが、とりあえず停止するだけで手一杯のようだ。大変だな...

2  メンテナンスコスト

うちのサーバは debian なので、定期的な apt-get でセキュリティホールの修正版が入ってくる。この手の security 関連のパッケージアップデートは自動実行される仕組みがあるべきだと思う。
どのみち、Web サーバのメンテナンスなんて言うのはコードいじりや翻訳と比べても退屈で、且つある程度のスキルが必要で、しかも日常継続的に見ていく必要があるという、きちんとメンテナンス出来るスタッフを恒常的に抱えるのはボランティアベースのプロジェクトでは難しいと思う。今ならば sf.net や sf.jp に預けるという方法もあるわけだが、古くからあるプロジェクトやサイト負荷が高いプロジェクトでは自前で抱える必要もあるわけで、なかなか簡単ではない。

3  サーバ運用委託

個人的には、「オープンソースを推進する」等と言っている企業が金を出して、ある程度共有でもいいので(UMLやVMWare、VPSのように仮想サーバにする手もある)データセンタにサーバを置いて、基本的な apache, postfix, cvs, ssh あたりのメンテナンスは面倒見るから各プロジェクトで使ってくれ、みたいな太っ腹なことをしてくれてもいいと思うんだけど。sf.jp の個別版みたいな。(大)企業にとってはコストもさほど高くないし、サイトに Powerd by なロゴを入れるくらいでもペイすると思うんだが。

1  アンチウィルス戦争最前線レポート

エフ・セキュア社のウイルス対策チームはこのぬいぐるみを警報として使っている。サルがキーキー鳴きはじめると、新種のウイルスやワームが暴れ出した合図なのだ。

うーん、意外と地味なのだな。もっと大型モニタなんかに Unknown Virus Detected みたいなメッセージ出て、警報が鳴り響いて、黄色ランプが回転して、30 人くらいが一斉にキーボードを激しく叩き始めるとかそう言う光景を想像していたのに。

2  地味さを払拭せよ

思うに、ネットワーク・情報システム管理者はもっと派手に事を行うべきなのではなかろうか。あまり地味に物事を運ぶと、事の重大さが伝わらないであろう。例えばこんな具合いに...

[Case] 社内LAN内で、社内が発信元と思われる Virus が見つかった場合
(全社放送)(サイレンが鳴り響く)『只今社内で Virus 感染が疑われる事象が発生しました。警戒モード C を発令。パターンが更新されるまで、社内からのメール送信は全て遮断されます。全社員は情報システム管理部門スタッフの指示に従ってください』

あるオフィスルームに黒スーツ・サングラス姿の男が 1 人と、その他 4,5 人のスタッフが入ってくる。
黒服の男「このオフィス内マシンからのウィルス送信が検出されました。社員の皆さんは直ちに作業中のマシンから離れ、作業が終了するまで待機してください。」
オフィス内の社員(ざわざわ)(大袈裟なことになったな)(誰だ厄介事を持ち込んだのは...)

スタッフA「被害の拡大を防ぐため、当オフィスを隔離します。ネットワーク切断準備」
スタッフB「128 の対象に対し、切断準備完了しました」
合成音声「切断を実行します... 完了」
スタッフA「続いてウィルス検出プロセス開始。検出用エージェントを投入開始」
合成音声「解析作業進行中... 現在 38%... ウイルス固有パターンのヒットを確認」
スタッフB「隊長、○○部長席のマシンからウィルス感染が検知されました」
黒服の男「...分かった。該当マシンは証拠として押収し、シール後に構造解析に回せ。」
スタッフA「了解。回収後、直ちに解析作業にかかります」

部長「お、おい。そんなことをされたら私の仕事が...」
黒服の男「お分かり頂いていないようですね。貴方の不注意によって脅かされたのは当社の信頼なのですよ。ウィルスメールが顧客に対して既に送信されていた場合、相応の責任は取って頂かなくてはなりません。事情をお聞かせ願いたいので、ご同行頂けますか。」
部長「き、君! 私を誰だと思っているのかね! 私は..」
黒服の男「当機関は社長直属であり、全ての業務に優先して実施されます。ご理解頂けますね。」
...
(全社放送)「発信元の特定、及び感染範囲の推定が完了しました。全ての管理下マシンの正常性確認。全情報危険レベルを A へ。社員の皆さんは通常業務へお戻りください。ご協力ありがとうございました」

くらいやらないと。

3  とは言え現実は

地道に啓蒙と作業をコツコツやるしかないのが現状なわけですが。