技術

VSE+SS 合同研究会成果レポート
情報サービス産業協会 VSE（基本開発プロセス）研究会 / VSE+SS 合同研究会

ここに報告する研究会成果レポートは 2016 年 1 月に作成したもので、本文に続き、2 つの解説と 1
つのプロセス定義文書で構成されています。

安全・安心なソフトウェアのための基本プロセスガイド
VSE+SS 合同研究会一同1

2

このレポートの目的

VSE プロセスとセキュリティ／セーフティプロセス

ソフトウェア／システム開発に関して、比較的

実は、セーフティにかかわるプロセスの標準に小規模な開発組織の開発プロセスの標準が、国は、国際規格として ISO/IEC 15504-103 が数年前

際 規 格（VSE 規 格、ISO/IEC 291101 シ リ ー ズ ）から提供されています。また、国際的な討議や検として定められています。その規格の基本は、ク

討において、セーフティとセキュリティは、それリティカルでないソフトウェアの開発を想定してらに取り組むプロセスの面で見るとあまり違わないます。一方、現代社会では、どのような開発でいといわれてきています。

もセキュリティが課題となり、また特に組込み系

それらの動向を踏まえて、また合同研究会内で開発では安全性（セーフティ）が幅広く課題と提 案 さ れ た 二、 三 の 案 を 踏 ま え て、ISO/IEC

2

なっています。VSE+SS 合同研究会 では、その15504-10 の内容をセキュリティが含まれるものにような課題に対応するために、VSE 規格の拡張

拡張するのが妥当だろうという結論となりましとして、セキュリティの要素とセーフティの要素た。この ISO/IEC 15504-10 は、一般的なプロセを付加した開発の手引きを産業界に提案すること

ス標準があることを前提として、それにセーフとしました。

ティについてのプロセスを追加するものです。そ本レポートでは、VSE+SS 合同研究会の討議経こにさらにセキュリティの要素を付加しようとし過を簡潔に述べ、その中で開発されたプロセスガている。また、小規模開発組織（VSE）向けに、

イドと、そのプロセスガイドと一体となって提示

プロセス定義を少しコンパクトにすることを行いされるべき「実施指針」（「セーフティの基礎」／

ます。

「システム開発の情報セキュリティの基礎」）の意

ところで、一般的なプロセスの標準化は、これ義を解説します。そして、それら「ガイド」／「実も 国 際 規 格 で は 略 称 で SLCP4 と 言 わ れ る も の施指針」の活用により、小規模なソフトウェア／（ 詳 し く は、ISO/IEC 12207 と ISO/IEC 15288）

システム開発組織での成果物のセキュリティ／があります。これらにセーフティを加えるのが、セーフティ品質の向上を図ることを提案します。

元となった ISO/IEC 15504-10 規格の立場です。

1

ISO/IEC 29110-2（JIS X 0165-2：2013) 等。なお、本研究会のレポートは、特定領域への VSE 規格の拡張適用方法を定めた ISO/IEC
29110-2-2：2016（発行準備中）を参考にしたものです。
2 VSE+SS 合同研究会は、（一社）情報サービス産業協会 VSE 普及部会、（一社）組込みシステム技術協会安全性向上委員会の各有志メンバー、
一般産業界の組込み系開発に関わる有志メンバー、そして本文に述べた課題に興味のあるその他の有志メンバーで構成された合同の研究会です。2014 年ころから 2015 年まで活動を行いました。
3 ISO/IEC 15504-10：2011  Process assessment ― Part 10：Safety extension
4 ISO/IEC 12207：2008 Software life cycle processes（JIS X 0160：2012 ソフトウェアライフサイクルプロセス）、ISO/IEC/IEEE
15288：2015 System life cycle processes（JIS X 0170：2013 システムライフサイクルプロセス）79

VSE（基本プロファイル）

拡張（SS）プロセス

プロセス
プロジェクト管理

セキュリティ＋セーフティ
プロセス

ソフトウェア実装■ガイドラインとしての利用■アセスメントのプロセス参照モデルとしての利用■その他、発注条件や認証としての利用

図1

VSE+SS のプロセスガイド（セキュリティ＋セーフティを SS と略す）

しかし、VSE ＋ SS 合同研究会は、小規模開発組

います。VSE のプロセスは基本開発プロセスで織向けでコンパクトな基本開発プロセス標準であありソフトウェア／システムのライフサイクルのる VSE 規格を出発点としています。そのため、流れに対応しています。SS のプロセスはそれとここに提示する VSE+SS プロセスガイドでは、並行して実施されるものです。必要なら SS プロ「VSE 規格のプロセス」＋「セーフティとセキュセスで述べられていることを VSE のプロセスのリティのプロセス」を小規模開発組織に必要なプ

中に組み込んで利用してもよいでしょう。

ロセスとしています。一般的にクリティカルな要

合同研究会の成果物の利用法としては、アセス

素がない開発ではセーフティとセキュリティの部

メントの実施による第三者的な評価を実施するま分は不要かもしれませんが、現在の多くの開発ででもない場合は、開発組織が自身のプロセスを明は（それも日本での産業・ビジネス目的・公共目

確にする場合のガイドラインとして利用すること的の開発では）セーフティとセキュリティの要素が で き ま す。 さ ら に、IT シ ス テ ム の 発 注 者 がが重要になると考えています。

VSE 組織に対して発注条件を設定する場合の手

図 1 に示すように、基本プロセスやセキュリ

引きとして利用することも有効でしょう。もっと

ティ／セーフティプロセスはプロセスアセスメン

進んで、アセスメントの結果をプロセスの認証のトにおけるプロセス参照モデルとして利用するこ形式で確実にするケースも想定できます。

と が で き ま す。 こ の た め の 利 用 法 の 詳 細 は、ISO/IEC 15504 のプロセスアセスメント（俗称SPICE アセスメント）として知られています。
またそのアセスメントサービスを提供するビジネ

3

セキュリティ／セーフティの「実施指針」スも存在しますので、それらの情報／サービスをご利用いただければと思います。
詳しく言えば、プロセスアセスメントのためには、プロセス参照モデル（PRM という）に加え

VSE+SS 合同研究会では、多くの活動をセキュ
リティとセーフティに関する各「実施指針」の作
成にあてました。その理由を説明します。

て、 よ り 詳 細 な プ ロ セ ス ア セ ス メ ン ト モ デ ル

一般にソフトウェア／システム開発のプロセス（PAM という）を開発して適用する必要がありのモデル適用やアセスメントの実施では、現場のま す。 し か し、 こ の 合 同 研 究 会 の 成 果 と し て

人々においてプロセスモデル定式化の背景的なこ

PAM は提供していません。

とやプロセス実施で実務的にはどのような事柄に

VSE のプロセスと SS プロセス（セキュリティ

注意すべきかがあまり理解されずに、形式的な面＋セーフティプロセスの略記）は少し雰囲気が違のみが前面に出てしまうと反省されることがよく

80
JISA Quarterly No.121 2016 Spring

VSE ＋ SS プロセスモデル
VSE プロセス

SS プロセスセキュリティ理解（「実施指針」）
セーフティ理解（「実施指針」）■深い理解に基づくプロセスの確立・実施

図2

実施指針の活用あります。セキュリティとセーフティについては、特にこのような幅広い理解の重視や、その理解促進のための現場マインドの醸成が重要です。

4

他の規格や基準との関係

そのような事情から、VSE+SS 合同研究会では、そもそもなぜセキュリティとセーフティに取プロセスの基準には、VSE 規格の他に上でもり組むのか、どのようなスタンスとマインドで取5触れた SLCP や日本国内での「共通フレーム」、

り組むべきなのかを示す「実施指針」を前提条件

IPA 作成の ESPR6 などもあります。VSE+SS 合として開発することとしました。この「実施指同研究会で開発した考え方の枠組みは、プロセス針」に類似する内容の概説書は世間に多くありまモデルとして VSE プロセスモデルでなくこれらすが、今回の「実施指針」は、ソフトウェア／シのプロセスモデルを利用することを妨げるものでステムの開発プロセス実施に際して、そのためのはありません。しかし、多くの小規模開発組織に前提的な理解を求めて簡潔な基本知識をまとめ、とっては、VSE プロセスモデルの適用が便利で2 章に述べたような VSE+SS プロセス実施を確しょう。

実にするための資料としたことに意義があります。

セーフティに関しては、たとえば自動車分野でこの「実施指針」の具体的な利用法としては、の ISO 26262 規格のように、多少厳しい基準適用

VSE に当たる開発組織が自身のプロセスを強固

スキームを持っているケースもあります。そのよなものにするための共通基礎理解として活用した

うな場合に発注元が示すセーフティ関連要求事項

り、ソフトウェア／システムの発注側が受注・開は厳密に満たさなければいけませんが、それらを発側に対して必要な基礎知識・スキルとして内容実施する際の背景やセーフティマインドの醸成に理解を求める材料として活用したりすることなど

は VSE+SS 合同研究会の成果物が役に立つと思が想定されます。（図 2 を参照。）

います。
セキュリティに関しては、セキュリティの「実施指針」にも述べられているように、2 つの観点（テーマ）を区別する必要があります。VSE 組織
にとってのセキュリティに関するテーマは、（1）
組織が企業活動上で管理する情報資産に関わるセ

5 （独）情報処理推進機構編・発行「共通フレーム 2013」、2013 年、（https://www.ipa.go.jp/sec/publish/tn12-006.html を参照）

6 （独）情報処理推進機構編【改訂版】組込みソフトウェア向け開発プロセスガイド」、翔泳社刊、2007 年（http://www.ipa.go.jp/sec/publish/

tn07-005.html を参照）

81

キュリテイ（ISMS 規格等が典型的に扱う）のやすいものですから、それぞれの開発現場で、そテーマと、（2）組織が開発・提供する製品が実現

れぞれのニーズに合わせて必要なカスタマイズをすべきセキュリティ品質のテーマとの、2 つのし、本来の必要な業務高度化の成果に結び付けてテーマとがあるということです。VSE+SS 合同

いただくのがよいと思います。このテーマは（実研究会の成果物は基本的には（2）の観点に沿っは）国際的にも先進的な取組みですから、皆さんたものです。これにあたる国際規格としてはコモの組織が競争力をつけ、マーケットで通用する確7

実な実力を身に着け、ビジネス上の信用力を向上

ンクライテリア というものもあります。

させることに役立てていただければと思います。
その他の具体的な使い方の例としては、JISA

5

8
から出版された「VSE 標準導入の手引き」に記

成果物活用をどう使うのか載されている「VSE 標準活用事例」が参考になるでしょう。

VSE+SS 合同研究会の成果物は、軽量な扱い■ VSE+SS 合同研究会メンバー
伏見 諭
足立久美
倉持俊之
塩谷和範
菅原博之
田渕一成
那須 誠
錦見美貴子
堀 武司
三輪一義
オブザーバ 山下博之
事務局
尾股達也
事務局
佐藤厚夫

座長

東海大学
TIS 株式会社
ソニー株式会社
ビジネスキューブ・アンド・パートナーズ株式会社
一般社団法人組込みシステム技術協会

国立研究開発法人

産業技術総合研究所

地方独立行政法人

北海道立総合研究機構

一般社団法人組込みシステム技術協会

独立行政法人情報処理推進機構
一般社団法人情報サービス産業協会

一般社団法人情報サービス産業協会

7

ISO/IEC 15408:2009（Security techniques-Evaluation criteria for IT security; Common Criteria とも略称）（JIS X 5070：2011
セキュリティ技術－情報技術セキュリティの評価基準）（http://www.ipa.go.jp/security/jisec/cc/ をも参照）
8 （一社）情報サービス産業協会編「VSE 標準導入の手引き」㈱アイエージー刊、2014 年

82
JISA Quarterly No.121 2016 Spring［解説］システム開発の情報セキュリティの基礎～小規模開発組織のセキュアな開発にむけて～
伏見 諭、那須 誠、三輪 一義

VSE+SS 合同研究会一同要旨IT やネットワークの発展に並行して、そのセキュリティ面の課題が指摘され、また実際のセキュリ
ティ上の攻撃が日常的に行われるようになって久しい。
しかし、ソフトウェアを組み込んだシステムを開発する際に、そのようなセキュリティへの対応を高い
信頼性で実施するにはどうすればよいかは、あまり明確になっているとは言えない。本稿は、特にソフトウェア開発を行う小規模組織のマネージャ層やエンジニアが、実際の業務においてどのようにセキュリ
ティの課題に対応すべきかの基礎的知見を提供することを目的とする。いわゆる組込み系システムに焦点をあてている。
ものだが、本稿では、後者の視点を中心に基本的

1

システム開発の情報セキュリティとはな着眼点と開発活動の指針を提供する。
製品等のセキュリティを問題とする上でも、技術面の課題と管理面の課題がある。これについて
は 4 章以下で説明する。

1.1
1.1

情報セキュリティの 2 つの課題

いま（特に組込み系等の）ソフトウェアを中心

1.2
1.2

セキュリティ確保の責任の所在とするシステム開発で、セキュリティを問題にする場合に、開発組織の（持つ、または取扱う）機

システムの開発においては、開発チームの他

密情報の漏えい防止などを主な着眼点とした取組に、発注者や社内の他部署が関係者（ステークホ

みと、開発対象であるシステムをセキュリティ的ルダ）となることが多い。開発されたシステムのに強固なものとしなければならないという取組み

セキュリティが確実となるためには、正しい運用の 2 つの課題がある（表 1）。両者ともに重要な設定が必要だが、システム／サービスの運用者・組織の情報資産を守るセキュリティ

製品・システムのセキュリティ

表1

情報漏えいなどから組織活動を守る。
情報の保全とサービス継続の活動。
機 密 性、 イ ン テ グ リ テ ィ（ 後 述：2 章 参 照 ） な ど 製品・システムとサービスの利用者が、利用時のシステムのセキュリティ設定等に関与することも多い。
それらの多くの関係の中で、どのようにシステ
ム全体としてのセキュリティを確保していくか、
適切に責任分担がなされ、対策がとられる必要がある。このことはシステムにセキュリティホールを作らないという意味で非常に重要である。シス

全体的なセキュリティ上の能力を確保する。

テム開発の 2 者間取引では、そうした責任分担が開発における情報セキュリティの 2 つの課題要となる。その際、発注者がセキュリティ課題を

契約的文書の中に明確に記載されていることも重83

分析（・設計）し、受注者がそれを実装するケースや、逆に受注側のソフトウェア開発者が専門家

2.1
2.1

セキュリティリスクとはとしての知識・スキルとノウハウに基づき、セキュリティを自己の責任で確保するケースなど、

