Malicious Mitigation Strategy Guide

Transcription

1 CYBER SECURITY OPERATIONS CENTRE Malicious Mitigation Strategy Guide Introduction (UPDATED) SEPTEMBER Socially engineered s containing malicious attachments and embedded links are commonly used in targeted cyber intrusions against Australian government networks. This document provides guidance on mitigating these malicious s using DSD s Strategies to Mitigate Targeted Cyber Intrusions. 2. This document is intended for use by Information Technology Security Advisors and system administrators. It should be read in conjunction with the advice on security and content filtering contained in the Australian Government Information Security Manual (ISM). 3. The mitigations in this document are ranked within categories in order of the overall security effectiveness of the mitigation, from most to least effective. Further information on these mitigation strategies can be found at Attachment A. attachment filtering 4. Attachments are a significant security risk associated with s. Effective attachment filtering and restrictions reduce the likelihood of malicious content entering the network. The key security considerations associated with attachment filtering are discussed below. Convert attachments to another file type 5. Converting a document to another format is a highly effective method of removing malicious content or rendering it ineffective. For example, Microsoft Office documents are converted to PDF and delivered to the user. A release facility should be available for selected blocked s in case the original is required for editing purposes. Allowing attachments based on file typing (Whitelisting) 6. File typing inspects the content of the file to determine the file type rather than relying on the extension as an indicator. File extensions can be changed and therefore a mismatch between a file s type and its stated extension should be treated as suspicious and blocked. DSD recommends whitelisting file types with a legitimate business purpose. Whitelisting is more proactive and thorough than blacklisting as it ensures only specified files can be received, while all others are blocked. Page 1 of 6

2 Block password protected archives, unidentifiable or encrypted attachments 7. Content within a protected archive cannot be inspected since the filter cannot decrypt the archive. Any protected archive or otherwise encrypted attachment should be blocked until such time as it can be deemed safe to allow through to the user. Unidentifiable content is less of a threat if effective file typing and whitelisting of attachments is used. Sanitise attachments to remove active or potentially harmful content 8. Active content, such as macros and JavaScript, should be removed from within the document before being delivered to the user in the same way that active content should be removed from the body. Active content removal can be completed by products such as Exchange Defend PDF which will detect a PDF document, scan the document for undesirable active content based on keywords, and rewrite those elements in the document rendering them inert. Complete and comprehensive sanitisation of an attachment is a difficult process. For this reason, the preferred solution is file conversion. Controlled inspection of archive files 9. Archived files can be used to bypass filters, for example, if an adversary crafts a malicious PDF and places it in an archive file and sends the archive file to the target. The contents of an archive file should be subjected to the same level of inspection as un archived attachments. Archived content should be inspected in a controlled manner to avoid archive file associated exploits, such as directory traversals and denial of service via archive directory recursion. Scan attachments using antivirus software 10. Attachments should be scanned using CLASSIFICATION up to date signatures, reputation ratings and other heuristic detection capabilities. To maximise coverage, use a product provided by a different vendor than the desktop antivirus product. Ensure that the anti virus software is up to date. Block attachments based on file typing (Blacklisting) 11. Blacklisting attachments based on file typing is far less proactive and thorough than whitelisting attachment types, and the overhead of maintaining a list of all known bad file types is far greater. Allow attachments based on extension (Whitelisting) 12. Allowing attachments based on file extension is less robust than file typing as the extension can be trivially changed to disguise the true nature of the file (for example, renaming readme.exe to readme.doc). Only file extensions with a legitimate business purpose should be whitelisted. Block attachments based on extension (Blacklisting) 13. Blacklisting attachments based on their extension is less proactive and thorough than whitelisting. Blocking based on file extension is less robust than file typing as the extension can be trivially changed to disguise the true nature of the file (for example renaming readme.exe to readme.doc). Page 2 of 6

3 body filtering 14. content filtering performed on the body of an helps provide a defence in depth approach to filtering. The possible attack surface presented by the body of an is less than attachments; however, it can be used for malicious communications. The key security considerations associated with filtering the body of an are discussed below. Replace active (live) web addresses in an s body with non active versions 15. An active web address allows the user to click directly on the hyperlink and be taken to a specified website. Active web addresses can appear to be safe but can actually direct the user to an unintended location. Hovering over the address will reveal the actual location, as shown here: 16. Active web addresses should be replaced with the actual location of the link, otherwise they should be replaced with text so that the user must copy and paste the link into their browser. Enforce protective markings on the body or subject line 17. Protective markings should be enforced to ensure that the content being sent and received in an is appropriately classified to traverse the network. Enforcement of protective markings on s helps to minimise the number of data spills and the exfiltration of data from the network via . Decode and inspect encoded content in an s body 18. Encoded content can be used to hide malicious or command and control communications originating from the network or intended for the network. For example a command to an implant can be encoded and inserted into the s body. A content filter should inspect the body for encoded content after decoding the body according to the MIME Content Transfer Encoding header. If encoded content is detected the should be blocked. Remove active content from an s body 19. s with active content such as VBScript or JavaScript pose a threat if the client is capable of running the active content. bodies containing active content should be sanitised to minimise the risk, however, the risk posed by active content is minimal because only a small number of clients have the option to execute active content. Page 3 of 6

