Nested Knowledge

Bringing Systematic Review to Life

User Tools

Site Tools


Incident Management and Response


This Incident Response Plan exists to ensure that we consistently handle information security events in an effective and efficient manner.


This policy offers guidance for employees, contractors, and consultants of Nested Knowledge who believe they have discovered or are responding to a security incident.

Affected Systems

This policy applies to all computer and communication systems owned or operated by Nested Knowledge and it’s subsidiaries. Systems include company shared drives, purchased software, as well as access to the Nested Knowledge AutoLit review platform. Reviews developed in the AutoLit software by parties external to Nested Knowledge are not covered in this policy.

Incidence Response Plan

The incident response (IR) team will consist of the following personnel:

  • Karl Holub, technical lead
  • Kevin Kallmes, CEO; investigator
  • Kathryn Cowie, operations lead; investigator
  • Other incident responders may be assigned as needed.

i) Identification

The incident response team must maintain a list of all all installed applications and services running on Nested Knowledge systems. The list of applications can be viewed in our Business Continuity and Disaster Recovery Policy. This will help detect unauthorized programs The IR team can classify these applications according to purpose and importance.

System Utilization and Malware Detection

At present, Nested Knowledge does not maintain an internal corporate network or provide company-issued computers. Should we set up a network or issue computers, Nested Knowledge will obtain baselines for processor, memory and hard drive utilization. These parameters may change due to virus, worms, malware etc.

  • CPU
  • Memory
  • Disk
  • Network
  • Tasks
  • Events

Obtaining baselines metrics is crucial for determining system health.

Risk Register

Nested Knowledge Incidence Response Team will maintain a list of security threats and vulnerabilities, classified by likelihood and consequence.

AssetThreat/VulnerabilityExisting ControlsLikelihoodConsequenceLevel of Risk
Malicious files/ processes

Unprotected data
Security policy dissemination and trainingHighly PossibleMajorVery High
NK ApplicationInjection, privilege escalation, leaks, untrustworthy dependenciesRuntime environment restrictions, mandated code review, dependency locking, developer education, penetration testingPossibleMajorHigh
Compromised access, through brute force or leaks

Network Isolation, key-based authentication, regular off-site backups
ServersCompromised access, through brute force or leaks
Network Isolation, key-based authentication

ii) Incident 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.

Nested Knowledge has prepared an incident response form for use while investigating an incident. Nested Knowledge Employees and contractors will be provided with access to the form and instructed to utilize it for all suspected incidents. The IR team will monitor responses and react immediately upon receipt.

In addition to submitting details via the form, Nested Knowledge personnel must email or send a message to #incident-response to notify the security team of suspected issues.

Reporting to Authorities

You can report scams, phishing attempts, and other cyber incidents to:

Internal Issues

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

We categorize incidents by severity and scope of control.


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.

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, threats with risk or adversarial persistence on our systems (eg: backdoors, malware), malicious access of business data (eg: passwords, vulnerability data, payments information), or threats that put any individual at risk of physical harm.

High severity issues should include an email to with “Urgent” in the subject line, or a message to #info-sec with “@channel” in the message to alert incident responders.

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.

Scope of Control

Incidents may be triggered by events that are inside or outside our scope of control.

External Risk Events
  • Supplier incident - service compromise, breach or unavailability
  • Regulatory change - unforeseen rules change
  • Security research - critical vulnerability published
Internal Risk Events
  • Abusive content - harmful, child, sexual or violent speech or content, harassment
  • Malware - ransomware, worm, spyware, rootkits, etc
  • Availability interruption - denial of service or sabotage
  • Information gathering - reconnaissance activities, network scanning or sniffing
  • Social engineering - phishing, bribes and other (physical) threats
  • Information breach - unauthorised access to, or sharing, modification or deletion of system/information
  • Fraud - theft of money or misappropriation of company resources
  • System intrusion - software exploit, SQL injection, XSS, use of stolen credentials
  • Governance failure - process or audit failure

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.

v) Incidence Response

For critical issues, the incidence response team will follow an iterative response process designed to investigate, contain exploitation, remediate our vulnerability, and document a post-mortem with the lessons of an incident.

  1. Observe/Orient
    1. - The technical lead and investigators will collect relevant data. Contextual information, such as asset information, company plans, and external/open-source intelligence may be used to help understand the landscape.
  2. Decide
    1. The operations lead will record decisions and justifications for the selected course of action.
    2. The technical lead and CEO will determine if a lawyer should be included and attorney client privilege between responders will begin.
  3. Act
    1. The technical lead, with support from other personnel, acts on the decisions made in the previous stage to further the investigation or remedy of the situation.
    2. A meeting will occur at regular intervals until the incident is resolved.
  4. Review
    1. Post-incident reviews are conducted without blame or finger-pointing to encourage open and honest participation so that lessons can be learned and improvements identified. Failing to create the right open, safe environment may cause participants to withhold information crucial to preventing events from occurring again.
  5. Recover
    1. Business as usual will be restored as soon as feasible. For more details on recovery, please see the Business Continuity Policy

Data Sources

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
  • Account activity - domain controller and active directory logs
  • IT Assets
  • Software configuration (authorized software packages)
  • Web logs and potentially similar host logs to above
  • Information storage (document management systems and databases)
  • Financial systems
  • Cloud service-specific logs
  • Local system activity

Mitigation Process due to Information Loss

Data lost or stolen must be taken into account, complying with state and federal laws mentioned in Part 1.

  • PII loss will be notified to the concerned persons as well as government authorities.
  • Incident will be analyzed, and action will be taken if evidence of transgressions by an employee is found. Legal team must assess the repercussions due to the loss, and will provide an official statement to the management regarding potential compensation losses to be incurred.

Specific Plans for loss of Availability of Services:

  • Databases protected with credentials. Primary and secondary servers are allocated for databases, to make sure services available even if a server is down. Databases are backed up by our cloud services provider on a transaction level and periodically exported to a different provider.
  • Servers are protected and backed-up by our cloud services provider, who provide coverage and consistent working, even during blackouts, shutdowns etc.
  • Laptops and Mobiles which are lost or compromised, cannot access our network without multi-factor authentication.

Key Contacts

Kevin Kallmes CEO - critical decisions, public relations
Karl Holub CTO - technical lead
Kathryn Cowie COO - coordination, documenting response an decisions
John FalloneLawyer - legal assistance
Dr. DheerendraBoard Member

Security Incidents

TimestampEventDescriptionReported ByStatus
01-17-2023 10:34 ETPhishing email Fraudulent email requesting payroll: moved to SPAM, blocked sender, and deleted. Kathryn Cowie Resolved 01-17-2023 10:37 ET

Revision History

AuthorDate of Revision/ReviewComments
K. Cowie11/15/2021Initial draft in progress; risk register needs technical review.
K. Kallmes11/19/2021Draft approved
K. Holub09/30/2022Reviewed with grammar edits
P. Olaniran9/29/2022Minor revisions

Return to Policies

wiki/policies/incident.txt · Last modified: 2023/08/25 17:47 by katcow