The importance of API security and PII

[00:00:00] Chris Sienko: Every week on Cyber Work, listeners ask us the same question. What cyber security skills should I learn? Well, try this. Go to infosecinstitute.com/free to get your free cybersecurity talent development e-book. It's got in-depth training plans for the 12 most common roles, including SOC analyst, penetration tester, cloud security engineer, information risk analyst, privacy manager, secure coder, and more. We took notes from employees and a team of subject matter experts to build training plans that align with the most in-demand skills. You can use the plans as is or customize them to create a unique training plan that aligns with your own unique career goals. One more time, just go to infosecinstitute.com/free or click the link in the description to get your free training plans, plus many more free resources for Cyber Work listeners. Do it, infosecinstitute.com/free. Now, on with the show.

Today on Cyber Work, our guest is Giora Engel of Neosec, and our focus is securing APIs. Find out why APIs are the new network, why their very nature makes them vulnerable to abuse, and how to position yourself as an authority in the ever growing field of API security. All that and a little entrepreneur talk today on Cyber Work.

Welcome to this week's episode of the Cyber Work with InfoSec podcast. Each week, we talk with a different industry thought leader about cybersecurity trends, the way those trends affect the work of InfoSec professionals, while offering tips for breaking in or moving up the ladder in the cybersecurity industry.

Giora Engel is a successful serial entrepreneur who founded LightCyber, later acquired by Palo Alto Networks in 2017, which laid the groundwork for what would later become an XDR. He is also the chair of the Fraud Prevention Task Force at Financial Data Exchange, FDX, within FS-ISAC. Prior to founding Neosec, he served as VP of Product Management at Palo Alto Networks. Giora is recognized innovator in cybersecurity, cyber warfare, and behavioral analytics, and hold several patents. His broad range of technology experience spans network analysis, cybersecurity, algorithmic coding, and mission critical systems.

So today's talk, we're going to talk about API security and how it relates to personally identifiable information or PII and some of the information that lies behind the API. So let's get to it. Giora, thank you for joining me today on Cyber Work.

[00:02:36] Giora Engel: Thank you for inviting me.

[00:02:38] CS: My pleasure. So to start with, I always like to get to know our guests a little bit by tracing their interests. So when did you first get interested in computers and tech, and what initially drew you to cybersecurity?

[00:02:53] GE: So I think my first experience was in elementary school. I basically started coding. Back in the time, back in the day, it used to be much – You had to really be interested in that because nobody had computers at the moment.

[00:03:08] CS: Yeah. It was not like every student had to have a baseline analogy. You had to be – It was – You were a specific outlier I imagine.

[00:03:15] GE: Yeah, for sure. I did a lot of electronics, which is not a thing to do anymore, I guess. But as a kid, I really enjoyed it. Yeah, I'm in computers. I got to understand that this is really what I'd like to do.

[00:03:30] CS: Yeah. Electronics in the sense of what? Like you were maybe building like radios or like sort of little electronics projects like that and stuff?

[00:03:37] GE: Yeah. All sorts of electronic projects like blowing up things. That is the thing, kind of like all sorts of fun.

[00:03:45] CS: Did that connect at all to yours sort of knowledge of computers in the sense of – Because some people can code and set up security perimeters all day long. But did you also have a good sense of like the guts of computers in that regard? Was there an interest in like taking apart computers and understanding how they work?

[00:04:03] GE: Yeah, exactly. I think it’s that taking apart and understanding how stuff works I think also applies to then hacking and kind of understanding things from the inside out.

[00:04:14] CS: Gotcha, gotcha, gotcha. Okay. So yeah. It’s take it apart and, hopefully, put it back together mindset. So can you talk about some of the formative projects, positions, experiences, or lessons that put you on the path from your days with the Israeli Defense Forces in the early 2000s to your present day role as CEO of Neosec. I mean, it seems like founder CEO springs up a lot in your background. So we mentioned that in the bio, but you're sort of a serial entrepreneur as well. What's the appeal of that? Again, I guess, I imagine it's building things, right?

