Method and system for reducing reporting of non-malicious electronic messages in a cybersecurity system

• US 9,781,149 B1
• Filed: 08/17/2016
• Issued: 10/03/2017
• Est. Priority Date: 08/17/2016
• Status: Active Grant

• Current Assignee: Proofpoint Incorporated
• Original Assignee: Wombat Security Technologies, Inc (Proofpoint Incorporated)
• Inventors: Himler, Alan, Campbell, John T., Ferrara, Joseph A., Hawthorn, Trevor T., Sadeh-Koniecpol, Norman, Wescoe, Kurt
• Primary Examiner(s): Pyzocha, Michael
• Application Number:
  US15/239,655
• Time in Patent Office: 412 Days
• CPC Class Codes: H04L 51/046 Interoperability with other network applications or services
• CPC Class Codes: H04L 51/212 using filtering or selective blocking
• CPC Class Codes: H04L 61/5007 Internet protocol [IP] addresses
• CPC Class Codes: H04L 63/123 received data contents, e.g. message integrity
• CPC Class Codes: H04L 63/1425 Traffic logging, e.g. anomaly detection
• CPC Class Codes: H04L 63/1433 Vulnerability analysis
• CPC Class Codes: H04L 69/22 Parsing or analysis of headers

Abstract

An electronic message analysis system of a cybersecurity network assesses whether a received message is a mock malicious message in response to, receiving a user activation action that indicates that the user has reported the received message as a potentially malicious message. The system does this by determining whether any header field of a header section of the message starts with a predetermined key. For any header field that starts with the predetermined key, the system determines whether a value that follows the predetermined key satisfies a trusted sender rule. If the value that follows the predetermined key satisfies the trusted sender rule, the system determines that the received message originated from a trusted sender. If the value that immediately follows the predetermined key does not satisfy the trusted sender rule, the system determines that the received message did not originate from a trusted sender.

Claims

1. An electronic message analysis system of a cybersecurity network, the system comprising:

a message origination server comprising a processor and programming instructions configured to cause the message origination server to generate a plurality of mock malicious messages and send the mock malicious messages to a client computing device; and

the client computing device, comprising a processor and programming instructions configured to cause the client computing device to;

receive an electronic message via a communications network,

receive a user activation action that indicates that the user has reported the received message as a potentially malicious message,

upon receiving the user activation action, determine whether the received message is a mock malicious message or otherwise originated from a trusted sender by;

determining whether any header field of a header section of the received message starts with a predetermined key,

for any header field that starts with the predetermined key, further analyzing that header field to determine whether a value that follows the predetermined key satisfies a first trusted sender rule,

if the value that follows the predetermined key satisfies the first trusted sender rule, determining that the received message originated from a trusted sender, and

if the value that immediately follows the predetermined key does not satisfy the first trusted sender rule, determining that the received message did not originate from a trusted sender,

if the client computing device determines that the received message did not originate from a trusted sender, forward the received message to a remote service, and

if the client computing device determines that the received message originated from a trusted sender, enable the user to cause the client computing device to take action on the received message without further reporting the received message to the remote service.

2. The system of claim 1, wherein the instructions for determining whether any header field of a header section of the received message starts with a predetermined key comprise instructions to:

retrieve any header field in the header section that is an extension field of the header; and

for each retrieved header field, determine whether the field name of the header field matches the predetermined key.

3. The system of claim 1, wherein the first trusted sender rule comprises a condition that the value match a predetermined known value or a predetermined known format, wherein the predetermined known value and predetermined known format are included in the programming instructions of the client computing device.

4. The system of claim 1, further comprising additional programming instructions that are configured to cause the client computing device to:

analyze an additional element of the received message to determine whether the additional element satisfies a second trusted sender rule; and

when the additional element satisfies the second trusted sender rule, conclude that the received message originated from a trusted sender, otherwise send the received message to the remote service for further analysis.

5. The system of claim 4, wherein the second trusted sender rule comprises:

a condition that any header field having a FROM fieldname include a value that is associated with a known sender;

a condition that any header field having a domain name include a value that is associated with a known domain;

or

a condition that any header field having a FROM fieldname include a value that is associated with a known sender, and a condition that any header field that includes a domain have a value that is associated with a known domain.

6. The system of claim 4, wherein the programming instructions for determining whether the additional element satisfies the second trusted sender rule comprise programming instructions to:

identify an Internet protocol (IP) address in a header field of the header section, and

determine whether a sender policy framework (SPF) record has been published with a domain corresponding to the IP address; and

the second trusted sender rule comprises a condition that an SPF record have been published with a domain corresponding to the IP address.

7. The system of claim 4, wherein:

the received message includes a digital signature for DKIM authentication;

the programming instructions for determining whether the additional element satisfies the second trusted sender rule comprise programming instructions to obtain a public key and use the public key to determine whether the digital signature may be verified; and

the second trusted sender rule comprises a condition that the digital signature be verified using an authentication protocol of DMARC.

8. The system of claim 1, wherein the instructions to enable the user to cause the client computing device to take action on the received message without further reporting the received message to the cybersecurity analyzer server if the client computing device determines that the received message originated from a trusted sender comprise instructions to:

prompt to the user to confirm whether to continue reporting the received message; and

only forward the received message to the cybersecurity analyzer server if the client computing device receives confirmation from the user to continue reporting the received message.

9. The system of claim 8, wherein the instructions to prompt to the user comprise instructions to display a message alerting the user that the received message is from a trusted sender.

10. A method of assessing whether an electronic message originated from a trusted source, the method comprising:

by a client computing device, receiving an electronic message via a communications network;

by the client computing device, receiving a user activation action that indicates that a user has reported the received message as a potentially malicious message;

upon receiving the user activation action, by the client computing device, implementing programming instructions that are installed on the client computing device that cause the client computing device to determine a source of the received message by;

determining whether any header field of a header section of the received message starts with a predetermined key,

for any header field that starts with the predetermined key, further analyzing that header field to determine whether a value that follows the predetermined key satisfies a first trusted sender rule,

if the value that follows the predetermined key satisfies the first trusted sender rule, determining that the received message may have originated from a trusted sender and enabling the user to use the client computing device to take action on the received message without further sending the received message to a remote service for analysis, and

if the value that immediately follows the predetermined key does not satisfy the first trusted sender rule, sending the received message to the remote service for analysis.

11. The method of claim 10, further comprising:

assigning a class to the received message, wherein the class corresponds to at least one of the following;

trusted from an internal source, trusted from an external source, or untrusted; and

causing the client computing device to output a prompt to the user, wherein the prompt includes the class or information corresponding to the class.

12. The method of claim 10, wherein the step of determining whether any header field of a header section of the received message starts with a predetermined key comprises:

retrieving any header field in the header section that is an extension field of the header; and

for each retrieved header field, determining whether the field name of the header field matches the predetermined key.

13. The method of claim 10, wherein the first trusted sender rule comprises a condition that the value match a predetermined known value, wherein the predetermined known value is included in the programming instructions.

14. The method of claim 10, wherein the first trusted sender rule comprises a condition that the value have a format that matches a predetermined known format, wherein the predetermined known format is included in the programming instructions.

15. The method of claim 10, wherein the step of determining that the received message may have originated from a trusted sender comprises concluding that the received message satisfies the first trusted sender rule.

16. The method of claim 10, wherein the method further comprises:

analyzing an additional element of the received message to determine whether the additional element satisfies a second trusted sender rule; and

when the additional element satisfies the second trusted sender rule, concluding that the received message originated from a trusted sender, otherwise sending the received message to the remote service for further analysis.

17. The method of claim 16, wherein the second trusted sender rule comprises:

a condition that any header field having a FROM fieldname include a value that is associated with a known sender;

a condition that any header field having a domain name include a value that is associated with a known domain;

or

a condition that any header field having a FROM fieldname include a value that is associated with a known sender, and a condition that any header field having a domain include a value that is associated with a known domain.

18. The method of claim 16, wherein:

the method further comprises;

identifying an Internet protocol (IP) address in a header field of the header section, and

determining whether a sender policy framework (SPF) record has been published with a domain corresponding to the IP address; and

the second trusted sender rule comprises a condition that an SPF record have been published with a domain corresponding to the IP address.

19. The method of claim 16, wherein the second trusted sender rule comprises a condition that the header section include a header field containing a FROM key and a value and that the value be aligned with one or more attributes of a specific domain using an authentication protocol of DMARC.

20. The method of claim 16, wherein:

the received message includes a digital signature for DKIM authentication;

the method also comprises obtaining a public key and using the public key to determine whether the digital signature may be verified; and

the second trusted sender rule comprises a condition that the digital signature be verified using an authentication protocol of DMARC.

21. The method of claim 16, wherein the second trusted sender rule comprises a condition that an element of a body of the received message include an alphanumeric identifier that matches a known identifier or that has a known format.

22. The method of claim 10, wherein enabling the user to use the client computing device to take action on the received message without further sending the received message to the remote service for analysis if the client computing device determines that the received message originated from a trusted sender comprises:

by the client computing device, prompting to the user to confirm whether to continue reporting the received message; and

by the client computing device, only sending the received message to the remote service for analysis if the client computing device receives confirmation from the user to continue reporting the received message.

23. The method of claim 22, wherein prompting the user comprises displaying a message alerting the user that the received message is from a trusted sender.

24. An electronic message device, comprising:

a processor; and

programming instructions configured to cause the electronic message device to;

receive an electronic message via a communications network,

receive a user activation action that indicates that a user has reported the received message as a potentially malicious message, and

upon receiving the user activation action, determine whether the received message is a mock malicious message or otherwise originated from a trusted sender by;

determining whether any header field of a header section of the received message starts with a predetermined key,

for any header field that starts with the predetermined key, further analyzing that header field to determine whether a value that follows the predetermined key satisfies a first trusted sender rule,

if the value that follows the predetermined key satisfies the first trusted sender rule, determining that the received message originated from a trusted sender, and

if the value that immediately follows the predetermined key does not satisfy the first trusted sender rule, determining that the received message did not originate from a trusted sender;

upon determining that the received message did not originate from a trusted sender, forward the received message to a cybersecurity analyzer server; and

upon determining that the received message originated from a trusted sender, enable the user to cause the electronic message device to take action on the received message without further reporting the received message to the cybersecurity analyzer server.

25. The device of claim 24, wherein the instructions to enable the user to cause the electronic message device to take action on the received message without further reporting the received message to the cybersecurity analyzer server upon determining that the received message originated from a trusted sender comprise instructions to:

prompt to the user to confirm whether to continue reporting the received message; and

upon receiving confirmation from the user to continue reporting the received message, only forward the received message to the cybersecurity analyzer server upon.

26. The system of claim 25, wherein the instructions to prompt to the user comprise instructions to display a message alerting the user that the received message is from a trusted sender.