1、 ETSI GS INS 009 V1.1.1 (2012-09) Identity and access management for Networks and Services (INS); Security and privacy requirements for collaborative cross domain network monitoring Disclaimer This document has been produced and approved by the Identity and access management for Networks and Service
2、s ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. Group Specification ETSI ETSI GS INS 009 V1.1.1 (2012-09) 2Reference DGS/INS-009 Keywords access control, data
3、sharing, multi-party computation, network monitoring, policies, policy management, privacy, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sou
4、s-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between s
5、uch versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subj
6、ect to revision or change of status. Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETS
7、I_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2012. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ET
8、SI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTETMare Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI GS INS 009
9、 V1.1.1 (2012-09) 3Contents Intellectual Property Rights 5g3Foreword . 5g3Introduction 5g31 Scope 6g32 References 6g32.1 Normative references . 6g32.2 Informative references 6g33 Abbreviations . 9g34 Scenario description and basic concepts 9g34.1 Cooperative incident handling by network operators .
10、10g34.2 Cooperative incident handling among enterprises 11g34.3 Cooperative anomaly and misuse detection . 11g35 Sharing schemes used in cooperative incident handling 11g35.1 Annotated Sharing Schemes . 12g35.2 Trusted-Third-Party Sharing Schemes . 13g35.3 Secure Sharing Schemes 13g36 Requirements 1
11、4g36.1 Business requirements 14g36.1.1 Confidentiality of business-sensitive data . 14g36.1.2 Impact on network operations . 14g36.1.2.1 Roles . 14g36.1.2.2 Same domain operations . 14g36.1.2.3 Cross-domain operations. 14g36.1.2.4 Legacy systems . 15g36.2 Regulatory requirements 15g36.2.1 Lawfulness
12、 of data processing 15g36.2.2 Purposes for which data are processed . 15g36.2.3 Necessity, adequacy and proportionality of the data processed 15g36.2.4 Quality of the data processed 15g36.2.5 Minimal use of personal identification data 15g36.2.6 Storage of personal data 15g36.2.7 Data retention 15g3
13、6.2.8 Access limitation 16g36.2.9 Information to and rights of the data subject 16g36.2.10 Consent of the data subject . 16g36.2.11 Data security measures . 16g36.2.12 Special categories of data . 16g36.2.13 Coordination with competent Data Protection Authority . 16g36.2.14 Supervision and sanctions
14、 . 16g36.2.15 Communications confidentiality . 17g36.2.16 Dissemination of data to third parties . 17g36.2.17 Transfer of data to third countries . 17g36.2.18 Flexibility and adaptability of legal compliance provisions . 17g36.3 Technical requirements 17g36.3.1 Privacy requirements 17g36.3.1.1 Purpo
15、se specification and binding . 17g36.3.1.2 Necessity, adequacy and proportionality . 18g36.3.1.3 Cooperation with third parties . 18g36.3.1.4 Complementary actions . 18g36.3.1.5 Data storage and retention . 18g36.3.1.6 Data protection mechanisms . 18g36.3.1.7 Access control . 19g3ETSI ETSI GS INS 00
16、9 V1.1.1 (2012-09) 46.3.1.8 Semantics 19g36.3.2 Security requirements . 19g36.3.2.1 Confidentiality 19g36.3.2.2 Integrity . 19g36.3.2.3 Availability 19g36.3.2.4 Backup 19g36.3.2.5 Access audit logs . 19g36.3.2.6 Network Segmentation 20g37 Available solutions and gaps 20g37.1 Incident information sha
17、ring (IETF INCH and MILE) 20g37.1.1 The Incident Object Description Exchange Format - IODEF . 20g37.1.2 Real-time Inter-network Defense RID . 21g37.1.3 Applicability to collaborative cross-domain network monitoring 21g37.2 Access Control . 21g37.3 Secure multiparty computation and other cryptographi
18、c approaches . 23g38 Conclusion 23g3Annex A (informative): Authors Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/ipr.etsi.org). Pursuant to the ETSI IP
19、R Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword Thi
20、s Group Specification (GS) has been produced by ETSI Industry Specification (ISG) Identity and access management for Networks and Services (INS). Introduction The threat landscape of todays Internet is characterized by highly distributed attacks (e.g. botnets) which leverage and target multiple doma
21、ins. Attackers do not care about boundaries between networks and jurisdictions; malware and cyber-attacks are criminal activities focused in having the best tools for the intended purpose (e.g. information theft, extortion), while remaining difficult to detect and defend against. Spreading malware a
22、s widely as possible across multiple networks is an effective tactic to this end, in large part because current detection and mitigation measures are taken from a the point of view of a single administrative domain; each operator or enterprise fights the threats locally, with limited or non-existent
23、 collaboration with other peers. Collaborative cross-domain network monitoring and mitigation seems to be a natural approach to fight these threats more efficiently. This approach includes technical solutions delivering distributed processing and computation, protocols, and data exchange allowing ne
24、twork operators to cooperate in network security monitoring efforts in a dynamic and efficient manner. This collaboration allows the scaling the defensive measures to the same level as those applied by the attackers. A keystone in this cross-domain collaboration is the communication and sharing of m
25、onitoring information among network operators, but this is limited by many factors: Network operators are not eager to share information about their operations, especially sensitive data such as event logs from intrusion detection systems for a variety of reasons, including privacy, regulatory compl
26、iance, and protection of information of commercial value. Current collaborative procedures are slow human-driven communications, as there are limited solutions available in the market for collaborative network defence. Research in the field is ongoing; there is little work to date on providing a hol
27、istic view of the problem and its potential solution (the state of the art in applicable research is explored in clause 7 of the present document). The purpose of the present document is: 1) to assess the context of any potential data exchange among different network operators, from different points
28、 of view (technical, regulatory, business) and extract security and privacy requirements to govern those exchanges; 2) to identify existing technologies, protocols and specifications helping to fulfil the defined requirement; and 3) to identify the gaps and to propose new technologies and protocols
29、to fill them. ETSI ETSI GS INS 009 V1.1.1 (2012-09) 61 Scope The present document places some general requirements applying on any security monitoring data exchange aiming at cross-domain detection and mitigation. 2 References References are either specific (identified by date of publication and/or
30、edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected
31、location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are necessary for the application of the p
32、resent document. Not applicable. 2.2 Informative references The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 SEPIA library. NOTE: Available at http:/sepia.ee.ethz.ch/. i.2 CoRR abs/
33、1101.5509 (2011): “Reduce to the max: A simple approach for massive-scale privacy-preserving collaborative network measurements (extended version)“, F. Ricciato and M. Burkhart. i.3 IETF RFC 5070 (December 2007): “The Incident Object Description Exchange Format“, R. Danyliw, J. Meijer, and Y. Demche
34、nko. i.4 IETF RFC 6545 (April 2012): “Real-time Inter-network Defense (RID)“, K. Moriarty. i.5 IETF RFC 6546 (April 2012): “Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS“, B. Trammell. i.6 draft-ietf-mile-sci-02.txt: “IODEF-extension to support structured cybersecurity in
35、formation“, February 2012. i.7 IETF RFC 6235 (May 2011): “IP Flow Anonymization Support“, E. Boschi, B. Trammell. i.8 IETF RFC 5101 (January 2008): “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information“, B. Claise (ed.). i.9 IETF RFC 5655 (
36、October 2009): “Specification of the IP Flow Information Export (IPFIX) File Format“, K B. Trammell, E. Boschi, L. Mark, T. Zseby and A. Wagner. i.10 In 19th USENIX Security Symposium (August 2010): “SEPIA: Privacy-Preserving Aggregation of Multi Domain Network Events and Statistics“, M. Burkhart, M
37、. Strasser, D. Many and X. Dimitropoulous. ETSI ETSI GS INS 009 V1.1.1 (2012-09) 7i.11 Computer Law rather, the collaborative monitoring service shall be specified in terms of interfaces between domains, leaving every domain in charge of deploying or running its own preferred internal monitoring sys
38、tem. 2) The information to be exchanged across domain is not necessarily limited to the sharing of actual monitoring data, meta-data, or alarms/reports (although especially this latter is the most obvious use case), but may extend (or conversely, restrict) to the exchange of pre-processed and/or sui
39、tably encrypted information which can be used to perform a joint (i.e. cooperative) detection of events or anomalies. ETSI ETSI GS INS 009 V1.1.1 (2012-09) 103) The collaborative cross-domain monitoring service should not specify a set of pre-established monitoring tasks or specific types of data to
40、 be shared, but should rather provide interfaces and control primitives to permit involved domains (or a subset of) to agree on, and correspondingly deploy a cooperative monitoring task or use-case. Thus, the focus is on the framework, rather than on the specific application to a target precise moni
41、toring goal (such as Botnet detection, DDoS mitigation, fraud detection, anomaly detection, etc). Unless otherwise specified, in what follows for simplicity we consider the scenario depicted in figure Figure 1, involving just two domains (owned by two different ISPs/Operators). In this reduced scena
42、rio we focus on the particularities of the proposed communication. Any reasoning for this scenario may be extended to situations with more participants like the one presented above, but we use this one as a starting point for the sake of clarity and simplicity. Figure 1 Communication between two dom
43、ains Each domain may have its own monitoring systems composed by an array of tools and solutions (network probes, SIEMs, IDS, etc.) Details of those systems are out of the scope of the present document, but we assume that they are providing alarms, security events, etc. comprising the detection info
44、rmation. This information, which is today customarily used for internal consumption only, now may be shared with the other peer through a dedicated cross-domain interface. Exchange of information further comprises, when applicable, mitigation information, as well as control information needed to sup
45、port more advanced cooperative and sharing schemes (e.g. cryptography based). Specific variants of this scenario are elaborated below. 4.1 Cooperative incident handling by network operators “Operator A,“ a country-wide operator, with a large data network, is concerned about their infrastructure. The
46、refore they have signed an agreement with other carriers to share relevant security-related incident information in order to improve the detection of distributed threats. Operator A is providing security events detected locally in its network by its security systems, composed of a wide array of moni
47、toring probes, IDS, collectors, etc. In exchange, Operator A receives similar information coming from the other operators in the consortium. Operator A is using these data to feed its already existing correlation systems, getting a broader view with data that originate from other domains and improvi
48、ng the detection rate and/or the characterization of certain attacks with this information. So the information is spread “globally“ and used locally by each member of the consortium according to their own preference. Eventually, Operator A is detecting some traffic volume in the order of several Gig
49、abits per secondconverging on some few nodes of its infrastructure, which is having some impact on the performance of some services offered to customers. Beyond taking the appropriate countermeasures to mitigate that attack on those nodes, Operator A is not able to characterize the whole attack since it is highly distributed and really complex to track down, but decides to share this incident with other operators. The other operators receive the incident information and correlate it with their current traffic activity in their networks, resultin
