注目イベント!
アドベントカレンダー2024開催中!
一年を締めくくる特別なイベント、アドベントカレンダーを今年も開催しています!
初心者からベテランまで楽しめる内容で、毎日新しい技術トピックをお届けします。
詳細はこちらから!
event banner

いま改めて、セキュリティ・バイ・デザイン(SBD)を考える

| 3 min read
Author: yasuhiko-nishio yasuhiko-nishioの画像

これは、豆蔵デベロッパーサイトアドベントカレンダー2023第7日目の記事です。

こんにちは。ES事業部の西尾と申します。
主にテスト、セキュリティ、モデリングの3分野に関心を持ち、日々お客様の課題解決の支援に取り組んでいます。

今回は、私が関心を持っている分野の1つ、セキュリティについてのネタで、セキュリティ・バイ・デザイン(SBD)というお話です。

「なぜこの記事を書くに至ったか」というテーマにも注目して、最後までお付き合い頂けますと幸いです。

SBDとは

#

2011年の内閣官房情報セキュリティセンター(NISC)における下記の検討会で提唱されて以降、SBDは一般に認知され始めました。

「情報セキュリティを企画・設計段階から確保するための方策(SBD: Security By Design)に係る検討会」

平たくいうと、企画・設計段階から、セキュリティを作り込もうという活動のことです。

なぜこの記事を書くに至ったか

#

みなさんも、上記のSBDの意義には否定の余地はないはずです。ただ2020年くらいから、SBDについてあまり聞かなくなったと思いませんか?

「SBDを最近聞かないが、SBDは今でも大事でいろんなアプローチの仕方がある」

この記事を書くに至ったのは、それを伝えたかったためです(本記事のテーマでもあります)。

SBDを聞かなくなった?

#

2011年のSBD提唱から4年後、2015年にはIPAから「つながる世界のセーフティ&セキュリティ設計入門」が発行されました。

2016年にはまた、IPAから「IoT開発におけるセキュリティ設計の手引き」も発行されましたよね。この時期はSBDに関する情報発信が比較的盛んだったように記憶しています。特にモデル化の仕方については、筆者も参考にしていました。

画像説明を記述

ただこのSBD、現場で使うと「モデリングして(絵を描いて)終わり」になってしまったこと、なかったでしょうか?今でもSBDの解説は検索すれば出てきますし、2022年にはIPAから「セキュリティ・バイ・デザイン導入指南書」も発行されていますが、設計のやり方まで踏み込んだ内容に出会うことはまだ少ないと感じています。

SBDは今でも大事でいろんなアプローチの仕方がある

#

SBDは、SBOMやDevSecOpsに取って代わられるか

#

「セキュリティを開発段階から考えよう」という考え方に関するものとしては、SBDよりよく聞くようになった取り組みがありますね。SBOM、DevSecOpsといった取り組みです(それぞれの詳細はここでは割愛します)。先述の「セキュリティ・バイ・デザイン導入指南書」にも触れられています。

SBDは設計技術に依存するため、SBOM、DevSecOpsへの取り組みは「セキュリティを開発段階から考えよう」に対する解としては、「手っ取り早くかつ、確実である」という見方もできます。

画像説明を記述

しかし、だからと言ってSBDは役に立たないという話になるでしょうか?

SBOMやDevSecOpsは、セキュリティの作り込みという点で考えると、どうしても後付け(出来てから)の対応になりやすいと考えています。このため、筆者はSBDが役に立たないとは考えておらず、SBOMやDevSecOpsを有効活用する上でも継続して見直されるべきものと考えています。

セキュリティベンダに任せれば良いか

#

SBOM、DevSecOpsだけでなく、SBDを導入する上では、セキュリティベンダに任せるのは1つの選択肢と言えます。導入保守コストの目途が立っていればなおさらです。

ただ、QCDの観点で最適なところにSBOMやDevSecOpsのツールならびにSBDを導入するのは、利害関係者の要望・要求を正しく抽出し、要求の分析や設計がなされていることが前提ではないでしょうか。

また、セキュリティベンダの言語・文化と、SBDを導入したい現場の言語・文化の齟齬が生じやすい問題もあります。そうした状況[1]の中、安易なツール利用等でセキュリティ対策を決着してしまうと、部分最適(セキュリティは最適だけど、他は最適でない)の視点から、課題も残ると筆者は考えています。

画像説明を記述

ソフトウェアエンジニアリングの開発プロセス全体の中でSBD

#

もちろん、先で述べた部分最適にならぬよう、開発全体を見たSBDを実践しているセキュリティベンダもあるかもしれません。

ただそうでない場合は、一般的に認知されているソフトウェアエンジニアリング[2]の知見を共通言語とし、その共通言語をもとにセキュリティの知見を駆使した方が全体最適を実現できるケースもあると筆者は考えています。

このため、上記のような場合は、

「ソフトウェアエンジニアリングの開発プロセス全体の中で、SBDの位置づけを明確にする」

というアプローチも1つの選択肢と考えています。

画像説明を記述

以上ここまで、「いま改めて、セキュリティ・バイ・デザイン(SBD)を考える」というタイトルで「SBDを最近聞かないが、SBDは今でも大事でいろんなアプローチの仕方がある」というテーマで書かせていただきました。

開発段階におけるセキュリティへの取り組みはSBDだけでなく、SBOMやDevSecOpsというやり方も出てきている。セキュリティベンダに任せるアプローチもあるが、そうでないアプローチもある。という内容についても伝えられたのなら幸いです。

次回は、本記事をさらに掘り下げた内容「ソフトウェアエンジニアリングの開発プロセス全体の中で、SBDの位置づけを明確にする」について書いていきたいと思います。

最後までお読みいただき、ありがとうございました。


  1. 利害関係者の要望・要求を正しく抽出できてなかったり、要求の分析や設計がなされていなかったり、セキュリティベンダの言語・文化と、SBDを導入したい現場の言語・文化の齟齬が生じやすい状況。 ↩︎

  2. INCOSE/OMG/SWEBOK等の要求定義から設計実装へと続く開発プロセス標準、ISO29119/ISTQB等のテスト標準等。 ↩︎

豆蔵では共に高め合う仲間を募集しています!

recruit

具体的な採用情報はこちらからご覧いただけます。