Overriding inherited TID settings
An overriding inherited TID setting is a configuration change that
-
changes the inherited setting at the child level,
-
retains the child object setting despite changes to parent objects, and
-
breaks automatic cascading of setting changes from parent to child for that specific setting.
Override behavior and inheritance
To override an inherited setting, change the setting at the child level. Refer to Edit Threat Intelligence Director actions at the source, indicator, or observable Level and Pause or publish Threat Intelligence Director data at the source, indicator, or observable Level. After you override an inherited setting, the child object retains that setting despite changes to the parent object(s).
At the observable level, you can revert from an override setting to the inherited setting, and the system resumes cascading setting changes automatically from the parent indicator to that observable.
Override inheritance scenarios
For example, you might start with these original settings, with no overrides set:
|
Setting |
SourceA |
IndicatorA |
ObservableA1 |
ObservableA2 |
|---|---|---|---|---|
|
Publish |
|
|
|
|
If you override the setting for IndicatorA, the settings would be these:
|
Setting |
SourceA |
IndicatorA |
ObservableA1 |
ObservableA2 |
|---|---|---|---|---|
|
Publish |
|
|
|
|
In this case, any changes to the Publish setting for SourceA no longer cascade automatically to IndicatorA. However, inheritance from IndicatorA to ObservableA1 and ObservableA2 continues, because the observable settings are not currently set to override values.
If you later override the setting for ObservableA1:
|
Setting |
SourceA |
IndicatorA |
ObservableA1 |
ObservableA2 |
|---|---|---|---|---|
|
Publish |
|
|
|
|
Any changes to the Publish setting for IndicatorA no longer cascade automatically to ObservableA1. However, those changes continue to cascade to ObservableA2, because it is not set to an override value.