choosing an email address for security incidents

All organizations are susceptible to potential IT attacks. Email is the most common method used for contacting the team in charge of handling security incidents.

How can a company set this email address so that it’s easy to remember and can serve as an efficient means of communication for anyone, especially people outside the organization? With this kind of email address, anyone (users, customers, partners, companies, hackers, journalists, government institutions, etc) can easily send information related to the organization’s security. 

a single address

First off, make it simple: don’t use multiple email addresses. Pick one and make it the preferred contact method. This will eliminate destination errors and ensure that all notifications are effectively taken into account and processed equally.

choosing an address

I’ll get right to the point: for the majority of organizations, using an address like “security@yourdomainname.net” is a good choice. After weighing the pros and cons, companies specializing in security, companies with the resources to put together a Computer Emergency Response Team (CERT), and government organizations can choose another email address.

recommended by the RFCs

The reason I recommend the "security@yourdomainname.net” address is because the Request For Comments documents (RFCs) – a sort of reference in the internet world – say you should do it this way:

1. RFC 3013 (RFC 3013 - Recommended Internet Service Provider Security Services and Procedures) recommends (cf §2.1) a "security@domainname.net" address, and refers to RFC 2142.
2. RFC 2142 (RFC 2142 - Mailbox Names for Common Services, Roles and Functions) also recommends (cf §4) a "security@domainname.net" address.  

a different perspective from the CSIRT handbook

The Computer Security Incident Response Team (CSIRT) Handbook offers quite different recommendations (cf §3.7.1.4, page 105): ssc@domainname.net (site security contact) and sep@domainname.net (security entry point). It does, however, indirectly reference the RFC 2142 :-).

Signed, sealed, delivered: let's go for security@domainname.net!

social networks

Social networks are also used for quick contact within a company: Twitter Direct Messages are also used. It’s important to relay the message to your communications team (if you have a “classic” account) so that they forward these messages to be addressed.

It’s also possible to create a Twitter account solely for collecting security notifications (though this should be avoided for confidentiality reasons). 

a dedicated webpage

“But how should I communicate this email address?” you ask. RFC 3013 (still in §2.1) gives us a clue: www.domain-name.net/security. We’ve come full circle. 

It’s still possible to add a section in the "Contact” page, which is very often accessible through a URL like “http://www.domainname.net/contact".

On this page, we can find other helpful information about telephone numbers, Pretty Good Privacy (PGP) keys for encrypting messages, and more (see the US-CERT contact page, for an example).

dealing with notifications

All emails sent to this address should be handled 24/7. This is typically the job of a CERT or, more generally, a CSIRT, or even a Security Operations Center (SOC). It’s your choice.