セキュリティ対策は、ある種のリスクマネジメ

さまざまである。受発注者の間で責任分担を明確ントとしてとらえられる。ここでのリスクは攻撃にし、かつ円滑なコミュニケーションを保つことを仕掛けてくる脅威源、攻撃を許してしまう防御がセキュリティ確保の基礎となる。

の脆弱性、攻撃の結果がどのように製品（また、本稿は、開発に携わる様々な立場の方が、情報それを含むシステム）に関わる情報資産、およ

セキュリティについて共通に理解すべき課題と、び、製品の利用者や関係者の情報資産にどう影響

それぞれの立場で責任を持つべき課題と対応方法

するかの 3 要素に分解してとらえられる（図 1）。

等について、以下に詳述する。2 章では製品開発

この「脅威」、「脆弱性」、「影響」の分析が、リスの情報セキュリティの概要を説明し、3 章ではセク分析の 3 要素である。

キュリティ対策の実際の展開の仕方について技術面を中心に説明し、4 章では管理的な側面での課題を説明する。5 章では、基本的な当時者である発注側と開発ベンダ側との役割分担について説明し、6 章では過去事例からの教訓について紹介する。

脅威（攻撃者の能力）図1

情報資産への影響

防御（脆弱性がある）（攻撃対象）

攻撃、防御（脆弱性）と影響

脅威・脆弱性・影響というリスクの 3 要素とともに、機密性・インテグリティ・可用性・真正性

2

情報セキュリティの基本（認証性）というセキュリティが守るものの種別を組み合わせて、セキュリティの具体的な課題を詳細にとらえていくことができる。セキュリティ

情報セキュリティは、現代社会の抱える出口のない大きな問題とも言えるが、多くのセキュリ

課題がとらえられると、それに基づいて、セキュリティ対応策を考えていくこととなる。

ティのニュースに接して、漠然と「セキュリティ

これらの、機密性、インテグリティ、可用性、の脅威に対抗しなければいけない」と言っていて真正性（認証性）のそれぞれの意味を表 2 に示す1。

も場当たり的になるだけである。そのような対応
では、対処すべき課題は膨大となり思考が拡散し、結果的には「大変だからまともには取り組め

セキュリティ
の守るもの

ない、そこそこで我慢しよう」ということにな

機密性

秘密にすべき情報／サービスが秘密に保たれていること。

インテグリ
ティ

利用対象の情報／サービスの情報内容が正しく保たれ提供されていること。

可用性

必要な時に妨害されずに情報／サービスを利用できること。

真正性
（認証性）

不正な人やサイト、プログラム
な ど で は な く、 正 当 な 主 体る。その結果生み出されてしまったセキュリティの弱点を突かれることになりかねない。
開発対象システム／製品における情報セキュリ
ティ上の課題を整理し、危険性を理解した上で、自分自身を含む開発者・関係者の知識リソース、
スキルリソースを整理して活用しかつ、開発者及び関係者の円滑なコミュニケーションを図りながら開発することが重要である。

表21

これらの用語の詳細について、たとえば参考資料 1）、2）などを参照。

84
JISA Quarterly No.121 2016 Spring説

明（人、もの、プロセス）である
ことを保証できること。

セキュリティの目的

セキュリティで守るものとしては、これらに加2ことは不可能に近い。そのため連続した防御壁にえてプライバシーの課題、否認防止 の課題、ア

よるリスク管理手法である「多層防御」が有効でカウンタビリティ（責任追跡性）の課題などを加ある。下の図 2 はいわゆるスイスチーズモデルとえることがあり、製品面のセキュリティの達成の呼ばれる多層防御のイメージを表すものである

ためにそれらを意識すべき場合がある。

が、複数の防御方策を設け、一つの防御が突破さ一般的なリスク対応には、⒜リスクを「緩和」

れても、次の防御層で阻止するという考え方であする方策のほかに、⒝リスクの関係するおおもとる。仮に、一旦不正な攻撃による内部侵入を許しの施策そのものをやめてしまう「回避」、⒞リスたとしても、システムの暴走を起こす攻撃は許さ

クの負担を第三者に肩代わりしてもらう方策をとず、場合により代替システムに切り替える、またる「転嫁」、また⒟緩和が一定程度進んだがある

外部への不正な情報流出は許さないといったよう程度のリスクが残り、その残存リスクをやむを得な第二、第三の防御策を考えておくことが重要でないとしてしまう「受容」、という方策もあるが、ある。

通常は「緩和」する方策が探られる。
2.3
2.2
2.2

リスクアセスメント

セキュリティリスクの重大特徴と防御
セキュリティリスクに対応するためには、情報

情報セキュリティにおけるリスクには、悪意を資産、脅威と脆弱性、攻撃を受ける場所・時間な持った攻撃者が不断にシステムの欠陥と防御の穴

どの対策すべき要素を、重要な情報資産とシステを探し出し攻撃を加えるという特異性がある。攻ムの特性の把握や過去の事故事例などに基づいて撃はアットランダムに行われるのではなく、攻撃

適切にリスク評価し、対策方法を決める必要があ者のスキルと知識がだんだんに蓄積され高度化する。

るという特異性もある。そのため、いったん攻撃

開発システムの中には、システム脆弱性があっ方法が確立され、かつ、執拗に狙われると、そのても、攻撃者の攻撃意図がまったく無いという想攻撃はほぼ確実に成功するものとみなさなければ

定が正しい場合もあり、セキュリティがほとんどならなくなる。逆に言えば、それまでの防御策は問題にならないケースもある（リスクを「受容」

無 効 化 す る。 例 と し て、 一 時 無 線 LAN で はする場合など）。どのようなプロジェクトの条件

WEP という方式が広くおこなわれたが、WEPでも同様に厳重なセキュリティ対応が必要なわけの脆弱性が発見されその脆弱性をつくツールが流ではない。

布するようになると、WEP 方式自体が無効なものとみなさなければならなくなった。

実際のセキュリティ対策については、次章以降で述べる。

このような攻撃を単一の防御策で完全に封ずる
2.4
2.4

さまざまなケースでのリスクの特色と対策

製品やシステムのセキュリティ対策と一口に言ってもそれらがどのような場でどのような使われ方をするのか、また守るべき情報資産が何なのかによりとるべき対策は多種多様である。以下に
図2
2多層防御のイメージ

実例を述べる。

情報主体が実際には行った行為を行っていないように主張することを否認と言い、インターネット上で行われるコミュニケーションを確実にす
るには否認の防止が必要となる。

85

1）ルータ等のネットワーク機器の場合

ように多様なリスクに幅広く対処しなければならないという特徴もある。

小規模事業所や家庭などで設置されるネット
ワークを構成する機器は組込みソフトウェアシス
テムであることが多く、これに対するセキュリ

3）業務システムの場合

ティ対策は企業情報システムのセキュリティ対策

組込みシステムではないが、企業内で使われると違い、出荷後修正が難しい大量生産機器であ

情報システム、ネット通販のシステム、官公庁／

り、かつ利用者が専門家でないことが多いことか

団体／一般企業などを紹介するホームページなど

らセキュリティ対策をより綿密に行うことが必要の場で使われる製品を考えた場合、それぞれに、である。これらネットワーク機器は、その機能仕守るべき多くの情報資産の多様な特色やセキュリ様として、ネットワーク機能とセキュリティ機能

ティの要請程度があり、それを明確にし、その結をもっていることが多い。そうした機能自体が果に照らしたセキュリティ対策が必須となるとい

しっかりしている必要がある。また、機器のパラう課題がある。

メータ設定用画面機能など支援的機能や、バイパスを許さない、物理的攻撃で情報を盗まれないといった統合システムとしてのセキュリティもよく検討し対策しなければならない。

2）スマホアプリや情報家電等の場合
情報家電、スマートフォンや NAVI システム3

セキュリティ対応の実際

3.1
3.1

セキュリティ機能の要件定義と実装のプロセスに代表される、ネットワークに接続して日常生活システムを開発する際には、開発している製品

で使う情報機器に組み込むシステムのセキュリの機密性、インテグリティ、可用性、真正性に関ティ対策もある。デジタルテレビなどデジタル

わる防御能力等がどの程度であるか、さらに具体化、双方向化が進んでおりており、ホームネット

的にどの程度の攻撃に耐えられるかが問題となワークにつながるデジタル家電がトレンドとなっる。これらの能力は、システムのセキュリティ機ているが、それらはオンラインでセキュリティ

能要件という形でまとめられることもあるが、セアップデートをかけられることが多い。セキュリ

キュア・プログラミングの技術のように、現場のティアップデートをどのように安全・有効に行う技術能力が製品のセキュリティ品質達成の大きなかもセキュリティ課題の一つとなる。図 3 は情報要因となるようなものもある。本節では、そのセ家電における脅威の例を示すものであるが、このキュリティ品質達成の具体的なやり方を説明する。

1）守るべき情報資産の特定
まず守るべき情報資産を特定する必要がある。
ここで、守るべき情報資産とは、製品・システムの使用者と使用状況とに関わる情報、技術的な機⒜ 偽の修正ソフトダウンロード⒝ 問題のあるネットワーク機器

図3

密性のある情報、さらに製品・システムが提供する情報サービスのことである。

⒞ スマホや無線機器からの不正アクセス⒟ 不正サイトへの安易な接続

利用者の行動様式が分かることをプライバシー上

情報家電の脅威と脆弱性の例の問題とする場合、その「利用者の行動様式デー

86
JISA Quarterly No.121 2016 Spring

例：テレビ、エアコン、車などの稼働状況から

タ」が対象となる守るべき情報資産である。

また、開発と運用の両方の要員の教育・訓練と、組織としてのセキュリティノウハウの向上を

2）リスクアセスメント
リスクの評価・見積りと対策を行う一連の工程図ることが重要になる。セキュリティ事件・事故が発生した時の、いざというときの費用と対処時間の見積もできる体制が必要になる。

をリスクアセスメントと呼ぶ。アセスメントのス

顧客の要求に基づいてシステム開発を行う場合

テップはセキュリティにおいても他の分野のリスには、特に、顧客にコストについての理解を求め

ク分析と同様である。すなわち；

ることが重要となる。

⑴

守るべき資産の洗い出し⑵

ハザード（脅威）や攻撃者能力の洗い出し⑶

システムの脆弱性の把握や評価

4）セキュリティの確実な開発ライフサイクルへの展開⑷

リスクの識別と分析

対策方法のセキュリティ機能要件を明確にする⑸ 上記で特定したリスクの程度の評価と対応策

こととともに、その目的とするセキュリティを実選択の方向性設定

現する技術としては、たとえば実装段階でセキュというステップとなる。

ア・コーディング等が必須となる。このような、

このアセスメントに抜けや欠点があった場合、セキュリティ対応の、具体的な開発プロセスへの

その後の工程で行う対策が不十分になるので、こ展開は、実務上で最も重要である。その方法としこでは特に十分に吟味して行わなければならなて、たとえば、VSE 規格（小規模組織向けプロい。

セス規格）を参考にし、その基本となる開発プロ

リスクアセスメントは時間・コストの許す限り

セスの中にセキュリティ対応事項を織り込むこと

徹底して行う必要があり、できる限り詳細リスクが考えられる。そのイメージ例については、図 4

分析（巻末資料 1 参照）を行うことが望ましい。

を参照。

評価の結果によりリスク緩和策が必要となった
場合、複数の緩和ソリューションを検討し、有効性とコストパフォーマンスの両面を考慮して選択する。この選択に当たっては、試行を行って効果を見定めるとか、セキュリティツールベンダの示
す効果表示値を検討するなどして慎重に行うとよい。
このようなリスクの程度の計算、ソリューショ
ン選択にあたっては、できるだけ厳密にという方
針で数値的に行う場合もあれば、概要を把握することが重要だという方針で定性的に評価すること

図4

 キュリティを考慮した開発プロセスのイ
セ
メージもあり、それぞれに各種の手法が開発されている（これも巻末参考資料 1 を参照）。

3）セキュリティ対策のコスト見積もり

5）運用時のインシデント対応のプロセス・態勢
セキュリティに関しては、多くの製品が出荷後に問題が見出されたり、新しい攻撃にさらされた

上述したように、実際にセキュリティ対策をとりすることが多い。システムの運用設定がまずいるためにはそのための費用（設備・ソフトウェア

ためにセキュリティの脆弱性が生じることもあライブラリ・技術・要員などを含む）と時間の手る。また、利用した汎用部品のセキュリティホー

当が必要である。

ルが発見されることもある。こうした事態に迅速87

にかつ柔軟に対処できるプロセス・態勢の構築

ティ品質が確保できる状態になっているかを実態や、利用者への指導、また、メンテナンス性の考に即して把握する。個々のプロジェクトの実施に

慮等の製品のアーキテクチャ上の工夫も必要であ

おいても、必要な場合は、セキュリティ品質上のる。

保証を行うためのプロジェクト管理ができるようにする。

6）参考となる情報の活用
上記のような対応を確実に行うためには、信頼できる基準やガイドを参考にするのがよい。それ

3）対象分野で規制等がある場合は対応する
たとえば医療機器分野では、薬事法（日本）やには、例えば、次のようなものがある。

FDA 規制（米国）等に基づく強制的規制や、多・IPA のセキュア・プログラミング講座等の情

くの業界基準が設けられている。これらの分野で

報は規制等への的確な対応を行う必要がある（資料h ttps://www.ipa.go.jp/security/awareness/

5 参考資料3）を参照）。

vendor/programmingv2/
・IPA の各種指針（たとえば ESCR など）
h ttp://www.ipa.go.jp/sec/reports/20150410.
html4）ライフサイクル全般を見据える組込みソフトウェアは組込まれるデジタル機器

・CERT-C、国際規格セキュア・ライブラリなどのセキュア・プログラミング指針
・OWASP、IPA などのセキュアな Web サイト
開発のための指針と一体なので、欠陥が発覚した場合、全品のリコール問題まで発展しかねない。組込みソフト
ウェアでなくても最近のソフトウェアは、システ
ム運用時のセキュリティ対応が重要である。もは・それらに対応する組織内／プロジェクト内のセや「ソフトウェアは作って終わり」という時代でキュア開発ルール／コーディングルールとそのはない。セキュリティ上では、製品やそれに付随

確実な実装をチェックする静的解析ツールの活するデータの廃棄や保全ということも重大な問題用となる。それ故、製品のライフサイクル（企画、開発、運用、保守、廃棄）全体を見据えたセキュ
リティの要件定義やライフサイクルを構成する各

3.2
3.2

セキュリティプロセスの留意点

1）攻撃方法が日進月歩進化していることへの対応

プロセスの品質向上が特に重要となる。

3.3
3.3

