LEM Thoughts of the Week: What IT Security Buzzword Drives You Nuts?

Hit the pavement running     -  Most really don't want to hit pavement to begin with, let alone running.

At the end of the day     - Translation  I have no clue what will happen, or what did happen, or how to make it happen.   But here is where I want everyone to agree.

Circle back     - Usually used to indicate they will contact you again "at the end of the day"

something a prior boss said on a regular basis drove me nuts... "On a go forward basis"

BIG DATA is one of those buzz terms that I find frustrating because without context it doesn't have a lot of meaning yet you see it getting used constantly in the industry.  While the term certainly seems to have gained traction in getting a definition it still doesn't have much meaning without context.  In many of the groups in LinkedIn I see companies trying to sell me solutions for my "Big Data" and I really have no idea what it is they are trying to help me with; that's not to mention the fact it also comes across much to similar to a male enhancement ad.

Big Data....yea right.  Sales people try to keep selling me products to solve my Big Data issue.  Then I tell them how much space I have in the SAN and they walk away.  

I am still dealing with small data.  What about me?

RT

Non-Linear Correlation  

I have had people ask me to show them a concrete example of non-linear correlation in LEM.  This idea is more of a statistical relationship within the dataset rather then creating a 'non-linear' filter rule.

Kind of like Rich Data....this was the key word thrown around when a former employer was trying to implement a CMDB. We had very Rich Data because

references were not normalized across all the data sources.  The vendor couldn't handle it...

Well, what WE mean when we say non-linear is that events can fire a correlation regardless of the order they occur.A lot of correlation engines have an "A, followed by B, followed by C" building blocks approach not an "A and B and C need to happen within a reasonable timeframe of one another" approach. Sometimes events don't come in in order due to different sources (if you're correlating firewall data with OS data, one might be faster than the other). Since rules that correlate multiple events are fairly uncommon in the scope of things (most people still have "small data" problems ) it's not really an every day exercise. It would take many rules to do what 1 rule would do if you really meant the second one and had to build a rule for all the permutations. (OTOH if you really mean the first one, we can do that, too, because the timestamps are a part of the event.)