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

Microsoft Malware Protection Center

Secure Hunter Anti -Malware

The post Microsoft cloud protection appeared first on Secure Hunter Anti-Malware.

http://ift.tt/1DuWz8e

Secure Hunter