All posts by misnomer

Head 2 Head, Security Learning, Security Tools, SIEM, What you need to know?

Evaluating SIEM – What you need to know?

8 Comments

how-to-prepare-for-a-trip-L-HTeG64

We, at Infosecnirvana have published several posts on SIEM. SIEM as a product has created a unique place for itself in the IT Defense in Depth Strategy and has helped several organizations to effectively detect and respond to security threats as well as rapidly achieve compliance needs. Such an important product in the Security space also has a steep price attached to it. The price is not only in dollar terms, but also in ongoing human effort to manage, maintain and generate value out of it. So it becomes paramount that a right choice is made when it comes to SIEM. This blog post aims to give a set of product evaluation criteria or set of questions customers should ask in the evaluation of SIEM. This guide is using a vendor agnostic approach.

Introduction: 

Before selecting a SIEM vendor we need to make sure that the product meets certain selection requirements. Often times, IT organizations have only a vague idea of what is required from a SIEM. They don’t have a solid understanding of the various parameters to be considered in selecting SIEM products. Some of the key requirements to be considered are as follows:

  1. Company & Product
  2. Architecture
  3. Installation & Configuration
  4. Event Collection
  5. Event Storage
  6. User Interface & User Experience
  7. Certifications

Company & Product:

A SIEM product or any other software product for that matter is as good as the company that develops it. This is key because, a company that is stable and has a long term road map focusses better on product development and building expertise. Hence, evaluating the company also becomes important when buying the product. Some of the key items to look for are:

  • Industry Focus, Market presence, Years of experience in the field
  • Financial Performance – Subjective Measurements over the past years
  • Marketplace opinions and reviews about the product and the company as a whole.
  • Do they have customer references for both the product as well as the company?
  • Analyst Reports for the last few years – Gartner, Forrester etcetera.
  • Know the Executive Leadership of the Company. Is the leadership team strong? Is it Trustworthy?
  • Do they have a track record of successful product launches, revisions, development etcetera.
  • Licensing and Pricing models
  • How strong is their product road map?
  • $$$$ spent on R&D for new products VERSUS Development on incremental growth of core product.
  • Is the vision of the product group forward thinking? Are they innovative?
  • How is the Company’s product support and services group? Is it a dedicated team in house or is it outsourced?
  • What are the product support & professional services options available? How focused is the management team in providing Support services? Is support available globally?
  • Is there expertise across the vendors partners (VAR, MSSP, Consulting Organizations) to support both basic and advanced consulting needs? How mature is the partnership or alliance relationship?

Architecture: 

One of the key components of a product is its architecture maturity. The product should be capable of catering to IT Infrastructure needs that vary from industry to industry, from enterprise to enterprise. Some of the key questions related to Architecture are listed below:

  • How flexible is the product deployment architecture? Can it be run as an Appliance, a Software standalone, a virtual appliance/machine or a SaaS?
  • Can the architecture be deployed in a way where individual data storage capability is available per business unit/location?
  • Does the architecture allow for full data replication for HA purposes? Is HA a built-in function or additional equipment is required?
  • Does the architecture allow for interoperability with Network Management devices, System Management devices etcetera.
  • Does the architecture support scalability? Is it modular enough to expand based on growth needs, storage needs and performance needs?
  • Does the product support granular Role based Access control for the underlying hardware & application software?
  • Does it meet the organization’s policy and standards compliance requirements
  • Does the product have a secure data transmission between Event Collection, Event Storage and Event Correlation layers? Does it use encryption? If so, how strong?

