Overview
Cyber security incidents are inevitable in modern software applications. Having a well-defined incident response process is critical for minimizing damage, maintaining user trust, and ensuring regulatory compliance. This guide outlines incident response procedures aligned with Australian Government guidelines.Australian Government - Responding to Cyber Security Incidents
Official Australian Government guidelines for cyber security incident response
What Constitutes a Security Incident?
A cyber security incident is any event that compromises the confidentiality, integrity, or availability of information systems or data.Data Breach
Unauthorized access to or disclosure of sensitive data including user credentials, personal information, or proprietary data
System Compromise
Unauthorized access to systems, privilege escalation, or malware infection affecting application infrastructure
Service Disruption
Denial of service attacks, system outages, or performance degradation caused by malicious activity
Code Injection
Successful exploitation of vulnerabilities like SQL injection, XSS, or CSRF resulting in unauthorized code execution
Incident Response Lifecycle
The Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) recommends a structured approach to incident response.
1. Preparation
Before an Incident Occurs
Before an Incident Occurs
Establish Logging & MonitoringDefine Response Team & Roles
- Implement comprehensive event logging
- Configure log aggregation and analysis
- Set up alerting for suspicious activities
- Ensure logs include timestamps and sufficient detail
The Australian Signals Directorate recommends event logging as best practice for threat detection. Learn more
- Identify incident response team members
- Assign clear responsibilities
- Establish communication channels
- Document escalation procedures
- Document step-by-step response plans
- Define incident classification criteria
- Establish evidence collection procedures
- Prepare communication templates
- Maintain backup and recovery systems
- Keep security tools and patches up to date
- Document system architectures and dependencies
- Establish secure communication channels
2. Detection & Analysis
Identifying and Understanding Incidents
Identifying and Understanding Incidents
Detection Sources
- Automated security alerts
- Log analysis and anomaly detection
- User reports of suspicious behavior
- Security testing and vulnerability scans
- External notifications (security researchers, law enforcement)
- Verify the incident is genuine (not a false positive)
- Determine the scope and severity
- Identify affected systems and data
- Document initial findings with timestamps
- Assess immediate risk to operations and data
- Type and sensitivity of data involved
- Number of users or systems affected
- Potential for ongoing damage
- Regulatory or compliance implications
- Public visibility and reputation impact
3. Containment
Stopping the Damage
Stopping the Damage
Short-term Containment
- Isolate affected systems from the network
- Disable compromised user accounts
- Block malicious IP addresses or domains
- Apply temporary security controls
- Preserve evidence for investigation
- Apply security patches to vulnerable systems
- Implement additional monitoring on affected systems
- Review and strengthen access controls
- Prepare for system rebuilding if necessary
Balance containment actions with evidence preservation—some actions may destroy forensic data needed for investigation.
4. Eradication
Removing the Threat
Removing the Threat
Elimination Steps
- Remove malware or malicious code
- Close exploited vulnerabilities
- Delete unauthorized user accounts or access
- Reset compromised credentials
- Verify threat actor access has been removed
- Identify how the incident occurred
- Determine what vulnerabilities were exploited
- Review security controls that failed
- Document lessons learned
5. Recovery
Restoring Normal Operations
Restoring Normal Operations
System Restoration
- Rebuild or restore affected systems from clean backups
- Apply all security patches and updates
- Verify system integrity before reconnecting to network
- Restore data from verified clean backups
- Test functionality thoroughly
- Increase monitoring of recovered systems
- Watch for signs of persistent threats
- Verify security controls are functioning
- Monitor for similar attack patterns
- Notify affected users appropriately
- Provide guidance on protective actions
- Restore user confidence through transparency
6. Post-Incident Activities
Learning and Improvement
Learning and Improvement
Incident Review
- Conduct post-incident meeting with response team
- Document what worked well and what didn’t
- Analyze response time and effectiveness
- Calculate incident costs and impacts
- Revise incident response plans based on lessons learned
- Update security controls and configurations
- Improve detection capabilities
- Enhance training and awareness programs
- Complete formal incident report
- Report to regulatory bodies if required
- Share threat intelligence with relevant parties
- Update stakeholders on remediation status
Logging Best Practices
Effective logging is fundamental to incident detection and response. The Australian Cyber Security Centre provides comprehensive guidance on event logging.
What to Log
What to Log
Authentication Events
- Login attempts (successful and failed)
- Logout events
- Password changes
- Account creation, modification, deletion
- Privilege escalation
- Access to sensitive data or functions
- Input validation failures
- Exception and error conditions
- Security control failures
- Configuration changes
- Service starts and stops
- Network connections
- File access and modifications
- Resource exhaustion conditions
What NOT to Log
What NOT to Log
- Passwords or password hashes
- API keys or tokens
- Session identifiers
- Credit card numbers or financial data
- Personal health information
- Cryptographic keys
Logging sensitive data creates additional security risks and privacy compliance issues.
Log Management Requirements
Log Management Requirements
Essential Log Attributes
- Timestamps (synchronized across systems)
- User or system identity
- Event type and description
- Source IP address or system
- Outcome (success/failure)
- Sufficient detail for analysis
- Protect logs from unauthorized access
- Prevent log tampering or deletion
- Implement log retention policies
- Regularly review and analyze logs
- Ensure adequate storage capacity
Defensive Data Handling
Input Validation
Preventing Malicious Input
Preventing Malicious Input
Input validation is a critical security control where input is checked to be valid data. Best practices:
- Validate data on entry before processing or storage
- Use allow-lists (whitelisting) rather than deny-lists (blacklisting)
- Validate data type, length, format, and range
- Reject invalid data with appropriate user feedback
- Never trust client-side validation alone
- Front-end validation using secure form attributes
- Back-end validation using regular expressions
- Framework-specific validation mechanisms
- Database constraints and parameterized queries
Data Sanitization
Cleaning Potentially Malicious Data
Cleaning Potentially Malicious Data
Data sanitization is the process of replacing potentially malicious characters with non-processing codes so text renders safely without executing malicious code.Example:
- Malicious string:
"';DROP TABLE users" - Sanitized string:
';DROP TABLE users - Renders as:
';DROP TABLE users(harmless text)
- Make all strings web-safe before storing or processing
- Use established libraries (Python html, Jinja2, etc.)
- Apply context-appropriate encoding
- Sanitize data for logs and error messages
Exception Handling
Secure Error Management
Secure Error Management
Code Review Questions for Exception Handling
- What approach for error handling is being used?
- What details about errors are displayed to users?
- Are errors logged with sufficient detail for analysis?
- Are database errors logged appropriately?
- Does error handling prevent information disclosure?
- Use try-except blocks for error-prone operations
- Log detailed error information securely
- Display generic error messages to users
- Never expose stack traces, database errors, or system paths
- Include exception handling in all data validation routines
Testing for Security Incidents
Vulnerability Scanning
Regular automated scans to identify known vulnerabilities before they’re exploited
Penetration Testing
Simulated attacks to find and exploit vulnerabilities in controlled conditions
Security Testing Approaches
Comprehensive testing methodologies aligned with SDLC phases
Log Analysis
Regular review of logs to detect anomalous behavior and potential incidents
Security Testing Throughout SDLC
Security by Design Processes
Security by Design Processes
| Phase | Security Activities |
|---|---|
| Requirements | • Gather security/privacy requirements • Vulnerability assessment |
| Design | • Threat modeling • Security design review • Security test design |
| Development | • Code reviews • Static Application Security Testing (SAST) |
| Integration | • Risk assessment • Dynamic Application Security Testing (DAST) • Grey-box penetration testing |
| Testing & Debugging | • Code reviews • SAST & DAST • Penetration testing |
| Installation | • Penetration testing • Vulnerability assessment |
| Maintenance | • Log monitoring & reporting • Vulnerability assessment |
Incident Response Tools & Resources
ZAPROXY
Open-source penetration testing application for identifying vulnerabilities
OWASP Testing Guide
Comprehensive web security testing guide for developers
CyberChef
Data analysis and decoding toolkit for security analysis
Cyber Security Guidelines
Australian Government incident response guidelines
Reporting Requirements
When to Report Incidents
When to Report Incidents
Regulatory Reporting
- Data breaches affecting personal information
- Incidents impacting critical infrastructure
- Breaches of privacy principles
- Financial data compromises
- All confirmed security incidents
- Suspicious activities requiring investigation
- Vulnerability discoveries
- Security control failures
- Law enforcement (for criminal activity)
- Affected users and customers
- Regulatory authorities (as required)
- Business partners (if their systems are affected)
Incident Response Checklist
Quick Reference for Active Incidents
Quick Reference for Active Incidents
Immediate Actions
- Document incident discovery time and initial observations
- Alert incident response team
- Assess severity and potential impact
- Begin evidence preservation
- Contain the incident to prevent further damage
- Analyze logs for attack vectors and timeline
- Identify affected systems and data
- Determine root cause
- Document all findings
- Remove threat actor access
- Patch exploited vulnerabilities
- Reset compromised credentials
- Restore systems from clean backups
- Verify security controls are functioning
- Conduct post-incident review
- Update incident response procedures
- Complete required reporting
- Implement preventive measures
- Update monitoring and detection capabilities
Effective incident response requires preparation, practiced procedures, and continuous improvement. Regular testing of incident response plans ensures teams are ready when real incidents occur.
Connection to Normo Unsecure PWA
When analyzing the Normo Unsecure PWA, apply incident response thinking:- What logging is implemented? Is it sufficient for incident detection?
- How would you detect if vulnerabilities you’ve found were being exploited?
- What evidence would be available for incident investigation?
- How could the application be hardened to prevent or detect incidents?
- What monitoring should be in place in the production environment?