Adding a "Security Information" contact?
Moin-Moin and hello, TL;DR: Should there be an optional contact for sending security information to (i.e. about vulnerable services), which can be different from the abuse contact? Background: We get a reasonable amount of security information sent to our abuse mailbox about things like "There's a vulnerable Confluence server on your network" and "This IP has contacted a botnet C&C server". Technically, this is not an abuse related issue, but still relevant to know and forward to the respective customer. Most of these e-mails originate from our local CERT (in my case CERT-BUND in Germany) but there are some other senders which are informing about these vulnerable services. I guess, most other providers know about these from their local CERTs or other organizations. Our abuse mailbox is not overflowing with these, of course, but it makes semi-automated handling a bit painful. For example, we would like to forward these information to our customers, but we wont need to take further action on this, because we refuse to break into the offices of our customers at night and patch their software. Also, sometimes these reports contain outdated data and the vulnerability has been removed in the time between collecting these information and sending the e-mail. On the other hand, for real abuse like sending spam or participating in DDoS, we also want to forward this information as quick as possible (automated), but also we want to know about and escalate so we can pull the plug if needed. So I wondered, if there (c|sh)ould be an optional contact/role for sending security related information to? This could be a different mailbox which does another automated handling of forwarding this notifications. What is your opinion on this? Greetings Max
Hi, On Tue, Jun 07, 2022 at 11:45:05AM +0200, Max Grobecker wrote:
TL;DR: Should there be an optional contact for sending security information to (i.e. about vulnerable services), which can be different from the abuse contact?
I see the problem, and maybe we need to re-think the definition of admin-c:, tech-c: and abuse-c: Reporters seem to only understand two possible approaches - use abuse-c:, or send to everything whois returns that has an "@" in it. The latter is something I consider borderline abusive, the former is not that helpful for security incident reporting (which might warrant a similarily fast reaction, but from a different team). So, no clear answer, just seconding that we might need to do a bit of work here. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Guys You could add an optional attribute "security-mailbox:" alongside the "abuse-mailbox:". If present it could be returned in a query with the abuse-mailbox address by default, or with a specific query. Or reference it separately with a "sec-c:" attribute. cheers denis co-chair DB-WG On Tue, 7 Jun 2022 at 12:01, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Jun 07, 2022 at 11:45:05AM +0200, Max Grobecker wrote:
TL;DR: Should there be an optional contact for sending security information to (i.e. about vulnerable services), which can be different from the abuse contact?
I see the problem, and maybe we need to re-think the definition of admin-c:, tech-c: and abuse-c:
Reporters seem to only understand two possible approaches - use abuse-c:, or send to everything whois returns that has an "@" in it. The latter is something I consider borderline abusive, the former is not that helpful for security incident reporting (which might warrant a similarily fast reaction, but from a different team).
So, no clear answer, just seconding that we might need to do a bit of work here.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Hi, On Tue, Jun 07, 2022 at 12:35:47PM +0200, denis walker wrote:
You could add an optional attribute "security-mailbox:" alongside the "abuse-mailbox:". If present it could be returned in a query with the abuse-mailbox address by default, or with a specific query. Or reference it separately with a "sec-c:" attribute.
Agree, this would be one of the options. But then, what is admin-c: and tech-c: intended to be used for, today? (Expecting no answers, just pointing out that there is lack of clear understanding) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 07-06-2022 12:42 +0200, Gert Doering wrote:
Hi,
On Tue, Jun 07, 2022 at 12:35:47PM +0200, denis walker wrote:
You could add an optional attribute "security-mailbox:" alongside the "abuse-mailbox:". If present it could be returned in a query with the abuse-mailbox address by default, or with a specific query. Or reference it separately with a "sec-c:" attribute.
Agree, this would be one of the options.
But then, what is admin-c: and tech-c: intended to be used for, today?
(Expecting no answers, just pointing out that there is lack of clear understanding)
Gert Doering -- NetMaster
I don't think the problem would be to add a new attribute if needed. The problem would be to *define* what should go there (and then get everyone downstream to use that new attribute) The line is quite thin. And not every company will group things in the same way. "There's a vulnerable Confluence server on your network" → Vulnerable "This IP has contacted a botnet C&C server" → Compromised "This is sending emails with malware" → Attacking other networks And often it will go in that succession. There was a vulnerable system, that got compromised, and then used to attack third parties. In some cases the same team will handle all of those. Others may have a different team for patching than for dealing with compromised hosts. And others may only stat worrying only after it starts giving problems to others. Regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
Hi, On Tue, Jun 07, 2022 at 11:02:19AM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
I don't think the problem would be to add a new attribute if needed. The problem would be to *define* what should go there (and then get everyone downstream to use that new attribute)
This... so, what would you suggest? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 7 Jun 2022, at 12:14, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Jun 07, 2022 at 11:02:19AM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
I don't think the problem would be to add a new attribute if needed. The problem would be to *define* what should go there (and then get everyone downstream to use that new attribute)
This... so, what would you suggest?
It would be nice, both for abuse contacts, and the potential security contact, to be able to advertise that you accept machine readable reports, what formats and how to accept them. There’s an obvious advantage for the abuse/security desk consuming reports for that, but it would also be an improvement in many ways for generators of reports over the current system where abuse-c contains an email address, and that email address is just an autoresponder saying that mail sent there isn’t read (but there’s this other channel over here you can use). I’ve a nasty feeling that any email address added as a security contact will be used as an additional place to report spam coming from the network, which might not be what the people on the end of that alias really need more of. Cheers, Steve
This is correct but additionally, I don’t see how adding a separate security contact resolves the problem of outdated or misdirected (as in, not from your network) compromise incident reports. You don’t have to break into your customers offices to patch their machines. You can just as well acl those IPs off till your customer has patched the vuln. Might even deploy a walled garden like Comcast implemented over a decade back, if you’re a large SP. --srs ________________________________ From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Steve Atkins <steve@blighty.com> Sent: Tuesday, June 7, 2022 4:50:58 PM To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] Adding a "Security Information" contact?
On 7 Jun 2022, at 12:14, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Jun 07, 2022 at 11:02:19AM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
I don't think the problem would be to add a new attribute if needed. The problem would be to *define* what should go there (and then get everyone downstream to use that new attribute)
This... so, what would you suggest?
It would be nice, both for abuse contacts, and the potential security contact, to be able to advertise that you accept machine readable reports, what formats and how to accept them. There’s an obvious advantage for the abuse/security desk consuming reports for that, but it would also be an improvement in many ways for generators of reports over the current system where abuse-c contains an email address, and that email address is just an autoresponder saying that mail sent there isn’t read (but there’s this other channel over here you can use). I’ve a nasty feeling that any email address added as a security contact will be used as an additional place to report spam coming from the network, which might not be what the people on the end of that alias really need more of. Cheers, Steve -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
El mar, 07-06-2022 a las 13:14 +0200, Gert Doering escribió:
Hi,
On Tue, Jun 07, 2022 at 11:02:19AM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
I don't think the problem would be to add a new attribute if needed. The problem would be to *define* what should go there (and then get everyone downstream to use that new attribute)
This... so, what would you suggest?
Gert Doering -- NetMaster --
I would use the Reference Security Incident Taxonomy (RSIT) as the classification source, which is the taxonomy used by (most of) the CSIRT community. See [1] So the PTY-MAXGROBECKER network could have: abuse-c: GROBECKER-ABUSE and the GROBECKER-ABUSE object: abuse-mailbox: general@abuse.grobecker.info abuse-mailbox-vulnerable: vulnerability-reports@abuse.grobecker.info abuse-mailbox-fraud: fraudabuses@abuse.grobecker.info where 'vulnerable', 'fraud', etc. are the machine readable tags defined in the RSIT for the values in the classification column. Thus, when CERT BUND wanted to report an unpatched Confluence, they would have an incident of type: "Vulnerable → Vulnerable System", find that there is a 'abuse-mailbox-vulnerable' attribute and report it there. Whereas if it was a phishing landing page (incident of type Fraud → Phishing), that would go to fraudabuses@abuse.grobecker.info (from 'abuse-mailbox-fraud') But if it was a host sending out spam, (incident classification Abusive Content → Spam), having no "abuse-mailbox-abusive-content", it would fall back to abuse-mailbox and direct it to general@abuse.grobecker.info. Does something like this seem sensible to others? Best regards 1- https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/b... -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
Hi, On Tue, Jun 07, 2022 at 12:36:10PM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
abuse-c: GROBECKER-ABUSE
and the GROBECKER-ABUSE object: abuse-mailbox: general@abuse.grobecker.info abuse-mailbox-vulnerable: vulnerability-reports@abuse.grobecker.info abuse-mailbox-fraud: fraudabuses@abuse.grobecker.info
where 'vulnerable', 'fraud', etc. are the machine readable tags defined in the RSIT for the values in the classification column. [..] Does something like this seem sensible to others?
From a LIR perspective, this sounds like an interesting and quite workable idea (... it would need some easily-findable help texts that explains what these terms stand for, and which one to use for what :-) ). I think teaching this to CERTs would also be doable... ;-) "whois" would need some help (as it today only returns one abuse e-mail), but that's implementation.... $ whois 195.30.0.1 % Abuse contact for '195.30.0.0 - 195.30.0.255' is 'abuse@space.net' Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I think this sounds like a good idea as someone who is also very much interested in security. However I think the implementation details should be discussed in the db-wg as opposed to the aa-wg. -Cynthia On Tue, Jun 7, 2022, 13:46 Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Jun 07, 2022 at 12:36:10PM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
abuse-c: GROBECKER-ABUSE
and the GROBECKER-ABUSE object: abuse-mailbox: general@abuse.grobecker.info abuse-mailbox-vulnerable: vulnerability-reports@abuse.grobecker.info abuse-mailbox-fraud: fraudabuses@abuse.grobecker.info
where 'vulnerable', 'fraud', etc. are the machine readable tags defined in the RSIT for the values in the classification column. [..] Does something like this seem sensible to others?
From a LIR perspective, this sounds like an interesting and quite workable idea (... it would need some easily-findable help texts that explains what these terms stand for, and which one to use for what :-) ).
I think teaching this to CERTs would also be doable... ;-)
"whois" would need some help (as it today only returns one abuse e-mail), but that's implementation....
$ whois 195.30.0.1 % Abuse contact for '195.30.0.0 - 195.30.0.255' is 'abuse@space.net'
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Cynthia Revström writes:
I think this sounds like a good idea as someone who is also very much interested in security.
However I think the implementation details should be discussed in the db-wg as opposed to the aa-wg.
-Cynthia
It affects both anti-abuse and db-wg. If anti-abuse sees no merit in that, there's no point in going further with it, but if this wg considers it worth pursuing, I guess it should then proposed it to the db-wg. I am open to input on the steps that should be followed, as I'm not familiar with what would be the proper process. Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
Yes, this was exactly my point :) If the aa-wg wants this feature it should be proposed to the db-wg for deciding how it should be implemented. (such as if it's another type contact or just another abuse mailbox attribute) -Cynthia On Tue, Jun 7, 2022, 20:12 Ángel González Berdasco via anti-abuse-wg < anti-abuse-wg@ripe.net> wrote:
Cynthia Revström writes:
I think this sounds like a good idea as someone who is also very much interested in security.
However I think the implementation details should be discussed in the db-wg as opposed to the aa-wg.
-Cynthia
It affects both anti-abuse and db-wg. If anti-abuse sees no merit in that, there's no point in going further with it, but if this wg considers it worth pursuing, I guess it should then proposed it to the db-wg.
I am open to input on the steps that should be followed, as I'm not familiar with what would be the proper process.
Best regards
-- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/
PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
====================================================================
INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union.
====================================================================
In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad.
====================================================================
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Gert Doering writes:
Hi,
On Tue, Jun 07, 2022 at 12:36:10PM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
abuse-c: GROBECKER-ABUSE
and the GROBECKER-ABUSE object: abuse-mailbox: general@abuse.grobecker.info abuse-mailbox-vulnerable: vulnerability-reports@abuse.grobecker.info abuse-mailbox-fraud: fraudabuses@abuse.grobecker.info
where 'vulnerable', 'fraud', etc. are the machine readable tags defined in the RSIT for the values in the classification column.
[..]
Does something like this seem sensible to others?
I think teaching this to CERTs would also be doable... ;-)
It should be. After all, that's based on the Reference Taxonomy used by CERTs, which they should be relatively familiar with (even if they aren't following it strictly). :)
From a LIR perspective, this sounds like an interesting and quite workable idea (... it would need some easily-findable help texts that explains what these terms stand for, and which one to use for what :- ) ).
I agree. By using an established taxonomy, this avoids having to create a new categorization of abuse contact subtypes, and (for those of us using RSIT) the need of mapping from RSIT to that one. But I admit the explanations at https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/b... are quite weak and should be improved.
"whois" would need some help (as it today only returns one abuse e- mail), but that's implementation....
$ whois 195.30.0.1 % Abuse contact for '195.30.0.0 - 195.30.0.255' is 'abuse@space.net'
That's not done by the whois binary, but by the whois server, see $ echo 195.30.0.1 | nc -C whois.ripe.net 4 Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
Hi, On Tue, Jun 07, 2022 at 06:07:13PM +0000, Ángel González Berdasco wrote:
"whois" would need some help (as it today only returns one abuse e- mail), but that's implementation....
$ whois 195.30.0.1 % Abuse contact for '195.30.0.0 - 195.30.0.255' is 'abuse@space.net'
That's not done by the whois binary, but by the whois server, see $ echo 195.30.0.1 | nc -C whois.ripe.net 4
"whois, as in 'this particular way users interface with the DB'" :-) (I'm aware it's the server doing this - which makes changing the implementation easier, as it's "just one place" - but in the end, "it needs to be done" which was the point I tried to make ;-) ) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote:
Hi,
"whois, as in 'this particular way users interface with the DB'" :-)
(I'm aware it's the server doing this - which makes changing the implementation easier, as it's "just one place" - but in the end, "it needs to be done" which was the point I tried to make ;-) )
Gert Doering -- NetMaster
Indeed. And many other tools interacting with the RIPE DB to find abuse contacts, I'm afraid. The uptake of those new attributes would neccessarily be relatively slow. Regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
On Tue 07/Jun/2022 20:14:49 +0200 Ángel González Berdasco via anti-abuse-wg wrote:
Gert Doering wrote:
"whois, as in 'this particular way users interface with the DB'" :-)
(I'm aware it's the server doing this - which makes changing the implementation easier, as it's "just one place" - but in the end, "it needs to be done" which was the point I tried to make ;-) )
Indeed. And many other tools interacting with the RIPE DB to find abuse contacts, I'm afraid. The uptake of those new attributes would necessarily be relatively slow.
People who send not only to RIPE IPs will never uptake, unless this is going to be a global change, including RDAP specs. Best Ale --
Hi, what might add some info to the discussion is the existence of the "security.txt" file described e.g. in https://securitytxt.org/ (https://www.rfc-editor.org/info/rfc9116) This adds security-information to websites - which might be sufficient for many incidents. (aside from whois) I would not go into too much detail on the type of abuse - that is just additional work for the ones who want to send complains/information. They should have as less work as possible to address an incident. It is up to the recipient to fiddle out the type of abuse and take care about it. Not all complaints are created by automatic scripts :) Gunther On 2022-06-07 20:07, Ángel González Berdasco via anti-abuse-wg wrote:
Gert Doering writes:
Hi,
On Tue, Jun 07, 2022 at 12:36:10PM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
abuse-c: GROBECKER-ABUSE
and the GROBECKER-ABUSE object: abuse-mailbox: general@abuse.grobecker.info abuse-mailbox-vulnerable: vulnerability-reports@abuse.grobecker.info abuse-mailbox-fraud: fraudabuses@abuse.grobecker.info
where 'vulnerable', 'fraud', etc. are the machine readable tags defined in the RSIT for the values in the classification column.
[..]
Does something like this seem sensible to others?
I think teaching this to CERTs would also be doable... ;-)
It should be. After all, that's based on the Reference Taxonomy used by CERTs, which they should be relatively familiar with (even if they aren't following it strictly). :)
From a LIR perspective, this sounds like an interesting and quite workable idea (... it would need some easily-findable help texts that explains what these terms stand for, and which one to use for what :- ) ).
I agree. By using an established taxonomy, this avoids having to create a new categorization of abuse contact subtypes, and (for those of us using RSIT) the need of mapping from RSIT to that one.
But I admit the explanations at https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/b... are quite weak and should be improved.
"whois" would need some help (as it today only returns one abuse e- mail), but that's implementation....
$ whois 195.30.0.1 % Abuse contact for '195.30.0.0 - 195.30.0.255' is 'abuse@space.net'
That's not done by the whois binary, but by the whois server, see $ echo 195.30.0.1 | nc -C whois.ripe.net 4
Best regards
-- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/
PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
====================================================================
INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union.
====================================================================
In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad.
====================================================================
-- NetCologne Systemadministration NetCologne Gesellschaft für Telekommunikation mbH Am Coloneum 9 ; 50829 Köln Geschäftsführer: Timo von Lepel, Claus van der Velden Vorsitzender des Aufsichtsrats: Dr. Dieter Steinkamp HRB 25580, AG Köln
Hi, (CSIRT hat on) I don't really agree with the vision where the taxonomy needs to be overloaded into object fields. I always perceived the abuse-c field already as the security-c. People interested in processing security/abuse issues will take messages received on the abuse-mailbox: seriously. Moreover, there are also irt objects. Regards, Carlos On Tue, 7 Jun 2022, Ángel González Berdasco via anti-abuse-wg wrote:
El mar, 07-06-2022 a las 13:14 +0200, Gert Doering escribió:
Hi,
On Tue, Jun 07, 2022 at 11:02:19AM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
I don't think the problem would be to add a new attribute if needed. The problem would be to *define* what should go there (and then get everyone downstream to use that new attribute)
This... so, what would you suggest?
Gert Doering -- NetMaster --
I would use the Reference Security Incident Taxonomy (RSIT) as the classification source, which is the taxonomy used by (most of) the CSIRT community. See [1]
So the PTY-MAXGROBECKER network could have:
abuse-c: GROBECKER-ABUSE
and the GROBECKER-ABUSE object: abuse-mailbox: general@abuse.grobecker.info abuse-mailbox-vulnerable: vulnerability-reports@abuse.grobecker.info abuse-mailbox-fraud: fraudabuses@abuse.grobecker.info
where 'vulnerable', 'fraud', etc. are the machine readable tags defined in the RSIT for the values in the classification column.
Thus, when CERT BUND wanted to report an unpatched Confluence, they would have an incident of type: "Vulnerable ? Vulnerable System", find that there is a 'abuse-mailbox-vulnerable' attribute and report it there.
Whereas if it was a phishing landing page (incident of type Fraud ? Phishing), that would go to fraudabuses@abuse.grobecker.info (from 'abuse-mailbox-fraud')
But if it was a host sending out spam, (incident classification Abusive Content ? Spam), having no "abuse-mailbox-abusive-content", it would fall back to abuse-mailbox and direct it to general@abuse.grobecker.info.
Does something like this seem sensible to others?
Best regards
1- https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/b...
-- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/
PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
====================================================================
INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union.
====================================================================
In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad.
====================================================================
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Yes this simply adds to paperwork and extra coding. It should be relatively trivial with an abuse report / IR oriented ticketing system to separate out genuine DDoS from random desktop firewall complaints about port scans from spam reports from all the outright spam that directly reaches such accounts. From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Carlos Friaças via anti-abuse-wg <anti-abuse-wg@ripe.net> Date: Saturday, 11 June 2022 at 12:28 PM To: Ángel González Berdasco <angel.gonzalez@incibe.es> Cc: gert@space.net <gert@space.net>, anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] Adding a "Security Information" contact? Hi, (CSIRT hat on) I don't really agree with the vision where the taxonomy needs to be overloaded into object fields. I always perceived the abuse-c field already as the security-c. People interested in processing security/abuse issues will take messages received on the abuse-mailbox: seriously. Moreover, there are also irt objects. Regards, Carlos On Tue, 7 Jun 2022, Ángel González Berdasco via anti-abuse-wg wrote:
El mar, 07-06-2022 a las 13:14 +0200, Gert Doering escribió:
Hi,
On Tue, Jun 07, 2022 at 11:02:19AM +0000, Ángel González Berdasco via anti-abuse-wg wrote:
I don't think the problem would be to add a new attribute if needed. The problem would be to *define* what should go there (and then get everyone downstream to use that new attribute)
This... so, what would you suggest?
Gert Doering -- NetMaster --
I would use the Reference Security Incident Taxonomy (RSIT) as the classification source, which is the taxonomy used by (most of) the CSIRT community. See [1]
So the PTY-MAXGROBECKER network could have:
abuse-c: GROBECKER-ABUSE
and the GROBECKER-ABUSE object: abuse-mailbox: general@abuse.grobecker.info abuse-mailbox-vulnerable: vulnerability-reports@abuse.grobecker.info abuse-mailbox-fraud: fraudabuses@abuse.grobecker.info
where 'vulnerable', 'fraud', etc. are the machine readable tags defined in the RSIT for the values in the classification column.
Thus, when CERT BUND wanted to report an unpatched Confluence, they would have an incident of type: "Vulnerable ? Vulnerable System", find that there is a 'abuse-mailbox-vulnerable' attribute and report it there.
Whereas if it was a phishing landing page (incident of type Fraud ? Phishing), that would go to fraudabuses@abuse.grobecker.info (from 'abuse-mailbox-fraud')
But if it was a host sending out spam, (incident classification Abusive Content ? Spam), having no "abuse-mailbox-abusive-content", it would fall back to abuse-mailbox and direct it to general@abuse.grobecker.info.
Does something like this seem sensible to others?
Best regards
1- https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/b...
-- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/
PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
====================================================================
INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union.
====================================================================
In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad.
====================================================================
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Hi, On Tue 07/Jun/2022 11:45:05 +0200 Max Grobecker wrote:
Our abuse mailbox is not overflowing with these, of course, but it makes semi-automated handling a bit painful. For example, we would like to forward these information to our customers, but we wont need to take further action on this, because we refuse to break into the offices of our customers at night and patch their software.
sorry to bother, but I hardly got that. Are these IP-driven messages? Don't CERTs lookup the abuse address with RDAP or WHOIS? Why doesn't the abuse address point (in)directly to the relevant IP user? That is, what's wrong in automatically forwarding CERT's security notices? I cannot understand how doing so entailS obligations to reach the customer's premises at night. Best Ale --
Hi Alessandro, Am 20.06.22 um 18:04 schrieb Alessandro Vesely:
Our abuse mailbox is not overflowing with these, of course, but it makes semi-automated handling a bit painful. For example, we would like to forward these information to our customers, but we wont need to take further action on this, because we refuse to break into the offices of our customers at night and patch their software. sorry to bother, but I hardly got that. Are these IP-driven messages? Don't CERTs lookup the abuse address with RDAP or WHOIS?
The reports we get from CERT-BUND are highly IP focused. I cited one of these report as an example at the end of this mail. In general, I think these organizations we get mail from are downloading the database from RIPE and are using an offline version.
Why doesn't the abuse address point (in)directly to the relevant IP user? That is, what's wrong in automatically forwarding CERT's security notices? I cannot understand how doing so entailS obligations to reach the customer's premises at night.
If I point the abuse address directly to an address controlled by the customer, I don't get any notices - regardless of security information or real abuse. And I'm interested in the latter one, as I want to stop the abuse, of course ;-) Therefore all abuse reports are handled by our internal system to be automatically escalated to the appropriate internal and external contacts. But for notices like "Oh, we think there might be a vulnerable service reachable on that IP" we don't want that whole escalation thing. Also, most of these notices contain a list of addresses, but sometimes, these lists are not stable parseable because there seems to be no standardized format. Reports we receive from CERT-BUND come with a CSV file which we are able to parse - but in the last months there came several new other services with their own data formats and I suspect, there will come more. If I could "route" these reports directly to the customer, this would improve reporting speed and keep these away from our regular abuse desk with escalations and all that stuff. This is one of the mails we more or less regularily get from CERT-BUND, reporting open DNS resolvers: ------------------------------------------------------------------------------- Dear Sir or Madam, open DNS resolvers are abused for conducting DDoS reflection/ amplification attacks against third parties on a daily basis. Please find attached a list of open DNS resolvers hosted on your network which can be abused for DDoS reflection/amplification attacks if no countermeasures have been implemented. The timestamp indicates when the open resolver was identified. We would like to ask you to check if the open resolvers identified on your network are intentionally configured as such and appropriate countermeasures preventing their abuse for DDoS attacks have been implemented. If you have recently solved the issue but received this notification again, please note the timestamp included below. You should not receive any further notifications with timestamps after the issue has been solved. Additional information on this notification, advice on how to fix reported issues and answers to frequently asked questions: <https://reports.cert-bund.de/en/> This message is digitally signed using PGP. Information on the signature key is available at: <https://reports.cert-bund.de/en/digital-signature> Please note: This is an automatically generated message. Replies to the sender address <reports@reports.cert-bund.de> will NOT be read but silently be discarded. In case of questions, please contact <certbund@bsi.bund.de> and keep the ticket number [CB-Report#...] of this message in the subject line. !! Please make sure to consult our HOWTOs and FAQ available at !! <https://reports.cert-bund.de/en/> first. Mit freundlichen Grüßen / Kind regards Team CERT-Bund Bundesamt für Sicherheit in der Informationstechnik Federal Office for Information Security (BSI) Referat OC22 - CERT-Bund Godesberger Allee 185-189, 53175 Bonn, Germany ------------------------------------------------------------------------------- And this is the CSV file, IP addresses and ASN replaced with dummy values: ------------------------------------------------------------------------------- "asn","ip","timestamp" "65535","192.0.2.1","2022-07-02 00:17:09" "65535","203.0.113.5","2022-07-02 00:36:42" "65535","198.51.100.26","2022-07-02 00:49:26" ------------------------------------------------------------------------------- Greetings, Max
Hi Max, thank you for your reply and explanations. Some more comments/ questions inline: On Sun 03/Jul/2022 23:25:28 +0200 Max Grobecker wrote:
Am 20.06.22 um 18:04 schrieb Alessandro Vesely:
Our abuse mailbox is not overflowing with these, of course, but it makes semi-automated handling a bit painful. For example, we would like to forward these information to our customers, but we wont need to take further action on this, because we refuse to break into the offices of our customers at night and patch their software. sorry to bother, but I hardly got that. Are these IP-driven messages? Don't CERTs lookup the abuse address with RDAP or WHOIS?
The reports we get from CERT-BUND are highly IP focused. I cited one of these report as an example at the end of this mail. In general, I think these organizations we get mail from are downloading the database from RIPE and are using an offline version.
It is very expensive. Do you think they only do European IPs, or do they have specialized procedures for each RIR? Perhaps RIPE provides for maintaining remote copies of the database, but a caching RDAP tool would be more standard compliant.
Why doesn't the abuse address point (in)directly to the relevant IP user? That is, what's wrong in automatically forwarding CERT's security notices? I cannot understand how doing so entailS obligations to reach the customer's premises at night.
If I point the abuse address directly to an address controlled by the customer, I don't get any notices - regardless of security information or real abuse. And I'm interested in the latter one, as I want to stop the abuse, of course ;-) Therefore all abuse reports are handled by our internal system to be automatically escalated to the appropriate internal and external contacts.
What I'd be curious to know is whether automatic escalation is based on per-customer abuse addresses or on parsing message contents looking for IPs. Per-customer address is something like asn65535@bc.grobecker.info or ip192.0.2.8/29@sc.grobecker.info, which can be forwarded to the relevant (big or small) customer without actually opening the messages, but still maintaining a copy of them. Doing so requires more work for maintaining the database, but less work for forwarding messages.
But for notices like "Oh, we think there might be a vulnerable service reachable on that IP" we don't want that whole escalation thing. Also, most of these notices contain a list of addresses, but sometimes, these lists are not stable parseable because there seems to be no standardized format. Reports we receive from CERT-BUND come with a CSV file which we are able to parse - but in the last months there came several new other services with their own data formats and I suspect, there will come more.
And the CSVs refer to multiple customers?
If I could "route" these reports directly to the customer, this would improve reporting speed and keep these away from our regular abuse desk with escalations and all that stuff.
I understand you don't want your abuse desk to get involved in checking whether, for example, an open DNS does in fact amplify queries if it is open. Is that the difference between forward and escalate? Using a different field entails the extra burden to educate organizations like CERT-BUND to use the appropriate reporting address based on the kind of report. For RDAP, those addresses could be tagged as less preferred. Some RIRs do so, leaving the actual meaning a bit obscure, though. Alternatively, RFC 7483 provides for a "notifications" role, which in theory applies to an associated object. Best Ale --
participants (10)
-
Alessandro Vesely -
Carlos Friaças -
Cynthia Revström -
denis walker -
Gert Doering -
gnitzsche -
Max Grobecker -
Steve Atkins -
Suresh Ramasubramanian -
Ángel González Berdasco