AppSec Data Design - Managing Application Security Reporting Data

Data management for Application Security (AppSec) reports and test results is often handled with a specialized module of a larger Technology Risk reporting and data management system. What follows are some basic thoughts about the data design to use within such systems.

Every Pen test, SAST, FOSS review and/or other AppSec test that is run against your applications should be recorded with the following common data elements:

1. Name of Application being tested
2. Test performed (Pentest, SAST, DAST, FOSS, etc.)
3. Results of the test
4. Date of the test
5. Who performed the tests
6. Who requested the tests (and/or policy that required the test)
7. Main application URL (URL to home page of the application after login)
8. Child records for all additional URLs tested as part of AppSec testing of the application
9. Notes and Additional Comments

If an automated DAST process spins through all the dependent web pages, it is advisable to generate a log of the URLs processed in a format that can be easily uploaded into the data management system. Coding of an automated solution can prevent the problem of too many URLs to enter and no time for a human to do it. Additional fields can help marry the data to other systems. Each time an AppSec report or record is used to honor a request for proof of security testing of an application, these fields should be filled out or updated in the system as well:

1. Business Area requesting the application security information
2. Business Name of Application Requested
3. Date of Request
4. Date Request was filled

These fields are useful in the following ways:

• The date fields can help with generation of customer service metrics. As the system improves, time to fulfillment should decrease.
• Other fields on this list help with auditing for discrepancies between how the business asks for application security results and how tech teams under IT and/or InfoSec (Information Security) records what tests took place and which apps those tests provided coverage for. As you learn of an unexpected connection between IT application names and the names used in business contexts, you will now have a record of what you’ve learned to help resolve future conflicts.

So how do these naming discrepancies occur? 

Distributed web application systems within medium to large companies or organizations can easily turn into a soup of web pages with no clearly definable boundaries between where one application ends and the next begins. The business usually knows them in terms of web page titles that customers see on each screen. They may also know them by how web services are bundled for sale which can vary greatly from how they are coded. Within IT, code is often built around reusable modules and features get added to an amorphous backend independently of the UI elements that present specific features to customers. Boundaries can blur and what constitutes a “product” or “application” is not always so clear. To solve this problem, “system IDs” and/or “application IDs” may evolve internally within IT. These IDs and their corresponding product names can completely fall out of sync with the names the business knows a product or service by. The relationship between IT product names and business product names is not always one-to-one further complicating resolution. This can turn into a tracking nightmare for Application Security since they manage AppSec testing with development but then deliver the results to the business.

This is why the URL field proposed in this design is so important. And yet, the idea of including this field is often not provided in out-of-the box solutions for managing AppSec data. Having the URL on the Pen test results document itself is useful and is a common best practice. But if the URL is not also included as a field for searching and reporting within your data management system, finding the right report to satisfy requests from business areas can become quite challenging.

I hope you find this post useful in thinking about your Application Security data design. Thanks for reading and have a good day.