# DSM: Minority Report


### **Introduction**

In addition to incident response, we can also anticipate dangerous situations by implementing **deviant behavior monitoring** for Council.

## TODO

- мониторить депозиты не от депозитора

### **What is Deviant Behavior?**

In the context of Council, deviant behavior refers to:

- **Significant deviation from the majority of other Councils**
- **Significant deviation from a trusted Council (e.g., the "golden" Council)**
- **Episodic absence of messages**
- **Errors in messages**

Deviant behavior can indicate:

- **Software bugs**
- **Environment errors**
- **Attempts to harm the system by a single Council**
- **Attempts to harm the system by a group of Council**
- **Duplicating messages**: The Council may compromise the private key, and an attacker who seizes it can spin up another instance, overriding messages from the original Council

### **Current Limitations**

Currently, we lack:

- **Dedicated responsibility for monitoring**
- **A system to perform such monitoring**

We currently monitor message delivery and trigger alerts if no messages are received for a certain period. However, we do not check data quality. We simply try to gather a quorum (4 messages). Therefore, no alert will be triggered if 1 or 2 Councils send incorrect data.

Additionally, we cannot reliably obtain logs from all Councils. Instead, we must request them to be sent in the chat if needed.

In other words, the current mechanism relies solely on trust in the Councils.

### **Proposed Solution**

To address these limitations, we propose implementing a separate service: **DSM-monitoring**.

This service will monitor the data, availability, and versions sent by the Councils.

Based on this monitoring, we can implement:

- **Alerts** to notify us of anomalies
- **Dashboards** to visualize data discrepancies

This will allow us to:

- **Prevent attacks**
- **Detect our own errors** (e.g., those introduced during software updates)
- **Simplify the debugging of Council instances**
- **Provide an alternative to log analysis**

### **Automation**

We can automate some tasks. For example, if specific metrics are detected, we can automatically exclude the problematic Council from the Data Bus until the cause of the problem is identified.

## **Next Steps**

- Develop a detailed design for the DSM-monitoring service
- Implement the service
- Integrate the service with existing monitoring and alerting systems
- Define automation rules for excluding problematic Councils

## **Conclusion**

DSM-monitoring will significantly improve the security and reliability of our Council deployment. By proactively detecting and responding to deviant behavior, we can prevent attacks, identify and fix errors, and simplify the debugging process.