<< Click to Display Table of Contents >> Navigation:  Bizagi Cloud Platform > Security > Monitoring and operations > Security incident response

Core Computer Security Incident Response Team (CSIRT)

The CSIRT is the focal point for dealing with computer security incidents at Bizagi. The specific responsibilities of the CSIRT are the following:

•Monitor systems for security breaches.

•Serve as a central communication point, both to receive reports of security incidents and to disseminate vital information to appropriate entities about the incident.

•Document and catalog security incidents.

•Promote security awareness within the company to help prevent incidents from occurring in your organization.

•Support system and network auditing through processes such as vulnerability assessment and penetration testing.

•Learn about new vulnerabilities and attack strategies employed by attackers.

•Research new software patches.

•Analyze and develop new technologies for minimizing security vulnerabilities and risks.

•Provide security consulting services.

•Continually hone and update current systems and procedures.

 

CSIRT Roles

 

 

Incident Response Plan

In the event of an incident, the CSIRT coordinates a response and will communicate with the associate members that will be involved in that particular incident. The following table shows the responsibilities of each role during the incident response process.

 

 

Key Points for Incident Response Activities

Initial Assessment

As part of your initial assessment we:

•Take steps to determine whether we are dealing with an actual incident or a false positive.

•Gain a general idea of the type and severity of attack. We must gather at least enough information to begin communicating it for further research and to begin containing the damage and minimizing the risk.

•Record the actions thoroughly. These records will later be used for documenting the incident (whether actual or false).

 

Incident Communication

When someone, either inside or outside the CSIRT suspects that there is a security incident, that person must quickly communicate it to the CSIRT via the Help Desk, email, or whatever means he considers best. The Team Lead, will assemble the team, and identify who needs to be contacted outside of the core CSIRT to make sure that appropriate control and incident coordination will be maintained, while minimizing the extent of the damage.

Only those playing a role in the incident response are informed until the incident is properly controlled. The Team Leader will later determine who needs to be informed of the incident.

 

Damage Contention and Risk Management

The CSIRT has to act quickly to reduce the actual and potential effects of an attack. The exact response depends on the nature of the attack. However, the following priorities are used as a starting point:

•Protect human life and people's safety. They are always our first priority.

•Protect classified and sensitive data. Determine which data is classified and which is sensitive to prioritize responses in protecting the data.

•Protect other data, including managerial data. Act to protect the most valuable data first before moving on to other, less useful, data.

•Protect hardware and software against attack. This includes protecting against loss or alteration of system files and physical damage to hardware.

•Minimize disruption of computing resources (including processes). Although uptime is very important in most environments, keeping systems up during an attack might result in greater problems later on. For this reason, minimizing disruption of computing resources can generally be a relatively low priority.

The minimum measures taken to contain damage are the following:

•Try to avoid letting attackers know that we are aware of their activities.

•Compare the cost of taking the compromised and related systems offline against the risk of continuing operations.

•Determine the access point(s) used by the attacker and implement measures to prevent future access.

 

Severity of the Compromise Identification

To be able to recover effectively from an attack, it is important to determine how seriously the systems have been compromised. This will determine how to further contain and minimize the risk, how to recover, how quickly and to whom you communicate the incident, and whether to seek legal counsel. The following aspects are considered when determining the extent of the incident:

•Determine the nature of the attack (this might be different than the initial assessment suggests).

•Determine the attack point of origin.

•Determine the intent of the attack. Was the attack specifically directed at your organization to acquire specific information, or was it random?

•Identify the systems that have been compromised.

•Identify the files that have been accessed and determine the sensitivity of those files.

To determine the severity of the compromise the team has to take into account the following:

•Have meetings to exchange information about team member’s findings, verify results, determine whether there might be related or other potential attack activity, and help identify whether the incident is a false positive.

•Determine whether unauthorized hardware has been attached to the network or whether there are any signs of unauthorized access through the compromise of physical security controls.

•Examine key groups (domain administrators, administrators, service accounts, and any other elevated privilege accounts) for unauthorized entries.

•Search for security assessment or exploitation software con compromised computers.

