Tokenized Search Terms

Certain search parameters in Cisco Vulnerability Management are designed to allow for case/location insensitive searches. 

• os
• cve_description
• fix_title_keyword
• hostname
• application

How Tokenized searching works

In this type of query, each word in the parameter is searched for anywhere in the string and in any case. In other words, skip the quotes and you get case-insensitive and location-insensitive searching. 

os:"linux" / os:linux / os:(linux) = find term linux in any location and in any case

os:(Windows Server) / os:(Windows OR Server) = find terms windows OR server in any location and in any case

os:(Windows AND Server) = find terms windows AND server in any location and in any case

os:"Windows Server" = find terms windows AND server in any case in the specified order. 

Tokenized search is efficient and can accommodate complex logic within the paren. For more information, see the queries shown in this article. 

Use wildcards to search

Tokenized searching should make wildcard search nearly obsolete but there may be occasions where they are still needed. Important point of note: 

Note: When a wildcard (* or ?) is added to a search, that search becomes a location and case sensitive text search.

os:"linux*" = find where "linux" is at the start of the string, is all lower case, with any text following. 

No results are found above because Linux is generally capitalized. 

os:"Linux*" = find where "Linux" is at the start of the string, is first letter capitalized, with text following.

The best use for wildcards is when you only want a small subgroup of information that is not differentiated by a whole word. In this example, you are looking for a specific version number and all of its subversions too:

os:"Linux - Linux - Linux - 2.6*" = find case sensitive whole string match for any 2.6 sub versions of Linux.  

While you might get the same results as a tokenized search, starting a query with a wildcard like os:”*Windows Server*” means that on the backend, Cisco Vulnerability Management needs to check every single entry in order to see if it matches as a String value. This is a very inefficient and costly function and for that reason you should not use leading wildcards to avoid query timeouts during periods of high load.