SIEM Implementation Guide for India — How to Deploy ManageEngine Log360 Step by Step

Deploying a SIEM is one of the most impactful security investments an Indian business can make — and one of the most commonly botched. Most failed SIEM deployments share the same problem: too many log sources configured too quickly, resulting in alert noise that overwhelms the team and causes them to tune out the console.

This guide walks through a phased, pragmatic approach to deploying ManageEngine Log360 in an Indian business environment.

Before You Start — Planning Checklist

Before installing a single agent, complete this planning exercise:

Inventory Your Log Sources

List every device and system that will send logs:

• Windows servers (domain controllers, file servers, application servers)
• Linux/Unix servers
• Active Directory (domain controllers)
• Network devices: firewalls (Fortinet, Sophos, SonicWall, Palo Alto, etc.)
• Switches and routers
• Wi-Fi controllers
• Cloud platforms: Microsoft 365, Google Workspace, AWS, Azure, GCP
• Security tools: antivirus/endpoint protection consoles
• Applications: ERP, CRM, database servers
• VPN concentrators

Prioritise: Not all log sources are equal. Domain controllers and firewalls are your highest-value sources for security monitoring. Start there.

Define Your Compliance Requirements

• RBI Cyber Security Framework (BFSI)
• SEBI LODR cybersecurity (listed companies)
• MeitY guidelines (government, critical infrastructure)
• PCI DSS (payment card processing)
• ISO 27001 (ISMS certification)
• GDPR/DPDP Act (customer data processing)

This determines which report templates to configure and which alert rules are mandatory.

Decide Deployment Architecture

• On-premise: Log360 server in your data centre or server room
• Cloud SaaS: ManageEngine-hosted Log360 tenant
• Hybrid: On-premise Log360 with cloud archiving

For most Indian BFSI, healthcare and government entities, on-premise is the correct choice due to data residency requirements.

System Requirements (On-Premise)

For a 100-device deployment:

The Log360 server should be dedicated — do not share with other applications. High-volume log collection is I/O intensive; slow storage is the most common performance bottleneck.

Phase 1: Core Infrastructure (Week 1)

Step 1: Install Log360

1. Download Log360 from the ManageEngine portal (or have Cloudfy provide the installation package with your licence)
2. Run the installer on your Windows Server
3. Default installation path: C:\Program Files\ManageEngine\Log360
4. Log360 installs as a Windows service (ManageEngine Log360)
5. Default web console: https://[server-ip]:8095
6. Default credentials: admin / admin (change immediately)

Step 2: Apply Licence

1. Log in to the Log360 console
2. Go to Admin > Licence
3. Upload your licence file (provided by Cloudfy)
4. Verify log source count and edition activate correctly

Step 3: Configure SMTP for Alerts

1. Go to Admin > SMTP Settings
2. Configure your organisation's SMTP relay or use a transactional email service
3. Test by sending a test email from the console

Phase 2: Active Directory Integration (Week 1–2)

Active Directory is your highest-priority log source. It tells you who logged in, from where, when, and what changed.

Step 4: Add Domain Controllers as Log Sources

1. Go to Log360 > Log Management > Windows Sources
2. Click Add Windows Source
3. Enter your domain controller hostname/IP
4. Configure credentials: use a service account with Domain Admin privileges (read-only access is sufficient for log collection; Cloudfy recommends a dedicated log360svc service account)
5. Select Event Categories to collect: Security, System, Application, Directory Service

Step 5: Configure ADAudit Plus Integration

Log360 includes ADAudit Plus for deep Active Directory auditing. Configure it separately:

1. Access the ADAudit Plus module within Log360 console
2. Add your domain
3. Enable auditing for: User logon/logoff, Account changes, Group policy changes, Privileged access, Object access

Critical AD audit policy settings (configure on all domain controllers via Group Policy):

• Account Logon: Audit Credential Validation — Success + Failure
• Account Management: Audit User Account Management — Success + Failure
• Logon/Logoff: Audit Logon — Success + Failure
• Object Access: Audit File System — enabled (for file server monitoring)
• Privilege Use: Audit Sensitive Privilege Use — Success + Failure
• DS Access: Audit Directory Service Changes — Success

Phase 3: Network Device Integration (Week 2)

Step 6: Configure Syslog from Firewalls

Most firewalls (Sophos, Fortinet, SonicWall, Palo Alto, Check Point) send logs via syslog.

In your firewall:

1. Enable syslog logging to the Log360 server IP
2. Port: UDP 514 (default) or TCP 514 for reliable delivery
3. Log severity: Informational or above (avoid Debug — too verbose)
4. Enable: Firewall rules, IPS events, VPN events, authentication events

In Log360:

1. Go to Log Management > Syslog Sources
2. Add each firewall as a syslog source
3. Select the correct device type/manufacturer (Log360 includes parsers for all major firewall vendors)

Step 7: Windows Event Forwarding for Member Servers

Instead of installing agents on every server, use Windows Event Forwarding (WEF) to centrally push events to a Windows Event Collector, then forward to Log360:

1. Configure a Windows Event Collector server (can be the Log360 server itself)
2. Create a WEF subscription with source-initiated subscription
3. Deploy the collector computer certificate via Group Policy
4. Configure Log360 to receive from the Event Collector

This reduces the number of direct connections Log360 needs to maintain.

Phase 4: Cloud Platform Integration (Week 2–3)

Microsoft 365

1. In Log360, go to Cloud Security > Microsoft 365
2. Connect using Azure AD App Registration (OAuth 2.0)
3. Required API permissions: AuditLog.Read.All, Directory.Read.All, Reports.Read.All
4. Enable: Exchange Online audit logs, Azure AD Sign-in logs, SharePoint audit logs, Teams activity logs

Google Workspace

1. In Log360, go to Cloud Security > Google Workspace
2. Connect using a Google Service Account with Domain-wide Delegation
3. Required scopes: Admin SDK Reports API
4. Enable: Login events, Admin console changes, Drive activity, Gmail audit

AWS CloudTrail

1. Enable CloudTrail in all AWS regions
2. Configure CloudTrail to deliver logs to an S3 bucket
3. In Log360, add the S3 bucket as an AWS log source with appropriate IAM credentials

Phase 5: Alert Configuration (Week 3)

This is the most important phase and the most commonly rushed. Resist the urge to enable every alert immediately.

Start with High-Fidelity Alerts Only

Begin with alerts that have low false positive rates:

Tier 1 — Enable Immediately (very high fidelity):

• Domain admin account created or modified
• New user added to Domain Admins or Enterprise Admins
• Service account password change
• Active Directory replication failure
• Firewall rule change
• Multiple failed login attempts from same IP (brute force threshold: 10 failures in 5 minutes)

Tier 2 — Enable After Baseline (higher noise):

• Login outside business hours (calibrate to your actual business hours)
• Login from new country or IP geolocation
• Large file volume access (calibrate to your actual access patterns — varies enormously)
• New service installed on server
• USB device connected to endpoints

Tier 3 — Enable After Tuning Tier 2:

• UEBA risk score threshold alerts
• Anomaly detection on data transfer volume
• Process creation on sensitive servers

Alert Tuning — The Critical Step Most Teams Skip

Before enabling any Tier 2 or Tier 3 alerts:

1. Run the detection in report mode (no alerts, just log the matches) for 2 weeks
2. Review the report: identify legitimate business activity generating matches
3. Create exceptions/whitelists for legitimate sources
4. Only then enable live alerting

This prevents the alert fatigue that kills most SIEM implementations.

Phase 6: Compliance Reports (Week 3–4)

Configure Indian Compliance Report Templates

1. Go to Reports > Compliance Reports in Log360
2. Select your required frameworks:
   • RBI Cyber Security Framework
   • SEBI LODR
   • PCI DSS
   • ISO 27001
3. Map your log sources to the report data requirements
4. Schedule reports: monthly for operational review, quarterly for audit submissions
5. Configure PDF export and email delivery to compliance team

SEBI LODR Specific Configuration

For listed Indian companies, configure:

• Real-time alert for any access to financial system databases outside business hours
• Monthly report of all privileged access events
• Incident report template pre-configured for the required format

Common SIEM Implementation Mistakes in India

Mistake 1: Collecting everything before tuning anything

Starting with 200 log sources and all alerts enabled results in thousands of daily alerts, all of which get ignored. Start with 20 sources and get those tuned first.

Mistake 2: No alert owner assigned

Every alert rule should have a named owner who is responsible for investigating it. Without this, alerts are reviewed by no one.

Mistake 3: No log retention policy

Indian compliance frameworks require specific log retention periods:

• RBI Cyber Security Framework: 3 years minimum
• PCI DSS: 12 months (3 months hot + 12 months archived)
• ISO 27001: As defined in your ISMS scope (typically 1–3 years)

Configure Log360 archiving to match your retention requirements.

Mistake 4: SIEM deployed without endpoint log coverage

A SIEM with only network device logs misses endpoint events — which is where most breaches are detected. Ensure Windows Event Forwarding or Log360 agents are deployed on all servers and endpoints.

Need Professional Help?

SIEM deployment is one of those projects where professional assistance saves weeks of painful tuning. Cloudfy provides ManageEngine Log360 deployment services in India — from initial planning through production deployment, alert tuning and compliance report configuration.

Contact us: +91 97600 50555 · connect@cloudfysystems.com

Frequently Asked Questions

How long does a Log360 deployment take?

A basic deployment (core infrastructure, AD integration, primary network devices) can be operational within 2–3 days. A full production deployment with cloud integrations, alert tuning and compliance reports typically takes 2–3 weeks. This is significantly faster than Splunk at comparable scope.

Can Log360 handle both on-premise and cloud log sources?

Yes. Log360 collects on-premise logs (Windows Event Forwarding, syslog) alongside cloud platform APIs (Microsoft 365, Google Workspace, AWS, Azure) in the same console. This unified view is one of Log360's key strengths.

What happens if the Log360 server goes down?

Windows/Linux agents continue to buffer logs locally and deliver them when the Log360 server recovers. Syslog devices (firewalls, switches) do not buffer — logs generated during the outage may be lost. For critical environments, configure syslog to a secondary log receiver as backup.

Does Log360 work with non-Windows log sources?

Yes. Log360 supports Linux (via syslog or direct agent), network devices (via syslog), cloud platforms (via API) and many application types. Over 700 pre-built log parsers cover most common enterprise sources.