Create an indicator

EclecticIQ Intelligence Center can ingest and disseminate indicators to model and to describe the fingerprints that threat actors leave behind when they carry out malicious activities.

Indicators help identify specific observable patterns. These breadcrumbs can point to behaviors, infrastructure, assets and resources that can lead to threat actors.
Indicators contribute to building context to the cyber threat scenario under investigation, so that you can react with an appropriate course of action, as well as implement preventive measures.

Indicators, or indicators of compromise (IOCs), are fingerprints that potentially malicious actors leave behind in a targeted system or environment.
They act as red flags to point out anomalous or unusual activity or behavior.

For example, you can spot indicators in logs, call stacks, tracebacks, network streams, and responses to request calls.
Look for unexpected data such as:

  • Unusual spikes in incoming or outgoing network traffic.

  • Access from IP addresses in unexpected geographic locations.

  • Anomalous DNS requests.

  • Access across security zones.

  • Connections on unusual ports or protocols.

  • Hosts systematically failing to connect to a target.

  • High counts of failed login attempts.

  • Unusual database activity.

  • Suspicious file or registry changes.

Create an indicator


Required fields are marked with an asterisk ( * ).

There are two ways of creating an indicator :

  • In the top navigation bar of a graph, click , and then Indicator.

  • In the side navigation bar of the Dashboard, click , and then Indicator.

If you create an indicator from a graph, double-click its icon to access its details page.

If you create an indicator from the Dashboard, its details page is displayed automatically.

Fill in the indicator's details as follows:

Define the general options

  1. In the Title field, assign the new indicator entity a clear and descriptive name.
    The name you specify here appears on the entity detail pane, in the header section.

  2. In the Analysis field, enter non-structured information such as additional context, references, links, and so on.
    This is where you tell the story of the entity, and where you describe the entity with as much relevant detail as possible.

  3. From the Types drop-down menu, select an option to define the threat actor type you want to describe and identify.

  4. In the Confidence field, assign an estimated level of confidence to assess the accuracy and trustworthiness of the entity information.

  5. From the Likely impact drop-down menu, select an option to assess the estimated impact of the intrusion on the targeted system or organization.

Define the characteristics

This section breaks down the main components of the indicator in a structured, standardized, and consistent way.

  1. In the Time window field, define a start and an end date to record a specific time interval when the anomalous artifact was or the event activity occurred.

  2. In the Test mechanism field, enter a test mechanism that enables the Intelligence Center to share entity information with external tools and systems.
    In particular, it is useful to send indicator information to an IDS/HIDS/NIDS to test it against a tool-specific rule.
    When matching hits are returned, you can either analyze them further, or include them in an automation workflow.
    For example, to generate sightings.

    • Generic: generic test mechanism to interact with a generic system supporting plain text format as an input.

    • Snort: Snort test mechanism.
      You can include the indicator in an outgoing feed to a Snort instance.
      The Snort rules in the indicator are used to look for matching patterns in the Snort logs.
      You can configure Snort so that matching hits trigger a follow-up action.
      For example, creating a sighting or adding a malicious entry to a blocklist.

    • YARA: YARA test mechanism.
      You can include the indicator in an outgoing feed to a YARA instance.
      YARA uses the rules in the indicator to look for matching patterns in the target files or locations you specify in YARA.
      You can feed indicators from the Intelligence Center to YARA to look for, identify, and classify malware samples.

  3. In the Sighting field, enter a sighting characteristic. This means that you observed a distinct occurrence of the indicator in your environment.

Under Characteristics, click Characteristic, and then select an option from the drop-down menu to display additional fields in the editor, where you can enter specific details about the selected item in a structured way.

Select the Time window option to define a time period when the anomalous artifact or event activity took place.

  • Use the Start time drop-down menu calendar to select the date marking the beginning of the time period.

  • From the Start precision drop-down menu, select an option to provide an estimation of how accurate the start date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  • Use the End time drop-down menu calendar to select the date marking the end of the time period.

  • From the End precision drop-down menu, select an option to provide an estimation of how accurate the end date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.


Although you cannot set the start time to after the end time, you can set the observed time to after the end time. This is useful in cases where a threat ended before it was observed.

