Frequently asked questions

Frequently asked questions and answers concerning the basic value, applicability, and operation of Microsoft Security Risk Assessment.

Fuzzing is an automated technique used by hackers to find security vulnerabilities in software products. Fuzzing consists in repeatedly running a software product with modified, or “fuzzed,” inputs with the goal of finding security vulnerabilities (like buffer overflows or crashes) in that product.

You install your application to be tested, along with a set of seed files, onto an Azure-hosted Customer VM we provide. A number of different fuzzers start up and exercise your code for a period of time, yielding security bugs, which you’d then repair. This workflow is the essence of a Security Risk Detection job, which is the way this service is sold.

Hackers — whether security professionals or state actors — constantly probe software for previously-unknown vulnerabilities. These vulnerabilities can allow the attacker to influence or control the application or server that contains them, and are known as zero-days, or 0days (named after the amount of warning the software publishers are given before a disclosure). If hackers find zero-days in your software, they could attack your customers, putting your reputation and your bottom line at risk.

How does fuzzing address this problem?

  • Fuzzing is a very effective technique used by hackers to find product vulnerabilities.
  • Fuzzing is not free, however: effective fuzzing, even with the most efficient algorithms, requires significant machine time.
  • Hackers consider this cost an investment toward the end-goal of finding and selling a vulnerability on the black market.
  • Fuzzing your software before hackers do decreases the number of bugs on your attack surface, resulting in an inflated per-bug cost, thus decreasing hackers’ ROI, encouraging them to look elsewhere.

Microsoft’s Security Development Lifecycle (SDL) recommends fuzzing all attack surfaces of a software product, especially those that expose a data parser to untrusted data. An attack surface is any product interface that may take untrusted data as input in any form (for instance, as a file or a network packet). After significant code changes, the product should be re-fuzzed in order to test that new security vulnerabilities have not been introduced.

Security Risk Detection currently supports fuzzing Windows applications and support for Linux is in preview.

Two things: an application and seed files. Depending on your application, you may need write a test harness.

You can — but how and whether you should depends on your site’s threat model. Security Risk Detection doesn’t currently identify vulnerabilities like cross-site scripting or request forgeries, and other issues on the OWASP Top 10. But it can certainly ensure any exposed data parser is hardened and resilient to attack.

Yes. Whether you’re improving the security of your code by doing so, depends on how your application is designed and deployed. We’ve provided a way of analyzing your managed code’s security risk we hope is useful.

  • Target Binaries – Application, Library or a Service to be tested. We need only the Binaries, NO Source code required
  • Seed Files – One or more files of a single file extension to exercise the full set of parser functionality and optimize code coverage
  • Test Driver – custom executable that transmits seed data to the target entry point
    • Not needed if the target binary is itself an executable that takes a seed file path as an argument