Ep. #57, Integrating Security into Development with Neil Drennan

In episode 57 of The Secure Developer, Guy Podjarny talks to Neil Drennan, CTO at 10x Future Technologies. 10x is building the first cloud-native banking platform that can be used by large-scale banks in order to solve the cost and security-related problems caused by their legacy systems. A key takeaway from this discussion is the importance of building security into development from the ground up.

Find more episodes here


10x is looking for more talent to join its team with roles in the UK in London and Leeds. You can see their latest roles here


Neil Drennan


As Chief Technology Officer at 10x Future Technologies, Neil leads the design and delivery of 10x’s cloud-native platform. Neil has deep expertise in delivering great customer experiences through cloud-based distributed computing systems on a global scale. He joined 10x in 2018 from Amazon where he worked on their video software and AWS projects. He has also held senior technology and engineering positions at BBC Worldwide, Virgin Media, ITV, Sky and Deloitte.



Show notes


Many banks are still running on decades-old sets of legacy technologies, but the security and performance advantages cloud-native systems offer is changing that. Today, we’re going into the future of banking technology with Neil Drennan, CTO at 10x Future Technologies. His firm is building the first cloud-native banking platform that can be used by large-scale banks in order to solve the cost and security related problems caused by their legacy systems. Neil fills listeners in about his role in the overall mission at 10x before diving right into the topic of how they integrate security into their development practices. Often security and development teams find it difficult to integrate into each other because they are kept in separate silos from the outset. Things are different at 10x though as Neil explains, talking about the back and forth conversations between his different teams and their use of vulnerability dashboards to keep things transparent. Neil weighs in on the necessity for 10x to get security right, but the benefits of working with banks as clients because of their high level of insight into potential threats. We hear all sorts of amazing improvements for threat monitoring that cloud-native solutions can provide, making the legacy moat model look outdated indeed. A key takeaway from Neil today is the importance of building security into development from the ground up, so tune in to hear how he manages best practices at 10x.


Transcript


[0:01:26.4] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Today, we’re going into the future of the banking technology over here with Neil Drennan, who is the CTO at 10x Future Technologies dealing with banking. Neil, thanks for coming on the show.

[0:01:38.8] Neil Drennan: Thanks for having me, Guy.

[0:01:39.8] Guy Podjarny: Neil, we're going to dig a lot into this intersection of modern banking and security and how do you gel the two together well and work. Before we dig into that, tell us a little bit about yourself and what you do, we’ll dig into 10x in a bit, but also what was your journey getting into this spot.

[0:01:56.1] Neil Drennan: Okay, great. I'm the Chief Technology Officer at 10x. I joined 10x in March 2018. Prior to that, I ran the larger scale services at Amazon video globally and also worked with a number of AWS teams. So really, I looked at large scale distributed computing challenges for the end-consumer, trying to make sure that our systems were secure, performant and gave a very good experience to our end-users. Looked at everything really from architecture design delivery, all the way through to running those live services at a pretty large volume.

Prior to that, I held a number of VP engineering roles across different areas of the UK media sector. I was VP of Engineering at BBC Worldwide for a while. I also led TV Engineering at Virgin Media. I did a lot of stuff around Ultra HD and bringing live simulcast services into Virgin.

[0:02:49.3] Guy Podjarny: Dealing with a little bit of small scale projects over there and here.

[0:02:52.6] Neil Drennan: It's interesting.

[0:02:53.6] Guy Podjarny: Across the industry.

[0:02:54.5] Neil Drennan: Actually, it’s interesting because I feel that banking is at this intersection where media and entertainment was about 10 years ago, which is yeah, at that point online video was just about growing and many broadcasters were thinking how are we going to deal with this potentially hugely disruptive change in behaviors. I felt that the financial services sector is in a similar way, it's got a really set of old legacy technologies, that banks have been running on for decades.

Some banks have moved and gone digital by building API management layers and building mobile apps, but they've not really addressed the legacy problem at the core of the bank. Bringing the new technologies that we have available to us now from a cloud perspective into the sector, I think is a great opportunity to address the end-user performance, to address the cost base of banks and to improve the agility of the solutions that are taking out to consumers.

Although, they’re completely different industries in many different ways, the challenges I think are quite similar and as exciting. I genuinely feel that financial services is going to go through a similar journey to the one that entertainment has gone and there's going to be some big winners in that world and there’s going to be some big losers as well.

