This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
wiki:policies:incident [2023/08/25 17:47] katcow [ii) Incident Reporting] |
wiki:policies:incident [2023/11/02 17:02] kevinkallmes [i) Identification] |
||
---|---|---|---|
Line 28: | Line 28: | ||
=== System Utilization and Malware Detection === | === System Utilization and Malware Detection === | ||
- | At present, | + | Nested Knowledge does not maintain an internal corporate network, but does provide company-issued computers. |
+ | |||
+ | Nested Knowledge will obtain baselines for processor, memory and hard drive utilization. These parameters may change due to virus, worms, malware etc. | ||
* CPU | * CPU | ||
Line 39: | Line 41: | ||
Obtaining baselines metrics is crucial for determining system health. | Obtaining baselines metrics is crucial for determining system health. | ||
- | ==== Risk Register ==== | + | ===== Risk Register |
Nested Knowledge Incidence Response Team will maintain a list of security threats and vulnerabilities, | Nested Knowledge Incidence Response Team will maintain a list of security threats and vulnerabilities, | ||
Line 49: | Line 51: | ||
|Servers|Compromised access, through brute force or leaks| \\ Network Isolation, key-based authentication|Possible|Minor|Low| | |Servers|Compromised access, through brute force or leaks| \\ Network Isolation, key-based authentication|Possible|Minor|Low| | ||
- | ==== ii) Incident Reporting ==== | + | ===== ii) Incident Reporting |
- | === Detection and Reporting === | + | ==== Detection and Reporting |
When an incident is detected, Nested Knowledge personnel should behave as if they reporting a crime and include lots of specific details about what they have discovered. | When an incident is detected, Nested Knowledge personnel should behave as if they reporting a crime and include lots of specific details about what they have discovered. | ||
Line 59: | Line 61: | ||
In addition to submitting details via the form, Nested Knowledge personnel must email karl.holub@nested-knowledge.com or send a message to # | In addition to submitting details via the form, Nested Knowledge personnel must email karl.holub@nested-knowledge.com or send a message to # | ||
- | === Reporting | + | ==== Reporting |
- | You can report scams, phishing attempts, and other cyber incidents | + | For breachs likely |
- | * The FBI' | + | * categories of data and the number of data subjects affected |
- | * The [[https:// | + | * our DPO' |
- | | + | * likely consquences of the breach |
- | | + | * measures proposed and taken to address the breach |
+ | |||
+ | ==== Reporting Scams to Authorities ==== | ||
+ | |||
+ | You can report scams, phishing attempts, and other cyber incidents to: | ||
+ | |||
+ | * The FBI's [[https:// | ||
+ | * The [[https:// | ||
+ | * Forward emails to reportphishing@apwg.org. | ||
+ | * Forward texts to SPAM (7726) | ||
=== Internal Issues === | === Internal Issues === | ||
Line 73: | Line 84: | ||
Issues where the malicious actor is an internal employee, contractor, vendor, or partner requires sensitive handling. Please contact the CEO and CTO directly. These are critical issues and must be pushed to follow up. | Issues where the malicious actor is an internal employee, contractor, vendor, or partner requires sensitive handling. Please contact the CEO and CTO directly. These are critical issues and must be pushed to follow up. | ||
- | ==== iii) Incident Categorization ==== | + | ===== iii) Incident Categorization |
We categorize incidents by severity and scope of control. | We categorize incidents by severity and scope of control. | ||
- | === Severity === | + | ==== Severity |
- | == Low-Medium Severity == | + | === Low-Medium Severity |
Issues meeting this severity are simply suspicions or odd behaviors. They are not verified and require further investigation. There is no clear indicator that systems have tangible risk and do not require emergency response. This includes suspicious emails, outages, strange activity on a laptop. | Issues meeting this severity are simply suspicions or odd behaviors. They are not verified and require further investigation. There is no clear indicator that systems have tangible risk and do not require emergency response. This includes suspicious emails, outages, strange activity on a laptop. | ||
- | == High Severity == | + | === High Severity |
High severity issues relate to problems where an active exploitation hasn’t been proven, but is likely to happen. This include vulnerabilities with direct risk of exploitation, | High severity issues relate to problems where an active exploitation hasn’t been proven, but is likely to happen. This include vulnerabilities with direct risk of exploitation, | ||
Line 89: | Line 100: | ||
High severity issues should include an email to karl.holub@nested-knowledge.com with “Urgent” in the subject line, or a message to #info-sec with “@channel” in the message to alert incident responders. | High severity issues should include an email to karl.holub@nested-knowledge.com with “Urgent” in the subject line, or a message to #info-sec with “@channel” in the message to alert incident responders. | ||
- | == Critical Severity == | + | === Critical Severity |
Critical issues relate to actively exploited risks and involve a malicious actor. Critical severity issues should involve a message to “@channel” in #info-sec. Continue escalation until you receive acknowledgement. Involvement of a crisis lead and a lawyer are highly recommended. | Critical issues relate to actively exploited risks and involve a malicious actor. Critical severity issues should involve a message to “@channel” in #info-sec. Continue escalation until you receive acknowledgement. Involvement of a crisis lead and a lawyer are highly recommended. | ||
- | === Scope of Control === | + | ==== Scope of Control |
Incidents may be triggered by events that are inside or outside our scope of control. | Incidents may be triggered by events that are inside or outside our scope of control. | ||
- | == External Risk Events == | + | === External Risk Events |
* Supplier incident - service compromise, breach or unavailability | * Supplier incident - service compromise, breach or unavailability | ||
Line 103: | Line 114: | ||
* Security research - critical vulnerability published | * Security research - critical vulnerability published | ||
- | == Internal Risk Events == | + | === Internal Risk Events |
* Abusive content - harmful, child, sexual or violent speech or content, harassment | * Abusive content - harmful, child, sexual or violent speech or content, harassment | ||
Line 115: | Line 126: | ||
* Governance failure - process or audit failure | * Governance failure - process or audit failure | ||
- | ==== iv) Coordinating a Response ==== | + | ===== iv) Coordinating a Response |
We primarily use Slack to coordinate our response to cyber security events. We also use Google Meets call for response update calls. If an issue is classified as Critical Severity we will create a channel in Slack specifically for that issue and include the relevant individuals and assign roles at that time. Phone numbers, email and other details on individuals and our key suppliers can be found in Key Contacts. | We primarily use Slack to coordinate our response to cyber security events. We also use Google Meets call for response update calls. If an issue is classified as Critical Severity we will create a channel in Slack specifically for that issue and include the relevant individuals and assign roles at that time. Phone numbers, email and other details on individuals and our key suppliers can be found in Key Contacts. | ||
- | ==== v) Incidence Response ==== | + | ===== v) Incidence Response |
For critical issues, the incidence response team will follow an iterative response process designed to investigate, | For critical issues, the incidence response team will follow an iterative response process designed to investigate, | ||
Line 140: | Line 151: | ||
The Technical Lead and Investigators are responsible for capturing and collating data that support the investigation of a security incident.Data and logs should be sourced from Data Sources relevant to the investigation | The Technical Lead and Investigators are responsible for capturing and collating data that support the investigation of a security incident.Data and logs should be sourced from Data Sources relevant to the investigation | ||
- | == Potential Data Sources == | + | === Potential Data Sources |
* Account activity - domain controller and active directory logs | * Account activity - domain controller and active directory logs | ||
Line 164: | Line 175: | ||
* Laptops and Mobiles which are lost or compromised, | * Laptops and Mobiles which are lost or compromised, | ||
- | ==== Key Contacts ==== | + | ===== Key Contacts |
^Name^Function^Contact| | ^Name^Function^Contact| | ||
Line 174: | Line 185: | ||
===== Security Incidents ===== | ===== Security Incidents ===== | ||
+ | |||
+ | [Example] | ||
^Timestamp^Event^Description^Reported By^Status| | ^Timestamp^Event^Description^Reported By^Status| | ||
- | |01-17-2023 10:34 ET|Phishing email |Fraudulent email requesting payroll: moved to SPAM, blocked sender, and deleted. | Kathryn Cowie | + | |01-17-2023 10:34 ET|Phishing email|Fraudulent email requesting payroll: moved to SPAM, blocked sender, and deleted.|Kathryn Cowie |Resolved 01-17-2023 10:37 ET| |
===== Revision History ===== | ===== Revision History ===== |