Automated Threat Response using SMS
- Pavan Raja
- Apr 8, 2025
- 16 min read
Summary:
The document provided outlines a detailed strategy for enhancing IT security through the use of SMS, focusing on automated threat response, privileged user monitoring, and detailed activity reporting. Here's an overview of how this approach can be explained during the session:
### Automated Threat Response Using SMS - **Event Triggering**: The system detects potential threats by triggering alerts based on specific conditions such as three login failures within two minutes outside normal business hours for sysadmin users. This setup leverages a correlation engine to escalate threats based on past behaviors. - Demonstration: Show how the system identifies patterns of activity that could indicate compromised credentials or malicious intent, and how it automatically triggers alerts without manual intervention. - **Privileged User Monitoring**: The system tracks privileged accounts and users across all applications, categorizing these by identity, role, department, etc., and monitors changes in roles and privileges. This is crucial for preventing unauthorized access to sensitive information. - Demo: Use a laptop demo with ESM (Enterprise Security Manager) and IdentityView tools to demonstrate how the system tracks privileged users and alerts on suspicious activities. - **Correlation Engine**: Discuss how this engine integrates data from multiple sources, correlates events, and escalates threats based on predefined rules set by security analysts. This includes active lists that track malicious actors or compromised systems. - Demonstration: Show how the correlation engine can take action against potential threats before they cause significant damage. - **Incident Handling**: Utilize a dashboard or event viewer to identify and understand incidents, employing investigative tools like correlation techniques for deeper analysis. This involves real-world scenario testing to validate response mechanisms. - Demonstration: Use ESM to illustrate how the system handles incidents from initial identification through resolution.
### Integration of Data from Other Systems - **Data Retrieval and Integration**: Discuss how the system retrieves, integrates, and analyzes information from various other systems to aid analysts in their work. This includes integration with external DHCP servers and user login servers for IP address resolution to username mapping. - Demo: Demonstrate how data retrieval enhances incident investigation by providing a comprehensive view of an attacker's path through the network. - **External System Interface**: Explain how connections are established with other incident management systems, including custom adapters created by third parties like DND. This involves handling feedback mechanisms to close incidents efficiently. - Demonstration: Show how external system interfaces support seamless data flow and efficient incident response across different platforms.
### Reporting and Alerting Mechanisms - **Queries**: Users can conduct both novice and expert queries to explore stored data, with options to save and share their findings for future reference or collaboration. - Demonstration: Show how the system's query functionality aids in uncovering patterns or anomalies that might indicate security threats. - **Reports**: Discuss the variety of user-friendly report formats available within the SIEM interface, which can be generated as needed by users. - Demo: Generate and review reports on potential threats or anomalous activities to stakeholders during the session. - **Scheduling**: Explain how users can schedule automated reports to be sent via email to designated recipients based on predefined criteria. - Demonstration: Schedule a report on privileged user activity for an upcoming meeting with stakeholders, showing how this functionality supports proactive security measures. - **External Tools Execution**: Discuss the mechanism for executing external tools using data extracted from event records, such as querying external systems for more detailed analysis. - Demo: Execute an external tool to cross-reference suspicious activities identified by the system, enhancing incident response capabilities. - **Documentation Integration**: Show how contextual documentation is provided via pop-ups when dealing with specific security issues, offering guidance on appropriate actions. This aids analysts in making informed decisions quickly and efficiently. - Demonstration: Provide a demo where an analyst encounters a security issue and accesses relevant documentation to guide their response strategy. - **Alerting Mechanisms**: Discuss the multiple alerting mechanisms available within the system, including email notifications and desktop alerts, which keep stakeholders informed about critical events or anomalies detected by the system. - Demo: Demonstrate how these alerts are configured and used in real-time to ensure timely responses to potential threats.
### Conclusion The document's approach is designed to provide a structured method for evaluating and demonstrating various aspects of incident management within an organization's IT infrastructure, focusing on both functionality and usability through practical demonstrations using ESM tools like IdentityView. The session will include interactive demos, discussions with stakeholders, and opportunities for Q&A to ensure attendees fully understand the capabilities and benefits of this SMS-based security system.
Details:
The document is a Proof of Concept Request Form for the Department of National Defence (DND) to assess ArcSight's capabilities. It outlines steps and requirements for conducting a proof of concept (POC). Key sections include:
1. **General POC Information**: Includes company name, shipping details, hardware required, and contact information.
2. **Primary Customer Contacts**: Lists key contacts from DND involved in the POC process.
3. **Additional Key Customer Contacts**: Names of additional personnel who will be part of the assessment team.
4. **Business Requirements and Drivers**: Requires answering business-related questions about specific needs or expectations for the ArcSight solution.
5. **Proof of Concept Scope**: Details the scope of what will be assessed during the POC, including hardware/software environments and tasks to be performed.
6. **Hardware/Software POC Environment**: Specifications for the test environment setup.
7. **ArcSight Manager Environment**: Setup details for ArcSight manager software.
8. **ArcSight SmartConnector Environment**: Technical requirements for connectors used in the assessment.
9. **Success Criteria**: Defines success metrics to be met during and after the POC.
10. **Sample Success Criteria**: Provides examples of criteria that will determine if the POC is successful.
11. **Proof of Concept Tasks**: Detailed activities to be completed over several days, such as preparation steps, day-specific agendas for meetings, and further tasks during subsequent days.
This document is intended only for use by ArcSight personnel and the DND for conducting a specific assessment and should not be replicated or distributed without written consent from ArcSight.
The document outlines a Proof of Concept (POC) project involving two main contacts, Major Mulroney for technical and business roles, and representatives from ArcSight, including Danielle Fournier and Gary Freeman. The POC was initiated on August 3, 2009, with an expected end date of August 7, 2009, spanning a total duration of 5 days, including 3 days onsite with the ArcSight team.
Mulroney's role is DIMEI 12-4 in both technical and business capacities within the Department of National Defence, focusing on security engineering expertise. His contact details include a main office phone number (1-613-991-4836), mobile phone number (1-613-316-0465), fax number (613-993-2833), and an email address (david.mulrooney@newterra.ca).
The primary business question addressed is the need for long-term log retention and analysis for Departmental information security infrastructure, along with operational short-term analysis of security event information as part of IT security operations. The executive sponsor for this project is the Director General Information Management Technology from the Department of National Defence.
For the POC scope, it was decided to conduct the test in a lab environment rather than using production devices or environments, which is standard practice when testing new technologies before potential implementation. Specific use cases include gathering information about long-term log retention and real-time security event analysis, as outlined by business requirements.
The objective of evaluating ArcSight is to determine its technical suitability for DND's planned purposes, focusing on functionality and operation rather than capacity metrics like events per second or storage space. Appendix E outlines the areas that will be examined during the evaluation.
The hardware/software Proof of Concept (POC) environment involves a Windows operating system installed on four servers each with a 2.8GHz dual-core CPU, totaling 8GB RAM and one NIC. The ArcSight Manager Environment includes an ArcSight Manager 2650 and Connector Server, all running on the same machine or provided by DND, depending on Appendix A specifications.
ArcSight products included in the evaluation are ESM onsite (with a focus on Onsite Enterprise Security Manager), TRM (Threat Risk Management), Logger, and Connector Appliance through VM demo. The hardware for ArcSight Manager and Database will be provided by ArcSight, installed on the same machine as the Manager or a system supplied by DND.
Expected event processing rates for the ESM proof of concept are less than 500 events per second (EPS). The evaluation environment is planned in a lab setup, where additional connectors can be included if necessary but limited to five or six for focused evaluations. A vulnerability scanner might also be included if desired, and Appendix A provides system specifications for hosting SmartConnectors.
This document outlines several connector setups for different devices and applications in a proof of concept (POC) environment. Each connector is designed to monitor specific devices or software products, with varying configurations and environments. Here's a summary of each connector setup:
1. **FlexConnector - Secure Computing Cyberguard 4150**
Environment: Lab
Device: FlexConnector (provided by Department of National Defence - Canada)
Version/Patch Level: 6.4
Events per Second (EPS): Low
Logging Mechanism: Provided log samples for engineering to build the connector.
Number of End Devices: 1
Device Administrator: TBD
2. **Cisco IOS**
Environment: Production
Device: Cisco IOS (7200 Router, 3750 Switch)
Version/Patch Level: 12.4 (7200 Router), 12.2 (3750 Switch)
Events per Second (EPS): Low
Logging Mechanism: Syslog
Number of Assets: 2
Device Administrator: TBD
3. **Cisco Security Agent**
Environment: Lab
Application: Cisco Security Agent
Version/Patch Level: v.5
Events per Second (EPS): Low
Logging Mechanism: File reader (reading from a shared directory)
Number of Application Instances: 1
Application Administrator: TBD
4. **Alladin eSafe**
Environment: Lab
Device: Alladin eSafe
Version/Patch Level: 7.1
Events per Second (EPS): Low
Logging Mechanism: Not specified, likely involves reading logs from the application itself or a shared directory.
Number of End Devices: Not specified (assumed to be multiple if it's an "eSafe" solution)
Device Administrator: TBD
Each connector setup is tailored to monitor specific devices and applications in either a lab or production environment, with varying logging mechanisms and expected EPS values. The document does not provide full details for connectors 2, 3, and 5 due to space constraints, but outlines the basic information required for each connector.
This document outlines several connectors being used in a proof of concept environment for monitoring various systems. The connectors are set up to monitor databases and applications within a lab environment. Here's a summary of the key points from each connector section:
1. **Connector #6**:
Monitoring a single database using Symantec End-Point Protection DB version 11, with logging via ODBC. This is intended for a lab environment.
2. **Connector #7**:
Using Syslog-NG version 1.6.8 on unspecified operating systems or appliances. The connector needs to report products and versions compatible with Syslog-NG. Expected EPS (Events per Second) is low, indicating minimal real-time logging requirements. Logging mechanism involves OPSEC, Syslog, SNMP, DB, etc., but specific details are not detailed.
3. **Connector #8**:
Monitoring Squid Web Proxy version 3 in a lab environment. The system logs events using a file reader from a shared directory. Expected EPS is low, suggesting minimal logging needs. The logging mechanism includes OPSEC, Syslog, SNMP, DB, etc., but specifics are not provided.
**Success Criteria**:
Satisfy SIEM functionality criteria by efficiently capturing, filtering, normalizing, aggregating, and categorizing event data from multiple sources including OS log, Firewall, IDS, Database.
These connectors are part of a broader initiative to demonstrate or validate SIEM capabilities within the lab environment before potentially scaling up to production environments.
This document outlines various capabilities of a system designed for real-time monitoring, analysis, and response to security threats in networks (VA Scanner). Key features include fault-tolerant event collection, real-time correlation, automatic tracking of suspicious users/hosts, graphical dashboard views, automated baseline monitoring, asset modeling, incident handling, workflow management, and report generation. The system aims to provide a comprehensive solution for network security by enabling quick analysis, investigation, and response without impacting network performance.
The summary highlights key aspects of a cybersecurity evaluation and implementation process using the ArcSight platform. It emphasizes the importance of flexibility in reporting, compliance with regulatory standards, threat correlation and visualization, and automation capabilities. Additionally, it outlines a typical one-week proof of concept schedule that includes preparation steps such as signing agreements, confirming resources, setting up lab equipment, and installing necessary software components like SmartConnectors. The process also involves coordination with business and technical stakeholders to ensure smooth integration without affecting production systems.
This document outlines a series of activities and requirements for implementing the ArcSight solution during the first five days, followed by information about supported platforms.
On day one, the server is set up upon arrival. Days two and three involve continued data collection using ArcSight Manager, development of custom content and use cases tailored to customer needs, and discussions on the ArcSight Architecture with key decision-makers. Meetings are reserved for these activities, accommodating up to six people at a time based on specific requirements (e.g., architecture review or day-to-day security operations).
Functional demonstrations for security analysts, business users, and presentations about reports or dashboards are scheduled during the same days, each lasting one hour with capacity for up to six participants. These sessions aim to showcase how ArcSight can address specific needs in these areas.
During day four and five, customers will privately evaluate the ArcSight solution as part of a Proof of Concept (POC) phase, supported remotely by ArcSight personnel. A dedicated primary technical contact is required for this period. It's assumed that DND staff will receive necessary training to operate the product during ArcSight's onsite presence.
Appendix A provides details on the supported platforms and system requirements for the ArcSight Console and Connectors, including operating systems such as Linux, UNIX, Windows, and Macintosh, along with their respective memory and disk space requirements.
This document outlines the setup and requirements for a Proof of Concept (POC) involving ArcSight, a security information and event management (SIEM) software. The POC involves evaluating ArcSight on various operating systems including Red Hat Enterprise Linux 4.0 (RHEL 4), Windows Server 2003 SP1, Windows Server 2003 R2, Windows Vista (64-bit), and Windows XP Pro SP2. Both the dual-core CPU system and memory requirements are specified as 1-2GB, while disk space required is 2GB per system.
The POC preparation steps include signing evaluation agreements for confidentiality and non-disclosure, confirming lab equipment availability for testing, securing administrative access to all systems and network devices, ensuring business permission for configuration changes, arranging information delivery for ArcSight equipment (ESM Server), and preparing use cases specific to the evaluation. Additionally, there are requirements related to network addresses/ports including ESM Server requiring 1 address/port for both 100 or 1000 Mbps in Full-Duplex mode.
Appendix C provides a list of required network ports for communication between ArcSight and production systems during the POC. This includes various TCP and UDP ports used by devices like Workstations, Connector Appliance, NSP Appliance, and Network Devices to communicate with ArcSight's ESM (Event Management Server) and other components. The document also specifies that SSH is preferred for network connections in most cases, while Telnet can be used as an alternative when necessary.
The document outlines several key aspects of ArcSight, a security information and event management (SIEM) tool primarily used in Windows environments for managing network security. Key details include:
1. **Connectors**: Specifically designed for Windows Domain Controllers (Windows DC), the connector uses RPC and Remote Registry to access the Windows Event Log over TCP ports 135, 139, and 445, as well as UDP ports 137 and 138.
2. **ArcSight Connector Appliance**: This appliance communicates with the ES (Event Server) via TCP port 8443, transmitting data in Common Event Format (CEF) back to ES for further processing. Additionally, it interfaces with NSP (Network Security Platform) through the same port and protocol for counter-acting activities related to Threat Risk Management (TRM).
3. **Non-Refutability**: The system incorporates features that ensure data integrity and non-manipulable records. This includes detailed documentation on litigation quality controls and non-refutability across the entire product suite, which guards against potential manipulation by administrative staff through measures like encryption or digital signatures.
4. **Normalization and Converters**: ArcSight supports normalization converters to standardize data formats from various sources, both pre-built (as part of the product set) and custom (using tools like FlexConnector for sample log data processing).
5. **External Storage**: The system can utilize external storage for near-line or off-line archival purposes, with minimal impact on search capabilities as managed through retention policies and partition management.
6. **Self-Audit**: ArcSight captures information about user activities that retrieve information, ensuring transparency and accountability within the system.
7. **Event De-duplication**: The system includes features to eliminate duplicate events by aggregating similar entries across multiple devices or sources.
8. **Seamlessness of Data**: For log and SIEM components handling event data from multiple devices, ArcSight aims to provide a seamless user experience through intuitive interfaces that integrate these disparate data sets into coherent overviews.
This summary provides an overview of how ArcSight operates in Windows-based environments and the comprehensive features it offers for network security management and auditing, including its approach to non-refutability, normalization, external storage integration, self-audit capabilities, event de-duplication, and data presentation across devices.
The document discusses various aspects of a SIEM (Security Information and Event Management) solution, focusing on mechanisms for managing event traffic, monitoring system health, handling licensing, scalability, encryption, automated log retention, agent impact, bandwidth usage, protocol and port utilization, configuration changes without service interruption, database complexity, and administration.
For addressing peaks in incoming events, the document mentions that mechanisms such as Logger peering and ESM network modeling are implemented to manage traffic and identify data loss using data monitors and connector configuration. It also covers event traffic health monitoring with tools like health monitoring correlation rules to alert if data collection from original reporting devices fails.
Regarding licencing implementation, this will be discussed in the document. The scalability of the system is another topic that includes a discussion on integration points, how it scales, and what these look like. Encryption for intra-system communications is also covered, including its implementation details.
The document discusses automated log retention with features such as partition management, scheduled archiving, and installation options to manage retention policies effectively. It evaluates the impact of agents on systems during log collection, event filtering and normalization, and log encryption during transmission. The bandwidth consumption by different components of the SIEM solution is evaluated using Wireshark, while protocols and ports used are detailed in appendix C.
Lastly, the document assesses whether configuration changes can be made without service interruption and provides a discussion on database complexity and administration access to data structures.
The document outlines several key aspects of a comprehensive security and log management system, including Logger retention policies, user management, data access management, backup/failover mechanisms, log functionality (audit, compression), archiving and retrieval, and SIEM functionality (standard analytics, reporting, threat tracking).
**Logger Retention Policies**: Deals with old events and logs by implementing policies that allow archiving or deletion based on source, size, and age. These policies are discussed in detail under the Logger retention policy section.
**User Management**: Focuses on how users are authenticated and authorized within the system. It also explores if external authentication systems can be integrated for enhanced security and authorization mechanisms. This topic is to be demonstrated and discussed as part of user management.
**Data Access Management**: Discusses the ability to group users and assign them access rights based on various criteria including user, user group, time, event source, or log/SIEM system. The process will be shown and explained during demonstration.
**Backup/Failover**: Describes general backup and failover mechanisms available in the system components. This is discussed alongside connector configuration and architecture.
**Log Functionality (Audit, Compression)**: Outlines audit mechanisms and record compression implementation within the system. The creation of audit schemes involves user involvement as well. These features are to be demonstrated and explained during discussions.
**Archiving and Retrieval**: Explores how archiving works and whether a mixed scheme for both can be implemented. It also looks into the complexity of retrieving archived data for analysis purposes. This is covered under the archiving and retrieval section, set to be demonstrated and discussed.
**SIEM Functionality (Standard Analytics, Reporting, Threat Tracking)**: Discusses how products can perform threat tracking and correlation using active lists that escalate threats based on past behaviors. It also covers the automatic maintenance of privileged accounts and users list which can be used within correlation rules for better threat management. This is to be demonstrated and explained during the session.
**Integration of Data from Other Systems**: The system's capability to retrieve, integrate, and analyze information from other systems aids analysts in their work. This topic is also slated for discussion.
**Event Trigger**: Describes the complexity of creating event triggers within the system and the mechanisms involved in this process.
This document outlines a comprehensive approach to managing security through the use of SMS (Short Message Service), focusing on automated threat response, privileged user monitoring, and detailed activity reporting. The system is designed to detect and respond swiftly to potential threats by triggering alerts based on specific conditions such as three login failures within two minutes outside normal business hours for sysadmin users. This setup includes a direct tie-in with the Correlation Engine and can simulate quarantine actions before execution, ensuring compliance with full chain of command protocols. The interface is secured with SSL encryption, maintaining secure storage of credentials for remote systems.
Additionally, the system monitors privileged users by tracking their activities across all applications, categorizing these by identity, role, employee type, department, and more. It also keeps a close eye on changes in roles and privileges within applications and identifies deviations from typical user behavior. The system can integrate multiple identity and authentication sources to map identifiers for employees accurately even after termination or leave. This comprehensive approach is intended to provide real-time monitoring and responsive action against potential threats and privileged misuse, ensuring the integrity of sensitive information systems and preventing unauthorized access.
The document outlines a comprehensive review of various aspects related to incident management within an organization's IT infrastructure, using specific software tools such as ESM (Enterprise Security Manager) and IdentityView. Key areas covered include privileged user monitoring, internal case management, external system interface, workflow management, incident handling, and the usability of the user interface.
For privileged user monitoring, the document highlights the importance of tracking and reporting on their behaviors to ensure they do not gain unauthorized access to sensitive information. This will be demonstrated using a laptop demo with ESM and IdentityView tools.
In terms of internal case management, the system's capability to route incidents based on triage is crucial for efficient handling. This functionality will be showcased during the demonstration with ESM.
Regarding external system interfaces, the document inquires about how connections are established with other incident management systems and what level of support is provided in creating custom adapters by third parties like DND. Feedback mechanisms to close incidents are also addressed.
Workflow management includes mechanisms for managing potential incidents right from the start, as well as provisions for escalating unaddressed incidents. This will be demonstrated using ESM.
Incident handling involves utilizing a dashboard or event viewer to identify threats and infected hosts, employing investigative tools like correlation techniques to understand the extent of an incident. The document suggests using real-world scenarios to test the system's workflow and incident handling capabilities.
The user interface is evaluated for its ease of use, with specific attention to drill-down/drill-across features in event and incident viewers, as well as the creation of individual and group dashboards.
Overall, the document provides a structured approach to evaluating and demonstrating how an IT security system supports various aspects of incident management, emphasizing both functionality and usability through practical demonstrations using ESM tools.
The document outlines a series of demonstrations and discussions planned for stakeholders such as Event Source Management (ESM) and Logger. These involve showcasing various features and functionalities within the system including queries, reports, scheduling, external tools execution, documentation integration, and alerting mechanisms.
**Queries**: Users can conduct queries in both novice and expert methods to explore data stored in the system. They have options to save and share their queries for future reference or collaboration.
**Reports**: The system offers various report formats that are designed to be user-friendly, making it easy for users to generate reports as needed.
**Scheduling**: Users can schedule automated reports to be sent via email to designated recipients on a predefined basis.
**External Tools**: There are mechanisms in place to allow the execution of external tools using data extracted from event records, such as querying an external DHCP server and user login server for IP address resolution to username.
**Documentation Integration**: The SIEM interface provides contextual documentation that can be accessed via pop-ups when dealing with specific security issues, offering guidance on how to handle these problems effectively.
**Alerting Mechanisms**: Users have access to multiple alerting mechanisms including email notifications and desktop alerts to keep them informed about critical events or anomalies detected by the system.
Comments