SPLK-2002 Project Requirements

Project Requirements Detailed Explanation

1. Project Requirements

Understanding Business Requirements

Before deploying Splunk in any organization, the first and most important step is to understand what the business needs. You're not just setting up a tool — you're building a system that will help the company monitor systems, detect threats, analyze data, and make decisions.

a. Data Sources

What this means: What types of data will be sent to Splunk?

Splunk can ingest many types of data, including:

• Web server logs (e.g., Apache, Nginx)

• System logs (e.g., /var/log/syslog, Windows Event Logs)

• Application logs (e.g., Java logs, Python logs)

• Firewall and security logs

• Cloud service logs (AWS CloudTrail, Azure Monitor)

Why it matters: Different data sources may require different configurations, parsing rules, or add-ons.

Example: A bank might need to ingest firewall logs to detect threats, while a retail company might focus on web logs to track customer behavior.

b. Volume Expectations

What this means: How much data will be sent to Splunk every day?

This is usually measured in gigabytes (GB) or terabytes (TB) per day.

Why it matters:

• It affects license costs (Splunk licenses are based on daily ingest volume).

• It helps plan the infrastructure size (number of indexers, disk space, etc.).

• It helps avoid future problems like slow searches or system overload.

Example: If a company estimates 100 GB/day today but expects 1 TB/day next year, the architecture must be scalable.

c. User Roles

What this means: Who will use Splunk, and what will they do with it?

Think about:

• Admins: Manage infrastructure, configuration, data inputs.

• Power Users: Build dashboards, alerts, reports.

• Analysts: Run searches, investigate issues, view visualizations.

• Auditors: Check for compliance or security issues.

Why it matters:

• Different users need different levels of access control.

• Helps decide how to secure the system and structure apps and roles.

Example: A security team may need access to all firewall logs, while an application team only needs access to application logs.

d. Use Cases

What this means: What are the business problems you are solving with Splunk?

Common use cases include:

• Security Monitoring (SIEM): Detecting and responding to threats.

• IT Operations (ITOM): Monitoring servers, networks, applications.

• Business Analytics: Tracking customer behavior, KPIs.

• Compliance: Ensuring logs are stored and auditable to meet regulations (like GDPR, HIPAA, etc.).

Why it matters:

• Determines which data is most important.

• Helps decide how to design dashboards, alerts, and reports.

• Influences which Splunk apps or add-ons you’ll need.

2. Project Requirements

Key Elements of Project Planning

Once you understand the business goals, you move on to technical planning. This is where you take those business needs and start making decisions about architecture and design.

a. Data Retention Policies

What this means: How long should data be stored in Splunk?

Data goes through different stages in Splunk: hot → warm → cold → frozen.

You need to decide:

• How long to keep searchable data.

• When to archive or delete old data.

• Whether to store frozen data outside Splunk (like on AWS S3 or Hadoop).

Why it matters:

• Affects storage costs.

• Impacts search performance (too much old data = slower searches).

• Influences compliance (some industries must store data for 7+ years).

Example: A healthcare company may keep data for 5 years due to regulations, while a tech startup may only need 30 days.

b. Search Frequency

What this means: How often will users run searches?

Some users run occasional searches. Others run real-time or scheduled searches every few minutes.

Why it matters:

• Frequent searches create heavy load on search heads and indexers.

• Helps decide how powerful your servers need to be.

• Tells you when to optimize searches or use acceleration.

Example: A security team may run threat detection searches every 5 minutes, while a business analyst runs weekly reports.

c. Scalability Needs

What this means: Will the system need to grow over time?

Ask:

• Will more users be added?

• Will new data sources be added?

• Will the volume of data increase?

Why it matters:

• Guides how you build the architecture from the start.

• Determines whether to use clusters (for future expansion).

• Influences cloud vs on-premise decisions.

Best practice: Always design for growth, not just for today’s needs.

d. Security & Compliance

What this means: Are there any legal, regulatory, or security rules to follow?

Some examples:

• GDPR: Data privacy for European users.

• HIPAA: Protecting health information.

• PCI-DSS: Credit card data security.

Why it matters:

• Determines what data can be collected and how it must be protected.

• Influences encryption, access control, and retention policies.

• May require audit trails or data masking features.

Project Requirements (Additional Content)

1. Data Classification Strategy

Not all data is created equal—different data sources may vary in sensitivity, regulatory requirements, and business value. It is important to define a data classification strategy early in a Splunk deployment project.

Key Considerations:

• Tagging or classification of data types based on:

  • Sensitivity (e.g., PII, financial data, security logs)

  • Business criticality (e.g., real-time fraud detection vs. development logs)

• Classification outcomes affect:

  • Indexing policies (e.g., whether to retain or discard)

  • Encryption needs (TLS in transit, at-rest encryption for indexed data)

  • Storage placement (e.g., isolated indexes or SmartStore policies)

Why it matters:
Data classification informs access controls, index architecture, compliance strategies, and cost management.

2. Multi-Tenancy and App-Level Isolation

In environments where Splunk is used by multiple teams, departments, or business units, it’s crucial to design for logical separation and resource governance.

Best Practices for Multi-Tenancy:

• Use app-level isolation:

  • Each tenant/team has its own app context with specific dashboards, lookups, and saved searches.

• Assign role-based access controls (RBAC):

  • Restrict index access and knowledge object visibility per tenant.

• Deploy separate indexes or index naming conventions per group (e.g., teamA_, prod_, test_).

Why it matters:
Helps enforce data privacy, ensures operational independence, and supports auditability in shared Splunk environments.

3. Index Sizing Estimation Models

Before provisioning storage and designing retention policies, it’s essential to estimate index volume requirements accurately.

Index Size Estimation Tips:

• Use the official Splunk Index Sizing Calculator, available online.

  • Inputs typically include:

    • Daily raw log volume (e.g., 100 GB/day)

    • Data type (e.g., web logs, syslog, firewall)

    • Estimated compression ratio (~10:1 average in Splunk)

    • Retention period in days

• Output: Required storage for hot/warm/cold buckets per index.

Why it matters:
Prevents under-provisioning or over-commitment of storage and helps with license planning and performance optimization.

4. Cloud vs On-Premise Strategy

Most modern Splunk deployments consider Splunk Cloud, on-prem, or hybrid deployment strategies.

Comparison Points to Note:

• Splunk Cloud:

  • Fully managed by Splunk or partner (SaaS)

  • Different license model (e.g., ingestion-based or workload pricing)

  • Multi-tenancy isolation built-in, limited access to OS-level configs

  • Automatic updates, built-in scalability, and compliance coverage (FedRAMP, HIPAA, etc.)

• On-Premise:

  • Complete control over infrastructure and Splunk services

  • More flexibility for custom apps, forwarder behavior, and configuration

• Hybrid Deployments:

  • Common for regulated industries or large enterprises

  • Use cases:

    • Forwarders on-prem sending to cloud-based indexers

    • Some indexes stored locally (for low-latency or compliance), others sent to cloud

Why it matters:
Deployment strategy affects data governance, upgrade cycles, licensing models, architecture decisions, and troubleshooting workflows.