[00:04:45] GE: Yeah. So I think when I started my army service, I kind of transitioned from just coding stuff to leading new projects and new ideas and new startups in a sense. I was very fortunate to be in a place where my innovation and basically thinking about new things and implementing new things that nobody thought about doing before was actually making a huge difference. So that really, I think, was maybe first step that prepared me for being a founder later on.

[00:05:19] CS: Yeah. Yeah. Oh, sorry. Go ahead. I mean, can you talk about like sort of that first feeling when you sort of like put together your first company, and then you watch it, say, maybe get acquired. Then you move on to the next thing. Like when was sort of like the moment when you were like, “Oh, I'm really good at this. I want to keep doing this.”?

[00:05:40] GE: So I think in this world, I mean, there's a lot of – You hear only about the successes. There's also a lot of hard work that is not necessarily successful. Maybe I'll start actually with like my first company was a company that was not as successful. I started that company in a space that is not cybersecurity. At the time, I thought that there was a need for that. There are a lot of things that did align. But eventually, it was – I realized after the fact that it was impossible to build a large business in that particular industry. So it was about maybe two years of doing a lot of work and having some successes but not the ultimate success, eventually.

Then I started LightCyber, which was my previous company. LightCyber was the inventor of XDR. We started the company in 2011. At the time, starting companies in cybersecurity was not as hot as it is today. I mean, today, there are so many companies. But back then, we were one of the first companies that started this new wave of cybersecurity companies. But we saw a real problem, and I think we had domain expertise to understand the problem better than others. Having that experience from the army service and so on, we knew how attackers operate. While all the other vendors, including big vendors, thought more about the technical artifacts, the malware, and they didn't really understand attackers. So I think that really gave us an advantage. Eventually, we built LightCyber. We were the first XDR and , eventually, we got acquired by Palo Alto Networks.

[00:07:28] CS: So just to sort of clarify , the thing that sets you apart from, like you said, even the larger companies that were in the same space was that while they were dealing with the sort of technical issues, you were thinking in terms of what like the hacker mindset. Is that what you’re saying?

[00:07:42] GE: Yeah. When we started LightCyber, nobody was thinking about the adversary like as an entity. They thought about only the technical artifacts and malware that they see. They thought about the specific maybe attacks or attempts, but it didn't understand that there is a human attacker on the other side that had some objectives. That was really the new thing. But understanding the attacker could let us focus on effective ways to detect and respond.

[00:08:12] CS: Can you talk about how you sort of adjusted your methods to this way of thinking versus – You know that I mentioned it's sort of like, “Well, if this thing comes, then this door slides down. If this thing comes, then we lock it this way.” So how did you sort of adjust your sort of strategy in terms of how you created your process?

[00:08:32] GE: So when you deal with realistic attackers, as opposed to just technical artifacts, I think it's more of a behavioral analytics question because at the end of the day, there's a human coordinating different aspects of the attack. Then typically, behavior analytics is the answer. It's also the connecting line between LightCyber and between what we do today at Neosec. These are the different areas of attack and different attackers. But understanding what the attacker is trying to achieve enables us to come up with a good solution of how to find or detect attacker behavior versus just other noise that exists out there.

[00:09:18] CS: I got you. Okay. Thank you for the clarification there. So today's topic, as I said, we're talking about API security. So I was sort of sadly ignorant of this a while back. But regular InfoSec guest, Alissa Knight, talked about API security and how she did a presentation, where she hacked the APIs of several organizations from the stage during her talk. But that was a while ago. So for our listeners who are new to the concept, can you break down exactly what an API is and what role it plays within networks and organizations, especially as regards those that collected sensitive information?

[00:09:55] GE: Yeah. I think the best way to think about APIs is like the new network, in a sense. I mean, if we think about the network, it has a lot of different layers. It has the physical layer where we connect cables. It has the Internet. It has like different layers that are built on top of the other. APIs is actually the top layer. Beyond all these networking layers, there is another, typically, HTTPS protocol. That basically enables to implement these APIs, and the APIs are just a way of communicating requests and responses. I mean, like different software components for the information and receive the information.

I think the best way to think about it is that today, in practice, this is the new network. It doesn't really matter if you're implemented in a data center or in public cloud like AWS. At the end of the day, you need to connect different software components together in order to provide a service. Maybe even more important than that, most of the services today are digital services that we consume as people and as companies. Therefore, the connectivity between the client and the provider of the service is all digital. So that is all enabled by APIs, and understanding the API is basically understanding the way that data and services flow today.

[00:11:27] CS: Yeah. I think the thing that sort of Alissa said was that it's something that I think a lot of people kind of set. Just turn it on and forget it. Or don't give it a lot of thought in terms of whether it's secure or not. It's just sort of like another link in the chain, and it seems like one where it's getting – It’s more impregnable than people would require or would expect, right?

[00:11:52] GE: 100%. I think that's one of the big changes when it comes to APIs is that it's actually not related to specifically the way that APIs work. But it's really to the reason why APIs are needed. Businesses today need to expose their services to the outside. So it's no longer just a way for internal components to communicate. It also solves that problem. But the more important problem that it solves is how to externalize your services and your products and your data to the outside because your clients are typically on the outside.

So we came from – I mean, we kind of transitioned in the industry from having business systems that are buried inside our network and gated by a lot of different gates into a place where our core business has to be exposed to the outside through these APIs because this is what we do. I mean, this is what we need to do from business perspective. But, of course, it brings a lot of risks because when you expose your core business to the outside, let's say if you're a financial institution and so on, you have to do it. But there's also so much risk in it because other people can – I mean, attackers can also try to use it against you and so on.

[00:13:14] CS: Right. So in our pre-show discussions, you were careful to mention that API security wasn't just about rogue actors, although that's certainly a big part of it, but also could involve misconfigured API. So can you talk about some of the common misconfiguration errors, why they happen so often, and some best practices for both implementing and testing your company's APIs to ensure that they're not inviting intruders?

[00:13:36] GE: Yeah. The first problem that we see typically starts from lack of inventory. That's even more basic than misconfiguration because if you don't know what your APIs are, you can't even ask yourself, are they configured right or robust enough. So it starts with that. Once you have a good understanding of your APIs, you can ask yourself, what is the way that they're implemented, deployed, configured to make sure that the right access controls are implemented and the APIs are built in a way that doesn't reveal more information than it should?

The hard thing about it is that all these details are actually kept in a lot of different places. I mean, some of it is in the API gateway. Some of it is actually in each specific micro service. So that code of – That controls authorization of who has access to what. In a lot of other decisions of how much information do you answer when you get these requests and so on, it’s actually buried in a lot of different places. So it's super hard to enforce it in one place. There's really no way to do it. So as a result, there are a lot of the different sensitivities and vulnerabilities that can be part of these APIs, API implementations.

But then vulnerabilities are not the only thing because vulnerabilities, I think what's good about them is that if you detect them on time, you can fix them. You can improve them. But even perfectly written APIs can be abused. That’s, I think, what's maybe new about APIs versus just the technical infrastructure that they sit on. Again, because they give you kind of a window or a portal to your internal business logic, there are a lot of good reasons why authenticated access would like to get more than it should. Sometimes, you can have a partner that uses APIs excessively or a new user on the system that is trying to use it in order to create many users and maybe get some benefits of new user creations and so on. So all these small things are basically ways to abuse the APIs without even hacking them.

[00:16:17] CS: Right. Those are more like insider threats then. Is that reasonable or –

[00:16:22] GE: They're not necessarily insider, though, right? I mean, it could be an external third party that has access to the API, either a partner or a user.

