Administration

Administration keeps a MISP instance usable, recoverable and appropriate for its community. Start with account and organisation boundaries, then establish a routine for service health, background jobs, updates and backups. A successful page load is only one part of that routine.

Note

This chapter follows MISP 3.0.0, 3.0_wip commit 99ebee729, in light mode. This is a development branch; choose an approved release and tested deployment procedure for a production upgrade. Select a figure to enlarge it.

Plan administrative access

A site administrator manages the instance, its settings and all organisations. An organisation administrator manages users within their own organisation, subject to the role and account restrictions. Organisation administration does not grant server settings, workflow administration or access to another organisation’s user accounts.

Use separate accounts for daily analysis, instance administration and integrations. Record who owns each service account, what it may access and how its key is rotated. Review effective role flags as well as the role’s name: roles can be changed locally and names are not a permission contract.

An operating routine: inspect health, investigate the affected layer, make a controlled change and verify the result before recording it.

Manage users

Open Administration → Users. The 3.0 list exposes organisation, role, TOTP/PGP status and account status, with filtering and row actions. Use it to review inactive accounts, unexpected administrative roles and accounts that still need their authentication setup.

The MISP 3.0 user list, populated with synthetic local training accounts.

Add or change an account

Choose Add user, then set:

Email: the login identity and notification address.
Organisation: the user’s local organisation. Check it before assigning permissions.
Role: the required data access and feature permissions, not an administrator role by default.
Password and delivery: decide whether to set a temporary password and whether MISP should email credentials. Verify the mail configuration before relying on delivery.
Options: publication/contact notifications and disabled status, as appropriate.
PGP key / NIDS SID: the user’s mail-encryption key and IDS export rule-ID offset where used.

The MISP 3.0 Add user form. Account creation and emailing credentials are separate choices in the form.

Use the account’s edit and password-reset actions for changes; check whether the next login will require a password change. A password reset can send mail or change credentials, so it is an operational action rather than a way to inspect an account. Follow the instance’s password policy and deliver credentials through the agreed channel.

Prefer disabling a departing user’s account to deleting its identity and history. Disabled accounts cannot authenticate with their keys. Review/revoke their integration keys and transfer ongoing responsibilities deliberately. A user’s public reporting identity is not an invitation to reuse their personal key in a service.

The Contact users feature can send notices, registration messages or password resets. Review recipients, encryption and the selected action before submitting it. Event publication alerts and contact-reporter subscriptions are separate notification choices.

Publication alert filters

Use the per-user publish_alert_filter setting to narrow publication-alert mail by supported tag, creator-organisation or threat-level conditions. It accepts a JSON condition tree, including AND/OR/NOT; review the filter and notification subscription together. Filtering mail does not change the user’s event visibility or the event’s distribution. For example, this filter excludes alerts whose event or attribute tags match tlp:clear:

{
  "NOT": {
    "Tag.name": ["tlp:clear"]
  }
}

Check the active per-user filter in user settings, using the authorised self/organisation-admin scope, and test the intended matches before relying on notification delivery.

Authentication keys and MFA

Manage individual keys under Account → My Profile → Auth keys, or the authorised user’s profile. Use comments, expiry, source-IP restrictions and read-only keys where suitable. The raw key is shown once when generated. See Automation & API for request authentication, rotation and read-only POST searches.

In Server Settings & Maintenance → Users & access, review password, session, brute-force and OTP settings together. The TOTP column in the user list reports enrollment; it does not prove every authentication path uses the same policy.

The Users & access settings filtered to OTP controls. The training fixture does not mandate OTP.

For built-in TOTP/HOTP:

Check PHP dependency health, authenticator compatibility and server time synchronization.
Have users enroll from their own profile and verify a code. Do not collect or screenshot their enrollment secret, QR code or recovery material.
Establish identity verification and an administrator recovery procedure before enforcing OTP.
Set Security.otp_required only after the rollout is ready. Users without a token are then required to enroll, except accounts with an applicable Skip OTP Reqs role exemption.

A site/organisation administrator can remove a user’s token within the permitted scope, using the user profile’s TOTP action. This removes enrollment; it does not disable the instance-wide requirement. The user must enroll again if required. Keep service-account exemptions narrow. Built-in email OTP and TOTP can coexist during a transition; external identity-provider/LinOTP policies need their own configuration. See Using MISP.

Maintain organisation identities

