- Welcome to the Cyber5, where security experts and leaders answer five burning questions on one hot topic and actual intelligence enterprise. Topics include Adversary Research and Attribution, Digital Executive Protection, Supply Chain Risks, Brand Reputation and Protection, Disinformation, and Cyber Threat Intelligence. I'm your host Landon Winkelvoss, Co-founder of Nisos a Managed Intelligence Company™. In this episode, I talk with Active Security Compliance Practitioner, Dylan McKnight. We talk about the business of security. That is how security can be effective at driving profitability, and not just be a cost center toward an organization. We also discuss how compliance measures can drive meaningful metrics around profitability, and avoid breaches. And finally, we talked about how threat intelligence provides the proper risk-based approach for security teams in this process. Stay with us. Dylan, welcome to the show sir. Would you mind sharing little royal your background with our listeners please?

- Hey, thanks Landon. Thanks very much for having me on the show. So I came to security from a non-traditional background, meaning that I've a degree in Fine Arts. I spent about the last 20 years in the tech industry. First, I started out doing some technology consulting for companies of various sizes, mostly in the SMB space plus some enterprise customers in there as well. Then I moved into managing the teams that run the infrastructure and databases. And most recently I've been working in security compliance and privacy, mostly in the B2B enterprise SAAS space. The opinions that I'm here to share are my own, they're not those of any of the organizations with which have been affiliated. And also the examples that I'm using are meant for illustrative purposes and are based on common practices. Any resemblance to actual events is coincidental.

- I love the stories when the fine arts become the security experts, and that's a powerful combination. Would you agree?

- Well yeah, there's an interesting book from Daniel Pink from a couple of years ago. I think that when you look at the skills it takes to create a piece it's as much about looking and thinking about what you're seeing and how to improve that beautiful perfect rectangle in front of you. And it really doesn't matter if that's a business plan, and you're still trying to separate out the noise, input what's meaningful, what's actionable, what's measurable into a rectangle of some form.

- Well, I think that's exactly what we're gonna be talking about today. And really, I think that there's so much when people hear compliance in the security space, they're kind of eyes glaze over. But realistically you've probably have a lot of experience dealing with small companies, like the company certainly you're with now where you wanna put in security that's lean and mean, that actually does win business, right? Where I think when you look at with larger companies, it's a little bit more bureaucratic, it's a little bit more process oriented and of course totally necessary. But then I think it has a potential to distract from what is actually the business of security. So I guess taking that as a launch point for our discussion in your experience provide a background on the security function having challenges integrating with business leaders, so to speak.

- So a lot of the organizations I've worked with are on the smaller side. And when you're smaller it's easier to achieve and sort of maintain a good line of sight through all the areas of the business, whether it's product or engineering or sales. It's easier to do that when you're a small startup, you kind of know everybody, you know what their challenges are, and you know what you need to do. I had a CEO from a while back who got all of his leadership together and asked, "Why are we here?" And myriad of answers came out, but ultimately what everybody walked out of the meeting understanding is they were there to sell more of their product. When you strip away everything else, that's the key. So the challenge is how do you get your security team to support that and not necessarily be on the cost center side of things? How do you get them out of, so to speak the back of the house and connecting those dots from your stakeholders? You can see this when you're talking to your customers, because they're paying a lot more attention to what you're doing. They want assurances that you're a responsible steward of their data. It's a part of their third-party risk management process. So you'll see this in RFPs and security questionnaires. Maybe they'll ask for a SOC2 examination or nice assert. Sometimes you even end up with these lengthy security addendums in the contracts. So if you're a business leader here, you gotta be thinking about what's your security team doing, not only to reduce the risk to the growth of the business. That's kind of what we all know that's traditional security role but also, what's your security team doing to improve the customer relationships? How are you building trust with those customers? Maybe you have a privacy program, their customer support, maybe have a good instant notification policy. So when you're talking about driving growth of the business, how do you work with your sales team to ensure that you're reducing the time it takes to close those deals by removing any sort of security issues from the contract negotiated process so that your customer is just support you agree with you, and say yeah, that's what we're signing up for. And privacy is one of these examples that's really growing right now. It's a relatively new thing for us. Two States this year passed data privacy laws and I think we'll see even more next year. And certain aspects of data privacy, such as like the minimization of collection, and the legal basis for collection those, don't always neatly fit into that CIA triad, that confidentiality, integrity and availability triad that we're familiar with. So you need to stretch some of these across many aspects of your business and if you're not careful that can lead to some conflict. So that leaves an opportunity for your team to sort of think about it a different way, and really think about what are the requirements, from your external stakeholders, right? Your requirements are gonna come from them. So your customers are gonna have something to say on that, your regulators, if you're in a regulated industry, and even if you're not you may find yourself in the state of privacy regulation that will have some sort of requirements for you and your auditors. You may not have those today, but if you do eventually end up going for a SOC2 examination or an ISO cert, there may also be a time in your future where you encounter an audit from a customer as well. So you get your requirements coming from those external stakeholders in any of your capabilities from your internal stakeholders. So what's your software development team capable of? What is your data science team capable of? What is your product team fit in all of this? And finally, the thing to really consider here last is the risk that your organization and others are willing to accept. And it's not just your executive team, you gotta think about legal stakeholders here that maybe their internal, maybe it's an external counsel. Certainly your board will have something to say, your customers are gonna have something to say, and your investors will have something to say on how much risk the organization is willing to accept. So you really get to kind of put this all together and think about very broadly, not just in these security silos, and product silos and sales silos, very broadly across all of these aspects. How do you drive the growth of the business?

