Category Archives: Security Investigation Series

Articles in this category are Lecture series that talk about various Security Investigation Process/Methodology for the various types of Security Incidents and Events identified.

Security Investigation Series

Accelops – An innovative take on Monitoring

Leave a comment

AccelOps-LOGO-Grey-Blue

AccelOps – An innovation take on Monitoring

We at Infosecnirvana.com have done several posts on SIEM. One of the most common request from readers of our SIEM posts is to review Accelops. So this post is our answer to those repeated questions.

Introduction: 

How many of you remember Cisco MARS? Well, if you don’t, let me remind you that they were one of the earliest SIEM products around that stemmed from the infrastructure monitoring space. MARS was geared more towards monitoring and reviewing network infrastructure including their utilisation, performance availability and logs. After a brief run in enterprises that were Cisco heavy, the product died a natural death. People who were involved in the product left Cisco and started AccelOps (Accelerate Operations). As a product, they took the fundamentals of data collection and integrated infrastructure log, event monitoring to the data analytics platform. The result is a promising product called AccelOps.

They have since been acquired by Fortinet, marking their foray into the larger Enterprise SIEM market dominated by the likes of HP, IBM, Splunk etc.

AccelOps:

As you can guess, by virtue of collecting data from various sources like Network devices and servers, AccelOps is a product that provides fully integrated SIEM, file integrity monitoring (FIM), configuration management database (CMDB), and availability and performance monitoring (APM) capabilities in a single platform.

  • APM Capability: This is their strong suite and it is MARS on steroids. AccelOps excels in capturing statistics to provide insights into how the system health is. This is value in a MSSP/NOC/SOC setup as there is no need for an additional monitoring platform. Again, Syslog or SNMP are your best bets for APM.
  • File Integrity Monitoring: Very few SIEM products (think Alienvault) offer native FIM capabilities and to see it in AccelOps is refreshing. The way they do is no surprise as FIM can only be done effectively using an Agent-based approach and Accelops also does the same.
  • CMDB: Accelops has the capability to keep track of all the elements in an organisation’s network infrastructure like network devices, UPS, servers, storage, hyper-visors, and applications. Using the data, a Centralised Management Database (CMDB) is available in AccelOps. This again is very unique and even AlienVault with all its Unified SIEM branding, does not shine as much as AccelOps does.
  • SIEM: Now that all the data from various network infrastructure is available in AccelOps along with CMDB, the ability to cross-correlates, in real-time becomes easy and AccelOps does that using its own patented correlation engine. The SIEM capability comes with all the bells and whistles one would expect – Rules, Dashboards, Alerting, Analytics, Intelligence, etc.

Now let us look at the Strengths and Weakness of AccelOps as a product

The Good:

  • AccelOps’ combination of SIEM, FIM and APM capabilities in a single box helps in a Centralised operations as well as security monitoring.
  • AccelOps serves as a centralised data aggregation platform for system health data, network flow data as well as event log data.
  • AccelOps has a mature integration capability with traditional incident management and workflow tools like ServiceNow, ConnectWise, LanDesk and RemedyForce
  • From a deployment flexibility, AccelOps excels in virtualisation environments. However, they are also available in traditional form factors. If customers prefer cloud, they are also available for deployments in either public, private or hybrid clouds.
  • From an architecture perspective, they have 3 layered tiers.
    1. The Collector tier does exactly what the name suggests – collects data from end log sources.
    2. The Analytics tier receives data from the collector tier. This analytics tier is built on big data architecture fundamentals supporting a master/slave setup. In AccelOps terms, it is Supervisor/Worker setup.
    3. The Storage tier then serves as the data sink housing the CMDB and the big data file system.
  • Because of the architecture setup, the scalability is not an issue with AccelOps. It does scale well with clustering at Analytics and Storage tiers.

The Not So Good:

  • The most obvious is that AccelOps as a product has relatively low visibility in the market. However, this is bound to change with the Fortinet buy. They will hopefully be seen in more competitive bids and evaluations.
  • While AccelOps tries to be a “Jack of All”, it unfortunately is a master of none. This means that the product has poor support for some third-party security technologies, such as data loss prevention (DLP), application security testing, network forensics and deep packet inspection (DPI).  This hinders the product versatility in large environments.
  • Parsing is a key aspect of SIEM and in this area too AccelOps lacks extensive coverage as seen amongst competition. While most of the popular ones are parsed out of the box, the others require a custom parser development skills, which unfortunately requires steep learning curve or product support to help build.
  • While for Network engineers and analysts, the interface makes sense, from a SIEM view, the usability could definitely be improved. This issue is evident when looking at dashboards, report engines, alerts etc. which seem to be afflicted with information overdose.
  • Ease of deployment is there, however, the configuration takes a lot of time considering the fact that there are several tool integrations to be done before it can generate value. Some of the configurations are really complex and may lead to user or admin being spooked. We were reminded of the MARS days time and again while evaluating this product.
  • The UI, while presents data in a very informative way, suffers from too much clutter hindering usability. While this is a personal opinion, when compared against the likes of IBM, Splunk and even LogRhythm, the AccelOps UI does not excite. We hope that Fortinet brings to fore its UI maturity to AccelOps, thereby becoming much more savvy.
  • Correlation capabilities are very good when it comes to data visibility, compliance and infrastructure monitoring use cases. However, when it comes to Threat hunting, trend analysis, behaviour profiling, AccelOps has a lot of ground to cover.
  • Without Infrastructure data, AccelOps loses its edge. As a traditional SIEM collecting only Event logs makes it look like a pretty basic SIEM. This can be quite an issue in organisations where Infrastructure monitoring is already being done by other tools. Unless customers duplicate data sets across  the tools, the value is poor.