セキュリティとセーフティの関係

攻撃者の目的は、単なるイタズラから金銭目当ての詐欺に移り、その上に国家の安全を脅かすまで高度化してきている。
IPA や JPCERT/CC などの国内の Web サイト、
国際的な情報源などにアクセスして、情報セキュ
リティの対策についての情報を常に把握しておくことが重要となる。

特に組込み系のシステムでは、セキュリティとセーフティは深く関係している。セキュリティ攻撃の結果としてセーフティが危うくなるケースが多くある。
大きな事例としては、海外での製鉄所へのセ
キュリティ面でのマルウェア攻撃が、プラント設
備の運用を危うくし、一種のセーフティインシデ

2）組織管理・プロジェクト管理上の考慮
人材の教育や文書管理を含め必要なセキュリ
88
JISA Quarterly No.121 2016 Spring

ントを発生させている。また、逆にセーフティが崩れると特に可用性や情報保全などの面でセキュ
リティに影響する。

セキュリティ攻撃の中でも、インテグリティや対象分野での規制や、デファクトの基準等の知

可用性に関連する攻撃は、このようにセーフティ

識も欠かせない。その結果必要であれば、適切なと直接関連する可能性が大きいため、セキュリ対処を行う。

ティとセーフティの課題は一体のものとして分析したり対策したりする方がよいことが多々ある。

3）カルチャーとマインド形成
自社が情報セキュリティにどのように取組むか4

開発部門／開発企業での体制づくりと意識向上についての共通的なマインド形成と、それに対応した実践上のカルチャー作りを重視しなければならない。また、そうした取組みを外部に対してもホームページなどで公表し、「セキュリティ対応

4.1
4.1

取組みのアプローチが優れていることを自他ともに認められる」ようにすることはビジネスメリットがあるだろう。

セキュリティ対策には人的投資が前提となり、また企業の風土作りも重要になる。開発を外部委託する場合であっても自社同様の企業風土・対応

4）ガイドラインや標準との付き合い方があるかを点検せねばならず、いずれにしても相次節で紹介するように、国際／国内のセキュリ

応のコストがかかることを予め考慮しておかなけ

ティガイドラインや制度が多くある。それらの自ればならない。

組織にとっての有効性・必要性を見極め、ガイドや制度の文面に過度にとらわれるのではなく実際

企業内での実際の風土作りは次のことを考慮して進めることになる。

にどうあるべきか検討し、またノウハウを蓄積しながら、自組織の実力を高めていくようにするのがよい。

1）最適な体制の構築
セキュリティ対策では、セキュリティ対応姿勢

4.2
4.2

の明確化やリソースの確保といったトップダウン

開発組織（企業）運営上の対策と情報セキュリティ認証制度の足並みをそろえた組織的な対応と、現場の工当然ながら、開発にあたる組織運営そのものに夫・ノウハウの集積といったボトムアップの取組

情報セキュリティの対策がなければせっかくの開

みとの両輪により情報セキュリティの管理体制を

発物のノウハウや機密情報が外部に漏洩したり、構築することが重要となる。

外部から開発中のソフトウェア製品そのものが改ざんされるなどの攻撃をされたりするおそれがあ

2）人材育成とノウハウの蓄積・活用る。
情報セキュリティの第三者認証制度を利用した

セキュリティ対策は掛け声だけでは空回りした

り、参考にしたりすると、体系的に組織運営上のり、過剰反応となったりすることがある。セキュセキュリティ対応を実施できることがある。情報

リティ知識・スキルを身に付けたスタッフの育

セキュリティ関連の第三者認証制度には巻末参考

成、その知識・スキルのアップデートの仕組み、

資料 2 に示すものがある。

組織的なノウハウ集積（最新情報収集）と活用のためのノウハウリポジトリ構築や、インターネッ
ト上にある有用なセキュリティ情報へのアクセス態勢などが重要となる。
89

こうしたリスクマネジメントは一挙に正解に達
4.3
4.3

セキュリティ対策での勘違いするのは難しく、分析・設計・実装・テストといった開発ライフサイクルを通じて、リスク対応

1）認証取得を自己目的化しない。
認証取得は自社のセキュリティ対策の確実性の証明方法としてビジネス的には重要なことである自体の品質向上のためのライフサイクルを経ることが通常である。リスク評価とリスク緩和の反復プロセスのライフサイクルの概要イメージを図 5に示す。

が、本来必要なのはセキュリティ対策をきちんと行うことであり、そのためには日常の情報セキュ
リティについての地道な活動が重要である。有効なセキュリティ日常活動の確立の上に認証取得もありうるという順序を踏み間違えないようにする
ことが望まれる。

2）ルールでがんじがらめにしない。
セキュリティの各種ガイドラインや認証基準が

図5

示す指導項目の理由をよく理解できていないと間 スク評価とリスク緩和の反復プロセスのイ
リ
メージ

違った対策や行き過ぎたルールを作ることになる。

リスクアセスメント全体を自ら行わず、発注者

例：開発組織内で「USB メモリを使用するこのセキュリティ要求事項をうけて業務を行っていとで事件事故が発生するそうなので USB メモリ

る開発組織の場合は、セキュリティ要求事項の意の使用を全面禁止する」といった方策を安易に決

味や背景を正しく理解する能力、また、必ずしもめることは、「危険そうだから禁止」という、よ要求事項に明示されていなくてもプロフェッショ

くある行過ぎ策の代表例である。USB メモリをナルな業務としてセキュリティ品質確保のために使わない場合のビジネスの効率性との比較検討や必要なことは何かを理解し実施する知識・スキル「強制暗号化 USB メモリを採用する方策の検討」が要請される。また、この場合にも、実装・テスなどとのトレードオフを評価した上で決定するこトの結果を図 5 の反復プロセスに活かす活動を行とが重要である。その結果仮に「USB メモリをう場合がある。

使用する」ことになった場合には、実際にどのような技術的・制度的対策をとるかを検討し、詳しく運用方法を決定することになる。

5

4.4
4.4

セキュリティの問題の中には、場合により利用

リスクマネジメントとセキュリティ要求
事項理解の知識・スキル作り

クリティカルな製品を開発する企業にとって、その社会的責務を果たすためには、開発にあたっ

発注側と開発ベンダ側の
ポジショニング

者等からの訴訟の対象となったり、報道に取り上げられて企業のブランドを傷つけられたりするものがある。

て常にリスクの評価とリスクの緩和策が正しいもセキュリティの取扱いについてのそうした面ものなのか検証する姿勢を持つこと、即ち、リスク考慮しながら、よいシステムを開発し、よいサー

分析、リスクアセスメント、リスクコントロール

ビスを提供するために、受注側・発注側双方の充手段の設計と実装、検証、妥当性確認を行うこと実したコミュニケーションをベースとして、具体が必要である。

的なセキュリティ課題に取り組む必要がある。

90
JISA Quarterly No.121 2016 Spring1）発 注側メーカは製品仕様に必要なセキュリ

・外部委託した作業員が権限を越えて個人情ティ機能を明確にする。
2）受 注側開発ベンダは不足しているセキュリ

報のデータベースにアクセスできた。
・シ ステムに USB デバイスが接続されたこ

ティ機能とその開発手法を提案する。
3）受発注側双方の技術を集合した開発プロセスを確立し、それぞれの立場と役割を明確にすとを検知する機能が不足又は無効だった。
開発／運用サービスベンダの留意点：
・個人情報データベースなどのアクセス制御る。これは開発案件ごとに必要になる。

を適切に設計・実装するとともに、運用

4）受注側開発ベンダは発注側の仕様を鵜呑みにルールを策定しそのルールに従って厳密にせず逆提案できるように、日頃から知識・ス

運用しなければならない。いわゆる組織のキルやノウハウを獲得・蓄積する。

情報セキュリティにも留意しなければなら昨今では、開発仕様に対してセキュリティ対ない。なお、組織の情報セキュリティの詳策が必要な要件を逆提案することが要求され細については巻末資料 2、ISMS、CMSiS

るので受注側開発ベンダは進んで提案できるを参照されたい。

ようになる必要がある。

・必 要・有効な場合、個人情報の暗号化を

5）受注者側の基本的スタンスとして大事なこと行ったり USB ポートの使用制限機能を実は、要件に含まれているか否かにかかわらず、

装したりする。

常にセキュリティを確保することは組織の社会的責務であること、発注者の元々のセキュリティ目標が達成されるべきことを忘れては〈事例 2〉 裁判事例：セキュリティ対策漏れの責任を開発会社が負わされた例

ならないということである。実装プロセスや事象：公開 Web サイトにおいて機密情報漏えい

テスト等で、自分自身の知識・スキルやノウが起こり、発注側企業はベンダ側の過失とハウを用いてセキュリティを確保できるようして損害賠償を求めた。2014 年、裁判所にすることが必要である。

は、社会で一般に知られている基準の無視による「重過失」だとして、開発費を超える多額の賠償を求める判決を出した。

6

過去の事例から学ぶ

背景：・こ れまで、開発に伴う責任が問われても、開発費を上限とすることが多かったが、本セキュリティの取扱いでは、セキュリティに関件では、その契約条項があっても重過失でする利用者の意識等の社会状況の変化や、実際のは適用されないという理由で多額の賠償と事故事例に学ぶことが特に重要である。以下に特なった。

徴的な事例を列挙するが、それぞれの開発・運用

・IPA が発表している「安全な Web サイト

組織でもこうした教訓を技術ノウハウとして蓄積の作り方」という文書等が社会一般に公知していくことが重要となる。

の品質基準であるとされた。

〈事例 1〉 大規模個人情報漏えい事件

開発ベンダの留意点：
・契約書および合意議事録において、双方の事象：個人情報を含むデータベース運用を外部委

責任分担と、仕様の上での「セキュリティ

託したシステムで、作業員が充電目的と偽要件の必要／不必要」とについて、できる

り、私用のスマホをシステムのクライアン

だけ具体的に記載することが望ましい。

ト PC に USB 接続し、個人情報をコピーして業者に販売したとされる事件。
背景：大きくは次の点が指摘されている。
91

〈事例 3〉 スマホでの情報漏えいにつながる
恐れ

境をよく理解していないと想定外の事象を事象：スマホでは、多くのアプリが並行動作してまた、この事例とは直接の関係はないが悪意おり、それらの間で情報の盗み取りが発生を持った攻撃者が、オンラインメンテナンス

する可能性が指摘されている。

やアップデートの仕組を悪用し機器の動作や背景：
・スマホは、個人情報の宝庫であることから起こすことがある。

機能を変更するというタイプのリスクもある
ことの教訓にもなっている。

攻撃者のターゲットになりやすい上、使用者の大部分が情報セキュリティに対する意識や知識が少ない一般人である。

〈事例 5〉 医療機器システムの遠隔メンテのセキュリティホール

・多用される通信経路がハッカーの比較的侵

事象：セキュリティ系の某ベンダが提供する PC

入しやすい Wi-Fi であることや、一見便利

オンラインリモートコントロール製品を導な無料アプリにウイルスが仕込まれること入した医療検査装置において、そのリモーがあるなど、さまざまなリスクに晒されてトコントロールソフトのセキュリティホーいる。

ルにより、ネットワーク上から攻撃を受け開発ベンダの留意点：

る可能性が指摘され、製品回収に至った。

・アプリ間情報連携はセキュリティ上の危険性をはらむことをよく理解して、対策・対背景：・機器のオンラインメンテナンスや操作法コ応が必要であることを強く意識する。

ンサルティング等を行うためのリモートコ

・セキュリティ確保のためにはどのような方

ントロール機能は便利だが、攻撃対象とな策が必要か、プラットフォームベンダ等のる可能性がある。特に本件のように安全に提供する情報を漏れなく収集し、適切に対かかわる医療機器の場合には大きなリスク応する。

を想定しなければならず、慎重な対処が必・「ジェイㇽブレーク」等、ブラックマー

要である。

ケットで行われている事象とは明確に距離

開発ベンダの留意点：

を置き、加担しない。

・システム構築やメンテナンスサービス提供の技術的な選択肢として商用のリモートコ
ントロール機能（ソフト）の組み込みを検〈事例 4〉 家庭用テレビのリブート障害

討することがあるが、製品供給者のビジネ

事象：某メーカの家庭向けテレビ受像機が、全国ストークを鵜呑みにすることなく、システ

一斉に深夜リブートを繰り返す事象が発生

ムトータルのセキュリティ確保を十分に検した。

討する必要がある。

背景：
・テレビのファームウェアは放送電波（特定電波）を利用してアップデートする機能を〈事例 6〉 自動車制御装置の乗っ取りリスク持つ場合があるが、本件では他社向けを含

事象：米 国のクライスラー社（FCAUS 社）は、

む特定電波データを、テレビに内蔵された2015 年 7 月に、同社の一部自動車車種がソフトが上手く取り込めなかったことが原サイバー攻撃（遠隔操作）リスクの可能性

因とされたを示唆されたとして、製品回収を発表した。

開発ベンダの留意点：

背景：・この例のようにネットワーク接続機器など

・IT メディアが、セキュリティ熟練者に協のアップデートはその手段や使用される環力を依頼して行った実験で、走行中の車を92
JISA Quarterly No.121 2016 Spring遠隔操作（ワイパー動作とエンジン停止）

対策推奨策（これらをベースランと言う）をもすることが可能だったと報じた。実際に悪とに、自社の実態とそれとのギャップをリスク

意ある攻撃を受けたという報告はないが、として評価するアプローチ。社会的な標準や基予防的な措置としてリコールに踏み切った

準を基に自組織の対策基準を策定し、その自組という。

織基準と実態とのギャップをチェックしていく

開発ベンダの留意点：

方法もある。簡単にできる方法であるが、選択・安全に関連するクリティカルなシステムでする標準や基準によっては求める対策のレベル

は、最終製品のメーカに協力して、十分なが高すぎたり、低すぎたりする場合が多い。ま

リスク分析のもと、十分なセキュリティ配

た、現在、公式にはあまり推奨されない。

慮をした実装を行う必要がある。

2）非形式的アプローチ
	組織の熟練者や経験者、またはコンサルタント／学識経験者などの知恵を集めて経験、判断に

7

よりリスクアセスメントを行う。短時間に実施

終わりにあたってすることが可能であるが、組織内の経験者等だけで実施すると、属人的な判断に偏る恐れが相以上述べて来たように情報のセキュリティの確当に大きい。

保ではいかなる対応策（管理策）を取るかが肝に

3）詳細リスク分析

なるが、その場合、技術的対策だけでなく開発に	データ、尺度を用いた評価表や数式を利用して

3

まつわる人的・組織的・物理的 側面でのいわゆ

