情シスとセキュリティ・バイ・デザインは密接に関連している

1. 企画・設計段階からの対策「セキュリティ・バイ・デザイン」について

2024年は3連休以上が11回の“豊作”の年にあたる。祝日が土曜日に重なるか、日曜日に重なるかで３連休の数が変わってくる。気になったのでカレンダーを調べてみた。日曜日に祝日が重なる機会が5回、土曜日と重なるのは2回だけ。結果、振替休日が多くなっている！
>ちなみに9月は敬老の日 9月16日（月）があり、秋分の日 9月22日（日）が祝日で振替休日があるので3連休が2回ある。 9月17日（火）〜9月20日（金）の4日間の休暇を取得すると10連休になる。夏休みが取れなかった人もいると思う。残暑はまだ厳しいと思うが、貴重なことなので長期のお休みを計画してみるのもよい。

さて、今回のテーマだが、「セキュリティ・バイ・デザイン」についてお話をしたい。セキュリティ・バイ・デザインとは、「製品の企画や設計のフェーズからセキュリティ対策を組み込むことで、サイバーセキュリティを確保しておく考え⽅」であり、それは「脆弱性に対して上流⼯程で先⼿を打つこと」でもある※。まったく初めて聞くという方は少ないと思うが、前職（NHK）の時、放送設備へのセキュリティ対策について、設備導入前に何ができるかを考えた。この考え方を整理したのでご紹介したい。参考になれば嬉しい。
※IPA（独立行政法人情報処理推進機構）「 セキュリティ・バイ・デザイン導入指南書 」より

2. セキュリティ・バイ・デザインを取り入れる理由

セキュリティ・バイ・デザインは、情報システムが抱えるシステムリスクを効率的に対処するために取り入れたい考え方だ。前職（NHK）の情シス業務でシステム開発を行っていた時、情報セキュリティ確保といえば、コーディング後の各種テストやセキュリティ診断の実施、そして運用面での対策検討を指していた。

システム上に致命的な欠陥が発見された場合、設計フェーズに巻き戻してやり直す必要が出ることもあった。ネットワーク機器のファームウェアの問題やOSのパッチ対応が見つかった場合は、カットオーバーの日程変更にまで発展することがある。これは単なるタイミングの問題ではなく、開発の段階からセキュリティ対応について考えてこなかった結果なのである。

このような状況になると、納期やコストを考慮し、手戻りを実施するか、不十分な品質や残留するリスクを承知の上でシステムをリリースするかの選択を迫られる。物理的な機器などの交換で済めばいいが、特にアプリケーションの見直しが発生する場合、業務上の影響を考慮しなければならない。

セキュリティ・バイ・デザインの発想は、このようなシステム開発の後戻りを起こさないようにするための必要な考え方になる。

3. セキュリティ・バイ・デザインが必要とされている背景

また、保守性の高いセキュリティ対策を実装するためにも、開発初期から検討する必要がある。たとえば、システムのアクセス権限を管理する、セキュリティ機能の実装についても、管理できる項目や範囲などを追加できるようにしておけば、機能を追加しやすくなる。このような保守性の高いセキュリティ機能を実装するためにも開発初期から対応しておかなければならず、セキュリティ・バイ・デザインの考え方を採用することは、セキュリティ性能や保守性、利便性を高めるために必要なことがわかる。

4. セキュリティ・バイ・デザインの発想を取り入れた整備

前職（NHK）の情シスとして行った内容について話をしたい。放送設備は専用の機材を使っているものもあれば、汎用PCを使ったシステムも数多く存在している。ネットワーク構成の中には汎用の機材（スイッチングハブ）が多く使われている。汎用PCには一般的なOSが組み込まれているため、脆弱性が見つかった場合OSのアップデートは必須になる。その都度、緊急の深夜作業を行っていたが、どのシステムも同様だが直ぐにパッチを当てればよいわけではない。どんな変更が発生してもシステム上の動作テストは必須で、24時間動くシステムの保守の大変なところだ。

① システム内での脅威を特定し、セキュリティ要件定義を決める

システムに対するセキュリティの脅威を分析し、脅威を特定する。ここは想定外のことも含めてリスクの洗い出しを行う。システムに対する脅威が何かを明らかにし、セキュリティ要件を定義する。情報の機密性・完全性・可用性を守るための要件を洗い出し、システムを安全に運用するための目標を決めセキュリティ要件定義書を作る。

② 脆弱性の特定と対策について具体的検討

脆弱性の特定とそれに対する適切な対策を検討していく。システムのセキュリティ要件を明確に定義し、「認証、認可、暗号化、アクセス制御」などや、ファイアウォール、IDS/IPS、WAFなどについて必要の有無も含めて検討する。

ガイドラインの構成は大きく２つに分かれている。我々がシステムを購入してからのフェーズは運用／保守のフェーズが中心になるが、セキュリティ・バイ・デザインの考えを取り入れて開発／整備のフェーズを含めているところが特徴になる。

►開発／整備のフェーズ

「開発ポリシー」「開発環境」「システム設計」「納品・現地調査」を事前に開発業者と検討し、システムの機密性／可用性／完全性に応じたセキュリティ対策を検討したものを開発／実装することを目的とする。

►運用／保守のフェーズ

システムの機密性／可用性／完全性に応じたセキュリティ対策を実施し、インターネット接続や外部記憶媒体を利用して保守を行う場合は、それに応じたセキュリティ対策を実施する。情シスの運用においては、セキュリティインシデントの監視と対応計画が重要になり、セキュリティ・バイ・デザインは、これらの側面を設計段階で考慮する。

開発／整備のフェーズでは、依頼主が作成する仕様書の中身も問題になる。当然経理上の問題もあり、開発側の理解も必要になる。重要なことは、セキュリティを最初から考慮することで、システム開発担当者だけでなく、情シス全体の問題として捉え、連携していくことが重要になるということである。

5. セキュリティ・バイ・デザインの潮流

IoT、クラウドサービスなどのデジタル技術の利活用が急速に発展し、各デジタル技術に対応するセキュリティ確保が求められるのと、アジャイル開発のようなシステムの早期リリースに応えるための効率性が求められる。このために業務効率化を図り、実用性の高いシステムを導入しなければならず、注目を集めているのが「DevSecOps（デブセックオプス）」だ。

情報システムにおいて、開発（Development）と運用（Operations）を連携させ開発期間を短縮し、リリース頻度を高める。その中で、Secが指すセキュリティ(Security)を融合させ、スピーディーかつ安全性の高い開発を目指すのがDevSecOpsを意味する。まさにシステムの各工程でセキュリティ対策を実施し、安全な状態で開発を進めるための手法になる。この手法は、セキュリティ対策を開発のライフサイクルに組み込むというところでは、セキュリティ・バイ・デザインの考え方になっている。アジャイル開発で抱える課題の1つと言える。

6. まとめ

セキュリティ・バイ・デザインの重要性とメリットを説明してきたが、設計においてどこまで何をすれば「セキュア」といえるのか、明確な基準はない。更に、システムごとに「セキュア」といえるかどうかの検討に時間をかけ過ぎたり、セキュアであることを重視し過ぎたりしてしまい、極端な場合には実現不可能な仕様を要求してしまってはいけない。

解決策としては、どこまでのセキュリティ仕様を盛り込むのか、また、検証をどのように行うのか、関係者で合意のうえ、事前に文書化し、共有しておくことが必要である。個人的に一番期待したいことは、チーム内でセキュリティへの意識が高まり、その結果、信頼性の高いシステムを開発できるようなることだ。

また、セキュリティインシデント対応では、被害を受けた後処理は行うものの、攻撃を受ける前の備えについては、全ての関係者で知恵を出し合うことが大切と思っている。ある程度の攻撃を受けてしまうことを許容することと、大きな事故にならないような仕組みと、社外への被害を最小限にすることを目標にして、経営者は、情シスの対応を理解すると同時に、セキュリティ対策への投資を行ってほしい。