Caitlin Marco
By Caitlin Marco
Posted On June 07, 2018

tCell CEO Michael Feiertag Talks the State of AppSec on The Five Nines of Downtime

Application Security | DevSecOps | Next Gen Cloud WAF

Michael Feiertag, CEO & Co-Founder at tCell, stops by to discuss the difficulties enterprises face around security in their cloud-based development projects. 

Listen now on SoundCloud or read the interview transcript


Alex: Today's guest is Michael Feiertag, co-founder of tCell. Welcome, Michael

Michael: Thanks, thanks for having me.

Alex: So why don't you tell us about tCell?

Michael: Sure. We're a start up based in San Francisco and we've got a service for any company building or deploying software, web apps or API services, and our job is to make sure our customers don't get hacked by outsiders.

We're particularly focused on the teams and companies who are trying to adopt newer approacher of building software, whether they are adopting cloud services, or trying to get DevOps working. They're trying to figure out how to make security fit into that environment where they are innovating very quickly and security teams are falling behind. That's where tCell comes in. We help security teams catch up and get ahead the game as new software gets shipped out. We make sure their software is secure, we tell them if they're being attacked, who's attacking, how they're doing it and we help shut down the attacker.


Alex: So, bringing web app security into the application layer, with the speed of innovation that happens there, how are you able to keep up with the demands of the DevOps/ Agile environment?


Michael: Good question. So there's a couple of answers to that. Starting with the basic philosophy. My background before starting tCell with Boris, was in running product management for Okta and Blue Coat systems. At Blue Coat we had security tools for our customer's that told their teams how to stop doing things. We had a box that would limit access to the internet and it essentially became a control point to limit access to only business appropriate things, and that was one of the principal functions.

With tCell, we have a very different approach to our security philosophy that we build the product around. Instead of giving a control point that helps security people stop things from happening, it's a control point that opens things up to make things happen quicker.

From a technology perceptive, we've done something different from a blocking device. We have a little bit of software backed by a cloud service that we give our customers. It's a little agent that gets dropped onto any part of the app that needs to be protected. Could be dropped on the proxy layer, tomcat, nginx, IIS ect, or could be dropped on the software itself on the language layer, java, python, ruby, .net, ect. Basically, the agents will hook into the running application and gives visibility into your users interacting with the application. We'll see the traffic coming to the application, but we'll also see the app start to execute. We'll see it sending queries to the databases, accessing the operating system, we'll see what happens inside the browser as it execute. So it gives the security person a clear view into how the app normally operates and a clear view into anything that it shouldn't do: running bad scripts, sending weird commands to the operating system, pulling bad content from a 3rd party location, [ect].

You can do all this without calling a meeting or adding a process to the release cycle, or anything that would slow down shipping software. It gives you visibility about how the application is behaving normally or abnormally without requiring developers or operations people from collecting that information for you and stop what they're doing to give you that information to you.

If you were to find something that shouldn't be there, you can then implement controls into the application to stop that from happening without requiring developers or operations to do it for you.


Alex: Interesting, it seems like coming out of Okta, you could have gone anywhere you wanted, why was this such an enticing space to move into? Was there really such a huge need here?


Michael: Oh, it's critical. If you think about it, basically every company is building and deploying software. It's not just the tech companies anymore. Everyone is trying to build and deploy software and they're trying to do it faster and faster because their competitors are. Anyone that can innovate faster with software tends to win. There's been huge innovation in the building of software, but what Boris and I saw was that everyone was getting better and better and building software faster, but worse and worse at securing that software. The real need from the market in order to take true advantage of all these new tools available was not a way to better build a dev or production environment, it was how to do that in a way that's secure so that you don't have this artificial break to innovation that's caused by legacy security tools.

It is the problem to unlocking your ability to move quickly with software.


Alex: One of the traditional problems that I've seen with the static code analysis market was that the budget for security was on the operational side of the house not the development side of the house. How do you see this coming down into a budget?


