Decrypt with Evervault: Tamás Henning From Circle

Listen on:

• Spotify
• Apple Podcasts
• Amazon
• iHeartRadio
  

In this episode, Shane has a conversation with Tamás Henning, Senior Director, Security Engineering at Circle. Circle is a global financial technology firm that enables businesses of all sizes to harness the power of digital currencies and public blockchains for payments, commerce and financial applications worldwide. Tamás cut his teeth in security from a natural curiosity towards making computers do things that were not initially intended for them to do. He’s held security roles at Skype, Microsoft, Roblox, and was interim CISO for Novi, Facebook's blockchain initiative. Tamas says he  “always looks at privacy in the matter of, if you don't do security right, you can't have privacy. If you don't do privacy right, you also can't have proper security. For me, the two go hand in hand in today's world, because if you really don't focus on both, how can you build user trust?”

A few highlights from their conversation include:

• 5:15: Why trust is so important to privacy and security
• 9:21: The value of being able to translate between compliance intent and engineering
• 13:04: How security should act less as a policing function and focus on helping the business succeed
• 19:08: His strong  believe that security practices like the utilization of HSMs and specialized hardware for encryption and decryption is something that we should be using not only in the Web3 ecosystem, but also in the Web2 ecosystem
• 29:15: Why he admires the Microsoft security team, primarily the Microsoft Security Response Center

Listen to the full episode on YouTube or wherever you get podcasts. You can find Tamás on Twitter @TamasHenning and on LinkedIn.

Shane (00:28):

Hey Tamas, thanks for joining us.

Tamas (00:30):

Hey, how's it going?

Shane (00:32):

Pretty good. I'm curious to hear from you. I know security isn't necessarily something that a lot of kids when they're growing up are aspiring to get into. Personally speaking, I wanted to be an astronaut or something similar. So I'd love to hear from you a little bit about how you got into security and where you developed an interest in computers and I guess how you ended up where you are now.

Tamas (00:52):

That's a very interesting story. So I grew up in Eastern Europe, and the cool thing about that was back in the very early '90s, computers weren't really a thing in Eastern Europe, and I remember my dad in 1990 actually bringing home the first computer, and it was such this magical thing that he was working on initially as a teacher. It was this curiosity of, oh, what is this thing that works on power and that is sitting in front and typing on and doing weird things with. And as time grew this curiosity towards this magical box that we had at home, that curiosity naturally grew and grew and grew to the point where at a super young age, I really started learning it, playing with it, initially playing games, and then later starting to write applications and then in school already starting to make it do things that it was not really intended to do.

(01:54):

I remember I was in sixth grade when the thing that I really wanted to do is rewrite Tetris in Berlin and Pascal and my dad was like, "Okay, kid, you're going to need to now learn trigonometry and all of that fun stuff." So did that. And in these times, Romania was still not as developed from a security and infrastructure perspective either. And we got our first always on internet, and my first WAN IP was a 192 168, and didn't seem weird at the time. Now it's like, what do you mean? So we were in a citywide land and I started to get accustomed to certain tools that were available on IRC forums and whatnot, and I just saw what they can do, like wait, I can laterally move around network and get into someone else's computer without them noticing.

(02:50):

And it was this curiosity towards making computers do things that were not initially intended for them to do. And then in high school, my high school at one point decided to lock down, so you couldn't install games, you could just use the applications that were installed. So we made it a sport with me and a friend of mine to see how can we bypass that lock, and we didn't do anything malicious with it. We just went to our teacher and said, "Well, you tried, you failed. Here's how we did it." That landed me in quality engineering. Went over to engineering, and this curiosity never went away and then landed in security.

Shane (03:36):

Awesome. I think computers have evolved quite a lot from an era where you're working on a citywide land to where they are today, and I'm guessing security, from your perspective, has changed quite a lot as well. It's not just a case of SSH-ing into somebody else's computer. So in terms of today, obviously you've got a role at Circle and Security. What does that look like and what does security actually mean for you today?

Tamas (03:57):

Yes, so I'm the Senior Director of Security Engineering at Circle, and I'm mainly here just to represent myself and talk about my views. So my role is really looking at the prevent side of the houseware circle. So I really focus on product security and cloud security and look at our blockchain things. And I'm going to answer more in a general sense of, "Hey, what does security mean to me?" I think it's one of the most important things that we could be working on. Looking at how the industry has changed in the past decade.

(04:30):

We went from a world where people are the product to privacy and security being the product itself. People are a lot more hesitant in sharing their data. They're a lot more hesitant in sharing their photos and being that really open about who they are, what they are. The world has become incredibly small with the advent of social media and whatnot, and we've seen the negative impact that it can have through influence, through not really being able to say what is a true tweet or what is a true social media post to influence into elections or influence into outcomes of how people think and whatnot.

(05:15):

So for me, security and privacy means a lot because we need to get down to the neutral basics of what we were used to back in what I'm going to say, the '90s and 2000s when journalism was fully trust-able. It wasn't influenced through other means. You weren't influenced and trusted by fake news or anything of that nature. So that's why I'm in this, is actually really protecting the world at the end of the day.

Shane (05:47):

I think your background's a little bit interesting that you are coming from both a technical security angle, but also privacy as well. I know you spent some time at Meta or I guess then Facebook. How did you make the switch from privacy into security? Or did you just see it as a natural progression?

Tamas (06:03):

What was interesting in my role at Facebook, it was actually I was leading security compliance for Novi, which was Facebook's blockchain initiative and eventually became their interim CISO. And as part of trying to figure out where to place the privacy program, the privacy program was placed with the CISO. So it was placed into my organization, but I always look at privacy in the matter of if you don't do security right, you can't have privacy. If you don't do privacy right, you also can't have proper security. For me, the two go hand in hand in today's world, because if you really don't focus on both, how can you build user trust?

(06:45):

How can you be in a world where you say, "Hey, consumer or business, we're doing X, but in the background we're doing something completely different." Privacy and transparency, et cetera are very, very critical for me and honestly, the transition is very, very natural because a lot of the things that you do in security inherently do help privacy. It's more of the other compliancy elements of privacy that you need to learn. There's a lot of things that you need to learn about it as well, but it's a very natural transition into one to the other.

Shane (07:21):

And I think placement within an organization is something that we hear all the time. We speak with a bunch of different companies that are on either end of the spectrum. For some companies security is very compliance driven. It's based on checklists of security controls and even organizational controls that need to be implemented. But then on the other hand, there's this new wave of companies that treat security as an engineering problem. So I'm curious if you think there's a right way of doing that. I don't really have a good answer for it myself, but if you were starting a security team from scratch, what would it look like?

Tamas (07:51):

Honestly, it really depends on way too many things, and I don't believe that there's one single answer that is absolutely correct. I'm an Engineer in a second line function today, and I'm doing really, really well. I'm doing the work that needs to be done as a traditional second line function. I've been in roles where I've been a first line function. I don't believe that just simply looking at these traditional lines is the path forward. It really needs to be what does the business actually need? We're in the business of protecting the company and providing inherently oversight on what is going on inside of a business.

(08:34):

Whether you label it as first line and say you also operate controls as well as oversight or you just provide oversight, is really going to depend on the type of business and the type of regulation that is expected. I'm not going to say one or the other is right, because in both cases you're going to have teams that just don't neatly fit into that particular model. And with overall this push into the DevSecOps world where there's this push to get as many things upstream as possible to give as many transparent controls and opportunities over to engineers as you can to make it as frictionless as possible for them, it's going to be a mixture of both worlds.

(09:21):

Honestly, the type of companies and type of other CISOs that I enjoy working with the most is the hybrid ones, is the one that really understand the compliance world, but also understand the engineering world. Because in a previous life, I always said my role is a Translator, I need to be able to translate between compliance intent and engineering speak. Because if you just look at compliance and regulation as a checkbox and you can only play within that checkbox, it's going to be incredibly hard to innovate, especially in the FinTech world or a very heavily regulated world. But if you look at it from the world of understanding the intent of the regulation and translating that down to particular controls, then you can actually be very, very creative with your solutions. But you need to be able to pull that back and translate that back to regulators around like, "Look, this is how we're interpreting it and this is how we're meeting it. Let me walk you through all the things we're solving by going this way versus going to traditional way." And I've had large success with taking that path.

Shane (10:33):

I think the point about distilling compliance and regulation down to simple rules or code is super interesting. Obviously if you look at infrastructure over the last number of years, developers shifted from click ops to using things like terraform or cloud formation to just define their infrastructure as code. Do you think that'll happen in security? And if yes, what's missing for that to be the case today?

Tamas (10:54):

Absolutely. I'm aware of several startups that are effectively working on what I call compliance as code. There are several startups that already have started more programmatically looking at IAM or programmatically looking at privacy programmatically, looking at security programmatically, looking at detection, prevent, et cetera. What I really think is missing at this point is a more solid compliance as code company to really come and revolutionize this space of really bringing these tools together in a manner where through a GitHub push, I'm defining what policies matter to me the most, what rules matter to me the most, and what are the automated evidence gatherings that I want to get in pars in an automated manner instead of humans just taking a look at the evidence, et cetera, and testing that is all good. So for me, it's a matter of time.

