Andrés Vega, Investments Unlimited | DevOps World 2023

This is Textron tv. Hey, welcome everybody. Welcome back to DevOps World in Santa Clara, Silicon Valley.

And of course, we're doing our interviews. We have a lot of great guests, including our next guest who's Andres Vega, um, author of Investments Unlimited and mm-Hmm. Of another company we're not talking about yet.

Someday you'll get to talk about soon. So soon. Okay.

Good. Soon. Hopefully a little bit of stealth work.

So, welcome, uh, congrats on the book as you and John and everyone who contributed to it. Thank you. Yeah, it was a great adventure riding together, just brain melding, exchanging our stories, the different experiences we have lived, eliciting that from others and capturing all, not, not a single story, but this convergence of what we'd all seen different places we had worked at, what we had learned.

And oftentimes, well, I feel we, we were partly remiss in calling the book The Mino Project, which was the title of the session this morning. Yeah. Mm-Hmm.

Yeah. It would've been consistent with the titles in the series, but also the story of Mino. 'cause compliance is elaborate.

It is a book about navigating compliance with modern software, and much like Theios going onto the maze to defeat a beast, but not necessarily knowing the way out. So hoping to lay down that threat. So others embarking on the same journey.

Many organizations have built broken systems, but if we are to build it right, how do we backtrack from there, share those learnings, make it somewhat abstract, generalize it so we can automate not the what, but the why compliance has done the way it is in first place. You know, we, the environment's changed so much, I think just in the last five to 10 years with how much we've moved from DevOps being a developer, you know, shipping software down a pipeline to CICV. Maybe it goes into production to thinking about the kind of full SDLC mm-Hmm.

And what are elements of that, whether it's the security parts at play in that process, but also, you know, compliance isn't, isn't a result. It's a, it's, it's, it's actually a thing that's an outcome of actions that you take. Right?

Well, at least you hope it is. You wanna move from it being an activity at the end to something that is an outcome of the work. How, how would you assess the state of really kind of thinking about security and compliance as part of a full SDLC mm-Hmm.

Versus, um, hi, I am from auditing. I'm here to help and I need this data and you need to fill out my stuff in the next three days. 'cause I gotta turn it in on Friday.

Totally. Well, the, the act of compliance is proving you did what you said you were going to do. Mm-Hmm.

And that in itself is both a goal and a constraint. You're bounded, but you agreed, whoever the governing body may be, whether that's a internal entity, internal auditing and management, or whether you're in a highly regulated industry vertical that could be both the accreditor, the story. Uh, we have a financial services organization regulated both by the office of Controller of currency.

That's an organization, not many folks outside of banking would've heard of and the SEC mm-Hmm. So they've exceeded the threshold of the market cap where they enter to be highly regulated. It's an organization that's far down a road of mature DevOps practices.

So they're doing all the DevOps things right. Yet they're not complying Mm-Hmm. They have, uh, within banking, if you're not doing things right, the regulator will bring it to your attention by a notice called an MRA matter requires attention.

Mm-Hmm. They've attach 15 RAs open throughout the year, and then they get what follows. An MRIA matter requires immediate attention.

Mm-Hmm. If you don't take care of that, you don't pay attention to that consequences, you get a cease and desist. Right.

There are financial organizations that have received, received a cease and desist, and as a result, they have to pay millions of dollars in civil money penalties or, uh, they have to get outta business and they sell their assets to another bank. Mm-Hmm. M and a are, are certainly another instance where, uh, there's a lot of regulatory scrutiny, uh, and organizations oftentimes don't even have the language.

We haven't formed the concepts and the words to, uh, talk with the other side of the wall much like we had in DevOps. Mm-Hmm. So there are, there are a number of parallels.

If we go back to the time where, when DevOps originated what was happening in the world of compliance, then, uh, we had come out of the financial crisis. Yeah. 2008, 2009.

So there was heightened, uh, regulatory pressures to do better. So, uh, history wouldn't repeat itself anytime soon. Uh, you go down few years, cloud goes mainstream.

Uh, the complexity of applications and their sprawl growth in the large orders of magnitude. So a second wave of compliance, and we start to see the first products around compliance emerge, but no combination of products today is gonna get you the, the outcome you seek. Mm-Hmm.

So we are onto this third wave where we must reassess following first principles from the ground up. How do we polish this rough, sharp edges between the different systems and how do we leverage, uh, progressive delivery practices? How do we reduce the batch sizes if we are trying to deploy software into production that does not meet the objective?

And we know that it's gonna require a refactor or even a re-architecture of the system that we know much earlier, rather than in banking, for instance, the window approval can be up to 12 weeks. Mm-Hmm. So after the auditing teams have reviewed all the screenshots of all the spreadsheets and pages and pages of questionnaires, if we have grown the observability, the telemetry, the interfaces where the machine can tell us, Hey, this breaks, uh, your regulatory standard or the framework.

So, you know, right there and there, and it shortens that feedback loop. Yeah. I think it's o one things that I've learned having gone through audits and certifications, is what you said is that most of them are yes sir laws, and you must do these things.

A lot of it is saying you're gonna do a certain set of things and then you have to prove that you actually did that. Mm-Hmm. So in the case of like security, if you're gonna issue digital certificates, well, what's your process?

Is it documented? Do you follow it? And do you have the data to support it?

Okay, great. Then we'll, we can recertify you based on that and the evolution of it. Yeah.

My, my roommate in college actually went to work for the FDIC, so I'm familiar with those. Not that I've gotten those notices that didn't, that didn't work for that part of banking. But it, it's, it's interesting.

It gets your attention. It gets, well, maybe the first notice may not, but you know that that action requirement will get your attention. 'cause banks do know the next thing is very consequential.

