Navigating The Terrain Of Shared Responsibility With Iftach Ian Amit

[00:01:24] GP: Hello, everyone. Welcome back to The Secure Developer. Today, we have a great guest that really could give us all sorts of perspectives on security, having really kind of dealt with it from inside and out as you’ll see in a sec, and that’s Iftach Ian Amit who’s the Chief Security Officer at Cimpress today.

Welcome to the show, Iftach. Thanks for joining us.

[00:01:42] IA: Thank you, Guy. A pleasure to be here.

[00:01:44] GP: Ian, we’ve got a whole bunch of topics to talk about. You’ve done stuff across the board indeed from being a security provider to now being a chief security officer. Can you tell us a little bit – Walk us through a little bit of your background and how you got into security. What was the journey you took?

[00:01:59] IA: Sure, absolutely. I started my career almost by mistake, by understanding at some part of my life that what I'm doing as a hobby, as a passion is something that people get paid for. I still find it fascinating but I was tinkering with computers and hacking since my early, early teens. I started my professional career in security after I finished my service and I started working as a consultant for a security consulting company and then, again, as I said, found out that all this hacking and tinkering with the security systems and operating systems is called pen testing. It’s something that's pretty sought after.

I spent a lot of years as a consultant in varying different positions, leading some practices, creating some other practices. I started from kind of the hands-on network operating system security. I have some developer background and slowly found my way into application security and doing some pen testing there. Over the years, I’ve also expanded the breadth of my purview into security and added on red teaming. So I added on the physical aspects, social engineering, kind of full adversarial perspective. I spent a few years running security research for a few security vendors, which is, again, a fascinating practice and allowed me to keep digging into different aspects of security, understanding more the adversary side, tiptoeing into thread intelligence, really understanding the mechanics or the economics behind attackers.

At some point, I started thinking like what's next in my career and started to understand that some of my clients that I work for as a trusted advisor had a really interesting job on their hands. As a consultant, I used to solve big problems in a short amount of time, and it dawned on me that I never kind of saw a strategic security progression with a big company, and that's what most of the CISOs I worked with were doing in a multiyear strategy for their companies. At some point, I started thinking, all right, how I’m going to get there and start working more towards the client side, so to speak.

I spent a couple years in Amazon in a couple of different positions, one with Amazon's information security running mostly application security and the other one with Amazon Web services diving into full platform security from the ship level up. After that, I took on my first full-time chief security officer position at Cimpress, so I kind of completed my transition from being an individual contributor, hands-on, full-on security/hacker guy through/from consulting to sort of service provider product, all the way down to the full client side being the consumer of these and building security programs, building practices, and then working at the high-level.

[00:05:21] GP: Definitely quite a –

[00:05:23] IA: That’s the journey.

[00:05:24] GP: Yeah, the different facets. I think – Within that journey, you’ve gone – At the beginning, you’re in a variety of fairly kind of forward-thinking companies in that consulting or research, but I don’t know if you can say application security is cool today. But like before, it was cool or –

[00:05:41] IA: I still think it’s cool, yeah.

[00:05:43] GP: At the time that it was still like nacen space to it, I mean, do you feel that you’ve sort of seen this mature over time? Or granted your purview was more than just application security, do you feel the difference? Do you feel like sort of the mainstream angle of application security has basically kind of gradually changed over the years? Or how have you seen this evolve?

[00:06:02] IA: Yeah, absolutely. Absolutely. I think I've seen application security grow from something that almost didn't exist, to be honest. We’re talking about secure coding back in the days in like ’99, early 2000s, and it was – I think there may be one or two books, the classic secure coding for Microsoft, and the practice itself was rarely to be seen. It was kind of a dark art for us consultants to come in and really be accepted by customers as they’re going to look at our code. They’re going to put their grubby hands on it and critique it and then try to actually test it and break it. This whole thing was really in its infancy. So I've seen it grow from that through automation and the first pure application security companies that build products around testing, as well as kind of their web application firewalls.

After this point, I think we've made tremendous strides these days with the cadence and the pace at which we as security practitioners can embed security. By the way, I like to call it equality coding. I’ve stopped using secure coding in the context of application security and just called it quality engineering. The way that we can embed it into each and every phase of whatever application development methodology you're using, whether it's traditional like old-school waterfall or super agile disjointed processes, CICD pipelines that you want, these days you can find a fairly easy off-the-shelf solution to really elevate the level of and the maturity of code that you're pushing out to production from – Back in the days, it was just nonexistent.

