building an effective action plan for the Department of Homeland Security

Transcription

1 Customer Guide building an effective action plan for the Department of Homeland Security Binding The recently issued directive from the Department of Homeland Security (DHS), Binding Operational Directive (BOD) has multiple milestones which agencies need to adhere to; the first of which is submitting your plan to the DHS by November 15, Before you start this project, assembling a project team who take responsibility is recommended the team should include the following people: A member of the Domain Name Server (DNS) team (or someone who has a working relationship with the DNS provider) A member of the Messaging team, with responsibility for, and knowledge of, internal MTA s A project manager An executive sponsor, whose main role will be to clear roadblocks (both internally and with suppliers) The project lead from your vendor (if you choose to use one) There are 7 requirements outlined in BOD that all civilian agencies must follow, along with defined timings from the issue date of October 16th, 2017: BOD Ref. Requirement Deadline 1. Submit Agency Plan of Action for BOD to DHS 30 days 2 Send monthly project status reports to DHS From 60 days 3.1 Deploy STARTTLS on all internet-facing mail servers 90 days 3.2 Deploy valid SPF record for all second-level domains 90 days 3.3 Deploy valid DMARC record for all second-level domains (with at least a monitor or p=none policy) 90 days 4.1 Disable SSLv1 & v2 on mail servers 120 days 4.2 Disable 3DES & RC4 ciphers on mail servers 120 days 5.1 Enable HTTPS (with HSTS) for all publicly accessible websites & web services 120 days 5.2 Disable SSLv1 & v2 on web servers 120 days 5.3 Disable 3DES & RC4 ciphers on web servers 120 days 5.4 Provide DHS with list of second-level domains that can be HSTS preloaded (thereby enforcing HTTPS for all associated subdomains) 6 Add NCCIC to DMARC record as recipient of aggregate reports 120 days 15 days from when NCCIC is ready 7 Deploy p=reject DMARC policy for all second-level domains 1 year This document provides resources and content that can be used to build your DHS plan.

2 2 1. SUBMIT AGENCY PLAN OF ACTION FOR BOD TO DHS Completing and submitting the project plan document will achieve this requirement. 2. SEND MONTHLY PROJECT STATUS REPORTS TO DHS The project plan should be updated on a monthly basis as the project progresses. 3.1 DEPLOY STARTTLS ON ALL INTERNET-FACING MAIL SERVERS Using STARTTLS helps ensure that the most secure connection is being used by the mail server. STARTTLS can be used to upgrade existing insecure connections to secure, encrypted connections. The steps to deploy STARTTLS on mail servers are: 1. Identify all inbound and outbound internet facing mail servers for all agency domains. 2. Enable opportunistic TLS. 3. Verify that STARTTLS is enabled by stepping through SMTP transaction. 3.2 DEPLOY VALID SPF RECORD FOR ALL SECOND-LEVEL DOMAINS SPF records must be entered for every domain and they must also be verified as being syntactically correct. The simplest way to build the list of IP addresses which need to be included in your SPF records will be to utilize the DMARC reports which will show every IP address seen sending from the domains which have such records. Your key task is to determine which IP address belongs to legitimate/authorized senders, and group them efficiently. This guide from M3AAWG offers more information about SPF record creation and options. The steps to deploy valid SPF records on second-level domains are: 1. Identify all domains registered to/belonging to the agency, and associated DNS system. (Note that subdomains are to be considered to be domains in their own right for this task.) 2. Agency will validate that SPF records are in a format that complies with the official Sender Policy Framework (SPF) RFC In the event that SPF records for given domains are missing or syntactically incorrect, the agency will make the necessary changes, creating or adjusting records as appropriate. (Note records will/must be terminated with the soft fail mechanism). 4. As a separate exercise, the agency will validate that the SPF records are complete i.e. that they include all the necessary IP addresses and/or include statements. The agency will also ensure that redundant IP addresses and include statements are removed as these present a security risk, and may also contribute to problems meeting the requirement defined in point The combination of explicit and implicit include statements must not exceed 10. (Note an implicit include statement is one contained in a record external to the original SPF record checked, that is referenced via an include statement). 6. In the event that the total of explicit and implicit include statements exceeds 10, the agency will work to collapse or consolidate the records or to make other changes to its ecosystem in order to meet this syntax requirement. 7. Run additional audits to validate that all SPF records are both correct and complete, validated using the tools available here: DEPLOY VALID DMARC RECORD FOR ALL SECOND-LEVEL DOMAINS DMARC records must be entered for every domain, they must also be verified as being syntactically correct. For BOD compliance you should ensure that you maintain a space for the NCIC aggregate reporting and update all records to contain this address when it is released. Initially all records must have a policy value of p=none, how rapidly you an update this to p=reject depends on how rapidly you can run through the process of identifying all sending entities, moving them all to the point where they authenticate both fully (aligned SPF and DKIM), and reliably. You will need a tool to receive, parse and present DMARC reports. If you choose a vendor to assist with your DMARC project they will provide this as part of the service, otherwise you will need to either develop your own or obtain one. There is more information on DMARC and tools from M3AAWG and DMARC.org.

3 3 The steps to deploy valid DMARC records on second-level domains are: 1. Create a DMARC record that is compliant with the requirements of BOD with respect to reporting addresses and policy value 2. Identify all domains (do not restrict this project to only those domains used to send ) registered to/ belonging to the agency, and associated DNS system. (Note that subdomains are to be considered to be domains in their own right for this task.) 3. Audit the location _dmarc.example.com for every domain identified in the initial audit for the presence of a DMARC record 4. Agency will deploy BOD compliant DMARC records for every domain which does not already have a DMARC record, at the location of _dmarc.example.com, and shall validate that said records are in a format that complies with the official Domain-based Message Authentication, Reporting and Conformance (DMARC) RFC In the event that a record already exists a new record shall be generated which includes the attributes (policy, reporting) from the existing record and adds them to the BOD compliant record. Where there is a conflict, the BOD record shall take precedence (for e.g. if the new record would exceed two reporting addresses for either RUA or RUF reporting then a non- BOD address shall be deprecated). 6. As a related exercise the agency shall validate that the reporting addresses are receiving the expected reports, from all parties (ISP s, gateway providers etc), and shall also validate that the tools being used to parse said records are sufficient to the requirements of the agency. 7. Finally, the agency will run additional audits to validate that all DMARC records are both correct and complete. 4.1 DISABLE SSL V1 AND V2 ON MAIL SERVERS Older versions of SSL have not been found to be secure and have been removed as criteria for many different regulations including the PCI Data Security Standard. As you have deployed STARTTLS on your mail servers, removing SSL v1 and v2 removes the potential for exploiting these weaker protocols. The steps for disabling SSL v1 and v2 are: 1. Analyze server logs to determine whether any key business partners transact SMTP over SSL v1 or v2 to 2. Disable SSL v1 and v2. 3. Examine server logs to determine whether any inbound mail could not be received due to disablement of SSL v1 and v DISABLE 3DES AND RC4 ON MAIL SERVERS 3DES and RC4 are older encryption standards that have been found to be vulnerable to exploitation and therefore need to be disabled to prevent them from being exploited on federal mail servers. The steps to disable 3DES and RC4 are: 1. Analyze server logs to determine whether any key business partners transact SMTP via 3DES or RC4 ciphers to 2. Disable 3DES and RC4 ciphers. 3. Examine server logs to determine whether any inbound mail could not be received due to disablement of ciphers. 5.1 ENABLE HTTPS (WITH HSTS) FOR ALL PUBLICLY ACCESSIBLE WEBSITES AND SERVERS Using HTTP is inherently insecure as all data travels unencrypted. To ensure the security of any data passed to and from websites, using HTTP is required. By enforcing HTTP Strict Transport Security (HSTS), agencies prevent the ability of attackers to use protocol downgrade attacks to reduce the level of security in place. The steps to enable HTTPS are: 1. Disable HTTP in favor of HTTPS on any Internet-facing servers on second level domains. It is recommended to use TLS 1.2 ciphers if possible; at minimum, TLS Register Internet-facing domains with DHS at FNR.BOD@hq.dhs.gov as defined in

