セキュリティの知識を共有するセキュリティパターン(2018/6/15)

Copyright (C) 2018 National Institute of Informatics, All rights reserved.
第34年度(2018年度)ソフトウェア品質管理研究会
第2回例会演習コースⅢ「セーフティ&セキュリティ開
発」
セキュリティの知識を共有する
セキュリティパターン
２０１８年６月１５日
吉岡信和
国立情報学研究所

2
https://www.itsgila.com/tipsgates.htm

演習：オフィスの設計
 あなたは建築士です。
 オフィスの設計を頼まれした。
オフィスの要求
 顧客：ゆるキャラの企画デザイン会社
 セミナールーム：定期的にゆるキャラセミナーを開催
 受付：しばしばお客さんが訪問し、打ち合わせする
 １００平米程度の平屋の一軒家
 裏手に駐車場、表にゲスト用駐車場
 研究開発部門：３名
 セールス部門：２名
 スタッフ：２名
 クリエティビティを高めたい！
 企画書は大事な資産です！
http://www.narukuma.com/株式会社デンソー名古屋オフィス/
クリエティブでセキュアなオフィスを設計してみましょう
個人演習：１０分
3

ネット社会の光と影：生活への浸透
情報通信技術が生活基盤の一部に
 ビジネスでの活用
 オンライントレード
 受発注
 生活に密着したサービスの普及
 オンラインショップ
 お財布携帯
 ネットバンク
 コンテンツ配信
生活はますます便利に
デジタルの価値が向上
4

ネット社会の光と影：ネット被害の拡大
 コンピュータウイルスの蔓延
 スパイウェアなどにより、個人情報・認証情報の流出
 迷惑メールの蔓延
 読みたいメールより迷惑メールの方が多い！
 マルウェアによるＷｅｂサーバへのアタック
 個人情報を盗むホームページ（フィッシングサイト）に差し替えられる！
 迷惑メールの踏み台サーバにされてしまう！
 全世界から攻撃される可能性：ネット社会に国境はない
 被害が社会問題まで発展
 規模・額が年々増大
 社会活動が脅かされる
 セキュリティ対策は面倒・不便
 ウイルス対策ソフトなしにはパソコンが使えない！
 ウインドウアップデートがわずらわしい
 重要なメールが迷惑メールボックスに入っていた！
5

セキィリティの脅威と
その変遷
6
ハクティビズム：
社会的・政治的な主張のもとに、
ハッキング活動を行うこと
情報セキュリティ10大脅威 2018, IPA
引用：IPA, 2016年版情報セキュリティ10大脅威,
https://www.ipa.go.jp/security/vuln/10threats2016.html

生活密着型情報インフラ vs. ネット被害の拡
大
便利
被害
便利な機能を便利に使えるようにする必要がある
安心
セキュリティ
怖い
悪用安全
面倒
便利と安全のバランスが取れたセキュリティが重要
使いづらい
コスト
攻撃
リスク
7

Security is important but…
https://imgur.com/gallery/mhyex
What does it protect?
Is the protection appropriate?
Against whom?
8

セキュリティとは？
 広辞苑の定義
安全、保安、防犯
 コンピュータセキュリティ（ウィキペディア（Wikipedia））
1. コンピュータを災害、誤用および不正な利用からコンピュ
ータシステムを守ること
2. ハードウェア、ソフトウェア、データのいずれについてもそ
の機密性、完全性、可用性を維持すること
 セキュリティ工学分野におけるセキュリティの定義
 悪意のある攻撃、およびその被害からシステムを守ること
※災害、誤用は、セキュリティ技術の範囲外⇒セーフティとし
て扱う
※悪意があるないにかかわらず同じ被害をこうむる可能性が
ある
⇒ 同じ技術で対策できる可能性がある
9

セキュリティは目的ではない
【セキュリティの特徴】
 それ単独で価値のある機能・サービスではない
 使いたい機能・サービスを安全にするために存在
例）ウイルス対策ソフトだけを使いたい人はいない
 価値のあるものを攻撃から守ってくれる
例）個人情報が盗まれるのを守ってくれる
 なくても困らないことがある
例）ウイルスがいなければウイルス対策は不要
例）個人情報を入力しなければ守る必要もない！
 被害にあわないと効果が分からない！（矛盾：パラドックス）
 セキュリティは、被害をなくす、もしくは最小限にとどめる（リスク回避）手段