[00:08:00] GP: Yeah. There are a lot more work that you just had to take on alongside kind of the lack of awareness [inaudible 00:08:04].

[00:08:04] IA: Yeah, and I think a lot less friction, to be honest. Again, back in the days, when you would schedule an application security pen test, you knew that things are going to break. You knew that you’re facing an uphill battle politically and working with the customer, and it was absolutely expected that you’re going to get pushback. For whatever finding you'll come up with, people are going to pull shit, sorry, on everything that you'll say. People in the field are very defensive about code that they produce. I mean, again, I come from the developing background and I know how it is. Your code is your baby.

[00:08:38] GP: Yeah, someone’s calling your baby ugly.

[00:08:39] IA: Exactly, yeah. What do you mean this is wrong or this could be better?

[00:08:45] GP: Well, today, we have bug bounties and we have sort of pent testing surroundings that – I think everybody still always would love to sort of get the clean bill of health. But at this point, there's an expectation that that never happens. There’s always sort of some mistakes, and you need to be appreciative that they’re being called out and –

[00:09:02] IA: Absolutely, yeah.

[00:09:04] GP: You’ve sort of seen this maturity, but the other change that you've done is indeed you've kind of gone from – I don’t know if I should call it the – Which one is the dark side? But you’ve sort of done from the –

[00:09:13] IA: They’re all the dark side.

[00:09:15] GP: They’re all dark, exactly. Some of sort of [inaudible 00:09:18].

[00:09:18] IA: The different shades of darkness.

[00:09:19] GP: And different elements. But you’ve gone from being a provider of security solutions, whether it’s sort of products and technology or research or consulting to being the one consuming it, right? You went from the vendor to the buyer.

[00:09:31] IA: To the customer.

[00:09:32] GP: How did that feel? Do you have – I’m kind of curious if you have more empathy for vendors because of this. It’s the opposite. You know all the dirty tricks, and nobody can kind of fool you. How do you see vendors now that you're on sort of the buyer side? Was there any guidance or dos and don’ts that come to mind?

[00:09:50] IA: That's a great question, and I don't have a very clear answer. I'm going to be very ambiguous here because, yes, I do know the dirty tricks. I know how things are priced. I know the models behind things, what’s automated, what's the – What we call puppetry is someone like –

[00:10:06] GP: Like the Sausage Factory. 

[00:10:07] IA: Moving the strings. Yeah, exactly. I’ve seen the Sausage Factory. I’ve set up some factories. I tore them down but I also understand the vendor side. I've had my own startup. I’ve ran my own consulting company. Being on that side, I work with sales and sales engineering and every facet of running a security company or provider, so I do have the empathy on the one hand. In that hand, I know to call bullshit very quickly. Some vendors are kind of intimidated I think or get a little bit frustrated when they got shot down for slinging FUD and trying to dazzle me with the emails full of buzzwords. Some get to kind of my blacklist of, “Oh, yeah. I’m not going to work with these guys.”

On the other hand, I know what it means to work with – I consider myself, by the way, a good customer. Once you pass that, the bullshit test, I expect full cooperation and I provide full transparency because I know how much it means to the vendor to get honest-to-god feedback, whether it's good, whether it's bad. Do you meet the expectations? What else do I need? I can tell that I'm working with a lot of vendors that I can sign off of different features and capabilities and sometimes entire roadmaps for their products, which I'm very proud of because I know that I have a sense of accomplishment and contribution to that vendor and I know that this is something that other customers are also seeing.

Again, it's a bit of a dichotomy between being there and it’s like, “Don’t bullshit me. I know. Don’t try to jack up the price. I know exactly what I'm supposed to pay,” and actually being affectionate and understanding what it means on the other side.

[00:12:01] GP: To challenge the [inaudible 00:12:02].

[00:12:03] IA: At the end of the day, everyone understands that you cannot run by yourself. Some organizations are closer in index spectrum, in that continuum to being able to be almost completely self-sufficient. Other organizations are on the complete other side of the spectrum, very lean security operation or headcount if at all, and tons of vendors and consultants and product. Most of the organizations are somewhere in the middle, and we all need to understand that everyone's got their own kind of combination of, “I'm going to use this vendor for that, and this is something I need to develop myself. I want to have those capabilities.

You know what? Sometimes, vendors also need to understand that it's not – Your product is not a one-size-fits-all. Different companies – It might be even the same size and category of company but they might be in different locations across that continuum of their security program.

[00:13:01] GP: No, that’s really it. I think it's great insight, both on the interaction model. It sounds like basically the right approach to sort of work with you is really to try and be a true partner, so don’t try to razzle-dazzle coming in, because it's just going to sort of seen through, which is probably like good advice and to be honest –

[00:13:20] IA: Yeah, just in general.

[00:13:20] GP: Sort of the DevOps space. I think probably most CISOs would relate to that. You might just have a slightly better radar at sort of separating a razzle-dazzle from facts but really kind of on the other side to truly partner. Definitely, it’s something to be appreciated. Yeah, I agree on this. Whether you're in the fully build or almost fully by, it's really about working together.

I guess on that notion, one very interesting step in your career is really that work in Amazon. So I’d like to dig into this notion of shared responsibility, right? When you talk about developing something on the cloud, there is I think a fairly accepted concept that before you – At least it was perceived that you own the full stack of security. You didn't really. There was hardware. There was maybe the collocation. But it was more of that. When you moved to the cloud, more of your security is kind of at the hands, at the mercy of the cloud vendor and that there needs to be a shared responsibility model.

I'm curious like from the other side, like working at Amazon, working at sort of the leading cloud provider, how do you see the lines get drawn, and are people doing something wrong? Are there misperceptions around how that shared responsibility should be split?

00:14:33] IA: That's a great topic, and I think that it’s being – It’s a constant struggle or a constant question that gets tested over and over again in Amazon and I'm sure that in very cloud provider. It really boils down to – How do you draw the line is a really tricky question, because not all services are created equal. You look at Amazon. You got thousands of different services and features. Each one is at a different level and each one has its own line in the sand in terms of this is our responsibility as a cloud provider to make sure that ABC – Like this is all being monitored and accounted for, and we can provide at stations and making sure that nothing breaks this from our perspective. From that point on, it is your responsibility as the customer.  As the developer, we’re providing a lot of controls, and that comes with the responsibility of making sure that you're not screwing yourself. I mean, that you're not doing things inadvertently.

Again, I think it's – Even with existing services, they go through phases in their lifecycle. If you remember back pre-corona days or in Internet years like three years ago or four years ago –

[00:15:53] GP: Or just like probably a month ago.

[00:15:56] IA: Yeah. You could set up an S3 bucket in seconds, and it was very easy to make it public, publicly writable, publicly accessible. Everything was open, very quick, and dirty. It was all about speed. It really depended on how you set it up. Is it CLI? Is it through the web interface? Versus these days, to make it publicly accessible, to make it publicly writable, you have to jump through hoops, and it's just one tiny little example of that constant reevaluation of “is the model working?” Are we providing enough documentation, communication? Are we providing enough checkpoints? Are you sure that you want to do this? Are you sure you're trying to expose this massive cachet of information publicly with no authentication?

From a feature perspective, from a user perspective, sometimes you're just in a rush or not even in a rush, but you're trying to get very specific functionality for your code, for your application, and you forget that the feature that you’re using or the service that you’re using has 12 other features as well or 12 other functions, and you just don't care. It goes back to the point of do I as a cloud provider have the responsibility to have kind of – You need to be this tall to use this service to prove to me that you read through the documentation and you understand it. Or is it all about my expecting you to be knowledgeable enough, and so I can just like –

[00:17:30] GP: Give you the full...

[00:17:31] IA: Give you all the features, all the bells and whistles, all configured through quick API, CLI and its different approaches. Different cloud providers dictate different approaches, so a really big challenge. Again, even as a user, sometimes I run into services that I haven't worked with before, and it takes me aback for a few seconds like, “Okay, let me fully understand what’s everything that’s provided here. What is that –” Whoever developed this service or capability, what were they thinking when they put that out because they might – I might come in from a different angle. I might've been looking for a particular solution or functionality that’s included there and I might be missing out on the context. I think that's where the shared responsibility really kicks in in drawing those lines that –

