¶ Intrusion Detection and Response Policy
This policy establishes the framework for detecting and responding to malicious or unauthorized activity within the Axion project's systems and infrastructure. The primary goal is to ensure the confidentiality, integrity, and availability of the application, its data, and the underlying services by enabling timely detection of and reaction to security incidents.
This policy applies to all systems, services, and infrastructure associated with the Axion project, including but not limited to:
- All servers and virtual machines (development, testing, and production).
- All databases,
- All application services (
Serve*.py) and core modules (factory.*).
- All external API integrations, including Slack, Google Gemini, and Infobip.
- The source code repository (Bitbucket) and local developer environments.
- All configuration files, especially
config.yaml and other files containing credentials.
- All critical systems must have logging enabled and configured to capture relevant security events.
- Logs shall be collected and stored in a centralized and secure manner to prevent tampering.
- Automated monitoring and alerting shall be implemented to detect suspicious patterns in real-time.
- A formal Incident Response Plan (detailed below) must be followed in the event of a detected intrusion.
- All personnel are responsible for reporting any suspected security incidents immediately.
¶ 4. Detection Sources and Monitoring
The following sources will be actively monitored for signs of intrusion:
-
Application Logs: The standard output from all Obj*.py modules, captured via the MQTT logging service. Alerts will be configured for high rates of errors, authentication failures, or unusual activity patterns.
-
Database Activity:
- Monitoring of database logs for excessive failed login attempts.
- Alerting on unusual or unauthorized queries, especially those involving
DROP, TRUNCATE, or attempts to access sensitive tables outside of normal application behavior.
-
Web Server Logs: The logs from ServeConversation.py, ServeReport.py, and other web-facing services will be monitored for:
- Spikes in HTTP error codes (4xx, 5xx).
- Evidence of scanning, SQL injection, or directory traversal attempts in the request URLs.
- Unauthorized access attempts to webhook endpoints.
-
API Credential Usage:
- Monitoring the usage of API keys for external services (Slack, Google Gemini, etc.). Any sudden spike in usage could indicate a compromised key.
- The
config.yaml file is a primary target. Any changes to this file outside of a standard deployment workflow should trigger an immediate alert.
-
File Integrity Monitoring (FIM) with Tripwire:
- For critical production deployments, Tripwire will be used as a host-based intrusion detection system (HIDS).
- What Tripwire Does: Tripwire works by creating a baseline "snapshot" of the filesystem, including critical system files, application binaries, and configuration files. It cryptographically hashes these files to create a unique signature for each one. It then periodically re-scans the filesystem and compares the new state to the baseline.
- An alert is triggered if any of the following changes are detected:
- Files being added or deleted.
- File contents being modified (which changes the hash).
- File permissions or ownership changing.
- This provides a powerful mechanism for detecting unauthorized modifications that could indicate a rootkit, malware, or a direct compromise of the server.
-
Source Code Repository:
- Monitoring for force pushes to the
develop or main branches.
- Alerts for any direct commits to protected branches that bypass the standard pull request and code review process.
¶ 5. Roles and Responsibilities
- All Personnel: Have the responsibility to immediately report any suspected security event to the designated security lead.
- Development Team: Are responsible for ensuring that all new services and modules implement secure logging practices as defined by the project's standards.
- Security Lead / Team: Are responsible for the configuration and maintenance of monitoring tools, reviewing alerts, and leading the Incident Response Plan.
- Management: Are responsible for providing the necessary resources to support this policy.
In the event of a detected intrusion, the following phased approach will be initiated:
- Immediately assess the alert to determine if it represents a genuine security incident.
- Categorize the severity of the incident (Low, Medium, High, Critical) based on its potential impact.
- Isolate the affected system to prevent the incident from spreading. This may involve:
- Temporarily disabling the affected service.
- Blocking a suspicious IP address at the firewall.
- Revoking compromised API keys or user credentials.
- Identify the root cause of the intrusion (e.g., a software vulnerability, a weak password).
- Remove the malicious code, user, or vulnerability from the system.
- Restore the affected system to a known-good state from backups.
- Verify that the system is clean and functioning normally.
- Re-enable the service and monitor closely.
- Within one week of the incident's resolution, conduct a post-mortem review.
- Document what happened, the timeline of events, the impact, and the actions taken.
- Identify lessons learned and create an action plan to improve security and prevent a recurrence.
Failure to comply with this policy may result in disciplinary action, up to and including termination of employment or contract.
This policy will be reviewed and updated on an annual basis, or more frequently in response to significant changes in the project's architecture or the threat landscape.