2016年2月29日
2016年2月29日
2016年2月29日（月）
「意識高い人」で行こう！（いい意味で）
ビッグローブ株式会社 事業推進本部 CSR 推進部 (CSIRT)
シニアエキスパート 古賀 洋一郎
最近「意識高い」がいい意味では使われなくなってきています。「意識高い系」という用語が、概ね自意識が実態以上に高い人を指す、どちらかと言うと悪い意味使われるようになってきたことが背景にあって、次第に「系」なしの「意識高い」もあまりいい意味で使われなくなってきているようです。注意して使わないといけないですね。
さて本題。最近身近なところで「意識が高い人（いい意味で）」の言葉に接して、ちょっと嬉しかった話をします。
セキュリティ上の課題に限りませんが、新しく何か対策を打とうとすると、世の中の水準に比べてどうなんだ？ 同業他社はどうしているのか？ といったことを経営層などから問われるケースがよくあります。意思決定するために参考になる「ものさし」がほしいというのはよく分かります。が、そうは言っても、世の中の対策水準や同業他社の状況を調べるといってもなかなか難しいものです。具体的なことは非公開、されていてもほとんど参考にならないことが多いものです。
通信事業者でセキュリティ担当をしている私、そんな調べものをしていて、報告締切が目前という切羽詰まった状況に陥ってしまい、藁をも掴む思いで知り合いの同業のセキュリティ担当の人に電話で相談してみたところ、これが快く話してくれる。そんなことまで教えてくれていいの？ っていうくらい詳細かつ丁寧に。ほんとうに助かりました。もう大感謝！
その人が最後に言ってくれた言葉がこれ。
「ぼくらは協力して通信事業者全体のレベルを上げてネット環境を安全にしていかないといけない。そのためだったらいくらでも話しますよ。」
あー、さらっと言ってくれるよ、この人。しかもキレイ事じゃなく本気で。カッコいい
じゃないか。
もちろん、ここまでしてくれるのにはそれなりの信頼関係があってのことで（多分ね）、振り返ると同じ問題・課題を協力して解決してきた経験がベースにあります。それでもこの人が「意識が高い人（いい意味で）」でないと、こうはいかなかっただろうな、と思いますし、逆の立場だったら自分は言えたかなぁ、とこのコラムを書きながら考えてしまいました。
実は、通信事業者の間ではこういうやり取りがしばしば行われています。たとえば「今こんな攻撃がうちでは観測されているんだけど、皆さんのところではどうですか？」といった生の情報の共有や、他での同様事象の発生確認といったことは日常茶飯です。Facebook で「今ちょっと電話していいですか？」なんていう意味深なメッセージの後、文字のやり取りでは差し障りのあるような密やかな情報交換がなされることもあります。
これ、意外だと思いませんか？ 今攻撃を受けている、なんていう情報、そうそう競合の同業者には出せないんじゃないの？ と思いますよね。
ところが、攻撃対応の最前線の現場にはこういう意識の高い人たち（いい意味で）が大勢います。こういう人たちが連携することで、私たち通信事業者はサイバー攻撃の脅威に立ち向かっています（ちょっと宣伝っぽいか）。自分がそこにどれだけ貢献できているかははなはだ心もとないのですが、ささやかでも貢献できているといいな、とこれは本当に思っています。
「ぼくらは協力して通信事業者全体のレベルを上げていかないといけない。」
これを大人な表現で言っているのが、当社も加入している通信事業者の業界団体、テレコム・アイザック推進会議の飯塚会長の挨拶の中の言葉で、私の大好きな言葉。
「健全なセキュリティは高邁なコラボレーションから！」
これを私が言ってしまうと、それこそ「意識高い系」になってしまいますが、誰かに相談された時などは、先の人のようにカッコよく応対できるようになりたい、と思うのでした。
ということで、私の2016年の目標はこれです。
「意識高い人」で行こう！（いい意味で）
※記載内容は執筆者の知見を披露されているものであり、著作権は本人に帰属します。
2016年2月29日（月）
ペネトレーションテストで実感したこと
三井物産セキュアディレクション プロフェッショナルサービス事業部
国分 裕
一昨年くらいから、ペネトレーションテストを担当する機会が増えました。ペネトレーションテストでは、脆弱性の存在を確認した後、実際にその脆弱性を使いサーバへの侵入を試みます。侵入後は、他のサーバ侵入に使えそうな情報を収集し、さらに別サーバに、と繰り返し侵入していきます。実際にやっていると、最初の１台に侵入できるまでのハードルは高いですが、その後は次々と侵入できることがよくあります。その理由を３つ紹介しましょう。
まず、サーバ内には夜間バッチやバックアップなど定期的に実行されるスクリプトがあり、中にはDBやNASへの認証が必要で、そのパスワードがスクリプトに埋め込まれている場合もあります。管理者だけに制限されていれば良いですが、探していると１～２個は一般権限でも読めるものもあります。
２つめは、コマンド実行履歴です。ここには運用担当者が実行したコマンドが、タイプミスも含め残っています。引数にパスワードを含んで実行したり、コマンドと間違えてパスワードを入力したことはありませんか？その履歴は全て消していますか？
３つめは、パスワードの使い回しです。前述のような方法で１つパスワードが取得できると、感覚的に約８割のサーバはそのパスワードでログインできます。
これはなかなか根が深い問題です。機器の台数が増えると全て異なるパスワードをつけて運用担当者間で共有するのは大変です。データベースなどでアカウント情報が一元管理されていて、結果的に全てのサーバのパスワードが同じになる場合もあります。
SSHの鍵認証などパスワード以外の認証方法が使える場合は、パスワード認証を止めるといいと思います。鍵認証が普及してないせいか、侵入したNASを探すとパスワードを書いたメモはありますが、秘密鍵を発見できたことは"まだ"ありません。またIPアドレスによるアクセス制御が保険的対策として有効です。ペネトレーションテストのように次々とサーバを経由して侵入する場合はファイアウォールを通らないこともあるので、各サーバ自身でのアクセス制御が効果的です。
ペネトレーションテストはあくまでも「テスト」なので、サービスが落ちる恐れのあるバッファオーバフローなどの攻撃試行が許可されない場合が多く、パスワード関連に偏っているかもしれません。前述の対策は基本的なものばかりですので、一つ一つ丁寧に実施しておきたいですね。
※記載内容は執筆者の知見を披露されているものであり、著作権は本人に帰属します。