セキュリティを強化する ⇒ 被害がなくなる ⇒ セキュリティの効果が体感できない！
セキュリティは不要と錯覚
 起きないことに対して対価を支払う
参考：保険は、起きた被害を最小に食いとどめる
 セキュリティの必要性が理解しにくい
10

セキュリティの難しさ
 考慮する範囲が広い
 さまざまなことを考慮する必要がある
 サービスの中だけではなく、それがおかれている状況も重
要
 完璧な安全はない
 セキュリティと利便性はバランスが大事（トレードオフ）
 セキュリティはタダではない
 セキュリティ強化にはコストがかかる
 起こりえる被害を優先して考慮する必要がある
 漏れ・抜けにより被害が拡大
 もっとも脆弱な部分（セキュリティホール）が狙われる
 セキュリティ機能の使い方を間違えると標的になる
11

セキュリティを考える上でのポイント
 セキュリティの考慮・保証範囲を明確にする
 どこまでの被害を防ぐか？
 最小限のコストで最大限のサービスを提供
 被害の分析、要求の優先付けが重要（セキュリティ要
求工学）
 想定した範囲でもれ・抜けがないようにする
 対策は十分か？漏れがないか？
 セキュリティの要求を満たしているか？
 想定したセキュリティレベルは保たれているか？
これらを保証するための技術（セキュリティ工学）が
必要
12

セキュリティ工学とは？
Security engineering is a specialized field of engineering that deals with the
development of detailed engineering plans and designs for security features,
controls and systems. [wikipedia]
セキュリティ工学とは、セキュリティの特性、制御やシステムのための綿密な
計画や設計などの開発を取り扱う工学分野である
Security engineering is about building systems to remain dependable in the
fact of malice, error, or mischance. As a discipline, it focuses on the tools,
processes, and methods needed to design, implement, and test complete
systems, and to adapt existing systems as their environment evolves. [Ross
Anderson: Security Engineering]
セキュリティ工学とは、悪意や誤り、不運があってもシステムをディペンダブ
ルに構築することである。学術領域としては、特に、ツールやプロセス、完全
なシステムを設計、実装、テストする際に必要とされる手法、環境の進化に
対して既存のシステムを適応させるための手法などが中心である。
13

セキュリティ工学の重要性
 最初からセキュアに作らないと脆弱性は取り除けない
 脆弱性の多くは、プログラミングエラーが原因
 要件、設計のエラーも無視できない
 運用だけでは防げない！
※脆弱性対策情報データベースJVN iPediaの登録状況 [2018年第1四半期（1月～3月）]
https://www.ipa.go.jp/security/vuln/report/JVNiPedia2018q1.html
※ソフトウェア製品の企画・設計段階から情報セキュリティを考慮する必要がある。
14
要求・設計レベル
の不都合

セキュリティ工学の課題
【課題①】複雑性
 セキュリティに関する関心ごとが多い
 分析すべき情報：資産、脅威、対抗策、機能要件、根拠･･･
 関心ごとがお互い複雑に関連、開発プロセスに横断
 対抗策の妥当性、正当性、機能要件の完全性
 考慮する範囲が不明確
 脅威の範囲、前提条件
【課題②】状況の変化
 新しい攻撃への早急な対応が必要
 攻撃方法は急速に広がる
 システムを取り巻く環境の変化
 実行環境の変化（モバイル等）、利用者の変化
【課題③】トレードオフ
 セキュリティの実現コストが大きい：
範囲、優先度をつけた実施が必要
 メンテナンス性、ユーザビリティなど他の特性とのトレードオフ
妥当性、一貫性の
確保が困難
15

セキュリティに関する関心ごと
 資産(Asset): 組織や人が価値があると認めることができる情報、ま
たは、リソース
 ステークホルダ(Stakeholder): 資産に特定の価値を見出す組織や人
 セキュリティ目標(Security objective): 脅威に対する安全の要求を満
たすための宣言・ゴール
 脅威(Threat): 資産に対する安全が脅かされる可能性があること
 攻撃(Attack): 資産の安全性を破壊する行為
 攻撃者(Attacker): 攻撃を実行する実体
 脆弱性(Vulnerability): 資産に関するセキュリティを破ることができる
欠陥や弱点
 対策(Countermeasure): 脆弱性や攻撃に対してアセットを保護するた
めの行為
 リスク(Risk): 攻撃が成功する確率の高さ×その時の被害の大きさ
16

機能要求
セキュリティ機能要求
要求
制約
アプリケーションの
ビジネスゴール
他の品質の制約：
信頼性、ユーザビリティなど
セキュリティ要求
セキュリティ目標
資産（asset）
システムアーキテクチャ
実装となる
制約となる
アーキテクチャ
マネージメント
制御原則
ゴール
操作となる
他の品質のゴール：
信頼性、ユーザビリティなど
導出される
運用となる
導出される
権限の委譲導出される
操作となる
要求
ゴール
クラス
依存関係
継承
凡例
システムとセキュリティの関心ごと
参考：[C.Haley他, Security Requirements Engineering]
印刷前に認証が必要
（秘）文書
（秘）文書を
組織外に見
せない
ＩＤカードによる
本人認証
17

設計に関連するセキュリティの関心ごと
利用者機能
脅威所有者
アクター
攻撃者
運用環境
前提条件
セキュアな機能
資産
システム設計
利用者限定印刷
印刷物
持ち出し
印刷機能
社内ＬＡＮ
社内ＬＡＮでは盗聴できない
（秘）文書
セキュアな機能を設計するにはさまざまな考慮が必要
利用する
満たす
満たす
実施
満たす
起こる
脅威所有する
防御する
制御する
実施
印刷前に認証が必要
セキュリティ
目標
（秘）文書を
組織外に見
せない
対抗する
セキュリティ要求
ＩＤカードによる
本人認証
参考：[K.Taguchi他, Aligning Security Requirements and Security Assurance Using the Common Criteria]
18

 分析すべき情報：資産、脅威、対抗策、機能要件、根拠･･･
 関心ごとがお互い複雑に関連、開発プロセスに横断
 対抗策の妥当性、正当性、機能要件の完全性
 脅威の範囲、前提条件
 攻撃方法は急速に広がる
 実行環境の変化（モバイル等）、利用者の変化
 セキュリティの実現コストが大きい：
範囲、優先度をつけた実施が必要
 メンテナンス性、ユーザビリティなど他の特性とのトレードオフ
セキュリティ工学での解決
モデル駆動開発
ゴール指向分析
エージェント指向分析
アスペクト指向開発
形式手法
コーディング規則
ソフトウェア工学を応用
…
Fuzz Testing
19

攻撃に強いソフトウェアを作るには？
http://www.etaoist.org/taoist/media/k2/items/cache/8b6e33345ac8d5ffd9cf0d107a7d9e9d_XL.jpg
20

攻撃に強いソフトウェアを作るには？
まず相手を知り、身の程を知る
知彼知己百戦不殆：
彼を知り己を知れば百戦して殆（あや）うからず（兵法書『孫子』）
中国の春秋時代の武将、孫武
価値のあるサービスに大きな被害が起きないように対策を講じる
相手を知り、身の程を知る
攻撃者・攻撃を知る
リスクを知る
価値のあるサービス・資産を知る
被害を知る
脆弱性を知る
21

セキュリティの考慮・保証範囲を明確に
する脅威に基づく分析が有効
 脅威のない対策は不要
 対象とする脅威が明確になれば、対策範囲も明確になる
 対象とする脅威は？
 被害が大きく、起こりえる脅威を優先
 最小限のコストで最大限のサービスを提供
リスクを知る
被害を知る
脆弱性を知る
脅威を知る
被害を知る
どれくらい
の価値？
どれくらいの
被害？
どれくらい
の頻度？
22

23
絶対に、知らない人物や不審な人物に、
カードの裏面、シートの表面またはE
メールに記載されているAmazonギフ
ト券の番号（ギフト券番号）を教えない
でください。

脅威と被害を分析する技術
 攻撃ツリー
木構造で攻撃の詳細をブレイクダウン
実際にありえる攻撃かを評価
対策方針に利用
 ミスユースケース
攻撃やその状況をモデル化（図示）
 被害の分析手法：
FMEA（Failure Mode and Effect Analysis）
 故障形態、その影響、程度、頻度、検出しやすさで数値で表現、重要度をランク付け
例）
振り込み詐欺、振込み機能の悪用、影響：大†
、しばしば、あとで発見 ⇒ 重要度：大
携帯盗難、お財布機能の悪用、影響：大、しばしば、すぐ発見 ⇒ 重要度：大
商品券
の購入
購入
詐欺
<<脅威>>
あなた友人を装った悪人
†
平成20年中の被害件数は3,718件、被害総額は約60億円
他人の商品券で家電を買う
友人を装う現金がないことを装う
商品券コード
を写メで送信
家電を
購入
あせった感じで商品
券の購入を依頼他の友人役が
登場
24

