Technical Information

非機能テストにおけるベリサーブの取り組みと、IoTのセキュリティ要求への対応

asset_approach_column_advanced-tech-security01_hero.jpg

株式会社ベリサーブ ソリューション事業部 事業部長 桑野 修

当社は、検証専門企業として2001年に設立した当初から、専門性を追求する分野の一つとして「非機能要件」の検証に、携わってまいりました。昨今のIoT関連製品の普及に伴い、「性能」や「セキュリティ」をはじめとした「非機能要件」に関する検証のご相談が増加の一途をたどっております。
そこで、本稿では「非機能要件」の中でも特に重要視されている、「セキュリティ」を中心に、当社での取り組みをご紹介いたします。

1.非機能要件について

1-1.非機能要件とは

「非機能要件」という言葉については、耳慣れない方もいらっしゃるかもしれません。ソフトウェア製品・システムには満たすべき振る舞いが「要求仕様書」などで明示的に定義される「機能要件」と、システム全体が満たすべき特性として期待されるが、必ずしも明記されていない「非機能要件」の2つが存在します。本来、非機能要件の実現には「システムアーキテクチャ設計」などの「最上流工程」での考慮が必要となるにも関わらず、暗黙の要件として見落とされてしまうことが少なくありません。実際に非機能要件に関する開発の手戻りは非常に大きく、ユーザーと開発者間でのトラブルを引き起こす要因の一つになっています。

1-2.非機能要件の重要性の高まり

ネットワークの発達によりシステムの規模やユーザー数の増大、多種多様のデバイス同士がつながることで、想定外の使われ方が出てくることから、非機能要件をきちんと考慮した開発がよりその重要性を増しています。2008年ごろからユーザー側、ベンダー側双方の立場を考慮した「非機能要件要求仕様定義ガイドライン(日本情報システムユーザー協会)」、「非機能要求グレード(2010年からはIPAより発行)」といった非機能要件についての要求ガイドラインが発表されるようになりました。品質特性についても、ISO/IEC 9126-1(※1)から、ISO/IEC 25010(※2)への改定時、「機能性」の副特性として定義されていた「セキュリティ」が、副特性から主特性として格上げされたことからも、その重要性が伺えます。このような流れからソフトウェアの開発に携わる企業は、ガイドラインや標準化をもとに、品質面でのリスクを十分に考慮する必要に迫られています。

※1 ISO/IEC 9126-1:ソフトウェア製品の品質-第1部 品質モデル
※2 ISO/IEC 25010:システム及びソフトウェア製品の品質要求及び評価(SQuaRE)-システム及びソフトウェア品質モデル

2.非機能要件に対するアプローチ

当社では、非機能要件の品質に対する関わり方として、主に「性能」「セキュリティ」の2つの側面よりアプローチを行っています(表1)。非機能要件については、テスト工程から対策を行うのではなく、要求・要件整理やレビューなどの活動を通して、開発の上流工程からテストエンジニアとしてがプロジェクトに関わるケースも増えてきました。テストプロセスを開発プロセスと並走させることにより、早い段階で課題を検出することが可能で、プロジェクトの効果的なリスク回避につながっています。

当社における非機能要件に対するアプローチ

表1 当社における非機能要件に対するアプローチ

3.セキュリティ要件に対する取り組み

図1は、IT、IoTを取り巻く代表的な脅威と、それに伴うセキュリティ基準の開始時期を表しています。インターネットの普及をきっかけに、
2000年頃より情報セキュリティの基準が設けられるようになりました。しかしIoT機器の普及により、機器同士やIoT機器とWebサービスの接続が行われるようになってきたことで、新たなセキュリティリスクが急増しています。
ITサービス・製品の開発に携わる事業者様、とりわけ標準化のスピードが速い自動車・車載分野を中心に、新たなセキュリティ基準の策定および適用が急速に進んでおり、多くの事業者様がその対応に苦慮されております。

セキュリティの脅威と対策の変遷

図1 セキュリティの脅威と対策の変遷

