セキュリティ・バイ・デザイン　～名前は新しいけど着想は製造業？～

2018/4/23 セキュリティ

こんにちは。はなくとです。
 
最近、「セキュリティ・バイ・デザイン」というちょっとカッコいい言葉を目にしたので、興味が湧いて調べてみました。

１．セキュリティ・バイ・デザインとは？

セキュリティ・バイ・デザインとは、内閣サイバーセキュリティセンター（NISC）が提唱しているシステム開発の考え方で、
情報セキュリティを企画・設計段階から確保するための方策
出典：情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
　　 （NISC）
のようです。
 
この文言を読んで、新人の頃に読んだトヨタ関連の書籍の中に、「品質は設計で作りこむ」と書いてあったことを思い出しました。この考えに習って言えば、セキュリティ・バイ・デザインとは「セキュリティを企画～設計で作りこむ」ということです。
着想自体は製造業では当然のことなのかもしれません。
 
■閑話休題
少し話がそれますが、このように自動車業界（モノづくり業界？）の考え方がIT業界にも応用できたりするので、IT業界以外の本や他分野で活躍している知り合いがいると、そこから新しい発想を得ることができます。
ルネサンス時代に多くの発明がなされたのは、個人が優れていた点だけでなく、各専門分野の最高峰の人達を一堂に集めていたことがあげられます。彼/彼女らが自由に議論し、異分野の知恵や知見を自分の専門分野に取り入れていたからこそ、多くのアイデアが出たのです。
もう少し詳しく知りたい方は下記の書籍を読むとよいかもしれません。個人のアイデア発想論ではなく、組織論として読んでみるのも面白いと思います。
 
 
また、先ほど少し触れた新人の頃に読了したトヨタ関連の書籍で良かったものを紹介します。
ほんの少し年がばれそうです。そうです。おっさんです。
 
 

２．セキュリティ・バイ・デザインのメリット

それでは、次に企画・設計段階から情報セキュリティを確保するとどのようなメリットがあるのか考えたいと思います。
はなくとは下記２つがメリットと考えてます。
 
①情報システムにおけるセキュリティの確保
②TCOの削減
 
①については、企画・設計段階でその情報システムが持つ、脅威や脆弱性を洗い出しておくことによって、より最適なセキュリティ対策を導入することが可能になる、ということです。
運用中のシステムにセキュリティ対策を導入する場合、「ネットワーク構成の変更はダメ」といった制約事項が必ずあり、効果の高いセキュリティ対策の導入が見送られる場合もあります（費用というどうしようもない制約もありますが）。
 
しかし、企画・設計段階でセキュリティの確保を前提にシステム構成や方式を検討すると、制約事項が少なくて済むので、セキュリティ対策の選択の幅が広がります。
結果としてより効果の高いセキュリティ対策を導入できる可能性が高まります。
 
②については、運用中のシステムにセキュリティ対策を導入する場合、テスト工数や関係各所との調整にコスト(時間)がかかる、ということです。
ネットワーク構成の変更やサーバ/エンドポイントへのセキュリティソフトの導入を伴うことがあります。この場合、導入後に毎回テスト（影響のある範囲全部！）を実施し既存業務に影響が無いことを確認する必要があります。
 
加えて、影響のある部署（主にインフラ部門、場合によっては業務部門も含む）との調整が必要になり、情報システム部門の負担が増大します。
セキュリティ・バイ・デザインによるシステム開発ではこのような負担が減り、TCOの削減につながると考えてます。　　　　

３．セキュリティ・バイ・デザインの進め方（企画・要件定義）

前述したとおり、適切に導入できれば大きなメリットのあるセキュリティ・バイ・デザインですが、どのようなプロセスで進めていけばよいのでしょうか？
企画・要件定義の進め方について書いていきたいと思います。
 
まず、企画・要件定義では、最終的なアウトプットである要件定義書にセキュリティ要件が漏れなく記載されていることがゴールとなります。
 