[00:18:23] GP: That you can do that. I think that’s a great view. But if I kind of extract some specific maybe guidance if you’re using it, which is it sounds like, first of all, there’s probably an element of the maturity of the cloud service or a service like S3 that's been around for a very long time. Presumably, the guardrails have been kind of evolved and evolved and evolved, and it’s harder to shoot yourself in the foot. So that’s probably good guideline. If you’re a little bit more cutting edge and you’re using it in your service, you need to pay closer attention.

Then that second one was really good is this notion of like think about the intent of the service and explore its full functionality so that you make a decision about are you using one or the other. I guess you can probably sort of template that or you can methodically do that within your organization pretty well. Are there any sort of resources or like when you guide your teams or the likes to those? Is there any place you like to sort of point them to or –

[00:19:14] IA: Class in documentation. It’s old school RTFM, and I think that's still if not the best source, one of the best sources for really understanding how things were intended to be. Amazon is particularly good at producing high-quality documentation. I’ve seen our providers do that as well. I think nothing beats high quality documentation and the diligence that us as users now, when using any kind of service to go through documentation at least once, really understand everything. You don't have to be an expert in each and every feature. You don't have to be the CLI ninja that remembers every switch and every parameter. No, but understand how the thing works. Understand the architecture. I truly believe that nothing beats that still. It may be a little old school but it’s still RTFM.

[00:20:06] GP: I think it’s good, and also it comes back maybe to that element of transparency, right? It’s not about somebody giving you some sort of silver bullet or anything like that.

[00:20:14] IA: Or a black box.

[00:20:15] GP: Exactly. You need to understand it, so I think that’s good guidance. Great. I think – Thanks for kind of walking us through that. I do think it's a perspective of both from inside and from outside, and I think that’s very valuable. Maybe let's dig into Cimpress a bit more where you’re the Chief Security Officer. Before we start, can you describe a little bit just like the rough structure of the business and specifically the security slice within it?

[00:20:38] IA: Sure, absolutely. To start with, most people probably don't know who Cimpress is because it’s sort of intentional. We’re actually – We have 15 different brands under the Cimpress top brand name, and all of those businesses operate within the market that's called mass customization. That boils down to providing services mostly to small businesses for branding and marketing, so anything from producing your own business cards through letterheads and marketing materials. Anything you can customize or want to personalize but you don't want to commit to producing at mass scale but you still want the advantage of having the pricing of mass production, so mass customization. All of those companies are operating in different models. They have different geographies, different customer bases sometimes, different specializations in terms of their product focus and the ability to cater for their customers.

A few things that kind of bundle them together is, first of all, the fact that they're all e-commerce. They’re all online, of course. The second one is we’re all producing at the end of the day something tangible, and you're customizing a product, whether – Again, it could be a business card. It could be a tumbler with your logo printed on it. Or it could be a massive sign that wraps around your building and has your company logo out. 

[00:22:02] GP: Any size.

[00:22:04] IA: Yeah, any size, anything, packaging, gifting, personal, whatever it is. I did mention, we do have the production side, so we’re producing something tangible at the end of the day. We’re not just selling bitcoin or just operating an e-commerce platform. First of all, that's what kind of drew me to the company to begin with. All that, the entire breadth of full e-commerce to tangible and having factories in place.

[00:22:31] GP: Just to name kind of one of the key brands I think people might have heard of a lot more is Vistaprint, right? Probably one of the bigger ones they knew.

[00:22:37] IA: Yeah. Vistaprint, BuildASign, and National Pen. We’ve got Printi in Brazil. We’ve got Pixart in Italy. We’ve got Tradeprint. We’ve got a lot of different brands. I’m not going to name them all.

[00:22:49] GP: Yeah. [inaudible 00:22:50] but probably heard one of those.

[00:22:53] IA: Yeah, exactly. Yeah. Depending on where you’re at, whether in Europe or in the Americas, you’ve probably heard of one of our brands or might have even used some of them. For the security perspective, that was the real challenge. Cimpress operates in a highly decentralized fashion. As I mentioned before, each company’s got their own target audience, their own geography. Each company is also free to choose their own tech stack and to cater for their specific needs. Each one sometimes actually chooses to operate their own factory, so that means a different technology, a different process, different OT.

