Date Syntax Searching: Simple date searches and relative date searches
Search terms in the Kenna platform are a valuable resource, but sometimes there are struggles with formatting the query properly and especially around date formatting. The first thing to remember when searching based on dates is to clarify which date function you’d like to use.
Searches can be performed on both Assets and Vulnerabilities. Some search parameters on the asset side include asset_created: & asset_last_seen:, and on the vulnerability side closed_at:, due_date:, fix_published:, vulnerability_found:, vulnerability_created:, vulnerability_last_seen:, and more.
Simple date searches:
When using these search terms, a user can search using specific dates like this:
vulnerability_found:2020-07-07 which would return all vulnerabilities found on July 7th, 2020.
Important Note: For our international customers, one consideration is to ensure the format used within your query matches the format of the date stamps contained in the vulnerability data within your Kenna instance.
Furthermore, one can use “<” or “>” to signify before or after a specific point in time like so:
vulnerability_found:<2020-07-07 which will return all vulnerabilities found before July 7th, 2020, and the opposite search vulnerability_found:>2020-07-07 would return all vulnerabilities found after July 7th, 2020.
Like any other search parameter, you can combine these date terms with other parameters like scoring, or operating system.
vulnerability_found:<2020-07-07 AND vulnerability_score:>90
This particular search will return all vulnerabilities found before July 7th of this year where the score is greater than 90. All of these searches are relatively simple and the hardest part is remembering which symbol “<” or “>” to use. However, there are more advanced searches that you can perform using dates.
Relative Date Searches:
These more advanced searches are based on relative dates, and allow you to create queries and Risk Meters on a certain time frame that is consistent as the date continues to move forward. For example, say one wants to create a risk meter on all vulnerabilities discovered in the past 30 days. You could create a risk meter everyday using the above searches and changing the date, but that is a daily manual effort that is not worth it. Using relative dates instead is much easier.
Instead of creating queries like vulnerability_found:>2020-07-07, and the next day vulnerability_found:>2020-07-08,and the next vulnerability_found:>2020-07-09, and so on, you can create the following search: vulnerability_found:>now-30d, which will return all vulenrabilities found in the last 30 days.
The use of these relative terms also applies on the asset side. Say your asset inactivity limit is set to 30 days, and you want to see all active assets that have not been seen in the last 30 days (meaning these assets were manually set to active) you could leverage the query of asset_last_seen:<now-30d where the asset status is set to active.
Finally, you can use the “AND” modifier to help you search for specific timeframe ranges that may not include “now”. For example, if you wanted to see all vulnerabilities found in the last 30 days, but not include those found in the last week, you would leverage the search
vulnerability_found:>now-30d AND vulnerability_found:<now-7d
These relative terms with multiple parameters can also be combined with other searches. For example, if you wanted to search for all vulnerabilities found in the last 30 days but not including those found in the last week with a score above 90 the search would look like this:
vulnerability_found:>now-30d AND vulnerability_found:<now-7d AND vulnerability_score:>90
For a list of all search terms (dates and otherwise) you can find those here.