[00:16:33] CS: Okay. Gotcha. Gotcha. Yeah, yeah. That is interesting. So I mean, at this point, there's not really a sort of easy answer to issues like that. Is that correct?

[00:16:49] GE: I think it goes back to the business sensitivities in the end of the day because, again, if API is a new network, you need to – I think the next question that you need to ask yourself is what are these core services that you expose to the outside as part of your core business? What do you do in order to protect them, in order to make sure that they're used correctly? It’s definitely beyond vulnerabilities. Vulnerabilities by themselves would not solve the problem.

[00:17:19] CS: Right. So speaking in terms of the sort of valuable things that are within, so it seems that APIs and especially those on personally identifiable information or PII, such as in finance, like you said, or health care, these are definitely tied to privacy issues. So we just had a live event recently, as I work live, in which we talked about privacy and regulation and how they differ from one part of the world to the next. Obviously, there's different privacy certifications and knowledge bases and stuff. So what role does API security and configuration in the privacy regulations required by places like the US, Canada, Europe, and others? Are there variants that you'll need to know about when sort of thinking about your API security?

[00:18:06] GE: Yeah. So I'll give you maybe another angle to that. I think it's actually really interesting to understand that regulation sometimes actually forces you to expose more through APIs. So it's maybe before even addressing the regulation that tells you to make sure that you're not exposing too much. So there's – One common regulation in the world is open banking. Open banking is more in Europe than in North America. But it basically forces financial institutions to expose their core payment capabilities through APIs. It forces them to actually let all the different companies that participate in the ecosystem to be able to hit their APIs, even if they don't know them. So that is one area.

Another area of regulation, actually, in the US is that in healthcare, the insurance companies are required by regulation to expose all the PHI information for what's called interoperability so that they can interoperate between themselves automatically and without paper trail. That basically means that they have to expose their most sensitive data in a way that they can truly control exactly how it's accessed but in a certain way. So maybe the conclusion from all of that is that regulation today for business reasons requires you to do more and more APIs.

In the same time, there are some compliance frameworks that help you to identify what you need to do in terms of protecting the data and not exposing information that you're not supposed to expose and so on.

[00:20:01] CS: Now, in your opinion, if someone is interested in getting into this aspect of privacy and API security, would it make more sense to specialize in sort of one part of the world? I mean, obviously, if you're living in a certain place, you're probably going to want jobs in that area. But Chris Stevens, one of our instructors, has the entire rainbow of privacy regulations from all around the world and can work anywhere in that regard. But do you think that there's just too much to sort of take in to be – You have to be kind of like master of one thing. Or can you really sort of specialize in a diverse way like that?

[00:20:46] GE: I think if you're limiting your question to privacy frameworks, I think, yeah, there are some different frameworks in different parts of the world. But I wouldn't necessarily think about it that way. I think APIs, since we said that APIs are kind of the new network, there are a lot of different aspects to it. One of them is privacy. But I think it makes more sense to maybe start from the basis and understanding API platforms, maybe even on the product side. I mean, what is the business reason for exposing APIs? Being part of that is probably super interesting. From there, you can get to different aspects of security and so on.

So in a sense, I think that understanding API frameworks is, I mean, a super interesting area, regardless of security. Definitely, within security, it requires some specialization to learn more about application security, rather than just the infrastructure security.

[00:22:01] CS: Okay. Yeah. To that end, I get the sense that when we get into areas like privacy and personal data, that for a lot of companies, there's kind of a checklist mentality for companies trying to stay within regulatory guidelines. Each requirement is kind of checked off by wrote, rather than thinking about how the entire thing fits together and mutually supports the data trying to be protected. So can you talk about creating a security plan for PII or PHI, with your API security that goes beyond the checking of boxes, and you're really thinking about the realities of data usage, retrieval, storage, cultivating, and when the time comes to storing?