Open Administration → Organisations. Local organisations can have accounts on this instance; remote organisations represent known peers/identities without granting local logins. Keep the UUID consistent for the same organisation across instances. Local numeric IDs are not portable, and a matching name alone does not establish identity.

The current organisation list, including local status, user counts and email-domain restrictions.

When adding an organisation, review its name, UUID, local flag, description, country/sector, contacts and any email-domain restrictions. Add logos through Server Settings & Maintenance → Files, following the accepted filename/type rules; do not give the web application broad filesystem write access to upload a logo.

Editing a name is different from merging identities. Merge organisations transfers users and data toward the selected target and can remove the source organisation. Confirm the source/target UUIDs, data ownership and sharing-group consequences, and take a recoverable backup before proceeding. The current delete actions reject organisations still holding users or events; deleting one is not an alternative to an ownership review.

Use Cerebrate or sharing-group blueprints where appropriate for community identity management. A directory entry does not itself authorize event access.

Design roles and resource limits

Open Administration → Roles. A role combines one base data-access level with individual feature flags and resource limits. The default role is marked in the list; review it whenever changing onboarding policy. Changes to a shared role affect every account assigned to it.

MISP 3.0 roles show base access, granted permissions, resource limits and the default role.

Base level	Data operations
Read Only	Browse data visible to the account.
Manage Own Events	Create and maintain the user’s own events without publishing them.
Manage Organisation Events	Maintain events owned by the user’s organisation, without publishing.
Manage and Publish Organisation Events	Also publish the organisation’s events.

Additional flags include site/organisation administration, API access, tagging/tag editing, sharing-group editing, sightings, object/galaxy/warninglist/decay-model editing and Analyst Data creation. Sync flags, ZeroMQ/Kafka publishing and server signing grant specialised capabilities; review them against the sharing and integration design rather than adding them to every analyst role.

The 3.0 AI tools permission is separate from ordinary event editing. It permits supported assisted-analysis actions on events the user may edit when the AI service is enabled. Granting it does not configure the service or approve sending data to a provider. See Modules.

The role editor separates data access, resource limits and feature permissions, including AI tools.

Set memory/time limits, search rate limits and maximum restSearch results for the workload. A result cap is not a substitute for client pagination; an integration should handle both limits and empty/error responses. Reassign users before deleting a role. Test a representative regular account after a permission change, including an operation that should be refused.

Use grouped settings and health checks

Open Administration → Server Settings & Maintenance. MISP 3.0 replaces the old tab strip with grouped navigation, searchable settings and separate health pages. The underlying names such as MISP.*, Security.* and Plugin.* remain useful for API/CLI configuration.

The MISP 3.0 settings overview groups configuration, operations and system-health checks. Findings shown here belong to the local training deployment.

Area	Start here
Configuration	Instance; Users & access; Sharing & data; Mail & encryption; Network & HTTP; Logging & audit; Integrations; AI.
Operations	Background jobs; Correlations; Files.
System health	Version & updates; PHP & filesystem; Database; Redis; Services; Security audit; Maintenance tools.
All settings	Search across settings when you know a setting name but not its new group.

Inspect the priority, current value, validation message and description before changing a setting. Advanced, CLI only, File only and redaction labels constrain where/how a value can be managed. A red finding can also describe a deliberately disabled optional service; read the condition rather than enabling every integration to clear a counter.

Keep production debugging off. Treat a downloaded settings report as potentially sensitive; review it before attaching it to a support issue. Configuration managed by a deployment tool, container environment or mounted file must be changed at that source so it survives recreation.

Defaults, mail and network configuration

Review default distributions for events, attributes, objects, event reports and Analyst Data. Defaults affect new data; they do not reclassify existing records. Unpublished does not mean private: use distribution and sharing groups for the intended audience.
Configure the external/base URL, HTTPS termination and trusted proxy handling together. Use the current deployment’s web-server configuration and certificate trust; do not copy an old Apache configuration or disable peer verification to make a connection work.
Configure notification sender/support addresses, signing and user encryption preferences. Subjects and routing metadata may remain visible even when the message body is encrypted. Review MISP.extended_alert_subject before including event details in mail subjects.
Coordinate reverse-proxy upload limits, PHP upload_max_filesize/post_max_size, execution time, memory and any attachment backend limits. Use the web PHP runtime’s configuration; changing CLI PHP alone does not change uploads.

Check the database and MISP 3.0 migrations

The Database health page separates schema/migration state, table space usage and engine configuration recommendations. A cache clear does not repair a missing migration, an interrupted value conversion or lost data.