詳細なリスクアセスメントを実施する。その例

る管理的対策にも十分留意することが重要であとして次の表のようなものが挙げられる。セる。万全の技術的対策と日々改善を目指す管理的

キュリティ要求事項を正しく理解するには、こ対策が、セキュアな製品を作り出す二本の柱であれらについてのある程度の知見があることが望ることを忘れてはならない。

ましい。
手法名称

⒝

FTA 法的なアプローチ

重要想定事故の原因となる事象を系統的に分析し、それに基づいて、事故の発生確率等を評価する。

⒞

ETA 法的なアプローチ

セキュリティ事故の進行と波及・拡散を系統的に評価する。セキュリティ分
野でアタックツリーという手法が用いられることがあるが、上記の FTA 法や ETA 法に分類できる。

⒟

FMEA 法的なアプローチ

システムの構造を用いてシステム全体のリスクを評価する。可用性の評価に用いることが多い。

⒠

HAZOP 法的なアプローチ

定性的な異常事態評価語（ガイドワー
ド）を用いてリスクの進行を評価する

⒡

形式手法

セキュリティ要求事項を数学的に厳密に記述し、要求事項の矛盾や抜け／漏れを低減・防止する。

⒢

実測・実験による評価

セキュリティテスト結果や、運用のユーザビリティ実験評価などの結果をセキュリティ要求にフィードバックする

一般的な IT 製品の開発
Web サイト、OA ソフトウェアなど■巻末参考資料
資料 1．代表的なリスク分析のアプローチと手法
リスク分析手法として言及されることの多いものを下記に示す。
1）ベースラインアプローチ
	既存のセキュリティ標準、基準やセキュリティ

説

ISMS が基本とする 情報資産を列挙し「資産価値（被害時アプローチの影響評価）」「脅威評価」「脆弱性評価」を行い、それを総合してリスクを評価していく。

組込み機器の開発
家電製品：テレビ、ビデオ、エアコンなど
車載機器：NAVI, 自動運転制御など

解⒜⒝ - ⒠については、JIS C 5750 シリーズを参照。
3

物理的管理には、フロア入退管理や媒体持ち出し管理等が含まれる。

934）組合せアプローチ
複数のアプローチの併用。よく用いられるの----------------------------------さらに、セキュリティ対応のための組織のプロ

は、⑴ベースラインアプローチと⑶詳細リスク分

セスの評価として次のものがある。

析の組合せである。ベースラインアプローチで-----------------------------------

ギャップが大きい、あるいは疑問点があるセキュ

4）S SE-CMM (Systems Security Engineering

リティ課題について重点的に詳細リスク分析を行Capability Maturity Model) 規格

うなどする。

セキュリティエンジニアリングプロセス成熟度
評価の国際標準（ISO/IEC 21827）である。

資料 2．認証制度等の例
1）情報セキュリティマネジメントシステム適合性評価認証制度（ISMS）
個別の問題毎の技術対策の他に、組織のマネジ5）国際標準である SPICE アセスメントのセキュ
アシステム開発プロセスへの適用
現在、ISO 等で審議中の国際標準がある。
6）VSE+SS 基準

メ ン ト と し て、 国 際 的 な 評 価 基 準 ISO/IEC

本稿作成の背景として、小規模開発組織向けの27001(JIS Q 27001) に準拠して自らのリスクアセ

セキュアなソフトウェア／システム開発の基準をスメントにより 必要なセキュリティレベルを決

VSE+SS 合同研究会で開発中である。VSE とは、め、プランを持ち、資源配分して、システムを運小規模開発組織向けの開発プロセスの国際標準用する企業活動を認証する制度。

で、コンパクトなプロセス群を提示しているが、認定機関： JIPDEC
2）情 報セキュリティ対策成熟度評価認証制度（CMSiS）

それに開発対象のソフトウェアのセキュリティとセーフティ（安全）の側面を付加するための基準である。

上記 ISMS 同様に ISO/IEC 27001（JIS Q 27001）に準拠した小規模な組織を対象とし、ISMS より

資料 3．ライフサイクルにおけるセキュリティ施策の展開簡素化されつつも実践的な運用ができる。チェックシートを用いて企業活動の実施面を認証する制度。

製品の開発・運用では、セキュリティのリスク分析に基づいて必要なレベル感で実務を進めてい認定機関：JASA

く。その際に、それぞれのプロセスで具体的には-----------------------------------

次のようなことに留意する。これらについて、発組織面の情報セキュリティではなく本稿でとり

注側と受注側の責任範囲を明確にし、情報交換もあげている製品面のセキュリティ評価スキームと緻密に行う。

しては次のものがある。

1）企画・設計時点-----------------------------------

・どのようなユーザ種別を想定し、それに応じた

3）コモンクライテリア認証制度（CC 認証）
情報システムを用いた製品やシステムについどのようなアクセス制御を行うかの方針を決め
るて、充分なセキュリティ対策が施されていること

・電子署名やパスワードを用いる場合、それらのを 評 価 す る 基 準 で あ る ISO/IEC 15408（JIS X

システム上、運用上の管理をどのように行うか

5070）により、セキュリティ上の脅威を排除するを決める。

ための対策が充分に行われているかを審査する。
CC 認証は、製品ごとに行われるものであり、また厳密なものであるので、認証取得実施は重荷だと感じられる面がある。しかし、内容として参考とすべきものは多い。
認証機関：IPA
94
JISA Quarterly No.121 2016 Spring・ユースケースなどに基づき、セキュアな運用が確保されているか検討し決定する。
・セキュアなコンポーネント、ライブラリ等の採用を決定する。
2）詳細設計・実装時点
・暗号関連処理の実装をどのように行うか（場合により、暗号化対応は専門家の参画が必要）。

資料 5．参考資料

・セッション管理をどのように行うか。

1）JIS Q 27001：2014

・直接オブジェクト参照などの脆弱性をどのよう

2）Official（ISC）2 Guide to the CSSLP", CRCに防止するか。
・同 時アクセス制御を確実に行う（レースコン
ディションやデッドロックの確実な回避を含む）。

Press（2011）3）IPA「2013 年度

医療機器における情報セ

キュリティに関する調査」（2014 年 4 月刊）・デ ータ検証処理、及び各種のエラー処理をセ
キュアに行い（フェールセーフ処理を含む）、
また攻撃者がエラーメッセージから容易にシステム特性を把握できないようにする。
・セ キュア・プログラミングを確実に実行する（コーディングルール策定や、その順守状況
チェック）。
具体的な内容としては、バッファーオーバーフ
ロー対策、フォーマットストリング対策、コマン
ドインジェクション対策、セッション管理対策等がある。
3）テスト時点
・ペネトレーションテストの手法と範囲を検討する。
・既 知の脆弱性に対するチェック方策を検討す
る。
・運用におけるセキュリティ上の留意点が確実に
テスト範囲に含まれるようにする。
4）リリース時点と運用時点
・リリースノートにセキュリティ上の注意事項が確実かつ有効に記載されるようにする。
・運用時の過去の不具合情報を教訓として活用する。
・セキュリティパッチの作成・配布方法について
明 確 に す る。 可 能 な 場 合、IPA と JPCERT/
CC が運用している脆弱性取扱いスキームに整合させる。
資料 4．組織名の略語等の表
IPA（独）情報処理推進機構

JASA（一社）組込みシステム技術協会

JIPDEC（一財）日本情報経済社会推進協会

JPCERT/CC （一社）JPCERT コーディネーションセンター
OWASP

Open Web Application Security Project

CERT

米国カーネギーメロン大学のセキュリティインシ
デント対応・研究部署の名称（略語ではない）

95

［解説］

セーフティの基礎～ VSE への展開にむけて～
足立 久美、田渕 一成

VSE+SS 合同研究会一同

キーワード
VSE、セーフティ、リスクアセスメント、本質的安全、機能安全、ISO/IEC GUIDE 51、
ISO 26262、Automotive SPICE、セキュリティ

要旨

今日、我々は様々な製品やサービスの恩恵を受けているが、逆にその欠陥や障害等により不利益を被ることもある。特に「社会とつながる」という機能をもった製品やサービスは、一度の障害が社会に大きなダメージを与えかねない。エンジニアはこのことを肝に銘じて、安全・安心な製品やサービスを利用者に提供していかなくてはならない。これを実現するための重要なキーワードは、セーフティ（Safety：安全性）とセキュリティ（Security）である。本稿では、VSE（Very Small Entities：比較的小さな
ソフトウェアを開発する小規模な組織）が、製品やサービスのセーフティとセキュリティに関する設計活動を見直すのにあたり、セーフティについて必要最低限知っておくべきこと、および車載電子システムにおける安全の動向や課題から得られたセーフティの適用のヒントについて解説する。
便性や快適性を提供してくれる半面、使い方を誤

1

はじめに

れば製品やサービスの利用者に対して害をもたらしかねないのである。つまり、ソフトウェアを搭載した製品やソフトウェアを利用した製品やサー

我々の生活は、自動車、鉄道、航空機などの乗ビスの提供者である技術者（エンジニア）は、所

り物、電気、ガス、水道、銀行のオンラインシス

属する企業や組織の規模に関わらず、このことをテムなどのインフラ、家庭における様々な電化製

強く認識し、安全な製品やサービスを社会に提供品など、日常のあらゆる場面でソフトウェア技術

していかなければならない。

の恩恵を受けている。

ここで、安全な製品やサービスを提供するとい一方、近年はソフトウェアを搭載した製品やソうことは、単に品質が高いということや信頼性がフトウェアを用いたサービスの大規模化、複雑化

高いということとは同一ではないという点に注意に伴い、ソフトウェアの欠陥により、その利用者して欲しい。「安全」という言葉と対としてよくが身体的な危害や経済的な損失を受ける事案も使われる言葉に「安心」という言葉があるが、安度々発生しており、ソフトウェアの安全・安心へ

全とは製品やサービスを利用する人にとっての安の関心が急速に高まっている。このように、ソフ

心につながるものでなければならない。つまり、トウェア技術（エンジニアリング）は、我々に利製品を開発した本人がその安全性にどれだけ自信

96
JISA Quarterly No.121 2016 Springを持っていても、それを利用する相手にその安全性が理解されなければ、相手にとっての安心にはつながらず、安全性を保証したことにはならない。そのため、安全性は製品やサービスの利用者、またはその開発を委託した委託元にとって、理解可能な形で示される必要があり、安全性を裏付けるエビデンスを確実に構築していくことも重要視される。
本 稿 で は、 特 に VSE（Very Small Entities：

図1

比較的小さなソフトウェアを開発する小規模な組

スイスチーズモデル
James Reason（1990）

織）が製品を開発していくにあたり、必要最低限

イスチーズモデル（Swiss cheese model：SCM）

知っておくべきことをセーフティの側面から、第である。このモデルは、不具合要因が多重の防護

2 章で、「安全設計の基本」として主に「安全設策の穴をすべて潜り抜けた場合に危害が発生する計の考え方」と「リスクアセスメント」についてことを示している。一方で、このモデルは同一の平易に解説する。また、第 3 章で、「VSE への適原因により複数の防護策を脅かしてはならないこ用にむけて」と題して、車載電子システムにおけとの重要性を示している。

る安全の動向と課題に基づいて、セーフティのVSE への適用のヒントを探っていく。

そこで、安全設計における代表的な防護策として、 フ ー ル プ ル ー フ（Fool Proof） と フ ェ イ ル
セーフ（Fail Safe）について以下に紹介する1）。
エンジニアは、少なくともこの二つの防護策を理

2

安全設計の基本

本章では、安全設計とリスクアセスメントの考
え方について述べる。

解し両者の違いを識別できなければならない。

（1）フールプルーフ（Fool Proof）
人は間違うことを前提にし、間違えにくい設計
または、間違うことの出来ない設計をすることを
フールプルーフと言う。

2.1
2.1

安全設計の考え方

これは、図 2 の防護壁（A）に該当する。操作
ミスなど人が誤った機械操作を行えば、機械装置

安全設計とは、「ものは壊れる、人はミスをす

が人に危害を与える可能性が考えられる場合、人る」ことを前提にし、その防止策や被害の最小策

が操作を間違えにくい設計または、人が間違うこを設計に盛り込むことである。

との出来ない設計をすることが重要である。

誤操作等の不具合要因が発生した場合でも、

フールプルーフは、通種バカヨケ、ポカヨケと人・財産・環境への危害が出ないように防護策を呼ばれており、電池を＋－逆接できないように施す必要がある。しかしながら、完全な防護策をなっている電池ボックスなどがこれにあたる。

構築することは難しく、何らかのリスクが残留する場合が多い。そこで、単一の不具合による直接的な危害を発生させないために、図 1 のように多重防護策を設ける必要がある（図 1 の防護壁が防護策にあたる）。
図 1 はマンチェスター大学の心理学教授ジェー
ムズ・リーズンによって 1990 年に提唱されたス

図2

フールプルーフとフェイルセーフ
97

（2）フェイルセーフ（Fail Safe）
もし間違いが発生しても、被害を発生させな
い、もしくは最小にとどめる設計をすることをフェイルセーフと言う。これは、図 2 の防護壁
（B）に該当する。操作ミスなど人が誤った機械操作を行ったり、機械装置が故障しても、機械装置が人に与える危害を最小化する設計、例えば故障してもなお安全を保ったり、誤動作したり危険な出力を生じないようにする（回路故障の際に、できる限り安全側の出力をする）といった設計をすることが重要である。決められた上限の速度を

図3許容できるリスクと許容できないリスク

超えてカーブに電車が入ってきた場合に電車を止める ATS などがこれにあたる。

件下では受け入れることができるリスクのことでなお、防護策には、一つのシステムを複数の装ある。また、安全に関する必ず押さえておきたい

置に分散して処理させるなど、システムの一部が重要な安全関係の用語を表 1 に示しておく（国際

故障した場合に性能の低下をさせてでも機能を継規 格 ISO/IEC GUIDE 51：1999 は 2014 年 に

続 的 に 実 施 さ せ る と い っ た「 フ ェ イ ル ソ フ ト

ISO/IEC GUIDE 51：2014 2）として改訂された際（Fail Soft）」や、航空機の与圧装置を 2 系統にすに、「安全（Safety）の定義が「受容できないリるなど障害は必ず発生するという考えに立ちソフ

スクがないこと」から「許容できないリスクがな

トウェアやハードウェアの冗長化をすることによいこと」に改正された。なお、「受容可能なリスりシステムの信頼性を図るといった「フォールトク」とは、どのような条件下でも受入れることがトレランス（Fault Tolerance：対故障性）」、製できるリスクをいう）。

