Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
セキュア開発の3つの敵
オカダリョウタロウ
riotaro@owasp.org
@okdt
OWASP –
Open Web Application Security Project
<mission: ソフトウェアセキュリティについて
意思決定をする人のために役立つ十分な情報を
提供すること>
– 技術者、ビジネスオーナ、ユーザ
–...
Red pill, or blue pill?
From : MATRIX
7http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/090700192/
「日本はオイシイ」からサイバー攻撃で狙われる
奈良先端科学技術大学院大学 山口英教授
Enabling Security ©2016 Asterisk Research, Inc. 8
ー 一般教養としてのセキュリティで今、いちばん情報が足りない分野はなんでしょうか?
設計・開発段階からセキュリティの機能を組み込む「セキュアプロ...
その1 ネットワーク・セキュリティ
セキュア開発の敵
Security: Network or Application
L7
Security: Network or Application
Security: Network or Application
Sources: Gartner, OWASP
Network
Server
Web
Applications
% of Attacks % of Dollars
90%
セキュ...
Intel Edison SD Card size PC
Bluetooth/LE
Wi-Fi
24x32x2.1mm
22nm 500MHz
Linux
1GB RAM
4GB storage
Dual Core IA
“コンピュータやスマー...
Privacy-by-Design Principals
• Proactive not Reactive:
• Preventive not Remedial
• Privacy as the default
• Privacy Embedd...
Sensors on Shelves
Automated Checkout
Proximity Advertising
Security Alarm & Environmental Sensors
Elements of a Protection
Architecture for IoT
https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project
• アタックサーフィスの概説
• 脅威エージェント
• 攻撃の経路(アタックベクター)
• セキュ...
IoT は ITの 総合格闘技だ
© MMA
Requirements to use ネットワーク・セキュリティ
• 許可された通信から情報は窃取されている。
– “ファイアウォール” はL7を理解しない。役割が異なる
• システムを総合的に守る価値
– ネットワーク・セキュリティとアプリ...
その2 オープンソース・ソフトウェア
セキュア開発の敵
アプリケーション
パッケージ, クラウドサービス, OSS, 3rd party
IoT Node Types and Data Paths
http://www.rtcmagazine.com/articles/view/105734
IoT Open Source “Heat Map”
http://www.rtcmagazine.com/articles/view/105734
Requirements to use Open Source Software
• プロジェクトとコードをチェックせよ
– Openである意味はそこにある
• 組み込むならOSSのコードもテストせよ
– Found issue? Shut u...
その3 脆弱性検査
セキュア開発の敵
テスト
(DAST)
直す 隠す無視・
あきらめ
テスト
(SAST)
開発サイドの悩み
アプリケーションセキュリティスキ
ルとツールの不足
予算配分管理の欠如
デリバリー再優先
セキュリティチームの悩み
全アプリケーション資産の把握がで
きて...
脆弱性検査 ?
| Enabling Security | ©Asterisk Research, Inc. 34
フェーズ Percent
企画・要件定義フェーズ 53.4%
設計フェーズ 16.5%
開発中 14.6%
コードのチェックイン...
開発プロセスで最も参照されているガイドライン
Enabling Security ©2016 Asterisk Research, Inc. 35
出典:SANS Institute (2015)
容易 x 甚大な影響を及ぼす脆弱性。
Enabling Security ©2016 Asterisk Research, Inc. 36
A1 – インジェクション
A2 – 認証とセッション管理の不備
A3 – クロスサイトスクリプティング...
Focus: “脆弱な現象から、その原因を探ること”
1.早期に、繰り返しセキュリティ検証する
2.クエリーのパラメータ化
3.エンコード処理
4.全ての入力値を検証する
5.アイデンティティと認証
6.アクセス制御の実装
7.データの保護
8...
Focus: “脆弱な現象から、その原因を探ること”
2016/3/26 ©2015 Asterisk Research, Inc. 38
1:早期に、繰り返しセキュリティ検証
• セキュリティ要件を決める
– はっきりさせるにはOWASP ASVSが役立つ
• 「テストによって品質は作り込めない」
– ならば「テストによってセキュリティは作り込めない」
• むしろ開発作業者をテス...
2: クエリーのパラメータ化
• SQLインジェクション
– データ盗難だけではない。
– 踏み台化するのに使う。
• 入力値がSQLコマンドの
一部になってしまうこと
を防ぐ
– ORモデルの利用
– 静的コード解析(動的に
SQLを作ってい...
3. データのエンコーディング
• 以下はそれぞれエンコーディングで
回避できる
– コマンドインジェクション
– LDAPインジェクション
– XMLインジェクション
– クロスサイトスクリプティング
• モバイル
– Webview の悪用...
4. すべての入力値を検証する
• すべての値を信頼できない
– HTTPヘッダ
– Cookie
– GET/POSTパラメータ
– アップロードファイル
• 形式と意味
– 権限
• どこでやるか?
– JavaScript?
• モバイル...
5. アイデンティティと認証管理の実装
• 多要素認証
• トークン認証
• パスワードの保管はどこに?
• リカバリー方式の実装
• セッションの生成と破棄
• 重要な処理を行う場合には、再認証
• パスワードのハッシュ化
https://w...
6.適切なアクセス制御の実装
• すべてのリクエストがアクセス制御を通る
ようにする
• アクセス制御のデフォルトは「拒否」
• 最小権限の原則
• アクセス制御をプログラムにハードコー
ディングしない
• アクティビティに基づいて記述する
•...
7:データの保護
• 通信経路のデータは暗号化する
• データを保存する際の暗号化
• 保存先を変更する場合にも、
データが保護されるようにする
• モバイルアプリケーション:端末
に安全にデータを保存する
8.ロギングと侵入検知の実装
• 重要
– アプリケーションの運用監視
– ビジネスの分析と洞察
– アクティビティの監査やコン
プライアンスの監視
– システムに対する侵入検知
– フォレンジック
• モバイル
– ログ出力を無効化してリリー...
9.セキュリティフレームワークやライブラリの活用
• Spring
• Apache Shiro
• Django Security
• Flask Security
• 攻撃されやすい
”フレームワーク”も
ある
10.エラー処理と例外処理
• 例外処理の重要ポイント
– 集中管理せよ
– ユーザに見えるところへの
出力メッセージに機密が含
まれないように。
– 品質保証やフォレンジック
チームが調査に十分な例外
を出力
“Build Security In”
ステージゲートと対策のマッピング
©2016 Asterisk Research, Inc.
犯罪
ケース
セキュリティ
要件
脅威
分析
リスクベース
テストプラン
コード
検査
ペネトレーション
テス...
Requirements to use 脆弱性検査
• 活用できる脆弱性検査を
– 脆弱性ありました!にとどまらないこと
– Proactiveな施策に変換。
• プロアクティブ・コントロール
– 脆弱性はなぜ出るのかを推察し改善の方向性を示す...
その4 セキュリティは報われるのか?
セキュア開発の敵 番外編
強い動機は?
| Enabling Security | ©Asterisk Research, Inc. 52
Drivers for AppSec Programs Response Percent
コンプライアンス、内部監査、調査レポート...
他業界のビルド・イン・セキュリティ例:
PCI DSSコンプライアンス
53
PCI DSS 3.0要件(引用)
要件6
安全性の高いシステム
とアプリケーションを開
発し、保守する
要件6は、現在および変化し続ける脆弱性、および安全なコード化...
他業界のビルド・イン・セキュリティ例:
HIPAA コンプライアンス + HITECH法
54
HIPAA
Privacy Rule
Security Rule
Breach Notification Rule
Patient Safety R...
「セキュリティ・バイ・デザイン」
2015/9/4 サイバーセキュリティ戦略 閣議決定
55
The biggest barrier is…
©2015 Asterisk Research, Inc. 56
RMS Titanic departing Southampton on April 10, 1912. (Photo: Crea...
対策: コミュニケーション x セキュリティ
社会価値
• 協調領域
• 競争領域
連携
• 新しいリスク
• 解決策
個別の
問題
• 問題対応?
• 事前対策?
Enabling Security ©2016 Asterisk Research, Inc. 61
日本語への翻訳・執筆プロジェクト
62
連携・コラボレーション
22
OWASP Japan Local Chapter Meetings
Reasons for holding OWASP Global AppSec in Japan – OWASP Japan Local Chapter – 2013....
64
国際コンファレンスの開催 (2014, 東京)
2015/9 リリース,
OWASP
2014 年次報告書
日本での活動を特集
報告書・レポートの制作
Local Activities
数々のプロジェクトへの参画・設立
Hardening Project
IPA セキュリティ10大脅威, JPCERT/CC,
総務省サイバー演習CYDER, SECON,
沖縄サイバーセキュリティネットワーク, Security Camp,
IoT x Healthcare H...
OWASP FUKUSHIMA発足おめでとうございます。
OWASP OKINAWA 2016 淵上真一・又吉伸穂
OWASP SENDAI 2015 小笠貴晴
OWASP KYUSHU 2015 服部 祐一・花田智洋
OWASP FUKUSHIMA 2014 6 金子正人・八幡圭嗣
OWASP KA...
Be the enabler!
Folks!
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
セキュア開発の&lt;s>3つの&lt;/s>敵
Upcoming SlideShare
Loading in …5
×

セキュア開発の&lt;s>3つの&lt;/s>敵

576 views

Published on

IoTxHealthcare Hackathon Pre-eventにて公開した講演資料。

Published in: Engineering
  • Be the first to comment

セキュア開発の&lt;s>3つの&lt;/s>敵

  1. 1. セキュア開発の3つの敵 オカダリョウタロウ riotaro@owasp.org @okdt
  2. 2. OWASP – Open Web Application Security Project <mission: ソフトウェアセキュリティについて 意思決定をする人のために役立つ十分な情報を 提供すること> – 技術者、ビジネスオーナ、ユーザ – ソフトウェアに関する技術・セキュアプロセス – 現状理解・普及啓発・適用推進 – オープンソース・コミュニティベースで実現
  3. 3. Red pill, or blue pill? From : MATRIX
  4. 4. 7http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/090700192/ 「日本はオイシイ」からサイバー攻撃で狙われる 奈良先端科学技術大学院大学 山口英教授
  5. 5. Enabling Security ©2016 Asterisk Research, Inc. 8 ー 一般教養としてのセキュリティで今、いちばん情報が足りない分野はなんでしょうか? 設計・開発段階からセキュリティの機能を組み込む「セキュアプログラミング」だろう。… すべてのプログラマーがセキュアプログラミングを常識として知っているべきだと思うが、 残念ながらセキュアプログラミングを学ぶための情報は限られている。 山口 英 奈良先端科学技術大学院大学教授, JPCERT/CC設立者, 内閣官房初代情報セキュリティ補佐官 http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/090700192/?ST=management&P=4
  6. 6. その1 ネットワーク・セキュリティ セキュア開発の敵
  7. 7. Security: Network or Application L7
  8. 8. Security: Network or Application
  9. 9. Security: Network or Application Sources: Gartner, OWASP Network Server Web Applications % of Attacks % of Dollars 90% セキュリティ攻撃 セキュリティ支出 75% 25% 10% 脆弱なウェブアプリケーション、67%
  10. 10. Intel Edison SD Card size PC Bluetooth/LE Wi-Fi 24x32x2.1mm 22nm 500MHz Linux 1GB RAM 4GB storage Dual Core IA “コンピュータやスマートフォンのみならず、椅子や コーヒーメーカーや、マグカップまでがネットワーク デバイスになります。” http://www.intel.com/content/www/us/en/do-it-yourself/edison.html
  11. 11. Privacy-by-Design Principals • Proactive not Reactive: • Preventive not Remedial • Privacy as the default • Privacy Embedded • Full Functionality • End-to-end Security • Visibility and Transparency • Respect for User Privacy • Privacy Impact Assessment
  12. 12. Sensors on Shelves
  13. 13. Automated Checkout
  14. 14. Proximity Advertising
  15. 15. Security Alarm & Environmental Sensors
  16. 16. Elements of a Protection Architecture for IoT
  17. 17. https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project • アタックサーフィスの概説 • 脅威エージェント • 攻撃の経路(アタックベクター) • セキュリティの弱点 • 技術面のインパクト • ビジネス面のインパクト • 脆弱性の例 • 攻撃の例 • この問題を避けるガイダンス • OWASP、他のリソース・参照情報 • 製造者、開発者、消費者それぞれ が考慮すべきことのリスト I1 安全でないウェブインターフェース I2 欠陥のある認証・認可機構 I3 安全でないネットワークサービス I4 通信路の暗号化の欠如 I5 プライバシー I6 安全でないクラウドインターフェース I7 弱いモバイルインターフェース I8 設定の不備 I9 ソフトウェア・ファームウェアの問題 I10 物理的な問題 OWASP Internet of Things Top 10 もっとも甚大なIoTセキュリティへのアタックサーフィス
  18. 18. IoT は ITの 総合格闘技だ © MMA
  19. 19. Requirements to use ネットワーク・セキュリティ • 許可された通信から情報は窃取されている。 – “ファイアウォール” はL7を理解しない。役割が異なる • システムを総合的に守る価値 – ネットワーク・セキュリティとアプリケーションセキュリティ は役割が異なり、バランスよく投資しなければならない。 • ネットワーク・セキュリティの人材と、アプリケーショ ン・セキュリティの人材ではスキルセットが異なる – 取り扱っているものは、単なる”データ”ではない。
  20. 20. その2 オープンソース・ソフトウェア セキュア開発の敵
  21. 21. アプリケーション
  22. 22. パッケージ, クラウドサービス, OSS, 3rd party
  23. 23. IoT Node Types and Data Paths http://www.rtcmagazine.com/articles/view/105734
  24. 24. IoT Open Source “Heat Map” http://www.rtcmagazine.com/articles/view/105734
  25. 25. Requirements to use Open Source Software • プロジェクトとコードをチェックせよ – Openである意味はそこにある • 組み込むならOSSのコードもテストせよ – Found issue? Shut up and fix it! • アップデートが重要 – モジュール、コードいずれのレベルでも
  26. 26. その3 脆弱性検査 セキュア開発の敵
  27. 27. テスト (DAST) 直す 隠す無視・ あきらめ テスト (SAST) 開発サイドの悩み アプリケーションセキュリティスキ ルとツールの不足 予算配分管理の欠如 デリバリー再優先 セキュリティチームの悩み 全アプリケーション資産の把握がで きていない 開発、セキュリティ、事業部のサ イロ化によるコミュニケーションコ スト増 脆弱性修正すると動かなくなるこ とへの恐れ 出典:SANS Institute (2015) Q. “Top Challenges for Builders and Defenders ” ? 間際のテストではオワコン
  28. 28. 脆弱性検査 ? | Enabling Security | ©Asterisk Research, Inc. 34 フェーズ Percent 企画・要件定義フェーズ 53.4% 設計フェーズ 16.5% 開発中 14.6% コードのチェックイン 4.9% リリース前 8.7% Other 1.9% 出典:SANS Institute (2015)
  29. 29. 開発プロセスで最も参照されているガイドライン Enabling Security ©2016 Asterisk Research, Inc. 35 出典:SANS Institute (2015)
  30. 30. 容易 x 甚大な影響を及ぼす脆弱性。 Enabling Security ©2016 Asterisk Research, Inc. 36 A1 – インジェクション A2 – 認証とセッション管理の不備 A3 – クロスサイトスクリプティング (XSS) A4 – 安全でないオブジェクト直接参照 A5 – セキュリティ設定のミス A6 – 機密データの露出 A7 – 機能レベルアクセス制御の欠落 A8 – クロスサイトリクエストフォージェリ(CSRF) A9 – 既知の脆弱性を持つコンポーネントの使用 A10 – 未検証のリダイレクトとフォーワード
  31. 31. Focus: “脆弱な現象から、その原因を探ること” 1.早期に、繰り返しセキュリティ検証する 2.クエリーのパラメータ化 3.エンコード処理 4.全ての入力値を検証する 5.アイデンティティと認証 6.アクセス制御の実装 7.データの保護 8.ロギングと侵入検知 9.セキュリティフレームワークやライブラリの活用 10.エラー処理と例外処理 2016/3/26 ©2015 Asterisk Research, Inc. 37 2016年1月リリース 日本語版もでました
  32. 32. Focus: “脆弱な現象から、その原因を探ること” 2016/3/26 ©2015 Asterisk Research, Inc. 38
  33. 33. 1:早期に、繰り返しセキュリティ検証 • セキュリティ要件を決める – はっきりさせるにはOWASP ASVSが役立つ • 「テストによって品質は作り込めない」 – ならば「テストによってセキュリティは作り込めない」 • むしろ開発作業者をテストするべき – 継続教育 • 毎回のイテレーション(スプリント)ごとに実装し検証できる範囲のテスト – コーディングチェッカー、OWASP ZAP
  34. 34. 2: クエリーのパラメータ化 • SQLインジェクション – データ盗難だけではない。 – 踏み台化するのに使う。 • 入力値がSQLコマンドの 一部になってしまうこと を防ぐ – ORモデルの利用 – 静的コード解析(動的に SQLを作っていないか) – パラメータ・クエリー String newName = request.getParameter("newName"); int id = Integer.parseInt(request.getParameter("id")); PreparedStatement pstmt = con.prepareStatement(“UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); pstmt.setString(1, newName); pstmt.setInt(2, id);
  35. 35. 3. データのエンコーディング • 以下はそれぞれエンコーディングで 回避できる – コマンドインジェクション – LDAPインジェクション – XMLインジェクション – クロスサイトスクリプティング • モバイル – Webview の悪用で写真、 GPS情報、SMSを操作可 能 • Java Encoder "Encode.forContextName(untrustedData)" • Escaperクラスの利用
  36. 36. 4. すべての入力値を検証する • すべての値を信頼できない – HTTPヘッダ – Cookie – GET/POSTパラメータ – アップロードファイル • 形式と意味 – 権限 • どこでやるか? – JavaScript? • モバイル – プロセス間通信 – バックエンドのサーバデータ – ファイルからの読み込みデータ • 方式 – ブラックリスト – ホワイトリスト – 正規表現 – HTMLサニタイズ
  37. 37. 5. アイデンティティと認証管理の実装 • 多要素認証 • トークン認証 • パスワードの保管はどこに? • リカバリー方式の実装 • セッションの生成と破棄 • 重要な処理を行う場合には、再認証 • パスワードのハッシュ化 https://www.reddit.com/r/funny/comments/1m628n/th ty/
  38. 38. 6.適切なアクセス制御の実装 • すべてのリクエストがアクセス制御を通る ようにする • アクセス制御のデフォルトは「拒否」 • 最小権限の原則 • アクセス制御をプログラムにハードコー ディングしない • アクティビティに基づいて記述する • アクセス制御には、サーバー側の信頼でき るデータを使う
  39. 39. 7:データの保護 • 通信経路のデータは暗号化する • データを保存する際の暗号化 • 保存先を変更する場合にも、 データが保護されるようにする • モバイルアプリケーション:端末 に安全にデータを保存する
  40. 40. 8.ロギングと侵入検知の実装 • 重要 – アプリケーションの運用監視 – ビジネスの分析と洞察 – アクティビティの監査やコン プライアンスの監視 – システムに対する侵入検知 – フォレンジック • モバイル – ログ出力を無効化してリリー スする方法
  41. 41. 9.セキュリティフレームワークやライブラリの活用 • Spring • Apache Shiro • Django Security • Flask Security • 攻撃されやすい ”フレームワーク”も ある
  42. 42. 10.エラー処理と例外処理 • 例外処理の重要ポイント – 集中管理せよ – ユーザに見えるところへの 出力メッセージに機密が含 まれないように。 – 品質保証やフォレンジック チームが調査に十分な例外 を出力
  43. 43. “Build Security In” ステージゲートと対策のマッピング ©2016 Asterisk Research, Inc. 犯罪 ケース セキュリティ 要件 脅威 分析 リスクベース テストプラン コード 検査 ペネトレーション テストビルド 品質分析 セキュリティ 運用 vulnerability 1.早い段階に、繰り返しセキュリティ検証 2.クエリーのパラメータ化 3.エンコード処理 4.全ての入力値を検証する 5.アイデンティティと認証 6.アクセス制御の実装 7.データの保護 8.ロギングと侵入検知 9.セキュリティフレームワークやライブラリの活用 10.エラー処理と例外処理
  44. 44. Requirements to use 脆弱性検査 • 活用できる脆弱性検査を – 脆弱性ありました!にとどまらないこと – Proactiveな施策に変換。 • プロアクティブ・コントロール – 脆弱性はなぜ出るのかを推察し改善の方向性を示す • ライフサイクル – 早期に、繰り返しセキュリティテストできる方法はある
  45. 45. その4 セキュリティは報われるのか? セキュア開発の敵 番外編
  46. 46. 強い動機は? | Enabling Security | ©Asterisk Research, Inc. 52 Drivers for AppSec Programs Response Percent コンプライアンス、内部監査、調査レポートの率直な指摘 71.5% 漏洩時の経済的打撃に対するリスクベースの意識 69.6% 顧客への「当然の品質」としての魅力提示 39.9% セキュリティ・インシデントの指摘 36.7% 業界の予算、ROI、TCO比較による 33.5% Other 1.3% 出典:SANS Institute (2015)
  47. 47. 他業界のビルド・イン・セキュリティ例: PCI DSSコンプライアンス 53 PCI DSS 3.0要件(引用) 要件6 安全性の高いシステム とアプリケーションを開 発し、保守する 要件6は、現在および変化し続ける脆弱性、および安全なコード化ガイドラインを反 映させるため要件が追加・更新されています。開発環境、開発者トレーニングに関 する要件が更新されています。また、コーディング実践に関する要件が追加されて います。 要件 11: セキュリティシステムお よびプロセスを定期的 にテストする。 要件11では、発展型要件、追加のガイダンス、明確化と多角的に要件が発展して います。特に、脆弱性テストには期間(四半期ごと)のみならず、訂正内容を検証 するための繰り返しテストの要件についても明確化されました。 要件12 すべての担当者の情 報セキュリティに対応 するポリシーを維持す る。 要件12では、2.0に引き続き、担当者教育の重要性が強調されています。入社時、 また年ごとに行うよう規定されています。
  48. 48. 他業界のビルド・イン・セキュリティ例: HIPAA コンプライアンス + HITECH法 54 HIPAA Privacy Rule Security Rule Breach Notification Rule Patient Safety Rule https://www.ibm.com/developerworks/jp/cloud/library/cl-hipaa/ http://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
  49. 49. 「セキュリティ・バイ・デザイン」 2015/9/4 サイバーセキュリティ戦略 閣議決定 55
  50. 50. The biggest barrier is… ©2015 Asterisk Research, Inc. 56 RMS Titanic departing Southampton on April 10, 1912. (Photo: Creative Commons)
  51. 51. 対策: コミュニケーション x セキュリティ 社会価値 • 協調領域 • 競争領域 連携 • 新しいリスク • 解決策 個別の 問題 • 問題対応? • 事前対策?
  52. 52. Enabling Security ©2016 Asterisk Research, Inc. 61 日本語への翻訳・執筆プロジェクト
  53. 53. 62 連携・コラボレーション
  54. 54. 22 OWASP Japan Local Chapter Meetings Reasons for holding OWASP Global AppSec in Japan – OWASP Japan Local Chapter – 2013.3.1 定期的なミーティング・トレーニング
  55. 55. 64 国際コンファレンスの開催 (2014, 東京)
  56. 56. 2015/9 リリース, OWASP 2014 年次報告書 日本での活動を特集 報告書・レポートの制作
  57. 57. Local Activities 数々のプロジェクトへの参画・設立
  58. 58. Hardening Project IPA セキュリティ10大脅威, JPCERT/CC, 総務省サイバー演習CYDER, SECON, 沖縄サイバーセキュリティネットワーク, Security Camp, IoT x Healthcare Hackathon
  59. 59. OWASP FUKUSHIMA発足おめでとうございます。
  60. 60. OWASP OKINAWA 2016 淵上真一・又吉伸穂 OWASP SENDAI 2015 小笠貴晴 OWASP KYUSHU 2015 服部 祐一・花田智洋 OWASP FUKUSHIMA 2014 6 金子正人・八幡圭嗣 OWASP KANSAI 2014 長谷川陽介・斉藤太一 OWASP JAPAN 2011 岡田良太郎・上野宣 Come on
  61. 61. Be the enabler! Folks!

×