The MISP 3.0 Database health page reports the migration ledger and schema version separately.

MISP 3.0 introduces a migration ledger and a shared attribute-value dictionary. Check both legacy numeric updates and migration status when upgrading. On a source installation:

sudo -u www-data /var/www/MISP/app/Console/cake Admin migrationStatus
sudo -u www-data /var/www/MISP/app/Console/cake Admin schemaDiagnostics

Admin migrationStatus --json produces a structured report. Admin migrationApply --dry-run prints planned migration SQL without applying it; on an up-to-date instance it reports that nothing is pending. These checks do not establish that a large upgrade will fit the available disk space or complete within the maintenance window.

Use the selected release’s upgrade procedure and the dependency chapter. The current Admin runUpgrade coordinates an offline upgrade: numeric updates, migrations and the attribute-value conversion where due, plus worker stop/restart requests. A failed run can leave the instance offline and partially converted; inspect its output and rerun the supported procedure rather than marking migrations applied by hand.

Before it runs, stop external writers and scheduled ingestion, take a consistent backup, check space and rehearse on a restored copy. Check that workers really stopped; the command can report a Supervisor failure. PostgreSQL upgrades also have engine-specific prerequisites, including pg_trgm for the relevant value migration. Use a persistent terminal/session for a long conversion. Restart the web PHP runtime after an upgrade, as directed by the command.

Values, correlations and retention

A MISP 3.0 value address is not an attribute occurrence. Values can be referenced by Analyst Data and collections; correlation suppression, detection eligibility and source visibility remain separate decisions. Do not manually truncate value tables to reduce correlation noise.

Control	What it changes
Correlation exclusions	Suppress matching values from correlation. Leading/trailing `%` support substring patterns. Use the cleaner to remove existing matches where appropriate.
Correlation rules	Exclude event sets from correlating, using creator/owner organisation, event ID or event-info selectors. Inspect the matching set before executing a cleanup.
Over-correlating values / Top correlations	Find high-volume matches. `MISP.correlation_limit` limits correlations for a value; increasing it may increase cost and noise.
Correlation engine	Select the supported engine for the database and audience. `NoAcl` is not a general replacement for the default ACL-aware engine; `OnDemand` is MySQL/MariaDB-only in this branch.
Value dictionary statistics	Maintain counts used by the values index. `Admin valueDictionaryStats` refreshes statistics; it is not a read-only report or a value-deletion command.

Correlation settings in the grouped MISP 3.0 operations pages.

Changing correlation does not mark a value benign, delete an observation or withdraw a previous downstream detection. Use the relevant data lifecycle and connector controls as well. Coordinate retention of logs, attachments, jobs and research data with backup and sharing needs; removing a reference does not necessarily remove its source occurrence.

Control incoming data

Use the control that matches the problem; these lists are not interchangeable:

Control	Scope
Event blocklist	Event UUIDs rejected on creation/import/sync when enabled. Blocking an existing event does not delete it. Deletion can add an event to this list when event blocklisting is enabled.
Organisation blocklist	Creator-organisation UUIDs rejected for event intake/sync. It is not an account-login ban.
Sighting blocklist	Organisations whose sightings should not be stored, when sighting blocklisting is enabled.
Galaxy-cluster / Analyst Data blocklists	Specific cluster or research-record UUIDs rejected on capture/sync. These lists have no separate enable switch.
Event block rules	A tag-based rule for event intake/synchronization. It does not prevent every later local tagging action.
Import Regexp	Type-scoped transformation/rejection of attribute values. A bad replacement can damage data or block imports.

The current event blocklist and entry points for adding UUIDs or editing event block rules.

Sighting blocklist

Use the reporting organisation’s UUID to exclude unwanted sighting sources. This does not block that organisation’s users from logging in or remove its event/attribute observations. Review local feedback and incoming synchronization separately when investigating a source.

Galaxy and research blocklists

Cluster and Analyst Data entries identify the particular record UUID to reject. They do not replace event/organisation blocklists or distribution controls. Check existing local data and peer behaviour before assuming that blocking an identifier also deletes every copy.

The event/org/sighting enable switches remain MISP.enableEventBlocklisting, MISP.enableOrgBlocklisting and MISP.enableSightingBlocklisting. For event block rules, the current tag-list form matches any listed tag; do not assume an arbitrary AND/NOT expression. Test the actual import and sync path with synthetic data before applying a broad rule.

