セキュリティオペレーション自動化に向けた、 基盤技術と共通インターフェースの構築

高橋健志 情報通信研究機構

1

ISOC-JP Workshop on May 20, 2016

但し書き: 本資料は、英文で作成した別の資料を使いまわしています。そのため、英文が 多数残っておりますが、ご容赦ください。

自己紹介

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&D

St

anda

rdiz

atio

n

本日の内容

1. 背景: セキュリティオートメーションの必要性

2. セキュリティオートメーションの概要

3. 各種標準化団体の活動状況

4. NICTにおける我々の研究開発事例

3

まずは、2015年のサイバーセキュリティをふりかえる

• 様々なセキュリティ脅威が存在し、脅威は拡大傾向 – ランサムウェアの増加 – 標的型攻撃の増加 – Haxposureの登場

• セキュリティインシデントのリスクを最小化すべく、各組織はサ

イバーセキュリティを維持する必要がある – セキュリティインシデント数は毎年増加傾向 – セキュリティインシデントは企業に甚大な損害を与える

4

最近のサイバーセキュリティの概観

Source: “Trends 2016,” ESET

しかしながら、世界的に人材不足であるのが現状

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

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

本日の内容

1. 背景: セキュリティオートメーションの必要性

2. セキュリティオートメーションの概要

3. 各種標準化団体の活動状況

4. NICTにおける我々の研究開発事例

7

Manual operationを自動化することが重要

• Security automation技術はセキュリティオペレーションを自動化し、オペレータの負荷を軽減する

• 「security automation」という言葉は文字通りに捉えると、非常に幅広い

• 「security automation」という言葉はセキュリティ情報を再活用

することによりオペレーションを自動化したいコミュニティに積極的に利用されている用語である

8

“security automation“とは何か？

自動化に必要な第一歩は効率的な情報共有

9

情報共有に必要な進化

We have got a malware

Is it a virus?

It spreads itself

worm?

We have information leakage problem

What is the range of the damage?

Personnel information Evidence preserved?

Please cope with the incident. Classification ID is 3.5.2.

OK

We are in the stage of “information leakage 3.2”

適切な情報交換手法は、コンピュータによる自動化を可能にする

Current, human-dependent operations

OK

それができると、例えば脆弱性管理の自動化が可能

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

多数のSDOが、この課題に取り組んでいる

ITU-R

ISO ETSI

OASIS

ITU-T OMA

CAB forum

TCG

3GPP

MITRE

NIST

APP Dev Forums

IEEE WiFi Forum

IMS forum

Cable Labs

FIRST

CCDB

CNIS

APWG

IETF

本日の内容

1. 背景: セキュリティオートメーションの必要性

2. セキュリティオートメーションの概要

3. 各種標準化団体の活動状況

4. NICTにおける我々の研究開発事例

12

MITRE, NIST, およびFIRSTの規格を紹介する

ITU-R

ISO ETSI

OASIS

ITU-T OMA

CAB forum

TCG

3GPP

MITRE

NIST

APP Dev Forums

IEEE WiFi Forum

IMS forum

Cable Labs

FIRST

CCDB

CNIS

APWG

IETF

これまで、多数の規格が検討されてきた

これらの規格はidentifierやschemaを定義

Some of major Information description specifications

• identifiers for vulnerability information CVE

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

まずはITU-Tの活動を紹介する

ITU-R

ISO ETSI

OASIS

ITU-T OMA

CAB forum

TCG

3GPP

MITRE

NIST

APP Dev Forums

IEEE WiFi Forum

IMS forum

Cable Labs

FIRST

CCDB

CNIS

APWG

IETF

Cybersecurity Information acquisition

Cybersecurity Organization

Cybersecurity Information

use

Cybersecurity Organization

Cybersecurity information exchange

Focus of CYBEX

ITU-T X.1500 (CYBEX) – Scope

ITU-Tでは情報交換のフレームワークを定義

ITU-Tはこの情報交換技術の重要性を強く認識

18

ITU-T Rec. X.1500 series

Reserved for the future

