Carbon Black S-1
sec.gov
sec.gov
Now all of a sudden it seems there’s a new IPO filing every week or so. Does this indicate a stronger economy and/or pressure from shareholders to allow their investments to become more liquid, or are people smelling a downturn around the corner and hoping to cash out before valuations drop?
Carbon Black has nowhere to go but up, they're destroying the AV industry and every security consultant I know is pushing this style of endpoint protection over traditional AV. And they're in the enterprise market, so they can charge big bucks.
Spotify on the other hand is one player in a crowded and competitive market with some huge players who could destroy them in a heartbeat. And even with their exclusives and much bigger subscriber count, they're still struggling to beat much smaller competitors in actual engagement [1] (or at the very least struggling to properly count their streams which seems like a basic requirement). It makes little sense for them to go public when they could just as easily be out of business this time next year.
[1] https://www.theverge.com/2018/4/3/17192342/apple-music-the-w...
Why hasn't traditional AV created a similar product then?
The way these "next-gen" endpoint systems work is by doing a deep analysis of every file, and like you said, uploading the hash to a central server for faster processing later. Your use case is atypical for CB customers but I fully believe you're having these issues. There's a drawback to every kind of endpoint protection. It does seem that the more general population is worse off with traditional malware protection than CB, but your use case seems non-traditional.
I should note that I am not affiliated with any endpoint product and AFAIK the absolutely massive company I work for doesn't even have an endpoint product that competes in the next-gen space. I'm just a security consultant who sees a lot of Fortune 500 companies and notices the trends they set/follow. It's trending away from Symantec and towards Carbon Black/Tanium/Cylance/etc.
(Not that it’s really fancy new tech - checksum AV have been around even since DOS. I’d have thought the best thing would be a combination of the two).
Obviously it's not perfect for everyone and technical staff will often need to run esoteric and constantly-changing applications, so whitelisting isn't always possible. In that case, using a checksum and having the central server is a better way of handling it. Better yet is something like FireEye which can intercept your file downloads and scan them before it hits your machine. I can't speak for which next-gen endpoint solution works best since that's not my area of expertise, but I can say it's better than traditional AV (which is basically useless). In that case, blacklisting is the better choice, for software no one should have installed.
"Spying on employees" is an interesting take on what I consider to be basic security. I'm heavily involved in technology that, if the end user saw what we could see, they'd be horrified. Basically, if you're in the US and using your employer's laptop on your employer's network, you have zero privacy and everything you do and every site you visit is being logged into a central log repository and can be made available to the security and audit teams at a moment's notice. Most of the time no one is watching it, no one except an AI looking for anomalies and reporting on outliers, but it's possible. If you're doing DNS lookups to your company's DNS server, they know every site you've visited. If you're using telnet or ftp or POP3, they know your passwords too, because they're likely sniffing internal network traffic as well and storing packet captures. And they may even be breaking SSL at the proxy or gateway level, so that doesn't help you.
Basically, if you're worried that Carbon Black sending a list of your installed applications is your employer "spying" on you, they're already collecting far more data than you think. Installed applications is the least of your concern. But again... that's not your laptop and it's not your network. It's all owned by your company, and governed by their acceptable use policy in the employee handbook.
Can apply prevention for
PowerShell, bat, java, javascript(node.js), perl, python, php scripts
Default “Trusted Scripts” applies to msi, msu, bat, cmd, ps1, psc1, psm1, vbs, wsf, vbe, ocx, cab, py, pyo, pyw, pl, pm, pls, rb, rbw, js, php files
Any other specified interpreter can be added using an Enhanced Scripts feature
REGSVR32.EXE (2016) without disabling its use “Trusted Script” technology allows IT to continue using REGSVR32.EXE while blocking any untrusted scripts loaded
Dynamically generated scripts (Trusted Children) e.g. Apps that spit out constantly changing .BAT scripts HP Warranty Checker Dell’s KACE Continuum RMM
And any application can be trusted by one click and that trust propagated across the enterprise similar to Active Directory’s inheritance mode.
They might move to employers who aren't that creepy.
I think it's a sexual harassment scandal waiting to happen, and hope things like the laws in Austria is what the rest of the world will adopt eventually:
https://www.taylorwessing.com/globaldatahub/article_austria_...
I will note that most regulations in the US (PCI, SOX, etc) require centralized log management. Unless you're at the smallest of small companies, your employer is doing this. It's a basic requirement.
1. Choose an existing trust list (over 1000 apps/dlls etc trusted) or build your own in a few minutes.
2. Install file filter driver - as soon as driver is installed on endpoint, instant protection, no scanning of drives, folders etc needed.
3. User runs a trusted app - intercepted at kernel, fingerprinted and matched allowed to run. Imperceptible to user.
4. Malware tries to execute - intercepted at kernel, check to see if on trust list, not on trust list - blocked.
5. Need to add a new trusted application? One click, no rules to amend, no whitelists to push to endpoints. All endpoints inherit new app trust and app can execute across global enterprise.
From what I understand, AV just tries to match hash signatures. CB is doing more analysis. It's a tougher not to crack.
> In 2016, TPG, Dragoneer and Goldman Sachs lent Spotify $1 billion via convertible debt financing, which was supposed to give the lenders the ability to eventually turn their loans into equity.
> The deal let Spotify bide its time before an IPO, but not too much time: The longer Spotify took to go public, the better the terms would get for the lenders. News emerged Wednesday that the company had confidentially filed IPO documents in late December.
- Dropbox demonstrated a reasonably strong market for IPOs, so it's definitely safer for other companies to get in before the first flop.
- There's probably a lot of pressure to go public, seeing as how many of these companies have private for more than a decade [1]
- There's also reason to believe we may see pressure in the equity markets in the near future, especially as the Fed adjusts interest rates.
[1] https://www.crunchbase.com/organization/bit9/funding_rounds/... Series A was in 2005
EDIT: Agree that if you must go public, go before the music stops. I'm wrong here.
Is that possible?
Well, they could at least identify when I used ncdu on / and thought it was a crypto-locker, which is nice.
* There wasn't really any "error", per se. It was really just a trial in deciding how much the CIO/CISO was willing to deal with knowing about, versus remaining ignorant by choice since that was far less work. Given where they ended up, I'm not sure whether the millions spent on the software was a smart business decision. <banghead>
Do you think what ServiceNow is doing in ITSM is really special?
I deployed Bit9/Carbon Black a few years ago.
Trusted apps are cyber fingerprinted using 6 hashes - in order to use a Shattered like attack all 6, including file length would need to be simultaneously crashed.
No rules are required, no scanning is needed, instant protection on installation and can be managed/administered by non-technical staff. Can use an out of the box trust list with over 1000 apps already fingerprinted or build own trust list.
Can be deployed using standard tools and is scalable to global enterprise.
It doesn't mean this hash hasn't been seen before, it means that application X which is trusted, is on the trust list (and yes, fingerprinted by 6 hashes) is allowed to run. Application Y which is not on the trust list is blocked from running.
That malware can't get on the trust list (unless by a malicious admin) and therefore can't run.
A zero day exploit that allows the injection of malware onto an endpoint for example, doesn't really matter as the malware can't run. How application Y got there, is irrelevant. It could have come from any attack vector.
People who think the top level poster’s approach to security is sufficient are gravely mistaken.
Doesn't do fileless, memory-based or rootkit but does prevent any untrusted and therefore unknown executable from running.
Does that have value - of course, a true default deny approach.
For example - what turned out to be a zero day exploit was blocked from executing as it was an unknown app. It was an uninstall script that tried to run ever hour and appeared to be part of an AV solution.
9 months later, it was identified as a zero day exploit by 'traditional' AV companies.
Similarly it has blocked SHA1 attacks where for example a previously trusted app has been compromised but even if the SHA1 matches, the other 5 hashes don't and therefore it is not allowed to execute. If any one hash doesn't match - it is blocked.