Decrypt with Evervault: Thomas Kinsella from Tines

Listen on:

• Spotify
• Apple Podcasts
• Amazon
• iHeartRadio
  

In this episode, Shane sits down with Thomas Kinsella, Co-founder and Chief Customer Officer from Tines to discuss the ins and outs of developing and scaling a security product. Tines is a no-code automation platform that helps some of the world’s best companies – from startups to the Fortune 10 – with their mission-critical security workflows. Prior to co-founding Tines, Thomas was Senior Director, Security Operations at DocuSign, Lead eCrime Investigator, Global Technical Investigations at eBay, and an IT Security and Forensics Specialist at Deloitte. In this conversation he shares stories and insights both as a seasoned security expert and a co-founder.

A few highlights from their conversation include:

• 10:33: The worst hack he saw at eBay (it involved passwords hashed with MD5)
• 18:11: How building your own security solutions come with risks around estimating the amount of work involved and relying on a dedicated team for the long term
• 23:59: Why ensuring uptime and resiliency is crucial when you’re automating business critical tasks.
• 27:43: Thinking of how to measure success when expanding a product

Listen to the full episode on YouTube or wherever you get podcasts. Connect with Thomas on LinkedIn and on Twitter @ThomasKsec.

Shane (00:26):

Hey Thomas, thanks for joining us.

Thomas (00:29):

Thanks for having me, Shane. It's a pleasure to be here.

Shane (00:32):

I always like to ask people who work in security and I guess tech in general, how they got into it. It's one of these industries where people generally have pretty interesting backstories. So I'd love to hear from you how you got into tech and then eventually security.

Thomas (00:43):

Yeah, I didn't really know what I wanted to do in my life. It's a bit of a philosophical answer straight away. But yeah, when I was in college, I kind of looked up to a couple of people that were a little bit older than me, cousins and things like that, and they were all in tech, and I was like, okay, this is an area I might want to be in. But I kind of hedged my betts and said, I don't know if I want to be in consulting. I don't know if I want to be in pure tech. I don't know if I want to go into security or anything like that.

(01:08):

And yeah, joined one of the big consultancy firms straight out of college. I worked there for a year, learned a ton about how to do things correctly and probably more about how to not do things correctly and to not treat your team, but really enjoyed the experience and then managed to get out by somebody else being like, hey, there's better opportunities out here. And got out recently quickly straight into a kind of weird security job, which was just super interesting.

(01:40):

So, consulting was pretty much just internal audit, some forensics, some pen testing, things like that. But moved to eBay where I was on the technical investigations team. So yeah, didn't really know much about phishing, didn't really know much about takeovers or fraud or anything like that. But got an experience where my team, we're a small enough team, maybe seven or eight people worldwide, but our job was to identify large criminal organizations abusing eBay and PayPal, where the remit was, they were making over a million bucks a year on the platform or off our users. And it was to identify the people involved for attribution and prosecution. And basically just had loads of... It was fun. It was a bit of a cat and mouse game.

(02:29):

It was tragic as well, seeing people lose a whole lot of money. But it was really interesting just going down and learning tons about cybercrime, scams and vulnerabilities in the platform that were being abused and large scale phishing attacks. And this is at the time that PayPal and eBay were the number one and number two phish brands in the world. So we were getting targeted all the time.

(02:51):

Did that for a couple of years and then after that, spent a little bit of time in the US and then got an opportunity to join the security operations team. Thought it might be a good time to move a little bit more into in the operation space. And worked for a couple of years in DocuSign's security operations side, so responsible for incident response throughout intel, security, infrastructure, all that sort of stuff. And then yeah, from there joined, or started Tines but yeah, there's no real, I want to get into tech. It was just kind a bit of a journey following some smart people and being in a privileged position to work with some really smart people and learn from them and learn with them.

Shane (03:30):

Cool. And since then, it doesn't seem like you've moved too far from the security operations side of things. Having started Tines a few years ago with Eoin Hinchy.

Thomas (03:35):

Yeah.

Shane (03:37):

It'd great to hear a bit more about what Tines is, how it got started, and I guess what you actually do day to day there.

Thomas (03:42):