いくつかの勧告は、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

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

次に、IETFでの活動を紹介する

ITU-R

ISO ETSI

OASIS

ITU-T OMA

CAB forum

TCG

3GPP

MITRE

NIST

APP Dev Forums

IEEE WiFi Forum

IMS forum

Cable Labs

FIRST

CCDB

CNIS

APWG

IETF

4つのWGがセキュリティオートメーションを検討

22

Secu

rity

Auto

mat

ion

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

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..*

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

Com

plet

ed

Wor

k-in

-pro

gres

s

2

• RFC 6684 – Extension Guidelines and Template

• RFC-7495 – IODEF Enumeration Reference Format

24

• XMPP-based IODEF exchange

6

Data representation

Transport

Guidelines

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

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

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

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

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.

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

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

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

I2NSFの目指しているもの

I2NSF WGは、NSFを制御・監視するための 情報・データモデルと、ソフトウェアインターフェースを定義する

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

I2NSFのユースケース

Source: draft-pastor-i2nsf-merged-use-cases-00.txt, slides-93-i2nsf-3.pdf

Installation and configuration Updating Collecting status Validation

ITU-R

ISO ETSI

OASIS

ITU-T

OMA CAB

forum TCG

3GPP

MITRE

NIST APP Dev

Forums

IEEE WiFi

Forum

IMS forum

Cable Labs

FIRST

CCDB

CNIS

APWG

OASISでの検討状況

IETF

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.

CybOX:サイバー攻撃観測記述形式

38 Source: 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内での記述手法として活用

CybOXで記述できる内容例

39 Source: https://cybox.mitre.org/

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) : 脅威に対応するための対策手順

STIXはcore constructsとそれらの関係性を定義

41 Source: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti

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 ………..

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

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”

セキュリティ情報レポジトリはすでに複数存在

• 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

本日の内容

1. 背景: セキュリティオートメーションの必要性

2. セキュリティオートメーションの概要

3. 各種標準化団体の活動状況

4. NICTにおける我々の研究開発事例

46

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

Darknet M

onitoring Livenet M

onitoring

47

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

NICTER

NICTERシステムは観測がベース

50

Atlas

Cube Tiles

システムの概要

51

NICTER

: Darknet : Livenet

Internal Darknet Alert (Local Scan)

52

NICTER

: Darknet : Livenet

: Infected Host

External Darknet Alert (Global Scan)

53

: Darknet : Livenet

: Infected Host

NICTER

Darknet Traffic

External Darknet Alert (Backscatter)

54

NICTER

Darknet Traffic

: Darknet : Livenet

: DDoS Victim

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;

オペレータ

Overview of “NIRVANA Kai”

56

NIRVANA Kai

Interface for accessing DB

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

Analysis engine

Analysis engine

Analysis engine

Data bus

Mirror traffic

Traffic collection system

Gate Sensor

Multifaceted defense system

Countermeasure candidate extraction engine

Countermeasure engine

対策の自動化プロトタイプを構築

Filter anomalous traffic

Scan a host

Drop all traffic

57

A demo scenario

本日の内容

1. 背景: セキュリティオートメーションの必要性

2. セキュリティオートメーションの概要

3. 各種標準化団体の活動状況

4. NICTにおける我々の研究開発事例 1. Traffic anomaly detection and triage using our darknet

sensors 2. Automated vulnerability management

58

知識ベース (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)

典型的なシステム構成

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

プロセスの概要

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

スナップショット (1/3)

スナップショット (2/3)

スナップショット (3/3)

管理者にアラートを送信

65

まとめ

1. 人材不足に対応するには、セキュリティオートメーションが重要との認識は徐々に広がってきている

2. 各種標準化団体は共通インターフェースの構築に注力している 3. 情報/データのスキーマについて多数の検討がなされてきたが、

今後は、それらをどのように利用し、実際のオペレーションを如何に自動化していくかの検討が求められている

4. NICTもセキュリティオートメーションの活動に貢献してきており、

具体的なオペレーションの自動化を実現していくための研究開発を進めている

Thank you.