4 Domain authentication 20. Being able to verify the authenticity and integrity of an can stop an agency from receiving some forms of malicious s. The key controls for authenticating the domain of an are discussed below. Block on SenderID/SPF hard fail 21. Checking the SenderID will verify the as originating from the domain it claims to originate from. Checking the SenderID allows an agency to block the if the checks fail. An SPF hard fail occurs when an is received which has been verified as not originating from the domain it claims to originate from. SPF hard fails should be blocked and investigated. An SPF hard fail can indicate a phishing attempt, especially if the failed message is spoofed to appear to come from a legitimate domain. Block on DKIM fail 22. DomainKeys Identified Mail (DKIM) is a method of verifying the sender s domain of an using the signatures provided by the sending domain. When an fails DKIM verification, the should be blocked and investigated. This should also be logged and potentially reported to the organisation that the was claiming to originate from. Block on SenderID/SPF soft fail 23. Checking the SenderID will verify the as originating from the domain it claims to originate from. Checking the SenderID allows an agency to block the if the checks fail. An SPF soft fail occurs when an SPF enabled domain cannot guarantee that the was sent from an authorised server of that domain. When an SPF soft fail is encountered, the should be blocked with the option of being able to retrieve it if it is a legitimate . Flag on SenderID/SPF soft fail 24. As above, except instead of blocking the , the should be marked before being sent to the user to allow the user to make a decision as to whether they will accept (trust) the message or not. For example, the subject line of the could be modified to highlight and identify to the user that the did not pass the SPF checks. Incorporate spam blacklists 25. Known spam senders and addresses can be blocked without the being examined. Additional filter functionality 26. The focus of this document is security controls to reduce the risk of compromise of the network or the information it holds. However, the following functionality will make an content filter, or management of it, more effective. Page 4 of 6

5 a. Logging and auditing. Logging of actions and events from the filter should be implemented, and these logs should be audited. Effective logging and auditing will help in the event of a current or past security incident. b. Minimal overhead for an administrator to release blocked content. This will allow an administrator to easily release content for a user when that content has been blocked. The administrator needs to be able to see why the was blocked to determine if the or content should be allowed through to the user. c. User self release of (based on blocked reason). This will allow the user who has had an blocked the ability to request to have the released without needing to go through the administrator. This option should only be available for selected blocked s based on the control triggered. All self releases should be logged for auditing purposes. Further information 27. The Australian Government Information Security Manual (ISM) assists in the protection of official government information that is processed, stored or communicated by Australian Government Systems, and is available at: Strategies to Mitigate Targeted Cyber Intrusions and other DSD products are available on DSD s public website and OnSecure, and complement the advice in the ISM. These products can be found at: For further information on protective markings, please refer to the Protective Marking Standard for the Australian Government produced by the Australian Government Information Management Office: government/security andauthentication /authentication identity.html. 30. For further information on Sender Policy Framework, please refer to Mitigating Spoofed s Sender Policy Framework Explained which can be found at: Contact details Australian government customers with questions regarding this advice should contact the DSD Advice and Assistance Line on 1300 CYBER1 ( ) or dsd.assist@defence.gov.au. Australian businesses or other private sector organisations seeking further information should contact CERT Australia at info@cert.gov.au or by calling Page 5 of 6

6 Attachment A: Summary of mitigation strategies Attachment Filtering Mitigation Strategy Overall Security Effectiveness User Resistance Upfront Cost (Staff, Equipment, Technical Complexity) Maintenance Cost (Mainly Staff) Designed to Prevent or Detect an Intrusion Helps Mitigate Intrusion Stage 1: Code Execution Helps Mitigate Intrusion Stage 2: Network Propagation Convert attachments to another file type Excellent Medium* Medium Medium* Prevent Yes No No Allow attachments based on file typing (Whitelisting) Excellent Medium Medium Low Prevent Possible No Yes^ Block password protected archives, unidentifiable or encrypted attachments Excellent Medium Medium Low Prevent Yes No Yes Sanitise attachments to remove active or potentially harmful content Excellent Medium* High Medium* Prevent Yes No No Controlled inspection of archived files Good Low Medium Low Both Yes No Yes Scan attachments using antivirus software Good Low Low Low Both Yes No No Block attachments based on file typing (Blacklisting) Average Low Low Medium Prevent Yes No Yes^ Allow attachments based on extension (Whitelisting) Minimal Medium Low Low Prevent Possible No Yes^ Block attachments based on extension (Blacklisting) Minimal Low Low Medium Prevent Yes No Yes^ Body Filtering Replace active (live) web addresses within an s body with non active versions Good Low Medium Low Prevent Yes No No Enforce protective markings on the body or subject line Minimal Low High Low Detect No No Yes Remove active content from an s body (e.g. JavaScript, VBScript) Minimal Low Medium Low Prevent Yes No No Domain Authentication Block an on SenderID/SPF hard fail Excellent Low Low Low Prevent Possible No No Block on DKIM fail Excellent Low Low Low Prevent Possible No No Block on SenderID/SPF soft fail Good Medium Low Low Prevent Possible No No Flag on SenderID/SPF soft fail Average Low Low Low Prevent Possible No No Incorporate spam blacklists Average Low Low Low Both# Possible No No Mitigations are ranked in categories based on the overall security effectiveness. *Potentially lower if document release is easy. #If the mitigation is applied to both incoming and outgoing s, then this is Both otherwise, just Prevent. ^Provided the attacker is attempting to exfiltrate a file type that is blocked. Helps Mitigate Intrusion Stage 3: Data Exfiltration Page 6 of 6