•Look for unauthorized processes or applications currently running or set to run using the startup folders or registry entries.

•Search for gaps in, or the absence of, system logs.

•Review intrusion detection system logs for signs of intrusion, which systems might have been affected, methods of attack, time and length of attack, and the overall extent of potential damage.

•Examine other log files for unusual connections; security audit failures; unusual security audit successes; failed logon attempts; attempts to log on to default accounts; activity during nonworking hours; file, directory, and share permission changes; and elevated or changed user permissions.

•Compare systems to previously conducted file/system integrity checks to identify additions, deletions, modifications, and permission and control modifications to the file system and registry.

•Search for sensitive data that might have been moved or hidden for future retrieval or modifications.

•Check systems for non-business data, illegal copies of software, and email or other records that might assist in an investigation. If there is a possibility of violating privacy or other laws by searching on a system for investigative purposes, the team must incorporate the Legal Advisor before proceeding.

The CSIRT uses tools such as EventCombMT and DumpEL in Windows Systems to help determine how much a system has been attacked.

 

Evidence Protection

In many cases, if the environment has been deliberately attacked, we or our customers will need to take legal action against the perpetrators. To preserve this option, the CSIRT is responsible for gathering evidence that can be used against them, even if a decision is ultimately made not to pursue such action. To do so, we have to back up the compromised systems as soon as possible. These back-ups are made prior to performing any actions that could affect data integrity on the original media. Two complete bit-for-bit backups of the entire system using new, never-before-used media are taken (whenever possible). One backup is made on a write-once, read-many media, so it can later be used for prosecution of the offender. This backup is physically secured until needed. The other backup is used for data recovery. Backup activities are documented as part of the incident response process activities.

For extremely large systems, comprehensive backups of all compromised systems might not be feasible. Instead, we back up all logs and selected, breached portions of the system.

 

External Agencies Notification

After the incident has been contained and data preserved for potential prosecution, the team may consider whether there is a need to start notifying appropriate external entities. All external disclosures are coordinated with the Legal Advisor. Potential agencies include local and national law enforcement, external security agencies, and virus experts.

For some types of breaches, we might also have to notify customers and the general public, particularly if customers might be affected directly by the incident. These types of disclosures have to be coordinated with Management as well.

 

Systems Recovery

System recovery will depend on the extent of the security breach. IT needs to determine whether it will be possible to restore the existing system while leaving intact as much as possible, or if it is necessary to completely rebuild the system.

Data restoration (whenever possible) is done using verified backups made before incident occurrence.

 

Incident Evidence Compilation and Organization

The CSIRT documents all processes when dealing with any incident. This includes a description of the breach and details of each action taken (who took the action, when they took it, and the reasoning behind it). All people involved with access are noted throughout the response process.

Afterward, the documentation is chronologically organized, checked for completeness, and signed and reviewed with management and legal representatives. Evidence collected in the protect evidence phase is safeguarded in our off-site backup facilities. The team has always two people present during all phases who can sign off on each step to reduce the likelihood of evidence being inadmissible and the possibility of evidence being modified afterward.

 

Incident Damage and Cost Assessment

Incident damage and costs are important evidence needed if we or our customers decide to pursue any legal action. The CSIRT decides whether to carry on with damage and cost assessment, in which case, Management is involved, and takes ownership of the activity. Damage assessment may include some or all of the following:

•Costs due to the loss of competitive edge from the release of proprietary or sensitive information.

•Legal costs.

•Labor costs to analyze the breaches, reinstall software, and recover data.

•Costs relating to system downtime (for example, lost employee productivity, lost sales, replacement of hardware, software, and other property).

•Costs relating to repairing and possibly updating damaged or ineffective physical security measures (locks, walls, cages, and so on).

•Other consequential damages such as loss of reputation or customer trust.

 

Response Review and Policy Updates

Once the documentation and recovery phases are complete, the team may need to review the process thoroughly to determine which steps were executed successfully and which mistakes were made. In case any findings appear, the Team Leader will be responsible for analyzing and suggesting process improvement.

Last Updated 8/2/2023 10:55:30 AM