Monitor Best Practices

Recommendations for deploying ByteHide Monitor effectively in production on Android.

Token Security

• Never hardcode tokens in source code. Use environment variables or secure vaults
• Use separate tokens for development, staging, and production environments
• Rotate tokens periodically and after any suspected compromise
• Restrict token scope: each token should be linked to a single project

Action Strategy

Development Environment

Use permissive actions to avoid disrupting the development workflow:

Debugger Detection → NONE (developers use debuggers)
Emulator Detection → NONE (testing on emulators)
VM Detection       → NONE (may develop on VMs)
All Others         → LOG

Debugger Detection → NONE (developers use debuggers)
Emulator Detection → NONE (testing on emulators)
VM Detection       → NONE (may develop on VMs)
All Others         → LOG

Staging Environment

Use logging actions to gather data without blocking:

All Protections → LOG

All Protections → LOG

Review the incident dashboard to tune which protections to enforce in production.

Production Environment

Use a graduated approach based on threat severity.

Desktop and Mobile protections:

Debugger Detection     → CLOSE (high severity)
Root/Jailbreak         → CLOSE (high severity)
Tampering Detection    → CLOSE (high severity)
Memory Dump Detection  → CLOSE (high severity)
Process Injection      → CLOSE (high severity)
Emulator Detection     → LOG   (medium severity)
VM Detection           → LOG   (medium severity)
Clock Tampering        → LOG   (medium severity)
Network Tampering      → LOG   (medium severity)

Debugger Detection     → CLOSE (high severity)
Root/Jailbreak         → CLOSE (high severity)
Tampering Detection    → CLOSE (high severity)
Memory Dump Detection  → CLOSE (high severity)
Process Injection      → CLOSE (high severity)
Emulator Detection     → LOG   (medium severity)
VM Detection           → LOG   (medium severity)
Clock Tampering        → LOG   (medium severity)
Network Tampering      → LOG   (medium severity)

Web and Cloud protections:

SQL Injection          → BLOCK (high severity)
XSS                    → BLOCK (high severity)
Command Injection      → BLOCK (high severity)
Path Traversal         → BLOCK (high severity)
SSRF                   → BLOCK (high severity)
NoSQL Injection        → BLOCK (high severity)
LLM Prompt Injection   → LOG   (evaluate before enforcing)

SQL Injection          → BLOCK (high severity)
XSS                    → BLOCK (high severity)
Command Injection      → BLOCK (high severity)
Path Traversal         → BLOCK (high severity)
SSRF                   → BLOCK (high severity)
NoSQL Injection        → BLOCK (high severity)
LLM Prompt Injection   → LOG   (evaluate before enforcing)

For web protections, configure Workflow Rules in the Cloud Dashboard to combine actions: Log + Block + Block IP for critical threats.

Protection Selection

Mobile Applications (Android/iOS)

Prioritize these protections:

1. Root/Jailbreak Detection: compromised devices are the top mobile threat
2. Debugger Detection: prevents dynamic analysis
3. Tampering Detection: verifies app integrity
4. Emulator Detection: blocks automated analysis

Desktop Applications

Prioritize these protections:

1. Debugger Detection: blocks reverse engineering
2. VM Detection: prevents sandboxed analysis
3. Tampering Detection: verifies binary integrity
4. Memory Dump Detection: protects in-memory secrets

Web Applications (Android)

Prioritize these protections:

1. SQL Injection: the most common web attack vector
2. XSS: protects user sessions
3. Path Traversal: prevents file system access
4. SSRF: blocks internal network access

Configuration Management

• Use cloud configuration as the primary method. It allows instant updates without redeploying
• Keep JSON configuration as a fallback for offline or air-gapped environments
• Use hybrid configuration in production: cloud for protection rules, Configuration API for custom action handlers
• Version-control your JSON configuration alongside your application code. Export from the Cloud Dashboard to keep them in sync

Monitoring and Response

• Review the incident dashboard regularly. Look for patterns and anomalies
• Set up Workflow Rules to automate responses with notifications to Slack or webhooks
• Use custom actions to integrate with your alerting system (PagerDuty, Slack, SIEM)
• Track incident trends: a sudden spike may indicate an active attack campaign
• Enable Anomaly Detection: it learns normal behavior and flags deviations automatically

Performance Optimization

• Set appropriate intervals: 60 seconds is a good default for most protections
• Increase intervals for low-risk protections: VM and emulator detection can run every 120 seconds
• Decrease intervals for high-risk protections: debugger detection can run every 30 seconds
• Disable irrelevant protections: don't enable VM detection on mobile devices

Deployment Checklist

Before deploying to production:

• [ ] Token is stored as an environment variable or secret (not hardcoded)
• [ ] Protection modules are selected based on your application type
• [ ] Action types are appropriate for production (not all set to NONE)
• [ ] Logging level is set to Info or higher (not Debug)
• [ ] Cloud configuration is working and accessible
• [ ] Incident dashboard is accessible to your security team
• [ ] Custom actions are tested and functioning
• [ ] CI/CD pipeline includes the token as a secret
• [ ] Debug logging is disabled
• [ ] Anomaly Detection is enabled

Next Steps