4 4 5.2 DISABLE SSLV1 AND V2 ON WEB SERVERS Older versions of SSL have not been found to be secure and have been removed as criteria for many different regulations including the PCI Data Security Standard. As you have deployed HTTPS on your web servers, removing SSL v1 and v2 removes the potential for exploiting these weaker protocols. The steps for disabling SSL v1 and v2 are: 1. Analyze server logs to determine whether user clients connect via SSL v1/v2 to understand potential impact of disabling. 2. Disable SSL v1 and v2. Proofpoint also recommends disabling SSL v3 for additional security, in favor of TLS Examine server logs to determine whether any client browsers were unable to connect due to disablement of SSL v1 and v DISABLE 3DES AND RC4 ON WEB SERVERS 3DES and RC4 are older encryption standards that have been found to be vulnerable to exploitation and therefore need to be disabled to prevent them from being exploited on federal web servers and websites. The steps to disable 3DES and RC4 are: 1. Analyze server logs to determine whether user clients connect via browsers using 3DES or RC4 ciphers to 2. Disable 3DES and RC4 ciphers on web servers. Proofpoint provides a patch to remove these ciphers. 3. Examine server logs to determine whether any client browsers were unable to connect due to disablement of 3DES or RC4 ciphers. 5.4 PROVIDE DHS WITH LIST OF SECOND LEVEL DOMAINS THAT CAN BE HSTS PRELOADED 1. Identify and create complete list of Internet-facing second level domains. 2. Disable HTTP in favor of HTTPS on any Internet-facing servers on second level domains. It is recommended using TLS 1.2 ciphers if possible; at minimum, TLS Provide said list to DHS at FNR.BOD@hq.dhs.gov as defined in 6. ADD NCCIC TO DMARC RECORD AS RECIPIENT OF AGGREGATE REPORTS As outlined in 3.3 it is required to preserve space for the NCIC reporting address within the DMARC record once it is released. It will be entered in the format mailto:reportingaddress@example.gov following the existing RUA address, separated with a comma, with no whitespace. You may choose to validate this with your vendor before updating your DNS. 7. DEPLOY P=REJECT DMARC POLICY FOR ALL SECOND-LEVEL DOMAINS Before setting your DMARC policy to p=reject, it is vital to verify that all the steps that you have taken have been correct and that: All IP s seen sending from DMARC reporting positively identified All legitimate senders to have been validated to be authenticating ALL sent on behalf of the agency with fully aligning SPF and DKIM (note SPF or DKIM alone is insufficient, and will negatively impact delivery of legitimate when not aligned.) Any errors could mean that fraudulent is still being sent, or could mean that legitimate is being blocked. Once your DMARC policy is set to p=reject it is important to: Provide all internal stakeholders with guidance on how must be sent in future to avoid deliverability issues (correct configuration of DMARC, SPF, DKIM etc) Have a mitigation plan in place, tested and communicated, alerts to trigger mitigation in place, tested and communicated (for e.g. legitimate failing authentication/process to mitigate)

5 5 ASSUMPTIONS, DEPENDENCIES, CONSTRAINTS AND UNKNOWNS The DHS BOD refers to SPF and DMARC, but does not cover DKIM. DKIM is however a requirement for deploying DMARC, it is assumed that the project team both understands this standard and has the resources to deploy this universally. Many legacy gateways do not support DKIM signing and agencies with these products will need to introduce new infrastructure which possesses the requisite abilities. DMARC deployment requires that the DNS is updated if any changes are made to the policy. The project team should evaluate current change control processes, change freeze windows and so forth to establish how best to work with them. DNS must support SPF, DMARC and DKIM records the latter can be large, and may need multiple records to be concatenated. Not all DNS platforms support this therefore this should be established early on in case a DNS migration is required as part of the overall project. Some third parties choose to authenticate in a way that contradicts the requirements of DMARC and therefore cannot pass the alignment check mandated by DMARC. These third parties must be identified early in the project, and a mitigation/migration strategy established. A vendor is particularly useful in this situation as they will understand what a third party can or cannot do, rather than what they say they can or cannot do. Vendors often revert to defaults resulting in partial authentication issues, so the agency needs to establish a means of monitoring for these, and have defined mitigation strategies in place to accommodate them. BOD has an extremely aggressive timeline for compliance, if the agency is of moderate to high complexity then starting the process of audit/plan/execute as soon as possible (and likely bringing in a vendor with their team of experts) is the best chance these agencies have of achieving compliance by October 16, ABOUT PROOFPOINT Proofpoint, Inc. (NASDAQ:PFPT), a next-generation cybersecurity company, enables organizations to protect the way their people work today from advanced threats and compliance risks. Proofpoint helps cybersecurity professionals protect their users from the advanced attacks that target them (via , mobile apps, and social media), protect the critical information people create, and equip their teams with the right intelligence and tools to respond quickly when things go wrong. Leading organizations of all sizes, including over 50 percent of the Fortune 100, rely on Proofpoint solutions, which are built for today s mobile and social-enabled IT environments and leverage both the power of the cloud and a big-data-driven analytics platform to combat modern advanced threats. Proofpoint, Inc. Proofpoint is a trademark of Proofpoint, Inc. in the United States and other countries. All other trademarks contained herein are property of their respective owners. proofpoint.com