全プログラマーが一般教養として知っておくべきセキュアプログラミング、「明日から現場に生かせる」短期集中講座が開講

セキュリティ人材よりも不足している
セキュアコーディングが行える人材

　一般にセキュリティ対策といえば、ファイアウォールやウイルス対策といった入口対策、監視・監査・多重認証といった出口対策、あるいは教育やリテラシーの向上から語られることが多い。もっともなのだが、この視点で決定的に欠けているものがある。

　それは、ソフトウェアの脆弱性について開発者側による事前の対策という視点だ。近年は標的型攻撃やフィッシングなど詐欺的な攻撃が広がっているため、問題発見してからの対応に目がいきがちである。しかし、これらの被害にあっても、OSやアプリの脆弱性がなければ被害を食い止めることができる。

　そのためには、セキュリティアップデートなどでソフトウェアを最新のものに保つ必要があるが、そもそも、開発段階から脆弱性を作り込まないという対策アプローチこそあってしかるべきだ。

　「この点について、日本は欧米に比べて5年くらい遅れています。セキュリティ人材が足りないといいますが、本当に不足しているのはセキュアなプログラミングが可能な人材だと指摘する専門家もいます。また、自社製品をアプリやクラウドサービスなど他社ソフトウェアの組み合わせで提供する企業が増えていますが、実際にデータ漏えいなどの問題が起きた場合、エンドユーザーは実際の開発元がどこかなど気にしません。ですから、直接開発部門を持たないプロバイダーやベンダーだとしても、セキュア開発を知ることは重要です」（岡田氏：以下同）

ペンテストやWAFだけに頼っていないか

　「うちはペンテスト（ペネトレーションテスト）をちゃんとやっている。導入先はWAFを入れたり、ネットワークの監視も行っている」という反論もあるだろう。あるいは、セキュア開発の重要性を理屈では理解していても、ビジネスにおけるインセンティブが薄いと見る傾向もあるだろう。一般にセキュリティ対策や関連業務はコストセンターとみなされることが多い。設計や開発に余分な工程やコードの制限を加えられることへの抵抗感も無視できない。

　これらを踏まえたうえで、岡田氏はセキュア開発・セキュアコーディングの重要性を説く。

　「設計・開発段階からセキュリティを意識して設計し、必要な機能を盛り込み、セキュアになるよう基準を設けて構築していくことをビルトインセキュリティや、セキュリティ・バイ・デザインなどと呼びますが、それらをすぐに開発フローに組み込むことのハードルの高さは分かります。しかし、コード自体に含まれる脆弱性を減らすことや攻撃を前提とした設計を行うと、システムへのセキュリティ被害の発生を抑え、ひいてはその後のコードのメンテナンスは楽になり、再利用性の高いプログラム資産が増えることにつながります。他方、実際にインシデントを発生させてしまったら、システムの修正と復旧、顧客対応、株主などステークホルダーへの対応、あるいは訴訟や行政による処罰などのペナルティ対応も考えなければなりません。その被害は、めったに起きないから大丈夫だ、で済むレベルではなくなっています。決してペンテストやWAFが無駄だという話ではなく、そういった施策に加え、ビルトインセキュリティを実践しましょうということです。できる手立てがあるのにそれを放置しているところを、攻撃者は容易に見つけることができますし、それを見逃してくれることは期待できません」

脆弱性は事前に排除可能でもある

　攻撃には、物理的なもの、ユーザーを狙ったもの、ネットワーク（プロトコル）を狙ったもの、ソフトウェアを狙ったものなど、いくつか種類がある。破壊や盗難など物理的な攻撃を除けば、ソフトウェアはいずれの攻撃にも関係している。コマンドやスクリプトのインジェクション、メモリリークやヒープ領域を利用したバッファオーバーフローなどは、ソフトウェアの脆弱性の代表例だろう。

　逆にいえば、システムに深刻な影響を及ぼすソフトウェアの脆弱性に対する攻撃、例えばインジェクションやバッファオーバーフローなどは、ソフトウェアの実装で未然に防ぐことができるものだ。ビルトインセキュリティは、このような既知の脆弱性を事前に排除することができると岡田氏はいう。

　「ビルトインセキュリティはコードの品質、ひいては製品やサービスの品質に貢献します。ペンテストや、あるいは被害が起きてからコードの問題が発覚し、ようやくバリデーションを強化することがありますが、そもそもなぜ最初からチェックしていないのか、という話に必ずなります。さらに、ひとたび書いたコードやモジュールというのは伝播するので、他のシステムでも使われてしまっているかもしれません。そのような場合、被害や脆弱性が発覚した時、そのシステム内のプログラムだけ対策すれば終わりというわけにはいかないことでしょう。でも、問題のあるコードがどこに使われているかなんて、後から確認するのは現実的にはとても困難でしょう。そんな無駄や手間を避ける意味でも、ビルトインセキュリティは重要です」