品やサービスの構成要素から可能な限り故障や障害などの不具合の発生要因を排除する、また不具合が発生しないように十分なテストを行うなど構成要素の信頼性を高めるといった「フォールトア
ボイダンス（Fault Avoidance）」がある。
表1

2.2
2.2

安全に関連する重要な用語

リスクアセスメント
安全を実現する方法として一般的に使われてい安全は、図 3 に示すように受入れ不可能なリスる方法がリスクアセスメントである。国際規格

クをなくし、リスクを受容可能なレベル（受容可3）4）ISO/IEC GUIDE 51：1999（JIS Z8051：2004）

能なリスク）になるまで低減させることで達成さでは、「許容可能なリスクをリスクアセスメントれる。つまり、このことは製品やサービスの安全によるリスク低減プロセスを反復することによっ性を担保するためには、その製品やサービスが、て達成させる。」こととし、図 4 に示すようなリ市場でどのように使用されるかを想定し、その使スクアセスメント及びリスク低減の反復プロセス

われ方に起因する危害を特定し、その危害のレベを定義している。

ルを利用者が受容できるレベルまで下げればよいことを意味する。
ここで、「許容可能なリスク」とは、特定の条
98
JISA Quarterly No.121 2016 Spring

ここで、国際規格 ISO/IEC GUIDE 51：1999
は 2014 年に ISO/IEC GUIDE 51：2014 として改訂された際に、リスクアセスメント及びリスクの能である限り事故発生時の責任はメーカーが負うべきという考え方があるため、この予見可能な誤使用を特定することが重要なポイントである。
ここで、予見可能な誤使用とは、開発者（メーカー）が推奨する使用方法でないにも関わらず、使用者の都合によって採用されてしまう誤った使用方法のことである。これは、通常はロックをかけて使用するようにメーカーが指定しているにも関わらず、使用者自身がロックを解除して使用することで操作の手間が軽減されるといった場合など、使用者が何らかの利点を感じることにより採用してしまうことが多く、それに伴って危険な事
象を発生させることがある。以上のことから、
図4 リ
 スクアセスメント及びリスク低減の反復プ
ロセス
ISO/IEC GUIDE 51：1999（JIS Z8051：2004）より引用

メーカーは意図しない使用方法であっても、使用者が故意に採用する可能性のある使用方法も含めて、予見可能な範囲における全ての使用方法を特定しなければならない。
次に、特定した各使用方法に対して個々に発生低減の反復プロセスの図が詳細な図に変更されたするハザードを特定する。代表的なハザードの特が、本稿では旧版の ISO/IEC GUIDE 51：1999

定方法に FTA、FMEA、HAZOP がある。

（JIS Z8051：2004）の図を用いた（理由：旧版と最後に、その発生するハザードが引き起こす製

新版とでは基本的な考え方は変わらない。また、品やサービスの使用者や関係者に対するリスクを

反復的リスク低減プロセスを 3 ステップメソッド

見積る。リスクの見積りでは主に危害の程度と発として詳細に定義している ISO 12100：2010（JIS

生確率の算定を行う。

B9700：2013）との対応をとるため）。
リスクアセスメント及びリスク低減の反復プロセス（図 4）は、リスクアセスメントとリスクの（2）リスクの評価低減により構成される。さらに、リスクアセスメ

リスクの見積りが終了したら、それが許容可能

ントはリスク分析とリスクの評価により構成されであるか否かリスクの評価を行う。もし、許容可る。以下、これらについて順番に説明する。

能であればプロセスを終了する（終了に際して結果の妥当性確認をすることが望ましい）。許容可（1）リスク分析

能でなければ「リスクの低減」を図った上で最初に戻り、リスク（残留リスク）が許容可能となる

リスク分析は、さらに「意図される使用方法・まで反復する。なお、「リスクの低減」を反復し合理的に予見可能な誤使用方法の特定」、「ハザーても、リスク（残留リスク）が許容可能とならなドの特定」、「リスクの見積り」により構成されい場合は、製品やサービスの開発の見直しをする

る。

必要がある。

まず、最初に対象の製品やサービスの意図されここで、リスクアセスメントではリスクを「許る使用方法と予見可能な誤使用方法を特定する。

容可能なレベル（許容可能なリスク）まで低減す

一般的に、「意図する使用方法を特定すること」

る」とあるが、できれば「受容可能なリスク」ま

よりも、「予見可能な誤使用を特定すること」のでの低減を狙うべきである。

方が開発者にとって比較的難しい。また、予見可99

（3）リスクの低減
図 5 に「リスクの低減」の方法を示す。「リスクの低減」方法は図に示すように、さらに「本質クを低減する。」といった本質的安全設計である。
本質的安全設計の実例を図 7 に記す。図 7 では自動車道路と鉄道を立体交差にすることにより本質的安全設計をしている。

的安全設計方策」、「安全保護（保護装置）」、「安

その次に、本質的安全設計を実施してもまだ許全上（使用上）の方法」の 3 つのリスクの低減方

容できない残留リスクがあれば、「安全防護（保法により構成される。

護装置）をつけて低減する」といった安全防護（保護装置）による防護を行う。ここで、前節で解説したフールプルーフやフェイルセーフがこの安全防護の方法に相当する。
安全防護（保護装置）による防護の実例を図 7に記す。図 7 では自動車道路と鉄道が交差するところに、地形等の理由で本質的安全設計（立体交差）にすることができない場合に、安全防護（保図5

リスクの低減手段（保護方策）
ISO/IEC GUIDE 51：2014 より引用

護装置）として遮断機付きの踏切を設置している。
そして、最後に安全防護（保護装置）を実施しリスクの低減で最初に実施するのは、「危険源てもまだ許容できない残留リスクがあれば、「使をなくす、または無くせない場合は危険源のリス

用上の情報を使用者に伝える」といった使用上（安全上）の情報発信を行う。図 7 では警報機（踏切の存在を通行者に知らせる踏切警標、列車の接近を視覚的に警告する警報灯、列車の接近を音により知らせる警報音、踏切が危険区域であることを示す、黄色と黒の縞模様の警告色がこれに相当する。
ここで、特に注意して欲しいことは、3 つの方策には優先順位（図中の番号）があるということである。つまり、本質的安全設計を考慮せずにいきなり安全防護によりリスクの低減をするのでは

図6

本質的安全の例：立体交差

なく、本質的安全設計をした上で残留リスクがあれば、安全防護をとるべきである。
なお、国際規格 ISO 12100：2010（JIS B9700：
5）6）
2013）
の「リスクの低減」の 3 つの方策の定義を表 2 に記しておく。

図7

安全防護の例：遮断機付きの踏切

100
JISA Quarterly No.121 2016 Spring

表2

リスクの低減の 3 つの方策の定義

図9
図8

使用者によって講ずる保護方策
ISO/IEC GUIDE 51：2014 より引用

本質的安全の例：立体交差（その 2）とに、防護装置を追加したり、訓練をしたり、保ここで、次の設問の答えを考えて下さい。

護具を装備するといった活動を実施することになる。

設問：図 8 は図 6 に対して線路と道路が上下逆ないくら設計者側が安全活動、安全設計によってだけで、同じ本質的安全の例であるが、一許容可能なレベルまでリスクの低減をしたとしてつの違いがある。それは何ですか？

も、利用者側においても安全活動を実施し、さらに残存リスクを軽減することは大切である。絶対答えは、図 8 では道路側に安全防護策として、的安全というものはありません。設計者側はもち鉄道のガード下に車が衝突し橋脚にダメージを与ろんですが、利用者側も安全意識、危機意識を持えないようにする衝突防止のためのゲート（線路ち続けることが肝要です。

の橋脚囲い）があることである（図中の鉄製で頑丈な黄色の構造物で、鉄道のガード下の高さより衝突防止のためのゲートの高さが低く設定されて

2.3
2.3

機能安全とはいる）。これは、先に説明したフールプルーフ（線路の橋脚に衝突させない）に相当する防護策

近年、車載電子システム向けの機能安全規格です。逆に図 6 には衝突防止のためのゲートがな

7）「ISO26262」などにより「機能安全」という言葉

いのは、線路を走る電車はその車高を確実に制限をよく耳にする。ここでいう「機能安全」は、できるためである。しかしながら、自動車（特に「リスクの低減」の 3 つの方策の中の「安全防護特殊車両）は確実に車高を制限することができな（保護装置）」に相当する。

い。図 8 は、このことも想定し本質的安全と安全

本稿では、機能安全についての詳細な解説は省防護の両方の対策をしていることを示している。

略するが、機能安全を理解する上で重要な用語のなお、この衝突防止ゲートにも図 7 の踏切と同様一つである「安全文化」について以下に説明をしに黄色と黒の縞模様の警告色をつけて、危険区域ておく。

であることを視認し易くしている。

「安全文化」とは、組織およびそれに属す個人

以上、3 つのリスク低減手段について述べてきに根付く安全の考え方や行動指針である。

たが、これらは設計者によって講じられる保護方

安全文化の必要性が強く求められるきっかけと

策 に 関 す る も の で あ る。ISO/IEC GUIDE 51：なったのが、1986 年のチェルノブイリの原子力2014 には、製品やサービスの使用者にとっての発電所の事故である。この事故において、国際原

安全活動を「使用者によって講ずる保護方策」と子力機関がその原因を調査していく中で、現場のして定義している。これを図 9 に示す。

作業員、発電所を運営する事業者、行政などそれ製品やサービスの利用者は、使用上の情報をもぞれに安全に対する考え方や仕組みの問題が提起
101

され、安全文化の必要性が唱えられた。現場の作

ミュニケーションによる情報共有（特に悪い情

業員に安全管理のマニュアルが渡されていても、

報）、同じ失敗を繰り返さない振り返り（学習）作業員がその本質を理解していない限り、安全管

活動、決められた基準・ルールの遵守などがアウ

理は本来の効果が期待できない。また、組織におトカム（outcome）として観測される。

いても安全管理者を設置するだけではなく、組織としての目標を掲げ、それを実現するための仕組
みや人材の育成が求められる。

2.4
2.4

安全関係の国際規格について

これは、車載電子システムの開発においても同じことが言える。後述の 3.1 にも関連した事象を安全に対する国際規格は、表 3 に示すように、

述 べ て い る が、ISO 26262 や Automotive

安全性に関する基本的な概念・原則・要求事項をSPICE の対応が求められたことによって、プロ規定した「基本安全規格」、複数の製品・サービ

セスの定義やガイドラインの作成を形だけの対応

スの安全性を規定した「グループ安全規格」、個で終わらせようとするケースも世の中には見られ別の製品・サービスの安全性を規定した「製品安るが、これでは安全文化の醸成は難しい。そのよ全規格」といった複数の規格で構成されています。

8）

うな組織の中には、上層部が安全の重要性を理解しておらず、最小の努力で規格対応を終わらせる
よう指示をしてしまっている場合も見受けられるが、改めて機能安全対応の本来の目的を考えるべきである。
また、機能安全対応の当初は明確な目的を持ってプロセス構築がされたものの、それが組織内で使用されていく中で、組織標準プロセスの構築当初の意図が忘れ去られ、結果的に不遵守へと陥るケースもある。人は誰でも意味のない活動を好ま

表3

安全規格の種類

ないものであり、意図のわからない活動は定着し

本稿で主に参照した規格は、二つの国際規格ない。そのため、組織標準プロセスは一度構築し「安全側面－規格への導入指針：ISO/IEC GUIDEて終わりではなく、組織の中で絶えず改善を続

51：1999（JIS Z8051：2004）」と「機械類の安全

け、組織標準プロセスを継承していく必要がある。

性―設計のための一般設計原則－リスクアセスメ

さらには , 製品設計における安全を最優先するン ト 及 び リ ス ク の 低 減：ISO 12100：2010（JIS

風土や気風の形成が , 安全文化の醸成において非B9700：2013）」である。安全設計に関わるエン常に重要である。具体的に言えば、安全最優先のジニアは少なくともこの二つの国際規格は読んで価値観（例えば組織の安全方針や目標）が関係者おかれることを強く推奨する。

全員で共有され、その共有された価値観に従って

車載電子システムの分野においては、2011 年

日々の設計業務（例えば、組織の安全方針や目標に機能安全規格 ISO 26262 が発行され、完成車を満足又は達成する安全活動）が遂行されているメーカーと自動車部品メーカーを中心にその取りことが要求される。いくら良い技術やプロセスが組みが行われてきている。

あっても、安全文化が未成熟な組織では、安全・

この規格は、前述の ISO/IEC GUIDE 51 の体

安心な製品やサービスを継続的に利用者に提供し系の中に位置づけられ、基本理念を引き継ぎつつていくことは難しい。

車載電子システムの特徴に基づいて構築された。

安全文化が成熟している組織では、組織を構成

しかしながら、ISO 26262 は、IEC 61508 等の従するメンバーのより安全・安心な製品・サービス

来の機能安全規格のアプローチに加え、車載電子を提供しようとする姿勢（使命感）、円滑なコシステムの開発の分野で取り組まれてきたプロセ

102
JISA Quarterly No.121 2016 Springスアプローチをその土台として色濃く持ってい車載電子システム開発向けのプロセスアセスメン

る。

トモデルとして Automotive SPICE が策定されここで簡単に ISO 26262 の発行に至るまでの車
載電子システム開発発の分野での取り組みを解説た。
従 来 の 車 載 電 子 シ ス テ ム 開 発 の 分 野 で は、
CMMI や ISO/IEC 15504 に基づいて自社のプロする。
1990 年代の後半から 2000 年代の初頭にかけ、セス改善に取り組む動きもあったが、それらのモ自動車のエレクトロニクス化が急速に進み、車載

デルや規格と比較して、Automotive SPICE は、

電子システム開発の環境が大規模かつ複雑なもの

開発委託先に対して開発委託元が第二者の立場でへと変化した。特に、車載電子システムに搭載さアセスメントを行うための特徴が強く反映されてれるソフトウェアの開発においては、前述の大規いる。

模化、複雑化に伴い、開発の受委託関係を含めた

そしてまもなく Automotive SPICE は、欧州開発体制にも大きな変化をもたらした。その結を中心として完成車メーカーの調達要件として掲

果、ソフトウェアに起因した不具合が急速に増加

げられるようになり、これに基づくプロセスアプ

し、その対策が重要視され始めたのである。特ローチは、車載電子システムを開発する上で広くに、自動車としてのもっとも基本的な機能である

適用されるようになっていった。

走る・曲がる・止まるという機能におけるエレク

このように Automotive SPICE は、ISO 26262

トロニクス化は、それに起因した不具合が発生すが発行される以前から車載電子システム開発の品ることで自動車の運転手や同乗者、周囲の歩行者

