セキュリティオペレーション自動化に向けた、基盤技術と共通インターフェースの構築 [ISOC-JP workshop, 2016/05/20]
•
4 gostaram•933 visualizações
This slide share the recent activities on security automation. First, it talks about the need for security automation; second, it talks about the standardization activities; third, it introduces recent research and development activities the presenter engages in
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a セキュリティオペレーション自動化に向けた、基盤技術と共通インターフェースの構築 [ISOC-JP workshop, 2016/05/20]
Semelhante a セキュリティオペレーション自動化に向けた、基盤技術と共通インターフェースの構築 [ISOC-JP workshop, 2016/05/20] (20)
Mais de Takeshi Takahashi
Mais de Takeshi Takahashi (7)
Último
Último (9)
セキュリティオペレーション自動化に向けた、基盤技術と共通インターフェースの構築 [ISOC-JP workshop, 2016/05/20]
- 1. セキュリティオペレーション自動化に向けた、 基盤技術と共通インターフェースの構築 高橋健志 情報通信研究機構 1 ISOC-JP Workshop on May 20, 2016 但し書き: 本資料は、英文で作成した別の資料を使いまわしています。そのため、英文が 多数残っておりますが、ご容赦ください。
- 2. 自己紹介 2 “Security Workshop” at Tsuda College 担当講義 (2016年度) 現在の所属 • Tampere Univ. of Tech. • Waseda University (JSPS research fellow) • Japan Patent Office • Roland Berger • NICT ITU-T • editor: X.1500, X.1570 IETF • MILE WG co-chair • Security Directorate • editor: RFC 7203 • ISOC-JP PC 主な業務内容 • Cybersecurity in general • Security automation • Android security 氏名 Takeshi Takahashi (CISSP, PMP, Ph.D.) R&DStandardization
- 3. 本日の内容 1. 背景: セキュリティオートメーションの必要性 2. セキュリティオートメーションの概要 3. 各種標準化団体の活動状況 4. NICTにおける我々の研究開発事例 3
- 4. まずは、2015年のサイバーセキュリティをふりかえる • 様々なセキュリティ脅威が存在し、脅威は拡大傾向 – ランサムウェアの増加 – 標的型攻撃の増加 – Haxposureの登場 • セキュリティインシデントのリスクを最小化すべく、各組織はサ イバーセキュリティを維持する必要がある – セキュリティインシデント数は毎年増加傾向 – セキュリティインシデントは企業に甚大な損害を与える 4 最近のサイバーセキュリティの概観 Source: “Trends 2016,” ESET
- 5. しかしながら、世界的に人材不足であるのが現状 5 • “By 2017 prospective hiring organizations may have upwards of 2 million unfilled security related positions” (Intel) Source: https://www.linkedin.com/pulse/cybersecurity-suffering-due-human-resource-challenges-rosenquist, https://www.ipa.go.jp/security/fy23/reports/jinzai/ • IPAの試算によると、下記の通りの人材不足が存在 talented engineer, 105,000 untalented engineer, 160,000 engineers in short, 80,000
- 6. セキュリティオートメーションが必要不可欠 6 How to cope with the talent shortage? Cultivate more talents Streamline security operations Semi- automation full-automation Assist engineers with insufficient skills Our focus: security automation
- 7. 本日の内容 1. 背景: セキュリティオートメーションの必要性 2. セキュリティオートメーションの概要 3. 各種標準化団体の活動状況 4. NICTにおける我々の研究開発事例 7
- 8. Manual operationを自動化することが重要 • Security automation技術はセキュリティオペレーションを自動 化し、オペレータの負荷を軽減する • 「security automation」という言葉は文字通りに捉えると、非常 に幅広い • 「security automation」という言葉はセキュリティ情報を再活用 することによりオペレーションを自動化したいコミュニティに積極 的に利用されている用語である 8 “security automation“とは何か？
- 10. それができると、例えば脆弱性管理の自動化が可能 10 ユースケース: 脆弱性管理の自動化 Information provider Information consumer Vendor A Vendor B Vendor C Vendor D Vulnerability Information repository Vuln. note Automatic push Applying patch, or config change Admin
- 12. 本日の内容 1. 背景: セキュリティオートメーションの必要性 2. セキュリティオートメーションの概要 3. 各種標準化団体の活動状況 4. NICTにおける我々の研究開発事例 12
- 15. これらの規格はidentifierやschemaを定義 Some of major Information description specifications • identifiers for vulnerability informationCVE CWE CAPEC CCE CPE OVAL CEE MAEC • identifiers for the software weakness types • identifiers for attack pattern information • identifiers for configuration issues • identifiers for IT assets such as software • language on how to configure IT assets • language for describing computer events • language for describing malware
- 17. Cybersecurity Information acquisition Cybersecurity Organization Cybersecurity Information use Cybersecurity Organization Cybersecurity information exchange Focus of CYBEX ITU-T X.1500 (CYBEX) – Scope ITU-Tでは情報交換のフレームワークを定義
- 18. ITU-Tはこの情報交換技術の重要性を強く認識 18 ITU-T Rec. X.1500 series Reserved for the future
- 19. いくつかの勧告は、industry規格をそのままimport X.1520: Common Vulnerabilities and Exposures (CVE) X.1521: Common Vulnerability Scoring System (CVSS) X.1524: Common Weakness Enumeration (CWE) X.1525: Common Weakness Scoring System (CWSS) X.1526: Open Vulnerability and Assessment Language (OVAL) X.1528: Common Platform Enumeration (CPE) X.1541: Incident Object Description Exchange Format (IODEF) X.1544: Common Attack Pattern Enumeration and Classification (CAPEC) X.1546: Malware Attribute Enumeration and Characterization Format (MAEC) X.1580: Real-time Internetwork Defense (RID) 19
- 20. X.1500は関連技術動向をupdateする • X.1500 provides only the overview of cybersecurity information exchange in its main body • Its appendix is updated in each meeting so that it can reflect the state-of-the-art activities in this area 20
- 22. 4つのWGがセキュリティオートメーションを検討 22 SecurityAutomation DOTS : DDoS Open Threat Signaling IETF 93 ～ I2NSF : Interface to Network Security Functions IETF 94 ～ MILE : Managed Incident Lightweight Exchange IETF 82～ SACM : Security Automation and Continuous Monitoring IETF 85 ～ Exchanges incident information among parties Monitors and evaluates the security state of end points Copes with DDoS attacks by signaling to network devices Manipulate security parameters of network devices Please see ISOC-JP workshop slides for the details http://www.slideshare.net/TakeshiTakahashi1/ietf-security-automation-updates-isocjp-event-20151006
- 23. MILE WGの概要 • MILE (Managed Incident Lightweight Exchange)はセキュリティ情報 の交換技術を検討する – MILE took over INCH WG – It copes with machine-to-machine in addition to human-to-human – For instance, it works on information representation, usage policy, transport, and guidelines Objective 23 Base spec • IODEF: Incident Object Description and Exchange Format • IODEFはインシデント 情報のデータモデル を定義 • XMLベース Incident IncidentID AlternativeID RelatedActivity DetectTime StartTime EndTime ReportTime Description Assessment Method Contact EventData History AdditionalData 0..1 0..1 0..1 0..1 0..1 0..* 1..* 0..* 1..* 0..* 0..1 0..*
- 24. MILE WGでの技術検討の現状 • RFC 7203 – IODEF-SCI (extension for structured information) 1 3 4 5 • RFC 6685 – Expert Review for IODEF Extensions • JSON-representation of IODEF • RFC5070-bis (=IODEF-bis) • IODEF guidance • IODEF implementation draft • Resource-Oriented Lightweight Indicator Exchange • RFC 6545 – RID / RFC 6546 – RID over HTTP/TLS CompletedWork-in-progress 2 • RFC 6684 – Extension Guidelines and Template • RFC-7495 – IODEF Enumeration Reference Format 24 • XMPP-based IODEF exchange 6 Data representation Transport Guidelines
- 25. MILE WGのまとめと所感 1. MILEはインシデント情報の交換技術に注力。特に、 data representation, transport, guidelineに関する規格を構築中 2. 最大のissueの一つがRFC5070-bis (IODEF v2)であるが、現 在すでにIETF LC中。 3. 今後、MILEは下記のテーマについて検討を進める a. The two transport-level drafts (XMPP and ATOM) b. JSON-representation of IODEF, and its profile c. rechartering or closure
- 26. SACM WGの概要 • SACM: Security Automation and Continuous Monitoring • endpoint postureの評価を実施する技術を検討 • 具体的には、言語やフォーマットに関する規格を 構築 Objective 26 History • Established on 26th Sep. 2012. • It had struggled with the terminology and framework drafts, but it finally embarked the discussion on solutions after IETF 94
- 27. SACM WGでの技術検討の現状 SACMのscope/positionを決定するドラフト群 • RFC 7632: Endpoint Security Posture Assessment: Enterprise Use Cases • SACM Architecture • SACM Requirements • SACM Terminology SACMの課題に対するsolutionドラフト群 • SACM Information Model • SACM Vulnerability Assessment Scenario • Concise Software Identifiers and its related drafts (2 in total) • OVAL(R) Common Model and its related drafts (8 drafts) • Endpoint Compliance Profile and its related drafts (4 drafts) 27
- 28. 脆弱性評価シナリオを検討 28 Overview of the draft Vulnerability assessment process 企業における脆弱性評価シナリオを概観する Identify endpoint and collect initial data Prepare vulnerability description data Evaluate endpoint applicability and conduct assessment Produce an assessment result
- 29. ソフトウェア資産の簡易表記技術を検討 29 Overview of the draft ISO 19770-2:2015で定義されているSWIDを簡潔に表 現する技術を提案 Content of the draft 1. This draft considers constrained environment and defines CBOR-based expression of SWID tags 2. Requirements include: a. The code for an encoder or decoder must be able to be compact in order to support systems with very limited memory, processor power, and instruction sets. b. The format must support all JSON data types for conversion to and from JSON.
- 30. OVALの規格化 30 <oval_definitions> <definitions><definition id="oval:tutorial:def:1"> <metadata> <title>Hello World Example</title> <description>This definition is used to introduce OVAL. </description> </metadata> <criteria> <criterion test_ref="oval:tutorial:tst:1" comment="the value of the registry key = Hello World"/> </criteria> </definition></definitions> <tests> <registry_test id="oval:tutorial:tst:1" check="all"> <object object_ref="oval:tutorial:obj:1"/><state state_ref="oval:tutorial:ste:1"/> </registry_test> </tests> <objects> <registry_object id="oval:tutorial:obj:1"> <hive>HKEY_LOCAL_MACHINE</hive> <key>SOFTWARE¥oval</key> <name>example</name> </registry_object> </objects> <states> <registry_state id="oval:tutorial:ste:1"> <value>Hello World</value> </registry_state> </states> </oval_definitions> OVAL consisｔs of Definition file and interpreter, with which the vulnerability check is automated
- 31. DOTS WGの概要 • DDoS Open Threat Signaling WG • It aims at building standardized signaling techniques among domains to mitigate DDoS attacks Objective 31 History • IETF92：BoF – http://www.isoc.jp/wiki.cgi?page=IETF92Update • It became a WG on 2015.06.27 • The first meeting was at the IETF 93
- 32. DOTS WGでの技術検討の現状 • Use Cases – Use cases for DDoS Open Threat Signaling (draft-ietf-dots-use- cases-01.txt) – Inter-domain cooperative DDoS protection problems and mechanism (draft-nishizuka-dots-inter-domain-mechanism-00) • Requirements – DDoS Open Threat Signaling Requirements (draft-mortensen-threat-signaling-requirements-00) • DOTS mechanism – Information Model for DDoS Open Threat Signaling (DOTS) (draft-reddy-dots-info-model-00) • Messaging – Co-operative DDoS Mitigation (draft-reddy-dots-transport-00) 32
- 34. I2NSF WGでの技術検討の現状 Source: draft-xia-i2nsf-capability-interface-im-03.txt I2NSFのscope/positionを決定するドラフト群 • Use Cases and Requirements for an Interface to Network Security Functions • Interface to Network Security Functions (I2NSF) Problem Statement • Framework for Interface to Network Security Functions • Analysis of Existing work for I2NSF I2NSFの課題に対するsolutionドラフト群 • Information Model of Interface to Network Security Functions Capability Interface • Software-Defined Networking Based Security Services using Interface to Network Security Functions • Interface to Network Security Functions Demo Outline Design
- 35. I2NSFのユースケース Source: draft-pastor-i2nsf-merged-use-cases-00.txt, slides-93-i2nsf-3.pdf Installation and configuration Updating Collecting status Validation
- 37. OASIS Cyber Threat Intelligence (CTI) 37 CybOX STIX TAXII Defining a set of information representations and protocols to support automated information sharing for cybersecurity situational awareness, real-time network defense, and sophisticated threat analysis.
- 38. CybOX:サイバー攻撃観測記述形式 38Source: https://cybox.mitre.org/, http://asmarterplanet.com/jp-security/blog/2015/07/80.html • CybOX: Cyber Observable eXpression • Cyber Observable: a measurable event or stateful property in the cyber domain CybOXが 定義するもの 用語 使い方 • コンピュータやネットワークの挙動や状態について、観測可 能な事象や属性の記述言語をXMLベースで定義 − 観測事象には、ファイル、HTTPセッション、X509証明書 や、その他のシステム構成要素などが含まれる − 拡張性を備える 検討主体 • OASIS、DHS、MITRE (DHSからOASISへ移管) • 特定のコンテキストでの一連の観測事象を脅威の検知指標 として活用。例えば、Windowsレジストリキー名が特定の値 を持つ場合、脅威の存在を示す検知指標となる。同様に、 特定のIPアドレスが悪意を示す検知指標となる • MAECやSTIX内での記述手法として活用
- 40. STIX: 脅威情報構造化記述形式 40 Source: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti, http://asmarterplanet.com/jp-security/blog/2015/07/80.html, http://stixproject.github.io/getting-started/whitepaper/ STIXが 定義する もの STIXの 構成要素 • サイバーセキュリティの脅威に関する情報や事象を記述するため のXMLベースの言語を定義。 − STIX: Stuctured Threat Information eXpression − STIXは、CybOXや、その他の各種言語を活用 − 攻撃者、攻撃活動、セキュリティ・インシデントなど、実際に機 能している脅威情報を包括的にカバー 検討主体 • OASIS、DHS、MITRE (DHSからOASISへ移管) • Observable: サイバースペースで観測できる事象 • Indicator: 観測できる事象のパターン • Incident: セキュリティインシデントに関する情報 • TTP (Tactics, Techniques, and Procedures): 攻撃者の挙動や動作 • Campaign: 特定の目的のために顕在化したThreatActor • ThreatActor: 脅威を呈する悪意あるアクターの特徴 • ExploitTarget: コンピュータやネットワーク、ソフトウェアの脆弱性や 弱点 • COA (Course Of Action) : 脅威に対応するための対策手順
- 42. STIX文書例 42 <stix:Observables cybox_major_version="2" cybox_minor_version="0" cybox_update_version="1"> <cybox:Observable id="example:Observable-3845653a-242a-4821-9f4d-31737a6e3ddd"> <cybox:Object id="example:Object-eb3402ee-34ac-40de-bc6d-10528eda3774"> <cybox:Properties xsi:type="ArtifactObj:ArtifactObjectType“ content_type="application/zip"> <ArtifactObj:Packaging is_encrypted="true"> <ArtifactObj:Encoding algorithm="Base64"/> <ArtifactObj:Encryption encryption_mechanism="PasswordProtected“ encryption_key="test"/> </ArtifactObj:Packaging> <ArtifactObj:Raw_Artifact datatype="string"> <![CDATA[UEsDBBQACQAIAOJ4fEL0EjjuTEUSAKk0FQAqAKMAVEFYSUlfU2VydmljZXNfU3BlY2lmaWNh ………..
- 43. TAXII: 検知指標情報自動交換手順 43 Source: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti The Trusted Automated eXchange of Indicator Information (TAXII™) specifies mechanisms for exchanging structured cyber threat information between parties over the network. Document list • Overview: This document provides an overview of TAXII. • Services: This document describes TAXII's Capabilities, Services, Messages, and Message Exchanges. • HTTP Protocol Binding: this document describes HTTP Protocol Binding. • XML Message Binding: This document describes how to express TAXII messages using an XML binding. • Default Query: This document describes the TAXII default query
- 44. TAXII: HTTP protocol binding 44 Header Description Accept Specifies which HTTP Media Types the requestor accepts in response. Content-Type Specifies the HTTP Media Type in which the entity body is formatted. X-TAXII-Accept Specifies which TAXII Message Bindings the requestor accepts in response. X-TAXII-Content- Type Specifies the TAXII Message Binding in which the entity body is formatted. X-TAXII-Protocol Specifies which TAXII Protocol Binding is used for this message. X-TAXII-Services Specifies the version of the TAXII Services Specification to which this message conforms. Source: “TAXII™ Version 1.1.1 Part 3: HTTP Protocol Binding”
- 45. セキュリティ情報レポジトリはすでに複数存在 • JVN • NVD • Red Hat Repositories • MITRE repositories Etc. 45 NVD/CVE: 70,147 MITRE/CVE: 69,365 JVN: 53,909 Source: online resources from NIST, MITRE, IPA, and Red Hat
- 46. 本日の内容 1. 背景: セキュリティオートメーションの必要性 2. セキュリティオートメーションの概要 3. 各種標準化団体の活動状況 4. NICTにおける我々の研究開発事例 46
- 47. NICTER関連システム 3. Livenet Real-time Visualizer NIRVANA 2. Darknet-based Alert System DAEDALUS 1. Incident Analysis Center NICTER 4. Anti-APT Platform NIRVANA改 /NIRVANA KAI DarknetMonitoringLivenetMonitoring 47
- 48. Target: Comprehensive analysis of security threats on the Internet - What happens on the Internet? - What is the root cause? Strategy: Darknet monitoring + Malware analysis NICTER Operation Room NICTERの概要 48 NICTER = Network Incident analysis Center for Tactical Emergency Response
- 49. 49 NICTER
- 52. Internal Darknet Alert (Local Scan) 52 NICTER : Darknet : Livenet : Infected Host
- 53. External Darknet Alert (Global Scan) 53 : Darknet : Livenet : Infected Host NICTER DarknetTraffic
- 54. External Darknet Alert (Backscatter) 54 NICTER DarknetTraffic : Darknet : Livenet : DDoS Victim
- 55. Goal and Mechanism of DAEDALUS 55 Goal: Utilize the darknet monitoring results for securing the livenet. Mechanism: if (NICTER receives packets from a cooperative organization) alert;
- 56. オペレータ Overview of “NIRVANA Kai” 56 NIRVANA Kai InterfaceforaccessingDB NIRVANA-Kai Visualized user interface Network of monitoring target Real-time traffic visualization Visualizes host information in real-time NICT’s detection engine DarkNet • DAEDALUS LiveNet • Low-speed scan • Segment infringement • Blacklist Secure Appliance Appliances to protect Juniper switch Cisco router OpenFlow switch FFR yarai Highlights events Visualizing the effects of automated countermeasure Endpoint security Host information collection system Visualizes alerts in real-time Alert information collection system Syslog transfer module syslog Event analysis platform Analysisengine Analysisengine Analysisengine Databus Mirror traffic Traffic collection system GateSensor Multifaceted defense system Countermeasure candidate extraction engine Countermeasure engine
- 57. 対策の自動化プロトタイプを構築 Filter anomalous traffic Scan a host Drop all traffic 57 A demo scenario
- 58. 本日の内容 1. 背景: セキュリティオートメーションの必要性 2. セキュリティオートメーションの概要 3. 各種標準化団体の活動状況 4. NICTにおける我々の研究開発事例 1. Traffic anomaly detection and triage using our darknet sensors 2. Automated vulnerability management 58
- 59. 知識ベース (KB) Our knowledge base links assorted vulnerability-related information repositories and enables retrievals across them Source: “Reference Ontology for Cybersecurity Operational Information,” the Computer Journal, 2014 (advanced access)
- 60. 典型的なシステム構成 Collect IT asset information Analyze it and locate related vulnerability information inside KB Provide alerts on at-risk IT assets Terminal Terminal Asset management server Terminal Vulnerability knowledge base Admin console Software switch Agent Agent Internet
- 61. プロセスの概要 Collect IT asset information Generate IT asset identifiers Look up the Vulnerability KB Generate Alert Any relevant information found ? Start Wait for a trigger Yes No
- 62. スナップショット (1/3)
- 63. スナップショット (2/3)
- 64. スナップショット (3/3)
- 65. 管理者にアラートを送信 65
- 66. まとめ 1. 人材不足に対応するには、セキュリティオートメーションが重要 との認識は徐々に広がってきている 2. 各種標準化団体は共通インターフェースの構築に注力している 3. 情報/データのスキーマについて多数の検討がなされてきたが、 今後は、それらをどのように利用し、実際のオペレーションを如 何に自動化していくかの検討が求められている 4. NICTもセキュリティオートメーションの活動に貢献してきており、 具体的なオペレーションの自動化を実現していくための研究開 発を進めている Thank you.