Installation & Configuration: 

  • Can the Installation and Initial Configuration be handled by technical staff with minimal training?
  • Ease of set-up, Maturity of Product Documentation and Support to facilitate this effort?
  • Ease of post install maintenance, patching, routine tuning?
  • Ease of patch management of the product including the underlying data architecture.
  • How does the product or solution facilitate asset tracking?
  • From a log collection perspective, who are the supported Vendors, what Products and Versions are supported for integration?
  • How varied and comprehensive is the Data export feature (extract logs, alerts, raw data etcetera.)? Does it support CSV, PDF, HTML, Raw text etcetera?
  • Data Workflow Integration (Bidirectional access to information via external workflow tools?)
  • Email interface for report distribution, ease of customization of the email templates
  • Interface to 3rd party applications (ticketing/workflow application, existing business logging solutions etcetera.)

Event Collection:

  • Does the product have support for both Agent based Collection and Agent-less Collection?
  • For Agent systems, does the solution support Windows, Unix and Linux Platforms, File readers, XML readers, Structured and unstructured data etcetera.
  • For Agent-less, does the solution support Syslog, SNMP, SQL, ODBC/JDBC,  and API collection
  • Is the Agent management function centralized or is it standalone?
  • Does it have any limitations in Input and Output Events Per Sec (EPS)?
  • Does it offer the following capabilities to ensure reliability and flexibility?
    1. Aggregation – Can the Agent aggregate similar information based on custom defined grouping values defined by the System Administrator to cater to the changing Event Collection requirements?
    2. Bandwidth Throttling – Can the Agent prioritize forwarding of events based on defined values such as event priority? Can it send events at a specific bandwidth rate
    3. Filtering – Can the agent provide Include as well as Exclude criteria for filtering?
    4. Caching – Can the agent cache all the events in the event that the Log Store goes down? When forwarding the cache after failure does it intelligently throttle the events?
    5. Fail-over Capabilities – Can the agent send Log events to a different alternate data store when the principal data store is down? Can it do multiple destination forwarding?
    6. Transport Integrity – Can the agent encrypt the log transport to ensure confidentiality? What compression and encryption mechanisms are used?
    7. Health Monitoring – Can the agent send health messages and statistics?
  • For Microsoft Windows Event collection can the agent map the GUID/SUID to local registry/names/references for each event ID in the SYSTEM, SECURITY and all APPLICATION logs on the system?
  • Are Agents that rely on Event Source Vendor API’s to connect and collect information approved and/or certified by that event source Vendor?
  • Can the Agent follow dynamically changing folders and file names? For example in order to support event sources like IIS Web Logs or custom applications that create a log per “site/application” per logging interval?
  • Does the Agent support Database Administrator Logging (From both SQL and System / File Based Sources) for Oracle, MSSQL, MySQL and DB2?
  • Agent parsing and mapping customization. Can the agent’s parsing be modified to assist with custom log messages? Can the normalization or categorization schema be updated to support custom log messages? How is system default functionality affected if these are modified?
  • Can the Agent act as a NTP source for Source Event Logs or otherwise help in time synchronization for source event logs?
  • Time difference adjustment feature (to allow the logging system to cope with devices having inconsistent times)