Yeah, sure. So the life of somebody in security operations is hard. So when we were in DocuSign, we were working long hours, but we were getting good support. We had a decent team. But the challenge that we faced was that the better we got at detecting, the more tools we got, the more we had to respond to. And yeah, the better the threat intel was, the better our detections got. We're like, oh no, we started seeing, this is actually really hard. We are going to get compromised at some point. And sure enough, same as pretty much every other organization, there were some large incidents involved. But when we looked around and we talked to our peers, we said like, hey, what are you doing? Are there any tricks here? Is there anything that you're doing that we're not doing? And a lot of people said, hey, we're automating or we're trying to automate.

(04:28):

And we looked at a lot of automation platforms and we didn't like them. We said, they're really hard. They're kind of clunky. You kind of have to be a developer or somebody that certainly knows how to write Python and knows how to write some decent code. And while we had good people on the team, they weren't necessarily the people that you wanted to be... That didn't themselves want to be writing code for boring operations and automations. So yeah, we started Tines about five years ago to be an automation platform that was similar. So Tines is a security automation platform. We allow people with very little coding background to automate repetitive manual tasks. It's mostly a workflow builder, was certainly a workflow builder at the start. We built a whole lot of things on top of that right now.

(05:19):

But it basically allows you to take a process and as long as you're familiar with the process, you can automate it using a few simple tools, but it can go from anywhere from five or 10 steps all the way up to hundreds of steps in your process. And yeah, it's a really powerful platform. We've got a lot of incredible customers. We're privileged to work with some of the best security teams out there and learn from them. So I'm chief customer officer now, but my job is basically make sure the team's happy, make sure the team's successful, redline legal documents, all that sort of stuff.

(05:51):

But mostly it's work with our customers and work with internal teams to understand what our best customers are doing and then pass that on as best practices to other people. So it's really being at the front line of what good security operations teams are doing and then evangelizing that to our customer and prospect base. There's always sales and stuff like that involved, but it's a fun job and Tines, it's a great platform when you see what people are doing with it. It's a privilege seeing, yeah, seeing people's security analysts, security engineers, their lives are easier as a result of using the platform. It's great.

Shane (06:26):

Yeah, I mean, I guess the product that you built from day one was pretty much solving a problem that you and Eoin probably had when you're working on various security teams across your previous jobs.

Thomas (06:37):

Yeah.

Shane (06:37):

Did the product change at all over time or were you guys pretty much spot on from day one?

Thomas (06:42):

No, I think when we built version one, we're like, this is it. Look at this. We built something amazing. It's going to be absolutely fantastic, just wait until the customers start rolling in. And now I look back and yeah, I'm like, that was rough. But they say you should be embarrassed by your first product when you launch it. We weren't. We were delighted with it. And now I look back and I'm slightly embarrassed by it. I'm like, that wasn't quite in as good shape. But the actual core principle that we had. When we set out, we said we wanted the platform to be simple enough for anybody to use. And so you didn't have to be a developer, you didn't have to know Python or write any code. We wanted it to be agnostic as the tools that it was connecting with. So it didn't matter if you were connecting to your own internal CRM or your own internal threat intel platform or a commercial off the shelf tool like CrowdStrike or Qualys or Jira or something like that.

(07:42):

And then the third thing was we wanted it to be super fast and lightweight. And we stuck through to that. The platform has evolved though. So, it used to be pretty much all on what we call the storyboard, the canvas that you're designing your workflows. So we've now introduced interactions outside of the canvas, which allow you to either kick off workflows or interact, say, hey, Shane, did you do X? Or maybe you want to bulk look up a thousand IPs or enriched a thousand vulnerabilities or something like that, and display some information back on a map or in a table or in a downloadable file or fetch stuff. That's all possible now.

(08:21):

The other thing we've introduced is we've introduced records. So the idea of being able to record what's happening in a simple database, and then cases as well where you can track what you're doing and collaborate a little bit on more significant things that you want to collaborate on. So, maybe it's an incident or maybe it's a request that you need to have a bit more of a chat about. The phrase we use is automation for the things you know, but cases for the things that you don't. So yeah, the product has expanded quite a bit, but the core fundamentals of it are pretty much the same, and that's very gratifying. The company has changed massively. We're now 165 people or something like that, and that's been a bit of a ride as well. But again, it's been fun.

Shane (09:09):

Yeah, they're all good problems to have.

Thomas (09:11):

Yeah.

Shane (09:11):

I think one thing that surprises me, and I guess a lot of the other people that are working in the security space in general is just how mature security teams are. All the things and various features that they look for, all the tools they're already using. But at the end of the day, security teams in general, and I think both Tines and Evervault have a roughly similar goal, which is to improve security across the internet. One thing about security is that it's very much a long tail risk that a lot of people don't necessarily grasp until they've actually experienced some kind of data breach or identity theft or something like that. You've obviously spent a lot of time in security investigations for when these things actually go wrong. I'd love to hear if there's any kind of noteworthy security incidents that you've either heard about or been involved with that you think are interesting and that could be good to learn from.

Thomas (09:54):

Yeah, there's a ton that I was involved in, both in eBay and DocuSign. Some are NDA worthy and others are generic enough that you can talk about in the general sense. The biggest one that I remember, so I used to think that the job was prevent every single compromise, and to a certain extent that's what you're charged with. But in security, you have to presume that there's going to be security incidences, that's why you exist and you can never stop absolutely everything. So you have to be able to detect and respond and then put in place measures afterwards to prevent them from happening again.

(10:33):

But yeah, in eBay, we had a couple of pretty bad ones. The worst one was, at the time there was, I think it was a Belarusian crew or maybe just an Eastern European crew that had compromised a whole lot of different people. So they compromised LinkedIn, they compromised Yahoo, they compromised Blast FM and a bunch of other people. But what they were doing was they were taking, for example, LinkedIn passwords, cracking those who were all, I think they were all MD5 hashes, so it didn't take very long to crack those. And then they were just finding anybody that signed up for LinkedIn with shane@everalvault.com and trying his, well, looking for the most interesting companies and then trying those.

(11:16):

And they managed to compromise several email accounts in eBay that way. And then from there, they managed to get somebody who was an admin of our active directory managed to, I think, intercept a couple of 2FA requests or 2FA issuances basically. Ultimately, they escalated privileges where they were able to issue their own second factor tokens for our VPN. And then they got into our network and they pivoted around, got a couple more accounts and basically dumped everything. But what was interesting at the time was we had decent sim, had decent detections, but boy oh boy, were we completely caught out by simple things like not having two-factor authentication on all of our email accounts, for example. Allowing simple enough passwords, not encouraging for some people strong, unique passwords for their email account. But what I remember was, I remember afterwards because one of the vectors was that VPN, one of the things that we did was the office didn't shut down, but anybody that was remote was prevented from logging in for a couple of weeks, as you can imagine.

(12:36):

But every single time somebody, then for the next basically six months, every time somebody requests or connected to the VPN from a new IP address or requested a new whatever, 2FA app, we had a team both internally and then eventually supplemented by some consultants where they would contact that person via email or via Skype, email and Skype and say, hey, Shane, do you recognize this activity? And what was crazy was that this was a manual team where we were spending tons on consultants to get them to just contact people randomly and say, hey, do you recognize this activity? And they'd say, yes, and we didn't anybody that way. We caught a couple of weird activity, but there was no, the guys were long since gone. But that was also that activity that reaching out to somebody saying, hey, do you recognize that that? That was also the same way that the SolarWinds breach was detected where somebody added a new second factor to their Okta account I think it was in SolarWinds, which Mandiant or FireEye detected at the time.

(13:50):

But yeah, that's a really simple process that I suppose we noticed. Yeah, we noticed we're just spending a lot of time on, and it's one of the things that we learned that you should just be automating. And that's pretty much the simplest story that every single one of our Tines customers automate. So every single customer will suspicious log in from a weird location either on their email or 2FA or SSO or whatever. They will contact the user on Slack saying, hey, do you recognize this activity? If they say yes, then they close the case. If they say no, then they escalate and they immediately revoke all sessions.

(14:24):

But that's one that I remember being really painful, front page of TechCrunch, front page of Twitter, all that sort of stuff. And it just hurt a lot. But yeah, learned a lot, learned a lot from this, what we could detect, what we had for catalogs for. There was nothing crazy. It was just a reasonably basic attack that compromises, because we didn't have a ton of, we had decent security measures, but just didn't have enough controls in place, so it was sore. Loads more stories, yeah.

Shane (14:55):

The response is always the most painful part to me. I think we've gone through processes like SOC2 and so on, and even as part of the SOC two, you kind of need runbooks for what happens when you detect all these breaches and just incidents in general. And it's surprising to me how many of the runbooks are still just on paper. So any kind of automation-

