Full function catalogue / 25 areas
The complete network and server security audit.
The AI Defence specification begins with a comprehensive read-only security audit of the authorised environment. The catalogue below lists every defined check, control and workflow item from the 7 September 2026 first-entry specification, followed by the rules for reporting, remediation, verification and continuous protection.
Scope is comprehensive; coverage must be evidenced
This is the intended product scope, not a claim that every check is already implemented or available on every operating system. The available collectors, permissions, environment and agreed assessment methods determine which checks can actually run. Unavailable, inaccessible and inconclusive checks must be visible in the client report.
Read-only means the assessment does not change configuration or remediate findings. Network discovery and security checks still need agreed targets and assessment limits. Intrusive validation, credential rotation, isolation and hardening belong behind separate customer authorisation.
Environment discovery and inventory
Establish what exists, its role and its dependencies before assigning risk to individual findings.
- Operating systems, versions and patch levels
- Physical hosts, VMs, containers and orchestration
- Servers, workstations and exposed infrastructure
- CPU/RAM/storage/environment characteristics
- Installed packages/software/services
- Running processes and daemons
- System roles and dependencies
- Network interfaces and routes
- DNS configuration
- Internal/external IP addressing
- Cloud infrastructure where detectable
- Containers/images/registries
- Databases, caches, queues, storage systems
- Web servers/reverse proxies/load balancers
- Source-control/deployment infrastructure
Network topology and exposure
Map authorised reachability and boundary configuration. Record the difference between observed access and intended access.
- Network/subnet discovery
- Reachable hosts
- Open/listening ports
- Externally exposed ports/services
- Unexpected services
- Firewall configuration
- Routing
- NAT
- VPNs
- Segmentation
- VLAN/security-zone boundaries
- East-west network exposure
- Internet-facing endpoints
- Management interfaces
- DNS exposure
- IPv4 and IPv6 exposure
- UPnP or accidental port exposure
- Shadow services/devices
Host security posture
Review host posture in the context of the workload. Platform-dependent checks require an appropriate collector and permission.
- OS security configuration
- Patch status
- Missing security updates
- Unsupported/EOL software
- Kernel security
- Secure boot where applicable
- File permissions
- Privileged binaries
- SUID/SGID exposure
- Writable system paths
- Scheduled tasks/cron
- Startup services
- Unnecessary services
- Remote management configuration
- Logging/auditing configuration
- Host firewall
- Antivirus/EDR presence and status
- Time synchronisation
- Backup configuration
Identity, authentication and privilege
Connect accounts and identities to their effective authority, including human, service and machine access.
- User/account inventory
- Service accounts
- Privileged/admin accounts
- Dormant accounts
- Default accounts
- Shared accounts
- Password-policy weaknesses
- MFA coverage
- SSH configuration
- SSH keys
- Stale/unknown authorised keys
- Root login
- sudo configuration
- Excessive permissions
- Privilege escalation paths
- Group membership
- Application/database credentials
- Machine identities
- API/service identities
Secrets and credentials
Locate credential exposure while keeping collected evidence bounded and sensitive values appropriately masked.
- Plaintext secrets
- Secrets in environment variables
- .env files
- Configuration files
- Repositories
- Git history
- CI/CD variables
- Container configuration/images
- Backup files
- Logs
- Hard-coded API keys/tokens/passwords
- Private keys/certificates
- Expired certificates
- Weak key material
- Credential reuse/excessive scope
- Secret rotation requirements
Vulnerability assessment
Identify affected components and correlate advisory evidence with the actual deployed state. Uncertain matches remain uncertain.
- OS CVEs
- Package/library CVEs
- Application dependency vulnerabilities
- Container/image vulnerabilities
- Web-server vulnerabilities
- Database vulnerabilities
- Network-service vulnerabilities
- Known exploited vulnerabilities
- Misconfiguration-derived vulnerabilities
- Default credentials/configuration
- Deprecated protocols/ciphers
- Unsupported software
- Vulnerability severity and exploitability
- Exposure/context-based risk rather than CVSS alone
Attack-surface assessment
Review internal and external entry points and the control systems that can affect production.
- External attack surface
- Internal attack surface
- Public services
- Administration panels
- APIs
- SSH/RDP/remote-access exposure
- Database exposure
- Development/debug endpoints
- Monitoring dashboards
- Container APIs
- Orchestration/control interfaces
- CI/CD systems
- Repository systems
- Backup systems
- Cloud consoles/endpoints
- Unauthenticated services
Web/application/API security
Assess configuration and available application evidence within agreed methods. Intrusive validation requires separate authorisation.
- TLS configuration
- Certificates
- HTTP security headers
- Authentication controls
- Session handling
- Access control
- CORS
- CSRF protection
- Injection exposure
- SSRF exposure
- Directory/file exposure
- Debug endpoints
- Error information leakage
- API authentication
- API rate limiting
- Unsafe HTTP methods
- Dependency vulnerabilities
- Secrets embedded client-side
Database/data security
Begin with read-only diagnostics. Database and data changes require a governed, authorised workflow.
- Public/database-network exposure
- Authentication
- Encryption in transit
- Encryption at rest
- Database privileges
- Superuser usage
- Default accounts
- Weak configuration
- Row/tenant isolation where relevant
- Backup security
- Replication security
- Sensitive-data exposure
- Data retention
- Audit logging
Cloud/container security
Inspect workload privilege and the surrounding cloud or orchestration boundaries where the environment and connectors support it.
- Container privilege levels
- Root containers
- Host mounts
- Docker socket exposure
- Dangerous Linux capabilities
- Network isolation
- Image provenance
- Image vulnerabilities
- Stale images
- Secrets in images
- Registry security
- Kubernetes/RBAC where relevant
- Cloud IAM
- Security groups/firewall rules
- Public buckets/storage
- Metadata-service exposure
- Excessively privileged workloads
Repository and software-supply-chain security
Follow trust from source and dependencies through build infrastructure, artifacts and deployment authority.
- Git repository exposure
- Branch/release controls
- Dependencies
- Lockfiles
- Package provenance
- Vulnerable dependencies
- Malicious packages
- Secrets in repository/history
- CI/CD workflows
- Build runners
- Artifact integrity
- Deployment credentials
- Third-party integration privileges
Email/DNS/domain security where applicable
Review domain, DNS and email controls where they are in scope and observable. Missing access must remain a coverage gap.
- DNS configuration
- SPF
- DKIM
- DMARC
- DNSSEC
- CAA
- Certificate configuration
- Subdomain exposure
- Dangling DNS
- Potential subdomain takeover
- Mail-service exposure
Malware/persistence/compromise indicators
Treat suspicious observations as evidence to investigate and correlate, rather than automatic proof of compromise.
- Suspicious processes
- Unexpected services
- Persistence mechanisms
- Unknown scheduled tasks
- Suspicious startup entries
- Unexpected network connections
- Strange listening ports
- Unexpected privileged users
- Modified security configuration
- Suspicious binaries/scripts
- Unusual authentication activity
- Known indicators of compromise
Logging, monitoring and detection readiness
Establish whether usable, retained and trustworthy telemetry exists for ongoing detection. Missing evidence is a blind spot.
- Available security logs
- Authentication logs
- System logs
- Web/application logs
- Firewall/network logs
- Audit logs
- Log retention
- Log integrity
- Alerting
- Centralisation
- Detection blind spots
- Whether enough telemetry exists for Remedy's continuous monitoring
Backups/recovery/resilience
Assess recovery evidence as well as backup configuration. A backup file alone does not prove a successful restore.
- Backup existence
- Backup frequency
- Backup integrity
- Off-host/off-site copies
- Encryption
- Access controls
- Immutable backups where possible
- Restore testing
- Single points of failure
- Disaster-recovery weaknesses
Security architecture/trust boundaries
Explain which systems and identities trust one another, and where a weakness could cross a boundary.
- What trusts what
- Service-to-service communication
- Privilege boundaries
- Internet-to-internal paths
- Management plane separation
- Production/development separation
- Tenant boundaries
- Database boundaries
- CI/CD trust
- Third-party trust
- Potential lateral-movement paths
Configuration and hardening assessment
Compare the discovered state with appropriate hardening principles. Recommendations should preserve required operations.
- insecure defaults
- unnecessary exposure
- excessive privilege
- weak authentication
- weak cryptography
- poor segmentation
- missing firewall rules
- unnecessary services
- unsafe remote access
- weak logging
- unsafe permissions
- insecure service configurations
Risk correlation
Correlate severity with context rather than dumping scanner results. Internet exposure, a vulnerable service, known exploit evidence and elevated privilege can raise urgency; isolation and compensating controls can change the risk.
- severity
- exploitability
- exposure
- business importance
- privilege
- lateral-movement potential
- available exploit evidence
- compensating controls
Initial client security report
Produce a plain-English executive explanation supported by technical evidence. Explain the recommended order of work and its likely impact.
- What was examined
- What was found
- What is secure
- What is insecure
- Critical/high/medium/low findings
- Evidence
- Why each finding matters
- What an attacker could potentially gain
- Recommended remediation
- Likely impact of remediation
- Whether downtime may be required
- Remedy's recommended order of work
Authorisation boundary
The initial assessment is observational by default. Present the findings and recommendations; the client decides what may change.
- everything recommended
- selected remediation
- individual findings
- or no changes
Controlled remediation after authorisation
These are specified potential actions, only after explicit authorisation and only where implemented and supported. They are not an unrestricted grant of access.
- close unnecessary ports
- modify firewall rules
- disable unsafe services
- correct file permissions
- patch vulnerable software
- remove insecure defaults
- strengthen SSH configuration
- revoke obsolete credentials/keys
- rotate credentials where supported
- strengthen TLS
- secure databases
- harden containers
- restrict network exposure
- improve logging
- deploy detection controls
- isolate dangerous systems
- remediate exposed secrets
- apply approved security configuration
Safety before remediation
Before every material change, establish safe conditions and a recovery plan. Reassess if the approved assumptions no longer hold.
- establish current state
- determine dependencies
- determine blast radius
- prepare rollback
- preserve connectivity
- avoid locking out administrators
- avoid breaking production workloads
- record the authorised action
Post-remediation verification
Every correction needs relevant retesting. Keep attempted fixes distinct from VERIFIED fixed outcomes, and retain failed or inconclusive results.
- vulnerability
- exposure
- service health
- network accessibility
- application health
- security configuration
Baseline creation
Record the accepted environment state after the assessment and authorised work, including known approved exceptions.
- known hosts
- expected services
- expected ports
- expected users
- expected packages
- expected network paths
- expected workloads
- expected configuration
- known approved exceptions
Continuous protection after initialisation
Use the accepted baseline and available telemetry to detect subsequent change and emerging risk. Ongoing detection does not remove the authorisation boundary for response.
- new vulnerabilities
- newly exposed services
- new devices
- new ports
- configuration drift
- privilege changes
- account changes
- new SSH keys
- suspicious processes
- unexpected outbound connections
- certificate expiry
- software becoming vulnerable
- malicious indicators
- anomalous behaviour
- weakened firewall/security configuration
- exposed secrets
- repository/dependency risks
- attack attempts
Start with understanding
What does your environment need to defend?
Discuss the assessment scope, current capabilities and the control you need with Altari Systems.