You can save any search for later reuse. Any IT Security Search operator or administrator can save searches and run saved searches, but only administrators can make them public for shared use.
To save a search, click the drop-down icon at the left edge of the search box and click Save Current Search. Proceed to configure your search in the popup that appears:
|
For example, Domain:{{Domain}} will make IT Security Search prompt you for the value of the Domain field, labeled "Domain"; Domain:{{Active Directory Domain}} will also prompt you for the value of Domain, but the label will be "Active Directory Domain". You can manually construct search strings that include this syntax, without using the field selector. This helps you provide descriptive labels for parameters. |
When you have configured these options, click Save.
To run an existing saved search, click the drop-down icon at the left edge of the search box; the available saved searches are listed at the bottom of the popup that appears. You can filter the list by clicking tag buttons in the Saved Search Categories drop-down.
You can publish a search to make it available to all operators only if you are an IT Security Search administrator.
In the saved search list, the items have a lock icon showing their state. A private search has a closed lock icon; click the icon to make it public. A public search has an open lock icon; click the icon to make it private.
To delete a saved search, highlight it in the saved search list and click the cross icon.
Saved search import and export capabilities help you back up and restore your IT data analysis knowledge and share it with other IT Security Search users.
To use the Import and Export actions, click the drop-down icon at the left edge of the search box; these actions are available at the top of the drop-down menu.
When you click Export, you are prompted to save a *.yaml file. The resulting file will contain all saved searches created under your account plus any saved searches made public by administrators.
NOTE: This action saves not only searches but also any custom action links defined in your IT Security Search deployment. For details about making custom action links, see Customizing Action Links. |
When you click Import, you are prompted to select a previously exported *.yaml file. If the file includes any searches with the same names as your existing searches, you have the option to collectively skip, overwrite or automatically rename such searches.
IMPORTANT: Overwriting administrator-created public saved searches is disallowed for IT Security Search operators, but not for administrators; in this situation, if you are an operator, the search in the source file is silently skipped instead. |
An action link is a clickable search link displayed to the left of a details page for an object. Action links are a way to enhance the cohesion of data that is linked in any way and enrich the context for the data you discover.
IT Security Search provides a number of action links out of the box. For example, you get the Files and folders owned by this user link when you view the details of a user and the Who changed permissions on this file link for a file. In addition to such bundled action links, you can define your own and bring them into your IT Security Search deployment using an import operation.
To define an action link, you need to create a valid YAML file that specifies the details of that link. A single YAML file can contain definitions of multiple action links along with definitions of saved searches. If action links and saved searches are in a the same YAML file, that doesn't mean they are associated with one another in any way. Each one is defined individually, and you can group them into files however you like.
The following is an example of two YAML-formatted action link definitions specified after saved search definitions in a single file. If you need additional information about the valid format, see the documentation at https://yaml.org.
SavedSearches:
...
ActionLinks:
- Name: Logons by this user
Query: 'Who:"{LogonName}" AND (What:authentication OR What:logon)'
Source: Users
Target: Events
Condition: '-Department:Management'
Tags:
- My company's action link kit
- OnPremise
- Name: Applications for this tenant
Query: 'objecttype="Azure Applications" AND Tenant:"{name}"'
Source: Azure Tenants
Target: Azure Applications
Tags:
- My company's action link kit
- Cloud
- Name: Find this event in Event-o-pedia
Query: 'http://eventopedia.cloudapp.net/?EventID={EventID}'
Source: Events
External: true
The following fields are required in an action link definition (mandatory fields are bolded):
Only IT Security Search administrators can import and reset actions links. To import action links, click the drop-down icon at the left edge of the search box and select Import. Note that both action links and saved searches are imported by this action. If you want strictly action links, don't include any saved searches in the *.yaml file intended for import.
NOTES:
|
To remove all custom action links and restore the default set, click the Reset Actions button, which is at the top of the Actions section in object details. Note that the button removes all custom action links for all object types and leaves only the default set.
The following examples explain how IT Security Search tools can be applied in practice to real-life situations.
To find events where a particular user is somehow involved (as the doer or as a subject), run a search for any of the variety of names that identify the user in the environment. You can supply the first name, last name, full name, logon name and so on.
The results of your search put the most relevant matching users at the top of the list. If there are too many matches, refine the results using facets.
From a different perspective, if you need to find a user whose name you are not sure about but whose manager's name you remember, try searching for the manager's name, then opening the details of the manager's user account and finding the user you are looking for among the manager's direct reports.
A typical use case is tracking the activity that involved a particular object, such as a file, folder, group or user account. You begin by finding this object; this provides a starting point and a context for your session. The next step is to use the links in the object's details view. This is the easiest way to create a context and filter out irrelevant data.
Another option is to start with events directly, especially if you expect to find specific events within a specific period of time. To specify the period, use the date range filter. The graphical timeline in the result grid can help you quickly locate peaks of activity that need closer examination.
For example, suppose you have discovered an unknown application called testaadapp in your Azure environment, and you want to know how it got there. To find the relevant events, run a search like the following:
testaadapp AND description:"add"
In the events that you find, use the Who link to discover who added the application.
You can learn a lot about a security incident just by looking at the initiator of an event and the account or object affected by the event. For this common pattern, the Who and Whom fields are defined for a variety of events. This gives you a consistent analysis tool, no matter what event fields the relevant data is actually stored in.
The technique is especially useful when you are looking at the account management activity of a particular user with administrative privileges.
IT Security Search provides quick access to information about files and folders owned by a user and all permissions assigned to the user; for that, use the Files and folders owned by this user, Files and folders where this user has direct permissions and Files and folders where this user has permissions (both direct and indirect) links in the details view for the user you are interested in.
Conversely, if you start with a particular file or folder, its details contain a table of permissions, which can prompt your further steps.
You can easily follow permission assignment activity using the Who changed permissions on this file and Who changed permissions on this folder links in the details view of a file or folder, respectively.
Object change history is available only if the Recovery Manager for Active Directory connector is enabled. For information about changes to an object and recovery tools, go to the History tab on the object's details page. This tab has two modes: Changes and Backups.
In Backups mode, the most recent backup states (three by default) of the object are shown, with details about how their attribute values differ from the current state. You can fully restore any of these states by clicking the Restore from backup link for that state.
In Changes mode, you have more fine-grained control and can view and roll back individual attribute changes. All changes recorded in the most recent backups are shown, including the "before" and "after" values, and you can sort them by attribute name or by date. To roll back individual changes, select their check boxes in the table and click the Revert to the previous attribute state link.
NOTE: In Changes mode, the date shown for a particular change is the date of the backup that contains information about that change. The date can be empty, meaning that the change is recent and has not been recorded in any backup state. |
You can track attempts to probe Active Directory prior to intrusion. One symptom of such activity is a trail of LDAP queries from unlikely workstations or by suspicious accounts. It may mean an effort to find vulnerable Active Directory accounts with administrative privileges. The following types of LDAP query in quick succession are telltale signs of this:
In IT Security Search, you can track such queries by running the following search:
What:"AD Query Performed"
In the search results, examine the LDAP - Attributes and LDAP - Filter fields.
In the following examples, trustedworkstation1 and trustedworkstation2 are computers where you don't consider running LDAP queries suspicious; with all other workstations, it's best to take a closer look.
Similar suspicious behavior often precedes pass-the-hash attacks that rely on stored password hashes. In this case, it can be accompanied by series of remote logon attempts to computers in the network. To capture such activity, you should also search for logon events that occurred around the same time as the LDAP queries you found.
See also the following topics for examples of investigations that IT Security Search can help carry out:
Suppose a critical file (such as a project roadmap or payroll file) is showing signs of tampering. You want to use IT Security Search to look into this.
To make the investigation as efficient as possible, make sure that data from the following sources is available:
You are about to examine the circumstances of file modifications, so it makes sense to start by finding the affected file. This will provide clues about where to go next and also mark a point (as a breadcrumb) that you can always fall back to, even if your next steps take you too far.
When you have found the file, open its full details and use the Who accessed this file link provided in that view. In the list of events that are found, find a "File changed" event and use the What facet to filter out other types of events. Try to spot any unlikely users in the list of file change events.
Suppose you find an event by a user who is not meant to have access to the file. Note the time of the event, and then open the details of the event and click the user name. In the the user details view that opens, click the Files and folder where this user has permissions link. If the file in question is not listed, that means the permissions have been rolled back by now—likely a piece of incriminating data.
You can also view the entire history of permission management for the file. Use the breadcrumbs to go back to the file details view, and click the Who granted permissions to this file link.
Use the breadcrumbs to go back to the user details view, and click the Activity initiated by this user link. Use the time range filter to restrict the results to a period around the time of the suspicious file modification. The results may reveal noteworthy details about the situation. Consider examining InTrust-specific user session events for the following clues:
In addition, check if there were any attempts to clear security logs.
© ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center