Event Storage:

  • Does the product allow storage of data locally, remotely in a SAN or NAS?
  • Is the data storage capable of compression? If so what is the rate of compression?
  • Is the storage architecture dependent on standard database or does it use proprietary architecture? If proprietary, does it have all the capabilities to meet storage security requirements?
  • Is Data Archival flexible? If so, is it built-in? What options does the product have?

 User Interface & User Experience:

  • Is the interface user friendly or technical? Is the interface a standalone client console or a web console?
  • How is the performance of the User Interface?
  • Performance when searching for various data elements (IP addresses, usernames, event types, etcetera)
  • Performance when generating reports, query results, data extracts?
  • Will the product function to support the needs of the Tier based SOC Analysts, Incident Handlers, Responders?
  • Can access to data in the system be restricted according to access rights (i.e. business units can see “only their data”)?
  • Can the console present just the events a particular analyst is assigned to handle?
  • Does the interface allow easy access to actionable data? Does the interface organization require a steep learning curve? Can the analyst drive deeper analysis or via tools with a single action (right click and select)?
  • Is the data presented in a manner that makes sense to the analyst?
  • Can analyst understand correlation actions?
  • Can analyst easily change correlation actions?
  • Could the product act as an incident management tool, accepting case notes, and related information on an incident?
  • Does the Solution provide graphical Business reporting using visual aids, graphics, dashboards, template based documents etcetera?
  • How mature is the reporting capability? Matches or exceeds requirements?
  • Ease of development of new reports, customization of existing reports, tuning of generated reports, scheduling reports etcetera.
  • How easy is the accessibility to internal, centralized log sources, in normalized and raw form in case of reporting needs?
  • How customizable is the reporting query?
  • Does it have compliance packages to aid in compliance reporting?
  • Does the product allow users to perform Advanced Analysis – Statistical, Visual, Mathematical, empirical?
  • Does the product support the most difficult use-cases for correlation? (Multi Vendor, Multi-Event, Custom Application and Custom field correlation)
  • Can the system support “live”, “custom”, or “dynamic” threat feeds for live correlation and alerting? Threat Intelligence Feeds such as IP’s, Subnets, Domain, Files, Patterns, etcetera.
  • Does the concept of a “Hot-list” or comparison list exist? Automated Hot-list Trigger. A Hot-list can be a watch list or any other static form of data that can be used as a reference point.
  • Hot-list Updates are manual or automated?Customizable real-time alerting based on specified criteria
  • Distributed search across multiple data stores
  • Functionality to initiate certain actions based on real-time alert (sending email/text message, executing script etcetera)
  • Is the software designed to track user input to understand how users interact with the system? Objective measures of feature use (misuse)? How is this information mined? Are there any Privilege user management content to audit and track privilege access?

Certifications & Training:

  • Training options for the product – Classroom? On-line? Mixed?
  • Certification path and criteria
  • Continuous training options available for new product releases, feature releases etcetera?

Conclusion: Phew!!! That is a long list of things to consider for SIEM evaluation and I still feel that there are many items I am missing from this list. As mentioned at the beginning, this post is a guide to perform SIEM evaluation and should be a great starting point in terms of a check list creation, Tender floatation, proposal requests and the like. Please feel free to add in the comments section or send me an message if you feel any more items need to be added.

Until next time!!! Ciao

Head 2 Head, Installation & Configuration, Log Management, Security Learning, Security Tools, SIEM, What you need to know?

Punching Hard – QRadar Security Intelligence Platform

Gallery 24 Comments

QRadarLogo

Off late, at Infosecnirvana, we have been looking beyond ArcSight Enterprise Security Platform (ESP) to see if there are any other SIEM products that either challenge or match up or exceed the capability of ArcSight ESP. One of the products that has caught our attention in recent times is the IBM acquisition – Q1 Labs offering – QRadar Security Intelligence Platform. IBM completed this buy in 2011 and jump started their Security Systems Division providing a platform to compete against HP who jump started their Enterprise Security Products group with the buying of ArcSight in 2010. Both of them are competing hard in the market place and are vying for the top spot as evidenced in numerous SIEM vendor analysis and reports.

Gartner reports are something that every company looks before investing in a SIEM solution. The interesting thing about QRadar that caught our attention is how consistently it has climbed the ladder of the SIEM Leaders Quadrant. Lets take a look at the last 3 years of the Gartner Magic Q to get an idea of the rapid climb of QRadar against ArcSight.

Picture1

Looking at the graph more closely, even McAfee Nitro and Splunk are catching up in the leaders Q. However, in this post we will concentrate on Q1 Labs QRadar only as they are by and large the biggest threat to ArcSight in terms of technology and capability, not to mention Market share.

First things First:

The QRadar Integrated Security Solutions (QRadar) Platform is an integrated set of products for collecting, analysing, and managing enterprise Security Event information. The various components that are part of this Platform are:

  • QRadar Log Manager – log management solution for Event log collection & storage.
  • QRadar SIEM – Correlation engine
  • QRadar VM – Vulnerability scanner and management tool set available to integrate Event data to Vulnerability data. This provides on demand scans, rescans and vulnerability tracking.
  • QRadar QFlow – Network Behaviour Analysis & Anomaly detection using network flow data. QFlow provides payload information (up to Layer 7) in every detected event which is a great value addition to Netflow data. 
  • QRadar vFlow – Application Layer monitoring for both Physical & Virtual environment.

Key Strengths of QRadar: Few of the things that blew us away when we played around with IBM QRadar was:

  • Easy Setup – It was a breeze to install the product. There are very few or no moving parts in the installation process. The console is also Web based and is a full functional console. From a deployment and operations perspective, this comes across as a super easy, super quick solution to SIEM needs.
  • Value Out of the Box – QRadar comes packed with a lot of content Out of the box to get up and running. The Dashboards are already built for you, more than 1500 reports are waiting for you to just click and run, rules are categorized nicely under various Threat sections and immediately start firing “Offenses” (Correlation rule triggers are called so in IBM world), Network Flow and Packet data are available instantly under the same unified console when triggers are analysed and so on and so forth. We have never seen such quick turnaround times with any other SIEM product in recent times.
  • Completely Replicated Architecture – Full replication is available in the product and can be enabled with a click. This is something which we were really impressed with. In major organisations, this is non-negotiable and such a easy set up really builds up a story.

Key Weakness of the Product: Now being ArcSight users for several years now, this section is something which is right down our alley. Some of the key weakness we saw with the product are:

  • Scale: In spite of all the ease of set up and value Out of the box, when compared against ArcSight, scaling up with multiple tiers is a problem. One of the caveats we see here is that QRadar is an appliance based model. You can have several collector appliances, but to query them you can have only only Manager or Console Appliance. This will severely impact the scalability in a multi-tier set up.
  • Multi-Tenancy: ArcSight has always been best suited for a Managed service implementation with its Customer tagging, zoning and overall multi-tenancy architecture. However, this is a big problem when it comes to QRadar. They don’t have such a capability today. However, we believe their product road map does talk about such features in the future, but we will have to bite our nails in anticipation.
  • Customization: One of the things which propelled ArcSight to land major defence and government contracts was its capability to customize almost everything except the core source code. When creating Content like Use Cases, Rules, Reports, Third party integration etc. this customization capability comes in handy. Such customization & flexibility is seldom seen in any SIEM product out there. QRadar offers some of these customization, but the moment you take it along that route, you will be disappointed on what it lets you do – Read NO API.
  • Workflow: Other impressive thing about ArcSight is its wonderful content management workflow. It has a full blow case management workflow, event handling workflow, Use Cases workflow etc. whereas QRadar falls short as it does not have any such powerful workflow capabilities. Hopefully IBM will address it in future product releases.

Overall Comparison with ArcSight: ArcSight ESP by far has been the oldest and supposedly the most mature SIEM offering in the market but honestly they are losing ground because, they have not been seriously challenged so far. QRadar does that exactly. Based on the key Strengths and Weaknesses of the product, you should have got an idea of where the product stands.

  • Most of the customers would love to get QRadar in their environment just for the ease of set up and Out of the box value. ArcSight is still a pain to set up and generate value. Most of the implementations of ArcSight have failed for the simple reason – Complexity
  • QRadar put a lot of emphasis on Network security based monitoring approach, where as ArcSight takes an Identity based Security monitoring approach. This is an interesting because the Cyber security world is still split about what is key – “Identity based or Network Security based”. In our humble opinion, a mix of both is what really works.

In Conclusion: QRadar definitely is a wonderful product and a worthy competitor to ArcSight as the battle for the top prize plays out. As technology enthusiasts, we are eager to see how the market plays out, but one thing is for sure

“QRadar Security Intelligence Platform is definitely Punching Hard”.

There you have it!!! Let me know what you guys think about these two products and which one do you prefer and why? Comment on below.

Security Investigation Series

