中小企業が実践すべき「セキュリティ・バイ・デザイン」 ~“セキュリティ後付け”のリスクを減らす~

「セキュリティ・バイ・デザイン」というキーワードを耳にする機会が増えてきました。
情報セキュリティに関係する省庁をはじめ、IPA(情報処理推進機構)などの業界団体も、経済社会への浸透を視野に方針やガイドラインを発表しています。

デジタル庁は2024年1月、「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」を公開。文書の対象は政府情報システムと関係する組織ですが、ここで示された内容は一般企業や調査機関からもよく参照されていて、この手法に対する認知度も高まってきました。

セキュリティ・バイ・デザインは、情報システムの企画段階から、セキュリティ機能を組み込むという考え方です。現状はサイバー攻撃による被害が起きてから、セキュリティを実装するやり方が多いのですが、実践のタイミングを企画段階から行うことで、安全対策にかかるコストと工数の大幅な削減が期待できるのです。

セキュリティ・バイ・デザインは2000年代から提唱されていて、特に新しい概念ではありません。ここ数年拡がってきた背景には、やはりサイバー攻撃の大規模化と先鋭化があります。被害企業の経済的損失の大きさ、社会的信用の低下などの影響が年々深刻化していくに伴い、安全対策を抜本から見直す機運が高まってきたのです。

今のところ積極的に取り組んでいるのは、政府機関や公共施設、大企業、ソフトウェアメーカーやクラウド事業者などのIT企業が中心ですが、セキュリティ対策の有効な指針は、分野と組織の規模は問いません。デジタル庁の「ガイドライン」などは、委託先のセキュリティ対策にも言及しており、いずれ中小の事業者も参加するサプライチェーンにも波及していくと見られています。

デジタル庁の「ガイドライン」では、「セキュリティ・バイ・デザインの概要」という項目の冒頭で、以下のように記述しています。

「企画工程からセキュリティを実装すること」のメリットは、まずコストの削減が挙げられます。IPAによる「セキュリティ・バイ・デザイン導入指南書」では、設計時のセキュリティ対策コストを1とすると、開発段階では6.5倍、テストの時点は15倍、そして運用時になると、必要なコストは100倍に達するとの試算を示しています。

IPAのコスト比較の話は、システム・ソフトウェア開発を例にしたものですが、考え方はシステムの導入側にも当てはまります。インシデント後に対処する場合、企画段階に比べると実装できる手段の選択肢が狭まり、結果的に高コストにつながります。導入を決めたツールは、既存システムと馴染まないなどの問題が起こりがちで、追加コストも想定しなければならないでしょう。

テストの結果、新しい脅威への対策が不十分と判断したら、設計の工程に後戻りします。人手が限られる環境では、工数の積み増しも軽視できません。セキュリティ・バイ・デザインに沿った手法は、コストと工数の削減、そして保守性にも優れたシステムの構築と運用が期待できるというわけです。

セキュリティの後付けが不利な理由を、中小企業にも身近な例で考えてみましょう。
例えば、新しく参加する企業グループのサービスで、ログインパスワードが15桁以上と決められた場合、既存システムが対応できなければ、設計からの見直しが必要です。最近は多要素認証が求められる場面も多いため、実装できなければ大幅な改修が必要になるかもしれません。

先ほど挙げた認証の例は、セキュリティ・バイ・デザインの全体像から見るとごく一部、フィールドにおける調整の一つに過ぎません。システムの企画段階から実践するには、業務内容と情報システムの全体像、仕様、対応する人員とそのスキル、セキュリティに対する経営層の考え方、そして予算などの要素を加味し、大きな視野から行う必要があります。

セキュリティ・バイ・デザインは、“考え方は平易だが、取り組み方が難しい”という声も聞かれます。今のところ明文化されたルールのようなものはなく、組織に応じた進め方があること、まだ歴史が浅く経験を積んだ人材も少ないなどの点が背景にありそうです。

デジタル庁の「ガイドライン」やIPA「導入指南書」は、こうしたニーズに応えたものです。
これらは組織の推進体制から役割分担、リスク分析と要件定義などのプロセス、運用後の管理方法など、取組み方を体系的に示したものですが、ここでは実践的なセキュリティ対策として、形をイメージしやすい部分を抽出してみます。

デジタル庁「ガイドライン」の「セキュリティ・バイ・デザインの概要」では、基本方針として以下を挙げています。

いくつか補足すると、「1.予防的な対策」は、その時点で想定できる脅威にできる限りの対策をしておくこと。例えば、一般的なセキュリティ上の問題として、一部のWebアプリケーションには、パラメータを改ざんすると本来は扱えないデータを操作できてしまう脆弱性がありましたが、こうした穴を事前に塞ぐセキュアコーティングのような手法は必須です。

「2.全ての開発ライフサイクルを保護」は、特定の工程だけでなく、開発の全工程をカバーすること。外部の事業者に委託する際も、セキュリティ・バイ・デザインの視点から一貫した管理が求められるとしています。

「3.初期設定値で安全を担保」は、管理者アカウントと権限などの初期設定値を、セキュリティが担保された状態にすること。初期設定のままで攻撃されてから対処するのではなく、設計段階からできる限りセキュアな状態、“セキュリティ・バイ・デフォルト”を前提とします。

IT分野の人員とスキル、経営層の積極的な関与、そして出資が欠かせないセキュリティ・バイ・デザインですが、中小企業もフォーカスを絞れば、その効果を取り込むことは難しくありません。この方針が浸透する流れを先取りし、できるところから実践して企業活動の安全性を高めていく道はあります。

視点の一つは外部委託の方法です。
中小の事業者は、社内にシステム部門を持たないか、部署はあっても限られた人数で回し、開発と保守は外部に依存する部分も多いと思います。まず委託先の選択ですが、最近のSIer(システム開発事業者)などは、セキュリティ・バイ・デザインを意識するところが増える傾向にありますので、企業理念などを参照すれば目安の一つにできるでしょう。

次はより実践的な段階、システム構築の委託やサービスの選択時に考慮する内容です。
外部に対しては、セキュリティ・バイ・デザインの方針に合致する要件を示します。具体的には、これまで触れてきたようなセキュアな開発環境、多要素認証を必須化する環境、脆弱な初期設定値の回避などの要素がありますが、これらが企画段階から指定できるか否かがポイントになります。

またクラウドサービスでは、国内では今のところ、セキュリティ・バイ・デザインに直接言及した基準はないようですが、総務省の「クラウドサービス提供における情報セキュリティ対策ガイドライン」などは、設計段階の安全対策にも触れています。こうした基準への対応状況も参考の一つになりそうです。

中小企業の場合、セキュリティ・バイ・デザインは過度な負担がかからないように小さく始めること。新規導入、あるいは大きな改修を予定するシステムなど、より実践しやすい部分から、また顧客管理や従業員のアクセス管理など、より重要なところから、スモールスタートで取り組んでください。