AAAI-10

Describe or provide a reference to the (a) system capability to log security/authorization changes, as well as user and administrator security events (i.e., physical or electronic), such as login failures, access denied, changes accepted; and (b) all requirements necessary to implement logging and monitoring on the system. Include (c) information about SIEM/log collector usage.*

Explanation

This question is asking about your system's logging capabilities for security-related events and how you monitor these logs. It has three main parts: (a) How your system logs security events: The assessor wants to know if your system records important security activities like failed login attempts, access denials, and configuration changes. These logs are crucial for detecting security incidents, investigating breaches, and demonstrating compliance. (b) Requirements to implement logging: This refers to what's needed to set up proper logging in your system - including configurations, storage requirements, retention policies, and any other technical prerequisites. (c) SIEM/log collector usage: A Security Information and Event Management (SIEM) system or log collector centralizes logs from various sources for analysis. The assessor wants to know if you use such tools to aggregate and analyze your security logs. This question is asked because proper logging is fundamental to security. Without good logs, organizations can't detect breaches, investigate incidents, or prove compliance. The assessor wants to ensure you have visibility into security events happening in your system. To answer well, provide specific details about your logging capabilities (what events are logged and how), explain your implementation requirements clearly, and describe any log aggregation or analysis tools you use. If you have documentation about your logging setup, reference it in your answer.

Guidance

Ensure that all elements of AAAI-10 are clearly stated in your response.

Example Responses

Example Response 1

(a) Our system logs comprehensive security events including all authentication attempts (successful and failed), authorization changes, user privilege modifications, and administrative actions Each log entry includes timestamp, user ID, IP address, action performed, and success/failure status For example, when an administrator changes a user's permissions, we log who made the change, what permissions were modified, when it occurred, and from which location. (b) Implementation requirements include: - Minimum 1TB storage dedicated to security logs - Log retention of 12 months for all security events - NTP synchronization across all system components to ensure accurate timestamps - Logging enabled at application, database, and infrastructure levels - Proper file permissions to prevent unauthorized log access or modification (c) We use Splunk Enterprise as our SIEM solution to collect and analyze logs from all system components Logs are forwarded in real-time to Splunk using authenticated TLS connections We've implemented custom dashboards and alerts for security events, with critical alerts (such as multiple failed admin login attempts) triggering immediate notifications to our security team via email and SMS Our SIEM retains logs for 12 months online and 7 years in cold storage for compliance purposes.

Example Response 2

(a) Our system logs security events through a multi-layered approach: - Authentication layer: Records all login attempts (successful/failed), password changes, MFA events - Authorization layer: Logs access requests, permission changes, role assignments - Administrative layer: Captures all configuration changes, user management actions, and security policy modifications All logs contain standardized fields including event ID, timestamp, user identity, source IP, action type, affected resource, and outcome. (b) Implementation requirements: - Logging must be enabled at OS, application, and database levels - Minimum 500GB dedicated storage with auto-scaling capabilities - Log rotation configured with 90-day online retention and 1-year archived retention - Write-once storage for log immutability - Encrypted log transmission and storage - Regular log backup to separate secure storage (c) We utilize Microsoft Sentinel as our SIEM solution, which collects logs from all system components via Azure Log Analytics agents The SIEM applies machine learning algorithms to detect anomalies and potential security incidents We've implemented custom playbooks for automated responses to common security events Our SOC team monitors the SIEM dashboards 24/7 and receives real-time alerts for critical security events Monthly log reviews are conducted to identify trends and potential security improvements.

Example Response 3

(a) Our system currently has basic logging capabilities that capture successful logins and major system changes However, we don't consistently log failed authentication attempts, access denials, or detailed information about security configuration changes The logs we do generate contain timestamps and user IDs, but lack contextual information like IP addresses or specific actions taken. (b) To implement comprehensive logging, we would need to: - Upgrade our application to enable more detailed security event logging - Increase storage capacity as our current allocation is insufficient for extended log retention - Develop standardized logging formats across system components - Implement proper log rotation and archiving procedures (c) We currently don't use a SIEM or centralized log collector Logs are stored locally on each server and must be manually reviewed when investigating issues We recognize this as a security gap and are evaluating solutions like ELK Stack or Graylog to implement within the next quarter Our current approach makes it difficult to correlate events across systems or detect patterns that might indicate security incidents We're working to address these limitations in our next development cycle.

Context

Tab
Product
Category
Authentication, Authorization, and Account Management

ResponseHub is the product I wish I had when I was a CTO

Previously I was co-founder and CTO of Progression, a VC backed HR-tech startup used by some of the biggest names in tech.

As our sales grew, security questionnaires quickly became one of my biggest pain-points. They were confusing, hard to delegate and arrived like London busses - 3 at a time!

I'm building ResponseHub so that other teams don't have to go through this. Leave the security questionnaires to us so you can get back to closing deals, shipping product and building your team.

Signature
Neil Cameron
Founder, ResponseHub
Neil Cameron