質向上のために広く適用されるようになっておの安全を脅かすこととなる。

り、その存在は ISO 26262 の策定や活用の仕方に

こ の よ う な 状 況 の 中、 図 10 に 示 す よ う に、も 大 き な 影 響 を 与 え た。 逆 に、Automotive

2000 年代の初頭から欧州の完成車メーカーを中SPICE も ISO 26262 の影響を受け、改定が進ん

心に、車載電子システム向けの機能安全規格の必だのである。つまり、この両者は非常に密接な関要性が訴えられ始め規格の策定につながっていっ係を持つようになり、車載電子システム開発の分た。

野においては、多くの場合、この両者の対応が同

この車載電子システム向けの機能安全規格の策

時に求められている。

定に向けた動きと平行して、品質の向上のため開ISO 26262 が発行された当初は、規格の解釈が発委託先に対するプロセスアプローチを強く推奨

十 分 で な か っ た 場 合 な ど も あ り、Automotive

する動きが始まっていった。当初は、各完成車

SPICE 対 応 の た め の 組 織 標 準 プ ロ セ ス と ISOメーカーが独自の基準に基づいた取り組みを展開

26262 対応のための組織標準プロセスを別々に構していたものの、開発委託先の品質向上は完成車築している組織も見受けられたが、本来の組織標

メーカー共通の課題であったため、2005 年には、

準プロセスとは、組織のあるべき姿を反映したもISO/IEC 15504 や ISO/IEC 12207 に 基 づ い て、のであり、Automotive SPICE や ISO 26262 の対応要求に左右されるものではない。

3
3.1
3.1
図 10

車載電子システムの安全に関する規格の推移

VSE への適用に向けて

安全設計の VSE への適用の考察

これまで述べてきた車載電子システム開発の分103

野における動向や課題に基づいて、VSE への適用について考察する。

（1）
「国際規格や法規の遵守」だけを目的としているケース

一般に、車載電子システムに搭載されるソフト

結論から述べると、国際規格や法規を遵守すれ

ウェアの開発は、非常に大規模なプロジェクトでさえいれば、安全な製品を開発できるわけではな

行われているという印象を持たれている方も多い

いということである。

が、カーナビゲーションシステムなど一部のシス
テムを除けば、大手の自動車部品メーカーにおいても、実際には 10 人以下の小規模なプロジェク
トが全体の半数以上を占めている。しかしなが規格や法規への対応は、下記の 3 つに区分することができる。
・法規（国家や国家連合体）で規定されている
安全要求

ら、プロジェクトの規模に関わらず、安全な製品

・顧 客（OEM）の会社規程（標準等）で規定を開発するという責任は変わるものではなく、車されている安全要求（国際規格から引用した

載電子システムの開発の委託元である完成車メー

もの及び自社独自の規程）

カ ー か ら は、 前 述 の ISO 26262 や Automotive

・自社規程（標準）で規定されている安全要求

SPICE の対応が厳しく求められているのである。
自動車の分野においても、プロジェクトの規模

まず、法的な要求は必ず満足しなければならが小さいため、ISO 26262 や Automotive SPICEず、また顧客からの安全要求も RFQ（Requestの対応が難しいという旨の声が聞こえることもあfor Quotation：見積依頼書）や SOW（Statement

るが、これらの規格やモデルの対応において重要

of work：作業明細書）等で合意した以上満足し視されていることの一つが、組織の特性に合わせなければならない。さらに自社規程からの安全要た組織標準プロセスの構築と、プロジェクト特性

求も含めて、これらの安全要求は、遵守すべきこに合わせたプロセスのテーラリングである。つまとの最低ラインとしての要求であり、これらを満り、ISO 26262 や Automotive SPICE の対応は小足することが最終目標となってはならない。もち規模なプロジェクトにとって必ずしも負荷の高い

ろん、正当な理由がある場合はその理由を明確にものということではなく、安全なものづくりを適残した上でテーラリングをすればよい。（法規を切に行っていく上で、組織やプロジェクトの特性除く）に合わせて取り組むべきこと、そして説明責任を

また、国際規格には何をするべきか（what）

果たすことが求められているだけとも言えよう。

は 書 か れ て い る が、 ど の よ う に 実 現 す る の か

確かに、中小企業よりも大企業の方が、組織内に（how）まで書かれていないことが多い。なぜな

安全活動を推進するための間接部門を置いたり、らば、前述のように、これらの要求事項は最低ラ

広く知見の共有を行ったりすることのできる利点

インとしてのものであり、その手段を詳細に要求はある。しかしながら、安全なものづくりをするするものではないからである。

上で果たすべき責任は、組織の規模に関わらず同じである。

さらに、国際規格は、必ずしも実施順序どおりに記載されていないことがあるので注意が必要である（国際規格をそのまま自社ルールに張り付け

3.2
3.2

安全設計の経験に基づく
VSE に向けたヒント

最後に、機能安全対応にありがちな 5 つのケー
スと、VSE での対応のヒントを考察する。

てもうまくいかない）。また、一般の開発者にとって、要求の意味が十分に理解できないもの
や、要求されている技法の適用の際の厳格さまでは記載されていないことも多く、関連規程や参考資料を参照しながら準備に膨大な時間を費やさなければならない場合もある。前述のように、国際
規格はあくまでも遵守すべき最低ラインの定義であり、それを自社の製品やサービスにあてはめな

104
JISA Quarterly No.121 2016 Springがら最適化し、組織の規程（標準、ルール、手順

なお、認証の取得や認証の維持にはそれなりのなど）に確実に実装していくことが肝要である。

コストが必要となるため、やみくもに認証を取得

つまり、規格に書いてある通りやコンサルタント

するのではなく、認証を取得することの効果をよに言われた通り実施するのではなく、自分の頭でく考えた上で決断すべきである。

目的を考えることが重要である。
（2）
「安全活動＝安全防護（機能安全）」と考えているケース（4）技術者倫理感が乏しくなったケース「機能安全の国際規格への対応が要求されたか

第 2 章のリスクアセスメントで説明した 3 つのら、これから安全設計をしなければいけない。」

リスクの低減方策の中の安全防護（機能安全）のという趣旨の発言をしているケースのことであみを安全活動と位置づけ、安全防御（機能安全）

る。そもそも、セーフティへの取り組みは、機能に特化した安全活動をしているケースも見られ安全の国際規格が発行されて初めて取り組むものる。
（1）のケースの国際規格に準拠しさえいればではなく、従来から社会に対して製品やサービス

良いというケースにおいて発生することが多い。

を提供してきた企業であればすでに自社の安全文

安全設計のリスクの低減において、最初に考える化が築かれ、自社の提供する製品やサービスに安べきは「本質的安全設計」である。

全設計を施しているはずである。もし、そうでな

しかしながら、本質的安全設計はソフトウェア

ければ安全対策が不十分な製品やサービスを社会だけでは対応することが出来ない。製品のシステに供給していることになってしまう。機能安全規ム全体で安全性を考慮して初めて本質的安全設計

格への対応だけが目的となってしまっている企業が可能となるのである。そのため、ソフトウェアの中には、前述のようにこれから初めて安全対エンジニアの中にはシステム全体の安全性を考慮

策、安全設計を行うような感覚を持っているエンすること自体を不可能と捉えている場合も見受け

ジニアも少なくなく、規格の対応から外れた製品られるが、システム全体の考慮なしではソフトについては、安全設計が不要という考え方も見らウェアの安全上のあるべき振る舞いは見出すことれる。そのような企業は、機能安全規格への対応ができない。

の前に技術者倫理の教育を行い、企業の社会的責任を果たす企業の風土を構築する必要がある。

（3）認証取得だけを目的としているケース
プロセス認証、ツール認証などの認証を取得す

製品設計と安全設計は表裏一体である。

ることが、安全活動の目的になってしまっている（5）
「苦能安全」活動と捉えてしまったケース。

ケースがある。安全活動の目的は認証を取ること「機能安全の国際規格への対応が要求されたのではなく、自社が利用者に提供する製品やサービで、これから大変だ！」といった考えに陥っていスの安全性を確保することである。また認証機関るケースである。（4）でも述べたように、安全文が対象製品の安全性そのものを保証するものでは化の醸成も安全設計も一から始めるわけではなない。

く、組織がそれまで蓄積してきた基盤がある。適一般に、認証は以下の 2 つの理由により対応が求められる場合が多い。
・流通対象国の法規要求や顧客要求で指定されている。

切な安全活動を実施しているのなら、その基盤（ベース）に自信をもって、「機能安全の国際規格への対応が要求されたので、自分たちが従来からやっている安全設計を、国際基準に照らし合わせ・顧客に自分たちの提供する製品やサービスのて、どのように準拠しているかの説明責任を果た

安全性を効果的に主張する根拠として用いせばよい。もし、不十分な点があれば必要な改善る。

をおこなっていけば良い。」と考えるべきである。
105

この考え方こそ「喜能安全」活動である。

説明責任（Accountability）を果たさなければな

また、機能安全の対応は必ずしも工数の増加をらない時代となった。安全とは、相手に対して安招くものではないということに着目する必要があ

心を与えることなのである。自分自身がいくら安る。プロセスアプローチが機能安全対応の土台と全に自信を持っていても、また自社の安全基準を前述していたが、適切なプロセスの適用は、全体達成していたとしても、それが相手にとって理解として大幅に効率が向上する。それぞれが個人のできるものでなければ、相手は安心しない、つまノウハウに基づいて独自の開発をしていた状況でり、安全とは言えないのである。このような安全は、それぞれの成果物に対して、その内容の正しの説明責任は、大企業であっても、VSE であっさや妥当性を客観的な立場から裏付けることは容ても同じである。

易ではないが、開発活動が組織の標準プロセスに

今後は VSE が提供する安全・安心な製品や基づいて展開され、計画の逸脱がないことを常にサービスにも、セーフティとセキュリティが問わ監視し、標準化された手法に基づいて開発を行れる。取り組みはじめるのは今、「安全に手抜きい、成果物を客観的に評価するための仕組みが確なし」である。安全文化を醸成し、リスクアセス

立しているなど、適切なプロセスアプローチが行

メントを活用するなど、より安全・安心な製品やわれることで、開発の効率化だけではなく、組織サービスを提供していくことを期待する。

へのノウハウの蓄積、さらには、安全文化の醸成が期待される。

■文献1）独立行政法人情報処理推進機構，組込みシス
テムの安全性向上の勧め（機能安全編），2006.

4まとめ2） ISO/IEC GUIDE 51 Safety aspects –Guidelines for their inclusion in standards,
2014.

以上まとめると、セーフティへの取り組みにお3） ISO/IEC GUIDE 51 Safety aspects –いては、組織の規模に関わらず安全文化の醸成がGuidelines for their inclusion in standards,

もっとも重要と言えよう。

1999.

製品の開発に関わるエンジニアは、安全文化の4）財団法人日本規格協会，JIS Z8051，「安全側重要性を理解する必要がある。そのためには、エ

面－規格への導入指針，2004.

ンジニアはスリーステップメソッドに従ったセー5）ISO 12100 Safety of machinery – General

フティの基本アプローチと安全技術の基本原理をprinciples for design – Risk assessment and十分に理解する必要がある。

risk reduction, 2010

また、組織は安全な製品を開発するための組織

6） 財団法人日本規格協会，JIS B9700，機械類の特性に合ったプロセスを構築する必要があり、の安全性―設計のための一般設計原則－リスク

さらに個別の開発プロジェクトにおいては、プロ

アセスメント及びリスクの低減，2013.

ジェクトの特性に合わせて組織標準プロセスを仕7）ISO 26262 Road vehicles - Functional safety,

立て直すテーラリングが必要である。

International Standard,

first edition, 2011.

このように、組織、プロジェクト、個人のそれ8） Automotive Special Interest Group：

ぞれの役割を果たすことで初めて安全文化が醸成

Automotive SPICE（R）Process Assessmentされるのである。

Model v2.5, 2010.（www.automotivespice.com）

従来は、安全・安心な製品やサービスを自社基準で提供すれば良かったが、これからは製品やサービスが安全・安心であることを、客観的かつ具体的な証拠でもって利用者に説明するといった
106
JISA Quarterly No.121 2016 SpringISO/IEC TR 15504-10 に対するセキュリティ拡張の検討
VSE+SS 合同研究会

VSE+SS 合同研究会成果レポートにあるように、「ISO/IEC TR 15504-10（セーフティ拡張）に対するセキュリティ拡張の検討」は、セーフティ／セキュリティのプロセスを通常の開発プロセスに付加するために本合同研究会で検討・定義されたものです。
現在この定義はまだ開発中の版であり、本合同研究会では引き続き早期の完成版の提示に向けて活動を継続します。検討中の事項として、VSE からさらにその先のサプライヤに言及する部分が必要なのかど
うかといった点があります。
VSE+SS 合同研究会（以下、本研究会）では、ISO/IEC TR 15504-10（セーフティエクステンション）の内容を参考に、セーフティとセキュリティを融合した対策の検討を行った。
なお、本研究会での研究成果として、本文書の最後にセーフティとセキュリティを融合したモデルの例を示すが、本内容は ISO/IEC TR 15504-10 との直接的な関係を持つものではない。
本研究会では、セーフティとセキュリティを統合した技術を SS（Safety and Security）と呼び、SS を達成するために必要な管理、技術、適格性確認に関するプロセスを以下のとおり検討した。
プロセス群：SSE（Safety and Security Extension）
・SSE.1：SS 管理
SS 目標を達成するために、ライフサイクル全体を通じて実施すべき SS 活動を計画し、その状況を監視し、逸脱があれば制御するためのプロセス。
・SSE.2：SS 技術
SS 目標を達成するために、製品に関係するハザードおよび脅威を識別し、それらを回避、抑制するための開発、検証、評価を行うためのプロセス。
・SSE.3：SS 適格性確認
サプライヤへの開発委託や外部購入など、外部リソースを活用してシステムを開発する場合に、外部リソースを適切に評価するためのプロセス。
これらのプロセスは、ISO/IEC 15504-2 のフレームワークに基づき、ISO/IEC 15504-5 や業界特化版として策定されている Automotive SPICE 等の ISO/IEC 15504 派生モデルへのエクステンションとしても活用が可能である。

107プロセス ID

SSE.1

プロセス名

SS 管理