Episode 5 – Security Investigation Series – DNS Reflection Attacks

Gallery Leave a comment

One of the most popular attacks in the Internet today is the DNS Reflection Attacks resulting in a Distributed DoS. One of the major DoS mitigation vendors, Prolexic released a Report for 2013 saying that, Distributed DoS Attacks have increased by over 20% and bandwidth utilizations have seen never before levels. Spamhaus, Network Solutions and several other companies this year have been hit by DNS Reflection attacks. The attackers specifically targeted organizations in order to hurt and humiliate them. Distributed DoS protection service providers are slowly gaining prominence. At this time, we at infosecnirvana.com feel that it is important to understand the mechanics of such attacks and how they can be detected and responded from an Enterprise Security standpoint. In this Security Investigation Series post, we talk about the usual suspects – What is DNS Reflection Attack? How do we detect them? & How do we prevent them?.

Understanding DNS Reflection Attacks: As we all know, DNS is one of the components of the internet that serves as a Directory Assistance service akin to the Yellow pages. The only difference is that DNS gives IP numbers when requested for Domain Names. People who understand how DNS Works, would definitely have heard about “Recursive DNS Querying”. Essentially a Recursive Query is like following the trail of bread crumbs till you solve the puzzle. Every DNS Server pushes up the query recursively till it gets the response for the DNS Query. This also essentially means that the Original DNS Query will be very small in size, however, the recursive query/responses will be huge in size. Since DNS uses UDP, Volume based DOS Attacks are possible by using this Recursive Querying capability. This is the basic premise of a DNS Reflection attack. By making several thousands of spoofed DNS queries that result in recursion, an amplified DNS Response can be directed to the spoofed address. To understand the attack pattern that typically a Distributed DoS Attacker would follow, lets list down the attack pattern:

  1. Attacker first compromises an Authoritative Name Server.
  2. Attacker then creates a large TXT RR (Large sized Resource Record).
  3. Attacker Spoofs the Target IP Range
  4. Attacker Sends DNS Query (with Target IP Range As Client IP) to a number of Open DNS Servers (close to 5 million Open DNS Servers allow recursive querying) in such a way that Recursive Query happens and they retrieve the TXT RR.
  5. In order to achieve Amplification, the attacker then uses Several compromised Zombies to send our DNS Requests for the larger resource record (RR).
  6. All the Responses go to the Spoofed IP – Typically the Organisation the attacker wants to flood with DNS responses thereby causing a potential Distributed DOS scenario because of Bandwidth Consumption.
  7. Typical rates of amplification achieved are – For every 100 Mb/s of request Traffic, reply traffic can be up to 10 Gb/s

Imaging several gigabytes of DNS Packets hitting your perimeter and choking the bandwidth. This is what a DNS Amplification Attack or a DNS reflection attack can do.

Detection of DNS Reflection Attacks: Now that we understand the Anatomy of the attack, lets see how we can detect them. DNS Reflection attacks have IP Spoofing as the basic premise to redirect DNS Query Responses to a Target site. However, if the target site was able to detect that it never sent a DNS Query to elicit a DNS response, these attacks can be mitigated or stopped right away. However, detecting this is easier said then done. This can be done using a combination of Network Traffic monitoring, IDS/IPS & SIEM Technologies. Using a Network Monitoring tool like IPTraf, Netwatch,Netramet, we can gather DNS Statistics. Use a custom Script or a custom parser (SIEM parlance), we can normalize the Statistics into a more simpler State table (This is similar to the Firewall State table but mainly for UDP, called a Pseudo-state table). The table should contain a minimum of the following parameters:

  • Transaction ID (This is unique DNS Query ID. The Response received from the Authoritative DNS Server will have the same Transaction ID). 
  • Source IP Address of DNS Query initiator client
  • Source Port of the initiator client
  • Destination Address to which the Query is directed to
  • Destination port the Query is directed to

