Late last week, Chris Sanders (@chrissanders88), a former FireEye colleague, posted an interesting "lunchtime poll":
See the full Twitter thread here or click on the tweet image above.
While this is a great thought exercise, "Security Twitter" (myself included) couldn't help but interject practical reality considerations into the conversation. After observing some discussion, I felt that there were some takeaways to discuss at a later point in time which I shared in the thread:
I'd like to have some of that further discussion on those points now. These are all with my current biases, so your experience may diverge a little, or greatly.
At Uptycs, we see the first debate around build or buy all of the time. It's often why customers (from security teams of 1 to upwards of 20+) come to us -- they began pursuing osquery because it is open-source, and really easy to do an initial trial on a laptop and see how flexible and functional it is. Therefore, a lot of people perceive it as a "low cost" solution to their problems, and dig in on trying to do something with it.
Don't get me wrong, in many ways, feature for feature, osquery-based solutions are often far cheaper than aggregating several commercial solutions that do similar things. But “Building” can have a hidden resource cost that counters the saving of $$$. The entity who tried out osquery works with it enough to see how immensely powerful it can be when deployed at scale -- but then they find that they still didn't have the in house technical know-how to move at the velocity that they want to to achieve that scale. Without that, osquery doesn't really deliver the value that they need so they pivot back to “Buy.”
This probably deserves a graphic, but that's not my forte, so, here's how I see this breaking down:
Little to no $$, Little to no Staffing -- you take what you can get -- things are done by staff as they can, and velocity is slow.
Little to no $$, Good Staffing -- here you definitely build. You have invested in the people, and don't have a commercial option due to lack of budget.
Good $$, Little to no Staffing -- many emerging companies are in this boat. And it's not that they have "no staffing", it's that there is no capacity remaining with the staff you have, and there is really no _additional_ staffing to address standing up a new system or project. This is often a great case to "buy" -- but you want to buy something that is going to add value to your staff without that limited resource having to do much additional work. This is our sweet spot, as osquery without a structured solution is a cool tool, but requires a lot of human resources to add value.
Good $$, Good Staffing -- these entities are the lucky few. They can do what they want. However, there are many cases where organizations like this will _still_ choose to buy. Talented staff are still the rarest resources, and you want to save them for the problems where there are _NO_ commercial solutions.
This seems like it would make a good quadrant chart - but really, we have to keep in mind that there would be a skew -- Humans are _always_ going to be the limiting reagent in information security (well, for the foreseeable future), so things are always going to be titled in favor of spending $$ if that is an option.
"Humans are _always_ going to be the limiting reagent in information security" - @dallendoug
I felt that a later comment in this discussion reinforced some of my ideas -- least operational overhead to me is what is going to be least taxing on your people resources, even if you have to spend a few bucks.
And if buy or build is a budgeting question and there's no strong opinions (or conflicting opinions) on staff, find the option with the least operational overhead. SaaS wins.
This is why we have focused on SaaS as our primary delivery mechanism at Uptycs -- if we are spending the resources making osquery scale and deliver value so that you don't have to, it makes sense that you want to optimize the value that you are getting from us by not having to run infrastructure on top of your investment. Now, this is not the case for all organizations (larger organizations or those with stricter requirements often don't trust SaaS in the cloud, ironically even if the company in question is itself a cloud provider), but for those who are in the value quadrant of a bit of money to spend but no spare cycles on the staffing front, SaaS is a logical choice.
Going back to the second question -- "do you buy tech to your staff? or do you staff to the tech you want to have?" I too feel that you want to buy tech to your staff, because humans are always the rarest commodity in the tech arena. However, you don't always find solutions that have the exact custom set of technology that your staff has on hand, _especially_ if you are buying something off the shelf. This is another place where osquery shines -- because despite your staff's area of specialization, odds are pretty good that most of them have run across SQL at some point in their careers and they can figure out basic SQL or leverage SQL tutorials.
Additionally, the flexibility of osquery to accept extensions in more than one language opens up it's accessibility as well. So, most shops are not going to have the staff that could have coded osquery from the ground up, but when trying to use or extend an osquery system, that becomes a lot more accessible to the skills that are in a lot of IT operations or security shops, even at smaller companies.
Obviously this is all biased from my point of view, but I'd love to hear other folks weigh in with their experiences. Feel free to drop me a line at @dallendoug on Twitter, and I will post this there to continue the discussion.
Related osquery resources: