脆弱性診断を内製化してみてわかったこと／セキュア開発の始め方

KDLはシステムの要件定義、設計、開発段階から脆弱性を作りこまない「セキュア開発」に取り組んでいます。主に既存のシステムをターゲットとした脆弱性診断やさまざまな対策支援サービスを展開しているKDLが、なぜ「セキュア開発」に取り組むようになったのか？

きっかけとなったのは、納品前の脆弱性診断を開発側で内製化したことでした。今回は脆弱性診断の内製化のメリットや気づきをご紹介します。

脆弱性診断とは

脆弱性診断とは、システムの脆弱性を見つける検査のことです。攻撃者の視点から様々な疑似攻撃をしかけ、潜在的な脆弱性を発見するものです。攻撃するには、ウェブアプリケーションに関する知識、攻撃する手法や最近の流行など、専門的な知識が必要になります。

経緯とわかったこと

従来KDLでは、開発したシステムの納品前にセキュリティ事業部が脆弱性診断を実施していました。しかし、もっと早いサイクルで診断を実施していく必要が出てきたため、これまで開発に携わっていたメンバーが脆弱性診断に関する知識やノウハウを学び、部内で開発したシステムに対して脆弱性診断を実施することになりました。

そして実際に診断をし始めると、様々なことに気づきました。

同じ診断結果が多い

まず、「同じような診断結果が多い」ということ。様々なシステムで脆弱性診断をするものの、毎回検出される脆弱性のタイプは決まっていました。つまり、典型的なものが繰り返されているということです。修正に時間がかかるものもあり、これが毎回検出されてはたまりません。

• クロスサイトスプリクティングの脆弱性
• HTTPレスポンスヘッダの設定不備によるインジェクション攻撃への脆弱性
• 登録可能なパスワードの文字数が短いことによる総当たり攻撃に対する脆弱性
  etc.

脆弱性について知識が少ない開発者が多い

検出された脆弱性を開発メンバーに説明すると、その脆弱性を知らないこともたびたびありました。知らないがために繰り返してしまうのです。

診断では見つけられないこともある

診断だけでは見つけられないことがあることを知りました。例えば、パスワードが暗号化されているかどうか、ログが出力されているかどうか、予防ではなく検知する仕組みはあるか、権限ごとのアクセス制限ができているかどうかなど運用面での問題も。

これらは脆弱性ではなくても、システムを安全に運用する上で大変重要な機能です。「予防する」という視点は、開発する側が意識していないと、対策を講じるところまで行き届かないのです。

勉強すれば診断できるようになる

脆弱性診断の方法は大変専門的な知識ですが、本が出版されており、サイトでも一般的に勉強できる環境が十分整っています。OWASP BWA （Broken Web Applications Project）やOWASP Juice Shopなど「やられサイト」と呼ばれる予め脆弱性が作りこまれた練習用のサイトもあります。エンジニアとしての基礎知識があれば、診断技術を身に着けることは可能です。

またKDLの場合は、セキュリティ事業部にプロフェッショナルが在籍しているので、いろいろ教えてもらえる環境も良かったと思います。

診断できるようになった結果

脆弱性診断をした結果、生産（開発）技術へのフィードバックができるようになりました。毎回検出される脆弱性は、フレームワークから手を入れて反映し、再発しないように対処しました。

また、開発者に対して定期的に脆弱性に対する教育（対策方法や実装方法、再現の方法など）の機会を設けるようになりました。結果、開発者のセキュリティへの意識が高まり、ポイントが抑えられるようになったことで、開発中やリリース後など必要なタイミングで診断を依頼するようになりました。

特に、アジャイル開発においては追加開発などのたびに診断を施すことができるので絶大な効果がありますよ！

診断の内製化がシフトレフトの始まり

経緯をご覧いただくと、脆弱性診断をして開発へのフィードバックをしていった結果、開発段階からのセキュリティ対策というシフトレフトが自然と始まりセキュア開発につながっていることがわかると思います。これこそが、KDLがセキュア開発に取り組むきっかけとなった出来事です。

日本ではセキュアコーディングが進まないという記事をよく見かけますが、その理由は「具体的に何をどう進めるのか？ということを知らないから」ではないでしょうか。最初から「開発段階でセキュリティ対策をしよう」ということを目標に定めると、実際にすべきことがわからなかったり、効率が悪かったりするものです。安心・安全なシステム開発を推進したい！というSIの皆様は、まず納品前の脆弱性診断の内製化をお勧めします！