Thomas (15:13):

Oh yeah, it's brutal.

Shane (15:14):

Is just so much easier and makes life so much easier for people. So I'm glad that Tines exists.

Thomas (15:18):

Yeah, and again with Tines, there's plenty of other platforms, there's plenty of other ways. What's really interesting is when people have those runbooks, but they're live where it's like, hey, you make a change in, for example, confluence where your runbook is, and then that will affect an automation. That's where we see a lot of our sophisticated customers going.

(15:36):

Or if someone's like, hey, so how do you approve access to certain apps? Or how do you detect if or how do you ensure that no EC2 instances spun up without whatever certain permission is applied? Like, well, this is how we do it, because as soon as it happens, it sends off a guard duty alert and then we automatically revoke those permissions, et cetera, by saying, hey, this is live is how it works. The only challenge is, or not the only challenge, a lot of the challenges is that there's an old military phase, which is generals are always fighting the last battle they lost.

(16:09):

So a lot of the time people are patching and building out processes because they've been told, this is how they got, not even that they got compromised this way or they got hurt. There was a very serious incident or near incident as a result of something. So that's what they'll go after. But yeah, most obviously if you don't do that, you will get hit by it again, but you also have to be looking towards the future and using tools like Evervault to be like, hey, if somebody does get closer to my crown jewels, what do I have to make sure that it's not actually catastrophic?

Shane (16:38):

Yeah, I think a lot of the time we're talking about all these various tools that get used in security as well, and it sounds like one part that Tines helps with is the actual runbooks themselves, what you do when you detect some event. But there's been serious sprawl over the last number of years and the number of different tools that security teams buy. It seems like you guys also do a pretty good job of aggregating all those things together. So if you've got a SIM and you've got just audit trails from things like CloudWatch and so on that you tie them all together. But it all sort of points to this old adage of build versus buy. At Tines, how do you guys think about security tooling and whether we're going to move more in a direction of having more and more tools or fewer tools that are just more tightly integrated?

Thomas (17:19):

We see everything. I think the best teams have a strategy around it and say, this is actually what we're focusing on, and it's not just we're buying a tool because it looks shiny, or we're building a tool because hey, Steve said he wanted a project this summer and this is a project that he wants. The thing that I think about with build versus buy, there's a lot of security teams that have incredibly smart people on them, and they absolutely, I've no doubt, could roll their own SIM and make it effective or roll their own EDR in some way and make it effective or roll their own encryption. But in many ways, depending on the security team that you're on, and that your risk posture and your risk tolerance, it's probably not a core competence of yours to build something that's better than everybody else out there and that's custom to you.

(18:11):

A couple of different reasons. One, you're inevitably going to underestimate the amount of work involved in building and shipping one of these things. Not saying that you can't, but there's a lot of good enough tools out there that do a pretty good job where they've got entire teams that are spending time, they're spending time developing something. But I think the other challenge is if you are saying, hey, I want to roll my own X and build it internally, you have to rely on that person or the team behind it being there and supporting it for the long term or even the medium term. And when we've seen people do it, it often it can be successful. It takes a long time. It's often a project that takes a huge amount of effort. It takes a lot of focus away from other areas they could be spending time on.

(19:03):

And then inevitably in two or three years time when those people move on to a different project, people are like, I don't know how to support this. And the reason is that it wasn't built for scale or it wasn't built for the enterprise that we're going to be at the moment. Or even worse, it's like, we just can't find anybody who wants to spend their time maintaining this legacy system over here that somebody spent a couple of months or a couple of years building.

(19:25):

So unless it's a core competency, and if it is a core competency, it makes perfect sense. If it's core to your business and a key differentiator against your competitors, you should absolutely look at building it internally. But if it's not, then yeah, just look at the market, have conversations and see. And it's up to the CISO or up to the CIO or CTO to decide is this something that's actually going to make a material difference to our company? And if it's not, then we should be looking at building and finding something that's good enough and having people focus on much more company specific risk reduction efforts. That's what we'd recommend. Not dissing people that do it, but security people bite off more than they can chew, and they have a tendency to scope, I think scope projects a little bit ambitiously.

Shane (20:18):

Yeah, it's pretty easy to fan the security community, so I wouldn't worry too much about that.

Thomas (20:23):

Yeah.

Shane (20:23):

It's very similar to engineering in general though, right? Most people are building tooling. Unless it's part of their core business, they probably shouldn't be doing it. So I don't think security is any different.

Thomas (20:34):

No.

Shane (20:35):

But you guys obviously spend a lot of time speaking with security teams and I guess your core customers. I'm guessing they're probably a little bit more cynical or I guess just in the weeds on how good your own internal security is. How do you guys structure security at Tines, just organizationally, and is it part of engineering, is it a separate team, and was that a consideration from day one?

Thomas (20:57):

Yeah, fortunately or unfortunately it had to be a consideration from day one, and we've had to be very, very careful on how we vet, we satellite. We've got Fortune tens, large banks, governments, whatever, international institutions, as well as some incredible security companies like Elastic or Barracuda, whoever as customers. And then you've got your standard just large enterprises or crypto customers who have zero tolerance. So we knew that as an automation platform as well, you said earlier, we're hooking into a whole load of different systems. So you could be hooking into your EDR platform, but you're also probably hooking into your people management system. Maybe it's like Workday or Bamboo HR, but you're also hooking into your Gmail and you're hooking into your SIM and all of a sudden you're like, well, actually, you've got access to a huge amount of information in this platform, so you have to be very careful about how to do it.

(22:04):

So we have a production environment that's incredibly locked down. So we've hired very good engineers, and their job is basically don't allow anything in there. Every single access is audited. Not only is there an alert crowd for the security team, the engineer has to acknowledge and say, hey, here's the reason why I went in. There's good fall integrity monitoring, things like that. So if anything does change that's unexpected, we'll know about it. There's obviously really good BCPDR teams. But then, yeah, as you said, it's also about the structure of the team itself. So we've got a head of security and his job is, it's like platform security and I suppose the detection response side. So we've used a bug bounty to try to detect everything or try to crowdsource activity. All of our customers, or not all of our customers, many of our customers will be pen testing the app themselves, taking our code, ripping it apart or pen testing a, fortunately, a siloed or dedicated cloud instance where they can knock it out and not affect any customers.

(23:16):

And then anything that we detect, you're doing your standard scanning static and dynamic application scanning to see is there anything, or are there any dependencies that are vulnerable? The answer is there's inevitably going to be some things, but again, it's about detecting and responding to it as quickly as possible. So making sure that we have visibility so that if something does pop up that we're able to, yep, heat patch really quickly and alert our customers to it, or making sure that even if something does happen that it's not going to hit our crown jewels. And our crown jewels is pretty much like any customer data or access to any customer systems. We don't want anything happening there. But yeah, fortunately or unfortunately, it had to be something from day one, myself and Eoin being security practitioners, we were able to build it in.

(23:59):

But then, yeah, just handing it off to people who can focus on a full-time and an engineering team who know the criticality of it. The other part that I haven't really mentioned is just ensuring uptime and resiliency as well. That when you're automating business critical tasks, any sort of uptime or any sort of downtime is really disappointing. And so yeah, we have customers where they're processing millions of events every single day, so even 30 seconds of downtime, they're like, okay, something happened. There was a blip. And that level of scrutiny means that we have to up our game. But it's been fun. Again, you're learning and they're giving us good advice and our customers will, they're broadly very tolerant if you tell them, hey, we're going to do something. If you give them enough notice, everything's fine.

Shane (24:59):

Yeah, it sounds like you guys probably have a lot of the same pain that your customers have when it comes to structuring security. So do you guys use Tines at Tines?

Thomas (25:06):

Tines? Yeah, there's an entire blog series that we're trying to write about using Tines at Tines. So yeah, we use it for everything. So we've introduced records now, so that allows us to use it for asset management. We use it for tracking all of our customer tenants. Now, we also use Snowflake and Fivetran and things like that as well. There's some data that we saw in there. And from a security point of view, all of our alerts obviously go through. So our similars will go through there and then EDR alerts will go through there as well.

(25:38):

Onboarding all new users goes through there. But the fun stuff is things like enriching every single lead, for example. So right now, if a customer, if you sign up on tines.com, we've got a free community edition. It'll look up your evershane@evervault.com, it'll look up ever vault, it'll tell us what sort of sector. We'll basically just have a lead rating system, look up what sector you're in, tell us a little bit about your role, your position, provide a nice Slack message to our customers or to your account manager saying, hey, here's some information about Shane. He just signed up.

(26:14):

But the thing about it then is we'll also if you, for example, import a new story or like a new blog or something like that, it'll say, hey, Shane's back. Or sign in for the first time in three weeks, it's like, hey, Shane's back and he's just viewed the pricing page and there's a little bit of intent there and we can track it. And that's all built on Tines as well. That's not something we should be advocating our customers use. But I'll tell you, forcing the marketing team and forcing the engineering team and forcing the other sales team to use the platform, you get a lot of feedback and it makes the platform... We're consistently trying to lower the barrier to entry. It makes the platform easier to use, and you learn a lot from how random people use the platform, not random, how less technical people use the platform.

(26:59):

They're like, hey, what does a binary decision mean? You're like, okay, we need to change this to be like say yes, no, or it's like, yeah, hey, how am I supposed to encrypt this? You're like, yeah, okay, you're just going to have to zip this up and then put on a password and et cetera. But you realize that you have to make things easier for folks in ways that you, unfortunately, I'm way too close to, and I'm just blind, spend too much time on the platform, so I'm blind to it at this point. But yeah, we use Tines for so much stuff internally. It's been, yeah, it's fun.

Shane (27:34):

And broadly, it does sound like the product could be useful for teams outside of security as well. Is that something you'd ever consider or is it just something that's not interesting for now?

Thomas (27:43):

No, it's definitely something we're considering. So we have a bunch of customers that are using it outside of security. So we have people that are using us for things like standard incident management. So your DevOps or your tech ops teams where if there's an instant they want to create a bunch of Slack channels, add a bunch of people in, collect records from a bunch of different places, backup up the chat, create a Zoom channel, all that sort of stuff.

(28:09):

We have IT teams who are using us for onboarding, off-boarding and things like that. We've got fraud teams who are using us for bulk account reviews and things like that. And then, yeah, there's a whole lot of weird use cases that we don't even consider where people are sending out access request tools. Again, like an IT kind of use case. A lot of these are, so it's like if you want access to a tool for half an hour or you want to have a software request access approved, you can put in a request, Tines will look up your manager, your manager will approve.

(28:43):

It'll look up your budget owner. The budget owner will approve, then it'll go to IT, who will just click yes, and then they'll auto provision. The way it normally happens is teams will see security doing something. So the IT team will see the security team off-board a user. So the security is usually responsible for off-boarding tools or off-boarding users rather than IT because security will get dinged by compliance. And the IT team are like, hold on a second. It takes us two days to provision this person with all these tools, and it's five o'clock on a Friday, and by 5:15 they're out of our system. How did you do that? They're like, oh, we use this tool Tines or the incident management team for tech ops will see Tines be used because a Slack channel with all the information pulled from a thread with the runbook saying like, hey, here's what you should do. They're like, hold on a second. How did you do this? Because we do all this manually. They're like, oh, we use Tines.

(29:40):

And then they'll start playing around with the platform and they'll really like it. We will start selling to those teams directly, but we're going to be a little bit deliberate about it. We don't want to go out and say like, hey, Tines, now use for IT, because then your proof of concepts take longer. You don't have defined use cases, you don't have profiles or competitive paddle cards, and maybe your land size isn't as big, et cetera. So you want to make sure that you're doing it deliberately. But we have identified a bunch of use cases that we know work really well, and it's about enabling the team to go after and sell those. But yeah, we just have to define what success looks like. So does it lead to a larger deal size?

(30:19):

Does it lead to a faster proof of concept? Does it lead to a faster expansion? Because if it's not leading to either more... There's definitely a larger tam, but if it's slowing down our process, if we're winning a smaller percentage of the deals or we're not making as much money from those deals and we're spending at the same time, it doesn't make sense to do it. So you just have to be careful in how you're approaching it and define the success criteria and measure it. And if it is working, then we're saying, okay, we should actually go after these areas deliberately. If it's not, then we should say, actually, we'll pull back a little bit and maybe we'll go after a different area. But we're seeing massive traction in security, so we're not saying, “hey, we absolutely have to do this,”, but it's a bit of a no-brainer. If we're able to win 60 or 70% of proof of concepts where with DevOps teams for this particular processes and we can get X amount of money from them, it's a no-brainer to do it.

