Incident Response Policy

1. Introduction
This document outlines the Incident Response Policy for the DeskCamera application. DeskCamera is an on-premises screen streaming application designed to work within the customer’s local network. It does not offer cloud services, does not store or process user data, and does not transmit any live content back to DeskCamera servers.

2. Purpose
To ensure DeskCamera has a structured approach to identifying, managing, and resolving security incidents that may affect its software development, distribution, or support infrastructure.

3. Scope
Covers security incidents related to the DeskCamera codebase, build pipeline, third-party dependencies, distribution systems, and internal development tools.

4. Incident Types Covered
• Unauthorized access to code repositories
• Compromise of signing certificates or build environment
• Supply chain vulnerabilities in 3rd party libraries
• Misconfigurations affecting the integrity of distributed installers
• Vulnerabilities in tools used during the SDLC (Software Development Lifecycle)

5. Roles and Responsibilities
• CTO – Oversees incident handling and approves critical actions
• Development Team – Assesses technical details, patches code, and restores systems
• Security Lead – Coordinates investigations, maintains logs, and ensures communication

6. Incident Handling Process
6.1. Identification
• Automated monitoring of CVEs (Common Vulnerabilities and Exposures) via security feeds
• Manual code reviews and anomaly detection during routine operations

6.2. Assessment
• Triage based on severity (Critical, High, Medium, Low)
• Check whether any distributed software was affected

6.3. Containment & Mitigation
• Immediate revocation of compromised credentials
• Isolate affected environments or pipelines
• Remove or patch affected third-party libraries

6.4. Recovery
• Restore clean environment from backups
• Re-sign builds using clean and verified keys
• Retest and revalidate the integrity of released installers

7. Communication
• Internal: All incidents are logged and shared with management
• External: Clients are informed within 24 hours only if the integrity of distributed builds or update mechanisms is compromised

8. Post-Incident Review
• Root cause analysis within 5 working days
• Update security procedures if needed
• Incident report stored internally and used in annual security training

9. Review and Testing
• This policy is reviewed annually by the CTO
• Internal tabletop tests of incident response are conducted periodically