Create Business Logic-Based Policies

This article will show you how you can use policies to enforce your business rules and logic.

Let's say that your business policies require you to flag any use of private data with an audit logging tag. This isn't a sensitive data leak but the creation of an access audit log for compliance purposes. To implement tagging, you can use the logger warn method in the application:

Package: org.slf4j.Logger

Method: warn

The following policy shows you how to tag three different methods with an audited custom tag. It also identifies any use of the data that should be tagged but aren't; these are then marked as an Insufficient Logging vulnerability.

IMPORT io.shiftleft/default

IMPORT io.shiftleft/defaultdict

## Add new audited tag for the warn methods

IO audited = METHOD -f "org.slf4j.Logger.warn:void(java.lang.String)" { PAR -i 1 "SINK" }

IO audited = METHOD -f "org.slf4j.Logger.warn:void(java.lang.String,java.lang.Object)" { PAR -i 1 "SINK", PAR -i 2 "SINK" }

IO audited = METHOD -f "org.slf4j.Logger.warn:void(java.lang.String,java.lang.Object,java.lang.Object)" { PAR -i 1 "SINK", PAR -i 2 "SINK", PAR -i 3 "SINK" }

## Create a conclusion that checks for the flow of private data without the audit method

CONCLUSION unaudited-data-use = FLOW DATA (payment-data OR location OR account-info OR pii OR medical) -> IO (NOT audited)

WHEN CONCLUSION unaudited-data-use => EMIT {

title: "Unaudited: Customer data is used {{via `$paramname`}} without audit {{in `$methodname`}}",

description: "Customer data is used by the application without an audit log to identify the user accessing the data. This is required as per compliance standards.

## Internal Help

As per SOC2 standards, all uses of private data should be logged for audit purposes. The audit log entry should contain the user's ID accessing the customer information along with other parameters. Refer to this [internal document](https://example.com) to learn more.

## Countermeasures

This vulnerability can be prevented by using the approved audit functions in your application.

## Additional information

**[CWE-223](https://cwe.mitre.org/data/definitions/223.html)**

**[OWASP-A10](https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring)**",

category: "a10-insufficient-logging",

score: "8.0",

vulnerability_description: "Insufficient Logging",

owasp_link: "https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring",

link: "https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring",

cwe_link: "https://cwe.mitre.org/data/definitions/223.html"

}

Whenever there are any issues with data that should be tagged but aren't, you'll see the "Insufficient Logging" category in the Dashboard, along with the number of findings present.

Clicking on the category brings up a list of identified findings.

You can get in-depth information for each finding by opening each one up individually.

Narrowing the Results

The policy above returns too many results; we can narrow what NG SAST returns by focusing on just data used in specific code (in this case, we want to focus on the controller files). To do so, we can enhance the conclusion section to add another IO flow called http. Then, controllers will automatically get tagged as http:

CONCLUSION unaudited-data-use = FLOW IO (http) -> DATA (payment-data OR location OR account-info OR pii OR medical) -> IO (NOT audited)

Then, NG SAST only reports the findings that occur in the controllers.