Nate Smith (2017) - Want to see the Invisible? It's not as hard as it SIEMS

### Overview In this introductory presentation at Saintcon 2017, Nathan Smith addresses the critical challenge of organizational visibility and walks through the fundamentals, deployment considerations, and architectural challenges of implementing a Security Information and Event Management (SIEM) platform. Drawing from his firsthand experience transitioning from knowing nothing about SIEMs to managing an enterprise deployment with LogRhythm across thousands of servers, Smith provides practical guidance for practitioners evaluating whether to choose open-source or commercial solutions.

### Key Topics - **Definition and Core Value of a SIEM**: A SIEM serves as a centralized source for gathering logs and events across heterogeneous environments (firewalls, endpoints, printers, systems). Beyond centralization, key use cases include event correlation across disparate systems (e.g., matching edge firewall alerts with internal host events), meeting compliance reporting mandates (such as PCI, HIPAA, and FedRAMP), automated alerting, forensic investigations, and policy-driven log retention. - **Open Source vs. Commercial Solutions**: Practitioners can evaluate open-source options such as Graylog, OSSIM, ELK stack (Elasticsearch, Logstash, Kibana), and SIEM Monster, alongside commercial platforms like LogRhythm, AlienVault, Alert Logic, HP ArcSight, and IBM QRadar. Commercial platforms provide turnkey rules and dedicated support but incur heavy annual licensing costs based on messages per second (MPS). Open source avoids license costs but demands significant time, documentation research, and maintenance overhead. - **Operational and Architectural Realities**: SIEM deployments face common pitfalls such as alert fatigue, resource constraints, lack of cross-team buy-in, and infrastructure sizing errors. Scaling often requires abandoning all-in-one server configurations in favor of distributed, virtualized architectures with dedicated log collectors and data processors.

### Technical Details - **Licensing and Sizing Calculations**: Commercial vendors typically license based on messages per second (MPS). Smith warns against linear math (e.g., assuming 1,500 additional servers will produce 15x the volume of the first 100) because server chattiness varies widely. Windows security event logs on idle servers generate fewer events than perimeter firewalls. In high-volume scenarios, teams may choose to log only threat intelligence/alert events rather than raw network traffic, or pre-filter through intermediate syslog servers. - **Scope and Triage Strategy**: Full network visibility across every internal node is often financially or technically unfeasible initially. Smith recommends prioritizing high-exposure assets first, starting with perimeter edge devices and DMZ systems reachable by external users. - **Tuning and Alert Fatigue**: Out-of-the-box alerting rules frequently generate excessive false positives. For example, geolocation-based alerts triggered on benign foreign connections in a cloud contact center environment, requiring extensive tuning to reflect organizational normal baselines. - **Hardware Scaling**: Moving from an initial all-in-one appliance that quickly became overwhelmed, Smith’s deployment grew to seven virtualized servers. Separating collectors from data processors allows the platform to ingest, archive, and correlate logs without choking processing pipelines, while virtualization enables dynamic allocation of CPU and RAM as host counts double. - **Automation Barriers**: While automated response features (such as automated IP blacklisting or account disabling) exist in commercial tools, organizational trust and buy-in from sysadmins and operations teams are required before security can enable active containment actions.

### Takeaways Deploying a SIEM is not a one-time product purchase but an ongoing operational commitment. Security teams must account for available personnel, support structures, cross-departmental coordination, and hardware scalability. By strategically scoping log sources, expanding collectors, and tuning default alerts, organizations can achieve meaningful visibility without overwhelming analysts or budgets.