RSA 2017 Impressions

This year I attended Bsides SF, AGC’s tech summit, a threat sharing group meeting, Google’s security talks and a bit of RSA; along with various coffee’s, dinners and drinks. I presented on eBPF at Bsides as well as at a threat sharing group (APT SIG) and received some great feedback. I also hosted a P2P session on IR in the Public Cloud that was well attended and I thought the discussion went well. The ecosystem of conferences that have sprung up in RSA’s orbit is impressive. While I could not bring myself to get any closer to the expo floor than the overwatch position from the entrance level, I did get to chat with investors, founders, and folks like me on the buy side in more civilized venues around the city. I wanted to take a moment to organize my thoughts and share some of the trends.

Always a good roadmap to the security space from Momentum Partners here.

Artificial Intelligence

AI is the new, ML which is the new Big Data. While there are some very reasonable applications of ML and Big Data to security, calling any of them AI is a big stretch. We asked a couple different VCs about their reaction to companies claiming to solve security problem X with AI. The consensus was that AI was not here yet, it is being worked against really hairy problems in health care and the hard sciences, as well as in applications like computer vision, but not in security. In addition there are maybe half a dozen professors in the world doing credible work on AI, and then next tier is nowhere near them. In general 80% of your detection problems can be solved with a heuristic. You might use ML to come up with new heuristics, but then it is more performant to code those up as a static alert than run a model. Of the remaining 20%, 80% of that can be solved with a linear regression. The remaining cases might need to tune a clustering algorithm for different dimensionality and features, and some folks are getting into the black box world of neural nets with some results… but in general the problems in security remain basic blocking and tackling, for which this stuff is overkill or rather a mismatch.

Endpoint Detection and Response (EDR)

The category formally known as Anti-Virus, and then nextgen AV, is now EDR. There was a touch of drama this week when several vendors sued a testing house over the results. I thought this post was a good summary - testing is hard, both sides are a bit shady. I did see the CEOs from several of the involved companies happily chatting on a panel and was reminded of the immortal words of Omar Little, “It’s all in the game.”

My general feelings on EDR are that third parties should stay out of the kernel. We need the OS vendors to provide stable safe APIs to pull security relevant data and then vendors can focus on shipping that data somewhere and doing useful detection on it. The other advantage of this model is you can correlate events across a broad fleet of devices, rather than making decisions with only local context. This should enhance detection, and blends into a hybrid service model (vs just buying product).

There is definitely a trend to this, CB announced their streaming events model. Windows Events have beefed up the detail they provide, and Microsoft will monitor them for you in various service models. My favorite Linux option is (or will be) eBPF with in house monitoring (but there will be commercial offerings here). OS X has not yet provided this type of telemetry, but does have the old Open BSM module in there. iOS I am not sure will ever provide system level telemetry, but given the locked down sandbox architecture it may not have to. It will need to provide some better information for fleet management though.

So ideally the OS providers handle collection, and the EDR folks move to cloud / managed monitoring models, where they eventually merge with other categories like UBA and what is left of NSM after we encrypt all the comms.

The trend to containers will impact this space on the datacenter side. We need container aware agents and approaches. It is also interesting to ponder what a serverless world looks like from a security monitoring perspective - all you get is logs. There may be some opportunity to enhance serverless code with additional logging code (breakpoints essentially), or see what the cloud providers offer up for performance and security monitoring of your functions. I was sorry to miss this talk on the subject, the slides look great.

Network Security Monitoring (NSM)

A big established category with defined budgets on the buy side, big incumbents and various wouldbe disruptors looking for an angle, however; in my opinion this space is on the decline. As we encrypt more of our communications, even between workloads in the datacenter, the network vantage point will have less and less visibility. Naturally the focus will shift to the endpoint logs and other telemetry. There will always be room for traffic analysis, and it may be useful to double check the endpoint with network visibility, but perhaps that comes from your SDN control plane as just another log source to your orchestrater / SIEM.

User Behavior Analytics (UBA)

A few interesting companies in this space. Hard to tell signal from noise. Many are slapping on the AI sticker this year. I am doubtful that most even have a real story around ML at this stage. The few that I have popped the hood on have not had much (see my paragraph on AI v ML etc), but even with some simple clustering you can get good results, and just having the visibility of what a user does across various services (log sources) is valuable.

I think it is much easier for a company (with engineering) to solve this problem specifically for their uses and technology stack. We know what our users should be up to. We only have to integrate one set of tools. Generalizing the problem is very hard. If vendors have a solid framework to build on that could be valuable, but with existing open source investments (in terms of data pipeline etc) it often makes more sense for tech companies to build rather than buy. I think companies at the lower end of the market will expect this capability from their SaaS providers, so not sure how much market is left for these vendors in between, but likely good acquisition options by SaaS providers.