プロセス目的SS 管理プロセスの目的は、セーフティおよびセキュリティの目標（SS 目標）を満足するために、製品／サー
ビスのライフサイクルを通じて SS 管理活動を確立することである。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
1）SS の原理と基準が確立されている。
2）プロジェクトのための SS 活動の範囲が定義されている。
3）SS 活動が計画され、実施されている。
4）SS 活動を実施するために必要なリソースと作業規模の見積もりが実施されている。
5）SS 管理組織（責任と権限、報告経路、他のプロジェクトまたは組織とのインターフェース）が確立されている。
6）SS 活動が監視され、SS に関する問題が報告され、分析され、解決されている。
7）SS 方針と供給製品またはサービスのための要件の合意が達成されている。
8）サプライヤの SS 活動が監視されている。

基本
プラクティスBP1 SS 目標と SS 基準の定義
ハザード／脅威に関する受容可能なリスクの限界が、組織の内外から課された SS 目標または作成された分析／開発方針として定義される。
また、SS 目標かつ／またはリスクの受容可能レベルが定義される。
BP2 SS ライフサイクルの定義
プロジェクトの目標、SS 基準、状況、複雑性に対して、適切な SS 活動のライフサイクルが定義される。
BP3 SS 計画の立案
SS 管理と SS 技術の活動は、SS 要求が識別され、それらの依存関係が決定され、それらの実装が計画され、そして、必要なリソースを識別されることを確認し、満足するために実装される。
BP4 統合された SS 活動の定義
製品開発、プロジェクトライフサイクル、支援プロセスが統合された SS 活動決定される。
BP5 スキル要件定義と責任の割り当ての決定計画された SS 活動を成し遂げるために必要なスキルが識別され、関連する役割の責任と権限と独立性が定義され、状況に応じて割り当てられる。
BP6 計画された SS 活動の実装
SS 計画で定義された活動が実装される。
BP7 SS 活動の展開の監視
SS 活動の展開が監視され、（計画からの）逸脱の是正が実施される。プロジェクトの SS 活動は監視され、作業成果物の SS に関するインシデントが識別され、SS 活動が報告され、分析され、完結さらに中止を管理する。
BP8 SS 要求と SS 方針の定義とサプライヤとの合意
サプライヤの SS 活動を監視するための方法と技術をサプライヤと合意する。サプライヤから供給された製品の SS を保障する方法の契約を締結する。
BP9 サプライヤの SS 活動の監視
サプライヤの SS 活動が、SS 要求に合致していることを監視し、報告する。
BP10 エスカレーションの仕組みの実装
SS 問題を解決するために、適切な管理層への上告が確実に実施されるためのエスカレーションの仕組みが構築され、保守される。

108
JISA Quarterly No.121 2016 Spring

プロセス ID

SSE.2

プロセス名

SS 技術

プロセス目的SS 技術プロセスの目的は、エンジニアリングプロセスのすべてのステージを通して SS を適切に達成することである。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
1）製品の関係するハザードおよび脅威が識別され分析される。
2）ハザードログが確立され保管される。
3）製品ライフサイクルを通じて SS が確立され、保守される。
4）SS 要求が定義される。
5）SS 統合要求が定義され、配置される。
6）SS 原則が、開発プロセスに適用される。
7）SS の変更要件の影響が分析される。
8）製品が SS 要求に対して検証される。
9）独立した SS の評価が達成される。

基本
プラクティスBP1 ハザードと脅威の識別使用条件や予見可能な誤用に関するハザードと脅威が識別される。
BP2 危害とリスクの識別
各ハザード／脅威に対して、（顕在する）可能性、影響の重大さを分析し、ハザード／脅威のリスクを評価する。
BP3 ハザードログの確立と保守
ハザード／脅威への対応のステータスが製品ライフサイクル全体を通して保守される。
BP4 SS の確立と保守
製品ライフサイクル中、段階的に SS を確立し、保守する。プロダクトとプロセス文書が、SS を裏付ける証跡として収集される。
注）SS の裏づけとは、「アイテムが SS 目標を実現しているということを具体的な証跡で明示すること」である。
ISO/IEC15504-1 3.3 項に「アイテムが示す証跡とその依存関係の集合は、リスクが許容される制約内でSS であると正当化すること」であると定義されている。
BP5 SS 要求の確立と保守
ハザード／脅威とリスクの分析結果と他の適用可能な対象に基づいて、製品ライフサイクルを通して SS 要求を確立し、保守する。
BP6 SS 完整性要求の決定
ハザード／脅威のリスク評価に基づき、各 SS 要求に対する SS 完整性要求を決定する。
注）SS 完整性要求とは、「SS 機能が確実に作動するために必要な要件を統合した要求事項のこと」である
つまり、単に SS 要求（SS 機能要求）を満足する SS 機能があるだけでは不十分ということを意味する。
BP7 SS 要求と SS 完全性要求の割り当て
SS 要求と SS 完全性要求は、アーキテクチャ、サブシステム、コンポーネントに割り当てられる。
BP8 SS 完全性要求を達成するための SS 原理の適用要求された SS 完全性要求の達成に関係する原理と方法が、製品ライフサイクル中適用される。
BP9 変更に対する SS 影響分析の実行
ハザード／脅威とリスクの要求変更の影響を分析する。変更要求と、その影響を受ける作業成果物を特定する。
BP10 SS の妥当性確認の実行
ハザード／脅威分析とリスク分析の結果に基づいて、SS 目標が正しく達成されることを確認する。
BP11 独立したアセスメントの実行要求された独立レベルに従って、製品ライフサイクル期間中のあらかじめ計画された時点で、プロセスと作業成果物に対するアセスメントが実施される。
BP12 市場問題への対策を提供できる体制の構築
製品を市場に供給し続ける間、市場で発生する問題への対策を提供可能な体制を維持する。

109

プロセス ID

SSE.3

プロセス名

SS 適格性確認

プロセス目的SS の適格性確認プロセスの目的は、外部リソースを活用して SS に関するソフトウェアまたはシステムを開発する場合に、戦略に従って外部リソースを適切に評価することである。
外部リソースの活用とは、サプライヤへの開発委託、製品に組み込むコンポーネントの購入、開発や管理に用いるツールの購入が該当する。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
1）外部リソースを活用するための、SS 適格性確認戦略が作成されている。
2）SS の適格性確認計画が作成され実行されている。
3）SS の適格性確認文書が記述されている。
4）SS の適格性確認報告が提出されている。

基本
プラクティスBP1 SS 適格性確認戦略の作成
適格性確認戦略を作成する。適格性確認戦略は外部リソースに対する品質要求を考慮するべきである。（SS に関係するソフトウェアやシステムに対して SS 要求への影響を決定する。）適格性確認戦略には、達成すべき
SS 目標、評価基準、確認結果に基づいた対処方法を含む。
BP2 外部リソースの完全妥当性確認の計画
外部リソースに対する SS 適格性確認活動を計画し、各外部リソースに対する適切な適格性確認方法を選択する。
BP3 外部リソースの適格性確認選択された適格性確認方法に従って、適格性確認を実施する。
BP4 SS 適格性確認結果の記録
SS 適格性確認結果を記録し、利害関係者に通知する。
BP5 SS 適格性確認結果の更新と保守
外部リソースを適用した製品／サービスが市場で運用されている期間内は、SS 適格性確認結果とその文書を更新し、保守する。

用語解説
・セーフティ（安全）受容できないリスクがないこと。
・セキュリティ
情報の機密性、完全性、可用性を維持すること。
・ハザード

べき目標
・SS 方針ハザード、脅威を回避、抑制するために取るべき活動の方針・完整性

人体に危害をもたらす原因となるシステムの故Integrity（ イ ン テ グ リ テ ィ） の 訳 語 で あ り、障。

「完全に整っていること」（JIS X 0160：2012）・脅威を意味する。セキュリティの分野ではこの言葉

セキュリティ上のリスクを生じる要因。
・リスク
危害の大きさと発生確率の組み合わせ。

を「完全性」と訳し、「正確さ及び完全さの特性」（JIS Q 27000：2014；情報が破壊されていないことという文脈でつかわれることが多い）・アイテムといった意味があるが、完整性と訳す場合はそ

開発対象

れとはややニュアンスが異なり、要求される事・サプライヤ柄が適切な水準で全体として抜かりなく実現さ

開発委託先
・SS 目標ハザード、脅威を回避、抑制するために達成す
110
JISA Quarterly No.121 2016 Spring

れていることを示すことが多い。

VSE セーフティとセキュリティの統合プロセス（VSE-SSE）
ISO/IEC TR 15504-10（セーフティ拡張）に対するセキュリティ再拡張の検討
第１版（2016 年 7 月 7 日）
VSE+SS 合同研究会
VSE+SS 合同研究会（以下、本研究会）では、 近年のソフトウェア製品に対するセーフティとセキュリ
ティの必要性の高まりに対して、VSE ソフトウェア開発へのセーフティとセキュリティ拡張の検討を行い、ISO/IEC TR 15504-10（セーフティ拡張）の内容を参考に、以下に示す「セーフティとセキュリティの統合プロセス（SSE：Safety and Security Extension）」を定義した。
なお、このプロセスは、ISO/IEC 15504-2 のフレームワークに基づき、ISO/IEC 15504-5 や業界特化版として策定されている Automotive SPICE 等の ISO/IEC 15504 派生モデルへのエクステンションとしても活用が可能である。
「セーフティとセキュリティの統合プロセス（SS：Safety and Security Extension）」は、「SS 管理」、
「SS 技術」、「SS 適格性確認」の３つのサブプロセスから構成される。

プロセス群：SSE（Safety and Security Extension）
・SSE.1：SS 管理
SS 目標を達成するために、ライフサイクル全体を通じて実施すべき SS 活動を計画し、その状況を監視し、逸脱があれば制御するためのプロセス。
・SSE.2：SS 技術
SS 目標を達成するために、製品に関係するハザードおよび脅威を識別し、それらを回避、抑制するための開発、検証、評価を行うためのプロセス。
・SSE.3：SS 適格性確認
サプライヤへの開発委託や外部購入など、外部リソースを活用してシステムを開発する場合に、外部リソースを適切に評価するためのプロセス。

1

プロセスID

SSE.1

プロセス名

SS管理

プロセス目的SS管理プロセスの目的は、セーフティおよびセキュリティの目標（SS目標）を満足するために、製品／サービスのライフサイクルを通じてSS管理活動を確立することである。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
１）SS達成の原則と基準が確立されている。
２）プロジェクトのためのSS活動の範囲が定義されている。
３）SS活動が計画され、実施されている。
４）SS活動を実施するために必要なリソースが識別され実装されている。
５）SS管理組織（責任と権限、報告経路、他のプロジェクトまたは組織とのインターフェース）が確立されている。
６）SS活動が監視され、SSに関する問題が報告され、分析され、解決されている。
７）SS方針と供給製品またはサービスのための要件の合意が達成されている。

基本プラクティスBP1 SS目標とSS基準の定義
ハザード／脅威に関する受容可能なリスクの限界が、組織の内外から課されたSS目
標または作成された分析／開発方針として定義される。
また、SS目標かつ／またはリスクの受容可能レベルが定義される。
BP2 SSライフサイクルの定義
プロジェクトの目標、SS基準、状況、複雑性に照らして適切な、ライフサイクル区分ごとのSS活動が定義される。
BP3 SS計画の立案
SS要求を満足するためにSS管理とSS技術の活動が識別され、それらの依存関係が決定され、それらの実装計画と、必要なリソースが識別される。
BP4 統合されたSS活動の定義
SS活動以外の面で見た製品開発、プロジェクトライフサイクル、支援プロセスに統合されたSS活動が決定される。

2

BP5 スキル要件定義と責任の割り付けの決定
計画されたSS活動を成し遂げるために必要なスキルが識別され、関連する役割の責
任と権限と独立性が定義され、状況に応じて割り付けられる。
BP6 計画されたSS活動の実装
SS計画で定義された活動が実装される。
BP7 SS活動の展開の監視
SS活動の展開が監視され、（計画からの）逸脱の是正が実施される。プロジェクトのSS活動は監視され、作業成果物とSS活動上のインシデントが識別され、報告され、分析され、インシデントの完結さらに今後の予防を管理する。
BP8 SS要求とSS方針についての利害関係者との合意
利害関係者間でSS要求とSS実施方針についての合意を確立する。また供給者から供給された製品のSSを確認する方法を合意する。
BP９ エスカレーションの仕組みの実装
SS問題を解決するために、適切な管理層への上申が確実に実施されるためのエスカ
レーションの仕組みが構築され、維持される。
BP10 市場問題への対策を提供できる体制の構築
市場に供給され、市場での利用／運用によって市場で発生するSS問題への対策を提供可能な体制を維持する。
SS問題への対策を提供する期間および対策の提供方法を定義し、市場に周知する。

3

プロセスID

SSE.2

プロセス名

SS技術

プロセス目的SS技術プロセスの目的は、エンジニアリングプロセスのすべてのステージを通してSSを適切に達成することである。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
１）製品の関係するSSに関するハザードおよび攻撃者からの脅威が識別され分析される。
２）ハザードログが確立され保管される。
３）製品ライフサイクルを通じてSSの論証が確立され、維持される。
４）SS要求が定義される。
５）SS完全性要求が定義され、割り付けられる。
６）SS原則が、製品ライフサイクルに適用される。
７）SSの変更要件の影響が分析される。
８）製品がSS要求に対して検証・妥当性確認される。

基本プラクティスBP1 ハザードと脅威の識別
SSに関して、システムの使用条件や予見可能な誤用に関するハザードと攻撃者からの脅威が識別される。
BP2 危害とリスクの識別
各ハザード／脅威に対して、（顕在する）可能性、影響の重大さを分析し、ハザー
ド／脅威のリスクを評価する。
BP3 ハザード／イベントログの確立と維持
ハザード／イベントの兆候とそれらへの対応の把握と記録内容の現状が製品ライフサ
イクル全体を通して維持・分析される。
BP4 利用状況の変化に対応できるSS要求の妥当性確認システムの利用条件や利用される環境の変化に対応して、またハザード／脅威の状
況の変化に対応してシステムが保守される可能性について、SS要求の妥当性を確認する。
BP5 SS要求の確立と維持
ハザード／脅威とリスクの分析結果と他の適用すべき事項に基づいて、製品ライフサ

4