(11:53):

As I said, there are several startups that I'm super-duper excited about that are in the stealth phase right now, that are working on this particular problem. Several here in the United States, several in Europe. I think it's inevitable that compliance as code is going to be the next thing, and engineers are going to be able to write compliance rules and go from there.

Shane (12:18):

I completely agree with you. I think one of the challenges that I've been trying to grapple with in my head is that if you look at something like infrastructure as code, if you're an engineer on a product team that's looking to build something, you need a database, you need servers, you need some way of actually running your software. Whereas with security teams and just security in general, it seems like a lot of these security teams are spending a huge chunk of their time basically fighting entropy within the companies. Product teams with deadlines to get new features shipped, and infrastructure is a requirement for that. Whereas security is one of these things that, in a lot of companies, it's just very easy to kick down the road because it's not a problem until it's a problem. I'm curious how you've gone about either at Circle or elsewhere, just competing with product priorities and huge sprawling roadmaps that just need to get done and making sure that people actually implement this stuff.

Tamas (13:04):

So throughout my career, one of the things that I always said is security is not police. Securities actually enable and help the business succeed. If we look at it from the lines of, "Oh, we're only going to ship something if it has perfect security," just shut down your company, go home, that there's no such thing as a company with perfect security. There's always risk that you take on, and the lens that you need to put on is how much risk are you actually willing to take on? What is your overall risk appetite and how are you going to measure that? And systemically and objectively have statements that say, "I'm comfortable with this amount of risk." And if you can get to that particular level of maturity and language and process where product comes in and says, "Hey, we have this idea, go figure out high level risks."

(13:59):

Cool. We can distill that down. As a product idea matures, security risks start maturing as well. Privacy risks start maturing as well. Compliance risks start maturing as well in terms of what could theoretically happen. And then you can give guideposts of like, "This is how the highway or the product should be built. These are the things that you need to really be aware of." And the more you inform the product and the business about all the different ways things can go wrong and go well, it's going to shape their product roadmap as well. And as upstream as you are possible, and in the design phase, the easier it's going to be for them to design in that timeline the thing that they need to design and build. So security and privacy and all of these functions are organically built into the product life cycle. You're not competing for deadlines anymore.

(14:55):

Are they going to be able to implement everything perfectly? No, but that's also not the expectation. There's going to be always a set of requirements. There's always going to be a set of recommendations and always going to be a set of fast follows. And as long as you can say, "Hey, I'm okay with this level of risk," fast follow can be done, then fast following, and that is it. And teams are very much receptive to this because the approach you're taking is I'm enabling the business, I'm giving the business the perspective of how to actually get these things done versus I'm a gate at the end. Nobody likes a gate at the end. They want partnership at the front so they know we're on the same boat.

Shane (15:40):

Something we talk a lot about is day zero security. So just the idea that people integrate security into the fabric of the software that they're building. And you spend a lot of time in payment security, which I think is a particularly interesting instance of this, they're both from your time at Marqeta and I guess at Circle as well. If you're building a new product in, let's call it traditional payments, so you're handling credit card data, a lot of the security conversations and ideas stem from things like PCI compliance, but crypto is obviously much newer and honestly just doesn't really have this overarching regulatory framework.

(16:14):

So one of the phrases that you repeated a lot, there was risk and risk I think is the way that all these new companies when they're not being overburdened by these compliance regulations, have to think about. So if you're a two person startup and you want to build your product and you want to launch a debit card, you need to be PCI compliant. So you just follow 300 different controls. But I'm curious in companies that don't necessarily have that compliance requirement, how can we encourage them to just think more about risk as the core reason that they should do things? Because in a lot of cases, these are company ending events.

Tamas (16:45):

So looking at the web three ecosystem in general, one of the things that I noticed and I was very pleasantly surprised, is the industry is a lot more security forward than the traditional web two space. I've seen small startups, one or two person startups actually have a surprisingly mature security mindset when it came to actually building their product way more mature than, let's say, a random startup that just decides to pull certain tools together. And for example, they don't care about any specific regulation.

(17:25):

I know of a company in the past that I worked with that was under HIPAA and HIPAA is self-certification, so while they had the regs, they very well in private back rooms admitted that they're not 100% needing it. But in the web three world, even how quickly things move and how quickly you're going to get exploited, it's not the same thing because you're going to have either a nation state or a hacker or someone come after you really, really quickly and your money is gone and it is gone forever. In more the web two world, there's a lot more risk appetite overall from what I've seen. So I'm really happy how web three is developing in this sense with a lot more security mindset.

Shane (18:18):

I think one of the things that blows my mind a little bit about web3 and crypto in general is that if you look at traditional security, if you're securing a bank or a payment processor or something, defense in depth makes sense. If you just make it incrementally harder to get to all these different parts of your system, and even if there is a breach, you can probably claim it back through the banking system or whatever. If you look at crypto, the private key is effectively the money. So if you have a wallet and you've a billion dollars in that wallet, the security of that just gets distilled down to 32 bytes or maybe even less in certain cases if you're using a much older crypto system. It boils down to that much security. So to your point, once it's gone, it's gone. Does security end up being designed totally differently in a world where the security and safety of money is tied to an individual wallet, private and public keeper?

Tamas (19:08):

So inherently, yes, but that's not the direction I would love to see the world go to. As an example, this is my ledger, this is my "storage of funds." This is the thing that has those bytes for the things that I own in the crypto world, but I strongly believe that a lot of these security practices like the utilization of HSMs and specialized hardware for encryption and decryption and storing private keys in insecure well-thought-out, well architect and manner is something that we should be reusing not only in the crypto space, in the web three ecosystem, but also in the web two ecosystem. Because if you think a lot of these things that we've learned in the web three world, they can help with tenant separation in a web two application. It can help with privacy, it can help with IAM, it can help with all of these different things to ensure that data doesn't get commingled where data doesn't need to get commingled.

(20:10):

And to go back a little bit to your question, do we think a little bit differently when it comes to securing keys that protect money versus keys that protect something else? Yes, but the fundamental concepts are very, very similar. It's private keys and it's hierarchy of keys, it's PKIs, it's certificates, et cetera. It's really building on what we've learned in the past 20, 30, 40 years since UPS and SSL has been a thing and certificates have been a thing. We're just building further on top of it and utilizing additional technologies around it.

(20:50):

Now, the other thing in my view that has quite changed the landscape a bit is technologies like multi-party computation or threshold signing and all of the different techniques that you can utilize to really remove single points of failure. And this is also a technique that I really want to see how we can bring to the more traditional world as well, where a single compromise of a service shouldn't lead to compromise of data. There's always two or three things that we need to be compromised in order for you to get access to enough entropy for you to actually get access to decrypted data. It's very easy translatable into traditional sense and not only to finance sense.

Shane (21:34):

Because one of the things that people talk about a lot when it comes to crypto is that it's more secure, which I think is somewhat true, but it seems that everybody focuses on almost anything imaginable except for the key itself, and they forget that keys are the single point of failure here. And I think moving towards things like multi-party computation or [inaudible 00:21:52] secret sharing or whatever to spread risk is great. But it brings me back to a conversation that I think we had before where you mentioned something along the lines of how encryption and IAM are inextricably linked and that engineering work going forward shouldn't be focused on how you can do more things with keys, but it should be restricting access to keys in the first place where you're actually authorizing all operations that happen on it. I'd love to hear a little bit more about your views on that and if it's something that you've explored at all from a technical perspective.

Tamas (22:19):

I have, and I've actually worked with several companies to explore more of these ideas and more of what I call real-time access. The reality is the way we do just-in-time access, et cetera, and role-based access is I would call almost antiquated. We have the computational power nowadays to do real-time analysis and realtime views into should Tamas have access to this particular system that I'm trying to, let's say, either access SSH into or the database that I'm trying to access or the data that I'm trying to decrypt. Those decisions nowadays can be done in a super-duper quick manner based on massive risk models that could be built out. But what could be really, really cool is, let's say, I get an entitlement and that entitlement allows me to unlock an encryption key that is now able to decrypt that data set that is fully encrypted.

(23:19):

What that actually means I have now full traceability to actually decrypt that data through logs. The same way as with AWS, I know I can trace a routing from all the way from the internet where it hit my boundary all the way down to the deepest node because AWS offers these features. I want to be able to do that with identity as well. And honestly, the best way to do that is through cryptography and through encryption because every service that I pass through in order to get access to something just tags on a signature, tags on another signature and tags on another signature, and somewhere if I try to fake something, that signature becomes invalid and it's immediately going to alert into systems that, "Hey, I'm doing something weird." So I really think we're under utilizing encryption and signatures nowadays as it relates to detection capabilities. And yes, it's a lot of things to build, but it can give a lot of insight into overall behavior and how people are moving around different systems.

Shane (24:26):