Click Characteristic, click Test Mechanism, and then select Snort to define a Snort test mechanism to search Snort logs for matching patterns, based on the specified Snort rules.

images/download/attachments/13570299/Snort-ids.png

  1. From the Type drop-down menu, select Snort.

  2. From the Efficacy drop-down menu, select an option to assess the effectiveness of the test mechanism at detecting the targeted observables.

  3. In the Product name field, enter the name of the Snort-compatible tool used to author the rules.
    Specify a CPE name, if available.

  4. In the Version field, enter the version of the Snort-compatible tool used to author the rules.

  5. In the Signature (rule) field, enter the Snort rule you want to use to look for malicious patterns and behaviors.
    The rule needs to be complete and in the Snort rule native format.

    1. Event filters: event filtering helps you reduce data noise.
      It sets a threshold to limit the number of times an event gets logged during a specified time period.

      • Click Add or More to insert new rows or input fields, as necessary, where you can enter additional event filters.

      • To confirm the current input and to display a new input field, press ENTER.

      Rate filters: rate filters change rule behavior.
      They can trigger a follow-up action in Snort when the rule exceeds a predefined amount of matches in a specified time interval.

      • Click Add or More to insert new rows or input fields, as necessary, where you can enter additional rate filters.

      • To confirm the current input and to display a new input field, press ENTER.

      Event suppressions: event suppression disables logging for irrelevant events, based on an IP list.

      • Click Add or More to insert new rows or input fields, as necessary, where you can enter additional event suppression filters.

      • To confirm the current input and to display a new input field, press ENTER.

  6. In the Name field, enter the name of the producer who authored the rules.
    This value identifies the source of the rules.

  7. Use the Start drop-down menu calendar, to select the date marking the beginning of the relevant time period the data refers to.

  8. From the Start precision drop-down menu, select an option to provide an estimation of how accurate the start date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  9. Use the End drop-down menu calendar, to select the date marking the end of the relevant time period the data refers to.

  10. From the End precision drop-down menu, select an option to provide an estimation of how accurate the end date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  11. Use the Received drop-down menu calendar, to select the date when you obtained the data.

  12. From the Received precision drop-down menu calendar, select an option to provide an estimation of how accurate the received date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  13. In the Reference back URL field, enter a valid URL pointing to relevant reference information on the indicator, if available.
    The field takes only URLs as input.
    Enter one URL per input field.

    1. To confirm the current input and to display a new input field, press ENTER.

    2. To remove an entry from this section, click the cross icon corresponding to the item you want to remove.


Click Characteristic, click Test Mechanism, and then select YARA to define a YARA test mechanism to use YARA pattern matching functionality to look for, identify, and classify malware samples based on the specified YARA rules.

images/download/attachments/13570306/yara.png

  1. From the Type drop-down menu, select YARA.

  2. From the Efficacy drop-down menu, select an option to assess the effectiveness of the test mechanism at detecting the targeted malware samples.

  3. In the Signature (rule) field, enter the YARA rule you want to use to look for malicious patterns. The rule needs to be complete and in the YARA rule native format.

  4. In the Name field, enter the name of the producer who authored the rules.
    This value identifies the source of the rules.

  5. Use the Start drop-down menu calendar, to select the date marking the beginning of the relevant time period the data refers to.

  6. From the Start precision drop-down menu, select an option to provide an estimation of how accurate the start date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  7. Use the End drop-down menu calendar, to select the date marking the end of the relevant time period the data refers to.

  8. From the End precision drop-down menu, select an option to provide an estimation of how accurate the end date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  9. Use the Received drop-down menu calendar, to select the date when you obtained the data.

  10. From the Received precision drop-down menu, select an option to provide an estimation of how accurate the received date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  11. In the Reference back URL field, enter a valid URL pointing to relevant reference information on the indicator, if available.
    The field takes only URLs as input.
    Enter one URL per input field.

    1. To confirm the current input and to display a new input field, press ENTER.

    2. To remove an entry from this section, click the cross icon corresponding to the item you want to remove.

Click Characteristic, click Test Mechanism, and then select Generic to define a generic test mechanism to use, for example, rule or regex-enabled pattern matching functionality to look for anomalous events, actions, behavior, or potentially malicious artifacts.

