40 comments

[ 2.8 ms ] story [ 92.8 ms ] thread
Five years ago all the chatter was about private financing being the “new” normal for tech, as it offered closer control with fewer disclosure requirements. Companies like Uber were raising insane amounts of private money while thumbing their nose at public markets.

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?

It's a confluence of all of those factors:

- 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

It seems like a terrible time to put your org's shares into the public market, so late in the business cycle with the eventual downturn looming.

EDIT: Agree that if you must go public, go before the music stops. I'm wrong here.

Surely now is preferable to during the downturn when you'll get half the value for the same percentage of your company? (Assuming of course that you and I are correct that a downturn is looming).
(comment deleted)
You’ll get half the value and it remains stable - versus you get twice the value and then it suddenly nosedives and everyone questions your performance as CEO because “you must have made it happen”.

Is that possible?

Now's the perfect time. We're near the peak, so valuations are very inflated.
Personally I think it's both. We're seeing companies that normally would have gone public (enterprise software like Carbon Black) at the appropriate time, combined with some companies where it makes little sense to go public (Spotify, Snapchat) that I think are cashing in before the bottom drops out.

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...

Spotify was "forced" into IPO in a way: https://www.recode.net/2018/1/3/16847786/spotify-tpg-tencent...

> 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.

Cylance is doing a lot better.
As a carbon black victim who gets angry at CB consuming %50 of my CPU in the kernel as I do builds that touch many small files, it just feels like a combination of corporate spyware/rootkits, traditional antivirus and uploading that info to a backend. Am I wrong?

Why hasn't traditional AV created a similar product then?

I feel your pain. I used to work for Bit9. Some customers found their Java builds slowed down a lot due to all the temporary files created and Bit9 trying to hash them.

From what I understand, AV just tries to match hash signatures. CB is doing more analysis. It's a tougher not to crack.

Carbon Black is far from the only player in the space. Tanium, Crowdstrike, Trusteer, Cylance, Cisco AMP, etc.

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.

Do you feel it’s technically superior or just people following the fancy new tech dragon (or something else like because it also lets you spy on employees, if it does, I don’t know)?

(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).

I do think it's technically superior when used right. Namely, application whitelisting is technically superior. Most employees only have a small number of applications they need to run, and making sure everything else fails to start is the right choice.

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.

Freehunter, grateful for your thoughts on the below in response to your comment about technical staff running esoteric and constantly changing apps and therefore whitelisting isn't always possible.

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.

Sorry, I honestly have no idea. I don't work with endpoint that closely, I'm more on the security architecture side. I have wonderful technical engineers on my projects who are paid to get that in-depth, but that's not me.
I call it the office bathroom camera problem & the creepy sysadmin problem. If employers were forced to be upfront about what they were doing, the equivalent of putting cameras inside each bathroom stall and having no real access control over what admins are doing with that data, people would be creeped out very quick.

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_...

You should read your employee handbook. It's not a ToS and it's not a legalese, they're generally pretty straightforward. Don't use your work machine for anything non work related. Pretend your screen can be seen by everyone at the company (because it probably can).

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.

Not all next-gen endpoint solutions do this. An endpoint application execution control can be much simpler.

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.

"Endpoints are the new front line in the cyber war, and organizations are shifting their defenses as a result" ... what do they mean by 'endpoint' ?
Computer systems end users access web/email with.

I deployed Bit9/Carbon Black a few years ago.

Each node or computing device is an endpoint. Endpoint security is the new industry terminology for antivirus/antimalware/etc.
It's a very old term; endpoint security is in contrast to network security, where you try to block bad things at network boards. Firewalls are the archetypical network defense, antivirus (very unfortunately) the archetypical endpoint defense; osquery would be an example of a modern open-source endpoint security tool.
thoughts on CarbonBlack or Palo Alto’s Traps? Separate category, but what about OKTA?? (I hear they are crushing it)

Do you think what ServiceNow is doing in ITSM is really special?

(comment deleted)
It's often got quite a different focus to antivirus/anitmalware, a lot more about identifying and preventing data exfiltration for example.
(comment deleted)
Endpoints are the machines (desktops, servers, &c) in organizations which have Carbon Black installed. Their client continuously monitors for process executions, network connections, file changes, registry changes, and samples unique files on the machine, and depending on configuration, can upload these contents both within the enterprise and share them with their cloud platform. That's what is meant by "our technology uniquely collects complete, "unfiltered" endpoint data by continuously recording endpoint activity and centrally storing the collected data for advanced analytics".
I deployed Carbon Black, and it seems a nice enough product. But it seems to generate too many programming related false alarms.

Well, they could at least identify when I used ncdu on / and thought it was a crypto-locker, which is nice.

I have heard that if you get Red Canary, they offer a service on top of Carbon Black to give a higher level of intelligence. This will likely help.
As long as Windows machines sit on employee desktops, there will be a compelling need for things like Bit9/Carbon Black. I helped with an enterprise deployment a few years ago and -- except the rule tweaking that required quite a lot of trial and error* -- it works as advertised.

* 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>

Next gen AWL/Endpoint solutions offer a simple and true default deny approach. Either an app (executable, script, dll) is trusted or it isn't. If it is not trusted it can't run - period. 100% successful at preventing zero day attacks and Shattered attacks and even malware that isn't written yet...

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.

Are you assuming no one ever finds zero-day vulnerabilities in "trusted" code? What happens when a piece of code that you trust is compromised in a way you didn't expect?
They're talking about malware, not exploits. It's a habit of the non-technical side of the industry and means 'this hash hasn't been seen before'. Given the phrasing -- "Apps" are "cyber fingerprinted", hashes are "crashed" -- I'd guess the post was written by a marketer or SE.
We are talking about file-based malware that needs to execute.

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.

Exploits don't have to pivot to PE files, and even the exploits that go that route don't have to do it in a way that triggers standard loader hooks (e.g. PsSetLoadImageNotifyRoutine).
To that point, all user submitted content has a new and unseen hash, and could become executable in the face of a zero day in otherwise trusted code that is processing it. This is equally true of web applications and Excel attachments to emails.

People who think the top level poster’s approach to security is sufficient are gravely mistaken.

No claims that it is sufficient - what is does do it prevent any non-trusted file based executable etc from running.

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.

Not at all, zero days are of course found in trusted code. But they are used to inject malware (file based). That malware is not on the trust list and therefore is blocked from executing.

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.