 Okay, why don't we get started? Thank you for coming to the second to last session of the day. So I'm between you and closing remarks and then the reception, which I hope you can join me at the end of the day. My name is David Yates. I teach computer information systems at Bentley University. If you've not heard of Bentley, we're predominantly a business school. And even though we're small and we're situated in Massachusetts, we have as many business students, in fact, more than you'll find at NYU or Penn State. This talk is going to sort of be broken into two parts. The first part, the metaphor that I want you to have in mind is an hourglass. So we're going to start about thinking about compliance and operations separately. Then try and bring them together in the title of this talk, which is Compliance Operations. And we're going to dig a little deep on what modern compliance looks like, what operational excellence looks like. The second half of the talk, I don't know what the right metaphor is. It's like being on a rough ocean or maybe being on a roller coaster. It's going to feel like a bit of a white-knuckle ride. Because it's actually very hard to do, even though this talk is incredibly simple. So let's think about compliance for a minute. Compliance is the state of being in accordance with established laws, regulations, guidelines, or specifications, or in the process of becoming so. Easy to say, hard to do. What about operations? If we're talking about IT, it refers to the set of processes and services that are administered by a department in service to a larger organization or enterprise. So we've started at the top of the hourglass, and now we're going to try and bring them together. So linguistically, compliance operation or comp-ops, it's just a contraction like dev-ops, like dev-ex-ops, like dev-sec-ops. But the next two bullets after the first one are really important. It's everything that you can think of at the nexus of compliance and operations. So it has to harmonize and reconcile concerns within those domains and bring them together. Of course, because of the origins of compliance and operations, it needs to bring the best practices of both to the art and science of compliance. So when you think about compliance, it's easy to fall into the trap of, oh, it's just logistics, oh, it's just numbers and bringing together the right numbers and be able to generate the right reports. But I would argue that there's an art to it as well, and anyone who's done this for a living can attest to that. Like dev-ops, one of the things that you want to do as you're thinking about doing compliance and operations and bringing them together in a way that they're synergistic, is you want to align your people, your processes, and your technologies, and this all needs to be done in the context of your own culture. This is where the real challenges lie, of course. As I always like to tell my students, all hard problems are people problems. What I want you to take away from this talk is really two things. I want you to think about compliance operations, first of all, as a thing. So think about compliance and operations being in synergy, and trying to situate the two within your security mindset and your security culture. If that doesn't happen in this talk, then I've not done my job. The other thing that I want you to do is try and connect compops to the antecedents of the term itself. Modern software and infrastructure delivery and security best practices, however your organization thinks of security. Let's dig deep a little now on compliance. So of course it's part of a triad, the GRC triad. So here we're concerned about corporate governance policies. We're concerned about enterprise risk and the programs that manage them or manage it. We're talking about regulatory and company compliance. What you really need to do is think about these three components and how the independence is managed. I'd like you to also come away believing that GRC is necessary but not sufficient for a sound security culture and a sound security mindset. In other words, they build a foundation, but there's much more to security culture and security mindset than GRC. The other thing I'll say about this triad is this is a journey. If you were here for Andrew's talk a few minutes ago, he had these spider diagrams about where you would be feeling good and where you might need to improve. Think of GRC in a very similar way. You need to start where you are and be honest about that as a company and an organization, and continually learn and improve expending your resources where you feel like you're most behind. This is all definitional and vocabulary. Of course, it is quite complicated. I've got people, processes, and technologies in the middle again. You need to worry about what your appetite for risk is, what your external regulations are. In Fintech, which is where most of you are today, there's at least 10 government organizations at the federal level in the US that you might need to worry about. That's before you even get to state and other things. Then you have your own internal policies. All of this has to operate in context of your organization. The operations are managed and supported within your organization through the GRC triad. If all of this goes well, you get ethically correct behavior, improve deficiency, and improve effectiveness all at the same time. This is often out of reach panacea, if you will. What does modern compliance look like? I'm going to read this quote because this quote was really the inspirations of this talk. In the same way that frequently exercising build and deployment steps reduces operational risks, exercising compliance on every change following the same standardized process and automated steps, reduces the risk of compliance violation. This is attributed to Jim Bird, and he's the author of Dev Ops for finance. This is the first of two Greeno Riley books that I'll be plugging in this talk, but this is a really good one. Then if you back up and think about why modern compliance needs to be thought of as a thing by itself, try not to think of it as a thing by itself. Try and think of this as part of your digital transformation and all that comes with that. If you're going to be thinking that big, then you're solving what people like to refer to as a wicked problem. There's no easy solution. You've got to think about things holistically. You need to be bringing your design thinking hat and holistic problem solving to modern compliance. You can adopt it piecemeal, but that is very organizationally dependent on how you do that. I'm going to consider that out of scope for what I'm going to talk about today. Oops, wrong way. I'll start with a bad news slide. The GRC triad is complicated, and modern compliance within that is complicated. Most of the compliance on the left is industry agnostic, and I've already said there's lots and lots of things in FinTech and financial services that go well beyond that. I want to bring your attention over to the right for a minute. Within compliance, you want to monitor, you want to assess, you want to worry about internal and external audits, and you want to have the right reports at the right time for your stakeholders. This in essence is a multi-stakeholder problem. On the monitoring side, you worried about at least three things. I'd argue this diagram is a subset. The threat landscape, what your controls are for your security infrastructure, hopefully you're running behavioral analytics. You're worried about your systems, your processes, and how prepared you are for your audits. You're performing regulatory audits, standards audits, and contractual audits, and your reporting needs to address internal stakeholders, regulatory bodies, customers, and partners as well. So that's the bad news. The good news is, lots and lots of technology development, I would argue in the last 15 years, has given you access to tools that can help automate modern compliance. I'll read another quote again. This is from a Deloitte and Touche report on DevPsychOps. Security monitoring and notification systems in DevPsychOps creates an automated audit trail through the software development lifecycle, which facilitates compliance reporting. So that's a great start, right? But you really have to sort of dig a little deeper than this quote suggests. You have to focus on the aspects of compliance that require testing. And it's not just compliance, by the way, which probably happens within a compliance framework that you're using from a regulatory body or you've developed yourself. It also has to synchronize with your operational framework, whatever that looks like, okay? And I'll refer to something I said earlier. This is truly a multi-stakeholder problem, or if you think of compops as a solution, you need to think about all of your stakeholders as you're developing and reshaping the solution. So what you want to do when you're doing that is establish shared metrics to evaluate any progress that you want to measure, probably domain dependent, probably even organizationally dependent, and tie them to business objectives for your organization. So make sure that the metrics which everybody loves, right? But if they're not meaningful with respect to your business objectives, they're probably not measuring your progress very well. So we've sort of dealt with compliance. Let's dig deep on operations for a minute, and I want to focus on something that I call operational excellence. I know it's a very common buzzword, but I'm gonna give Chris Tozzi's definition of it. Operational excellence is a mindset that is embraced across an organization to maximize outcomes and positive results. It can be reinforced by specific tools and processes, but it's ultimately a philosophy and a cultural principle. It must be integrated into your organizational culture in order to achieve its full effects. So this is what we're sort of going for on the operations side, now that we've dealt with compliance. But again, back to this idea that you're dealing with multiple stakeholders. First of all, ask yourself, why? Why are you really doing this? Is it just serving compliance? Is it serving my business in some way? If you are a big fan of this, this is a shout out to Simon Sinek. Start with why. And because it's a multi-stakeholder problem, you need to understand the implications of addressing that why. Who's gonna be affected? And you need to ask why and who before you worry about the what and the how. The other thing to keep in mind is that you're trying to achieve operational excellence, but also be efficient about how you do this. So another shout out to one of my favorite business books, Eli Goldwrights, The Goal. So this is a paradox to improve your performance and your efficiency at the same time. Put up a review slide per minute because I'm an academic. So we started out with this contraction between compliance and operations. We've talked a little bit about what's at the nexus of the two, at least visually through those slides, and thought about what harmonizes and reconciles the concerns at the intersection of the two. So for the rest of the talk, I'm going to try and focus on how DevOps and security best practices can be applied to the art and science of compliance. And I'm going to try and ground it in people processes and technologies along the way. And as another shout out to the previous talk, I'll present a maturity model. So this project, so this is a research project that I've been involved with for about seven years at Bentley. A couple of PhD students have graduated working just on this. But the genesis of this was work that was done by Booz Allen Hamilton that I was involved with. And what we were really focused on at the time is, well, what is modern software delivery? What is it all about? And it boiled down to seven things. Configuration management, continuous integration, automated testing, infrastructures code, continuous delivery, continuous deployment and continuous intelligence. So part of the shift about working towards compops as an extension of DevOps was start thinking about any of these with the preposition for and then compliance or with compliance. So for example, what is continuous integration for compliance mean? What does automated testing for compliance mean? What does infrastructure as code with compliance mean? What does continuous delivery for compliance mean? So think about all of these needing to be aligned with your compliance. Best practice is for security. So I teach cybersecurity at the graduate level and about three weeks in I put this up. This is one of my favorite security frameworks. So it's a little complicated because it's got 25 squares in not four, but if you read across the top you should recognize this from the NIST cybersecurity framework, now eight years old and in its second revision. But you want to identify your assets, protect your assets, detect intrusions or events, respond and recover. On the left hand side, you've got your attack surface, not depicted of course, you have your threat landscape. And then within this, there's a third dimension that you need to worry about that which is, well within the scope of people processing technology, what level am I worried about? So most of the identify and protect, you comply your favorite technology towards achieving. But once you're out in this respond and recover phase, you're depending on your people a lot more and all along the way you're depending on processes. So I would argue that compops is an important part of what you have to think about here. This cyber defense matrix is part of an OWASP project and it was originally conceived by Sunil Yu who's now a Jupiter one. If you've read anything about Agile and DevOps for the last 25 or 10 years depending on how you count, what it's about is achieving velocity. And again, you're achieving velocity in a complex environment. You're achieving velocity with multiple stakeholders. So you need to have empathy for all of them and where they're going to have to chip in and how they're going to benefit from your DevSecOps processes. So this includes, I would call friends like customers, partner and your security and compliance teammates, but also external organizations as well like your auditors, like your regulators and government agencies. And if you've studied Agile and DevOps, it all leans on the three Cs, communication, collaboration and cooperation. None of this machinery works. This DevOps or DevSecOps infinite loop. None of this works without communication, collaboration and cooperation. And the extension here really is about thinking not just about this within the organization but also with external stakeholders. Continuously learn and continuously prove as you do this, improve iteratively and incrementally. So when I said start where you are and then move from there, don't try and do it all at once. And for this to work, DevSecOps need to align, synchronize and synchronize and security and compliance must also be continuously delivered assured and verified as you mature in doing this. Gonna deconstruct this a little further. I'm first gonna focus on ops and what it can do to serve your compops cause and then focus on sec ops. So what we're after is the first bullet. We're after about, we're trying to achieve great DevSecOps to ensure that our IT is agile, reliable, secure and compliant. If you're not using cross functional teams to do this you're not really doing it right and they need to be involved in all aspects and responsible for all aspects of the product or the project or the product you're working on. So this includes the scope, the features, the usability, security, reliability and compliance. So you need to have that mindset within your DevSecOps teams. In order to do this well obviously you need to be addressing compliance directly which means you're monitoring all phases of the software development life cycle. You're doing compliance validation along the way and providing evidence attestation when needed. In order to do this well you need to adopt an integrated operating model. If you're doing technology development make sure all of your services and microservices are secure. You need to implement automation and testing and evolve your product architectures to include DevSecOps and compliance. Seeing the same diagram here annotated with specific security. So this is a, and I should have attributed this. This is a Gartner diagram on how to think about DevSecOps. So they've annotated this whole thing with all of the security considerations. Again, beyond the scope of this talk but I just wanted to show what they all mean or what they all are. And even this is not a complete list. So what are you after? Again, I'm gonna focus on the first bullet. You're really interested in having a secure by design mindset but then verifying that design at every step of the way. What does this involve? Security, auditing, monitoring, and notification systems. These should all be automated and continuously monitored. And what you get out of that with respect to compliance is the next three bullets. You improve compliance feedback, you reduce open compliance findings, and you decrease time from audit requests to evidence delivery. And within all of this because you're doing these things multi-stakeholder teamwork is critical. And I put a shout out there to some of the work we did at Booz Allen about how to develop great teamwork about DevOps. And if this is done well, you get security assurance and enhanced compliance. So hopefully at this point you understand this alignment if you will between CompOps and DevSecOps and the connections to compliance. If you want to sort of build it and boil it down to sort of what do I have to do as a DevOps organization or a development organization, think of everything as a service and everything implemented as a code, right? This is what cloud native and DevSecOps is all about. So you're familiar with terms like software as a service and function as a service. Of course, this gets extended to security as a service and security as code. And now I'm proposing compliance as a service and compliance as code as well as part of your CompOps program. If you do all of this well you get strong security and robust compliance. But of course you're never done, right? So if you look at what DevExOps or DevSecOps is doing, it's now incorporating Git events and GitOps and AIOps as well. And so to the extent that that is evolving your compliance operations need to follow suit. And this maturity model shows sort of where AIOps is going, right? So we're starting with being able to observe. Are you looking at the right things? Are they tied to your business objectives? Do you know what context these data are coming in? How are you thinking about them as you're gathering these data and generating reports on them? Are you acting on them accordingly? I mean, you're learning as you go, okay? So it's actually, I'm not a big fan of every security model. There are bad ones out there but I do like this one for AIOps. So compliance and operations, pair like risk and governance are in my world wine and cheese. So think about them going together. It's necessary for a security mindset. You need this modern compliance but it's not sufficient. Part of this journey is achieving operational excellence but this is a journey, it's not a goal. And by the way, you're never done. In terms of mindset and philosophy about this, I encourage you to think about compliance operations and the fusion of the two as part of your digital transformation. Keep in mind that teamwork, culture and mindset are all critical to this journey. Compops requires testing and automation. That's sort of the block and tackle part of this talk. It builds on and extends DevSecOps and a couple of cautionary notes to close my argument. There's a lot of people that are resistant to DevOps because it requires cultural transformation and the card that is usually paid is that, oh, it's not compatible with something. So one of my favorite myths is DevSecOps is incompatible with my compliance requirements. And what I would argue is, well, that may seem so on the surface but can you adopt or adapt DevSecOps so that they align and don't conflict? And in terms of going forward, since DevSecOps is evolving, your compops mindset also needs to prepare for more complexity, more automation, more learning and more continuous intelligence from your infrastructure and your applications. That's it. Again, we only have five minutes before we move to stage four for closing remarks but I wanted to open it up for any questions. Yes, go ahead. Sure, so one of the, since we're at an open source strategy forum, one of my favorite tools out there right now is the Open Policy Agent. So it is a whole language and whole infrastructure for actually encoding your policy. And it's agnostic as to whether that is external or internal. It was just a detail that I didn't wanna get to in this talk. So when I said configuration management and policy management implicit in that was that you would be doing policy as code. But you're right, I could have added it to that slide. The legacy mindset. Yes. Okay, yeah. Of course. Yes, yes. Right, right, right. Of course, right, requires validation. No, I agree. And so from a security point of view, if you don't get your policy right and security of course is a bigger umbrella than compliance, then nothing you do in terms of mechanism is worthwhile because it's supporting a policy that's inherently broken. So that's a great point. So getting your policy right, finding a good way to encode that and then be able to assure and validate it along the way at every step is a big part of this. Other questions, other comments. So if you have follow-up again, I am at the reception tonight and I'm available at this email address. If you wanna follow my employer, that's our hashtag. Some of you look like you might have college-aged students or teenagers. It's a great business school. I've been there for 16 years, I love it. Other questions, other comments. Yeah, go ahead. It's really a new proposal. What I'd encourage you to do as a starting point is there's a periodic table of DevOps tools available out there at digital.ai and they actually have an open-source button if you're interested in those first and foremost and it's probably the best taxonomy I've seen and so you can look at what the modern compliance tools are and of course if you unclick open-source you get the commercial products as well but they've had that periodic table for what, five years now and it's still a great reference, so digital.ai, formally Zebia Labs I think. Other questions, other comments? I'm not giving you much back but there's a minute and 42 seconds on my timer so I'm gonna give that up to you to walk back. I am gonna go to the closing session and again I'll be at the other side. Thank you. Thank you.