Eddie Knight, FINOS Foundation | Open Source Summit Europe 2022

This is texturing TV. Hey folks, we're back at the open source Summit in Dublin. And we're here with Eddie Knight who's the chief developer advocate for sonotype?

And he's also a maintainer of the Finos project and we're gonna be talking about infrastructure as code and the financial services space and how it might be all coming together in new and interesting ways Annie welcome to show I'm really excited to be here. This is awesome. It's also a good break from all the talks that have been going on.

There's just like information overload this week. This is true. So you guys are working on a project that involves setting up some infrastructures code tools is a brand new tooling or as an extension specifications that I think will address some of the security concerns people have been having with those tools for the financial services space.

What do you guys up to and will others benefit from this? Yeah, okay. That's a lot.

Yeah, last one your last question. Can anybody outside of financial services benefit from this? Yeah, absolutely.

So what we're working on is defining. What it looks like to deploy infrastructure inside of a regulatory highly regulated environment, right? We're working with feedback that we're getting from financial institutions.

So all of our members, we've got a long list of banks that are members and other finance that are involved in the phenos organization and we're able to take feedback that we're seeing from them Consolidated into documentation. We're doing a lot of extending Beyond just like the CIS standard and from that once we have all those definitions in place. We're working with hashicorp actually to create a lot of terraform modules and we're working with red hat to do a lot of configurations that are making things available in that locked down way that is ready to use or at least A lot closer to being ready to use than traditionally when the financial services are trying to deploy infrastructure.

One of the dirty little secrets of our industry is that a lot of those cloud services are misconfigured because people are using these tools and they don't really know much about security. It was kind of an elective for most developers and they generally didn't take that elective. So, you know, how will we address this issue as we go forward and how easy will it get to fix this problem?

Yes, so I feel like you're you're kind of referencing the the shared responsibility model with the cloud providers. Right? It's it's not their responsibility or legal obligation to provide something that's totally locked down.

Right? It needs to be configured. It needs to be customized extended.

You need to you need to know what you're doing to lock it down and they're going to keep their stuff secure you need to keep your stuff secure even though it's on their system. They're not responsible for it. And the problem that comes in which is what you just mentioned.

Is that a lot of us, so I came from Front End development and then I went into backend development that I went into Autumn engineer engineering before going into like SRE and devops and along that way and no point. Did anybody sit me down and say this is the right way to secure everything. And so they're probably been times where I was like that's safe enough.

Let's secure enough right and ship it but inside of the financial services organizations, that doesn't fly, right we need to do a lot more work a lot more regimentation. And that's why we have these like miracles to get 30 days like, oh my gosh, you deployed something in 30 days, like that's amazing. Right usually takes like three months six months, like some of us are getting it down pretty low to where once everything's finished 30 days later.

We can deploy it. It's like that's that's really slow especially outside in like the Ubers of the world. Right?

These are really slow deployments because there's so many boxes that we have to check. There's so many conversations. We have to have I have to explain it not just to my peers my colleagues, but I have to like write an entire document and submit it and get it reviewed by other people and organization that I've never met before they need to look through that and say yes, I agree with you that that's a good way to secure it.

So what we're working on inside of Phoenix is Trying to streamline that get stuff that can be put into the financial service registry that will cut some of those Corners. You don't need to explain it anymore because you're using 90% of it is coming from a boilerplate and kind of closing that Gap reducing that time that almost sounds like I've been driving at 25 miles an hour and now I'm up to 40 and I'm going wicked fast wicked fast. Thank you.

Yeah. Yeah, just like, oh my gosh, I'm going 40 miles an hour. Yeah.

That's right. You nailed it? As we go along we hear a lot about shifting security responsibility further left, but we also have sres and the question I've always had is how far left do we ship security versus do we get like security Engineers who do that function the same way sres do that function and maybe they take care of the security issue on behalf of the developers.

Oh man, nobody's ever gonna agree on that. Right? So so whatever I say sure the audience is gonna come in and be like, well no think about this thing about it, but for my take We have really really.

Skilled intelligent well-intentioned folks in the security and architecture spaces that are very keenly aware of the requirements and we have our developers and our infrastructure Engineers that are really really keen on how to provide those things and bridging that Gap doesn't necessarily just mean grabbing somebody from a team and saying, okay. Well you do that other job now, it has to start with the communication lines. It has to start with just not scheduling meetings, but overlapping the workflows and just creating opportunities where both teams can say.

Hey, I am familiar with that. Let me pick up that part not just like hey security you need to come learn infrastructure deployments like I don't know. That giving other people other jobs is actually the solution I would say communication and overlap is the solution.

That's my take on it. What is the state of the relationship between the security people and the financial services space in the developers? Because historically there's not have been a lot of love loss between the two this Security Guys kind of look at the developers and go, you know, you're kind of the root cause of all my problems and and then the exact same quote comes the other way, right?

Yeah. I've been in conversations where and you know what let me just say me. I've been guilty of sitting there and being like these incompetent fools right on both sides of the table.

I've been like I've been on this side where I'm sitting there as an infrastructure like SRE focus in the in with the security guys, and we're looking at what's coming from App Dev and we're just like these incompetent fools, right and then I've been in conversations like with other app devs and we're trying to deploy something we're trying to ship something and we get some pushback where they're like, no, you can't do that until you get your VPC configured like this and we're just like these incompetent fools, right? And so there's a lot of Of that of just like the other the other guy is the stupid one and that's what I say. We just I mean we need to overlap the communication.

I think that's happening. I think we're getting closer to that. We're we're getting a lot more into the places where the the big institutions are learning like we need to open up those lines of communication and it's because we're at a point in history where leadership is becoming familiar with the fact that they have competent employees that that Steve Jobs quote of I'm not gonna get the quote right but we we don't hire smart people to tell them what to do.

We hire smart people and get out of their way. Right? Like I think that I've seen more and more Bank leadership understanding this concept of like I hired these people for a reason so I'm going to kind of just clear the obstacles for them.

Is that Universal? No, is that the norm maybe I'm too optimistic in saying so but I think we're getting closer to where we're trusting the professionals to have the right conversations to bring the right information to the table and I think it's coming a long way. Is there a smart way about doing that or should I just take them all and throw them in a room and lock the door and see what happens?

Yeah, please. Yeah. Yeah, bring them up when you come back.

But you don't think the security people should learn how to program per se it doesn't sound like that those conversations are happening. Okay? I would not be an advocate for that necessarily.

I think that when you come into programming from a security mindset, you're gonna be a lot more focused on scripts when you come from an app that mindset you're gonna be focused a lot more on objects and Systems, right and both of those have their place but just asking the security guys to just suddenly one day wake up and start writing code the way that appdev does the way that infrastructure does it's gonna be really hard. It's gonna be a really big shift. And so what I would say is like bring those skills to the table and bring the the object-oriented programming the like really in-depth knowledge that different industry professionals have related to programming bring that to the table.

And then have the solutions come from this table where we have these shared goals and diverse skills. We talked about the shared responsibility model. Is there more that the cloud service providers could be doing to help this whole conversation along?

so we're we're seeing a lot coming out of the cloud service providers on. Just being aware. Of how much work is necessary for the financial institutions inside Phoenix.

We've Google's a member AWS has come out and contributed to some stuff on occasion. And actually I'm not sure about their member status. Don't quote me on that.

Sorry about that, but we have seen them like actually wanting to engage with the community and there's this awareness that it's been really difficult for for the financial institutions to use their tools. Like Hey, we're making this available to you you can figure it and then they just keep getting phone calls. Keep getting phone calls keep it in phone calls, and I think that that awareness is manifesting in Steps being taken to streamline stuff being taken to automate stuff looking for tools looking for Solutions.

We're not we're not across the bridge yet. But I think that the cloud service providers, especially the two that I mentioned have have started on the bridge. They're like, hey, we need to be going in this direction.

We need to be shifting things and IBM's a huge red hat is a huge contributor in our community because ansible is a huge infrastructure automation. I mentioned hashcorp. It's terraform Indigo red hat with ansible is also a big part of the work that we're doing right now.

And so so they're showing up and they're trying to really streamline that process but we're definitely not across the bridge. There's a lot of more work that needs to be done from From all sides. So the bad guys are getting really good at using penetration testing tools to find these misconfigurations.

So how long a journey are we on? And you know, when can people think about maybe closing this Gap? Yeah, when it comes to penetration as we're familiar with it.

I think that I mean that's never going to stop right? We're always going to be there but there is a degree to which that's not what's causing the fire drills. Right, that's not what's I mean log4j is why nobody got a Christmas break because the log4j had a vulnerability and nobody could keep track of where they'd installed log4j.

And so they needed to go in and find every single place where have I installed log4j across my entire organization and how do I get get it updated? I think inside the US 90% of Financial Services have updated all of their log4j installs from vulnerability but a hundred percent are saying that they're done with it. So there's there's a there's a gap there somebody like one of you guys is not telling the truth or you're just not aware of a few of the installs total.

So sonotype manages Maven Central we can actually see the downloads and After everybody said like yeah, the log4j incidents done still 40% of installs are from the vulnerable version of log4j, which is a supply chain vulnerability. That means that if you are using software if you've installed log4j then any script Kitty with instructions from a Blog can come and exploit your software. All that has to be true is that they are they have those instructions.

They're targeting you and you use log4j in your toast. That's a really big deal. Right?

And so that's why all all week. We've been hearing about the supply chain. So traditional penetration is absolutely something that we need to be aware of but I think we also have a lot of skills in that area.

A lot of people are coming to the table with an awareness of how to respond to these things. Whereas the supply chain dependency is a relatively new topic. It's like really skyrocketed over the last two years.