脅威分析の難しさ
 起こっていない脅威を見つける難しさ
 攻撃される前に防御する必要がある！
 ネット社会では、攻撃者は不特定
 戦っている特定の相手がいるわけではない！
 完璧な脅威分析はありえない
 常に新しい脆弱性と攻撃方法が考案される（セキュリティには寿命がある！）
 見つかった新たな攻撃はすぐに真似される
 蓄積された最新のセキュリティ情報の有効利用
セキュリティ情報（インシデント情報）の蓄積・再利用が重要
 カタログ化・パターン化による再利用
典型的な攻撃は参考にしやすい形式でカタログ化
例）ネット情報の盗聴のパターン、ホームページ上の個人情報の取得パターン
25

大きな被害が起きないように対策を講じ
る
リスクを知る
被害を知る
脆弱性を知る
脅威を知る
被害を知る
セキュリティの目標（どうあるべきか）を決定
対策方針の決定と実施
• 対策方針の決定
• サービス・機能へのセキュリティ要件の決定
• セキュリティ要件に合わせてサービス・機能を作成、運用
26

セキュリティ目標を定める
価値のあるサービスや資産が持つべき性質が成り立つことをセキュリ
ティの目標とする
 機密性
限られた人・組織のみが閲覧、書き換えなどが出来ること
例）口座の情報は本人のみが閲覧できる
 完全性
情報が変化せずに完全に保たれている状態で、その情報をだれがいつ作成、
変更したかを同時に証明できるようにすることが多い
例）口座に振り込んだ額は、後日変化しない
 可用性
必要な時に必要な情報・サービスが利用可能になっていること
例）２４時間ネットで振込みが可能
※ この他にも、プライバシーやアカウンタビリティ（説明責任）をセキュリティ
の目標とすることもある
27

対策方針の決定と実施
 どのように対策を行うかの大まかな方針（対策方針）を決定
例）本人でないと振込みサービスが使えない、口座情報が見えない
 サービス・機能が満たすべきセキュリティ上の必須条件（セ
キュリティ要件）の決定
例）携帯バンクの振込みサービスを利用中は、携帯のＩＤとパスワー
ドで認証する（システムでの対策）
例）ＡＴＭの振込みサービスを利用中は、携帯の使用を禁止する
（運用での対策）
 セキュリティ要件に合わせてサービス・機能を構築、運用
 セキュリティの機能を使ってサービスを構築
セキュリティ機能：暗号モジュール、署名モジュール、認証モ
ジュールなど
28

セキュリティ機能の設計のためパターン
 アクセス制御・機密性、完全性に関するアーキテクチャ・デザインパターン
 ロールベースアクセス制御
 シングルアクセスポイント、チェックポイントなど
 ユーザインターフェースに関するパターン
 有効性に関するアーキテクチャパターン
 ファイアウォールパターン：IPレベル、トランスポーテーションレベル、サービスレベル
 OSレベルのデザインパターン
 説明可能性に関するデザインパターン
 Webアプリケーション向けのデザインパターン
【セキュリティ目標とシステムへの要求】
 機密性(Confidentiality)
 完全性(Integrity)
 有効性(Availability)
 説明可能性(Accountability)
【セキュリティの実施方針】
防御（Prevention）、検知（Detection）、対応（Response）
 アクセス制御
 認証
 暗号化
 署名
 ロギング
どうシステムに作り込むのかの典型例
29

30
https://www.itsgila.com/tipsgates.htm

31
トップエスイー「ソフトウェアパターン」平成29年度第1回講義資料

32
トップエスイー「ソフトウェアパターン」平成29年度第1回講義資料

セキュリティのデザインパターン例
 セキュリティに関する設計方法
や攻撃方法をカタログ化
 再利用しやすいように構造化
ロールベースアクセス制御（RBAC）パターン[5]
33

シングルアクセスポイントパターン
 サービス利用の入り口を一箇所に限定する
 アクセスの制限を簡単に行える（門番を置く）
 攻撃されうる箇所を制限して対策を単純化する
 利便性が損なわれる恐れがある
Markus Schumacherほか, "Security Patterns: Integrating Security
and Systems Engineering", Wiley,2006.
34

シングルアクセスポイントパターン
35
User
log-in
Single
Access Point System
do something
check
client
ok
do anything
Markus Schumacherほか, "Security Patterns: Integrating Security
and Systems Engineering", Wiley,2006.