Shane (31:12):

Very cool. Watch this space, I guess.

Thomas (31:14):

Yeah, absolutely.

Shane (31:16):

I think we all need role models when we're building companies. I'm curious from your side, are there any particular security teams or products that you admire, either just from how they're built or designed or just how they've impacted your life in general?

Thomas (31:27):

Yeah, there's a few. So as a practitioner, I loved working with some vendors and absolutely hated working with others. So the vendors that I worked with who told me what the product did, didn't oversell it and said like, hey, we do a good job. You can try it out yourself, you can have some fun, or not even have some fun. You can try it yourself. You can get it working reasonably quickly. But mostly they said like, hey, this is what it does. This is what's on the roadmap. And they'd ship their roadmap. I really liked working with them. The vendors that I didn't like working with were people who said, yeah, that feature would be available in two weeks time. You'd buy the software and a year later it still wouldn't be there. It wouldn't be working. Or they'd say, it'll detect every single new domain that's registered, or it'll whatever, detect all types of this commercial malware, and then you'd be hit by that and they're like, well, the detection didn't quite work. And you're like, well, then don't tell me that it does that.

(32:28):

So there's a bunch of companies that we thought did a good job at that. There's one in particular company called Qintel who were just a brilliant threat intel, bespoke threat intel team. But I like teams like, yeah, random platforms like Carbon Black, where they actually just said what they did on the tin. And that's what we started Tines to be. We started Tines to be the platform that we wished we could work with, the vendor that we wish we could have worked with. So we have a free community edition. Our branding is like, it's weird, it's purple. It's purple and pink. It's friendly. It's designed so that, security's hard, you don't have to be told you're going to get compromised tomorrow because if you do get compromised tomorrow, you still don't need to be told it was your fault because you didn't do X.

(33:13):

There's a lot of those, I suppose, not even snake oil, well are snake oil, but some dodgy security companies out there. So we've tried to be a little bit different. Oftentimes there's a lot of practitioners that create companies like that or like Tines as well that are part of it. There's some bunch of security companies that do a good job at this at the moment that I'm fans of. The likes of, yeah, Material Security, Panther or LimaCharlie or GreyNoise where there are people that worked in, I suppose worked in security, but they kind of let the product speak for themselves and said, we're good at what we do. Elastic are similar enough. I know they're a lot larger, but we're good at what we do. We'll let you try it out for free. Our customers will be our biggest advocates, but we're not going to tell you, hey, we prevent everything. We'll tell you this is what we do and we're really good at it.

(34:06):

They're the companies that I really admire and the people that I really admire behind it. There's a bunch of non-security companies as well that are doing similar things. I also have a bit of a grow for Irish startups as well. So anytime I see anybody from Ireland, I'm like, I want these guys to succeed and hope that they're successful and give them a shout-out whenever I can. There's a new threat intel company called Silent Push, a guy called Ken Bagnall started them up and yeah, I think they just announced last week they got 10 million for their threat intel platform, and I'm like, I might check them out and see what they're like. So hopeful, again, free community edition and practitioners starting them, but we'll see how they do.

Shane (34:50):

Cool. I heard Evervault's pretty cool as well.

Thomas (34:52):

Yeah. Sorry. Absolutely. Evervault is, yeah, no, again, your marketing's really nice as well. You're very, very friendly and very modern. And again, a bunch of happy people telling us good things.

Shane (35:09):

Yeah. No, I'm just joking. But yeah, Thomas, I really appreciate you taking the time to jump on the podcast with me. What's the best way for people to learn more about Tines and get started if they're interested?

Thomas (35:20):

Yeah. So, tines.com. There's a free community edition. You can start up and sign up with your Gmail. There's no requirement to talk to anybody from sales. A bunch of playbooks there that you can get started with. Several hundred. Yep. And yeah, you can follow us on Twitter @tines_io. For me, you can follow me on LinkedIn or on Twitter, @ThomasKsec and say hi. We're always looking for feedback, so give us as much as possible and tell us like, “hey, this is great. I really like this area”, or “this is an area that needs to be improved.” That's the only way companies survive. So we're trying to be open to it. But yeah, sign up, say hi. Tines.com/slack as well if you want to join the community. And yeah, we'd love to see you.

Shane (36:07):

Great. Thanks again and all the best with Tines going forward.