From a security perspective, that means that we have to kind of provide control over everything and cater for everyone. I mentioned before that I switched to the customer side, but Cimpress really took a – Put a twist on it because what I did as Chief Security Officer for Cimpress is essentially build an MSSP inside of Cimpress. We’re vending security services to our businesses in a way that allows them to consume that according to their actual needs. As I mentioned before, there is no one-size-fits-all. What we did at Cimpress Security is create or define a – You need to be this tall to ride the Cimpress train, which is a set of basic essential security services or capabilities that everyone needs to have and then provide a complementing set of products and services that we offer internally, that we manage for our different businesses which they can consume, as I said, based on their specific needs.

If someone is a pure job shop, we cater for that. If someone else is a Python or C# or whatever it is, whatever environment they operate in, full Linux or GCP or on-prem or AWS, whatever it is, we’re ready or we need to be ready to cater for it. That’s kind of really high-level overview, yeah.

[00:24:55] GP: How do you – The base set of requirements is sort of you need to be this tall. Those are mandatory, right?

[00:25:01] IA: Yes.

[00:25:01] GP: There’s no – You had to, I’d imagine, that when you set them in place, some brands had to step up to meet that line that were below it before.

[00:25:10] IA: Yeah, correct. Some brands needed to either level up a little bit or sometimes actually change, so they might've met the metric for specific capability but they netted through a different product or a different vendor. What we did is to be able to provide the same level of services to all of our businesses and to be able, for me to provide the assurances to the rest of my executive management, to my CEO, to my CFO that everyone is kind of aligned and we have visibility and we have control, sometimes we have to switch providers. If someone had an EDR solution of some sort, it’s like, “All right, that’s cool.” But upon next renewal, you’re going to have to cut that off and switch over to our kind of standardized EDR solution.

But, yeah, first of all, the process wasn’t as simple as just pulling a few notes out of a hat. It was like, “All right, EDR and firewalls and IAM. It was a little more involved than that as you probably imagine but it was a lot of work with our different businesses, a lot of work, and first of all creating those metrics and understanding like how do I measure. What is that minimal level? Only once we’ve got that and got a good feeling of the lay of the land, we’re able to say, “All right, we need to be at this level, and that's what it means and provide all the services to support it.”

[00:26:35] GP: From a development perspective, I mean, when you think of it, it sounds like every one of these business units might also have kind of their own. If they have their own tech stack, they might have their own pipelines, their own kind of source code surrounding. How do you maintain a standard when that variety is there? I guess, in general, like does the company also take a similar stance? Are there some kind of minimal requirements in terms of the software development process as well?

[00:27:00] IA: Software development obviously is a much harder nut to crack. You can’t just standardize it and say, “Oh, just use this one solution or vendor, and you should be fine.” Having said that, we do have defined standards. We call them RFCs internally that define the minimal level, the minimum set of expectations and capabilities that we as security or as a technology leadership require everyone to have, and it covers some of the identity and access management in software development. It takes use of third-party software. It talks about code quality and testing and assurances. It talks about the need to review. It talks about the use of clouds and providing assurances around that, third-party vendors.

We do have that classic set of requirements. However, because of the nature of the company and because, as we discussed before, the fact that everyone can choose their own tech stack, everyone can and should be free to choose their own path because we do believe that that promotes innovation and promotes people and companies to be very specific about what they're trying to do and be agile and competitive. It’s going to be very hard to find a dev-centric solution that fits everyone. So to complement that, what we did is, and we’re still doing. Again, nothing that I did ever in my career was –

[00:28:27] GP: I guess everybody.

[00:28:28] IA: Yeah, exactly. It was just like, “Okay, that’s it. Done. Sign off. Walk away.” We are developing an SDLC that defines or helps people kind of reference the software development and secure software development lifecycle, what we are expecting from them to have, at least the threat model, at least a quarter view. Show me artifacts of consideration around your architecture. Show me where you have checks and balances in terms of your deployment process. Before you deploy the production, you at least have to have some level of assurance, whether it’s for an automated means or a manual pen test application testing that shows that you've taken all of those into consideration, but everything is aligned with the threat model that you started with and you kept updating, of course, as you develop.

We provide that very rough framework or thought cycle almost around quality coding, and we couldn't just let that be or let that live as a document or just as a framework, so we do offer some complementing services that we know could cater for 80%, for 70% of our businesses from a technology perspective. If there's like a classic code scanning capability that you can easily embed into different CICD pipelines, great. We’ll choose a provider. We’ll go with that. We’ll make it easy for people to embed that. If we have a testing solution that makes it very easy to kind of take the package and dynamically test its features and make sure it's not exposed, we’ll provide that. If there's something that quickly scans for third-party libraries, make sure that everything is updated. Again, we’ll take that into consideration and offer that again as a service or as a product that people can consume from our portfolio.

But generally, at the application security perspective, we just keep it at the framework level. There's nothing mandated other than remember that you have to adhere to these standards and expectations but it's pretty much you’re on your own. Again, I think it's actually a little more challenging than being able to define “here’s the baseline, you all must use this.”

[00:30:41] GP: I think it's more about the agility. But I actually find like a lot of analogies with what you're describing in the whole paved roads kind of approach within a microservices kind of agile surrounding, right? To an extent, you can – I don’t know that I’ve ever heard anybody sort of describe it this way, but you can sort of say that even if you're a – Even if it’s all one business and you’re running it, if you want the different kind of agile teams to be autonomous and run, you can define the same type of principles. When you hear like Netflix talk about that, I imagine Amazon is similar, which is you have to be this tall. Those are things that are non-negotiable. You’re not empowered to make the decision not to do those. There’s limits to that empowerment.

Then beyond that, you have guidelines of what good looks like. Within that, you have the paved road which is, well, if you don't have any reason not to, why don't you use one of those services that we already provide and make life easy for you? Otherwise, you just need to spin more cycles, kind of invest more in figuring out how to do that yourself. Or you might do it poorly, which is kind of its own problem. Probably, the – While it’s larger scale and maybe the responsibilities are not just inter-organization but broader. But fundamentally, it sounds very analogous to that sort of paved road approach, right?

[00:31:54] IA: Yeah. Correct, correct. We also augment that with what we call security guild, which in some cases is it shows up as security champion. Obviously, I like to operate in fairly lean, very effective efficient teams. I don't have hundreds of people under me. So we’re utilizing the power of other developers and organizations and kind of lure them into that security or add-on position as part of that guild to represent us, to represent security and code quality within their tribes, within their organizations. We provide them with the tools. We provide them with education and training, and that allows us to have kind of a force multiplier across those different businesses.

To a point almost, they act as a translation mechanism for us sometimes, sometimes literally because they operate in different countries and even culturally. Their development environment might be different. We might not be privy to understanding exactly what the specific technical challenges and acute abilities that they have. So it allows I think a better back-and-forth between the development organizations and the security organization. But, yeah, you’re right. It is. What we’re trying to get to that point of this is the paved road, this is the general direction. I think that here as opposed to, again, large organizations like Amazon that do promote a lot of agility and independence but can also mandate a lot of gating at the end of the date, which says, “If you don't pass this level of scrutiny, you're not raising any production.”

I mean, none of the AWS services that are linked to production could be released without a proper security review. It doesn't matter how big you are or how powerful or whatever it is. It’s just not going to happen. We’re not there yet from a complete gating perspective. But as you mentioned, by providing that paved road, by providing different technologies and capabilities and product, we’re trying to make sure that that it gets close to that.

[00:33:59] GP: I mean, it sounds like a healthy approach and yet not an easy journey and probably one that won’t end. It’ll continue as we go, and somebody would use one of those sort of new AWS cloud services. I think like all this path makes sense. Maybe sort of the million-dollar question is you do all this stuff. You guide and all that. How do you measure it? How do you know if you've done the right things? How do you know if you're improving? What’s your approach there?

[00:34:26 IA: Again, the million-dollar question is making sure that you're actually doing the right thing. We took an approach at Cimpress security where we kind of created this cycle or general security lifecycle, and we start measuring. Again, I'm not necessarily talking about code but just in general. We’re using then this cybersecurity framework to measure kind of the tactical capabilities or the maturity level across 100 different sub-elements for each and every one of our businesses. Then we use the fair methodology, which is factor analysis of information risk to understand the top level loss scenarios for the businesses.

That helps us understand what is the business environment. What's the CEO most afraid of? What's the CFO's nightmare in terms of a scenario that is actually likely to happen? We’re not talking about aliens and asteroids. We’re talking about actual business things. Using those, we try to tie that back into, “Okay. So now we understand what is your technical infrastructure and environment and this type of CFS. We understand what’s your business environment from the fear.” Based from that, we can now talk to developers and understand what's their challenges.  That just provides the framework. Through these two different approaches, by the way, we’re right off the gate. We’re getting basic metrics. Again, maturity metrics on one hand and business metrics on the other hand from the actual loss calculations.

From a development perspective, it’s still work in progress, I have to admit. I can tell you that in my past, what we did is as we develop that SDLC, we started measuring the artifacts of each and every phase of that SDLC. From a simple yes, no, do you have a threat model? Yes, no. Is it up-to-date? What's the last date of update, and what's the gap between features and architecture that have changed since you did a threat model to that documented threat model? If you do have some kind of automated way of measuring your code quality, again code quality and not necessarily security, what are the metrics around it? How many failures are you seeing? Eventually, I'd like to measure against known incidents because I'm not expecting code to be 100% clean and 100% secure. Things are going to happen. Things are going to break. When they do break, I want to be able to track it back and say, “All right, could I have identified that earlier? Where would that have been?”

Based on security or code quality testing and capabilities that we've injected into the process, how many bugs have been found and fixed before they made it into production?

[00:37:11] GP: It’s prevented. Security problems are prevented in the first place.

[00:37:14] IA: Exactly, exactly. Because I know that if I have to fix it in prod, it’s going to cost me anywhere between 10 to 3 times more than if it was found earlier. The later it’s found, the more expensive it gets. We’re trying to find those metrics. Again, it’s –

[00:37:32] GP: It’s a hard problem.

[00:37:33] IA:  It’s a hard problem. I think it's more art than science at this point, and it really is business-dependent. Because even if I do find a security bug in production, my typical question is how much do I care or do I care. Not all bugs are created equal.

[00:37:51] GP: Not at all, and so true for functionality as well. I think you have like a healthy sequence of priorities as well. The first thing I want to know is I want to know what is the maturity of processes here. What are my odds of sort of being so that it’s not a fluke that that I'm secure, whether I am or not? Then what’s the risk in the business because it has to be proportional. You shouldn't invest equally in security, and you basically get practical. I think you have the high level, so at least that attention, even though it’s still like a little bit more manual. It’s sort of spent on the right parts of the business.

[00:38:26] IA: Exactly. It’s basically being able to contextualize those efforts and apply kind of the right pressure in that context. We don't want to be that overbearing security organization. We do want to be supportive. Let me work with you and let me do find ways to enhance your code and help you be a better coder, be a better engineer.

00:38:47] GP: Yup, which is definitely kind of the way to scale. There’s been like a whole ton of sort of great advice here as we sort of gone through it. I can probably go on for a while but I think we’re roughly kind of at the end of the time. Before I let you go, I like to ask every guest on the show. If you have one bit of advice or sort of one tip, it could be like a pet peeve of like something people should stop doing that you want to give a team that is looking to level up their security foo, what would that be?

[00:39:14] IA: You did give me the heads up at the beginning of the conversation, and I did try to think about it. But I think that as we were kind of going through both of my history as a practitioner, as well as different methodologies and approaches, I think the one thing that struck me the most or that left the most mark for me as a security practitioner is being able to measure things. If not for nothing, I would recommend going through a book called How to Measure Anything by Dan Hubbard. It’s a great book that provides both security practitioners, as well as business practitioners kind of some insights about how do you measure effectiveness of something. How do you measure risk of something? I know it's a little bit kind of off left field for typical developers but I do think that it provides a little bit of context and broader thinking about how do I measure my good quality, how do I measure the effect that I have or my team has over the business. That would probably be my recommendation.

[00:40:17] GP: I think it’s great advice and it’s the DevOps adage, right? It’s the core element of saying you can't optimize what you can’t measure and sort of the DevOps philosophy of if it moves, measure it and if it doesn’t move, measure it.

[00:40:29] IA: [inaudible 00:40:29].

[00:40:32] GP: That works well. Ian, this has been great. Thanks a lot for coming onto the show.

[00:40:36] IA: Yeah, absolutely. Thank you, Guy.

[00:40:37] GP: Thanks, everybody, for tuning in, and I hope you join us for the next one.