Best Practices for scanning in a production environment
When running tests in IBM Security AppScan Standard, how can you make certain that no information is changed in the database?
Tests do not change data within the database, but there is a possibility that AppScan Standard will inject data into the database.
Note: This information is included (and expanded) in Help pages in AppScan Standard version 8.6 and later. Go to AppScan Standard UI -> Help -> AppScan Help and search for "Live production environments".
Since AppScan Standard may inject data into the database during a test, it is recommended that you create a test account to perform the scanning with so this information can be removed or ignored after the scan.
Best Practices for security scanning in a production environment:
- Use a test account:
Use a dummy/test account that can be easily tracked. (Example: To make sure services are not really ordered.) This will also help the site administrators clean the site after the test.
Please consider this criteria for test accounts:
- Permit access only to test records in the database so that modified records can be restored.
- New records created by the test account will be deleted.
- Purchase orders (or other transactions) from the test accounts will be ignored.
- If transactions have an impact (such as when dealing with stocks), the account should have access to test records only.
- If the site has forums, the test account should only access test forums so that real customers will not be able to see the tests created during the test phase.
- Use more than one test account. If the site uses different privileges for different accounts, then set another test account to have differing privileges. This will ensure a more comprehensive test of the application.
- The dummy/test account should not have administrative level access.
- Prevent e-mail flooding:
Identify pages that use e-mail notifications and configure these to be excluded from the scans. AppScan Standard will generate a lot of requests and can overload an email server if you are not careful.
This can be difficult; however, there are several techniques to overcome this:
- Test the page(s) in Quality Assurance (QA) and exclude them in production. In the QA process, change the e-mail address to a dummy mailbox.
- When running a scan on a production environment, test only one web server and prevent it from connecting to the SMTP server when running your scan.
- Configure the scans Automatic Form Filler to insert a unique value in the email field so the email recipients will be able to easily identify that AppScan Standard generated the request.
- If possible, send the emails to a Junk Mail destination.
- Develop and test 'clean up' scripts in advance:
After the production scans are executed, utilize these scripts/programs in order to remove test data created by the scans. Include a procedure to reset the test account user settings.
- Identify session parameters and tokens that would invalidate the session:
These can usually be obtained from the application owners. If you have an invalid script, make sure you do not spider through it automatically.
- Account invalidation:
Identify any account invalidation routines, as the scan should avoid these routines.
- If possible, turn off account invalidation for failed password attempts.
- If not possible to turn off account invalidation, then scan the login pages as separate runs using an test account and password.
- A scan may not work correctly if the login page is not scanned. In this case, it is better to configure it to scan the login page but not test it.
- Authentication considerations:
- Scan pages that can be accessed outside of the application (pages without authentication) as separate scans.
- For pages that require authentication and seem to be giving incomplete runs, you may consider turning off the Infrastructure tests and focusing on the Application tests (such as Cross-Site Scripting and SQL injection).
- Interactive crawls:
Use interactive crawls to identify sensitive areas (HR, Payroll, Financial) and configure them as special scans. Another way to exclude them is by setting the test account permissions.
- Disable Intrusion Detection System (IDS)/ Intrusion Prevention System (IPS):
If possible, disable IDS/IPS systems that may obscure results, or scan around them.
- Scanning through a proxy:
If possible, do not scan through a proxy. While this is supported, the proxy has the potential to obscure results.
- Automatic Form Fill:
Make sure to configure the Automatic Form Fill (Scan Configuration > Automatic Form Fill) to fill forms with valid values.
Translate this page: