開発エンジニアのためのセキュリティ - 情報収集方法と技術的トレンドとは

開発エンジニアも対岸の火事ではない

続いて行われた後半のテーマは「実例から読み解く技術的なトレンド」。まず、新井氏が、昨今急速に増えている「バンキングマルウェア」と呼ばれる銀行の不正送金の事例を紹介した。新井氏によると、バンキングマルウェアが猛威を振るったのは2010年頃から。Zeusと呼ばれるマルウェアのソースコードがgithubに公開されて以降Zbotと呼ばれる亜種が爆発的に増えたのだという。Zeus/Zbotに感染すると、正規の銀行サイトにアクセスしたときにパスワードや乱数表を入力する偽の画面が表示され、そこに入力した情報が盗まれることになる。

ただ、今年に入ると、Zeus/Zbotは廃れ、Neverquest/Vawtrakと呼ばれる不正送金マルウェアが流行してきた。特徴は、個人口座よりも、扱う金額が大きい法人口座が狙われるようになってきたことだ。「法人口座では、電子証明書でアクセス制限がかけられるケースが多いのですが、その証明書を盗んで、法人口座から不正に送金するケースが目立ちます。5月までの被害額は14億円を超え、昨年1年間の金額をすでに超えています」(新井氏)

不正送金というと、開発エンジニアにあまり馴染みがないようにも思える。だが、証明書の窃取は、開発エンジニアにとって決して対岸の火事ではないという。根岸氏が挙げたのが、韓国のゲーム開発会社の事例だ。会社が狙われて、社内ネットワークに侵入され、ゲームのプログラムに使用していたコード証明書が盗まれたのだという。そのコード証明書が不正送金マルウェアで使われた。「不正送金で狙われるのではなく、不正送金を行うために、開発や運用に携わっている会社が狙われるという可能性がある」(根岸氏)というわけだ。

新井氏は、同じようなケースとしてStuxnetを挙げた。イランの核実験施設を破壊したとされる有名なマルウェアだが、半導体機器などを作っている会社の証明書が盗まれて、プログラムにコード署名された。「こうしたケースは、今でも、散見されています。開発エンジニアも、狙われるリスクがあるということは知っておいたほうがいい」(新井氏)とアドバイスした。開発者目線での話として、辻氏は、パスワードフォームでの使用文字に制限がある事例を紹介した。セキュリティ専門家の立場としては、パスワードは大文字小文字記号などをあわせた強固なものを設定することをアドバイスしている。だが、いざ、ユーザーがそうしたパスワードを作成しても、フォーム上で受け付けないことが少なくないのだという。

「記号が通らなかったり、6文字以上8文字以下しか入力できなかったり。ユーザーが意識を高く持っていても、ダウングレードしなければならない。いろいろな事情があるのはわかるが、開発者が頑張ろうという意思を崩さずに設計していってほしいと思う」(辻氏)これに対し根岸氏は、複雑なパスワードを設定できるサイトを称賛するというアプローチも有効と指摘した。「仕様でしばるのは難しいという気がしている。海外では、第三者的な機関が、複数のeコマースサイトを調査して、パスワードの安全性の格付けレポートを公表するといった取り組みがある。ここがひどい、ここがすばらしいといった消費者からのプレッシャーでサービスを改善していくことができる」(根岸氏)

狙われやすい開発環境は? どのくらいコードを書く?

後半のディスカッションのあとは、会場からの質問を受け付けた。すると「狙われやすい開発環境は何?」「インシデントレスポンスで開発者はまず何をすべき?」といった質問が飛んだ。狙われやすい開発環境については、新井氏が「CなどのOSに近い言語よりは、perlやphpといったWebアプリ向けの言語が狙われやすいという実感がある。Windows OSやIEなどの脆弱性を突く攻撃は非常にしんどい。それにくらべて、Webアプリは1つ抜けがあると、パッと広がる。SandboxやJailのような技術で封じ込めるやり方もあるが、それでも感染の拡大は止められないことが多い」と回答した。

これを受けて、辻氏は「事故の事例でいうと、圧倒的にWeb系が多い。最近では、WordPressのプラグインなども狙われている。誰がいつ作ってどうメンテナンスしているかがはっきりしない。Webサイトを制作した会社がテンプレのように提供するため、そもそも発注者が把握していないというケースが多い。クライアントの話になるが、これは購入時からインストールされていることの多いJavaやAcrobat Readerにもあてはまる。自分たちの環境内に何が存在しているのかを、まず把握しなければそれをメンテナンス、最新版にしようという意識がもてない」とした。また、セキュインコ氏は、「事故が起きるシステムを見ているとメンテナンスされていないことが多い。その原因は、設計段階でメンテナンスが考慮されていないことにあると思います。問題が出たときも、手順が曖昧なため、後手後手にまわる。そこは開発の段階から気にしなければいけないポイントだと思う」とした。

セキュリティインシデントで気をつけるべきポイントとしては、根岸氏が、「脆弱性を指摘されたときの対応の重要性」を挙げ、「インシデント対応の部署にいるが、実際にどこに指摘がくるかはわからないことが多い。正規の窓口にこなかったときに対応を誤ると、マイナス点を稼ぐことにもつながる。(脆弱性報告制度のある)IPAを通さずに、直接、脆弱性の指摘がくるケースや、バグ報告の報奨金(Bug Bountry)制度があってもそれとは別の部署にくることもあり、そうした場合に、きちんとハンドリングできるか、指摘をきちんと拾えるかが重要」と述べた。

このほかにも、「セキュリティ業界に入ったきっかけは?」「実際にどのくらいコードを書く?」などといった質問が出て、セキュリティの達人はそれぞれの経験やキャリア、考え方を交えながら、丁寧に回答していた。軽妙ながら内容の濃いディスカッションが続くなか、予定時間は20分あまりオーバー。その後の懇親会も含めて、最後まで盛り上がりを見せていた。