[0:04:03.4] Guy Podjarny: Yeah. No, it makes a lot of sense. I guess the challenges if media was a little bit more towards scale and delivery of quality over the web. A lot of it over here is about security. It is about how do you modernize while staying safe, keeping my data safe on it.

[0:04:19.2] Neil Drennan: A 100%. Yeah, absolutely. I think if you look at consumers’ needs of a banking platform, a lot of people’s first order concern is that my money is safe and that the people are looking after my money are doing a really good job. In the world that we live in today where the security vectors that attack patterns are continually evolving, you have to take a very different approach in terms of your security posture and the way in which you embed security within the organization to deliver the outcomes that consumers demand. We all know the issues of what happens if you don't do so well in that space. It has a dramatic outcome for the organization that fails in this regard.

[0:05:00.0] Guy Podjarny: Yeah, absolutely. I guess, let’s just for a context in that because we'll talk about how you build it. Tell us a little bit about 10x. What is it? What is your offering? What is it that you're building?

[0:05:09.1] Neil Drennan: Sure. We're building the first cloud native banking platform that can be used by large-scale banks, small banks to be able to run their services in the cloud, specifically on AWS to start with, but longer-term, other cloud platforms. This enables banks to address their legacy challenge around the cost base. Most banks if they're running a core banking solution, typically would have been built in the 1970s, 1980s. Plethora of different systems come in, museums of old technology really as our founder, Antony Jenkins would call it.

I think that we are very much bringing the new technology that is available in from a cloud native perspective into this domain. We're enabling banks to take our service and run their full bank on it. We build everything from a mobile application all the way down to data stream processing out for analytics purposes, the whole bank effectively in the cloud.

Now some of our clients take our mobile application, others build on top of a set of SDKs that we build, others integrate directly into our API management layer. Essentially, it's the whole piece thought from scratch, designed from first principles, architected in a way that enables domain-driven design and scalability of the platform with security from the onset. That's really been the really exciting challenge that – why did I leave Amazon? It was like, this is the scale of challenge that you dream about once in a generation. I feel very fortunate to have the opportunity to do this.

[0:06:41.9] Guy Podjarny: Oh, that definitely sounds like a massive undertaking to overhaul how that infrastructure of banking is done. Let's talk org a sec. You're the CTO. You run a good portion of it. Where does this security activity sit? How much of it is your group? Is there a separate security organization? How does security responsibility get enacted?

[0:07:06.1] Neil Drennan: I think security is everyone's responsibility. If I answer the question in terms of org structure, then within technology, I have 40 odd teams that are building out that different microservices and components that are required to run the bank. When we're building those services, we think about – we have a common tool, steam core builder tools that builds out the capabilities to enable those 40-odd development teams to be efficient.

We have a team on platform engineering, we have a team on infrastructure and release engineering. We have a team that sits against developer experience to make the developer more effective in their role. Then a support team, because we support a range of environments across our clients. That sits alongside independent security function. If you can think of the independent security function as the checks and balances on everything that we're doing, a quality gate to ensure that we have separation of concerns and that we meet regulatory obligations to our clients, but really I see it as security cuts across everything within the lifecycle. I use the language security by design and trying to emphasize that within our development community.

Whenever we're designing – architecting or designing a solution, we're very cognizant of how we're doing that in a secure manner. Then we have the process elements that ensure that security each stage of the lifecycle. We use a range of leading security tool sets, including Snyk, within our pipeline that are blocking to stop developers putting unsecure code into the code base. We have a set of tool sets that are continually scanning our environments that are alerting to our own seam.

We also have very close relationship with some very large-scale organizations who have their own seams that we provide them with the data to be able to correlate with what else they're seeing out else in the world. I think that collaborative approach that we have both internally within our org, but with our clients gives us much stronger than the sum of the parts really. It's been exciting to see how we're evolving that model, because I genuinely haven't seen that elsewhere. We're working that through and it's extremely exciting to see the benefits that's giving us.

[0:09:20.8] Guy Podjarny: Yeah, for sure. I'd love to dig into that collaboration with the security teams. Before we veer off I guess outside – within the team, like as you introduce something like vulnerability scanning, how does that external security team engage versus say, one of these platform teams, or tool building teams? Would you say it's primarily those internal teams that are doing developer experience and infrastructure and such that are leading it? Does the mandate come from security? How does that work?