セキュアなコードを伝播させたい

　実際、ビルトインセキュリティの考え方は、グローバルではかなり浸透してきている。マイクロソフトは、SDL（Security Development Lifecycle）として10年以上前からソフトウェアの開発にセキュリティ要件やテストを組み込んでおり、定期的なセキュリティアップデートと、製品そのもののライフサイクルを規定したリリースを実施している。

　日本では、Pマーク、ISO、PCIDSSのようなセキュリティ基準を重用している企業があるが、グローバルでは、これらのクライテリアの要件を実質的に満たすため、セキュア開発に注力している。このようにソフトウェアの品質を継続的に確保することは戦略的に重要な差別化ポイントになっている。

　セキュアな開発をしているといっても、それを客観的に示す指標がないため、ビルトインセキュリティの意義はなかなか理解されにくい。しかし、岡田氏は、「先ほど、コードは伝播するといいましたが、よいコードも同様に広がっていきます。開発者がセキュア設計・セキュアコーディングを身につければ、ソフトウェアと人材の流動により、堅牢なコード、よい開発スタイルが業界に広がっていきます。私がライフワークとしてセキュア開発やビルトインセキュリティに取り組み、その啓発や周知に力を入れているのは、この理由からです」と活動の意義を語る。

実践的な情報提供が重要

　ビルトインセキュリティの重要性を広めるミッションを負う岡田氏だが、必要性や効果、しないことの危険性を訴えるだけでは不十分だとも考えている。現場のエンジニアにしてみれば「では、具体的にどうすればいい？ なにを参考にすればいい？」という実際面の問題もあるだろう。

　「そのためにOWASPではOWASP Night、WASForumではHardening Projectといった活動を行っています。OWASP Nightは、Webセキュリティに興味のある人やセキュリティ担当者などの情報交換やセミナーを行っています。Hardeningは、セキュリティ競技により脆弱性のあるECサイトをチームごとにいかに工夫して堅牢にしていくかを競います。これらは、セキュリティを踏まえた実装や運営の実践者が互いに学び合う優れた機会になっています。

　ビルトインセキュリティの周知がままならない日本において、関連情報がどこにあるのか、どんな文献があるのかも分からないという人が多いかと思います。セキュリティのスキルは、コーディングにおいてもOJTが非常に有効な分野だと思っています。今回のセキュア開発Boot Campは、まさにセキュア開発とは、それはどうすれば実現できるのかを教えるために企画しました。タイトルにカッコ書きでCodeZine Academy Editionとしているのは、今回のためにアレンジ、追加した内容も用意しているためです」

「コードは動けばいい」の時代は終わった

　セキュア開発Boot Campは2日間のプログラムだ。初日は、まず現状理解から入るそうだ。Webアプリケーションのリスク、最新の攻撃動向などを紹介しつつ、ビジネスインパクトについても解説する。脅威の現実を知ってもらうためだ。そして、多くのサイトがやってしまいがちなコードを例として、その問題点や攻撃の仕方を解説する。そして、どうすればその問題点が修正されるのかをハンズオン形式で習得する。

　2日目は、ビルトインセキュリティの実現にかかわる問題に入る。初日に学んだ問題のあるようなコードを開発段階からなくす方法論の話だ。要件定義や設計段階で、どのようなセキュリティコントロールや検証を考えればいいのか。さらに、リリース前後に必要な情報収集や製品ライフサイクルの考え方を学ぶ。

　「インジェクションやバッファオーバーフロー、権限昇格など、問題のあるコードの種類はそれこそ膨大な量になりますが、実は問題となりがちなコードには特定のパターンや、共通のポイントがあります。初日の講習では、そんなスキルも身につくと思います。セキュリティは病気と似たところがあり、初日はいわば「治療」に相当する部分となります。病気をいかに発見し処置し、治療していくかという視点で脆弱性対策を考えます。

　この例からしますと、2日目は、「予防」です。セキュリティではプロアクティブコントロールなどと呼んでいますが、病気にかからない、感染しにくい体＝プログラムを作るための話です。PCI DSSやSDLのような脆弱性発生を防ぐプロセス、OpenSAMMといったソフトウェア開発ライフサイクルに関する話も取り扱います。

　いまは、プログラムは仕様通り動けばいい、という考え方は通用しません。「セキュアに」動作しないプログラムは大きなビジネスリスクだと考えるべきです。例えば、Webアプリケーションは何種類ものクラウドのAPIを組み合わせていることが多く、そのアプリケーションそのものも、他社に何らかのサービスを提供していることでしょう。このとき自社のサービスに脆弱性があり、インシデントを引き起こしたら、どれだけ多くのサービスが被害の影響を受けるでしょうか」

　興味をもった開発者の方は、ぜひこの貴重な機会に参加いただきたい。