セキュリティのセッション管理
User
log-in
Check Point Manager Component
Session
new session
SessionId SessionId
Session
do_something
SessionId
get user info
SessionId SessionId
releaselog-off
SessionId
https://www.famitsu.com/news/201109/images/00050502/NgfJkz5fxlzzb9
GzE4eTiTEL4NowsNIs.html
Security Session Pattern [6]
36

セキュアなロギング（記録）
uses SecureLogger
Factory
Client LogManager
Logger
SecurePipe
SecureStore
uses
uses
uses
creates
stores
uses
結婚式で受付を頼まれた方必見！
https://www.mwed.jp/manuals/427/
Secure Logger Pattern with Secure Log Store Strategy [4]
37

演習：セキュアなオフィスの設計
https://imgur.com/gallery/mhyex
What does it protect?
Is the protection appropriate?
Against whom?
パターンを使ってオフィスをセキュアにしてみましょう！
個人演習：２０分、グループレビュー：１０分、発表会：１０分
38

その他のセキュリティパターン
セキュリティ
上の問題
セキュリティ
対策（解決）
要求工程設計工程実装工程テスト・運用工程
ソフトウェアのライフ
サイクル
セキュリティ
ゴール
脆弱性（セキュリティバグ、ミス）
攻撃
脅威・リスク
セキュリティ
戦略・ポリシー
セキュリティ
機能要求セキュリティ機能
セキュリティライブラリ・
フレームワーク
セキュリティアー
キテクチャ・設計
セキュリティ設定
分析パターン
攻撃パターン・
脆弱性パターン
設計パターン
実装パターン
資産
39

参考：コモンクライテリアとパターン
40
ロールベースアクセス制御（RBAC）パターン[Fernandez01]

参考：コモンクライテリアとパターン
41
User
log-in
Check Point Manager Component
Session
new session
SessionId SessionId
Session
do_something
SessionId
get user info
SessionId SessionId
releaselog-off
SessionId
Security Session Pattern [6]

 関心ごとがお互い複雑に関連、開発プロセスに
横断
 セキュリティの実現コストが大きい：範囲、優先度
 メンテナンス性、ユーザビリティなど他の特性との
トレードオフ
セキュリティ設計での解決
SecureUML
UMLSec
42

アクセス制御モデリング言語：
SecureUML
J2EEの設定ファイルの自動生成
※David Basin：Model Driven Security
UMLのメタモデル
 David BasinらによるUMLのプロファイル
 ロールベースアクセス制御（RBAC）に基づくアクセス制御のモデル化
 セキュリティ設定を自動生成可能
43

セキュリティモデリング言語：UMLsec
 Jan JurjensによるUML のセキュア
システム開発のための拡張
 セキュリティに関する予め定義さ
れたステレオタイプ（とその意味
論）を用いて、モデルを記述
完全性を保つべきプロトコル
セキュリティコンテキスト
制御フローの依存関係
データ制御の依存関係
44

セキュリティ実装・テスト
【セキュリティ実装】
 脆弱性除去のためのセキュアコーディング規約
 最低限のマナー（リテラシ）として教育されることが多い
 コーディングプラクティス
 スタンダードに準拠するために必須のルール
 セキュリティや品質向上のために推奨されるレコメンデーション
 規約例
 不正なデータ・例外の排除
 バッファオーバーフローをさせないメモリサイズチェック
 すべての例外をキャッチ
 書式指定出力関数（sprintf）の引数チェック
【セキュリティテスト】
 Fuzz Testing
 有効範囲外・例外的なデータ・処理によって脆弱性がないかをチェック
 “00”、NULLデータの入力
 巨大な文字列の入力
45

 関心ごとがお互い複雑に関連、開発プロセスに
横断
 セキュリティの実現コストが大きい：範囲、優先度
 メンテナンス性、ユーザビリティなど他の特性との
トレードオフ
開発プロセスでの解決
i*,secureTrops
SQUARE
46

セキュリティのための開発プロセス
【セキュリティのためのアクティビティ】
 脅威分析
 攻撃分析
 対策（方針）決定
 対応範囲決定
 リスク分析
 要件の優先度付け
 セキュリティ機能の設計・実装
 脆弱性除去
 インシデント対策
【主に上流工程の手法】
 エージェント指向開発法：i*, Secure Tropos
 SQUARE（Security Quality Requirements Engineering）
47