For import regular expressions, preserve the source context, restrict the applicable types and test both matching and non-matching inputs. Blank replacements can reject matches. Review how normalization affects stored values, value addresses and correlations before rewriting them.

The historical Signature allowedlist page/controller is absent in this 3.0 checkout. Review detection flags, warninglist-aware export filters and the destination’s selection policy when replacing an old export setup. A correlation exclusion does not provide the same behaviour.

Monitor jobs and recurring work

MISP uses SimpleBackgroundJobs, Redis and Supervisor. CakeResque instructions do not apply. MISP.background_jobs enables background processing; the SimpleBackgroundJobs.* Redis and Supervisor settings must point at the actual services. Generic MISP Redis and job-queue Redis can use different databases/namespaces; a successful redis-cli ping is not enough to prove that both application paths work.

The MISP 3.0 Background jobs page, with actual Supervisor-managed workers in the isolated training instance.

Queue	Typical work
`default`	General background processing, including non-blocking workflows.
`email`	Notification and alert delivery.
`cache`	Feed/export and other cache work.
`prio`	Higher-priority work such as user-requested publication.
`update`	Database/data-model update jobs; do not start competing update workers.
`scheduler`	Discovers due recurring tasks and queues their work. It is not an ordinary indicator-processing queue.

Use Administration → Jobs for job history, status, messages and progress. Distinguish the SQL job ID from its background process UUID. A successful enqueue is not a completed job, and a completed process does not prove a remote peer accepted every requested change.

The Jobs list after a local read-only diagnostic ran through a real background worker.

Purging job-history rows does not cancel a running process or empty a Redis queue. Conversely, Worker flushQueue discards waiting work; it is not a routine recovery step. Redis persistence, job-history expiry and the operation’s retry behaviour determine what can be recovered after a restart. Do not assume that every stopped/interrupted job will resume without loss or duplication.

Inspect and restart workers

On a source installation, substitute the actual OS account and path:

sudo -u www-data /var/www/MISP/app/Console/cake Worker status
sudo -u www-data /var/www/MISP/app/Console/cake Worker showQueues
sudo -u www-data /var/www/MISP/app/Console/cake Worker showJobStatus JOB_ID_OR_PROCESS_UUID

In this 3.0 branch, Worker restart restarts all workers or a supplied Supervisor worker name/PID, and Worker restartDead starts workers that are not running. The older Admin restartWorkers/related commands now call the current worker tooling too; they are no longer the no-ops described by old documentation. Use --help from the deployed checkout.

With a matching Supervisor installation, supervisorctl status 'misp-workers:*' shows its process group. Use the deployment’s service controls in a container installation. Fix Redis, permissions or dependency errors before repeatedly restarting a worker. Inspect worker output and Supervisor logs as well as the MISP Jobs page.

Schedule recurring tasks

Open Administration → Scheduled Tasks. The 3.0 form supports an interval in seconds, minutes, hours or days, a next execution date/time, an enabled flag and a user context. This is an interval scheduler, not a general cron-expression editor. A blank next execution can make a task due immediately; configure it deliberately before enabling it.

A scheduled-task draft using the current interval controls. It has not been saved or enabled.

Supported families include server pull/push/cache, feed fetch/cache, ad-hoc workflows, TAXII push, periodic summaries and supported Admin actions. Admin tasks also include external-user validity checks and a separate block invalid users operation; reporting and disabling accounts have different consequences.

Verify the selected user’s permissions, scheduler health, next execution, last job result and retry/overlap behaviour. A definition-update task is different from a database upgrade. For a custom operational task, use a suitable external scheduler and the documented CLI/API rather than modifying the scheduler’s internal tables.

Use logs for diagnosis

The top Logs menu separates application, audit, access and search views. Read the layer that can answer the question:

Layer	Useful evidence
Application log	Login/authentication events and operational messages; search by action, account and time.
Audit log	Recorded model changes and their field differences, when `MISP.log_new_audit` is enabled. Scope depends on permissions and organisation.
Access log	Request timing, route, response code and optional detail when paranoid/API/per-user monitoring is enabled; site-admin access.
Runtime/service logs	PHP/web-server errors, worker output, Supervisor, database, Redis and container service failures.

The MISP 3.0 audit log, filtered to account changes in the synthetic fixture.

