KDL BLOG
セキュリティ事業部長の三木です。セミナー「サイバー攻撃に備える『DevOps』という選択」の参加レポート、前回に引き続いて、今回はKDLのセキュア開発推進・プロジェクトサポートチームの松田くんの登壇内容と、まとめをご紹介します。
そこでDevOpsという選択
いかにしてわれわれはセキュア開発に取り組み始めたか
最後に登壇したのは神戸デジタル・ラボの松田康司です。松田くんからは、「DevOpsという選択 いかにしてわれわれはセキュア開発に取り組み始めたか」というテーマでKDLがセキュア開発にどう取り組んだかの事例をご紹介しました。
このセキュア開発への取り組みは、私も絡んできたところです。
KDLはセキュリティ関連事業を事業部展開しており、開発部門がリリースするアプリケーションやシステムに対してセキュリティ事業部が第三者として脆弱性診断を行っていました。それによるセキュリティの担保が当社のシステム開発のウリでもありました。
しかし、縦割りの部門体制の中、理想のタイミングで診断を行うことが出来ないとう問題がでてきたため、開発部門に診断ツールを持たせ、開発部門による脆弱性診断の「内製化」を進めることになりました。そこを担ったのがこの松田くんです。
脆弱性診断を内製化してわかったこと
もともとは納品前の脆弱性診断を内製化することを目的としていましたが、実際に内製化して分かったことは以下のとおりでした。経緯はこちらのブログで詳細をご紹介しているのでぜひご覧ください。
私も、実はこれらはなんとなく問題として見えていました。特に3つ目は、セキュリティ事業部が診断して発見してくれるから、というスタンスでセキュアに開発するという観点が足りないように感じていました。
そこが、開発部門自らが脆弱性診断をするようになったことで、自分たちで能動的に解決できることとして認識できたのです。なぜもっと早く内製化しなかったんだろう。。。反省
まずは指標を活用して成熟度を可視化
そこで彼のチームが取り組んだのは、要件定義、設計、開発にセキュリティ要素を加えていった。まさにシフトレフトです。ただやみくもに実施するのは良くないとして利用したのがOWASP SAMM（ソフトウエアセキュリティ保証成熟度モデル）でした。これを使って、段階ごとの成熟度を可視化して、進捗確認していったそうです。
セミナーではその可視化の進み方を赤裸々に紹介していました。
どの施策も同様、目標・指標を持たずして改革を始めるのは非常に難しいので、最初にこのような指標を使い、継続的にモニターするのがベストですね。
セキュリティ要件の決定は開発側主導に
セキュリティ要件については、「これまではお客様からの指示があればそれに従う」のスタンスでしたが、プロジェクトメンバーで検討会議を実施し、自ら要件を決定していくようにしました。ただしその検討の前に、事前に次のことを想定してプロジェクトメンバーに共有そこから要件を決めていったとのことです。
- ビジネス要件にあった脅威想定
- コンプライアンス
- セキュリティ7要素のプロファイリング
ここまでやっている開発会社がどれだけいるだろうか（手前味噌）。このようにして決定したセキュリティ要件を実装してライブラリに利用、脆弱性診断後にライブラリにフィードバックするサイクルを回すようにしたところ、脆弱性診断の指摘が劇的に減ったとということでした。
質疑応答セッション
最後に、講演中に参加者の皆様にお書きいただいた質問について、回答するという形式で質疑応答のセッションを行いました。
「部門間の対立をどう解消したか」や「脆弱性でよく見つかったものは何か」など、リアルな現場に向けたぶっちゃけどうですか？という質問が多かったように思いました。
まとめ
3者のセッションを聞いて、以下の共通点を感じました。
- 運用・開発に上流下流はない
- 垣根をとっぱらって同じスタンスで議論する
- 可能な限り自動化・フロー化する
一見遠回りで手間のかかるアクションに見えますが、結果的にシステム自体の品質が上がり、コストが下がるということを改めて実感しました。
ご参加いただきました皆様、ありがとうございました。
