いま注目したい品質とは？ （その２） ー セキュリティ＆セーフティ － I PA / S E C 連 携 委 員 ソフトウェア品質説明力向上・普及WG委員 合同会社ソフデラ 代表社員 伏見 諭 1 発表者の経歴・背景 IPA/SEC 連携委員 ソフトウェア品質説明力向上・普及WG委員 SSE-CMMプロジェクトを推進した(2000-2004) その関係で、ISSEAという米国に本部のある団体の役員をしたことがある 関連して、CISSP資格制度の日本での初期立ち上げや日本の情報セキュリティ監査制度の初期推進にたず さわった ISO/IEC JTC1で SC7（ソフトウェアエンジニアリングの委員会）からSC27（ITセキュリティの委員会）へ のリエゾン（連携）オフィサーを7年くらいやっている 東海大学講師 合同会社ソフデラ 代表社員 2 はじめに セキュリティ／セーフティの課題は、いま、社会の差し迫った問題ですが、「品質」 の問題でしょうか？ Yes No （どちらともいえない） この発表では、上記について、基本的にはYesだという事情を詳しく探ります。 また、 セキュリティ／セーフティを品質課題として扱う際の基本的なアプローチについて、概要を整 理して示します。 セキュリティ／セーフティと品質課題を連携して現場に示すにはどのようにすればよいかを 検討します。 3 セキュリティ問題の広がり インシデント事例は多数ある・・・ PCへの侵入（マルウェア問題） システムの脆弱性をつく攻撃（不正アクセス問題、ワーム問題、トロイの木馬によるコンピュータ乗っ取り問題） ソーシャルエンジニアリング ホームページ攻撃 盗聴 不正に仕組まれたデータによる攻撃（アプリケーション脆弱性） 制御システムへの攻撃 組込み系システムへの攻撃 標的型攻撃、APT攻撃 etc. 開発・運用で、担当者がそれらを全体としてどうとらえ、また有効に対処したらよいかが問題 ときに、「セキュリティはそれの専門家による脅迫」といわれることもあるが、そういうわけでもなく、真面目 な対策が必要。 個人や、個々のチームでは対応しきることが難しいので、誰かがやってくれている（「うちの会社のセキュリ ティ部門は口うるさいし・・・」）と思いがちだが、そういうことはない。 4 セキュリティを取り扱う視角 セキュリ ティ対策 古典的アプローチ（歴史的にはGMITS等） 攻撃 防衛策 情報資産 （被攻撃資産） （事故・災害を含む） 脆弱性 リスク／インシデント リスク対応 インシデントレスポンス 5 セキュリティを取り扱う視角（続き） セキュリティ的に隙のないソフトウェアはあるか？ あるかもしれないが、経験的には、非常に難しいと もちろん、「だから、仕方ないと言って手をつけない」ではない ぎりぎりどこまで隙をなくす努力をするかが問題 「隙」とはなに？ リスク認識全般の隙 攻撃可能性が適切に認識されていない。設計された防御策があまい。 脆弱性を作りこむ隙 プログラミング、テスト、運用設定があまい。 スキルと知識の問題 現実のセキュリティリスクの水準と多様性の具体的な理解と、それに対処 できる個別スキルの水準が追い付かない。 製品、システムの企画プロセスや運用プロセスも視野に入れた、広い意味では、ライフサイクルを通じ たシステムの品質の問題といえる。 6 世の中はダイナミックかつオープンな ので、 完璧なセキュリティ品質のシステム（たとえば、アクセス制御で完璧に管理されたインター ネット）があると仮定することはできない 当然、セキュリティ的には、さまざまなアプローチの多重防御の考え方が必要となる。 セキュリティは結果主義であり、リスクを防ぐために、可能なことはすべて有効に動員する セキュリティ ニーズ セキュリティ装置・機能 による防御（ファイア ウォール等） セキュリティ理論・ノウハウによ るによる防御（アクセス制御、暗 号、署名等およびプロセス品質） セキュリティ運用・設定によ る防御（セキュアな設定ノウ ハウ、ハードニング等） システム一般（製品とプロセス）の品質 7 SQuaREではセキュリティをどう扱うか？ 製品品質 セキュリティ（品質特性） データ品質 信頼性（品質特性） 機密性 機密性副特性 成熟性副特性 インテグリティ副特性 可用性副特性 否認防止性副特性 障害許容性副特性 可用性 責任追跡性副特性 回復性副特性 回復性 一貫性 追跡可能性 真正性副特性 etc. 情報セキュリティ管理策という観点で見ると、 SQuaREはそのITシステム部分に焦点を当てている システムが期待（設計）通りに、かつ有効に 動くためには、 SQuaREの他の多くの「品質 特性」も幅広くセキュリティに関連する 利用時の品質の 「信用性」も関連 8 製品品質のみ掲載。 （参考）副特性の定義 副特性 赤字は補足コメント。 緑字・青字は飛ばして読ほうが頭に入 りやすい。 定義(JIS X 25010から） 機密性 製品又はシステムが，アクセスすることを認められたデータだけにアクセス することができることを確実にする度合い。 インテグリ ティ コンピュータプログラム又はデータに権限をもたないでアクセスすること又は 修正することを，システム，製品又は構成要素が防止する度合い。 否認防止性 事象又は行為が後になって否認されることがないように，行為又は事象が 引き起こされたことを証明することができる度合い。 責任追跡性 実体の行為がその実体に一意的に追跡可能である度合い。 真正性 ある主体（人、プロセス）又は資源（リソース）の同一性(アイデンティティ）が主張したと おりであることを証明できる度合い。 可用性 使用することを要求されたとき，システム，製品又は構成要素が運用操作可 能及びアクセス可能な度合い 回復性 中断時又は故障時に，製品又はシステムが直接的に影響を受けたデータを 回復し，システムを希望する状態に復元することができる度合い。 ログ、署名、 フォレン ジックなど アカウンタ ビリティ 9 一般的な低品質がセキュリティに関連する例 パスワードファイルや個人データ格納ファイル等が外部から検索ソフトで アクセスできる。 パフォーマンスの悪いアンチマルウェアソフトは、現場利用者がOFF設定 にしてしまう。 キャパシティがぎりぎりのシステムが容易にDOS攻撃（サービス妨害攻 撃）に会う。 良くないヒューマンインタフェースが誤操作やデータ誤入力を引き起こす。 メモリ管理の不適正により、プログラムが停止し、その結果、データファ イルが破壊される。 etc. 10 制度・法令との関係では・・・ 企業組織全体で のセキュリティ ＩＳＭＳ、ＪＳoＸ法、個 人情報保護法対応 を考慮 製品・運用システ ムのセキュリティ コモンクライテリア対 応を考慮 プラント等のセ キュリティ 制御システムセキュ リティ対応を考慮 制度対応などが必 要な場合は、対応 した深堀りが必要 11 セーフティ問題の重大化 ＩｏＴ時代とは、あらゆるモノやサービスがＩＴで制御され（特にソフトで制御され）、相互に干渉 する時代だともいえる われわれの生活と産業を支えるモノやサービスは、見えてこそ安全という面があるが、ソフト ウェアは見えにくく、また存在があまり意識されない それらの結果、ソフトウェアの欠陥が重大事故につながる危険性が増している ソフトウェアの欠陥に対する許容度を極度に厳密化する必要がある ヒューマンインタフェースの品質問題も大きくなる 専門家だけが扱うシステムが、一般利用者も扱うシステムに進化すると、話はますます深刻となる 一般にシステムのステークホルダ全般のセーフティを幅広く検討・対処すべき場面が拡大する（環境 や経済損失を含むリスクも考慮） 12 図にすると・・・ 製品／サービス提 供側の人間系 ・開発 ・提供 ・保守 製品／サービスを 受ける人間系 直接利用者 システム ソフトウェア 提供 間接利用者 いろいろな場面／ステークホルダのセーフティ 健康・身体だけでなく環境・経済リスクも考慮 13 どこで典型的に問題となるか 医療機器、医療システム、製薬システム 生活支援ロボット、産業用ロボット 交通機関（移動体、管制システム、その他） 家電 プラント スマートシティ etc. 14 セーフティのリスク管理サイクル リスクへの対応 リスク緩和策 リスク分析 と評価 ハザード／イン シデント特定 リスク見積り No 受容可能か？ Yes 回避／転嫁等 リスク評価 実施 15 SQuaREではセーフティをどう扱うか？ リスク回避性（品質特性） 経済リスク緩和性副特性 健康・安全リスク緩和性副特性 ソフトウェアというより、 システム全体としての セーフティを見ている ビジネス、マネー、経済全体, etc 医療/医薬品、食品、化学物質、 機械、運輸 etc. 環境リスク緩和性副特性 大気、排水、廃棄物 etc. 計測・制御、表示情報、入出力（交換）情報、評価・分析、etc. 16 製品全体とソフトウェアのセーフティの強固化 製品・システムのセーフティ（しっかりリスク分析） ソフトウェアのセーフティ要求事項（強化） 理解・補足・ フィードバック 現場のプロセス（厳密化） 17 現場的には、開発のプ ロセスでの製品品質の 測定も重要 セーフティの測定 ＳＱuaREでは、品質特性、副特 性は品質測定と結びついている 「リスク回避性」は、利用時品質であり、利 用者サイドから評価される位置づけ セーフティ測定量の例 システム利用で影響を受ける対人安全率 ＝ ハザードにさらされる人数 全利用人数 18 セキュリティ／セーフティを現場でどう 品質として取り扱うか(1/3) ソフトウェア製品とプロセスの品質全般が悪いと、セキュリティや セーフティの方針があっても実装されない、実現されない可能性が 大となる その認識が基本として必要 19 セキュリティ／セーフティを現場でどう 品質として取り扱うか(2/3) 品質問題として統一的に扱うべき場面がある 設計レビューで 利用者のセキュリティやセーフティにかかわる利用場面や、セキュリティ攻撃対処などを「設計 のもれ」の問題としてレビューする。 コーディング規約順守の検査で 静的解析ツールやレビューで統一的に検証する。 テストについて 要求事項適合の検証を品質を含めて漏れなく行う。 テスト設計をできるだけ上流側から対応する方針で、品質テスト設計もシステム（ソフトウェア） 設計時点で大筋を考慮する。 20 セキュリティ／セーフティを現場でどう 品質として取り扱うか(3/3) セキュリティ／セーフティ特有の取り扱いをすべき場面がある 参照すべきガイドライン等に固有のものがある。 安易な暗号化技術等がつかわれていないか、技術的専門性を踏まえたレ ビュー等が要求されることがある。 テスト等で、セキュリティ/セーフティ特有のテスト手法を要求されることが あり、それに対応するリソース等を確保すべき場合がある（ペネトレーション テスト、脆弱性チェック等）。 形式手法等の利用が要求される場面もある（26262規格やコモンクライテ リア認証のある場合に）。 セキュリティやセーフティに関わる認証を求める場合には、その要求事項 に対応する必要がある（同上）。 21 「手引書」での取扱いと活用(1/2) 「手引書」(*)での取扱い 「つながる」システムでのセキュリティ／セーフティの重大化の確認 セキュリティとセーフティのアーキテクチャ設計がしっかりしていることが最 初のステップとして重要 セキュリティとセーフティのそれぞれの特色と詳細課題 セキュリティとセーフティの要求事項設定のためのリスク管理の解説 (*) 「つながる世界のソフトウェア品質ガイド（仮称）」 IPA/SECホームページにて「3月公開予定」 22 「手引書」での取扱いと活用(2/2) 活用方策の期待値 「手引書」により、コンセプト、概要、他の制度/規格との関係を把握 「SQuaRE概要書」 (*)により、セキュリティ副特性の留意事項を把握 個々の現場実態/プロジェクトニーズや、必要な制度対応との関係で、さら にセキュリティ／セーフティ対応の必要内容を深堀りする セキュリティ/セーフティの品質要求事項、機能要求事項をまとめ、実現す る 組織のプロセスを、セキュリティ/セーフティを日常的に取り扱えるように改 善していく (*) 「SQuaRE品質モデルとその応用（仮称）」 IPA/SECホームページにて「3月公開予定」 23 おわりに ＩＴシステムの開発ではしばしば、業務や製品の利用者に提供する利便性に関 する機能だけが要求事項になることがあります。 品質要求は、典型的な非機能要求として、上のような要求事項の一環に組 み込まれるべき課題として取り上げられてきました。 時代は、非機能要求の一部としてのセキュリティ/セーフティというより、セ キュリティやセーフティというものを直接要求しています。 しかし、これらの観点を統一的に有効にＩＴシステムで実現していくべきことは 当然です。 24
© Copyright 2024 ExpyDoc