- That's certainly very helpful context, almost a playbook so to speak in terms of how to get started. But it didn't like get a little bit more in the weeds, if you could about how can security better align with the profit law side of the business?.

- If you're working for a company that's lucky enough to have something like an OKR, you can set relatively meaningful objectives and start achieving those within a quarter. You really got to think about what do you have? What's available to you? And how do you make the most of that? How do you get sort of a minimum viable product out there? So you don't have to solve for the entire security exhibit, they might get from a customer in one fell swoop. You can say, hey, this is ultimately where we want to do, we want to have all of these mature capabilities, but look, we're a relatively small team and we need investments like yours in order to grow so that we can add these kinds of requirements into our security program. And just give you an example, right? Like you could think about IM roles and how difficult that can be to sort of match up our file integrity monitoring, which is another control, which if you implement it properly has a lot of value, but it can take time and effort to get there. So instead of trying to implement the full blown solution, do something meaningful to start, build on that, iterate on that, and measure your progress over a quarter. And continue to do that until you feel like you've ultimately achieved your goal. I've often heard security teams lament that they don't get enough face time with the executives. And I think the important thing to understand is especially in small medium businesses, and this is probably also true of enterprises. The vortex of power really tends to center around the sales and product teams, which lights especially important for those security teams to kind of get outside of the back of the house mentality, and think about becoming customer facing security practitioners. You gotta start thinking about ways to embed your security professionals in those sales teams, understand what the customer requirements are, and understand why they have those requirements. This is best done if you're speaking directly to the customer, maybe you understand that some of the requirements are because they work in a regulated industry, then maybe you can select the right frameworks to help guide your business decisions to enable those customers. You also kind of wanna think about data privacy. And to be honest, I really think that a lot of times that function really belongs with your product team. This should be something that your CEO and your COO require you should. If you're lucky enough to work in a company that has OKRs you can work, with the product team to develop objectives that are aligned with those privacy requirements. Understand the risks and the various types of data. Think about the IP in the employee files in that customer data. And then you can really adapt to protecting what's most critical.

- That's helpful. And then, so from achieving those meaningful goals, how should security leaders think about the levels of security build out at different sizes of the business?

