That a very standard Vulnerability Scan. Your application need not only hide the http error code 500, but also 404, 403 from the adversary (in other words, always display 200 OK). 404 error happen when the crawler try to navigate to a page that does not exists (http://yourservice.com/ninja.asmx). 403 is went the crawler try to list the content of a folder (ex: http://yourservice.com/images) if you fix the 500 error, the next scan might come back with 403 or 404. Fix all of them at once to avoid back and forth with the security team. By the way beside hiding the error, you might also need to think how to log those errors for administrative review in the future. Could be another red flag if you don't have this control in place.
Ok, for the http errors:
1. make sure the application is redirecting all error to a generic error page, we don't want our nosy adversary to know what was broken
Example:
<system.web>
<customErrors mode="On" defaultRedirect="~/Error.html" />
</system.web>
2. Configure custom error pages in IIS, this will tell the IIS to display custom error page. Example, if someone enter url http://yourservice.com/ninja.php, that out of the application jurisdiction, IIS has to decide what to do with it. if the IIS return 404, then the adversary will know the IIS does not support PHP. etc...
You can configure it through the IIS or copy and paste this into the web.config
<system.webServer>
<httpErrors errorMode="Custom">
<remove statusCode="500" subStatusCode="-1" />
<remove statusCode="404" subStatusCode="-1" />
<remove statusCode="403" subStatusCode="-1" />
<remove statusCode="401" subStatusCode="-1" />
<error statusCode="401" subStatusCode="-1" prefixLanguageFilePath="" path="/Error.html" responseMode="ExecuteURL" />
<error statusCode="403" subStatusCode="-1" prefixLanguageFilePath="" path="/Error.html" responseMode="ExecuteURL" />
<error statusCode="404" subStatusCode="-1" prefixLanguageFilePath="" path="/Error.html" responseMode="ExecuteURL" />
<error statusCode="500" subStatusCode="-1" prefixLanguageFilePath="" path="/Error.html" responseMode="ExecuteURL" />
</httpErrors>
</system.webServer>
3. turn off debug mode (keep the stack traces, etc... to yourself) if not the IBM tool will trigger another flag.
<system.web>
<compilation debug="false" />
</system.web>
4. Test, test, test before letting the other team re-scan/re-run the IBM tool.
Please read...
HTTP Errors <httpErrors> : The Official Microsoft IIS Site[
^]
<customErrors> Element[
^]
HTTP Error 404 in ASP.NET web application[
^]
How To Set Up Custom Error Pages In IIS 7.5 With ASP.NET[
^]