For an API security platform to succeed in today’s fast-paced society, it must be widely familiar with the current trends of the digital world and keep its most skilled people for a long time. Tyler Shields sits down with Karl Mattson, CISO at Noname, to discuss these two vital factors. Karl explains how they approach cybersecurity as an up-to-date organization, the best way to keep up with APIs growing rapidly, and how not to acquire so many unnecessary cybersecurity tools in a constantly expanding team.
Listen to the podcast here
Understanding Human And API Security With Karl Mattson
Join us as we delve into human security, API security, and a bunch of other fun stuff with Karl Mattson CISO at Noname Security. Friendly Fire arms you with the knowledge to defend your digital realm. Welcome to the show, Karl.
Thanks for having me.
I’ve been super excited about this episode, Karl. I love Noname. I love the API security space. I love the stuff you guys are doing. I’m sure we’ll get to some of those topics. Before we do, you have an amazing, very storied background. I would love for you to give the TL;DR to the audience and kick them off a little bit about what got you into cyber, how you ended up at Noname, and what you like about being a CISO. Give us a high-level intro.
It’s a third career. In my first career, I enlisted in the Army and right after high school, I was assigned to be a SIGINT analyst at NSA. For a teenager to get assigned to NSA is winning the lottery career-wise. I spent about the first decade of my career there. I decided I wanted to get out of the security field. I moved home to Minnesota and got a job in IT, thinking that was my career trajectory. That was right about the time that cybersecurity started to hit the commercial market. I moved back into cybersecurity.
I spent about a decade working in different corporations, a CISO role for Citi National Bank, and a CISO role for PennyMac Financial. A few years ago, I decided to join Noname. This has been my first role on the security vendor side. It’s been an amazing journey. Two years in a startup feels like it’s about a decade now. This is the third and very different move in my career. It’s super exciting because I get to learn a lot about the business of cybersecurity, but not transparent as a practitioner.
Let me click on that for a second. That’s such a cool shift. I, too, have had multiple shifts in my career, but to go from military to banking/commercial to vendor is three different lens colors on your glasses. What are the differences between the three being security related because you’re wearing a CISO necessarily at NSA, financial CISO, and then vendor CISO? What are the key differences in day-to-day life? What are the key differences in what you can bring to the table? What do you like or dislike about each one?
The move to Noname as a practitioner in building out this program and the team and updating our security stack as a new company was remarkably similar to what I had in financial services. It was no less different than I thought it would be. As a software company, we’re selling our software to banks, large retailers, and large Fortune 500 companies. It essentially built a program that reflected those sensibilities in terms of what we prioritize, what the target state of maturity, and those types of things. As a practitioner, it’s almost indistinguishably a bit different on a day-to-day basis. The key difference is where you project outward.
For example, at a financial institution, you’re projecting outward to auditors, regulators, and business executives because you’re trying to gain their trust or provide them with evidence of the program that’s built. On the vendor side, that audience is almost all customers. Customers are looking at us like the way an auditor or a regulator is used to financial services. Those roles end up being remarkably similar. I thought this was going to be a wild change of pace on everything. As a security practitioner, it’s pretty darn close, to be honest.
That’s interesting. I would’ve guessed that it was wildly different between the three as well. I’ve never operated as a CISO. I had different style roles in my cybersecurity career, but as a CISO at a vendor in this particular question, there are lots of different things you have to secure as if you were a commercial entity or general enterprise entity, for example, including specifically identity theft and insider threats, like the APTs of the world. What can a program look like that slows those down or steps those styles of insider threats and APT-style threats given the difficulty of even detecting them? How do you handle those types of risks effectively in Noname or previous roles? What have you done to target those attack vectors?
We have an unfair advantage compared to a general commercial enterprise, which is a company whose infrastructure is brand new which is called Cloud Native. For example, when it comes to privileged access management, we employ just-in-time permissions management. If there’s a DevOps engineer who needs access to a critical system, we can provision and deprovision that access specifically for the time that they need to access it and then remove that credential. We also get into general employee access control. We are almost 100% centralized into Okta except for one system that is not Okta-friendly.
We start with a position of strength because we can take advantage of a couple of remarkable technology innovations that would be hard to do at a bank that has an on-premise directory and they got old Windows servers. These sophisticated cloud-native technologies are not the whole for most organizations. Whereas for us, they’re the whole environment. We’ve rolled out technologies that we’re done with by the end of the day.
Do you think that the modernization of the infrastructure model to cloud-native, distributed infrastructures, and all of the modern ways that we build applications and do infrastructure for day-to-day support has been in the net positive or net negative about cybersecurity? There’s certainly a bunch of uplift that has to occur in those environments. If you have new tools, new ways of collecting data, and all those kinds of things from a cyber vantage point, transition can be difficult.
Overall, a lot of people say, “This whole new way of doing things is costing us a ton of money and we have to funnel all these new security controls into a place where we didn’t have to have them before.” In your case, it’s awesome because you didn’t have the old legacy stuff and you’re able to flip on the new stuff right out of the gate. Do you think it’s a net negative or a net positive from a security perspective when we add on all these new innovative infrastructure models?
I would characterize it as the information security team that could be joined to the hip or perhaps you call it a sidecar to the CTO in terms of architectural decisions and infrastructure. If the security team is making modernizations that are either dead off or behind the CTO, that’s a net negative. It’s a net positive when the security team is transforming the same case as the organization. It’s self-defeating to be an early adopter of technology.
Let’s say you’re buying security technologies that your organization only has 1% of its footprint in that model. Of course, being behind the public cloud adoption or the microservices changes, that’s negative too. It’s a tremendous positive if you are right there with the CTO or the application owners. At the time they’re transforming, that’s the moment for the security team to transform. If you’re doing it in a vacuum, you’re definitely in the wrong spot.
That’s an interesting way to think about it. That was a difficult question. The way you framed that response is important. During our prep call, you mentioned that you have a unique approach to managing cybersecurity at Noname. Can you provide some insights into your strategy to optimize your resources and focus on core competencies? You mentioned that you were doing things there. Maybe it’s organizational structure related or resource focus. How do you get your team to focus on what needs to be done on a day-to-day basis for teams that you have utilized?
There are two aspects of the way we operate, which are to us now habits. The first is that everything in security we run is a two-week sprint. We run our security program exactly how development teams run the development of the application. We need to be even in the mindset of having daily standups. You’ve got sprint reviews and backlog. We’ve got a feature. We use the lexicon, terminology, and methodology of the product team and that’s how we do security. For example, the implementation of EDR or SIEM. We take a two-week sprint model. We’re drinking our champagne from a methodology perspective. The second thing is the developer teams, particularly for security technology, are oftentimes security experts, especially with a company.
Let’s say it’s Noname but also a Crowdstrike or a SentinelOne or somebody like that. They have developers who are sharp security minds. It’s incumbent upon us to first make sure that when we’re engaging with our developers and DevOps teams, they’re on board. A lot of things that we can do in security are best done by a developer themselves or by the DevOps team if they’re willing to take ownership. Let’s say it’s a technical selection, a DaaS, or a SaaS technology.
Those are professionals who know what they’re doing. It gives them skin in the game and lets them win things running with the implementation or take their advice on reprioritizing a vulnerability queue. We lean into those experts. A heavy hand is not very useful, particularly when the DevOps team is a team of security specialists as much as they are a DevOps team.
Let me dig in a little bit about what you mentioned on some concepts in the answer about the difference between security infrastructure and security operations, and then the concept of having a security engineering person or team. I think the more forward-looking companies are helping to upgrade their security analysts into security engineers. These people can effectively build and create while also simultaneously analyzing. Do you have a concept of a security engineer in your environment?
We only have security engineers. We have an individual who’s assigned to the SOC, and the SOC is designing and building the technologies as well as operating the incoming events and alerts. Those projects will sit on hold if there’s something to handle. The same goes with application security, which is its joint responsibility for the implementation of the technology and deriving telemetry as well as the actual operational use of the platform.
At this point, we don’t differentiate. Our Okta admin is an engineer, and he is the lead access control administrator. We do subscribe to the notion that the difference between an engineer and an operator are, for us, indistinguishable. At a scale, that may not work because if you’re Citibank and you have, a 365, 24/7 SOC operation, obviously there are limitations there.
You bring up a great point when you bring up the scalability of that type of design. At the end of the day, security tooling, in a general sense now, is only 1/3 of the problem. You have people processing technology that wraps around what makes a security program successful. Without the other two pieces of that, then security programs will fail. I want to talk a little bit about the cybersecurity landscape. What are the biggest risks that you see in cybersecurity now? I’m going to leave that open to whatever topics you think make sense there. Especially with emerging technologies like AI, is that a real risk? Is there, “We’re not worried about AI with regards to cyber yet?” Let’s answer that in two phases, two questions.
It’s the question of the day. It’s two parts that, at least in my mind, are separate. One is, let’s call it, your average employee’s use of publicly available tools. John from the marketing department is using ChatGPT to create a better list of candidates to focus on the email campaign. That’s a model that has to be governed by the ChatGPT or the open AI would have to be secured as an enterprise asset that has to be secured with access control logging and DLP protections. That’s the next generation of CASB or DLP technologies, which is the individual use of those models or the department’s use of the models, but that’s secondary or separate from those who are language learning model producers.
For us, we use behavioral modeling in our platform. Our use of modeling and ensuring that the models themselves have integrity that is not poisoned, biased, or infected in some way, that’s a product security problem. It’s a product security discipline. The product security aspect of model integrity is an ML Ops problem or a product problem to solve. The security team may not have the expertise in the actual models themselves. Maybe we have to grow a lot of expertise in terms of making sure that we have accountability for the integrity of these models. Most of us in security are not Ph.D. mathematicians.
If I’m projecting for a year or two years, I have a control layer for my employee’s use of approved platforms like OpenAI or Microsoft and Google. Separately, I have a control layer to provide integrity to the LLMs we’re using in our software. So far, the new market is divided up into, first, security teams get DLP and CASB, and should John and marketing use ChatGPT? Security teams are struggling with how to be the relevant influencer on the model itself and the integrity of the model. We have to learn that.
I love that answer. The fact that you’ve already set a framework in place to try to tackle the problem goes to show the forward-thinking nature of cybersecurity in the program that you’ve created. Take a step back in time with me and talk about the cybersecurity landscape as a whole outside of the AIML security question. For you, what are the biggest risks that you worry about that keep you up at night concerning the threat landscape for Noname as a whole? The cybersecurity landscape is constantly changing. Give me a little bit of information about where you think the real risks are specifically for a modern up-to-date organization like yourself, but alternatively maybe for the big banks or some of those folks that are not necessarily as cutting edge as Noname.
Two thoughts. This isn’t a risk but the biggest problem that keeps me up at night, and this for some time is highly skilled employee retention. That is overwhelmingly still the biggest problem to solve, which is security technologies are available. Essentially, there’s a weapon for everything but we have to have the skilled talent to use those weapons in defense. That’s the thing that I can influence the most and care about the most is getting that right. The second piece of that, which is the other end of that spectrum, is the actual risk surface. What concerns me the most is the DevOps toolchain.
It’s the combination of a CICD pipeline, the code repo, and those assets. Let’s say protecting the public website. The chess game of protecting a public website is territory. We’ve all been familiar with that for many years. We’re good at that. Maybe we’re not perfect but we all know how to defend against a DDoS attack at this point or SQL injection basic stuff. DevOps toolchain is a little different because the surface can change. The DevOps teams, CICD pipelines, and the tools they use are configured well. The code repository is the lead entity and credential problem that could expose my DevOps toolchain to a compromise that I don’t know about.
There are good technologies that are available but we’re still learning how to be a security practice and perfecting that. The backend toolchain is where my head is at. If you look at a lot of the breaches that have occurred over the last year or so, they involve things like publicly exposed repos, credentials that snuck away, compromise of source code repositories, and things like that. Maybe SolarWinds wasn’t the first but it certainly brought software supply chain security to the forefront in the supply chain for our infrastructure and software. That backend plane is where the greatest risk is for us.
There are so many different storylines in that answer. I want to touch on one of the earliest storylines you brought up in that answer and talk about tools and tool overload. You mentioned there’s a weapon for all of it. There’s a way that we can combat each threat vector. Are we in a situation where there are too many cybersecurity tools in the world? I hear this occasionally from CISOs, and they tend to be the vocal minority that I hear complaining about tool overload. In the statement you said, there’s a tool for everything. Are we in a situation where there are too many tools?
When I go to the grocery store into the wine section, I can’t conceive of the notion of there being too many choices. I can conceive of the notion that maybe I’m not enough of an educated wine buyer so I stick to your regulars. I guess in that sense, everybody, of course, is entitled to their opinion, but ultimately our opinions are expressed in the dollars we spend. The market is voting for the companies that are succeeding in the market to remain available options.
As soon as the company gets a little bit of a successful track record and then it gets gobbled up by a big public company, the trajectory is oftentimes the original customers of that technology aren’t super satisfied with that product anymore. Maybe it doesn’t progress as it used to when it was a scrappy startup, and now it’s a big corporation collecting dust. Things like acquisitions don’t seem to be changing. Companies are still getting acquired by big mothership public companies. As long as that trajectory still happens, there’s a pipeline of new technologies that are going to come in to fill that void.
You mentioned you like to focus on efficiency, avoiding unnecessary technologies or vendors. Are there any process recommendations that you can recommend to those companies that aren’t quite as advanced as Noname in their security program? How do you maintain efficiency and avoid the extra tools? Is there an evaluation process or framework that you use? I know a lot of bigger CISOs will say, “You’ve got to get through John or Amanda before I’ll even consider a purchase.” They become gatekeepers. How do you focus on making sure that you don’t have tool sprawl and risk mitigation sprawl and spend way too much money against what might be a smaller threat scenario to your company?
For me, the answer has been employee retention. Let me explain that. If I go back in my career, the individuals who were taking out new technologies for a test drive were perhaps following my guidance in some regards in terms of priorities or what to look for. They do POCs or RFPs. Once teams come together and develop their habits for how they assess technologies, I’m at a point right now where I’m quite certain that the team at Noname, and this is the same with my team at PennyMac, they’re very capable of making that nuanced choice about when is enough and how much testing of different products is enough. They say, “Yes, this is the one,” or, “No, this isn’t the one.”
It takes people a lot of repetitions. I’m seeing a lot of technologies practicing a lot of practice and POCs, and myself, as a leader, give them a little bit of top cover, time to practice, and be wrong sometimes because they’ve figured out what works for them. If I was going to buy my wife a car, it would be irresponsible of me to provide all the specifications for it. She’s the one who has to drive it every day. She has to make the selection. She has to go through her process. If someone’s practiced enough POCs and RFPs, then they can develop their intuition to make quick judgments. If there are too many tools, the engineers have to raise their hands.
This brings up another interesting question. You have had a long career. You’ve built up great teams underneath you in multiple places from multiple different-sized organizations and types of organizations. Are there any consistencies in how you lead, how you mentor, and how you grow that talent? Do you have any recommendations for first-time CISOs that might be tuning in to say, “If you got a team of 5, 6, 10, 12, or whatever it is, here are the 1, 2, 3 key takeaways that I’ve always relied upon to help my team fulfill whatever their maximum capacity could be.”
The two things that thematically continue to have good feedback, number one, is to give teams autonomy. Give individuals the last vote. “We’re looking at a new email security vendor. We’re looking at three.” That final vote shouldn’t be the CISO. The final vote should be the person who’s going to man that ship every day or who’s going to drive that car. That gives people a sense of ownership. I take a lot of pride in the engineers in particular who’ve been on teams that I’ve been on because they’re the brains of the team. It’s wise for me to remember that their experience and guidance are ultimately what I need to rely on.
The second thing is, that I take a lot of pride that I’ve not had a lot of people in my team resign over the years. A lot of that has to do with the fact that I have very open transition discussions with people early. For example, if somebody is looking for a promotional opportunity or if this particular organization is not a good fit for them and geographically, it’s a bad schedule, I will help them find a new job. What they need to know is that they don’t need to be scared of raising their hand and saying, “Something is not working for me. I’m having a problem with my manager. I’m having challenges. I need to cut my schedule differently.”
They need to know that I’m not going to freak out if they express a degree of like, “I need some change.” I bring it up. I bring up certifications, education, or what career move they want to make. I bring it up so they don’t have to, “I’m setting the tone that it’s okay that throughout your career, you’re probably going to change jobs a couple of times.” The result is retention positive because people don’t look at this team as a discussion as something they have to hide from.
In teams I’ve built, I’ve found very similar techniques that work very well and make those smart moves of saying, “Come to me first, we’ll figure it out. If you’re not right here for whatever reason, we’ll figure out where you can be right. I’ll do my best to make sure you’re successful wherever you go.” It has always worked for me over time. I do want to double-click a little bit about Noname. Noname does API security, in particular, which is a rapidly expanding market where lots and lots of customers are building more applications and starting to roll out more APIs.
Can you give me a little bit of a reason why you think API security is growing as fast as it is? What are the key drivers that are making that? You need it. You have your APIs. I presume you drink your champagne at Noname. What’s making APIs grow so fast, and what’s the right way to try to tackle that problem for the average enterprise CISO?
It comes back to the discussion about being the CTO or the application team’s co-pilot. The API is not new, but more of our infrastructure is managed via APIs. For example, virtually, every cloud management service, container, AWS, or Azure is an API call. If your organization is going to a public cloud, you are going to an API future state as an infrastructure or if your web applications are being modernized over time, we’re going from a webpage with 1 or 2 APIs to a portal with hundreds of APIs. It’s the development team’s prerogative to use an API-centric model. What we’re doing is we’re putting workloads via API, whether it’s the management plan of the infrastructure or it’s the public-facing website.
The API is not new, but now we’re traversing critical traffic over the API. It used to be the case where an API might be exchanging service information by a network up, network down, and date time group across the network. Now it’s publicly facing, and because it’s publicly facing, the level of precision on that call has to be in step with any transmission of sensitive data. The more that we expose publicly via API, the attacker community finds that low-hanging fruit because an API, if poorly designed or unauthenticated, is a fast track to data leakage.
I like the API security market. As I’ve mentioned before, Noname is at the top of that market. CISO schedules got crazy busy. I don’t know if you have a family that’s chosen some additional time for you on a day-to-day basis, but I imagine you’re a very busy man. How do you stay up to date on that ever-changing threat landscape, the latest news, and the latest risk threats? Do you have a team that does that for you? Do you have a set of newsletters you like to review? How do you remain up to date on such a fast-changing market?
I’d be lying if I said I felt up to date a lot. My role as well as my learning style is I talk to people all day. I get my professional insight into the industry largely through conferences and panel discussions with experts. That’s how I learn and stay to date to learn what other CISOs are doing in the industry. Whereas a member of our product security team is on the CVE where learning about new vulnerabilities is being published. In the moments it happens, I’m reliant on the de-escalation of those vulnerabilities or an event that happens in the world. I’m relying on the team to escalate those things situationally because my focus is thinking about the market and the patterns big picture, which is for me, it’s in person or like we’re doing here, as a face-to-face exchange.
A lot of CISOs challenge themselves to stay up to date on the latest and greatest information in the news. Many of them have a good capability to achieve that, but at the end of the day, your team is participating in keeping you up to date on that. You have such a diverse set of data you have to consume, know, and understand as a CISO. Delegating some of the, “You own CVEs, policy, this, and that,” allows you to remain up to date by working so closely with a team of experts.
One other thing too is I did a quick count. I pulled up my Slack. I have sixteen different Slack subscriptions, and about half of them are various open-source CISO networks. I am shamelessly absorbing some of the folks and the smartest people in our industry who regularly share what their teams are working on posts. Slack is our secret weapon right now. By the way, it all happened during COVID. We were all sitting at home for the first time trying to figure out how to connect. These open-source communities of CISOs spoon up. Anybody tuning into this, if you’re looking for a Slack network to plug into, I can give you ten recommendations of people who have a high degree of engagement on Slack as a peer-to-peer exchange.
There’s something to be said for connecting with your peers and working together as a global team. You were at a disadvantage against attackers. They have the luxury of infinite time. We don’t, and they have the luxury of being as focused or as distributed as they want. They get to set the boundaries or the alignment of the war. To have peers and others that you can bounce ideas off of, be open with, and be clear with is extremely valuable. That goes for any role, but certainly the CISO role, given the asymmetry of warfare. You mentioned in a previous question some conferences, like Black Hat, etc. Do you have any themes, threads, or concepts coming up from Black Hat that you’re like, “I cannot wait to hear more about X?”
I know it’s cliche but I can’t wait to see what’s coming out in AI. I know that even our SEC or RSA, companies like HiddenLayer were making a big splash. I’m super excited to see if there are 2, 3, or 4 other companies now who are coming out. By the way, in this AI space of any space, I do think of the vendors as the way that I’m going to put in my CPE hours by learning from people who know what they’re doing. I’m going to sit through presentations because I want to learn how to think about this problem set. The smartest people who are thinking about it every day are thinking about it. The part that I’m looking for is some thought leadership and AI.
I love that sentiment. We can all learn from every interaction and communication pattern. It takes a rather elevated person to recognize that and lean into that. As we wrap up this show, I want to allow you to talk about anything exciting to you right now. Do you have any projects you or Noname have running that you’d like to tell the world about? The floor is yours.
API security is a bit of a new discipline in security. We started this program we called a Workshop. It’s NonameSecurity.com/Workshop. It’s essentially a three-and-a-half hour to four-hours. It’s a live-fire practice range. It’s our contribution to education. In those three and a half hours, you play attacker and defender of a fake website, and you can use the tools of the trade, both as the attacker and to defend the network.
It gives a security pro a tangible understanding of what it means to be attacked and defend an API abuse. It’s good for CPE credits. If you have a CISSP or a CISM, we submit those hours automatically through a certification like (ISC)². It’s a good use of time, particularly for somebody who, “I know what an API is, but do I feel confident in what my organization is doing or not doing? How confident am I in our defenses?” It’s one of the practice ranges for a couple of hours.
I need to get to the golf practice range way more often because my game is not on point, Karl. I want to thank you very much for coming on this episode of Friendly Fire. Your commentary has been fantastic. We appreciate you taking the time to come on here. I want to extend a heartfelt thank you to our incredible guest, Karl Mattson.
Your profound knowledge and passion for impacting cybersecurity change have been truly inspiring. Your insights into mitigating unintentional human risk will empower our audience to safeguard their digital lives. Remember, cybersecurity is a collective effort, and every step we take to fortify our defenses counts. Stay tuned for more compelling discussions on cybersecurity. Until next time, stay vigilant and stay secure.
- LinkedIn – Elevate Security
- Facebook – Elevate Security
- Noname Security
- Black Hat
About Karl Mattson
Karl is a cybersecurity leader and innovator who serves as the CISO for Noname Security. He has over 25 years of experience leading innovative and diverse teams of technology and security professionals in financial services, retail, and federal government.
Previously, Karl served as the Chief Information Security Officer (CISO) for PennyMac Financial Services and City National Bank. He has a track record of providing CEOs, CTOs, and investors in cybersecurity with strategies for product, market, and customer success.