ASP.Net Core Application process failed to start due to Anti-virus scanning

This article is contributed. See the original author and article here.

When you host ASP.Net Core 2.x version in IIS/IIS Express, the application runs in a process separate from the IIS worker process (out-of-process) with the Kestrel server. Here you can find the detailed explanation on publishing an ASP.NET Core app to an IIS server.


 


Recently, I came across an issue where ASP.Net Core 2.x version failed to start with the error below:


 


 


Exceptions:


 


After browsing the page, the exception on the browser:


 


HTTP Error 502.5 – Process Failure


 


Common causes of this issue:


The application process failed to start


The application process started but then stopped


The application process started but failed to listen on the configured port


 


Troubleshooting steps:


Check the system event log for error messages


Enable logging the application process’ stdout messages


Attach a debugger to the application process and inspect


 


In the Event Viewer logs, the error will be:


 


Event ID 1020 from Source: AspNetCoreModuleV2


 


Application ‘/LM/W3SVC/1/ROOT/Site’ with physical root ‘<path>’ failed to start process with commandline ‘<path><application>.exe ‘ at stage ‘CreateProcessW’, ErrorCode = ‘0x80070002’, assigned port xxx, retryCounter ‘0’.


 


 


Root Cause:


There are many reasons when process fails to start. One of the reasons is documented here:


ASP.Net core application exe was quarantined by the Anti-virus.


 


 


Resolution:


The application runs in a process separate from the IIS worker process (out-of-process). So two processes will spawn to process the requests: IIS worker process(w3wp.exe) and Application process(dotnet.exe/Application.exe)


Both w3wp.exe and exe of the application(application.exe or dotnet.exe) must be excluded from Anti-virus scanning.


 


This article includes information about folders that need to be excluded from antivirus scanning in ASP.net applications.

Optimize fraud control with scenario segmentation in Dynamics 365 Fraud Protection

Optimize fraud control with scenario segmentation in Dynamics 365 Fraud Protection

This article is contributed. See the original author and article here.

To protect your business in today’s rapidly evolving fraud landscape, it’s critical to incorporate the use of both rules and machine learning. Machine learning can quickly detect new and emerging fraud patterns, and output a risk score to indicate the probability of fraud for a particular event. Rules can then use that risk score to automate decisions, enabling you to control the level of risk that’s right for a particular scenario. So how do you write an effective rule set selecting just the right amount of risk to minimize fraud as well as false positives?

While it may be tempting to set a singular risk threshold for your entire business, this “one size fits all” approach can result in significant fraud loss or unnecessary friction for good users. Instead, we recommend dividing your business into meaningful segments, and setting custom risk thresholds for each segment. This technique is known as scenario segmentation and it can be a powerful tool to help you optimize decision accuracy and increase profits.

Select segments that share a common risk level

Segments can be large or small, and the number of segments may vary depending on the size and diversity of your business. However, what is most important is that the events within each segment all share a common level of risk.

These segments may slice on attributes such as product type, payment method type, or country and region. In Dynamics 365 Fraud Protection, you can use Virtual Fraud Analyst to help identify slices, which have above- or below-average fraud rates.

For example, if you sell both physical and digital goods, you may observe that the two have very different fraud rates, indicating that these would make appropriate segments. However, upon further inspection, you observe that within the digital segment, fraud rates still vary considerably. Some digital products, such as gift cards, may be heavily targeted by fraudsters and account for a disproportionate amount of all digital fraud. In contrast, other digital products, such as some low-risk subscriptions may have consistently low fraud rates, indicating that they are rarely targeted. Therefore, these two product groups can each be placed in their own segment.

Balance segmentation needs with operational efficiency

While more segments allow for more granular control, it’s important to remember that each additional segment will require additional effort to maintain. While you could create unique segments for every product in your catalog, each with their own individualized score cutoff, this would quickly become unreasonable to manage. Therefore, it’s important to be mindful of available resources and ensure that the operational load does not exceed a reasonable capacity.

Configure risk-based thresholds for each segment

After your segments have been defined, the next step is to choose appropriate score cutoffs for each segment. Generally higher-risk segments (such as gift cards) will have low cutoffs, minimizing fraud loss, while lower-risk segments (such as subscriptions) will have high cutoffs, decreasing false positives and reducing customer friction. It is important to consider factors such as profit margin, fraud rate, rejection rate, and false positive rate when setting this cutoff.

After you determine your segments and their corresponding score cutoffs, the final step is to implement your segmentation strategy using real-time rules. The rule engine in Dynamics 365 Fraud Protection provides you with the flexibility to easily segment your traffic and set custom score cutoffs for each segment.

As in the example above, given their differing fraud rates, you may want to set a lower score threshold for gift cards, and a higher threshold for subscriptions. You can accomplish this with the following rules:

RETURN Reject()WHEN @"productList.category" == "Subscription" and @"riskScore" > 700
RETURN Reject()WHEN @"productList.category" == "Gift Card" and @"riskScore" > 400

These rules are written in the custom rules language included in Dynamics 365 Fraud Protection. For more information, check out the Language guide for Fraud Protection rules.

Next steps

Segmenting your traffic and writing effective rules is a crucial step in protecting your business from fraud. Dynamics 365 Fraud Protection offers several tools to make segmentation easy and effective. Take advantage of the virtual fraud analyst to help select appropriate segments and cutoffs, and learn how to use Dynamics 365 Fraud Protection’s rule engine to create and manage rules, allowing you to automate decisions for each segment.

If you are not currently using Dynamics 365 Fraud Protection, check out the documentation to learn more and start a free trial today.

The post Optimize fraud control with scenario segmentation in Dynamics 365 Fraud Protection appeared first on Microsoft Dynamics 365 Blog.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

RCE Vulnerability Affecting Microsoft Defender

This article is contributed. See the original author and article here.

Original release date: January 14, 2021

Microsoft has released a security advisory to address a remote code execution vulnerability, CVE-2021-1647, in Microsoft Defender. A remote attacker can exploit this vulnerability to take control of an affected system. This vulnerability was detected in exploits in the wild.

CISA encourages users and administrators to review Microsoft Advisory for CVE-2021-1647 and apply the necessary updates. 

This product is provided subject to this Notification and this Privacy & Use policy.

Cisco Releases Security Updates for Multiple Products

This article is contributed. See the original author and article here.

Original release date: January 14, 2021

Cisco has released security updates to address vulnerabilities in Cisco products. A remote attacker could exploit some of these vulnerabilities to take control of an affected system. For updates addressing lower severity vulnerabilities see the Cisco Security Advisories page.

CISA encourages users and administrators to review the following Cisco Advisories and apply the necessary updates:

This product is provided subject to this Notification and this Privacy & Use policy.

Juniper Networks Releases Security Updates for Multiple Products

This article is contributed. See the original author and article here.

Original release date: January 14, 2021

Juniper Networks has released security updates to address vulnerabilities affecting multiple products. An attacker could exploit some of these vulnerabilities to cause take control of an affected system.

CISA encourages users and administrators to review the Juniper Networks security advisories page and apply the necessary updates.

This product is provided subject to this Notification and this Privacy & Use policy.