Conclusion:

All in All, the product is a well rounded performer when it comes to combined Infrastructure and Security monitoring, however in traditional SIEM bake-offs, they need a lot more flavour to make it exciting. Hopefully the Fortinet buy will do just that. We will continue to watch out for this product and its road map in coming months.

Until next time – Ciao!!!

Security Investigation Series

CSIRT Series – Introduction

6 Comments

Incident Response is a key component of any organization serious about Cyber Security. However, many organizations are faced with the challenge of building and maintaining an “efficient” IR function or CSIRT. In our definition, an IR function is a perfect amalgamation of three major things – Well defined Process, Qualified People and appropriate tools & technologies. At InfosecNirvana, we have posted several things related to SIEM, Security Investigation and Log Management, however we have not spent considerable time in the IR side of things.  This blog post aims to introduce you to our take on how an IR function should be.

Our IR Framework:

There are several IR frameworks in the internet, the most popular ones are the NIST framework and the SANS framework. Though the approaches are similar they are different in practice. Hence, we have tried to build a very generic framework that can be used by all the organizations that want to set up a IR function. The framework is as below:

The IR framework depicted here consists of 6 major functions. They are as follows:

  1. Incident Detection: – You can only respond to what you can see.
  2. Incident Classification: – Know where you are going, what you are dealing with.
  3. Incident Handling: – Handle with care
  4. Incident Containment:- Stop the bleeding
  5. Incident Recovery: – Get it back up and running
  6. Continuous Improvement: – Never stop learning and improving

Each of these functions listed above have a heady mix of Process, People and Technology. Several organizations have varied definitions for each of these function, but in this post, we are trying to make them as generic and all-encompassing as possible. Since a single post does not do justice to the readers, we have decided to split this into several sections for easy access and readability. Below are the links that explore each of these functions in detail. Feel free to comment in these individual sections so that discussions stay on topic.

Until next time… CIAO!!!!

Security Investigation Series

Part 1 – Incident Detection

Gallery Leave a comment

Introduction

As we always say at Infosecnirvana, “Every Attacker leaves behind a trail”. Identifying the trail in an organization’s infrastructure is the main goal of Incident Detection and this is where all the cutting edge technology, talented people and mature processes come together. From Perimeter protection devices like Firewalls (Both Network & Application), IDS/IPS, Breach Detection Systems (FireEye, Fidelis, etc.), to Endpoint Protection Systems like AV-AS, HIDS, there are a host of security management systems that help to detect potential Security incidents needing action. Even Physical Security systems, Industrial control systems, etc. can be detecting Incidents. Never before has incident detection been important than today and it comes as little surprise when organizations globally want to look at Incident Detection as an important tenet in their security posture. But before embarking on an Incident detection journey, it is important to understand the basics of Incident detection and how it forms the foundations of CSIRT functions world over. So let us start with the introduction.

Security Events are not Security Incidents:  Confused??? Don’t be. Yes, Security events are not Security incidents. Both are different and here’s Why? Security products and technologies generate several actionable items. Helpdesk, Consumers, Business, Audit and compliance and even a Security guard reports Security issues. All these together are “Security Events”. However, not all of these events are fit enough to become Security Incidents. The Events have to be carefully validated for Relevance, Authenticity, Impact and Urgency. Only after this initial validation does an event qualify as a Security incident worth investigating. In short “A Security Incident is a Qualified Security Event”. If a team where to focus on every single Security event as a Security Incident, it will be an Operational nightmare. Hence it is important to perform Event Management or Event Handling.

Event Management: Every organization should have an effective Event Management process. The Event management philosophy should be “Many inputs (Event Reporting) but One Output (Incident)”. At a broad level there are 2 major Input sources to a Central Event Management system. They are described below:

  • Automated Event Reporting: Most of the Security tools and technologies today generate several Security events daily. However, it is always difficult to individually handle these events when there are several point products in the market today. But, with the advent of SIEM, gathering, correlating and real-time alerting of these Security events is now possible. In SIEM parlance, this is done using “Use Cases”. Years back, we published a post on “Use Case Development Framework for SIEM” which went in enough details on how to build Use Cases on SIEM. This Automated Event reporting thus becomes the most important input into the Central Event Management function.
  • Manual Event Reporting: Anyone from the Business, Legal, Consumers, End Users etc. can report potential Security events to an organization. Generally, most of the organizations have a IT Helpdesk as the central reporting desk for such issues. The reporting is typically done through and email system or through a phone call. Several organizations have an online self help ticketing system to report such events too. However, these have to be handled manually.

Event Qualification:

Once the events are reported automatically or manually, the next step is Event Qualification. Before making a determination whether the event is an Security Incident or not, a few deterministic questions need to be answered. Some of those are listed below:

  • Date – Date of event discovery
  • Time – Time of event discovery
  • Time Zone – Time zone of the event source is critical when systems or businesses are geographically dispersed
  • How was the event discovered?
  • What is the impact of this event and what locations are impacted?
  • Is the event ongoing?
  • Event Reporter contact information?
  • Type of data or systems affected (if available)

Based on the responses, an initial determination can be made about the nature of the event. If this event is a Non-Security related event, they it can be routed to the respective teams for further investigation and resolution. If the event is indeed a Security related, it is raised to the Incident Detection & Response team or the CSIRT team as a Security Incident for further investigation and response.

After generating a Incident…

Once an Incident is generated from Event/Events, it has to be classified and categorized. This is the main function of Incident Classification function.

Go back or Continue reading Part 2 – Incident Classification