そこで、当社でもセキュリティ基準の準拠のご支援を行っている、代表的なセキュリティ基準や業界の動向についてご紹介いたします。

① PCI DSS

PCI DSSとは、Payment Card Industry Data Security Standardの略で、VISA、MasterCardなどをはじめとするペイメントカードブランド5社が展開しているセキュリティプログラムの拠り所となる、国際的なデータセキュリティ基準です。
2006年9月に公開後、改定が繰り返され、現時点では2018年5月に改訂された3.2.1版が最新版となっています。この基準にはセキュリティ要件と、具体的なテスト方法が記載されているため、カード業界だけでなく、機密性の高いデータを保持するあらゆるシステムのセキュリティに関する要件抽出に役立ちます。また、さらなるクレジットカードのセキュリティ強化を目的として、すべてのカード事業者についてはPCI DSS準拠が義務化されるようになりました。

② CC認証-JISEC

CC(コモンクライテリア)認証とは、IT製品に対するセキュリティ評価の国際標準規格を指します。CCは1999年にISO標準(ISO/SEC 15408)に制定されており、車載などの業種別セキュリティガイドラインでも広く利用されています。
日本ではJISEC(Japan Information Technology Social Evalution and Certification Scheme)と呼ばれる、IT関連製品のセキュリティ機能の適切性・確実性を、第三者(評価機関)がCCに基づいて評価し、その結果を認証機関が認証する制度があります。この制度は主に政府調達に利用されています。JISECよりCC認証を受けた場合、その認証はCCRA(CC国際認証アレンジメント)加盟国17カ国と、14カ国受入国からも相互認証を受けることが可能です。

③ 自動車・車載分野における動向

組込みソフトウェア製品領域の中で、セキュリティ対策の具体化が最も進んでいる分野として「自動車・車載」の分野が挙げられます。現在、自動走行やコネクテッド化も視野に入れたセキュリティ対策に関する国際標準 ISO21434の策定が進められており(DIS版2020年2月発行済み。2020年内に正式版策定予定)、OEM(完成車メーカー)を中心に、CCなどを活用したセキュリティ要件の明示化が自主的に進められています。このような動向に伴い、Tier1(一次請サプライヤ)をはじめとした各サプライヤについても、セキュリティ要件に対する対応の検討・実施についての説明責任が伴うようになりました。これらの対応については、お客様からのご相談も多く、検証の立場よりご支援を行っている分野となります。

④ セキュリティ運用についての課題

セキュリティ要件の新たな動向として、SIRT(Security Incident Responce Team)組織の立ち上げを課題とされているお客様が増えています。背景としては、プロダクトの開発にOSSを利用するケースなどが増えてきており、自社製品の中に組み込まれたOSSの脆弱性がリリース後の運用時に見つかるケースなどが増えてきたためです。情報システムに対する対応組織であるCSIRT(Computer Security Incident Responce
Team)の普及はここ5~10年で進んできましたが、IoT機器の普及に伴い、組込み製品に対する対応組織であるPSIRT(Product Security
Incident Responce Team)の立ち上げを急がれるお客様が増えています。組織の立ち上げに関するお客様の課題は、概ね次のようなものに分類されます。

a.PSIRT 組織構築・ガイドライン策定
b.付帯業務の効率化
c.脆弱性管理運用

当社では、これらの課題に対し、製品を構成するソフトウェアのBOM(部品表)の整備や、ナレッジの集約などのご提案を通して、SIRT組織の立ち上げや、運用効率化のためのシステム整備および運用のご支援を行っております。

4.おわりに

IoT技術の進歩と普及により、非機能要件の中でも特にセキュリティのリスクは飛躍的に高まっています。そのセキュリティリスクを回避するために、さまざまな分野において色々な規格や基準が設けられ、それが常に改変されているのが現状です。当社は、それらのトレンドを常に取り込みながら、適切なサービスやソリューションを考えて、お客様のご要望にお応えして参ります。


この記事をシェアする

Facebook  Twiter