I think you're preaching to the choir a little bit here. It's definitely something that we think a lot about in terms of our long-term product roadmap. But one of the interesting things you sort alluded to there is the idea of tracing versus straight-up restriction. A lot of security, I think people imagine it as you're trying to stop things from happening, but there's also a major element of seeing what has happened in the past, if there's a minor data breach for a particular account, being able to go back and see what happened and when. Do you think we're focusing on the right balance of these things and modern security? Are we focusing too much on prevention over tracing, or should it be the other way around, or do you think it's just right?

Tamas (25:04):

I still believe we're in the world where we're way too reactive and not focusing sufficiently on prevent, because if we would be primarily focusing on prevent, we would have tools like this already built in. So I still don't think the industry as a whole has what I would call single pane of glass available yet around what is going on in an entire ecosystem because everyone is still, and every company that I've worked with or chatted with, the main theme is we're still catching up to gain as much visibility into what's happening within our systems. We need to be shifting a lot more towards prevent and natively having these capabilities just ready to go versus just that this constant react mode that we're in.

Shane (25:55):

I think a lot of the time when people think about making a decision to proactively prevent breaches, they spend too much time just assuming that it's not going to happen to them. So I'm curious from your perspective, and this is somewhat masochistic I guess, but is there a data breach that you've heard of or worked on even just from a third party that you find super interesting or particularly scary?

Tamas (26:18):

For me, and I've been thinking about this quite a bit since we originally talked, I have to say Log4J was the one that really was like, "Oh, this is bad." But bad in the sense of everyone is impacted by this, and what really amazed me about that incident is how the different security communities really came together to share information as quickly as possible and as quickly as possible to implement different controls to actually mitigate that particular issue. Several security communities with other CISOs and other security professionals, and the amount of information we shared in terms of indicators of compromise, potential rules that may work, potential avenues that you can take in order to mitigate against the issue or slow down any particular issue or even how you can test certain variations of Log4J as it was being discovered by researchers inside of different companies really showed that this is a small community and the community is really about helping each other out to make sure that nobody really gets compromised.

(27:34):

Yes, let's say two companies may be competing, but their security teams aren't competing. They're helping each other, and this is insanely massive for me with something like Log4J or something that bad as Log4J was because it means, I have to say, faith in humanity restored because if we can't come together in a big security incidents like this, that literally could break the internet, then I don't know when else can we. So it was really, really a lot of work for everyone going through that, but it was really, really humbling to see how the industry came together.

Shane (28:13):

I remember being blown away how quickly the narrative in security media and even on Twitter and so on changed from we're all screwed to this is actually okay because security have come together and fixed this right now. So it's great that everybody reacted quickly, but I'm curious, do you think there's been more work done to stop this from happening again, or is it only a matter of time before there's another Log4J?

Tamas (28:35):

I'm always of the mindset that it's only a matter of time. And security breaches are always a question of when and not if. Are we going to have big things like Log4J again? I think the likelihood is going down and trending towards zero, but I don't think we're ever going to say, "No, it can't happen ever again."

Shane (29:01):

Very interesting. And shifting gears a little bit, just in general, I'm curious for your own developments, are there security teams or security products that you admire either just from how they've built their products or designed their products or just how they've impacted your life in general?

Tamas (29:15):

So there is a pretty interesting team that I've had the opportunity to visit several times, and that's the Microsoft security team, primarily the response center up in Redmond. The work that that team does there to really track ongoing attacks, not only in the Windows ecosystem or the Microsoft ecosystem, but globally and some of the attacks that they're able to tort down and really prevent real world harm, for me, has been absolutely inspiring. And they're an amazing group of people over there, and it is been really, really great seeing their operations center of all the things that are ongoing in the internet and how they're working to actually prevent harm. So I'm going to say kudos to the MSRC team.

Shane (30:07):

I think just the shift that Microsoft have made in the last number of years towards open source and being community first has been hugely impressive and at their team that really I aspire to be like as well or to be part of as well. I'm curious from a technology perspective, is there one technology that you're most excited about in security that you think will have a big impact over the next say five, 10 years?

Tamas (30:30):

Most definitely. I mentioned that I actually worked with quite a few startups, early stage startups, and I can't really disclose some of the things that they're working on, but the combination of web three and the combination of security and the combination of threat intelligence and what's going to be possible with this open and transparent world really has me excited about what's going to be possible if we properly leverage tools that are being built right now by, I'm going to say, the next generation of founders that grew up with web three instead of building web three. So stay tuned because I'm seeing a couple of very, very interesting companies on the horizon.

Shane (31:17):

I definitely will. It sounds very exciting. Tamas, it's been a great conversation. I really appreciate you taking the time. Where can people find you on the internet? What's the best place for people to get in touch?

Tamas (31:27):

And thank you for having me. It's been really, really absolutely a pleasure. Best place to find me is LinkedIn and Twitter.