SYS.1.1 General Server is the building block of the German BSI IT-Grundschutz catalogue that applies to every server, whatever it runs.
An Artica appliance is a server, so an organisation that works to IT-Grundschutz — German federal and state authorities, and their suppliers — must be able to show that this building block is satisfied on it.This page is the reference for that conversation:
what SYS.1.1 asks for, what the appliance does about each point, what you have to switch on, and what it deliberately leaves to other tools.
IT-Grundschutz states its requirements in three tiers, and the distinction matters when you write a security concept:
| Tier | German wording | Meaning |
|---|---|---|
| Basic requirements | Basis-Anforderungen — MUSS / MUST | Not negotiable. These must be met, and an auditor will ask for evidence. |
| Standard requirements | Standard-Anforderungen — SOLLTE / SHOULD | Expected for normal protection needs. A deviation is allowed but must be justified and documented. |
| Elevated protection | Anforderungen bei erhöhtem Schutzbedarf | Suggestions for systems whose protection need is rated high or very high. |
Requirement numbers (
SYS.1.1.A1,A2, …) are renumbered between editions of the IT-Grundschutz-Kompendium.
This page therefore addresses the requirements by content, in the wording that appears in a typical security-concept questionnaire.
Map them to the article numbers of the edition your organisation works to.
Two clusters of SYS.1.1 concern the appliance directly, and they are the subject of this page:
An Artica proxy has two populations of accounts, and only one of them lives in your directory service.
Answering SYS.1.1 for the wrong one is the single most common mistake in an Artica security concept.
| Proxy end users | Appliance administrators | |
|---|---|---|
| Who | The people whose web traffic goes through the proxy. | The people who log into the Artica web console. |
| Authentication | Squid, using Negotiate/Kerberos against Active Directory. | The console — never Kerberos: local SQLite accounts, an LDAP simple bind against AD, OpenLDAP, RADIUS, SAML or a client certificate. |
| Where the accounts live | Active Directory. | The appliance's own admins.db, plus the built-in Manager superadmin, which exists on every appliance and is in no directory anywhere. |
| Who audits account changes | Your directory service, with its own auditing. | The appliance itself — nothing else can see them. |
Auditing Active Directory covers the proxy's users.
It does not show a single administrator login to the console, nor the creation of an Artica administrator, nor a change to the superadmin password.
Those come from the appliance, and the rest of this page is about how.
Read the Condition column before quoting any line of this table in a security concept.
| SYS.1.1 requirement | Status | Source of the record | Condition |
|---|---|---|---|
| MUST — System starts and reboots | Met | systemd-journald (persistent when /var/log/journal exists), wtmp, and the auditd session rules. |
None for journald and wtmp. The auditd rules require auditd to be enabled. |
| MUST — Successful and failed logins, operating system | Met | sshd and PAM write to authpriv, i.e. /var/log/auth.log. |
None. |
| MUST — Successful and failed logins, application software | Met | Two independent trails: /var/log/artica-webauth.log (plain file) and the syslog event kind=auth.console. |
The file trail is unconditional. The syslog event requires the audit trail to be armed — see below. |
| MUST — Failed authorisation checks | Met | Proxy ACL denials in access.log; denials on the appliance's own API as kind=authz.rest. |
Proxy denials unconditional; authz.rest requires the audit trail. |
| MUST — Blocked data flows / ACL violations | Met | Squid TCP_DENIED entries, and a kernel LOG rule at the head of the firewall reject chain with prefix ARTICA:REJECT:. |
None. The firewall rule is emitted whenever the Artica firewall is active. |
| MUST — Creation or modification of users, groups, permissions | Met | Directory service for proxy users. For the appliance: the admin.* events, plus the auditd identity and perm_mod rules for OS accounts. |
admin.* requires the audit trail; the OS rules require auditd. |
| MUST — Security-relevant error messages (hardware, capacity) | Met | SMART / mdadm / RAID-controller health as hardware.disk and hardware.raid; free-space breaches as capacity.disk. Both also raise an operator notification. |
The notification to the operator is unconditional. Only the syslog record requires the audit trail. |
| MUST — Warnings from security systems | Met | ClamAV writes to syslog by configuration (LogSyslog yes, daemon and updater); Suricata and CrowdSec produce their own event streams. |
Each component must be enabled. |
| SHOULD — Monitoring concept, continuous status and service monitoring, error detection | Supported | Per-service watchdog supervision, the Statistic Communicator, an SNMP agent, a Zabbix agent, and the REST API. | None. |
| SHOULD — Alerting of personnel, alerting on thresholds | Supported, configuration required | Notifications by e-mail and in the console; disk-health thresholds are editable per metric. | Escalation policy is deliberately yours to define. |
| SHOULD — Regular security testing against the hardening specification | Met | CIS Benchmark A read-only audit every day at 02:30, archived as a dated report. |
The feature must be enabled; it is off by default. |
| SHOULD — Identify existing vulnerabilities | Met | CVE Vulnerability Scanner Scan the Artica appliance itself for known CVEs with Trivy |
Use an external vulnerability-management solution. See What this appliance does not do below. |
| SHOULD — Automation of the checks | Met | Every check named here is scheduled, not manual, and every result is readable over the REST API. | None. |
The syslog audit trail is a Corporate feature.
It emits only whenTrackAdminsis enabled and the appliance holds a Corporate licence.
Both conditions, not either.
Enable it from Your system > Features > Track administrators.
Then confirm the appliance agrees with you.
Do not infer the state from the settings:
The module is armed once per settings cycle, so a licence that has just expired or a setting that has just changed is not yet reflected.
What still works without a Corporate licence.
Console logins keep their file trail in/var/log/artica-webauth.log;
The firewall reject log keeps working; and a failing disk or a full filesystem still raises its alert to the operator.
What you lose is the syslog stream — that is, the feed a central SIEM consumes.
Every event is one line in logfmt, written to syslog facility authpriv, priority notice, with the tag artica-audit.
On a standard Debian appliance that means /var/log/auth.log
The same file as the sshd records, so anything already collecting host authentication logs picks these up with no extra configuration.
Sep 3 13:59:46 proxy01 artica-audit: outcome=failure kind=auth.console actor="jdoe" src=10.12.4.51 detail="invalid credentials, mode=password"Sep 3 14:02:11 proxy01 artica-audit: outcome=success kind=admin.privileges.set actor="Manager" src=10.12.4.51 object="7" detail="privileges=AsSystemAdministrator"Sep 3 14:40:03 proxy01 artica-audit: outcome=failure kind=hardware.disk actor="-" object="sdb" detail="Disk sdb (SATA ST4000NM): reallocated sectors 42 >= 1"
The outcome comes first because that is the field an analyst filters on, and it makes a raw log readable without tooling.
Fields that come from outside — an account name, a URI — are sanitised, so a user who controls their own login name cannot forge a second audit line by putting a newline in it.
kind |
Emitted when | SYS.1.1 requirement |
|---|---|---|
auth.console |
A console login succeeds or fails — including the superadmin, the Active Directory, SAML and client-certificate paths. | Logins to the application software |
authz.rest |
An authorisation check on the appliance's own API is refused. Coalesced to one record per source address per 60 s. |
Failed authorisation checks |
admin.user.create · .update · .delete · .enqueue |
An administrator account is created, changed, removed or queued for creation. | Creation or modification of users |
admin.group.create · .update · .delete |
An administrator group is created, renamed, enabled/disabled or removed. | Changes to groups |
admin.membership.create · .delete |
An account is added to or removed from a group. The removal record names the account and the group, not just a row id. |
Changes to groups |
admin.privileges.set |
The privilege set of a group is rewritten. The granted privileges are recorded. |
Changes to permissions |
admin.password.set |
An administrator password is changed. The hash is never recorded. |
Modification of users |
admin.apikey.upsert |
An API key is created or replaced. The key itself is never recorded. |
Modification of permissions |
hardware.disk |
A disk crosses a health threshold — temperature, reallocated or pending sectors, NVMe wear, media errors, link errors. | Hardware faults |
hardware.raid |
A software or hardware RAID array is degraded, rebuilding, or has no redundancy at all. | Hardware faults |
capacity.disk |
A filesystem falls below the configured free-space threshold. The record names the mount point. |
Exceeded capacity limits |
Every
admin.*record names the administrator who made the change.
The console passes that identity to the daemon, and the daemon accepts it only over the local socket — a remote client cannot attribute its actions to somebody else.
A change made directly through the API without that identity is recorded with the actorapi, which is still a record: nothing mutates an account silently.
/etc/passwd, /etc/group, /etc/shadow), permission changes, login records, sudo usage, kernel module loading and more. Both ship disabled. On an appliance where SYS.1.1 has to be demonstrated, enable both — and record in the security concept that you did.
Nothing special is required.
The audit records land on authpriv.notice, so they are in the same stream as sshd:
whatever already forwards host authentication logs will carry them.
Two practical notes:
artica-audit to isolate the appliance's own trail, then use the dotted kind as your first-level facet — auth.*, admin.*, hardware.*. /var/log/journal exists — without it journald keeps the journal in memory only and the boot history is lost at every restart — and that wtmp is retained for the period your policy requires.A log an audited person can rewrite is not evidence. Check this on every appliance, once:
ls -l /var/log/artica-webauth.log# expected: -rw-r----- 1 www-data adm ...
This file is the unconditional record of console logins.
It must be 0640, owned by www-data (the account that writes it) with group adm (the account that reads it).
Appliances updated to a current release enforce this by themselves on every permissions pass.
If you need a non-root log collector to read it, add that collector to the adm group — never to www-data, which would give it the whole console tree.
One SHOULD requirement is not met, and no part of this page claims otherwise: identify any existing vulnerabilities.
The CIS Benchmark audits configuration against a hardening baseline.
It does not know the CVE exposure of the installed packages, and it is not a substitute for a vulnerability scan.
For the SYS.1.1 requirements on regular security testing of externally exposed and internal servers, use a dedicated vulnerability-management solution and include the appliance in its scope, exactly as you would any other server.
These endpoints are served on the local ArticaREST socket and are restricted to the local transport — the UNIX socket or loopback.
| Method & path | Purpose |
|---|---|
GET /securityaudit/status |
Is the audit trail armed on this appliance, and if not, which condition is missing. |
POST /securityaudit/event |
Submit an audit event. Used by the web console for the login paths it handles itself. Body: kind, actor, src, outcome, object, detail. Any outcome other than success is recorded as a failure. |
GET /system/hardware/health |
Current disk and RAID health: per-device attributes, verdict, and the worst verdict overall. |
GET /system/hardware/thresholds |
The health thresholds in force, with their factory values. |
GET /system/cisbenchmark/status |
State of the daily hardening audit; see the CIS Benchmark page for the rest of that API. |
GET /system/auditd/status |
State of kernel-level auditing; see the Auditd page. |
A useful sixth check, once the trail is armed: attempt a console login with a wrong password, then look for outcome=failure kind=auth.console in /var/log/auth.log.
That single test exercises the console, the daemon, the syslog facility and your collector in one go.