[00:22:41] GE: So building a security framework around APIs, I think, is very similar to managing other assets. Let me draw the analogy here. So when you look at your physical assets and network assets and devices in your network and so on, you need to have an inventory of devices so that you can know what to protect. Same for APIs, you need to have some kind of asset management. You need to have inventory of APIs. So this is kind of step one.

Step two is the way that you can find vulnerabilities and understand what are the inherent sensitivities in some of these APIs. Then the third step is kind of monitoring how they're used because they're not a static resource. I mean, they're actually meant to be consumed. So being able to monitor that activity and find abnormal behavior or abuse of the APIs is important. So these are, I think, three steps that are very much equivalent to managing other assets from a security perspective, just applying the same methodology, terminology to APIs.

I think what's unique to APIs, though, is that you can actually directly connect it to a business purpose. Because if every API service is directly linked to some kind of core business service, and the benefit of that is it makes it possible to understand exactly what is the business meaning of using this API, and what is the business meaning of abusing the API or losing data through the API. It's very, very clear. I think that's what's so exciting about this field is that it's no longer just an infrastructure component and kind of indirectly related to your business. Abusing the APIs is directly related to your core business, therefore worse.

[00:24:45] CS: Yeah. I was going to say it spiders out into so many things from risk assessments and threats and so forth. Well, that's a perfect way to sort of pivot into the work side of the Cyber Work podcast. So API security, obviously, doesn't have maybe the same glitzy allure as, say, rules in pentesting or red teaming or incident response or even maybe creating security systems. But as an incredibly vulnerable gateway to your organization, having security professionals in your company that can get it just right is going to be very important.

For listeners, who are interested in working in API security and related areas, so what are some skills, experiences, education, hands-on work that they should be getting involved with now, in order to demonstrate their qualifications to a hiring manager?

[00:25:32] GE: First of all, I think it's a good topic to focus on for a lot of people because in my view, that is really the future of security. It's also – API is the future of software development. I would say not even the future. Just this is where things are today, and there are only going to be more and more of that. Definitely, from a security perspective, security is one step behind because, first, we need to create the thing, and then we need to secure it in a sense. So from a security perspective, I think application security is definitely the new frontier. It’s definitely a good area for people to focus on.

What did I need to do in order to get there? I think learning application development and application security is important. APIs are part of that. For that, I think understanding application platforms and that technical basis is important because once you have that basis, you don't have to be a developer necessarily to be a good security architect. But you need to understand these development concepts. You need to understand how API calls are made and how API frameworks are built and what are API specifications and so on. I think once you know all of that, I think it's easier to understand how to protect them and how to do security for these environments.

[00:27:09] CS: Do you have a sense that a lot of companies are hiring for that specialty? Or are they thinking that people who have other security backgrounds that, oh, you're also going to be sort of securing our APIs and so forth? I mean, is that – I mean, obviously –

[00:27:26] GE: You mean specialty, yes.

[00:27:27] CS: Yeah, specialty in a huge financial thing. I'm sure, maybe you have specialty people. But is that the case across the board you think?

[00:27:33] GE: Yeah, for sure. I think some places call it product security, which kind of focuses on securing the product that you deliver, as opposed to the infrastructure. Some other places call it application security or OpSec. In some organizations, OpSec people are part of the developer team. In some other organizations, it's more than the security team or sometimes in both places. So, yeah, in order to be part of that, I think it's important to understand software development, more than it used to be for security people. In a sense, I would say that application security is more closely related to the product development, compared to infrastructure security, that kind of original security that is more closely related to IT, in a sense.

[00:28:29] CS: Yeah. No. Yeah, I totally agree. But that's what we're seeing. As more and more things come online, come into the cloud, are interconnected, that no industry and no service is going to make it without the sort of interconnected security issue. So, yeah, that doesn't surprise me at all.

One sort of speculative thing, and I don't know if this is even – If there's anything to this. But because of their location in the security network and the ease of which you can sort of abuse or take over, APIs can be a surprisingly, I think, fragile point in the security chain. So I think in past, we've seen things like universal spam filters for email or just the way that malware is seen and attacked and so forth. Do you see any universal industry changes to how APIs work or are made that might make them more intrinsically safe or hack-proof in the future? Or is this something that is always going to kind of be with us?

[00:29:35] GE: I think, I mean, I'm trying to not spread fear or that type of thing. But I think it's kind of inherent in the way that we build APIs. Building APIs is synonymous with digital transformation and building more product capabilities. I think the main purpose of these APIs is to expose these capabilities to the outside from a business perspective. Therefore, I think there's always going to be that business sensitivity. I mean, we expose more and more over time.

[00:30:07] CS: Yeah. There's sort of a controlled danger there. It's like it has to happen if we're going to let it through. Okay. I see.

[00:30:12] GE: It has to happen. I don't know if there's a silver bullet that can make the APIs better. I think in – Naturally, I mean, if people have better tools and products, and they have good sense of their inventory of APIs, and they eliminate vulnerabilities, that's good. But I think we're seeing that building product securities is an inherent part of building product. So you always need to invest in that.

[00:30:45] CS: Yeah. No, I think it's a really a great way of putting. I think that's also – It sort of future-proofs people who want to work in securing these systems, is this is not something that's going away. It's not going to change. It's always going to be something that we need qualified people to work with.

As we wrap up today, why don't you tell us a little bit about Neosec and what types of tools or services you offer your customers? Do you have any projects that are coming up that you're especially excited about? You can tell us about that as well.

[00:31:19] GE: So in Neosec, we secure API. We protect API against abuse. The way we do it is three main areas. First, we discover all the APIs and create that inventory automatically. Then with the inventory, we can also find all the vulnerabilities and rank the risk and help manage that risk and recommend the next step of how to fix it. Then the third step is being able to detect abnormal behavior. So let's say your APIs are perfect. They don't have any vulnerabilities. I mean, they probably would have some.

But let's say you're on top of that. Still, your perfect APIs can be abused because your authorized users might be compromised, or they might be misimplemented or have different interests in the new. So preventing, detecting, and blocking that abuse is super important. I think what's unique for us is that we do it in an XDR like way, which means that you can always go back, investigate, threat hunt. All these things that we're used to doing in XDR are kind of fundamental capabilities that we built in Neosec.

[00:32:35] CS: Nice. Finally, one last question. For all the marvels of our guests who want to learn more about Neosec or Giora Engel, where should they go online?

[00:32:44] GE: Definitely go to neosec.com. We have a great resource on learning more about APIs, different kinds of APIs, frameworks, and so on. So definitely check it out.

[00:32:54] CS: Cool. Giora, thank you so much for your time and insights today. This was really entertaining and informative.

[00:33:01] GE: Thank you.

[00:33:02] CS: As always, I'd like to thank you all for listening to and watching the Cyber Work podcast. It must be said in an unprecedented scale. In the past three months, all of you have helped to more than double Cyber Work’s viewership on YouTube. For that, I am thankful and humbled. If you're subscribing, thank you. If you're watching when it goes live on Mondays at 1:00 Om, Central, thank you even more. And if you're telling friends and colleagues, thank you, thank you, thank you. We're delighted to have you all along for the ride.

So every week on Cyber Work, listeners ask us the same questions. What cybersecurity skills should I learn. So I always recommend you try this. Go to infosecinstitute.com/free and get your free cybersecurity talent development e-book. It's got in-depth training plans for the 12 most common roles, including SOC analyst, penetration tester, cloud security engineer, information risk analyst, privacy manager, secure coder, and more. We took notes from employers and a team of subject matter experts to build training plans that align with the most in-demand skills. You can use the plans as is or customize them to create a unique training plan that aligns with your unique skills and goals. So one more time, that is infosecinstitute.com/free. Or click the link in the description below and get your free training plans now.

Thank you once again to Giora Engel and Neosec. And thank you all so much for watching and listening. As always, we’ll see you next week.