images/download/attachments/13570312/generic-logo.com.png

  1. From the Type drop-down menu, select Generic.

  2. From the Efficacy drop-down menu, select an option to assess the effectiveness of the test mechanism at detecting the targeted malware samples.

  3. In the Description field, enter a short description to provide additional context or extra details about the mechanism, the authoring tool or the rule format.
    Specify a CPE name, if available.

  4. In the Specification field, enter the mechanism you want to use to look for anomalies or malicious artifacts.
    For example, a rule or a regex.

  5. In the Name field, enter the name of the producer who authored the rules.
    This value identifies the source of the rules.

  6. Use the Start drop-down menu calendar, to select the date marking the beginning of the relevant time period the data refers to.

  7. From the Start precision drop-down menu, select an option to provide an estimation of how accurate the start date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  8. Use the End drop-down menu calendar, to select the date marking the end of the relevant time period the data refers to.

  9. From the End precision drop-down menu, select an option to provide an estimation of how accurate the end date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  10. Use the Received drop-down menu calendar, to select the date when you obtained the data.

  11. From the Received precision drop-down menu, select an option to provide an estimation of how accurate the received date is: from second (dead-on accurate) to year (inaccurate).
    If you do not set precision, time is measured in seconds.

  12. In the Reference back URL field, enter a valid URL pointing to relevant reference information on the indicator, if available.
    The field takes only URLs as input.
    Enter one URL per input field.

    1. To confirm the current input and to display a new input field, press ENTER.

    2. To remove an entry from this section, click the cross icon corresponding to the item you want to remove.

  13. Select the Sighting option to notify a specific occurrence of the indicator in your environment.


An observable test mechanism characteristic is a structured set of fields stored inside the indicator containing the observable.
Yara and Snort rules are among the available test mechanisms.

Besides the test mechanism type, it is possible to include the corresponding value; that is, the actual Yara or Snort rule.

An observable test mechanism value field accepts strings up to about 2000 characters in length. Longer input strings are truncated at around 2000 characters.
To view the original, non-truncated value, open the observable in the detail pane, and then click the Neighborhood tab to retrieve the the original entity or entities containing the test mechanism value – that is, the rule – in structured form.

Observable test mechanism details that you create and update by modifying the indicator containing the observable in the entity editor are stored as-is.

Add observables


If you manually create an entity in the entity editor, and add observables with a type or value that matches the criteria of an existing observable ignore rule, these observables may not be accessible after saving the entity.

Observables are discrete pieces of information that represent properties, attributes, actions, and events.
They record a distinct piece of information, such as: an IP address, a hash, name of a country, name of a city, name of an organization, or the name of an individual; or an event such as the creation of a registry value, or a file deletion or modification.

They are atomic: the information they hold is complete and meaningful, but it cannot be split into smaller components without losing meaning and intelligence value.
They are factual: they record facts with no additional context or background.