イクルを通してSS要求を確立し、保守する。
注）「他の適用すべき事項」とは、法的要求、標準、規制、企業方針、顧客要求、
顧客及び利用者からのフィードバック、検証結果、品質保証に関わる所見、妥当性
確認結果、製造時の経験、設置と撤去時の経験、保守修理の経験、実地運用検討結果などである。
BP6 SS完全性要求の決定
ハザード／脅威のリスク評価に基づき、各SS要求に対するSS完全性要求を決定する。
注）SS完全性要求とは、「SS機能が確実に作動するために必要な要件を統合した要求事項のこと」である つまり、単にSS要求（SS機能要求）を満足するSS機能があるだけでは不十分ということを意味する。
BP7 SS要求とSS完全性要求の割り付け
SS要求とSS完全性要求は、アーキテクチャ、サブシステム、コンポーネントおよびサブプロセスに割り付けられる。
BP8 SS完全性要求を達成するためのSS原則の適用要求されたSS完全性要求の達成に関係する原則と方法が一貫して実現されるように、製品ライフサイクル中適用される。
BP9 変更に対するSS影響分析の実施
ハザード／脅威とリスクの要求変更の影響を分析する。変更要求と、その影響を受ける作業成果物を特定する。
BP10 SSの検証と妥当性確認の実施
ハザード／脅威分析とリスク分析の結果に基づいて、また、必要なSS活動に特化した検証と妥当性確認を実施して、SS目標が正しく達成されることを確認する。
BP11 SS活動の論証の論証と維持
製品ライフサイクル中、SSの論証が確立され、プロダクトとプロセス文書が、SSを裏付ける証跡として収集され維持される。
注）SSの裏づけとは、「アイテムがSS目標を実現しているということを具体的な証跡で明示すること」である。SSの論証とは、たとえば、SSに関するアシュアランスケースやセーフティケースなどである。

5

プロセスID

SSE.3 （本プロセス項目は、外注・部品ソフト利用・既製品開発環境利用等の
外部リソースを活用した開発が行われる場合に適用されるオプション項目である）

プロセス名

SS適格性確認

プロセス目的SSの適格性確認プロセスの目的は、外部リソースを活用してSSに関するソフトウェア
またはシステムを開発する場合に、戦略に従って外部リソースを適切に評価することである。
外部リソースの活用とは、サプライヤへの開発委託、製品に組み込むコンポーネントの購入、開発や管理に用いるツールの購入が該当する。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
１）外部リソースを活用するための、SS適格性確認戦略が作成されている。
２）SSの適格性確認計画が作成され実行されている。
３）SSの適格性確認文書が記述されている。
４）SSの適格性確認報告が提出されている。

基本プラクティスBP1 SS適格性確認戦略の作成
適格性確認戦略を作成する。適格性確認戦略は外部リソースに対する品質要求を考慮するべきである。（SSに関係するソフトウェアやシステムに対してSS要求への影響を決定する。）適格性確認戦略には、達成すべきSS目標、評価基準、確認結果に基づいた対処方法を含む。
BP2 外部リソースの適格性確認の計画
外部リソースに対するSS適格性確認活動を計画し、各外部リソースに対する適切な適格性確認方法を選択する。
BP3 外部リソースの適格性確認選択された適格性確認方法に従って、適格性確認を実施する。
BP4 SS適格性確認結果の記録
SS適格性確認結果を記録し、利害関係者に通知する。
BP5 SS適格性確認結果の更新と維持
外部リソースを適用し開発された製品／サービスを市場に供給し、市場で発生したSS問題への対策を提供する期間内は、外部リソースを適用し開発された製品／サービスのSS適格性確認結果を維持する。

6

[用語解説]・セーフティ（安全）受容できないリスクがないこと。
・セキュリティ
情報の機密性、完全性、可用性を維持すること。
・ハザード
人体に危害をもたらす原因となるシステムの故障。
・脅威
セキュリティ上のリスクを生じる要因。
・リスク
危害の大きさと発生確率の組み合わせ。
・アイテム
開発対象
・サプライヤ
開発委託先
・SS 目標ハザード、脅威を回避、抑制するために達成すべき目標
・SS 方針ハザード、脅威を回避、抑制するために取るべき活動の方針
・完全性
Integrity（インテグリティ）の訳語である。これを完整性と訳す時は、「完全に整っていること」（JIS X
0160:2012)を意味する。要求される事柄が適切な水準で全体として抜かりなく実現されていることを示すことが多い。セキュリティの分野ではこの言葉を「 完全性」 と訳し、「 正確さ及び完全さの特性」（JIS Q
27000:2014; 情報が破壊されていないことという文脈でつかわれることが多い)といった意味がある。完整性と訳す場合とはややニュアンスが異なる。

7

VSE セーフティとセキュリティの統合プロセス（VSE-SSE）
ISO/IEC TR 15504-10（セーフティ拡張）に対するセキュリティ再拡張の検討
第１版（2016 年 7 月 7 日）
VSE+SS 合同研究会
VSE+SS 合同研究会（以下、本研究会）では、 近年のソフトウェア製品に対するセーフティとセキュリ
ティの必要性の高まりに対して、VSE ソフトウェア開発へのセーフティとセキュリティ拡張の検討を行い、ISO/IEC TR 15504-10（セーフティ拡張）の内容を参考に、以下に示す「セーフティとセキュリティの統合プロセス（SSE：Safety and Security Extension）」を定義した。
なお、このプロセスは、ISO/IEC 15504-2 のフレームワークに基づき、ISO/IEC 15504-5 や業界特化版として策定されている Automotive SPICE 等の ISO/IEC 15504 派生モデルへのエクステンションとしても活用が可能である。

■SSE（Safety and Security Extension）「セーフティとセキュリティの統合プロセス（SSE：Safety and Security
Extension）」は、「SS 管理」、「SS 技術」、「SS 適格性確認」の３つのサブプロセスから構成される。
・SSE.1：SS 管理
SS 目標を達成するために、ライフサイクル全体を通じて実施すべき SS 活動を計画し、その状況を監視し、逸脱があれば制御するためのプロセス。
・SSE.2：SS 技術
SS 目標を達成するために、製品に関係するハザードおよび脅威を識別し、それらを回避、抑制するための開発、検証、評価を行うためのプロセス。
・SSE.3：SS 適格性確認
サプライヤへの開発委託や外部購入など、外部リソースを活用してシステムを開発する場合に、外部リソースを適切に評価するためのプロセス。

1

プロセスID

SSE.1

プロセス名

SS管理

プロセス目的SS管理プロセスの目的は、セーフティおよびセキュリティの目標（SS目標）を満足するために、製品／サービスのライフサイクルを通じてSS管理活動を確立することである。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
１）SS達成の原則と基準が確立されている。
２）プロジェクトのためのSS活動の範囲が定義されている。
３）SS活動が計画され、実施されている。
４）SS活動を実施するために必要なリソースが識別され実装されている。
５）SS管理組織（責任と権限、報告経路、他のプロジェクトまたは組織とのインターフェース）が確立されている。
６）SS活動が監視され、SSに関する問題が報告され、分析され、解決されている。
７）SS方針と供給製品またはサービスのための要件の合意が達成されている。

基本プラクティスBP1 SS目標とSS基準の定義
ハザード／脅威に関する受容可能なリスクの限界が、組織の内外から課されたSS目
標または作成された分析／開発方針として定義される。
また、SS目標かつ／またはリスクの受容可能レベルが定義される。
BP2 SSライフサイクルの定義
プロジェクトの目標、SS基準、状況、複雑性に照らして適切な、ライフサイクル区分ごとのSS活動が定義される。
BP3 SS計画の立案
SS要求を満足するためにSS管理とSS技術の活動が識別され、それらの依存関係が決定され、それらの実装計画と、必要なリソースが識別される。
BP4 統合されたSS活動の定義
SS活動以外の面で見た製品開発、プロジェクトライフサイクル、支援プロセスに統合されたSS活動が決定される。

2

BP5 スキル要件定義と責任の割り付けの決定
計画されたSS活動を成し遂げるために必要なスキルが識別され、関連する役割の責
任と権限と独立性が定義され、状況に応じて割り付けられる。
BP6 計画されたSS活動の実装
SS計画で定義された活動が実装される。
BP7 SS活動の展開の監視
SS活動の展開が監視され、（計画からの）逸脱の是正が実施される。プロジェクトのSS活動は監視され、作業成果物とSS活動上のインシデントが識別され、報告され、分析され、インシデントの完結さらに今後の予防を管理する。
BP8 SS要求とSS方針についての利害関係者との合意
利害関係者間でSS要求とSS実施方針についての合意を確立する。また供給者から供給された製品のSSを確認する方法を合意する。
BP９ エスカレーションの仕組みの実装
SS問題を解決するために、適切な管理層への上申が確実に実施されるためのエスカ
レーションの仕組みが構築され、維持される。
BP10 市場問題への対策を提供できる体制の構築
市場に供給され、市場での利用／運用によって市場で発生するSS問題への対策を提供可能な体制を維持する。
SS問題への対策を提供する期間および対策の提供方法を定義し、市場に周知する。

3

プロセスID

SSE.2

プロセス名

SS技術

プロセス目的SS技術プロセスの目的は、エンジニアリングプロセスのすべてのステージを通してSSを適切に達成することである。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
１）製品の関係するSSに関するハザードおよび攻撃者からの脅威が識別され分析される。
２）ハザードログが確立され保管される。
３）製品ライフサイクルを通じてSSの論証が確立され、維持される。
４）SS要求が定義される。
５）SS完全性要求が定義され、割り付けられる。
６）SS原則が、製品ライフサイクルに適用される。
７）SSの変更要件の影響が分析される。
８）製品がSS要求に対して検証・妥当性確認される。

基本プラクティスBP1 ハザードと脅威の識別
SSに関して、システムの使用条件や予見可能な誤用に関するハザードと攻撃者からの脅威が識別される。
BP2 危害とリスクの識別
各ハザード／脅威に対して、（顕在する）可能性、影響の重大さを分析し、ハザー
ド／脅威のリスクを評価する。
BP3 ハザード／イベントログの確立と維持
ハザード／イベントの兆候とそれらへの対応の把握と記録内容の現状が製品ライフサ
イクル全体を通して維持・分析される。
BP4 利用状況の変化に対応できるSS要求の妥当性確認システムの利用条件や利用される環境の変化に対応して、またハザード／脅威の状
況の変化に対応してシステムが保守される可能性について、SS要求の妥当性を確認する。
BP5 SS要求の確立と維持
ハザード／脅威とリスクの分析結果と他の適用すべき事項に基づいて、製品ライフサ

4

イクルを通してSS要求を確立し、保守する。
注）「他の適用すべき事項」とは、法的要求、標準、規制、企業方針、顧客要求、
顧客及び利用者からのフィードバック、検証結果、品質保証に関わる所見、妥当性
確認結果、製造時の経験、設置と撤去時の経験、保守修理の経験、実地運用検討結果などである。
BP6 SS完全性要求の決定
ハザード／脅威のリスク評価に基づき、各SS要求に対するSS完全性要求を決定する。
注）SS完全性要求とは、「SS機能が確実に作動するために必要な要件を統合した要求事項のこと」である つまり、単にSS要求（SS機能要求）を満足するSS機能があるだけでは不十分ということを意味する。
BP7 SS要求とSS完全性要求の割り付け
SS要求とSS完全性要求は、アーキテクチャ、サブシステム、コンポーネントおよびサブプロセスに割り付けられる。
BP8 SS完全性要求を達成するためのSS原則の適用要求されたSS完全性要求の達成に関係する原則と方法が一貫して実現されるように、製品ライフサイクル中適用される。
BP9 変更に対するSS影響分析の実施
ハザード／脅威とリスクの要求変更の影響を分析する。変更要求と、その影響を受ける作業成果物を特定する。
BP10 SSの検証と妥当性確認の実施
ハザード／脅威分析とリスク分析の結果に基づいて、また、必要なSS活動に特化した検証と妥当性確認を実施して、SS目標が正しく達成されることを確認する。
BP11 SS活動の論証の論証と維持
製品ライフサイクル中、SSの論証が確立され、プロダクトとプロセス文書が、SSを裏付ける証跡として収集され維持される。
注）SSの裏づけとは、「アイテムがSS目標を実現しているということを具体的な証跡で明示すること」である。SSの論証とは、たとえば、SSに関するアシュアランスケースやセーフティケースなどである。

5

プロセスID

SSE.3 （本プロセス項目は、外注・部品ソフト利用・既製品開発環境利用等の
外部リソースを活用した開発が行われる場合に適用されるオプション項目である）

プロセス名

SS適格性確認

プロセス目的SSの適格性確認プロセスの目的は、外部リソースを活用してSSに関するソフトウェア
またはシステムを開発する場合に、戦略に従って外部リソースを適切に評価することである。
外部リソースの活用とは、サプライヤへの開発委託、製品に組み込むコンポーネントの購入、開発や管理に用いるツールの購入が該当する。

プロセス成果このプロセスを適切に実装した場合の成果は、以下のとおりである。
１）外部リソースを活用するための、SS適格性確認戦略が作成されている。
２）SSの適格性確認計画が作成され実行されている。
３）SSの適格性確認文書が記述されている。
４）SSの適格性確認報告が提出されている。

基本プラクティスBP1 SS適格性確認戦略の作成
適格性確認戦略を作成する。適格性確認戦略は外部リソースに対する品質要求を考慮するべきである。（SSに関係するソフトウェアやシステムに対してSS要求への影響を決定する。）適格性確認戦略には、達成すべきSS目標、評価基準、確認結果に基づいた対処方法を含む。
BP2 外部リソースの適格性確認の計画
外部リソースに対するSS適格性確認活動を計画し、各外部リソースに対する適切な適格性確認方法を選択する。
BP3 外部リソースの適格性確認選択された適格性確認方法に従って、適格性確認を実施する。
BP4 SS適格性確認結果の記録
SS適格性確認結果を記録し、利害関係者に通知する。
BP5 SS適格性確認結果の更新と維持
外部リソースを適用し開発された製品／サービスを市場に供給し、市場で発生したSS問題への対策を提供する期間内は、外部リソースを適用し開発された製品／サービスのSS適格性確認結果を維持する。

6

[用語解説]・セーフティ（安全）受容できないリスクがないこと。
・セキュリティ
情報の機密性、完全性、可用性を維持すること。
・ハザード
人体に危害をもたらす原因となるシステムの故障。
・脅威
セキュリティ上のリスクを生じる要因。
・リスク
危害の大きさと発生確率の組み合わせ。
・アイテム
開発対象
・サプライヤ
開発委託先
・SS 目標ハザード、脅威を回避、抑制するために達成すべき目標
・SS 方針ハザード、脅威を回避、抑制するために取るべき活動の方針
・完全性
Integrity（インテグリティ）の訳語である。これを完整性と訳す時は、「完全に整っていること」（JIS X
0160:2012)を意味する。要求される事柄が適切な水準で全体として抜かりなく実現されていることを示すことが多い。セキュリティの分野ではこの言葉を「 完全性」 と訳し、「 正確さ及び完全さの特性」（JIS Q
27000:2014; 情報が破壊されていないことという文脈でつかわれることが多い)といった意味がある。完整性と訳す場合とはややニュアンスが異なる。

7