idnits 2.17.1
draft-daisuke-iodef-experiment-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([RFC5070]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (February 12, 2014) is 3719 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970)
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MILE Working Group D. Miyamoto
3 Internet-Draft UTokyo
4 Intended status: Experimental T. Takahashi
5 Expires: August 16, 2014 NICT
6 February 12, 2014
8 Knowledge obtained from the implementation experience of an IODEF-
9 capable incident response management system
10 draft-daisuke-iodef-experiment-00.txt
12 Abstract
14 This document explains our observation on the usability of IODEF
15 [RFC5070], based on our experiments. We aim at developing an IODEF-
16 capable incident response management systems in order to facilitate
17 incident response activities. We started to design and implement the
18 system for our university CERT, however, there are several technical
19 issues while implementing and operating the system. This document
20 shares the observation from our proto-type implementation and
21 provides new sight from operational aspects.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on August 16, 2014.
40 Copyright Notice
42 Copyright (c) 2014 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3
60 4. Operational Issues . . . . . . . . . . . . . . . . . . . . . 4
61 4.1. type attribute @ Impact class . . . . . . . . . . . . . . 5
62 4.2. category attribute @ NodeRole Class . . . . . . . . . . . 5
63 4.3. action attribute @ Expectation Class . . . . . . . . . . 5
64 4.4. Potential information leakage . . . . . . . . . . . . . . 5
65 4.5. Configuration of Nodes . . . . . . . . . . . . . . . . . 5
66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
68 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
72 9.2. Informative References . . . . . . . . . . . . . . . . . 6
73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
75 1. Introduction
77 The number of incidents in cyber society is growing day by day.
78 Incident information needs to be reported, exchanged, and shared
79 among organizations in order to cope with the situation. IODEF
80 provides a scheme to describe and exchange incident response
81 information among interested parties.
83 For our university CERT, we decided to introduce an IODEF-capable
84 incident response management system to facilitate incident response
85 activities. Our university has two types of CERT, namely, a central
86 CERT and divisional CERTs. The former is a contact point for
87 external organizations, and the latter is a CERT for each division in
88 the university. When the central CERT receives such information, it
89 notifies the information to the corresponding divisional CERT who has
90 an accountability for decision and actions.
92 Our old system employed emails for exchanging the information between
93 the central and divisional CERTS, however, we started to employ
94 machine-readable message in regard to the growing demand for
95 automated incident response systems. For doing so, we attempted to
96 implement an IODEF-capable incident response management system.
98 In our implementation, we encountered problems while dealing with XML
99 schema. To save the development cost, we employed code generators
100 that build class libraries for accessing values in IODEF elements.
101 Due to the complexity of IODEF message format defined in [RFC5070],
102 some code generators could not understand its schema.
104 We also found some operational problems as well as the implementation
105 problem. Most of the problems were on the choice of values for IODEF
106 attributes and/or elemens.
108 This draft provides how we evade the implementation problem, and
109 explores the suitable value for XML element in regard to the
110 incidents.
112 2. Terminology
114 The terminology used in this document follows the one defined in
115 [RFC5070].
117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
119 document are to be interpreted as described in [RFC2119].
121 3. Implementation
123 Since a code generator for XSD automatically develops useful
124 libraries for accessing XML attributes and/or composing messages, we
125 tested following generators to build the libraries from RFC 5070
126 [RFC5070] .
128 o XML::Pastor [XSD:Perl] (Perl)
130 o RXSD [XSD:Ruby] (Ruby)
132 o PyXB [XSD:Python] (Python)
134 o JAXB [XSD:Java] (Java)
136 o CodeSynthesis XSD [XSD:Cxx] (C++)
138 o Xsd.exe [XSD:CS] (C#)
140 We thought we can use them to generate IODEF, but they cannot be
141 easily used. For instance, we have used XML::Pastor, but it could
142 not properly understand its schema due to the complexity of IODEF
143 XSD. The same applies to RXSD and JAXB. Only PyXB, CodeSynthesis
144 XSD and Xsd.exe were able to understand the schema.
146 To cope with the situation, we have made a trick, which is not
147 recommended, but is one option to go through the situation. That is,
148 "XSD2XML2XSD", which means that XSD is converted to XML, and it is
149 again converted to XSD. The resultant XSD was process-able by the
150 all tools above.
152 Nevertheless, the generated module was unworkable. This is due to
153 the fact that IODEF uses '-' (hyphen) symbols in its classes or
154 attributes, listed as follows.
156 o IODEF-Document Class; it is the top level class in the IODEF data
157 model described in section 3.1 of [RFC5070].
159 o The vlan-name and vlan-num Attribute; according to section 3.16.2
160 of [RFC5070], they are the name and number of Virtual LAN and are
161 the attributes for Address class.
163 o Extending the Enumerated Values of Attribute; according to section
164 5.1 of [RFC5070], it is a extension techniques to add new
165 enumerated values to an attribute, and has a prefix of "ext-",
166 e.g., ext-value, ext-category, ext-type, and so on.
168 According to the language specification, Perl classes and/or
169 functions could not contain '-' symbols in their names. We replaced
170 hyphens with '_' (underscore) symbols to evade this issue. Before
171 outputting an IODEF format message, our system must manually replace
172 these renamed characters in its serialization process.
174 Aside from the case of Perl, other language tend to evade using any
175 hyphens in its name space. PyXB and CodeSynthesis XSD automatically
176 replaced hyphen with underscore symbols, and JAXB and Xsd.exe simply
177 removed hyphens. These tools also might output an exact IODEF
178 message format through their serialization process. RXSD was similar
179 to JAXB and Xsd.exe, replaced with hyphens automatically, but did not
180 support converting the renamed characters for outputting.
182 4. Operational Issues
184 This section explains some pitfalls while assigning values for IODEF-
185 based XML elements. Mainly, our central CERT notifies the incident
186 information to the issued divisional CERT, and the divisional CERT
187 reports the results of forensics. Based on this situation, we found
188 several cases that we were not sure about which attributes should be
189 chosen.
191 4.1. type attribute @ Impact class
193 Various incident classification exist. For instance, JPCERT proposes
194 the following classification: phishing site, page hijack, malware
195 propagation, scan, DoS/DDoS, and control systems. Nevertheless, it
196 is hard to fit them into the type attribute of theimpact class.
198 For example, phishing site, scan, and DoS/DDoS might be mapped as
199 "social-engineering", "recon", and "dos" attributes in respectively.
200 In the rest of cases, what the type of the attribute should we
201 choose?
203 4.2. category attribute @ NodeRole Class
205 IODEF has category attribute for NodeRole class. Though various
206 categories are described, they are not enough. For instance, we
207 sometime report the category of "proxy server" in our daily CERT
208 operation, but which one am we supposed to choose? How about web
209 mail? Should we choose "www"? or "mail"?
211 4.3. action attribute @ Expectation Class
213 Assuming if the notifier sends a message with expecting to forensic
214 for the issues, and the reporter answers the result of their
215 forensics. In such cases, the notifiers would choose
216 "investigation", but what types of action attribute should the
217 reporter choose? Should the reporter choose "nothing" ?
219 When a notifier sends IODEF document, the report wishes to confirm it
220 without asking any further actions. Then what values shall we
221 choose?
223 4.4. Potential information leakage
225 The numbering of Incident ID needs to be considered. Otherwise,
226 information, such as the number of incidents within certain period
227 could be observed by document receivers. For instance, we could
228 randomize the assignment of the numbers.
230 4.5. Configuration of Nodes
232 Node class can describe various information of the system, but the
233 level of information granularity there is not defined. It could be
234 that very detailed information is needed, or it could be the
235 opposite. It has the field of the software id and configid, but the
236 formats for them are not specifically defined.
238 It is natural to guess that we cannot define single, common level of
239 information granularity. Depending on situation and operation, the
240 needed level of information granularity differs.
242 Thus one approach is using IODEF-SCI, which can choose arbitrary
243 schema to describe the details of such information.
245 5. Security Considerations
247 This document raises no security issues itself. The potential
248 security issues are the vulnerabilities in the class libraries
249 constructed by code generators.
251 6. IANA Considerations
253 This document contains no considerations for IANA.
255 7. Conclusions
257 The document explains the implemetation issue, the problems raised
258 from code generation, and the operational issue, the problems while
259 choosing the value in XML elements for IODEF format messages.
261 8. Acknowledgements
263 Many thanks for feedback from Tomohiro Ishihara for his comments.
264 This work is materially supported by the Ministry of Internal Affairs
265 and Communication, Japan, and by the European Union Seventh Framework
266 Programme (FP7/2007-2013) under grant agreement No. 608533 (NECOMA).
268 9. References
270 9.1. Normative References
272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
273 Requirement Levels", BCP 14, RFC 2119, March 1997.
275 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
276 Object Description Exchange Format", RFC 5070, December
277 2007.
279 9.2. Informative References
281 [XSD:Perl]
282 Ulsoy, A., "XML::Pastor",
283 .
285 [XSD:Ruby]
286 Morsi, M., "RXSD - XSD / Ruby Translator", .
289 [XSD:Python]
290 Bigot, P., "PyXB: Python XML Schema Bindings", .
293 [XSD:Java]
294 Project Kenai, "JAXB Reference Implementation", .
297 [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++",
298 .
300 [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
301 .
303 Authors' Addresses
305 Daisuke Miyamoto
306 The University of Tokyo
307 2-11-16 Yayoi Bunkyo-Ku
308 113-8658 Tokyo
309 Japan
311 Phone: +80 3 5841 0836
312 Email: daisu-mi@nc.u-tokyo.ac.jp
314 Takeshi Takahashi
315 National Institute of Information and Communications Technology
316 4-2-1 Nukui-Kitamachi Koganei
317 184-8795 Tokyo
318 Japan
320 Phone: +80 423 27 5862
321 Email: takeshi_takahashi@nict.go.jp