You can relate observables with entities to provide context.
If observables are detected in a specific context, or if they are sighted within the organization, they become indicators and sightings, respectively.

  1. In the Create indicator view, go to the Observables section, and click Observable.
    The Add observable pane opens.

  2. From the Type drop-down menu, select an observable type that describes the type of information you are storing in the observable.
    For example, a bank account number, a payment card number, an IP address, a domain name, a country or city name, and so on.

  3. From the Link name drop-down menu, select an option to define the type of relationship existing between the observable and the parent entity.

    Setting link names to define relationships adds intelligence value by describing how entities and observables are related.
    This information provides additional context, and it helps understand how a specific resource is used, or the purpose it serves for a potential attacker.
    For example, it can clarify that an observable describes a vulnerability or a weakness related to its parent entity.

    Therefore, observables with a Link name value are in general more relevant and more valuable than observables without a Link name value.

    Link name options vary, based on the relationship the observable has with the specific entity type it belongs to.
    The supported entity-observable relationship link names for the indicator entity are:

    • Observable: the observable related to the indicator.

    • Sighted: the observable related to the indicator was sighted, that is, at least one specific occurrence of the observable was detected inside the organization.

    • Test mechanism: the observable related to the indicator describes an element of a test mechanism.
      A test mechanism enables the Intelligence Center to share entity information with external tools and systems.
      In particular, it is useful to send information to an IDS/HIDS/NIDS to test it against a tool-specific rule.
      For example, a rule, or the IP address or domain name pointing to malicious infrastructure, or the name of a product.

    You can modify and update the link name value at any time to reflect changes in the entity-observable relationship:

    1. In the top navigation bar, click Intelligence > All intelligence, and then Browse.

    2. Click the Observables tab.

    3. If the section is populated with observables, each of them has a Link name column.

    4. Click the Link name drop-down menu for the observable whose relationship link name you want to update, and then select one of the available options.
      If the Link name drop-down menu has no options, the selected the entity-observable relationship is undefined.

  4. In the Value(s) field, enter the value of the observable.
    The value and its format should match the specified observable type (kind).
    If you specify multiple values, enter one value per line.
    If you enter multiple values on one line, use a comma (,) as a separator.
    Example: 75.23.125.231, ipwnu.biz, Kansas City, [email protected], Alvin Slocombe.

  5. From the Maliciousness drop-down menu, select a maliciousness confidence level to assess the likelihood the potential threat may or may not damage the organization.
    This option corresponds to the value that is set under Confidence in observable rules.

  6. To store your changes, click Save; to discard them, click Cancel.

When you flag an observable with a maliciousness confidence level, it cannot transition back to being safe or irrelevant. It can only transition to a higher maliciousness confidence level.

You can use the specified observable values to set up automation processes, so that the potential threat that the entity represents can trigger an action in a security system or another device in the toolchain.

For example, if the observable Type is Email, the Link name is Parameter, and the Value(s) are [email protected], [email protected], and [email protected], you can create a rule in the email server to block all incoming messages from the honestpaul-superdeals.com email domain.

Add relationships

  1. In the Relationships view, click Relationship.

  2. From the drop-down menu select the option corresponding to the relationship you want to create.
    The following options are available:

    Option
    Incoming/Outgoing
    Description

    Associated campaigns

    Outgoing relationship

    Relates the campaign to the selected campaign(s) on the Search an entity dialog.

    Attributions

    Outgoing relationship

    Relates the campaign to the selected threat-actor(s) on the Search an entity dialog.

    Related incidents

    Outgoing relationship

    Relates the campaign to the selected incident(s) on the Search an entity dialog.

    Related TTPs

    Outgoing relationship

    Relates the campaign to the selected TTP(s) on the Search an entity dialog.

    Indicator Related campaigns

    Incoming relationship

    Relates the selected indicator(s) on the Search an entity dialog to the campaign.

    Report Campaigns

    Incoming relationship

    Relates the selected report(s) on the Search an entity dialog to the campaign.

    Threat actor Associated campaigns

    Incoming relationship

    Relates the selected threat-actor(s) on the Search an entity dialog to the campaign.

    Sighting Campaign

    Incoming relationship

    Relates the selected sighting(s) on the Search an entity dialog to the campaign.

  3. In the Search an entity dialog, click the checkbox(es) to select one or more entities that you can relate to the current one.

    You can refine search results by specifying a search string in the filter input field.
    Alternatively, click images/download/attachments/3604538/filter.PNG to select one or more quick filter options such as:

    • Entity

    • Source

    • TLP

    • Date

    • Datasets

  4. Click Select.

Select this option…

… to create this relationship for the indicator

Indicated TTPs

Outgoing relationship
Relates the indicator to the selected TTPs(s) in the Search an entity dialog.

Suggested courses of action

Outgoing relationship
Relates the indicator to the selected course(s) of action in the Search an entity dialog.

Recommends carrying out a course of action to respond to the indicator.

Related indicators

Outgoing relationship
Relates the indicator to the selected indicator(s) in the Search an entity dialog.

Related campaigns

Outgoing relationship
Relates the indicator to the selected campaign(s) in the Search an entity dialog.

Incident Related indicators

Incoming relationship
Relates the selected incident(s) in the Search an entity dialog to the indicator.

Report Indicators