If there is a Query with a Transaction ID (say 0xcefd) & a corresponding response with the same transaction ID, we can safely say that the DNS Query & Response pair is legitimate. However, if there is only a Query or a Response, they are categorized as an “Orphan entry”. Orphan entries can be two types: 1. Only Query packet seen but no response is seen. & 2. Only Response packet is seen but no query packet is seen. Only Query & no response in my opinion is less harmful and can be safely ignored. But keep in mind, if this number is too high, it means something is wrong with your organizations DNS client or server and could even potential indicate a compromised asset. Only Response & No Query is the most likely candidate for DNS Reflection attacks. However, we need to also keep in mind that for smaller volumes these can lead to false positives as well. Some of the reasons for this is infrastructure logging fidelity (since DNS is UDP), bad routing of outbound traffic etc. In essence, our focus is on DNS Responses without preceding Queries. Now that we know what to look for, we need to start filtering all the remaining noise. This is where Range Thresholds are important. A small volume may not warrant attention, however, if there is an exponential increase in volume, it is really important to take actions aimed at mitigation. This is where an SIEM system comes in handy, Giving you a trend analysis based on the data collected over a time period. Let me just show you how this can be done in ArcSight SIEM. Data from the Traffic monitors can be parsed using a File Reader Custom Parser (using ArcSight Flex Connector). This parser can parse the required data fields as mentioned above from the Network logs and can map them to a native Event field schema. Then we use a Rule to populate all the Queries in an (First) Active list called DNS Query List. Similarly we use a Rule to populate all the Responses in another (Second) Active List called DNS Response List. You can then have a separate rule to populate a Third Active List for Orphan entries. This list will be a count based list giving you how many entries are there without Responses. A monitoring Dashboard can be then created for detecting Trend patterns  due to an increase in the Orphan entry list which would typically indicate a DNS Reflection Attack. I am sure there are couple of other ways we can get this done in ArcSight, but I am not going to go into those details in this post. But basically you should be able to get an idea of how this can be done. As far as other SIEM vendors are concerned, QRadar SIEM has some capabilities to do this, however I don’t think McAfee Nitro & Symantec SIM have this capability (Readers, let me know what you think about these SIEM Tools and whether this logic can be implemented or not).

Mitigation Methods for DNS Reflection Attacks: Once the suspicious list shows an increased percentage of Orphaned Response entries, there is a high likelihood that the organization is targeted. Unless you have partnered with a Distributed  DoS protection service provider, fending off such attacks would be a challenging prospect. However, there are ways and means to mitigate the attack from getting bigger.To start of with, lets look at the perimeter defences and how we can leverage them to mitigate the attack. Organizations generally will have a core router, an IPS/IDS, an Authoritative name server and a firewall.

On the core router we can enable URPF (Unicast Reverse Path Forwarding) to ensure that spoofing based attacks are controlled.

On the IDS side, we can enable rate limiting signatures for DNS packets to detect and probably drop packets thereby limiting the success of DNS Amplification based attacks. We can also enable Geography based filtering to ensure that the attacks remain controlled within a region.

On the DNS server side, we can limit the recursion so that our DNS servers don’t become part of the amplification attack. There are some experimental features in DNS on Rate Limiting on DNS Responses, however it is not commercialized and not many people have this feature tested. There is a great paper on the technical details of this feature. Please visit http://ss.vix.su/~vixie/isc-tn-2012-1.txt to take a look at it.

Finally, if you have money, spend on Distributed DoS protection services from Cloudflare, Imperva, Akamai, Prolexic etc. who can provide you with some of the rate limiting and geo based filtering based protection.

A combination of all these controls will ensure that the attacks are mitigated to a great extent. However, if you bandwidth is choked, you would still face a service disruption and slow website loading, but considering the defences, this would a good start.

What do you think would be your strategy to combat DNS Reflector attacks? Would you do it yourself or would you play with the big boys shelling big bucks? Chime on.

Until then….Detect & Respond.