So many times has been doing it for 15 years. We've got a whole software suite on that. I'm not gonna go into that but it's that it's the topic right now.

It's the Hot Topic. That's the thing that is going to be causing a lot of the gaps that need to be closed. infrastructure is code is where you come in and prevent a lot of those gaps and that's why inside of CFI inside of phenos.

It's really exciting to be able to be setting stuff up that can be consumed by the financial services. So that way when they're consuming this we can kind of help prevent those vulnerabilities the supply chain attacks that are happening. From bleeding in and causing those gaps inside the banks.

Do you think that the Regulators at the SEC in places like that are starting to understand the issue about the software supply chain, and they're going to start showing up asking some rather pointed questions. So yes, especially after Equifax. because that was just like a blatant like huge issue that was like you didn't update Apache struts, right you didn't up to you didn't update struts and now everybody's social security number just got released to the dark web.

Like that's that's a huge issue because you didn't update your software. There is a known vulnerability. You didn't know that you had that vulnerability because you didn't to the diligence to track it.

And so then you didn't do the update and now the entire country is just like in upheaval like everybody's freaking out. So after that there is this fine of like, what was it 700 million dollars. Don't quote me on that billion.

I don't know. It was a number far larger than I can imagine. and in the aftermath of that The Regulators said we will we will use the full force of the law to pursue anything like this in the future.

And so there's like this warning. That's like hey if this happens again like you guys like we will burn you to the ground is kind of the the message that's coming in and then the White House comes in and says, hey supply chain security is extremely important. You need to have your software building materials.

If you're doing any federal contracts inside the United States, obviously, we're in Europe. So probably should be thinking out beyond that, but that's the experience that I have and And yeah, a lot of the a lot of the regulation is starting to shape up in the area of like, okay, we've talked about the penetrations that we talked about your firewall on your network and everything else. But now we need to start talking about your supply chain and securing your software supply chain.

All right, so we're at the point where this is becoming issue you can ignore The developers themselves, they still seem to think that somebody's magically gonna take care of all this stuff for them in the in the platform somewhere. So what's your best advice to those folks about how to get engaged with this and start thinking about it so that you know, you're not the last kid in the block upgrading your log for Jay instance. Yeah.

Yeah, definitely. I think just being aware of the topic what conversations are happening in the topic. There's a lot of tools.

Like I said in the last two years. This has become all the hotness, right? A lot of innovation is happening in this space.

The be aware of that the Linux Foundation has some trainings on like what is an s-bomb. Why do I need an s bomb some tools are coming up recently. We've got a free tool that you can use to generate an s bomb on a GitHub.

It's called lift. So there's there's some tools that are that are out there. There's a lot of really good competitors to ours that are addressing this space.

So there's just options Galore what I would personally advise against is Homebrew solutions for this specifically in the area of identifying vulnerabilities because this is something that we've seen happen is that Equifax thought that they secured it. They thought that they had it good, but they didn't have a research arm. And so the you're gonna need to be working with somebody who has a research arm that can actually be in front of this stuff instead of asking Alex in the other cubicle.

Like hey, how are cve's like, what's the what's the dashboard looking like this week? We can't just be like relying on the sock to update us when this kind of stuff happens. We need to have some more security tooling that's actually integrated into the entire development life cycle that that needs to be happening and So the s-bomb is essentially the equivalent of a list of ingredients that are in my product or whatever and people can look at that and say oh well, I don't want to consume that or that's not good for me because I have an allergy.

Yeah, that's perfect analogy. Yeah, and it's the kind of that process. But so I get all this data from all these people and it comes up in this s bomb and then I stick it in a repository and I check the box.

Now. What am I supposed to do with all this stuff? Yeah.

Yeah as a developer to you like your job's done. The best mom is a communication tool. Now the organization the system that you operate in needs to communicate with that.

We need to get it integrated into other tools that are actually going to say like, okay based on what you're telling me. This is how we're going to respond. We're gonna red light green light yellow light based on what we're seeing in here.

if you only ship it at the build stage, like you're going to check that Federal box for the us, but I think that if you want to get ahead of these International regulatory standards and actually take like Mmm, make full use of the knowledge that's out there the experience that we've been gaining over the years that the industry has been gaining. Then you need to be integrating your s-bomb your bill materials and Other tooling like through your entire life cycle you need to be so if you can get something in your IDE, so that way your developers win. Their coding can be aware of the best practices like, oh I'm importing something as an own vulnerability.

If you can get something at the pull request stage like oh cool. I auto-generated my my s bomb. So when I changed my code the s bomb is getting updated right just integrating it every single and then obviously build and release is the is that's the big one, right?

We need to have that spot when we're releasing it but there's there's different places where this needs to be integrated. I'm sorry, if I lost track of your question. No worries.

No words. Hey guys, so you heard it here first. Basically, we're about to play a giant game of red light green light.

One two, three. Any thanks for being on the show. Appreciate it.

Thanks so much.