Tag Archives: Security Strategy

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

Random Thoughts, Security Learning

How good is our current Security Strategy?

Gallery 4 Comments

Few years ago, none of the “Hacktivist Groups” existed or even if they did, they lurked in the underworld. But today, they have the guts to come out in public and declare war on the Internet. They have also been very successful in bringing big corporations loss in terms of data and money. And how much wager would you like to place that this is just the beginning. This begs us to the very question – How good is our current Security Strategy? 

Traditionally we have been building the Security Regime using one or both of the approaches in tandem: Known Bad Security (Blacklisting) and Known Good Security (Whitelisting). To all those signature and behavior based thinkers, don’t fret, for this approach is a superset of Signature and Behavior based approach.

First let us look at Known Bad Security or Blacklisting:
One of the things we are very good at is, “KNOWN BAD” detection and response. By this I mean, we are good at identifying Vulnerabilities based on Vendor releases, patching them once the vendor releases the patches, updating AV/AS, IDS/IPS, Content Filtering etc to protect against exploitation. This is what “KNOWN BAD” Security is all about. You know it is bad and you defend against it. But a recent survey by Verizon shows that only 1% of the total data breaches are identified by IDS/IPS or AV solutions. This is a clear indicator that Signature based detection or Blacklisting based response is not giving us the results. So even though we are very good at Known Bad Security, we are being compromised day in and day out!!!!

Known Good Security or Whitelisting is just the opposite of Known Bad:
By this I mean, we identify and maintain a list of KNOWN GOOD items in our IT Infra. What connections are good, What users are good, What files are good, What is allowed, What is unauthorized etc as our data points for Known Good Security. Based on this data, we identify Security Abnormalities, anomalous pattern detection etc that don’t conform to the Whitelist and go after them as Rogues/Attackers. We investigate them, if found bad follow remediation process for them or if found good add them to the Whitelist. Once we know What is bad, we automate it by feeding to the Blacklist detection and Response. This while being effective is a slow and tedious process thereby giving gracious amounts of time for an attacker to wreak havoc.

Some Good, Some Bad:
Most of the Enterprises today effectively use a combination of Blacklisting and Whitelisting to achieve their Information Security needs. But based on the threats being propagated today, we can say with enough confidence that this approach is failing. The main reason for the failure is that, “Actual Good and Actual Bad are way more than Known Good and Known Bad”. Since we are unable to quantify these numbers scientifically, we end up doing good of nothing.

What we lack?
Our current strategy towards security has some gaping holes. Some of them are listed below:

  • Over Relying on External Sources: We still rely on Vendor input, community input and other public disclosures to define Blacklisting. One vendor’s threat detection efficiency is different from the other. One vendor might rate a Malicious Code as High Severity, but the other may rate it as Low. This kind of disparity does not help in determining what is “Actually bad”.
  • Poor Knowledge of our environment: How many times have you identified a Security incident and while investigating found out something new about the environment. I can bet that it is literally every time. Without knowing the exact nature of our environment, we would not be able to do any effective Whitelisting. Without effective Whitelisting, effective Blacklisting also is impacted
  • One cure for All diseases: We think that if one organization is compromised by a specific exploit, it is applicable to all. We seldom think or evaluate the Controls we have may differ significantly from the controls other organizations have. Security should be tailored to suit not vice-verse.
  • Once we Whitelist something, we never re-evaluate. We perceive that “it is clean” and pay little attention till hell breaks loose. This is more related to human nature than anything else I guess. Once we “move past” we never look back. This will hurt us because, a whitelist today might turn bad tomorrow due to IT dynamics, thereby leading to an exploit.
  • We live by and die by More tools – more security, Latest signatures – more protection, more resources – more coverage, more training – more knowledge. Most organization just buy Security tools or technologies to fill a check box in their Audit/Compliance needs. If the company execs have caught wind of some Security attack that happened at some other company, they are paranoid that it will happen to them as well. Hence “Gimme more security” approach.
  • More the HooHa More Serious the Threat: The amount of publicity received is directly proportional to the severity of the threat. We would have several other threats in our environment, several gaps we need to fix, but we would still look for the famous Conficker, Flame, Stuxnet, Aurora, Zeus etc. Even though some of them were big in terms of spread, every organization had different infection rates.
  • We still think Security as a “Operations function“. We still go by the number of Alerts worked, number of incident raised, time to solve, time to respond etc. Security is more Analytical, investigative field. Looking beyond the noise, finding the needle in the haystack, attacker attribution and all sound cool on paper, but to bring it to reality the current strategy doesn’t help.
  • Security is not a culture. In everyday life, you lock the front door, keep important things in a safe, put on safety gear, wear a seat belt etc, but we don’t treat our IT systems development, implementation and management with a Security mindset. Bad products are developed, bad implementations happen, bad administration and monitoring happen, and finally mistakes from people too happen, leading to a Security breach, data theft and loss.

I am sure there is more than the above list in terms of flaws in our current strategy. What do you think? Please comment on!!!