ここで、「１．セキュリティ・バイ・デザインとは？」で引用した下記の資料は政府が業者に提示する調達仕様書にセキュリティ要件を盛り込む手順を記載したマニュアルです。

中身を読んだところ、割と汎用的に書かれており、政府・民間を問わず利用できるのではないかと考えました。そこで、ここでは本資料の内容を紹介したいと思います。

情報システムに係る政府調達におけるセキュリティ要件策定マニュアル（NISC）
 
流れとしては、①業務要件を検討し、どのような情報を扱うのか？保護すべき資産とそのレベル等を定義します。
次に業務要件に基づいて、②セキュリティ要件を策定するという流れです。
少し細分化した内容を以下に記載します。
 
①業務要件の検討
　セキュリティ要件の策定の前に、まずどのような業務を想定しているか整理します。
 
　■ステップ 1　目的及び業務の洗い出し
　■ステップ 2　業務の特徴の整理
　　　            　それぞれの業務に対して、業務に関与する主体・取り扱う情報・利用環境を
　　　　　　　　整理する。
   ■ステップ 3　システム概要図の作成
　　　　　 　  　ステップ2で収集した情報を図示化する。
   ■ステップ 4   定型設問による業務要件の詳細化
      　               システムの利用人数や利用時間帯、情報漏えい時の影響度合、
　　　　　　　　RTO（Recovery Time Objective※）等
 
　　　　　　　　※RTOとは、システム停止から復旧するまでの目標とする時間。
 
②セキュリティ要件の策定
　①で検討した業務要件の内容をベースにセキュリティ要件を策定します。
 
　■ステップ 5　判断条件による対策方針の検討
　 　　　　　　  セキュリティ対策を対策区分、対策方針、対策要件に分け、優先的に実施す
          　           べきセキュリティ対策とその実施レベルを決める。
   ■ステップ 6　対策要件の決定
　 　　　　　　  実施レベルとコストを勘案して記載内容を決める。
　■ステップ 7　調達仕様書への反映
　 　　　　　　  記載内容の具体化。妥当性の点検等
 
以上が企画・要件定義工程におけるセキュリティ・バイ・デザインの実現方法となります。設計については別の機会に書いていきたいと思います。
 

４．セキュリティ・バイ・デザインに限界はあるか？

ここでは、セキュリティ・バイ・デザインに限界は無いのか？思うところを書いていきます。
まず、セキュリティ・バイ・デザインは完全無欠ではないと思っています。
 
理由は、大きく２つです。
 
①新たな脆弱性や脅威（攻撃手法）が絶えず発生する
　セキュリティ・バイ・デザインを導入したとしても、新たな脆弱性や脅威に対してはこれま
　でと同様、後追いでセキュリティ対策を検討する必要があります。
　これはやむを得ないと思います。
 
②セキュリティ・バイ・デザインの導入の難しさ
　これは、セキュリティ・バイ・デザインを誰でも簡単に適切に導入できるか？ということで
　す。セキュリティ・バイ・デザインを適切に導入するための前提条件として、セキュリティ
　人材の確保や上層部の理解が必須と考えてます。
 
　しかし、旗振り役となるセキュリティ人材が不足していることはご存知のとおりです。
　また、セキュリティ・バイ・デザインでは、企画～設計でセキュリティ設計するための工数
　が増え、開発コストが増えているように見えてしまいます（後追いでセキュリティ対策する
　よりはるかにマシですが）。
 
　そのため、上層部のセキュリティに対する理解がないと、「コストが増える」ところだけを
　見られてしまい、セキュリティ・バイ・デザインによる開発許可が得られない可能性があり
　ます。
 
　このような場合は、セキュリティ・バイ・デザインの有効性・有用性を数字を使って説明し
　ましょう。
 

５．まとめ

　　セキュリティ・バイ・デザインは、
　　　・セキュリティを企画～設計で作りこむ考え方。
　　　・設計以降に発生した新たな脆弱性や脅威（攻撃手法）には無力。
　　　・導入にはセキュリティ人材と上層部の理解が必要
　　です。
 
 
おしまい
error: Content is protected !!