Galleries

Security Learning, Security Tools, What you need to know?

Security in Developer first organization…

Gallery Leave a comment

Security in an Agile, Developer First organization is a constant ”tug-of-war” between “more security controls vs more developer usability”. The reason for this is primarily the need of Security professionals to maintain control over the “hacky” by nature developers. I am a big fan of Mordoc and the comic strip below shows exactly how this tug-of-war is:

Developers typically use a lot of tools in their machines like:

  1. Build Tools (iOS, Android EMU, IDE, VM, Containers etc.)
  2. Browsers
  3. Repo tools constantly updating
  4. Testing tools.

On such machines, there is always a risk of developers being the target to steal source code or sensitive information. In order to protect these developers, Security teams become overzealous and implement several security tools like Endpoint Security solutions (AV, EDR, HIDS etc.) and Compliance tools (DLP, Web Proxy, Patching, logging etc.).

A typical machine that has all the security tools installed and running looks something like this. This pattern is true across typical enterprise organizations.

The question always is – Where is the balance between Security controls vs Developer productivity?

I gave a talk at a conference on this topic and the slides are available here.  There are various strategies we can employ to secure the developer machines or in general any enterprise computing asset. Some of the innovative ways (they are real and implementable) we can use are described with examples. I thoroughly enjoyed working on this talk and all the associated research that went with it.

 

 

Please leave your comments below. Until next time!!!

SIEM

Is the SIEM dead?

Gallery Leave a comment

change siem technology

It has been several years since SIEM emerged into the Security industry as an “Security Alerting” system. Since then, it has grown into a huge market with several vendors like ArcSight , QRadar, Splunk, Nitro, becoming successful since they were the first movers. Today, in 2020, they are becoming more and more obsolete. While people still buy SIEM for compliance needs, the real question to ask  is “Is the SIEM dead?”

What does a SIEM do?

SIEM by definition does the following:

  1. Log Collection from multiple devices/vendors
  2. Log Parsing and normalization into proprietary formats
  3. Log Aggregation
  4. Log Storage across a variety of data stores
  5. Rules Engine
  6. Management workflows
  7. API Driven Integration

Every vendor does all the above in different ways with varying degree of efficiency. However all the vendors have some common issues as well:

  • Poor Scalability: By definition, SIEM products scale very well in the Log Collection and Aggregation department. However, when it comes to Correlation, the SIEM falls short on Scale. Use case based Correlation rules, Log Filtering, Tuning etc need to be performed with ruthless focus on minimizing the need to scale the Correlation engine. While “on paper” vendors claim their correlation engines can be scaled, however, in practical use and effectiveness they fail.
  • Poor Intelligence: Contrary to popular belief, the Rules engine has no intelligence at all. All out of the box rules are stock compliance driven or basic security best practice driven. The pattern recognition rules are so archaic that seldom do organization detect any malicious attacker in the network using them.
  • Limited scope: Outside of Security operations centers (SOC), there is not much of a scope for SIEM to be relevant and valuable. This is primarily because while they are good at alarm based event management, they are miserable at “Event Searches” and “Reporting” thereby making it less and less attractive outside of the SOC realm.
  • Steep Learning curve: Every SIEM product  suffers from the steep learning curve. The learning curve on “General Use” is comparatively easy however, the “Power Use” and “Admin” is steep. Often times organization rely on a very small set of people (often 1 person) who is an expert on the product to keep this beast of a system up and running.
  • Maintenance Nightmare: The more you scale the SIEM, the more the maintenance needed to keep it up and running. This is especially a huge problem when you have mission critical functions depending on alerting and monitoring from SIEM. The amount of engineering resources burnt on this is significant.
  • Poor Analytics: While the SIEM vendors claim to be “Analytics” providers, what they provide is sub-par. Analytics requires the ability to analyse large volumes of data and run meaningful queries, however, most of the SIEM vendors because of “Poor scalability” , can’t process, store and provide analytical output on large volumes of data. Splunk for sure is an exception on this point as they are an Analytics platform first and a SIEM (poorly) later.
  • Poor ITSM capabilities: Again, SIEM vendors don’t do cases management as well as ITSM tools, thereby relying on 3rd party integrations which often times is a “one-way” integration, meaning cases can be created, but updates cannot be tracked in return.
  • Poor Automation: Reliance on 3rd party automation & response tools makes the SIEM ecosystem even more complex.

There are probably a few more issues depending on the SIEM vendors we see, but in general the above are the most common ones.

So the question is “Is the SIEM dead”??

Let me know in the comments section

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