Security Information and Event Manager (SIEM)

SIEM is a dirty word, but there are several new SIEMs that actually are quite promising. I think this category is an important one. Being able to integrate data from across services is vital to security response (and IT management). Consider a fully cloud focused environment like Netflix: You have multiple SaaS providers holding your corporate data, as well as a product running in one or more IaaS clouds. Within those there are multiple log formats and services generating information. You need to get that normalized and moved into a format that allows easy pivots and data exploration, alerting and appropriate retention.

This is another problem that is easier to solve for one company (one set of integrations) than to generalize. There is a space between what Open Source offers you and what you would expect from a turnkey, and companies that can close that gap for less than an FTE or two add value. One issue is often with pricing models based on data volume. As you get more data into the service it becomes more valuable to you and more sticky, but the costs go up - fast. I would love to see a pricing model that encourages customers to put more data in. Perhaps a flat fee for profit (based on company revenue or size) and a variable cost to cover storage and compute but not gouge the customer. At our scale it is just cheaper to hire the engineers (even at our top of market pay!).

Orchestration

Similar to SIEM, orchestration is an integrations challenge. How do you get the data from varied sources and then build runbooks around enriching that data automatically and presenting the right data to the right person to make the right decision (or can we automate that too)… and then present the right set of response options that are also automated against the tools in your environment.

Most of the companies in this space are built around the example of a spearphishing attack. The orchestrator grabs the email headers, runs them against threat intelligence feeds, pulls the malicious link, follows it and grabs payloads, runs them on virus total and other static analysis, detonates them in Cyphort, aggregates all that information and presents it to a responder, or just cuts a ticket to IT to reimage the box. Maybe follows up by querying the fleet (through and endpoint agent) and NSM appliance for evidence of any of the IOCs it gathered from threat intelligence and analysis of the attack to catch emails that were missed. Very cool stuff, and what our FIDO open source tool does for us.

I would love to see this applied to the data center and public cloud as well. We are investing in tools to enrich alerts from AWS. For example, we might alert on a CloudTrail event, it would be great to have lambda functions kick off and grab metadata on the instance, take a snapshot of disk and analyze it, execute live response scripts through SSM, and bring all that data back to the responder (in Slack or JIRA say). Then present options to terminate, quarantine and/or turn up logging for a period. We will work on these lambas in house, but it might be cheaper to buy them.

Deception

I have always liked this concept. I am still not sure it is relevant to most security organizations. I can see this as a cool hack day project, but I don’t think I would invest core time or cash at this stage… or am I just deceiving you.

Beyond Corp Model

This is the idea of authenticating directly to every service as opposed to coming through a VPN gateway. I think it is the right one. The perimeter is an illusion. Many have tried this before. From IPSEC at the host-to-host level, to Microsoft Direct Access, to several startups in the space. The problem I most often see is a focus on implementing some new enforcement mechanism (firewall, encryption, etc), rather than solving the really hard problem of a policy engine that is manageable.

The other missing piece is a VPN endpoint that can pass along system state. I feel like there is a weekend project here with OSQuery and OpenVPN… but then you still need the policy engine.

I think this ties in with Identity and Access Control. We should be using hardware (Yubi or built in options like Mac/iOS SEP, maybe Intel SGX later) to confirm the device identity, and pair that with biometrics (or password) to confirm the user. There is a lot to build around device enrollment and bootstrapping a user’s identity. Again the focus too often is on the hardware dongle, and not enough on the policy management and implementation.

Post-Quantum

Still waiting. The one RSA talk I went to was the crypto track on post-quantum. Jintai Ding presented a quantum secure key exchange that required a shared password. Quantum has been five years out for ten years now. When it does happen it is going to be a Y2K style scramble to fix, so I am always interested in positioning for that day. Interesting slide Jintai presented, a mathematician in the 1910’s proved there were only three ways to implement Diffie Hellman style key exchange (which was not conceived of until many decades later). This greatly limits the options for post-quantum DH, of course there are other key exchange possibilities.

IoT

I struggle with this one. Consumers simply won’t pay for security (I would love to be proved wrong, but since AV in the early days no one has replicated that profit model). I think IoT aware firewalls are neat, but unless the ISPs buy them to integrate into their modems to save on DoS costs or something, I am not sure who is going to pay outside the security community. There is some interest at the corporate level for building controls etc, and perhaps the solutions start there. Or via regulation, for example of medical devices. Regulation can make some nice profitable monopolies, but those monopolies aren’t much fun to work in. Either way IoT is going to be huge and there are big security challenges, from data privacy, to DDoS (Mirai), to kinetic effects.