Incoming relationship
Relates the selected report(s) in the Search an entity dialog to the indicator.

Sighting Indicator

Incoming relationship
Relates the selected sighting(s) in the Search an entity dialog to the indicator.

From the Relationship type, you can select the name of entity relationship you added.
You can also type in your own relationship name in the empty input field.

When you assign a relationship a predefined or a custom name, it is visible in the graph view.

The arrow orientation, either or , indicates that the relationship is either incoming — from the related entity to the current one — or outgoing — from the current entity to the related one.

  • To remove a relationship type name, go to the relationship type you want to remove, and click  .
    The relationship type name is removed.

  • To remove a relationship, go to the row of the relationship you want to remove, and click .
    The row and the corresponding relationship are removed.


You cannot undo these actions. They are irreversible.

Add metadata information

  1. In the Estimated observed time field, enter the date when the entity was first observed/detected.
    It corresponds to the date and time when the threat was detected, recorded, and reported for the first time.
    Usually, Estimated observed time can be either the same as Estimated threat start time, or it can mark a point in time after Estimated threat start time. It can also be after the Estimated threat end time if the threat ended before it was observed.

  2. In the Estimated threat start time field, enter the estimated date the threat activity started, based on observation, reports and other intelligence.
    It corresponds to the date and time when the threat was detected, recorded, and reported for the first time as an active/in-progress event.
    The Estimated threat start time can be either the same as Estimated observed time, or it can mark a point in time before Estimated observed time.

  3. If the threat is no longer active, go to the Estimated threat end time field, and enter the estimated end time of the threat activity, based on observation, reports, and other intelligence.

  4. Go to the Half life section.

    Half-life represents the amount of time it takes for a threat to lose half its intelligence value.
    It corresponds to the number of days it takes for the malicious potential of a threat to decay by 50%.

  5. Select the Use default value option to assign the entity the predefined half-life value.
    You can assign default half-life values to each entity type in the /etc/eclecticiq/platform_settings.py file.
    Integer values represent the number of days.
    settings.py (sourced from EIQ platform-backend)

    Author

    Rutger Prins

    Commit

    17a58f9f930d83ee862b731813ff472ea3994a37

    Timestamp

    February, 14, 2022 11:59 AM

    Full path

    eiq/platform/settings.py

    Title

    [SNYK] Upgrade packages and ignore issues with no upgrade path

    Description

    **Upgrade packages:**<br> `ipython==7.16.0` => `ipython==7.16.3` == no risk <br> `cairosvg==2.4.2`=> `cairosvg==2.5.2` == no risk <br> `jinja2==2.10.1` => `jinja2==2.11.3` == no risk<br> `pillow==7.2.0` => `pillow==8.3.2` == no risk <br> `pygments==2.6.1` => `pygments==2.7.4` == no risk <br> <br> **Snyk Ignore:** <br> _Removed issues that no longer affect our product._<br> Increase ignore time for following issues:<br> snyk:lic:pip:html2text:GPL-3.0 - can't be applied for 2.9<br> SNYK-PYTHON-PIP-609855 - can't upgrade PIP due to incompatibility with credential escaping<br> SNYK-PYTHON-PIP-1278135 - can't upgrade PIP due to incompatibility with credential escaping<br> SNYK-PYTHON-DATEPARSER-1063229 - no fix available<br> SNYK-PYTHON-CELERY-2314953 - fix can't be apply due to incompatibility with python 3.6<br> SNYK-PYTHON-PILLOW-2329135 - fix can't be apply due to incompatibility with python 3.6<br> SNYK-PYTHON-PILLOW-2331905 - fix can't be apply due to incompatibility with python 3.6<br> SNYK-PYTHON-PILLOW-2331907 - fix can't be apply due to incompatibility with python 3.6<br> SNYK-PYTHON-PILLOW-2331901 - fix can't be apply due to incompatibility with python 3.6<br> SNYK-PYTHON-PILLOW-2397241 - fix can't be apply due to incompatibility with python 3.6<br> SNYK-PYTHON-CRYPTOGRAPHY-1070544 - can't apply fix risk accepted SNYK-PYTHON-PYSAML2-1063038 - can't apply fix risk accepted SNYK-PYTHON-PYSAML2-1063039 - can't apply fix risk accepted See merge request engineering/platform-backend!6465

    # Default values
    HALF_LIFE = {
    "campaign": 1000,
    "course-of-action": 182,
    "eclecticiq-sighting": 182,
    "exploit-target": 182,
    "incident": 182,
    "indicator": 30,
    "report": 182,
    "threat-actor": 1000,
    "ttp": 720,
  6. Select the Override value option to override the default half-life value for the entity, and to set a custom one.
    Enter an integer to represent the number of days it takes the entity to lose half its intelligence value.

  7. In the Tags section, click Add tags to associate one or more tags with the entity .
    Tags enable structuring and categorizing entities based on criteria such as confidence and attack stage.
    Tags improve findability, and they offer quick reference pointers to place entities in a broader cyber threat context.

  8. Click Source, and select the source of the threat information you are using to create the new entity.
    The options available are the names of existing assigned user groups in the Intelligence Center.

  9. Go to the Source reliability section.
    Use this option to flag the entity with a predefined reliability value to help other users assess how trustworthy the entity data source is.

  10. Select the Inherit from source option to assign the entity the same reliability value as the corresponding original data source.

  11. Select the Custom override option to override the default source reliability value for the entity, and to set a custom one.
    From the drop-down menu select, select an option to flag the entity data source reliability level.

  12. Values in this menu have the same meaning as the first character in the two-character Admiralty System code.
    Example: B - Usually reliable

Add information source details

  1. In the Description field, provide context and details to qualify the information source.
    For example, enter a job role, or the function of an institution.

  2. In the Identity field, enter the name of the information source.
    For example, an individual’s name or the official name of an entity such as an organization or government agency.

  3. From the Roles drop-down menu, select one or more options to define how the information source contributed to the information in the report.

  4. In the References field, enter a URL pointing to relevant reference information on the report, if available.
    The field takes only URLs as input. Enter one URL per field.

    • To confirm the current input and to display a new input field, press ENTER.

    • To remove an input field from this section, click the corresponding .

Define sharing and usage

  1. From the TLP drop-down menu, select the TLP color code you want to use to filter enrichment data.
    You can choose to override the TLP color by selecting Not set in the Override TLP drop-down menu.
    TLP provides an intuitive reference to assess how sensitive information is, focusing in particular on how serious it is, and whom it should or should not be shared with.

  2. In the Terms of use field, enter any legal notes about fair use of the information about the entity.

Define a workflow

  1. Select the Add to dataset checkbox to include the campaign to one or more existing datasets.
    From the drop-down menu select the target datasets you want to add the entity to.

  2. Select the Manually enrich checkbox to manually enrich the entity with the enricher sources you select from the Enrichers to apply drop-down menu.

Save and publish

To store your changes, click Save; to discard them, click Cancel.
To access additional save options, click the down arrow on the Save button:

  • Click Save draft to store your changes without publishing the entity.

  • Click Publish to release the new version of the entity that includes your changes.

  • Click Cancel to discard the changes.

Save a draft

Drafts are available in the entity editor under Draft entities.

Two additional options are available when saving an entity as a draft:

  • Click Save draft and new if you are creating a new entity and have not saved it before. This option saves the current populated form as a draft without publishing it to the Intelligence Center, and creates and opens a new draft form in the editor.

  • Click Save draft and duplicate to the current populated form as a draft without publishing it to the Intelligence Center, and create and opens a prepopulated copy of the draft entity in the editor to speed up the creation of a new entity of the same type.

Publish an entity

Published entities are saved to the Intelligence Center.
When the new entity is indexed, it is available in the Intelligence Center, in the entity editor under Published.
Published entities associated with a workspace or included in a dataset are available also through the corresponding workspace and dataset.

Two additional options are available when publishing an entity:

  • Click Publish and new if you are creating a new entity and you have not published it before. This option saves the current populated form, publishes it to the Intelligence Center, and creates and opens a new form in the editor.

  • Click Publish and duplicate to save the current populated form, publish it to the Intelligence Center, and create and open a prepopulated copy of the newly published entity in the editor to speed up the creation of a new entity of the same type.

See also