[0:09:46.5] Neil Drennan: It's a combination of both. The security will have a posture on what our security standards need to be in certain areas and give us a very clear set of requirements and mandates that we need to look at. Then we're constantly evolving the architecture and the design, so we'll regularly sit with them and say we've got a design for this new component or new area. This is how we're planning to do it. What do you think to that?

We have all levels really. When we're using tool sets, when we're alerting off any vulnerabilities that are found, then that's transparent and open to everybody. Anyone in the team can go and see what the current state of vulnerability is across the entire org. We have a vulnerability dashboard in fact, that pulls the data from all these different sources and then makes it really super clear. We review this in our daily standup across all teams, so it's not just a functional delivery piece. It's functional, non-functional and security, that everybody all comes together every morning.

That means that there is this very dynamic environment, where we identify a problem, we can jump on it and we can fix it really, really quickly. That's been quite exciting, because I think in a lot of organizations I've seen before, you have the separate silo that is the security function over on the side somewhere and they find it really hard to engage in with the development community. We've really tried to break down those barriers and get a close working relationship across the teams. Important that you do have that separate checks and balances, right.

[0:11:11.1] Guy Podjarny: Yeah. It sounds like, it's almost like a customer provider type element, right? It sounds like security is – understanding the security posture and setting the requirements for saying well, you need to tackle this vulnerabilities problem for instance. Can we know known vulnerabilities, but a lot of the implementation and definitely the daily operation is done right alongside and those stand-ups and by the same teams that are building, tackling quality problems or functional additions. Is that the right way to think about it?

[0:11:39.0] Neil Drennan: That’s exactly it. I think it's good, because you've got that single view across the whole platform and you can make the relative prioritization decisions as a collective group. We've got a common problem. We're going to address it in this way. I think that really helps the teams become more effective and having that open communication channel across those teams is super, super important, especially at the rate that vulnerabilities are coming up today. You can't be effective without that openness and transparency of the data that is coming out from all these great tools.

[0:12:08.8] Guy Podjarny: Yeah, yeah. Fully agreed. It sounds, indeed, truly scalable. Let's talk skills a little bit. For that to work, did you need to adapt anything about the type of people you bring on to the team?

[0:12:19.9] Neil Drennan: Yes. Yeah. I mean, I love to think most problems with an organization start with people. My HR director is going to get upset with me for saying this, but I think you start with the right people and then the process and the technology follow. I think that when looking at this challenge, I went out to find someone from a threat modeling perspective, just an example. His last job was five years at GCHQ and doing that type of activity across a number of government intelligence agencies that you can never tell me about.

That's the type of person that I think we sought out to work within our organization, because the type of threats that I think we face are the internal threat, the external threat and the scale of clients that we work with and planning to work with are state level actors. There is this existential threat on our company if we don't get this right, and the threats are various and always there. You need to scale your organization with the type of people that can help protect you against those risks.

[0:13:22.2] Guy Podjarny: Yeah. Yeah. Interesting. The security organization exists there off to the side, but you are hiring specific security talent into the CTO work into the technology organization, because you do need that more embedded in as well.

[0:13:36.3] Neil Drennan: Exactly. We have it across both. I think that helps then with a really great level playing field and the conversation between security team and engineering functions. Seeing that collaboration across the two evolve has been really great. I look forward to seeing that happen more.

[0:13:52.3] Guy Podjarny: Let's maybe go down a level. You talked about security by design and building things from first principles. What are some examples of that, whether it's on the tooling side or on the architecture of some tools you've built in, or decisions you've made that you think are, I guess manifestations of that.

[0:14:11.0] Neil Drennan: I think the classic thing is if you look at the world today, if you're a bank, you're running a whole range of legacy platforms, right? Somewhere up in the region of 4,000 plus applications on a heterogeneous architecture that's running usually in active-passive data centers, separated by a minimum of 30 kilometers. The classic we've built the 10, we've put the network in, we're running servers and it's all big. Runs into the order of if you're a 2 in 1 bank, billions of dollars a year to run your technology and operations services and takes a long time to build out new capability.

If you want to build a new data center, you're looking at billions of pounds worth of cost and several years of doing it. Whereas now, obviously within the cloud, we can spin up entire environments in no time. We actually spun up an environment in Sydney a few weeks ago, put a whole bank into Sydney in less than five days and the rate determiner was some of the third parties we were using. Not our ability to run a terraform through on AWS. AWS’s API was the rate limiting factor on us and we're talking to AWS about relaxing that a little bit.

[0:15:17.8] Guy Podjarny: So neither would scale.

[0:15:19.0] Neil Drennan: The speed at which you can do this now is transformational compared to the legacy approach. I think in couple with that from a security perspective, those data centers, the security posture and the way in which banks thought about security in the past has been very much the old moat problem. We’ll secure the edge and then everything out. As long as no one gets in around the edge then okay, we're all right underneath it. Whereas, the tooling that we've got available to us in the cloud native world is completely different.

We can continually scan everything that we're doing on all of our environments, if I take down line as an example. We can look at our performance against NEST. We can look at our conformist against ISO 27001 constantly all the time across all of our environments. The minute anything comes up, we've got auto-mediation rules that can kick in and help resolve that problem before it becomes a publicly known issue. That's just completely different from the way that things used to be done.

I think the first thing is that the technology that is available now is transformational in the things that you can do, your observability on the platform is completely different from where it was. Knowing the unknown becomes far easier in the cloud world than it does on a legacy architecture.

Then from a process and delivery perspective when we're designing and delivering code, when we've got our release pipeline, we are all running scans with Snyk on open source run abilities across 40 teams on every piece of code that gets put into the pipeline. In fact, we've been doing that in a manual – It's an automated way in which the processes run and it highlights our vulnerabilities. Next week we're actually blocking it into the dev pipeline, so code won't be able to be pushed to our lowest level environment if it doesn't tick the box.

[0:17:05.8] Guy Podjarny: Great moment.

[0:17:07.6] Neil Drennan: We're already excited about that next week. It's a big week for us doing that. We've been running in this mode where we've been actively monitoring each day, the results, and then dealing with it, but it's going to be blocking for next week. It's pretty cool.

[0:17:20.8] Guy Podjarny: Yeah. It’s very cool. Definitely, it sounds like the evolution of building the practices to have these tools built in. They’re built into the stand-ups, they're built into the pipeline, the continuous monitoring aspect of it and just built into the way that you develop software, which I think is really good. I always love to think about the concrete tips that people can adopt. It sounds like very much the embedding of the vulnerability dashboards as part of the – not just the pipeline, but also the standup review sounds like a great practice to have, as well as the comment about hiring.

It can't all be GCHQ. For US friends, that’s the intelligence body here in the UK. Somebody with security backgrounds to actually help drive those activities inside the technology organizations. That sounds really, really quite powerful.

[0:18:10.4] Neil Drennan: Yeah. We've adopted the stride framework as well in terms of application threat modeling. I think that there’s another concrete tip that we found that to be really useful. Getting teams sitting down with their pack of cards and then playing out different security vulnerability scenarios is a really engaging way to get the teams excited about security and thinking about the right things on a continuous basis. Yeah, I'd really recommend doing that.

[0:18:34.5] Guy Podjarny: Before we opened up this element of working with customers and these are big banks that have very significant compliance requirements, right? Compliance is I guess doesn't have the best reputation of being the most nimble and agile in its own right. You need to on one hand, drive agility and drive speed. On the other side, still introduce – remain compliant and fit those needs. What's been your experience? How do you try to serve those two masters, if you will, and be compliant while keeping up this pace?

[0:19:09.2] Neil Drennan: I think a lot of it comes with our tooling and being able to provide evidence that you're executing the practices that you talk about. Embedding that tooling, embedding the processes in place gives you – there's a lot of benefits in doing that. First, you get conformance in terms of the way that teams operate. Second, it becomes easy to evidence, because it's just naturally part of the process that you're doing every day. That builds a lot of confidence in compliance teams and risk management teams is my experience.

Thirdly, I think that a lot of the tools and techniques that we're using here are fundamentally more advanced than legacy approaches. By the mere implication that we're doing these types of things oftentimes, compliance and risk management organizations like – didn't do that today. This is great. Well, how do we embed this in the rest of the organization? Because what we're seeing here we really like.

It was one of the areas I was probably most concerned about coming into financial services as an industry. It's one that I've actually enjoyed the most perversely, because some of the teams that we've worked with our clients are so on the ball with what's happening within a marketplace and what threats were exposed to that, they've been able to work with us really closely in terms of on the design elements, as well as compliance side of things. That's helped drive up our maturity as an organization really, really quickly.

When you think if you're working with large scale banks around the world, they've been exposed to these threats day in, day out for years. There's a lot of great learning that can be applied from that. Although, the method in which you protect yourself nowadays is different. The type of attack patterns are the same.

[0:20:54.5] Guy Podjarny: Yeah. I think that's really interesting. You talked about collaborating with them by actually plugging and pushing data into their systems for them to analyze? Is that correct?

[0:21:04.2] Neil Drennan: Yes. Yeah, yeah. This is the novel approach. Obviously, we get logs off everything in terms of what we're observing from the tool sets that we're using across all our environments. Those are real-time streamed. We can real-time stream those into our clients’ seams. What that enables them to do is to be able to aggregate all of that data and information across the 10x platform for their environments with everything else that they’re seeing out in the world.

With that then super set of data, they can – anomaly detection becomes better as a result. They've got known threat vectors that are coming in that they've known about for a while that they can then look for within the data set that we have. That's one of the things, the capabilities that we built out a while ago and we've seen it used to great effect. That doesn't mean that we take any less of a relaxed posture. We have our own seam. When you couple that seam with client seams as well, then it becomes a much more powerful proposition in totality.

[0:22:01.4] Guy Podjarny: Yeah. I think the model is really interesting. You almost wonder whether as soon as you're a part of the operation, even if you're a third-party service that's not quite at the core as you are, whether these types of models are feeding this information into the customers, in this case, the banks are seam surrounding is something that would grow in demand, because as you point out, you're separating out the understanding of the threat from the ability or the methodology through which you protect against it.

As more security controls go into the development surrounding, that surrounding knows how to build software, knows how to build it resilient, but don't necessarily understand security as deeply. That collaboration with the security side and feeding them information so they can be data-driven might be something. You can envision how banks might demand that of more of their vendors or services overall.

[0:22:52.6] Neil Drennan: I really hope so. There’s no reason why it can't be done. I think we've sort of proven that it can be. I hope others follow that direction. I think if we can improve the security landscape in this area by providing more data, more real-time to enable better decisions across the organization, then I'm all for it.

[0:23:11.9] Guy Podjarny: Have the banks been – have they been receiving that well? Have they been positive in their outlook? Do they have to scratch their heads? It's like, “What do you mean you're going to send me data?” Was that demanded from them?

[0:23:22.9] Neil Drennan: No. It’s very much been a again, a collaborative approach, right? They see this as an opportunity for us to work really closely together. It's been across both sides. It's willingness to try out this new thing. If it works as we've seen it has done, then great and we'll keep on building and iterating and improving it over time. That's why I see it now as when we're talking about it probably 18 months ago, we were going, “This is new. We’ve not done this. It feels slightly uncomfortable. Is it going to be okay?” Now looking back now, it's just the standard. We’ve set the bar another level and I look forward to every time pushing that higher and higher.

[0:24:01.5] Guy Podjarny: Yeah, that comes from as you pointed out, thinking from first principles about what's the right way to do it. This has been great, Neil. A lot of great insights and tips and definitely an impressive set up. I like to ask every guest coming on the show, if you have one tip, one bit of advice or maybe a pet peeve that you have that people are doing they should stop about security that you can give a team looking to level up their security foo, what would that be?

[0:24:27.6] Neil Drennan: I say, security by design. I think if you start carefully thinking about how you can embed security across your entire organization and the processes, the way in which you train your developers and the tooling that you enable them to use to be able to identify and fix problems ahead of them being an issue, I think that's the thought I would leave people with.

[0:24:50.7] Guy Podjarny: Yeah. Well, that's definitely excellent advice. Well Neil, this was a pleasure. Thanks again for coming on the show.

[0:24:55.3] Neil Drennan: All right. My pleasure. Thank you very much for having me.

[0:24:57.4] Guy Podjarny: Thanks everybody for tuning in and I hope you join us for the next one.

[END OF INTERVIEW]


MyDevSecOps ©2019 POWERED BY SNYK

The MyDevSecOps community is powered by Snyk Ltd. Our aim is to create a vendor-neutral space to share knowledge and best practices related to software security.

avatar-transparent.png
  • White Twitter Icon
  • White YouTube Icon