Ruby/Python/JS/Swift: Add category of Private information to shared sensitive data heuristics #16446
Conversation
joefarebrother
force-pushed
the
shared-sensitive-heuristics
branch
from
b3d9a6f
to
23fbfce
Compare
No change note is needed for Swift, as the new heuristics are unused and thus should not affect any queries.
joefarebrother
changed the title
There was a problem hiding this comment.
As the author of the private information regexps for Swift (class SensitivePrivateInfo), I'm happy to see these expressions being used more widely. They've already had a reasonable amount of testing and iteration in Swift, and I expect they will work pretty well for other languages with minimal or no additional tuning.
| @@ -49,6 +49,7 @@ class SensitiveCredential extends SensitiveDataType, TCredential { | |||
| exists(SensitiveDataClassification classification | | |||
| not classification = SensitiveDataClassification::password() and // covered by `SensitivePassword` | |||
| not classification = SensitiveDataClassification::id() and // not accurate enough | |||
| not classification = SensitiveDataClassification::private() and // covered by `SensitivePrivateInfo` | |||
There was a problem hiding this comment.
I see you've excluded the new results from Swift for now. Since they're a near duplicate of Swift's existing class SensitivePrivateInfo I think we should aim (now or later) to define that in terms of the new result classification instead, similarly to how class SensitivePassword already works. This may add a few new results (for SSN and CCN) in the four or five Swift sensitive data queries.
There was a problem hiding this comment.
... I don't mind doing this as follow-up actually. I already made half the changes I'll need to run a test of the SSN and CCN terms!
| print(debit_card) # NOT OK | ||
| print(bank_number) # NOT OK | ||
| print(bank_account) # NOT OK, but NOT FOUND - "account" is treated as having the "id" classification and thus excluded. | ||
| print(accountNo) # NOT OK, but NOT FOUND - "account" is treated as having the "id" classification and thus excluded. |
There was a problem hiding this comment.
These NOT FOUND results are good observations. We can think about mechanisms for limiting the exclusions perhaps and finding more results in cases like these.
There was a problem hiding this comment.
Should that be considered for this PR or as potential follow-up?
There was a problem hiding this comment.
As potential follow-up I'd say. There will always be more improvements we can make to heuristics like this.
|
@geoffw0 What are the next steps for this? Should I just be waiting for an approval from each language team? |
|
@joefarebrother: Could you summarise what changed results your evaluations showed. |
|
@erik-krogh There are new results for New results in ruby sensitive get looks like a few TPs from new heuristics. (The MRVA run that restricts to only new heuristics shows some apparent FPs, but they are also present in the run of the full version of the query prior to changes; and appear to be the result of some nodes being spuriously detected as calls to several different methods including those matching sensitive heuristics) Python cleartext storage and weak sensitive hashing have a few new results for which the sources look like TPs from new heuristics. |
Adds a category of private information to the shared sensitive data heuristics file.
This may result in new results for the following queries:
rb/sensitive-get-querypy/clear-text-storage-sensitive-datapy/clear-text-logging-sensitive-datapy/weak-sensitive-data-hashingjs/clear-text-stotage-sensitive-datajs/clear-text-logging