About ASPEN

ASPEN supports unique dynamic architecture - it can consist of one node at the beginning, and then grow to many interconnected nodes, as requirements evolve. This architecture has benefit of intrinsic High-Availability (Fail-Over and Load-Balancing) operations without any special requirements or configuration. Due to this architecture, it is possible to build the network of SIEM servers following internal organizational requirements (Head Office, Branches, Departments, …). Every node in ASPEN network can perform partial processing and then filter or forward data for final processing at the central SIEM.

SIEM and log management are independent features of the system. This means that one can be used with or without the other. Further more, each feature can be turned on or off or replaced with another product at any time, without impacting operations of the other features.

Search engine embedded in our SIEM/log management solution is state-of-the-art, distributed, scalable, highly elastic, cloud-technology-based indexing and searching solution. What this means is that SIEM/log management can start with one or two nodes (for High Availability) and, as amount of data to be processed increases, ASPEN can grow to hundreds of servers, without any downtime or reconfiguration.

Search engine is optimized to use this distributed nature maximally. All queries are split and executed in parallel on multiple nodes.

User interface to this search engine consists of high-performance, full-featured text searching API. Some of the supported features are:

• many powerful query types: phrase queries, wild-card queries, proximity queries;
• range queries and more;
• fielded searching;
• date-range searching.

Indexing has near-real-time guarantee on index data availability. This means, that, depending on the system load, indexed data might take up to a few seconds to appear in search results. Under normal load, this delay is not noticeable (well below 1 second).

Indexed data is partitioned in chunks containing fixed length period of data. This provides us with predictability and control of indexing and search performance.

Performance of the query depends only on selected search period and amount of data in that period, not the total amount of data in entire system. For example, if user limits his search to a period of few days, performance will be near-real-time, even if entire SIEM/log management contains years of data stored.

This also reflects on data retention. Total amount of data that can be stored in the system depends on available system resources (disk space and memory) and prolonged data retention periods have minimal impact on system performance. In other words, there are no hard limits on data retention, it entirely depends on available resources and licensing limitations.

Our solution fully supports advanced processing capabilities on all received events - filtering, forwarding, triggering internal scripts or external programs and many others.

Due to architecture of the system, this is one of the areas where SIEM and log management responsibilities overlap. Log management feature of the system is only concerned with indexing all received logs and providing search interface to this data. Any post-processing is actually done by SIEM components.

Different parts of the system can generate notifications and send to notifications engine. The engine will, according to it's configuration, deliver notifications to appropriate recipients using supported channels (e-mail, SMS, voice phone call, …).

Since generation of notifications is separate from delivery, this provides for high level of flexibility. Standard usage scenario example is to send notifications during working hours Operations Team, but outside of working hours, high severity notifications will be delivered to operative on call via SMS.

One additional benefit of Advanced Security Processing Engine solution is it's advanced correlation engine allowing anomalies detection. It is based on statistical modeling of values supplied by correlation scripts for variable time frame lengths, from hourly to yearly. Correlation scripts then perform real time comparison of current to historical values and detect any anomaly.

ASPEN is using its data maps for tracking any suspicious behavior. When any suspicious action is detected, either based on anomaly, policy or threshold violation, it remembers action key users and/or hosts and automatically performs new checks against future events. This allows of recognizing low severity events that

ASPEN is using its data maps for tracking any suspicious behavior. When any suspicious action is detected, either based on anomaly, policy or threshold violation, it remembers action key users and/or hosts and automatically performs new checks against future events. This allows of recognizing low severity events that