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

DGS/INS-009

General Information

• Status: Published
• Publication Date: 27-Sep-2012
• Technical Committee: INS - Identity and access management for Networks and Services
• Current Stage: 12 - Completion
• Due Date: 10-Oct-2012
• Completion Date: 28-Sep-2012

Standards Content (Sample)

Group Specification
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 Services 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.

2 ETSI GS INS 009 V1.1.1 (2012-09)

Reference
DGS/INS-009
Keywords
access control, data sharing, multi-party
computation, network monitoring, policies, policy
management, privacy, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture 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 such 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 subject 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/ETSI_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.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are 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
3 ETSI GS INS 009 V1.1.1 (2012-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 9
4 Scenario description and basic concepts . 9
4.1 Cooperative incident handling by network operators . 10
4.2 Cooperative incident handling among enterprises . 11
4.3 Cooperative anomaly and misuse detection . 11
5 Sharing schemes used in cooperative incident handling . 11
5.1 Annotated Sharing Schemes . 12
5.2 Trusted-Third-Party Sharing Schemes . 13
5.3 Secure Sharing Schemes . 13
6 Requirements . 14
6.1 Business requirements . 14
6.1.1 Confidentiality of business-sensitive data . 14
6.1.2 Impact on network operations . 14
6.1.2.1 Roles . 14
6.1.2.2 Same domain operations . 14
6.1.2.3 Cross-domain operations . 14
6.1.2.4 Legacy systems . 15
6.2 Regulatory requirements . 15
6.2.1 Lawfulness of data processing . 15
6.2.2 Purposes for which data are processed . 15
6.2.3 Necessity, adequacy and proportionality of the data processed . 15
6.2.4 Quality of the data processed . 15
6.2.5 Minimal use of personal identification data . 15
6.2.6 Storage of personal data . 15
6.2.7 Data retention . 15
6.2.8 Access limitation . 16
6.2.9 Information to and rights of the data subject . 16
6.2.10 Consent of the data subject . 16
6.2.11 Data security measures . 16
6.2.12 Special categories of data . 16
6.2.13 Coordination with competent Data Protection Authority . 16
6.2.14 Supervision and sanctions . 16
6.2.15 Communications confidentiality . 17
6.2.16 Dissemination of data to third parties . 17
6.2.17 Transfer of data to third countries . 17
6.2.18 Flexibility and adaptability of legal compliance provisions . 17
6.3 Technical requirements . 17
6.3.1 Privacy requirements . 17
6.3.1.1 Purpose specification and binding . 17
6.3.1.2 Necessity, adequacy and proportionality . 18
6.3.1.3 Cooperation with third parties . 18
6.3.1.4 Complementary actions . 18
6.3.1.5 Data storage and retention . 18
6.3.1.6 Data protection mechanisms . 18
6.3.1.7 Access control . 19
ETSI
4 ETSI GS INS 009 V1.1.1 (2012-09)
6.3.1.8 Semantics . 19
6.3.2 Security requirements . 19
6.3.2.1 Confidentiality . 19
6.3.2.2 Integrity . 19
6.3.2.3 Availability. 19
6.3.2.4 Backup . 19
6.3.2.5 Access audit logs . 19
6.3.2.6 Network Segmentation . 20
7 Available solutions and gaps . 20
7.1 Incident information sharing (IETF INCH and MILE) . 20
7.1.1 The Incident Object Description Exchange Format - IODEF . 20
7.1.2 Real-time Inter-network Defense – RID . 21
7.1.3 Applicability to collaborative cross-domain network monitoring . 21
7.2 Access Control . 21
7.3 Secure multiparty computation and other cryptographic approaches . 23
8 Conclusion . 23
Annex A (informative): Authors & contributors . 24
History . 25

ETSI
5 ETSI GS INS 009 V1.1.1 (2012-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); 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 IPR 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
This 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 today's Internet is characterized by highly distributed attacks (e.g. botnets) which leverage and
target multiple domains. 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 as 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 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 network 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 monitoring
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 compliance,
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 holistic 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
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 to fill them.
ETSI
6 ETSI GS INS 009 V1.1.1 (2012-09)
1 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 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 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 present 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/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. Demchenko.
[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 information",
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 (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. Strasser, D. Many and
X. Dimitropoulous.
ETSI
7 ETSI GS INS 009 V1.1.1 (2012-09)
[i.11] Computer Law & Security Report 24(6), 508-520 (2008): "The EU Data Protection Directive: An
engine of a global regime", Birnhack, M.
[i.12] Directive 2006/24/EC, European Parliament and of the Council of 15 March 2006 on the retention
of data generated or processed in connection with the provision of publicly available electronic
communications services or of public communications networks and amending
Directive 2002/58/EC, Official Journal of the European Communities, No. L 105, April 2006,
pp. 54-63. 2006/24/EC.
[i.13] Directive 2002/58/EC, European Parliament and of the Council concerning the processing of
personal data and the protection of privacy in the electronic communications sector (Directive on
privacy and electronic communications), Official Journal of the European Communities,
No. L 201, pp. 37-47, July 2002.
[i.14] Commission Decision 2000/520/EC of 26 July 2000 pursuant to Directive 95/46/EC of the
European Parliament and of the Council (Safe harbor principle).
[i.15] "Access control: Policies, models, and mechanisms": in FOSAD 2000: Foundations of Security
Analysis and Design, Vol. 2171 of Lecture Notes in Computer Science, Springer, Berlin,
Heidelberg, 2001, pp. 137-196, P. Samarati, S. D. C. di Vimercati.
[i.16] IEEE Computer 29, 2 (February 1996), pp.38-47: "Role-based access control models",
R.S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman.
[i.17] OASIS: "eXtensible Access Control Markup Language (XACML) 2.0", February 2005.
NOTE: Available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml.
[i.18] "Leveraging Access Control for Privacy Protection: A Survey": in Privacy Protection Measures
and Technologies in Business Organizations: Aspects and Standards, , (Ed.), pp. 65-94, 2012,
IGI Global, ISBN: 978-161-3505-014, G. Yee, A. Antonakopoulou, G. V. Lioudakis, F. Gogoulos,
D. I. Kaklamani, I. S. Venieris.
[i.19] "Hippocratic databases": in: VLDB '02: Proceedings of the 28th international conference on Very
Large Data Bases, VLDB Endowment, 2002, pp. 143-154, R. Agrawal, J. Kiernan, R. Srikant,
Y. Xu.
[i.20] "Purpose based access control for privacy protection in relational database systems": the VLDB
Journal 17 (4) (2008) 603-61 9, J.-W. Byun, N. Li.
[i.21] "Limiting Disclosure in Hippocratic databases": in Proceedings of the 30th International
Conference on Very Large Databases (VLDB' 2004), pp.108-119, Toronto, Canada,
August 31-September 3, 2004, K. LeFevre, R. Agrawal, V. Ercegovac, R. Ramakrishnan, Y. Xu,
D. DeWitt.
[i.22] "Exploiting cryptography for privacy-enhanced access control: A result of the prime project":
Journal of Computer Security 18 (1) (2010) 123-160, C. A. Ardagna, J. Camenisch, M. Kohlweiss,
R. Leenes, G. Neven, B. Priem, P. Samarati, D. Sommer, M. Verdicchio.
[i.23] "PuRBAC: Purpose-aware role-based access control": in R. Meersman, Z. Tari (Eds.), On the
Move to Meaningful Internet Systems: OTM 2008, Vol. 5332 of Lecture Notes in Computer
Science, Springer, 2008, pp. 1104-1121, A. Masoumzadeh, J. Joshi.
[i.24] "Privacy-aware role-based access control": ACM Transactions on Information and System
Security 13 (3) (2010) 1-31, Q. Ni, E. Bertino, J. Lobo, C. Brodie, C.-M. Karat, J. Karat,
A. Trombetta.
[i.25] "Organization Based Access Control": in: 4th IEEE International Workshop on Policies for
Distributed Systems and Networks (Policy"03), 2003, pp. 120-131, lake Come, Italy,
A. Abou-El-Kalam, R. E. Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A. Miège,
C. Saurel, G. Trouessin.
[i.26] "Modeling Contextual Security Policies": International Journal of Information Security 7 (4)
(2008) 285-305, F. Cuppens, N. Cuppens-Boulahia.
ETSI
8 ETSI GS INS 009 V1.1.1 (2012-09)
[i.27] "Dynamic deployment of context-aware access control policies for constrained security devices":
Journal of Systems and Software 84 (2011) pp. 1144-1159, S. Preda, F. Cuppens,
N. Cuppens-Boulahia, J. Garcia-Alfaro, L. Toutain.
[i.28] "Contextual privacy management in extended role based access control model": in
J. Garcia-Alfaro, G. Navarro-Arribas, N. Cuppens-Boulahia, Y. Roudier (Eds.), Data Privacy
Management and Autonomous Spontaneous Security, Vol. 5939 of Lecture Notes in Computer
Science, Springer, 2010, pp. 121-135, N. Ajam, N. Cuppens-Boulahia, F. Cuppens.
[i.29] "Privacy-aware access control and authorization in passive network monitoring infrastructures": in
CIT 2010: Proceedings of the 10th IEEE International Conference on Computer and Information
Technology, 2010, F. Gogoulos, A. Antonakopoulou, G. V. Lioudakis, A. S. Mousas,
D. I. Kaklamani, I. S. Venieris.
[i.30] "Legislation-aware privacy protection in passive network monitoring": in I. M. Portela,
M. M. Cruz-Cunha (Eds.), Information Communication Technology Law, Protection and Access
Rights: Global Approaches and Issues, IGI Global, 2010, Ch. 22, pp. 363-383, G. V. Lioudakis,
F. Gaudino, E. Boschi, G. Bianchi, D. I. Kaklamani, I. S. Venieris.
[i.31] "A Contextual Privacy-Aware Access Control Model for Network Monitoring Workflows: Work
in Progress": in Proceedings of the 4th MITACS Workshop on Foundations & Practice of Security
(FPS), Paris, France, May 12 - 13, 2011, LNCS, Vol. 6888, Springer-Verlag,
E. I. Papagiannakopoulou, M. N. Koukovini, G. V. Lioudakis, J. Garcia-Alfaro, D. I. Kaklamani,
I. S. Venieris.
[i.32] "How to share a secret": Communications of the ACM vol. 22 (1979), pp. 612-613, A. Shamir.
[i.33] "Completeness theorems for non-cryptographic fault-tolerant distributed computation": in
Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing, STOC '88,
pages 1-10. ACM, 1988, M. Ben-Or, S. Goldwasser and A. Wigderson.
[i.34] "How to generate and exchange secrets": in Foundations of Computer Science, 1986, 27th Annual
Symposium on, pages 162-167, 1986, A. C. Yao.
[i.35] "How to play any mental game": in Proceedings of the nineteenth annual ACM Symposium on
Theory of Computation, STOC '87, pp. 218-229. ACM, 1987, O. Goldreich, S. M. Micali and
A. Wigderson.
[i.36] "Fully homomorphic encryption using ideal lattices": in Proceedings of the 41st annual ACM
Symposium on Theory of Computing, STOC '09, pages 169-178. ACM, 2009, C. Gentry.
[i.37] "Asynchronous multiparty computation: Theory and implementation":
in PKC, pp. 160-179, 2009, I. Damgard, M. Geisler, M. Krigaard and J: B. Nielsen.
[i.38] "Fairplaymp: A system for secure multi-party computation": in Proceedings of the 15th ACM
Conference on Computer and Communications Security, CCS '08, pages 257-266. ACM, 2008,
A. Ben-David, N. Nisan and B. Pinkas.
[i.39] "P4P: Practical Large-Scale Privacy-Preserving Distributed Computation Robust against Malicious
Users": in The 19th USENIX Security Symposium, August 11-13, 2010, Washington, D.C.,
Y. Duan, J. Canny and J. Zhan
[i.40] "Assisting Server for Secure Multi-Party Computation": 6th Workshop in Information Security
Theory and Practice, June 19-22 2012, Egham, UK, J.-M. Bohli, W. Li, J. Seedorf.
[i.41] "Enabling conditional cross-domain data sharing via a cryptographic approach":
th
IEEE 5 International Conference on Internet Multimedia Systems Architecture and Application
(IMSAA), 12-13 Dec. 2011, G. Bianchi, H. Rajabi and M. Sgorlon.
[i.42] "Large-scale collection and sanitization of network security data: risks and challenges": in
Proc. 2006 workshop on New security paradigms. NY, USA: ACM, 2007, pp. 57-64, P. Porras and
V. Shmatikov.
ETSI
9 ETSI GS INS 009 V1.1.1 (2012-09)
[i.43] "Attribute-based encryption for fine-grained access control of encrypted data": in Proceedings of
the 13th ACM conference on Computer and communications security (CCS '06), 2006, V. Goyal,
O. Pandey, A. Sahai and B. Waters.
[i.44] "Ciphertext-Policy Attribute-Based Encryption": in Proceedings of the IEEE Symposium on
Security and Privacy 2007: 321-334, J. Bethencourt, A. Sahai and B. Waters.
[i.45] "Decentralizing Attribute-Based Encryption": EUROCRYPT 2011: 568-588, A. Lewko and
B. Waters.
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
DAC Discretionary Access Control
DDoS Distributed Denial of Service
DNS Domain Name System
DMZ Demilitarised Zone
GCR Globally-Constrained Randomization
GUI Graphical User Interface
IDS Intrusion Detection System
IESG Internet Engineering Steering Group
IODEF Incident Object Description Exchange Format
IP Internet Protocol
IPFIX IP Flow Information Export
ISP Internet Service Provider
IT Information Technology
MAC Mandatory Access Control
QoS Quality of Service
RBAC Role-Based Access Control
RID Real-time Inter-network Defense
SEPIA Security through Private Information Aggregation
SIEM Security Information and Event Management
SMC Secure Multiparty Computation
SOAP Simple Object Access Protocol
TLS Transport Layer Security
TTP Trusted Third Party
XML eXtensible Markup Language
4 Scenario description and basic concepts
The goal of a collaborative cross-domain network monitoring service is to permit multiple (two or more) operators to
mutually exchange information so as to permit each peer to achieve a wider perspective of on-going attacks or
anomalies extending beyond a domain perimeter, hence achieving a more efficient and effective detection and
mitigation. Such a cross-domain network monitoring service is not meant to be defined as a specific solution, but it is
rather meant to specify a general framework, characterized by the following crucial and structural properties:
1) Involved entities (domains) should not be bound to agree on any specific or common choice of internal
monitoring platforms or systems; 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 system.
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 suitably encrypted information which can be
used to perform a joint (i.e. cooperative) detection of events or anomalies.
ETSI
10 ETSI GS INS 009 V1.1.1 (2012-09)
3) The collaborative cross-domain monitoring service should not specify a set of pre-established monitoring tasks
or specific types of data to 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
monitoring 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 scenario 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 domains
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 information. 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 support 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. Therefore
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 monitoring 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 improving 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 Gigabits 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, resulting in the association of the sources and the target of the attack characterizing a
DDoS attack. Although they are not the target of the attack, hosting the elements of a botnet has a severe impact on
their public reliability and reputation, so they also take measures to cut that traffic, causing the end of the attack or at
list some noticeable relief on Operator A's attacked infrastructure.
Thus, both the first immediate victim (Operator A failing to keep the QoS) and the secondary ones (other operators
hosting attacker and losing reputation) obtain some benefit from this collaborative model.
ETSI
11 ETSI GS INS 009 V1.1.1 (2012-09)
4.2 Cooperative incident handling among enterprises
"Bank B," a bank, has a large IT network hosting many critical services. Bank B is really worried about the security of
its services, and, as part of its Security policy, enforces traffic management policies (particularly outbound traffic) in
order to detect data extrusion, malicious users, malware or network traffic that may pose a threat to the security of
neighbouring systems. The final goal here is protecting the service and their users (customers) more than the
infrastructure by anticipating the attack at the origin. Thus, analysing the data received at and sent by the service is
paramount. Since data exfiltration techniques are normally the same in many incidents, they have joined some related
partners (including other banks) in a cooperative initiative focused on sharing incident information. Bank B is using
incident info from other partners to better identify similar events, and the same in the other way round: they are sharing
their own detected incidents to help the others. Moreover, an extrusion detection system is more generally aimed at
identifying successful and unsuccessful attempts to use the resources of a computer system to compromise other
systems so it tries to prevent attacks from being launched in the first place. Collaboration among as many as actors as
possible makes a lot of sense to detect more attacks at the origin and incident sharing let the targeted systems protect
from the attack.
Bank B monitors all its critical services. Eventually, a suspicious activity in one of the services is detected; part of the
outbound traffic seems to be malicious. Immediately, it reports the incident the other enterprises (including relevant
information but also applying some data transformation to comply with privacy restrictions and regulations). Other
partners receive the information and set up security means to protect from the potential attack. The symmetric situation
is also possible: a partner reports a suspicious activity generated in its network and Bank B takes some mitigation
actions to protect from the threat.
4.3 Cooperative anomaly and misuse detection
The two previous variants consider final results at some domain that are shared to others. This last variant considers the
case of intermediate results that are shared to get an overall final result. Let us consider Operator A again; the company
has decided not only to share their own detection results but also to set up real collaborative cross-domain application
with other Telcos. This means that they can create applications that provide larger coverage since they operate with
input data from different domains. This is noticeably different from the first scenario; now we deal with intermediate
data instead of final results. We do not have applications at each operator that are sharing results, but just raw
intermediate data that are analysed by one distributed application.
As a good initial application they decide to deploy a DNS misuse application. Each participant provides data related to
DNS traffic in its network; these data are neither relevant nor conclusive itself but when aggregated with data provided
by the other partners lead to some more relevant results. Each partner computes the results respecting the privacy and
business constraints of the external data and all the partners get finally the same output. Similar collaborative
applications can be developed using any kind of input data that operators are able to share.
5 Sharing schemes used in cooperative incident
handling
In the previous clause we have presented a general scenario and some variations motivating the existence of some
means to exchange information about security incidents between domains. Now we present three different schemas for
that sharing (and many others that we may consider). These schemas are general approaches fitting any general
cross-domain monitoring situations. They apply in one way or another to the described scenarios.
When considering network security monitoring in a multi-domain environment, it becomes necessary to define
additional requirements for the sharing of intermediate or final results across administrative domains or jurisdictional
boundaries. There are three general approaches to cross-domain cooperation in network monitoring. The simplest of
these is the sharing of desensitized final results, where the publisher of the data trusts the recipient to use the results
properly, and not to forward the results to untrusted parties. That is, while there may be transformations done to the data
to reduce their sensitivity while maintaining their utility (e.g. anonymization of IP addresses) and annotations on the
data which describe the data and the expectations the publisher has as to what the recipient may do with the data, there
are not any technical protections on the data. We call these annotated sharing schemes.
ETSI
12 ETSI GS INS 009 V1.1.1 (2012-09)
Several applications require the aggregation, union, or intersection of final results from multiple publishers into a single
shared result, generally to be distributed back to all participating publishers, or more publicly. These applications share
the property that while the information from each publisher is still sensitive, the aggregate or intersection/union, without
attribution, is less so. There are two ways to arrange such applications. First are trusted-third-party (TTP) sharing
schemes, where each publisher hands the sensitive data to a third party trusted by all publishers. This third party then
performs the calculations, and returns or further publishes the final results, destroying the per-publisher data.
Nevertheless, such approaches are in principle unacceptable, because not only sensitive data are disclosed, but also the
third party becomes a warehouse of sensitive information, with the dangerous potential of combining and correlating
this information and, eventually, extracting sensitive meta-information and generating even more sensitive information.
Many of the implications with TTP sharing schemes can be remedied through the application of cryptographic
technology, specifically secret sharing schemes from secure multiparty computation. Here, the TTP is replaced by a
collection of privacy peers operated by the publishers, such that any one entity does not have access to any published
data from any other publisher, or to any intermediate results. Schemes for secure multiparty computation specifically
applicable to cooperative network monitoring include SEPIA [i.1] and GCR [i.2].
The subsequent clauses explore and define requirements for each type of scheme.
5.1 Annotated Sharing Schemes
Annotated sharing schemes refer to any network traffic data sharing schemes between or among organizations in a,
whether manual or automated, wherein the data is annotated to indicate its contents and the preferences which the
publisher has with respect to the use and further publication of the data.
These annotations can take virtually any form: they may be appended explicitly inline, attached externally to the data in
a metadata file, made available via a web service, implicit to an entire collection of data, or even contained in some
contract between the publisher and the recipient.
There are several examples of such schemes. IODEF [i.3], the Incident Object Description Exchange Format, is an
XML format designed for the description and interchange of data about network security incidents. These incident
reports are derived from network traffic measurements as well as information about the involved entities and limited
information about remediation (e.g. "denial of service attack from IP address A, against host B, which is a webserver;
suggest rate-limiting the source address"). RID [i.4] [i.5] adds a protocol atop IODEF for on-line exchange of incident
reports to support cooperative mitigation of network security events.
IODEF provides limited annotations for data sharing restrictions, through its restriction enumeration, which limits
information to "public", "need-to-know", or "private" dissemination, with an additional value "default", which
references an external agreement between the publisher and recipient. Each element of an IODEF document may have a
different restriction, allowing public, redacted versions of IODEF documents to be derived from those containing; note,
however, that the only method of redaction involves the removal of elements. The charter of the IETF MILE working
group includes an internet-draft [i.6] to add additional elements to IODEF for a richer description of data sharing
restrictions; this work is ongoing.
Annotations can also include information about how a particular data set was handled, e.g. [i.7], which adds metadata to
IPFIX exports [i.8] or IPFIX files [i.9] for noting which fields of the exported records are anonymized, and how. This
specifically does not add data handling markers, but would work together with external annotations to provide a
complete picture of the contents of a data set, and what can be done with it.
First, annotations are advisory only, and do not provide any technical protection for the contents of the annotated data.
They should only be used in situations where the publisher explicitly trusts the recipient to follow the data handling
annotations, and that the recipient is competent to protect the data as well as the publisher itself. It is recommended that
such schemes only operate within the framework of an explicit agreement between the publisher and recipient, and that
annotated data only be published to the general public when it contains no sensitive information.
Given the advisory nature of data sharing annotations, the security of data in transit shall be guaranteed though
cryptographic means. When sharing data using protocols which specify a binding to a transport-layer security scheme
(e.g. TLS), as in the case of the RID and IPFIX examples above, the transport-layer security shall be used in order to
guarantee integrity and confidentiality of the
...