Security Response Plan Policy

1. Overview

A Security Response Plan (SRP) provides the impetus for security and business teams to integrate their efforts from the perspective of awareness and communication and coordinated response in times of crisis (security vulnerability identified or exploited). Specifically, an SRP defines a product description, contact information, escalation paths, expected service level agreements (SLA), severity and impact classification, and mitigation/remediation timelines. By requiring business units to incorporate an SRP as part of their business continuity operations and as new products or services are developed and prepared for release to consumers ensures that when an incident occurs, swift mitigation and remediation ensues.

2. Purpose

The purpose of this policy is to establish the requirement that all business units supported by the Infosec team develop and maintain a security response plan. This ensures that the security incident management team has all the necessary information to formulate a successful response should a specific security incident occur.

3. Scope

This policy applies any established and defined business unity or entity within the eCuras.

4. Policy

The development, implementation, and execution of a Security Response Plan (SRP) are the primary responsibility of the specific business unit for whom the SRP is being developed in cooperation with the Infosec Team. Business units are expected to properly facilitate the SRP for applicable to the service or products they are held accountable for. The business unit security coordinator or champion is further expected to work with the eCuras LLC in the development and maintenance of a Security Response Plan.

4.1  Service or Product Description

The product description in an SRP must clearly define the service or application to be deployed with additional attention to data flows, logical diagrams, architecture considered highly useful.

4.2 Contact Information

The SRP must include contact information for dedicated team members to be available during non-business hours should an incident occur and escalation is required. This may be a 24/7 requirement depending on the defined business value of the service or product, coupled with the impact on the customer. The SRP document must include all phone numbers and email addresses for the dedicated team member(s).

4.3 Triage

The SRP must define triage steps to be coordinated with the security incident management team cooperatively with the intended goal of swift security vulnerability mitigation. This step typically includes validating the reported vulnerability or compromise.

4.4 Identified Mitigations and Testing

The SRP must include a defined process for identifying and testing mitigations before deployment. These details should consist of both short-term mitigations as well as the remediation process.

4.5 Mitigation and Remediation Timelines

The SRP must include response levels to identify vulnerabilities that define the expected timelines for repair based on severity and impact on consumers, brands, and companies. These response guidelines should be carefully mapped to the level of severity determined for the reported vulnerability.

5. Policy Compliance

5.1         Compliance Measurement

Each business unit must demonstrate they have a written SRP in place and that it is under version control and is available via the web.  The policy should be reviewed annually.

5.2         Exceptions

Any exception to this policy must be approved by the Infosec Team in advance and have a written record.

5.3         Non-Compliance

Any business unit found to have violated (no SRP developed before service or product deployment) this policy may be subject to delays in service or product release until such a time as the SRP is developed and approved. Responsible parties may be subject to disciplinary action, including termination of employment, should a security incident occur in the absence of an SRP.

Revised: March 14th, 2018

Table of Content

  1. Acceptable Encryption Policy
  2. Acceptable Use Policy
  3. Clean Desc Policy
  4. Data Breach Response Policy
  5. Disaster Recovery Plan Policy
  6. Digital Signature Acceptance Policy
  7. Email Policy
  8. Ethics Policy
  9. Pandemic Response Planning Policy
  10. Password Construction Guidelines
  11. Password Protection Policy
  12. Security Response Plan Policy
  13. End User Encryption Key Protection Policy
  14. Acquisition Assessment Policy
  15. Bluetooth Baseline Requirements Policy
  16. Remote Access Policy
  17. Remote Access Tools Policy
  18. Router and Switch Security Policy
  19. Wireless Communication Policy
  20. Wireless Communication Standard
  21. Database Credentials Policy
  22. Technology Equipment Disposal Policy
  23. Information Logging Standard
  24. Lab Security Policy
  25. Server Security Policy 
  26. Software Installation Policy
  27. Workstation Security (For HIPAA) Policy
  28. Web Application Security Policy
  29.  Analog/ISDN Line Security Policy
  30. Anti-Virus Guidelines
  31. Server Audit Policy
  32. Automatically Forwarded Email Policy
  33. Communications Equipment Policy
  34. Dial In Access Policy
  35. Extranet Policy
  36. Internet DMZ Equipment Policy
  37. Internet Usage Policy
  38. Mobile Device Encryption Policy
  39. Personal Communication Devices and Voicemail Policy
  40. Removable Media Policy
  41. Risk Assessment Policy
  42. Server Malware Protection Policy
  43. Social Engineering Awareness Policy
  44. DMZ Lab Security Policy
  45. Email Retention Policy
  46. Employee Internet Use Monitoring and Filtering Policy
  47. Lab Anti Virus Policy
  48. Mobile Employee Endpoint Responsibility Policy
  49. Remote Access Mobile Computing Storage
  50. Virtual Private Network Policy