「セキュア開発」って何？ ためしに検索エンジンに「セキュア開発とは？」と入れてみてください。上位にKDLのブログ「セキュア開発の推進のために取り組んでいること」が出てきます。そこには《セキュア開発とは、従来のシステムの完成・納品前に実施される脆弱性診断だけではなく、そのずっと前の工程であるシステムの要件定義、設計、開発段階から全体の安全性に留意して開発する手法です》《KDLでは2017年ごろから「セキュア開発推進」という部署を設け、本格的に取り組みはじめました》と書かれています。
このたびKDLでは、この「セキュア開発」の「トレーニング」を外販することとなりました。概要は以下の通り。
セキュア開発トレーニングのご紹介
ABOUT
セキュア開発トレーニングは、ECサイトや業務システムなど、主に個人情報や機密情報を扱うシステムの開発者向けのサービスです。
開発チーム全員が共通認識を持ち、プロジェクトの初期段階から脆弱性を作りこまないセキュア開発の手法を身に付けることで、脆弱性の発見も早まり、リリース直前のコスト増加やスケジュール遅延を防ぐことができます。
トレーニング概要
なぜセキュア開発に取り組むのか、まず何から始めればいいのかといった基礎から、システム実装時の具体的な設定や制御の方法、その必要性などについて学んでいただくトレーニングです。テーマごとの講義や質疑応答に加え、途中何度かの理解度テストを実施し、受講者がどれくらい理解できているのかを評価しながら進めます。
対象者：ECサイト、業務システムなどを開発する企業の開発者
受講スケジュール：全8時間
※原則、8時間×1回。4時間×2回、2時間×4回での実施も対応可能です。
但し、初回実施後30日以内にすべてのトレーニングを受講いただける場合に限ります。
場所：オンライン
受講者数：最大100人
価格：※価格は別途お見積りさせていただきます
※お客様の業務内容や開発者スキルレベルに応じたトレーニング内容のカスタマイズも承ります。
トレーニング実施後、当⽇に参加できなかった⽅や社内の他の開発者にもご活⽤いただけるよう、講義の録画や使⽤した資料をご提供する予定です。
KDL公式YouTubeチャンネルで、セキュア開発トレーニングの第一回講義の様子を少しだけご紹介しています。
なんで「トレーニング」なんですか？
石井：
……ということで、「セキュア開発トレーニング」の概要はわかりました。しかし、謎は残ります。「セキュア開発トレーニング」を担う生産技術チームの皆さんにぜんぶ訊きましょう。まず、なぜセキュア開発トレーニングを外販しようと考えたのかを教えてください。
松田：
セキュア開発トレーニングは、もともとKDLの社内向けに始めたものです。
山岡：
社内でやってみて、「これは良い」と実感しました。この良い経験を広めていくことは良いことではないか、と。
トレーニングはKDLにとって必要だった。
それなら、他の会社にも必要なはず
石井：
皆さん、今まで社内でどんなことをやってきたのですか？
大崎：
うちのチームは、もともとシステム開発プロジェクトの品質管理を専門に行っていました。
松田：
プロジェクトマネージャー（PM）にプロジェクトの円滑な進行を支援するルールを提供し、遵守しているかをチェックする仕事です。PMと喧嘩するのが役割ですね（笑）。
石井：
さて、そのチームがセキュア開発トレーニングに携わるようになったきっかけは？
松田：
たしか2014年ごろですね。その当時、あるセキュリティ事故について判決がでました。SQLインジェクション攻撃に対する対策が十分にできていなかったことで、クレジットカード情報の流出被害に遭った企業が、開発を担当したシステム開発会社を訴え、開発会社に対して損害賠償の支払いが命じられたんです。「この判例やべえな」と。じゃあ何をすればいいかとなりまして、「リリース前に脆弱性診断をきっちりやる」というルールを決めて、ぼくと山岡さんで一緒にやりだしたんですけど……。
山岡：
これが、なくならないんですよ（笑）。こちらが何回言っても、開発現場からは同じ脆弱性が出る。脆弱性発生を防ぐツールも入れてみたんですけれど……。
松田：
使い方を知らなければツールもうまく使えない。セキュリティのことをよく知らない開発者は、アプリが動かないときにツールの機能をオフにして作業を続けるということをやりがちなんです。結局そこが脆弱性の穴になる。「これを解決するにはトレーニングじゃないか」と。
石井：
そこでなんで「トレーニング」なんですか？
トレーニングにたどり着いたのは
KDLのこれまでの開発実績があるからこそ
松田：
われわれは脆弱性診断をして「ここを直しなさい」と言い、そのときは直るんです。しかし、チームの担当者にしか伝わっていない。でも、攻撃者はいちばん弱いところを突いてくる。開発チーム全員が同じ原則に従って同じように開発できるようにならないと駄目なんです。なので、全員参加必須のトレーニングで教えていこうと考えました。
石井：
トレーニングは、なぜ、有効なんですか？
松田：
「教えてもらわなきゃわからないこと」って、けっこう多いんです。たとえば、セキュリティの世界では「パスワードはハッシュ化して保存する（※）」という考えがあり、KDLの中では常識なんですけれど、まだそのことを知らない開発者が世の中にはけっこういるんです。
大崎：
そう、原理原則とか知識って、教えるしくみを意識的につくっていかないと身につかないんですよ。
※「ハッシュ化」とは、データを規則性のない文字列に変換する処理のこと。鍵を使って元に戻すことができる「暗号化」とは異なり、ハッシュ化したデータは元に戻せないこと（不可逆性）が特徴。パスワードをハッシュ化して保存しておくことで、仮に第三者が不正にパスワードにアクセスしたとしても、復元が困難なため、悪用されるのを防ぐことができる。
はっきりと成果が出たんです
石井：
さっき「全員参加必須」とおっしゃいましたね。「全員」って誰ですか？
松田：
「開発に携わる人全員」です。KDLで言えば全社員150人のうち100人くらいですね。
石井：
「全員対象のトレーニング」がKDLで可能になったのはなぜですか？
松田：
社内に「これからはトレーニングだ！」と、声が大きい人がいたというのもあるんですが（笑）、トレーニングを社内で1年続けたときに、はっきりと成果が出たんです。リリース前の脆弱性診断で開発チームが「ここを直しなさい」と指摘を受けることが30%減りました。「直しなさい」と言われてから必死に、それこそ夜を徹してのデスマーチで一気に直すことが減り、安全にリリースできるようになりました。
大崎：
リリースが差し迫った状態で問題が見つかると、要は後手後手になってしまう。そうやってできた成果物っていうのは、やっぱり品質に問題がある。そうならないように、前段階から脆弱性を意識して、つくることができるようになったわけです。
F1に例えると、いくら車が良くても、運転手が下手だと事故が起きる。
セキュリティツールも同じ
石井：
100人のエンジニアのデスマーチが１年間で30％減った。この実績をもって、KDLはセキュア開発トレーニングを外販していく、と。さて、そのお客さまはどんな方ですか。
松田：
ユーザー企業さんがメインになるかもしれません。最近は、当社とお取引のあるユーザー企業さんからも「自分たちでプログラムを書きたい」という要望が増えています。そのような企業さんが自社でアプリケーションを開発する前に、KDLのトレーニングを受けていただくことで、よりセキュアな開発を行えるようになると考えています。ぼくらシステム屋は、若いころにたとえば「Stack Overflow（プログラマ向けQ&Aサイト）に書いてあるコードはそのままコピーして使うな」といったことを口すっぱく教えられてきましたが、大きなユーザー企業さんの中には、そういうことを改めて学ぶ機会がない方も多いと思います。
大崎：
一方で、ユーザー企業さんほど、先ほど申し上げたSQLインジェクション事件のことはご存じだったりする。
松田：
お客さまに近いぶん、ユーザー企業さんのほうがセキュリティに対して敏感かもしれませんね。
つくっているのは「実践的なカリキュラム」です
石井：
KDLのセキュア開発トレーニングを競合他社と比較したとき、KDLの優位性は？
松田：
わたしはトレーニングカリキュラムをつくっているので、色々な記事を読んだり、セミナーで話を聞くのですが、セキュリティの専門家が作成しているカリキュラムは「攻撃」の方法や被害事例が多く取り上げられていて、「守り方」の情報が少ないと感じましたね。
石井：
では、松田さんは何の専門家なんですか。
松田：
ぼくは開発者です。ぼくがつくっているのは、泥棒がピッキングする手法を詳しく学ぶのではなく、「ピッキング防止用の鍵を買って、効果的な場所に取りつける」という実践的なカリキュラムです。攻撃の手法を山ほど覚えるよりも、「ここから入ってくるだろう」というところを強化する。カリキュラムをつくりながら実感しているんですが、組織には古くからの考えとかいろんな障壁があって、そこに浸透して変えていかないと、セキュリティってちゃんとできないんじゃないかなと思うんですよ。
石井：
組織風土の問題ですね。
山岡：
そうですね、「今までのやり方がいちばん効率がいい」という、変化を嫌う考え方はKDLの中にもありますが、じゃあ、なんでうちが全員参加のトレーニングを始めることができたかというと、トップダウンが大きかったんですよ。
松田：
さっき言った「これからはトレーニングだ！」と、声が大きかった人（笑）。
山岡：
さっき松田さんが言った泥棒の話のような比喩が響くトップの方っていると思うんです。そういう方から社内に「落として」いただくのがいちばん効率がいいのかな。
石井：
となると、セキュア開発トレーニングを買うお客さまは、トップのセンスが良いとも言えますね。そのぶん、厳しいお客さまかもしれませんが。センスがあるお客さまとの遭遇が、今から楽しみです。
みなさん、一緒にトレーニングしましょう！
（実はハイブリッド収録でした）
今なら、第1回講座を無料でトライアルできます！
お問い合わせの内容欄に、「セキュア開発トレーニング無料トライアル希望」とご記入ください。
無料トライアルお申し込み
大崎 努おおさき つとむ
株式会社 神戸デジタル・ラボ
デジタルビジネス本部 生産技術チーム部長
1978年生まれ。北海道情報大学経営情報学部情報学科卒。2000年、KDLへ新卒入社。WEBシステムの基盤設計・構築、ECサイト構築案件などに従事。2020年、自社開発案件の品質向上を目的に生産技術チームを発足、開発プロセスの改善や効率化などをリードする。
山岡 賢一やまおか けんいち
株式会社 神戸デジタル・ラボ
デジタルビジネス本部 生産技術チーム所属
1971年生まれ。大阪府立大学工学部応用化学科卒。ソフトウェア開発企業での管制システム開発などを経て、1998年にKDL入社。ECサイトやWEBシステム構築案件を担当。2013年より、KDL独自の標準開発プロセス作成に携わるなど、PMO（Project Management Office）の役割を担う。
松田 康司まつだ こうじ
株式会社 神戸デジタル・ラボ
デジタルビジネス本部 生産技術チーム所属
1982年生まれ。神戸大学工学部情報知能工学科卒。モバイルコンテンツ提供企業などでサイトやアプリの開発、サービス立ち上げに携わる。2014年、KDL入社。ECサイト構築案件を担当するとともに社内のセキュア開発推進にも従事。2021年よりセキュア開発推進担当とPSIRTを兼任。
石井 伸介いしい のぶすけ
神戸デジタル･ラボ 広報アドバイザー（株式会社苦楽堂 代表）
1963年生まれ。文教大学情報学部広報学科卒。1986年、プレジデント社⼊社。「プレジデント」副編集長、書籍部長などを経て2013年末に退職。2014年、阪神・淡路大震災の取材以来通い続けた神戸に移住し、出版社「株式会社苦楽堂」を創業。
建設現場の安全文化向上を
支援するプロダクト
「アザス」開発を支援
「アザス」は、建設現場で働く職人の日々の行動や習慣を称賛し、また、現場で起こったヒヤリハットを職人自らスマホアプリを使って報告していただくことで、安全な現場環境の整備や安全文化の醸成を支援するものです。
KDLは、スマホアプリのUX/UI設計およびデザインのコンセプトづくりと、サービス全体のプロダクト開発を担当させていただきました。
リアルのコミュニケーションの良さを損なわず、且つデジタルのメリットを享受できるように様々な視点で案を出し合いUX/UIを設計しました。開発フェーズにおいては、要件の定義から設計・実装・テストといった⼀連の⼯程をタスクを分散しながら短期間で繰り返すスクラム開発（アジャイル開発のひとつの⼿法）を採⽤。「アザス」のコンセプトや想いを全員が理解し、同じ目標を共有しながら進めることで、想いの詰まったサービスをリリースできました。
リリース後も、操作性の向上や利用状況に応じた改善提案など、継続的に運用を支援させていただいています。
※「アザス」は日揮ホールディングス株式会社と株式会社神戸デジタル・ラボの合弁会社「JGC
Digital株式会社」により提供されています。
セキュリティ機器のログ管理状況を
手軽に調査する
「ログ設定診断」
サービスを開始
もし、サイバー攻撃などのセキュリティインシデントが発生した時、復旧・状況の把握を行うために必要になるのがIT機器の活動状況の記録、すなわちログです。皆さまは適切なログを取得・管理することができていますか？
KDLの情報セキュリティサービス「Proactive
Defense（プロアクティブディフェンス）」ではセキュリティインシデント発生時の対応を行っていますが、いざ調査を開始すると、必要なログが管理されていないケースが多くあります。結果として、セキュリティインシデントの根本原因、その影響範囲、情報の流出があったのか無かったのか、もし流出していたとしてその情報は何だったのかなど、重要な情報が確認できず、インシデントの事後対応が十分に取れないことが多いのです。
そこでKDLでは、「もしもの時」に必要となるWindowsサーバやセキュリティ機器のログが取得・管理できているかどうかを事前に調査するサービス「ログ設定診断」を開始しました。お客様企業で稼働している各種システムのログ取得状況をKDLのセキュリティコンサルタントが確認します。取得できているログの有効性を確認し、その状況からインシデント対応時に判断可能な内容を明示するとともに、多くのガイドラインに準拠できるような改善案をご提案します。