- Yeah, that's a good question. And I think going back to what I said, generally, if you peel things back you understand that your business exists to essentially sell more stuff. And that's your role, whether you're small, medium or large, that's gonna be your strategy to enable growth. So your challenge is to apply the right security measures in order to reduce the risk of the future growth, but also how do you position your security team to be enablers within the business regardless of the size. And that enablement is really about that communication across those various aspects. So you've gotta make a real effort to ensure that you're talking to people, especially in this work from home world, that you're talking to people that you wouldn't normally encounter, whether it's customers or other people in your office, you need to make an effort, to get those discussions happening. When you're small, it's really important to ensure that you have the right people and the right positions. So hiring is super important at that stage. Your objective is relatively clear, it's that growth objective. So how do you do the minimum to get those meaningful things done? What are the small steps you take, in order to get that long-term improvement over time? So it's never too early to do a risk assessment. I started doing a quantitative risk assessment model a while back, and it's really useful because, it can help you describe risks in terms that a business person will understand. And by that, I mean, it'll be dollars. So we can talk about risk that might affect the business on a specific timeline, like say 12 months. And you can describe the dollar value of the probable losses. It then allows you to rank your risks based on the dollar value, and you can start even thinking about the cost of the controls in that context. Often what you'll find is that you always have to accept some sort of risk, and the challenge there is really to ensure that it doesn't get in the way of making the best with what you have. So you can use this to develop standards for your security program, and make it easier for people to do the right thing and make it harder for them to do the wrong thing. And I'll just give you an example of that vendor security is something that is pretty time consuming if you really wanna do it right. And you don't always have time, especially as a small company, you don't always have time to go through vendor security questionnaires. And if you even have your own, that's great power to you, but it can be a difficult thing to get right. So you need to think about how do you have standards that align generally to your risk assessment, and how do you execute on those? And as you get a little bigger, you have more resources at your disposal, but you find that this whole notion of moving past freaky things, were really starts to break down because your customers probably rely on your service in order to conduct their business. So you may even have some delays in your contract. So breaking things could have a real monetary impact on your company. So you're thinking more about maybe where does security belong within the organization? Is it under engineering? Is it has own reporting structured at CEO? How do you build tools to empower your teams? And one of the ways that I find this very useful to do that is to provide some training individual training on a team-based platform. You're talking to your sales team about things that are relevant to them. It's not just a generic sort of security training, that way people know what's always okay, what's never okay. And there's a big gray area in between, and they know how to get help with that gray area. And that's really important when things get a little more complicated as you start to grow and end up with these silos. A few other suggestions that I can throw out there are, think about building a database for your sales team so that they know how to answer these security questions most of the time. And the only thing is getting escalated to your security team are those exceptions. You can also identify security champions, and there's a lot of information out there on how to do that, but it's really important to have those points of contact within the organization, your partners, across all the years of business. So you know who to talk to, and you know that those teams have someone on that they can rely on to come back and talk to you. And finally go to your QPRs, go to the other team's meetings, go to their stand-ups, be sure that you understand what those problems are, and make sure that you're understanding how to help them solve those problems. And I'll give you an example of that. Say your marketing team becomes aware of some research you've done and they want to make a public paper as part of a marketing effort. You might ask some questions about what was the data that was used and how was the process. And you may find that there was some PII included it and the processing of this data. And your privacy program might require that you do not use PII in any way that could lead back to an individual, or maybe even back to a specific customer. Some of these markets in mature operating, it might be highly competitive and there might only be one or two customers in a specific area. So how do you ensure that you're not accidentally identifying them? So you might need to work with the marketing team and get down into the weeds on how the study was created? What the data is? How it's being used? And think about how can you aggregate these results. Maybe you can use customer A's data, but not customer B's. Maybe customer C is never okay with doing this kind of thing, but there's some value here. Maybe you wanna go and talk to that customer and get them to support this kind of effort. So there's really a lot of ways that you can help that marketing team publish that research, get that press, drive more growth within the company, but also ensuring that you're meeting your contractual requirements towards confidentiality of the customer data that's used.

- And so you talked about that customer data that's used, and like that's the biggest risk to any tech company. And so how important is compliance at reducing those visibility gaps that allows a team to say, what's in their environment is truthful, accurate and complete. And I guess, can you provide some granular examples of how you've seen these things play out and how compliance has been useful in that regard?

- Sure, so the rule of compliance here, it can really help those teams understand what the requirements are. What is a reportable event? Who would you notify? and when you can think about your contractual requirements, those are things that are coming from your customers. And here it's important to remember that it's much cheaper to keep an existing customer than it is to when a new customer, most of the time. So when you're driving new business, you might win out on price. But when you're trying to keep business, trust can be a real deciding factor there. So those notifications can actually help you. In some ways you can say, hey, we saw something that wasn't quite right. We acted upon it. We prevented any sort of damage or further damage. And that can actually, by being truthful and honest with your customer, that can actually help win their trust. So that when something really bad does happen, you may need to have that good relationship, that open honest relationship, their customer will believe and support whatever remediation efforts you have to go through whatever, however painful they may be. You might also think about what your legal regulator requirements are. What are the breach notification laws in whatever state you're doing business in or wherever your customers are. Again, compliance can kind of help bridge that and help bring those regulations into your requirements. So your engineering teams, your software development teams can execute on them. And by the industry standards, right? Those are the things that you might get audited against that might be you SOC2 examination or your ISO certification. What are the standards and the frameworks that are used to help identify those requirements? So you can put all of this together, and you can really empower your SOC to ensure that the right things are being monitored and you can combine this with your risk assessment that you've done. You can also create a data map, which sort of describes from collection to deletion, how data is collected and works through your environment, and who has access to it, and in what the characteristics of the security and the processing are there. So you can take all of these things together and you can help inform your SOC because these security tools are very expensive and be pragmatic in your approach, and in smart with your investments here. But really to ensure at the end of the day that the right things are getting monitored. You're putting the right level of examination towards your very sensitive assets. And if you're having trouble getting started, there's a lot of native security tools, especially if you're in a SAAS space, native cloud security tools that you can use such as guard duty or MDR managed detection response, which is really growing for a lot of small companies that maybe can't afford that 24 seven SOC right now, the configuration of those notifications is really important ensuring that you're getting the right escalations from the right locations.

- So work through an example there, right? Let's take cloud permissions in AWS. How are you doing categorizing the changes and permissions as just one example? How can you do those types of compliance checks and scalable fashion that ultimately is beneficial to a security operations team that's looking at incidents?

- Yeah, that's a good question. And what I'm thinking there is, so when you think about permissions, you're thinking about your requirements here, and your customer may have something to say on least privilege. They may also wanna make sure that access is only granted on a need to know basis. It can be really difficult to do this in your cloud environment because if you haven't carefully thought through what roles you want to assign to various groups, you may end up giving more permission or less permission than necessary. So you wanna think about carefully constructing your security groups so that they're going to grant the right level of access to the right kind of data. And this again you can go back to your data map to think about where is the data in your environment? What are the resources that someone in a role of data science would need? And how is that different from someone who might be in a role of QA? So you'd wanna think about how your environments are set up and how those groups are going to relate to those environments. You probably have a production environment, which you really wanna secure it to the maximum level possible, but that may be a little prohibitive for some teams like data science, where they need a little bit more granular access to data. So you can split up not just the roles, but the roles grant you access to certain things in certain environments but not others. So you'll wanna make sure that you're thinking through, how do your teams use the assets and the data that's in your environment in order to do their jobs? So how are you ensuring that you're actually granting these privilege? And at the same time, you may wanna create just like a time based access where maybe QA is troubleshooting an issue you need to get in, investigate a problem, but then when you're done investigating the problem you get back out, and that ensures that you're meeting that requirement of a need to know access.

- That makes logical and methodical sense for sure. Adding on to that understanding this is, we're threatened intelligence plays in the ecosystem. Most would argue that certainly there has to be an action arm usually with a SOC that ultimately can consume threat intelligence. Understanding even small businesses going to be using an MSSP or an MDR, how can you see threat intelligence making a positive impact into reducing these gaps?

- Yeah, so I think it's important to, no matter what size you are, take a risk-based approach to managing your infrastructure and in your assets, especially your data. And I think threat intelligence has a part to play here because you need to understand who's attacking you, and what they want. I've been lucky enough that I've worked in industries which don't deal with a lot of state secrets, so most of what we're concerned about are potential misconfigurations in the environment, which could open a door to an attacker, just looking for something, an easy target. However, it doesn't matter what size company you are. You probably have some IP, which is of some value to you, and you really wanna make sure that you're protecting that IP. So you might wanna understand to whom is that IP also valuable. And that can really help you make the right investment decisions when you're thinking about what are those reasonable security measures to implement in order to reduce that risk to future growth.

- Dylan, I can't thank you enough for your time. You've been a friend of Nisos for many years, and again, appreciate your certainly your perspectives. It's not every day that people come and really articulate the business of security in the ways that you did, and appreciate your time, sir. For latest subject matter expertise around Managed Intelligence, please visit us at www.nisos.com. There we feature all the latest content from Nisos experts on solutions ranging from Supply Chain Risk, Adversary Research and Attribution, Digital Executive Protection, Merger and Acquisition Diligence, Brand Protection and Disinformation, as well as Cyber Threat Intelligence. A special thank you to all Nisos teammates who engage with our clients to conduct some of the world's most challenging security problems on the digital plane, and conduct high State security investigations. Without the value the team provides day in day out, this podcast would not be possible. Thank you for listening.