このブログは「風見鶏」が、日々気づいたこと、思ったこと、したことを気ままに綴る日記です。2008年9月に旧ブログから引っ越しました。バックアップをご覧ください。

ゲストログインがうまくできないので、コメントを承認制にしました。スパムでないことを確認の上、公開します。判断はあくまで「風見鶏」の主観で行いますので、文句は受け付けません。(笑)承認が遅れることもままあると思いますが、あしからず・・・

システムトラブルのため、2015年以降のブログ画像と2018年5月以降の記事が消失しました。画像は鋭意、新しい物から順次復旧中ですが記事については残念ながら戻せません。残念ですが、あきらめます。

なお、ここに書いていることは、あくまで個人的な思いであり、いかなる組織をも代表、代弁するものではありませんし、無関係ですので念のため。

守るも攻めるも・・・

| コメント(0) | トラックバック(0)

昨夜から天気は下降気味。朝方は雨、気温も少しため家でムシムシする。この天気では洗濯は無理か、と思って、朝飯を食ってまたふて寝していたら、なんだか外が明るくなってきた。少し薄日もさしてきたようなので、とりあえず、なんとかなるか、と洗濯。それを干してから昼飯に出かけた。少し青空も見えていて、結構日も差していたのだけど。道を歩きながらふと見上げたら、電線に蜘蛛の巣。

こいつは小さな飛ぶ虫にとっては、さしあたりAPTといったところだろうかな。(笑)

APTからの攻撃への対策は簡単ではない。セキュリティというと、どうしても防止するという観点からものごとを考えがちだが、それしか考えていなければ、防止できなかった際には打つ手がない。標的を定めたマルウエアがウイルス対策ソフトを簡単にすりぬけてしまうように、APTによる攻撃は一段階の防御では防ぐことが難しいばかりではなく、万一、防御線を突破された時のことも考えて、それを発見して被害を広げない方策を考えておく必要がある。

こう言うのは簡単だが、実はそれほど容易ではない。何重もの対策にはコストがかかるし、ITの利便性もある程度犠牲にせざるを得ない場合も多い。大規模な組織ほど、むしろ難しいのが現実だろう。しかし、実は、APTを考えた場合、「本当に守るべきもの」の総量は、相対的には、かなり小さいはずだ。問題は、それがきちんと洗い出されていないことや、洗い出されていても、その他のものと混在して分散してしまっていることなのではないだろうか。

最初のステップは、これらを徹底的に整理して、物理的に隔離することから始まる。人的にも、組織的にも、場所的にも、そしてネットワーク的にも分離して重点的に管理する。こうした重点管理区域を絞り込むことで、より効率よく防御策が導入できる。

もちろん、これだけでは安心できない。もし、その業務にたずさわる人間が特定されたとしたら、たとえば古典的な手口だが、その人間を懐柔するなり、脅迫するなりして協力させるような方法も考えられる。本人が気づかないうちに、攻撃に利用されてしまうようなこともあるかもしれない。また、ネットワーク的に分離されていたとしても、Stuxnetのようなケース考えれば、マルウエア侵入の可能性も否定できない。なので、こうした物理的、論理的に分離された区画は、徹底的に監視しておく必要があるだろう。もちろん、ネットワークは直接的にインターネットに接続できないようにしておくことが必要だが、一方で、マルウエア感染を前提に考えると、デフォルトルートを集約して、そこに集まってくるトラフィックを監視しておくのも手だろうと思う。通常の通信はデフォルトルートに流すのではなく、L3スイッチ間で、直接ルーティング情報を交換すればいい。一方で、作業用のPC間の通信はそれぞれ、L2レベルで分離し、必要なサーバとしか接続できなくしたり、ルーティング情報のような情報収集に使えるようなパケットはクライアントには一切流さないなど、とりうる方法はいろいろと考えられる。

あと、PCを集中管理するのであれば、その管理のためのサーバは特段の注意を払って防御する必要がある。たとえば、ADサーバが乗っ取られたら、結構寒いことが発生する。こうしたサーバへの区画外からのアクセスも絶対に避けたいところだ。

作業者はこの区画のリソースにアクセスする際は、必ずこのネットワークの中からやる。少なくとも外部から入ってくる道筋はすべて絶っておきたい。たとえば、作業者がインターネットにアクセスすることが必須なのだとしたら、区画外に置かれたシンクライアントのサービスにのみ、接続を許可して、それを経由してインターネットを参照させる。こうすれば、インターネットから何かを拾ってしまっても、区画の外にとどめておくことができる。この逆はやらないほうがいい。外から中に入れるルートはないにこしたことがないからだ。たとえば、内部のシンクライアントサービスを外部からアクセスさせれば、たとえばそのサービスによって侵入をうけるリスクが生じる。こうしたインバウンド通信が必要になる原因は、多くの場合冒頭に述べたような業務と情報の整理が十分できていないからかもしれないと思う。

そして、一番重要なのが、もし、何かが発生した、もしくはその兆候を見つけた場合に、きちんと対応ができる仕掛けと体制を作っておくことだろう。瞬時に特定のPCが接続されているポートのVLANを切り替えて隔離した上でモニタしたりといった仕掛けも必要になるかもしれない。過去の動きをトレースするために、常時ネットワーク上のパケットをキャプチャして、長期間保存しておくようなことも必要だろう。そして、そのようなことをすばやく実行できるCSIRT(Computer Security Incident Response Team)つまり、専門的な緊急対応チームを作っておくことである。外部の事業者を利用することも考えられるが、初動を考えれば、最低限の専門要員は自社で保有しておき、外部のセキュリティ事業者にそのバックアップをたのむというやり方が最も効率がいいと思う。

これは書き出すときりがないので、これくらいにしておこうと思うのだが、まずは基本に立ち返って、情報や重要業務のセグメンテーションをやっていくことなのだろうと思う。これなしには、対策はすべて中途半端に終わる。必要のない業務に余計な負担を与え、一方で本当に重要な業務は守れないという最悪の対策だ。そんなことにならないようにしたいものだ。どんなに強そうな艦隊もその使い方次第では、最後にはすべて沈む。それは昔の戦争の教訓だ。そして、APTを語るとき、それは既に戦争に近いのだろうと思う。

午後も、なんとなくだらだらと過ごした。洗濯物は日差しが会った割には、いまいち乾きが悪く、日が暮れてから取り込んで部屋で干している。あまり動いていないので、いまいち腹も減っていない。風呂でも入ってから飯にしよう。

トラックバック(0)

トラックバックURL: https://www.kazamidori.jp/MT/mt-tb.cgi/726

コメントする

月別 アーカイブ

この記事について

このページは、風見鶏が2011年10月22日 18:29に書いた記事です。

ひとつ前の記事は「言葉のはなし」です。

次の記事は「食って寝て・・・・」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。