Microsoft cloud protection


Microsoft is using cloud protection to help keep our customers safe. In fact, nearly any detection made by Microsoft security products could be the result of cloud protection. Software developers often ask us how this cloud protection works and how they can improve our cloud’s impression of their software.

How our cloud protection works

When our antimalware products encounter anything unusual, they can send a small packet of information about the event or file to our server. The server then sends back a reply telling the antimalware software whether to block it or not. It can also request a sample for further analysis.
There are three situations that highlight the benefits of cloud protection:

  • If a file is known to be malware by our servers but not by the local antimalware product, the cloud protection module can tell the local product to block or remove it.
  • If a file is known to be clean by our servers, but the local antimalware product detects the file as malware (an incorrect detection situation), the cloud protection module can tell the local antimalware to not detect it, and the incorrect detection does not affect the user.
  • If a local antimalware product encounters a file that we don’t know about, our server can make a determination based on probabilities, and tell the local antimalware software to block it, even without having seen a copy of the file.

It’s this third point that I would like to discuss further.

Improving your software’s cloud impression

We are often asked by software vendors if we have a way for them to pre-whitelist their software. However, our backend processing actually works better if we see your software as it’s naturally distributed. I will outline a few methods to improve our cloud’s impression of your software below:

  • Digitally sign your software using a method accepted by Microsoft. This is the fastest way to get a good cloud reputation because the reputation of a good file can be distributed to all files signed by the same key.
  • Once you have digitally signed your software, be careful that malware isn’t also signed by your key. This will negate any good reputation. You can help avoid this situation by:
    • Making sure you protect your key from being stolen by malware authors.
    • Ensuring your development process prevents a parasitic file-infecting virus from being inadvertently signed by your key.
    • Reading more about the best practices for signing software.
  • If you can’t digitally sign your software, be aware that every minor version of your product will have to build reputation from scratch. This affects vendors who provide a different file on every single download. It doesn’t mean you can’t make bug-fix versions, different languages, etc.
  • Make sure your software doesn’t install malware:
    • Take care to avoid security vulnerabilities. Even if you don’t intend to install malware, a security vulnerability could be detected as your product installing malware.
    • If you download executables off the internet, have your software check a digital signature or cryptographic hash, to ensure it has the correct file you intended it to download. We have seen one case where a popular installer had some URLs distributing malware and we had to detect every one of their installers in case it was downloading one of the malware URLs.
  • Make sure your software isn’t installed by malware:
    • Proactively check your affiliates and companies who bundle your software.
    • Fill out the metadata information such as the information about the author and company in the file resources. If this and the digital signature isn’t enough, consider adding contact information, or a pointer to find contact information on the web. This contact information should direct to the right contact to report a security vulnerability, or work with to fix or prevent a incorrect detection.
  • If you use a runtime packer or obfuscator, you need to be aware that the majority of malware is packed or obfuscated, and this does affect how your software is seen at the back end.
  • Consider how your software is seen and whether it’s installed on the machines of users who really want it. We have honeypots, web crawlers, and automatic software testing. We can look at whether users chose to continue the download after the warning that a program isn’t commonly downloaded. We can also see whether users chose to ignore or remove software if our antimalware detects it. Bad behavior can quickly ruin a good software reputation.
  • There are some behaviors that, while not enough to warrant a detection on their own, do attract the suspicion of human and automated systems. They could be used for legitimate reasons, but are often closely associated with malware behavior. This includes:
    • Installing outside the commonly accepted folders for the type of software.
    • Modifying or adding a sensitive registry key.
    • Process or thread injection.
    • Autonomous internet activity.

If you believe we have made an incorrect detection for your product you can submit a developer contact form. Making a slight change and pushing it out to your software won’t necessarily address any incorrect bad reputation applied to the code signing key you used for the file that was incorrectly detected. Our cloud protection might also note the similarity between the file that it still believes was correctly detected as malware, and the new version.

MMPC

 

Comments (9)

  1. adwbust says:

    thanks for the transparent explaination. a lot wonder if mse does employ cloud tech. maybe change or have a detection name for threats (specifically) detected by your cloud?

  2. bill says:

    did you guys send this? Microsoft account team account-security-nor..

  3. Jenny Moreira Sabando says:

    Muy buena App

  4. adwbust says:

    Inline

    "If a file is known to be malware by our servers but not by the local antimalware product, the cloud protection module can tell the local product to block or remove it." – Experienced this through DSS. A specific sig was downloaded.

    "If a file is known to be clean by our servers, but the local antimalware product detects the file as malware (an incorrect detection situation), the cloud protection module can tell the local antimalware to not detect it, and the incorrect detection does not
    affect the user." – Does MSE download a DSS signature also? What if file was already put to quarantine? Will MSE auto restore (and whitelist) it? That's why on each sig update or on every system startup, MSE should rescan quarantined (and allowed) items.

    "If a local antimalware product encounters a file that we don’t know about, our server can make a determination based on probabilities, and tell the local antimalware software to block it, even without having seen a copy of the file." – Is this a joke? Never
    seen a detection like this. Is this like Norton's Suspicious.insight and Panda's Trj/CI.A?

  5. adwbust says:

    MSE behavior monitor (detections) are passive. Are they also purely dependent on local sigs? Or do they use the MAPS cloud? Have you heard of McAfee raptor? Check it out. First Artemis (file attribute cloud) and now Raptor (file behavior cloud). McAfee is innovating! I can't say the same for MMPC. Stop idling and rotting by.

  6. adwbust says:

    eleanor, you got no prompt because you're using an admin account. now, for cloud backup, use onedrive, dropbox or any equivalent. ask on the microsoft answers forum for advice.

  7. Enri Pahapill says:

    Thank You!

  8. Danny says:

    How does the cloud signal the local antimalware to block a locally undetected problem, if the cloud reviews and makes locally based decisions as a triggered response to local detection?

    Wouldn’t this mean then, that in this particular context of the local – cloud relationship, that the cloud functions could be emulated entirely by end users simply maintaining the latest definitions via automatic updates?

    If so, this would imply that MAPS then otherwise offers no other end user benefit in this diagnostic regard.

    What is the use of developing a cloud based diagnostic system that has different definitions than those given to the end user?

    Is there a local cpu load for comparison analysis on these exchanges that conduct perhaps, secondary and tertiary byproduct calculations locally that are not viewable by end users?

    How about removing the need for local definitions altogether to instead integrate MAPS based definitions into the end user environment? Afterall, you’ve already required MAPS enrollment in order for end users to enjoy other security features that should have been built into the local program to begin with.

  9. Crystal Geng says:

    How do get this cloud protection for my computer? Is it free? I can’t afford it if it isn’t.
    I’m doing a paper for school and my computer said my macros was not enabled and I can’t do my paper without it be enabled. Can someone help me with this? I have to get my paper done. Thanks,
    ]

Skip to main content