Sometimes trying to describe what something is, is harder than describing what it's not. While you can skim the overview, RTFM or try digest some old presentations, they may not be as helpful as just explains what something DOESN'T try to do. Hopefully what you're left with, is the pure problem something is trying to solve, nothing more.. nothing less. Lots of "Threat Management Platforms" these days try to read email, re-invent the RSS reader and implement a very shoddy "ticketing system", CIF... doesn't try to do any of these things. In fact, it ACCELERATES at not doing those things EXTREMELY WELL. If you're NOT looking for a new ticketing system, CIF might be for you. If you're NOT looking for a new way to digest RSS feeds, CIF might be for you!
Where's the UI?
One of the first questions I get, "where's the web interface" ? ... coupled with kind of glazed over blank stare. While in CIFv3, there's a very thin and basic Flask/Bootstrap based UI, it's not documented and almost never really used. "A webUI you say, what problem are you trying to solve with that?". This usually leads to more blank stares and eventually folks wandering off to something a little more shiny and targeted towards the actual problem THEY want to solve (eg: wasting human cycles on things that we can easily automate). In the early stages, we actually considered the lack of UI a 'soft spot' and it stayed on the todo list- .. for years. After a while (and a few rounds of blank stares) a surprising thing happened, I actually started thinking of this as A FEATURE.
In the world of open-source, you have a lot of great ideas, and very few people willing to pay for them. A lot of your time is chewed up by kids who haven't yet been introduced to the magic of google, or those too lazy to read some of the code (however poorly written it may be). Snapping off a quick email, or logging a ticket is easy enough, and if you're like me and enjoy teaching, you're suckered right into doing some of the legwork for them. It's a labor of love, that's why we get into this in the first place, but it also has the potential to chew up a lot of your time. So you make a choice, you could spend all your hours trying to make something nice and shiny.. or teach... but hardly ever both (and be successful). What's the happy medium? Spend your cycles on the API and bet that others will use that to build LOTS OF GREAT UIs, or .. better yet.. people will figure out that the problem they were trying to solve was integration, not YetAnotherWebInterfaceTab.
Those that don't figure this out (eg: integration, not another cruddy web experience) move onto other projects and stop wasting your time. What you built isn't what they probably wanted anyway and by directing them off your project and onto someone else sooner, probably saves both you and them a bit of time and frustration. CIF doesn't try to compete with the MISPs of the world, to us, MISP is just another Bro, which is just another Snort, which is just another feed consumer. How can normalize the feeds so your platform can consume them faster, whether it's getting that data in front of an analyst or a network sensor, we don't care. We just want to be the fastest at it. People who want to move millions of indicators a day, use CIF. Those that don't, use something ... more shiny.
Where's the FaceBag?
If i watch another sales pitch about someone who's re-invented the wiki, the social graph or the face-bag by helping you share your indicators with your friends, I may kick, something small and cuddly. In order to share data with my friends, I have to give you my personal information, my indicators and possibly pay you for the privilege? Not to mention who the hell knows how many "upsell" phone calls i'll get once I give you that information. Nor how if I use your system, how i'm now under some form of NDA and my data is vendor locked until you sell it to some large valley company on your exit. That's ... bullshit. You're probably just re-selling my data without telling me anyway, cause let's face it, that's the age old model that seems to work.
There are two types of data sharing in the world today, platforms and marketplaces where we build APIs and marketplaces and automate the hell out of things, or the facebag. Where at some point, you just start ignoring data because it's not setup for that. It's setup to get you to share your data, so at scale- the vendor can aggregate it and make it more useful. You may get away with doing 10 or 15 indicators a day with your 'friends', but you're not doing millions, and that seems like what everyone is counting on. I can lock you in with "the shiny", aggregate across all of you, without any of you getting any kind of real hard-core "defend the network" value from it.
I'm not picking on any single or specific vendor, this is all just speculation. I have really no idea what any of them do with that kind of system (for the life of me I can't figure out WHY they built the things they did), but when you start thinking through the problem of scaling information sharing (and i mean REALLY scaling it, millions and billions of indicators per day), their models just don't make sense. It's almost like they're trying to re-engineer the good old aggregation advertising model. They bought a bunch of jr programmers who don't know any better, and 10 years later.. here we are. Same horse and buggy that gets a top speed of ... 10 mph.
Where's the ticketing system?
Stop. Seriously, just stop this nonsense. If you find a platform that "also does ticketing"; run, don't walk. No single product does everything well, the good ones do ONE THING really well, and have amazingly great API's and web-hooks for you to integrate with your ticketing system. Products that perform poorly try to do all-the-things well, and end up spending no time on the thing they set out to solve. Would you buy a boat that also runs as a car? I mean, I know they're out there- but ... bolting a ticketing system onto a threat intel platform is just as absurd. Not to mention, it raises your costs which makes you less competitive and loses you potential customers because they ALREADY HAVE TICKETING SYSTEMS SO YOURS IS JUST EXTRA BLOAT. You spend less time focusing on making your system faster and more integrated with existing technologies, so you start out at a disadvantage.
Where's the news?
I cannot, for the life of me understand why someone actually had a meeting and said "we should totally put news in the platform, yea that's a GREAT IDEA". Your product can in no way, shape or form keep with the advancements of news.google.com or google alerts. If you're focusing your IR on the news, you're doing IR wrong. It's like trying to trade on the news, once the news is out- the event already happened. In options trading, we trade the probabilities of what the data is telling us, if you're relying on the news for insight- you're looking at the wrong data sources. News is usually distracting, misguided and just plain uninformed. This is as true for security as it is for the financial markets.
Think about it, you have journo's with little or no experience in the security space, writing about things they are not informed about, usually days, weeks or months after the fact. If you want updated context on what's going on around your network, it's simple. Slackify your analysts and watch that stream of data. Hook it into your threat platform such that- when they're talking about an indicator, the platform DM's them with some information and vs versa. Make your stream of news, relevant to your environment.
Why can't I pivot?
What we've come to discover, there are 2-3 types of 'information sharing' tools. There definitely is a need for analyst to 'connect the dots', none of this ... rant should be construed that there isn't. How else would get gather intel that goes into feeds and continues the cycle? What i've learned is, many people (especially the analysts who give me the blank stares) confuse this space, in that, every platform should do both. You should be able to process threat intel at the high speeds AND make a UI that lets them pivot through the data.
No. Again, just no. Not only are these two different concepts, the technical requirements are such that you basically need two different types of underlying infrastructures to pull this off. One is heavily graph based, one is heavily time-series based and no matter how much people may suggest "Graph can do time-series"; they are lying to you.. or they have ba-jillions of dollars for hardware.. or both. However, much like the ticketing system discussion, build a great API into the data, treat it like an operating system for the graph, you open your platform up to many different pivoting products.
The problem is, most analyst tools confuse this even more by bolting network delivery of indicators on as an afterthought. They mis-understand how you'd use the indicators, why you'd maybe want to whitelist a few of them, why you might want to aggregate them and that you should be building simple clients your users will understand. They tend to suggest "we support open standard X or Y", but leave all the heavy lifting to the end user. They don't build these tools from the network up- with a fundamental understanding of how this data is used, they build them from the top down with the understanding that ... "oh, shiny!" and "of course we should start with a ticketing system! how else would you correlate this data!".
Where's the Data Enrichment?
This is odd- because analyst think "enrichment" means "can I at-least see if the echo chamber around me signals that this thing is odd". Traditionally this has also meant- can I find this data in enough other sources, that I can feel confident in my assessment. The reality is, while this helps weed out *some* obvious false positives, very few systems actually focus on any kind of probabilistic automation, which means analysts get bogged down rabbit hole after rabbit hole thinking they're making informed choices about the data, with little or no sense of probabilistic outcome. Furthermore, most systems are designed to encourage this and help the analyst form a semi-non repeatable process based on "gut feel" and some hap-hazard "if then else" statements they can't really articulate to others well. So, when they leave, so does the "enrichment process".
It's not a bad thing- it's probably the best we have at the moment, one of the reasons the only "enrichment" CIF tries to do is break indicators up into different parts (eg: URLs into FQDNs, FQDNs into IPs, and so on). It then presents some context around that data so practitioners are free to enrich the bleepity-bleep .. out of it. In the future- scale though comes from understanding the context around the indicator and assigning some kind of probability model to it, rather than giving analysts actual access to "enriched data". To scale and be successful, this process needs to be automated, repeatable AND most importantly, measurable. Today, it is mostly none of those things. Entire sales forces are dedicated to sell products that help you "enrich your data", but at human scale- not web-scale.
WebScale?
A great man once said:
“You make a racing car faster by removing weight, not by adding power. You can make your community lighter, faster, and more agile by being dogmatically minimalist about the work you do. Though it sounds lazy, it’s often harder to not do something that seems fun than to just go ahead and do it.”
You'd think this would be obvious to most, but from experience (my own mistakes included) it's not. CIFv0, v1, v2 all suffered from this. We (I) listened to too many of the wrong groups of people without a clear understanding of the problem we set out to solve. I thought it had to do everything, and (mis)spent years trying to make that happen. The speed and performance came when I started saying no to things and focusing on the thing that makes CIF fast, it's simplicity. The goal is to a few things really well consume threat intel extremely fast, scale in a way that, you're just adding boxes to handle the load, provide an easy to use API so you can deliver that normalized threat intel to your network, ticketing system or chatroom and GTFO of your way. Nothing more, nothing less.
There's a reason CIF and CSIRTG are completely separate products focused on completely separate problem spaces. For a lot of the same reasons, that's also why you can't read the news or pivot on either platform. We're focused on building better exchanges and highly embeddable platforms for you to BUILD on. You may already be using CIF behind the scenes, and not even realize it. That's the point. We're making a faster race-car, not a better boat-car... or car-boat... whatever that fugly looking thing is.
Run Faster.