セキュリティ要求の獲得手順：i*の拡張
 Lin Liuらによる
 i*に攻撃者の振る舞い、攻撃の状況の分析を追加
アクタ特定
戦略モデル
（アクター間の依存関係）
ゴール・タスク特定
戦略原理モデル
(ゴールツリー、ソフト
ゴール間関係を含
む)
依存関係特定
攻撃者特定
悪意特定
脆弱性分析
攻撃方法特定
対策特定
攻撃者モデル
悪意モデル
脆弱性モデル
攻撃方法
モデル
対策モデル
通常のi*プロセス
48

セキュリティ要求の獲得手順：Secure Tropos
 H. Mouratidisらによる
 ステークホルダの分析の際
にセキュリティ制約を整理
 その制約をシステムの制約
に詳細化
初期要件（Early Requirements）の整理
• ステークホルダ（アクター）の分析
• セキュリティ制約分析
• セキュリティ実体分析
後期要件（Late Requirements）の整理
• システムの分析
• システムセキュリティ制約分析
• システムセキュリティ実体分析
アークテクチャ設計
• アクターのゴールとタスクを分解
• エージェントへタスクを割付け
詳細設計
49

セキュリティ品質要求工学：SQUARE
 N. Meadらによる
 プロジェクトの初期
段階からのアクティ
ビティと利用可能な
技術を整理
 セキュリティの重要
により軽量プロセス（
SQUARE lite）を選択
可能
50

ガイドライン（IPA)
 IoTのセキュリティ
 https://www.ipa.go.jp/security/iot/index.html
 つながる世界のセーフティ＆セキュリティ設計入門
 組込みシステム、情報家電／オフィス機器、自動車、
医療機器、制御システム
 ツール・ガイド：
安全なウェブサイトの作り方など
 IPA セキュア・プログラミング講座
 https://www.ipa.go.jp/security/awareness/vendor/pr
ogramming/
51

強いソフトウェア作成レシピ
1. 価値のあるサービス・資産を見つける
2. 攻撃とそのリスクを分析
3. 被害を分析し、対策すべき脅威を決定
4. セキュリティの目標を決定
5. 対策方針の決定
6. サービス・機能へのセキュリティ要件の決定
システムへの対策、運用での対策、教育による対策などさまざま
7. セキュリティ要件に合わせてサービス・機能を作成、運用
新しい攻撃・脅威・被害を発見
52

セキュリティ工学の今後の展望
 困難な課題
 状況の変化への対応方法
 モデルでの対応、プロセスでの対応
 効率のよいセキュリティ情報管理
インシデントそのものだけではなく、設計、要求な
ど上流開発まで含めた対策の再利用
 さまざまな手法・技術の使いこなし方
 工程間のトレーサビリティ
 一貫した構築手順・ガイドラインの整理
53

[1] 吉岡信和,大久保隆夫,宗藤誠治, “セキュリティソフトウェア工学の研究動向”,
日本ソフトウェア科学会, コンピュータソフトウェア, Vol.28, No.3, pp.43-60,
2011.
[2] 吉岡信和, “セキュリティの知識を共有するセキュリティパターン”, 情報処理学
会, 情報処理, Vol.52, No.9, pp. 1134-1139, 2011.
[3] 吉岡信和、田口研治編集、 “セキュリティ要求工学の実効性”、情報処理学会
、情報処理、Vol.50、No.3、Mar.、2009
英語の教科書
[4] Christopher Steel他, "Core Security Patterns: Best Practices and Strategies
for J2EE, Web Services, and Identity Management", Prentice Hall, 2005.
[5] Markus Schumacherほか, "Security Patterns: Integrating Security and
Systems Engineering", Wiley,2006.
[6] Eduardo Fernandez-Buglioni, "Security Patterns in Practice: Designing
Secure Architectures Using Software Patterns", Wiley, 2013.
[7] Jay Ramachandran, "Designing Security Architecture Solutions", John
Wiley & Sons, 2002.
参考文献
54

55
Eykholt, K., Evtimov, I., Fernandes, E., Li, B., Rahmati, A., Xiao, C., Song, D. (2017).
Robust Physical-World Attacks on Deep Learning Models.
One more thing…

セキュリティの知識を共有するセキュリティパターン(2018/6/15)

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to セキュリティの知識を共有するセキュリティパターン(2018/6/15)

Similar to セキュリティの知識を共有するセキュリティパターン(2018/6/15) (20)

More from Nobukazu Yoshioka

More from Nobukazu Yoshioka (14)