Michael: That's a good question. Because we're focused on protecting the production environment, we fall into the security operations budget which makes life a little easier for us. We've also seen the traditional stack of where people are spending their budget dollars on production security or operational security, is shifting quite dramatically. If you were to go back 5 years and talk to a CISO about where they are spending their money, it would generally mirror what the CIO bragged about spending their money on. 

The CIO used to brag about how they've got the biggest CISCO network in the world, they're Dell's second biggest customer, and the lines of business would sell some software on the side. The CISO would mirror that and say I've got the best firewalls in the world, I'm on Palo Alto's Customer Advisory Board, I've got cutting edge end-point protection, and I've got some application security with a web app firewall as kind of a side show.

These days, starting with the CIO, no one brags about the network they've got. They brag about how little of a network they've got an how dynamic they made their servers. They're all moving to public cloud. What they're really going to brag about is how many developers they have and how much software they're cranking out to support their business.

The CISO isn't bragging about what network security they've got, they're starting to brag about what cloud security they have in place. More importantly, they've got protections for the software that's in place. They're building out the best production application security programs in the world.

The budgets are staying in that production world, but the pyramid is shifting from the low-level infrastructure emphasis to a dynamic, cloud infrastructure emphasis.


Alex: Interesting, it is a major shift. It's funny that you point out the "we're Dell's biggest customer" as a major bragging point.


Michael: Yeah, now it's embarrassing if you say that.


Alex: It's a major shift. I don't think anyone could have predicted that 10-20 years ago. I’m wondering what's the future of the market then? Where's this all going? Web Application Firewalls have been around for a while now so what's the future of this market?

Yeah, so it's a good question. The reality is security markets tend to follow underlying infrastructure markets. So, in this case, what's happening is that customers are looking for security solutions that will fit correctly into their new world which is both an infrastructure thing {public cloud} and operational, social thing - DevOps. The future of the market ends up being; what is the right way to solve these problems; am I under attack, is the attack successful, what do I do about it at the application layer, how do I solve that in a new way that works best and leverages the new tools that are available rather than the old proxy techniques of the web app firewall.

So, what you'll see is it might be called the WAF market, might be called the Next Gen Cloud WAF market or the RASP market. There’s lots of words that are floating around. Basically, there's a solution for protecting production applications, it starts pulling the best elements of technologies from these kinds of different worlds. Some things from the old world like the WAF. There will be web app firewall type of capabilities that move into the new worlds. Even Amazon and Azure built that into some of their components. But, it will start to leverage new things that are available because it's in this new environment, so you’re pulling ideas from Application Performance Management tools like New Relic or App Dynamics. It will cover all the problems that are relevant today, not just the problems that are relevant five-ten years ago. So, bot mitigation becomes incredibly important in addition to blocking for specific vulnerabilities. And all [tools] get built in a different way to support this different release model right; so it becomes pure software, it becomes automatable. It just works the way people build and deploy software today just like the old world racking of a box worked well when the way to deploy applications was rack onto Dell boxes.

All that shifts over, but the common themes actually stay there very similar. Make a list of what possible attacks are relevant today, those change, but there is a list. Pick the right technologies to identify and block those attacks, subject to the most important thing which is [the technology] is highly deployable by the operations team they have to partner with and make sure that they are cost effective, they scale the way the applications scale, they work right based on the technologies and that's all there is to say, that’s where things are going.


Alex: Interesting. I'm going to hand you over to Steve now and see what sort of fun technical questions he has.


Steve: How’s it going? Immediately, my first question to you is from reading through your documentation, it looks like your technology works by integrating with the current sort of web application frameworks that an end user might be using. Something like Tomcat or Ruby on Rails. It sends telemetry back to your servers. Am I correct about that?


Michael: That's correct.


Steve: And so then you're able to perform a threat analysis from that telemetry data?


Michael: Yeah, so with that telemetry from the web server tier, from application tier with bits of javascript [in the browser] called Content Security Policy that will give us the visibility into what's happening inside the browser itself. So, from those three points, [tCell ] will asynchronously collect information about how the application’s operating. Initially, for example there will be a discovery phase where you'll start to understand the risk profile of the application.

What 3rd party library got loaded in and will map that to known CVEs. If you have vulnerable libraries, it will tell you. It will tell you what API end points have been exposed to the outside world; On the browser side, it will tell you what scripts are in there, but more importantly, it’ll tell you what 3rd party domains are being loaded along with your applications. Is your app pulling content from Akamai, are you pulling images from Google, ect. You get this in the discovery phase.

Then the next thing you'll see is how people start accessing the application in a normal way. So, you'll see what end points can get accessed, what database is going to have tasks, what content you’ve pulled in. Pretty quickly, on the Internet, someone is going to start poking at the app. You’ll see if they start hacking it and you'll start identifying attacks. You’ll see malicious payloads coming in, you'll see attacks that might be targeting your authentication controllers. You can see if they are using a user name or password that might have stolen from somewhere else.

So, you'll start seeing malicious activity against the application, but then because it's got those hooks inside of the application, it can see which of these attacks result in an actual breach. For example, all the hundred thousand command injection payloads that were thrown at your application, did any of them result in a shell command that got executed by the application?

In most cases, the answer is no, but if you have a vulnerability; either your own vulnerability or a vulnerability from a library, and you leave it open long enough some attacker is going to find that hole. tCell allows you to see that happening.

The last phase is; when you have policies in place that prevent the app from doing something it shouldn’t do; let's say that for example, someone throws in a payload, they figure out how to run a shell command. Well, in your tCell policy it’ll say ‘my app doesn't run shell commands’. tCell would stop that shell command from running and that would prevent the catastrophic breach. So, you’ve discover the risk, you seen the attacks happening, you isolate the breach from the unsuccessful attacks but you've also got policies in place to stop any attacker from making real progress and breaching application.


Steve: Interesting, that reminds me a little bit of writing a LINUX policy to deny certain kinds of privileges from an application.


Michael: That's exactly right. So, if you picture you’re going serverless, the vast majority of the attack surface area of your environment is exposed by the application itself. At the app layer, there's so much more complexity which translates so much more risk. You want to set up similar level of controls and disability to actually protect the app because that's basically where your exposure is.


Steve: Makes perfect sense, that sounds really interesting especially how you can sort of do a discovery of different kinds of threat vectors and other sort of bits of normal usage of your application, then apply these kinds of remediating policies to ensure that if the worst really does come to the worst, the impact can be quite low. Along this sort of idea, I was curious because since we’re sending information to the tCell servers and some of the information coming from a web app might include privileged information like HIPAA, PCI or something like the GDPR in particular. I was wondering how tCell’s able to ensure the security of the data that's being sent to the servers.


Michael: Yeah, sure. That's a critical thing to make sure you have right with any product like ours. We have to be obsessive about the security of our service. There is specific product functionality we want to give to people; clear visibility of what data is being sent out to the [tCell Service] with clear documentation, and beyond that there are modes where you can inspect the data to see what's going on there.

Then, on top of that we want to make sure that the data is handled correctly. That starts with ensuring that encryption happens everywhere it needs to be.

And then, the last step is; because you have very clear visibility of what data is going up to the servers you can be very selective about it, you can decide what data you want to share with the servers and what you don't. Everything you send up adds value to identifying attacks, understanding your application, so there's a strong incentive to sending all kinds of information up there, but there is going to be data you never want to send.

So, we handle the data correctly, make sure it's encrypted and give controls over what you want to send up to the cloud.


Steve: The field of security really has been lagging especially in the era of web scale and having to adapt to a new world where internet technology, particularly mobile technology, are ubiquitous. So that's fascinating and tCell really does seem like a really fantastic product.


Thank you so much for coming on the show today it's been an absolute pleasure having you.


Michael: Absolutely, I appreciate it. It’s been a lot of fun.