You don't always have that in other industries. Right. You don't.

So it isn't as tangible of, you know, we can still wiggle it. We can kind of say we are and maybe we aren't fully. Yeah.

Um, I, I'm wondering how do you address that? I mean, it was, I understand why you picked finance. 'cause I think that that's a little more cut and dry.

I about other industries that it's not so cut and dry, let's say like Right. Retail or manufacturing or something like that. Uh, life, life support systems and, and healthcare safety systems such as avionics, uh, federal government programs, weapons systems, uh, there are many, many sectors that are highly regulated and they have their respective standards and frameworks.

Uh, banking is one of the most tedious and cumbersome. So the thesis is, if we're able to prove success there, the principles, if not the details will also translate and we can cascade from there. Mm-Hmm.

You did talk about security and for a while, particularly with the more recent, with the emergence of ai. Can't we just write a program to do it? Well, the challenge is, unlike non-security events or non-compliance events, let's talk about reliability.

Random failures, random failures based on upon simple heuristics. You can write a program, uh, to take care of that. But think of a game of chess.

You can, you can write a program to play the machine, and that program is, is likely to win, like un contended every single game if you codify what the rules of the board, no. Having a perfect understanding of the board. Now, if you put that game, that program to play against the human, it doesn't fare that well because there's, uh, the uncertainty mechanics, what people in, uh, threat modeling or war games called the fog of war.

Mm-Hmm. You don't know what's in your opponent's mind. Right?

So there is the fact that you're playing an intelligent adversary, and that adversary may not even be adversarial, maybe a developer trying to get their work done. So if their computer doesn't give them the response they expect, because there's compliance guardrails, they're gonna find a way to go around it, shadow it. And in a adversarial setting where when you're defending your organization's assets, you're playing this, these actors that are stitching and chaining different attacks, not following, not following those heuristics of the program.

So that's what makes it slightly more challenged and there's no, uh, a slide of hand in the, in the heuristics to accomplish. So. Very cool.

Uh, la last thing I'd love to get your thought thoughts on, do you think AI can play the role of, kinda like we do chaos testing, we do fuzzing, we do things to try to simulate unexpected behaviors, but, you know, anything you, anything you script or, or automate is probably, you know, what the expect the expectation of what it's like when that's happening. You, you in theory could have, you know, something like an AI engine. Maybe it's a gender to AI engine that might come up with scenarios we wouldn't think of, or it's, it's taken that from data we, we don't have access to or we don't kind of think in those paradigms.

Do you see, is AI a tool to help us sort of push the edges of what, what we can test and validate? I, I believe there's plenty of room to augment. There's, uh, plenty of room to, to compliment.

Uh, it, it makes a difference where you direct it at. If you, if you direct an AI at trying to mitigate the occurrence of an attack, it becomes extremely expensive. Even when, when you think of like the zero trust, uh, marketing, uh, trust doesn't have to do much with security.

You have to trust something. You have to trust your, your cryptography, for instance. And if you model trust as a cost saver, if you have absolutely no trust, it's a insurmountably expensive proposition.

Mm-Hmm. You are, you are gonna get attacked. You are gonna get breached.

So thinking of, it's not an all or nothing proposition. If you dedicate the, uh, artificial intelligence assistance to protect your critical assets and maybe lower value targets, it's, it's less, less about mitigating the occurrence of the attack because it will happen. It's perhaps more about and investing and more expedient recovery or more expedient mitigation when the detection of a breach where the, the detection of a deviation has emerged rather than theoretically solving what, what the AI has trained on, uh, as opposed to, uh, all the other things that will keep on growing and coming and constantly having to retrain and learn is like, how do we, how do we recover faster from anything that can happen has more in common and like, it's less broad and expensive.

Yeah. And a less expensive proposition again, 'cause like creating, So you're new and unknown ways of attacking versus we do have an incident response process. We do have a triage process.

There's some things we know to go through. You might apply it to new domains, um, and, and have different scenarios, you know, attacks or compromise that might be instigating that. Right.

But you do have a known process, but hopefully we'll get you to the bottom of what's happening. Yeah. Reinforce resilience.

Mm-Hmm. And being less fragile. A lot of, one of my favorite talks on in the DevOps domain as Dr.

Woods, the Late Dr. Woods, the Bone talk Mm-Hmm. On how, uh, bo bones heal themselves along the fault lines of, of a rapture or, or of bone having any sort of damage.

But the mechanics or play are the same as hemostasis. Even when the bone is fine, it's constantly healing, rebuilding itself. Right.

Right. Yeah. But you, you will have impact.

You will fall, uh, you'll bump into things, but your body can, can handle, uh, very effectively. Most of, most of the cases, I think we, I think most of us crossed the Rubicon into not, if you get attacked, it's, you will, and you probably already have, most people have had to respond to those. And Andreas great to talk with you.

Congrats on the book. Well, likewise. And, uh, you can go to your favorite bookstore online in person.

I think you said you found your, you found a book at Barnes and Nobles and, you know, pick that that Up. That's right. Yeah.

Amazon fiscal store in Seattle also carries it. There you go. And it's a quick read.

It's, it's not very long. It's, and it's a narrative, you know, like the Phoenix Project. And My problem with books generally is that there's just too many words in them.

But yeah, people, uh, have commented that it's, it's a light, enjoyable read, but very timely, very relevant. It is. It is a great read.

I haven't read it myself. So congrats again. Thank you.

And thanks for spending time with us. Thank you for, uh, being with us. We've got some more interviews coming up just in a few minutes, so hang tight.

Western mother, great guests here at DevOps World in Santa Clara.