Configure collection under Server Settings & Maintenance → Logging & audit. Request-body and SQL logging can include sensitive data and add substantial storage overhead. Review redaction, access and retention before enabling verbose logging; do not assume every free-text field or failed credential is safe to export. Failed web/API authentication commonly uses login_fail / auth_fail actions. MISP.log_auth and MISP.log_client_ip control additional collection; trusted proxy handling affects the recorded source address.

For an incident, retain a time window, request/job identifier, route and sanitized error. MISP application logs are normally under app/tmp/logs/; worker/web-server/container log locations depend on deployment. Avoid posting settings reports, authenticated request bodies, API keys or raw SQL dumps to a public issue. Use the MISP issue tracker and support resources with a reproducible, sanitized report.

For Redis failures, compare the configured host, address family, port, authentication, database and namespace from the web and worker contexts. For missing database fields, compare code, submodule and migration state first. Clear caches only when the diagnosis calls for it. Purge expired sessions through the applicable maintenance tool for the configured session backend; do not remove active sessions or run unrelated SQL cleanup as a first response.

Back up and rehearse recovery

A MISP backup must preserve the data and the secrets/configuration needed to interpret and access it. Document recovery time and acceptable data loss, then keep a coherent set of:

The database, using the database engine’s supported consistent-backup procedure.
Attachment storage, including an external/S3 backend where configured.
Configuration and secrets: database connection details, salt/encryption keys, instance mail keys and any signing keys/certificates needed by the deployment.
Uploaded logos/files, custom modules/workflows and other local customizations.
Tested application/image, submodule and dependency versions, plus deployment/service configuration.
Required operational Redis state and its recovery procedure. Do not blindly replay restored queues or treat regenerable caches as authoritative source data.

Restore a consistent backup into an isolated environment, verify data and services, then deliberately reconnect integrations.

The repository includes historical backup/restore helpers. Inspect their assumptions before use: they target a conventional MySQL/MariaDB installation and do not establish complete coverage for containers, PostgreSQL, external attachments or a 3.0 migration rollback. Follow the backup mechanism supported by your actual deployment.

Test restoration on an isolated host with outbound mail, synchronization, scheduled tasks, workflows and connectors controlled. Verify login/keys, organisations/distribution, events, attachments, value references, Analyst Data, collections and migration state. A completed tar archive is not a restoration test. Restore code/configuration and data from compatible points; reverting a Git checkout alone does not undo a schema or attribute-value conversion.

CLI reference and operating checks

Run the CLI as the application’s OS user, with the intended configuration and environment. Paths in this book assume /var/www/MISP; containers have their own execution/service wrapper. Start with the deployed command’s help:

sudo -u www-data /var/www/MISP/app/Console/cake Admin --help
sudo -u www-data /var/www/MISP/app/Console/cake Worker --help
sudo -u www-data /var/www/MISP/app/Console/cake User --help

Task	Command family / constraint
Read/change a setting	`Admin getSetting SETTING`; `Admin setSetting SETTING VALUE`. A full settings dump may include sensitive information.
Maintenance state	`Admin live` reads it; `Admin live 0` / `1` change it. Coordinate writers and service access separately.
Database health / migration plan	`Admin schemaDiagnostics`, `Admin migrationStatus`, `Admin migrationApply --dry-run`.
Apply a planned 3.0 upgrade	`Admin runUpgrade`, after backup/rehearsal and quiescing writers. Lower-level migration commands are not a generic substitute.
Redis health	`Admin redisReady`; check the job backend separately with `Worker status`.
Definitions	`Admin updateJSON` or the relevant `updateGalaxies`, `updateTaxonomies`, `updateWarningLists`, `updateNoticeLists`, `updateObjectTemplates`. These modify local definitions.
Accounts	`User` help covers password/key changes and block/unblock operations. Prefer scoped advanced keys; protect console output/history.
Sync/feed processing	`Server` help covers peer pull/push/cache and feed listing/fetch/cache. IDs, user context and direction must match the intended operation.
Enrichment	`Event enrichment` uses the configured modules and account context; it may contact providers or change events.
Security/configuration checks	`Admin securityAudit`, `Admin configLint`; TLS probes and reports have their own network/data scope.
Cache/storage maintenance	`Admin cleanCaches`, `optimiseTables` and value-maintenance commands have different effects. Diagnose first, then schedule the required work.
Secret-key rotation	`Admin reencrypt` is a controlled key migration, not a routine update. Retain a compatible backup and follow the command’s current help.

For automation, use bounded API queries and checkpoints rather than assuming every console command can safely be retried. See Automation & API, Workflows & Blueprints and Updating Python Dependencies.