Hello everyone. A warm welcome at CON42 DevSecOps 2024 conference. APIs are like teenagers. They need constant supervision or they will break the rules in ways you never imagined. That makes API security sound more like parenting. It's challenging, it's hard, and there are no guarantees. Welcome again to the talk on API security in DevSecOps. A brief background about myself. I am Anirudh Karandikar, Principal Software Engineer at Fortune 500 company. I am a full stack engineer with a niche skill set in API management and have around 18 years of industry experience. As part of my work profile, I deal with all phases of APIs, right from inception to governance. All the views and opinions expressed here are based solely on my observation and in general industry research, and as such have no binding on any of my employers. Having said that, let's jump right into the agenda. So first and foremost, we'll see why do we even need API security or why do we even care for API security. Then we'll take a look off about what do we mean by security mindset. Then we'll gloss over some of the security best practices in API design, development, testing, release, operations, and monitoring. Basically, we'll walk through the SDLC lifecycle of API management. So why API security? Let's take a look at a few of the stats. Rapid API growth. By 2025, over 80 percent of all web traffic is expected to pass through APIs, making them a vulnerable target for attackers. About 91 percent of organizations have experienced some sort of an API security incident in last year. Underscoring the critical need for proactive security measures. Cost of security flaws. It costs astonishingly 30 times more to fix a security vulnerability in production than during design phase. Highlighting the importance of early security integration. The underlying messages catch them early, catch them often. Human errors in API security. This is a very important stat. Nearly 80 percent of API vulnerabilities are caused either by misconfigurations or by coding mistakes. Proactive security majors are needed in API development lifecycle. And we will take a look at a few of these majors later in the talk. Rising API threats. APIs are becoming the most targeted attack vector, exceeding web applications in frequency. Web applications held this crown for a long time, but today APIs are numero uno. Security testing gaps. Despite the high risk, only 40 percent of organizations test their APIs for vulnerabilities during development. Many systems remain exposed to attacks post deployment. This underscores the need of having security testing as part of the overall testing strategy. So now let's take a look at what do we mean by security mindset. But before that, let's see what DevSecOps advocates. So traditionally development, security and operations have been its own silos. DevSecOps advocates a cultural shift in which there is a need to break these silos and draw synergies and collaboration between development, security and operations. Now, once you have this practice established, What security mindset or security first principle means it is it emphasizes embedding security at every stage of software development lifecycle, ensuring that security is a shared responsibility. So the underlying fundamental tenet is security cannot be an afterthought. It needs to be ingrained right from its inception during planning and design and then carried through all the subsequent stages be development, testing operations and monitoring with the objective to proactively identify and mitigate the vulnerabilities early in development, because as we saw earlier, the cost of fixing security in production is very high. So let's take a look at a few of the API design best practices. This is not an exhaustive list, but it highlights some of the key security areas. So first and foremost is authentication and authorization. Now it's a big topic in itself, but at a very basic level, All the APIs need to solve for a need to validate their API consumers and identify who they are and whether they have the right privileges to access this particular endpoint and the data exposed by the API. Now, there is an OAuth specification that explains quite in detail how to do this. As to how an authentication and authorization should be implemented. And then there are identity providers like Okta or Azure that have already implemented parts of this specification. So enterprises today can leverage any of these IDPs to realize their authentication and authorization requirements. Data encryption, in the Veeam, in the same Veeam of Authn and Authz, the next important step is to classify your APIs based on the data that they are exposing. Now it could be restricted, confidential, public, or internal API. Depending on that, the data encryption needs need to be designed. Most of the enterprises today are doing decent when it comes to encryption at rest. However, it's equally important to encrypt the data during transit. If I were to take a case of rest APIs, then H three t ps with DLS 1.2 is a given. But I would advocate even one step further, and I would say that it needs to be explicitly encrypted. If you could use hybrid encryption and good. If not, you can use a single encryption, algorithm like a ES. What, is, an important nuance is due to performance reason you may or may not be able to encrypt the whole payload, in case of latter. It is imperative that you at least encrypt the sensitive attributes, in the request and response payloads. Limit sensitive data. The underlying principle is, reduce the attack surface. So design APS to return only necessary data to users, minimizing exposure of sensitive information. Configuration management. We saw a stat earlier that about 80 percent of the incidents are caused by human errors. And configuration management is one of the key reasons out of it. So during design, it is, Very imperative to design. How are we going to manage our configurations? And it's not only related to your APIs, but configuration related to all the components that APIs interact with. Those could be your API servers, databases, caches. Another good strategy to think about at design time is how are you planning to propagate these configurations across environments and up to production. Logging and observability. They say you can only protect or secure what you can see and measure. So that makes logging and observability a critical component of design. You absolutely need to have logging frameworks and observability in place so as to monitor API usage, detect anomalies, and enable forensics. However, it's a double edged sword. When it comes to logging, you have to be careful that you are not logging sensitive data. If there is absolute need to log sensitive data, then at the very least, that data needs to be masked and then it needs to be stored securely. so that only the people who need to have access to that data have access to that particular piece of data. Error handling. This is more for your presentation there. So use generic error messages to avoid revealing implementation details while locking specifics securely. many attacks have been happened because the error messages were too descriptive and hackers could find a way to bypass those particular errors. So you have to be very careful, especially if these error messages are getting exposed. Access control. Clearly define what are your public APIs and internal APIs. Have this classification done at the design time based on the very purpose of that API. Again, many attacks have been happened because The APIs that were supposed to be internal were exposed on the internet and by the very nature of it, they had less security guardrails around it and that was exploited to gain access to the system. Rate limiting and throttling. This is a industry practice and there are products that will help you achieve rate limiting and throttling. So implement rate limiting and throttling to control request frequency and prevent abuse. This is basically to avoid the risk of DDoS and DDoS attacks. Input validation and data sanitization. Yeah, this is again a well established industry practice. Validate and sanitize all incoming data to prevent injection attacks like SQL injection, XXS, and so on. Token expiry and refresh policies. This is a key call out. Set expiration times for tokens and establish secure token refresh mechanism to limit misuse. Many attacks have happened due to the long lived tokens. Tokens usually have access to parts of the system and as long as they are not expired, they have the risk of being exploited. API versioning. It is a good practice to have your APIs versioned and to maintain a list of which consumers are accessing which version of APIs. This is especially important if you are releasing security fixes as part of your versioned APIs. And it is also a good practice to have your API consumers move to your latest APIs and then deprecate the outdated APIs. Again, a lot of attacks have been happened because the outdated APIs were running into production and those APIs were used as a backdoor entry into the system. Secure API documentation. Restrict access to API documentation, especially for private APIs. Limiting it to authenticated users. Again, it has been a finding that many attacks have been happened due to the API documentation being exposed on the net. And that same documentation was used to design well crafted attacks to bypass the security of those APIs. Minimum privilege principle. I think this is a general good practice, not only for APIs. Design APIs to grant only the necessary permissions based on user roles or scopes or privileges. And lastly, request and response payload site restriction. This is again, one of a good strategy to prevent resource exertion attacks. The modulus operandi of these kind of attacks is, you would have a valid request with valid request headers, but they would stub garbage data inside your request or response payloads so as to overwhelm your system. So one of the ways to prevent these or to put such kind of requests in check is to have a check on the request and response size payloads and then reject all the payloads which are not adhering to that particular restriction. So after design is done, let's take a look at a few of the best security practices in API development. First is software version. Regularly update software libraries and frameworks to eliminate known vulnerabilities. It is a good practice to have a certain amount of bandwidth reserved. if you're falling agile, reserve a certain bandwidth of your effort for software upgrades or technical upgrades. This helps you get out of tech debt and it also limits your attack surface. In the same vein is dependency management. Software today's rely on a lot of third party libraries or third party softwares, and your code specifically may not have any vulnerability, but the dependency that you are using might have that. A good example would be a logging library like Log4j. There are tools in the market like Renovate that help automate dependency updates. ensuring that your software is always secure. Secrets management. Use tools like HashiCorp Vault or AWS Secret Manager or others that are designed specifically to store secrets or sensitive information. There are also tools available such as ggShield that detect and prevent accidental commits of sensitive information in source code. This ties back to that stat earlier which we looked about human mistakes like accidentally leaking secrets into your Git repositories. Tools like ggshield help arrest these security reviews and scans. Most enterprises today employ some form of CICD pipeline. So it is a good practice to integrate your static and dynamic analysis tools into your CICD pipelines. to continuously access for vulnerabilities. Another key call out is your peer reviews. So peer review should not only focus on your functional reviews, but they should also take a look on the security of that code. is the code following some of the best practices and, is the exposure, limited, Is it classified correctly, like we saw earlier, whether this is an internal API or external API or the data classification thereof. It would be even nice if there is some sort of a checklist, which is custom or tailor made, depending upon the code you have, infrastructure as code. This is a good SRE practice, which also helps drive security in terms of consistency and having the version control and security checks in place. So what do I mean by that? So let's take an example. For example, I have to set up an AWS resource like say S3 bucket, and I'm doing it manually. if I have to do this across, let's say, 10 environments and also on production, there is a chance that while setting this up manually, I might miss a certain access control policy or a security check in one of the environments. Doing it as infrastructure as code, allows for those version controls and checks to be in place every single time, knowing that each environment, in each environment, it would be set up in exactly the same way. Automated code quality checks. There are tools like Sonar Cube, to evaluate your code quality alongside your security, ensuring code is maintainable and adheres to best practices, which indirectly improves security. you can even shift left, like there are tools that can integrate with your IDs, like Sonar Lint or check marks that provide instant feedback to the developers while they are coding. And they highlight the best security, Practices as well as if their code has any vulnerabilities. Moving ahead. Let's take a look at security practices in API testing. The first is static application security testing. Analyze source code early in the development cycle to catch vulnerabilities before deployment. Yes, we saw like typically enterprises today employ some sort of CSAD, so it's a good place to integrate. SAST testing, dynamic application security testing, or DAST. Test running applications to identify security weakness through simulated attacks. So the well formed simulation attacks are formed and those are tested against running applications to discover runtime security discrepancies or anomalies. Container scanning. Most of the APIs today employ use containers and some sort of container orchestration tool. The most popular ones are Docker and Kubernetes. However, the base images that are used for building these containers might have vulnerabilities. So it's absolutely imperative to scan container images for vulnerabilities to ensure secure deployments performance testing. This is a good strategy. always have both tests set up, in one of your environments to evaluate API performance. Under various conditions adjusting parameters like rate limiting to prevent abuse So they not only help uncover the benchmarks, but they also help Discover any security anomalies, especially when under load like what happens if your timeout Increases what happens if your backend systems are not responding? In time, does it accidentally expose any security vulnerabilities? So these are very good tests to have. And lastly, security testing. Conduct negative tests, negative access testing and penetration testing to discover and remediate security gaps effectively. A major chunk of your testing strategy should focus on security testing, not only your functional testing. And this is like explicitly conducting negative testing to break your systems. Because as we saw, the cost of fixing this in production is very high. Moving ahead, let's take a few, take a look at a few of the security best practices in API release. so the first and foremost is canary deployment. again, this is a good SRE practice and also it helps security as well. So what do we mean by canary deployment? This is a practice in which we gradually release updates To a subset of users allow allowing for monitoring and rollback if issues arise So imagine if your latest deployment has some security issues then as part of canary you will only release this to a subset of users thereby reducing the attack surface And once you identify it's easy to roll back. So the basic fundamental principle behind this is limiting your attack surface. The next is automated sanity testing, integrate security test cases in CICD pipelines to ensure every deployment meets security standards. the keywords here are automated, so that it becomes part of each and every deployment. You run those negative access testing and penetration testing, and you test those against some of your key flows to make sure that deployment meets security standards. Your standards, security, your standards, security standards. Moving ahead, let's take a look at some of the operational security practices. Now, most of these, are curated for if your APIs are exposed in public. But nevertheless, it's good practice to have these components as part of your API infrastructure. So the first one is Web Application Firewall or WAF. There are many COTS products available for WAF. So use WAFs to shield APIs from common threats such as SQL injection and cross site scripting. Next is bot detection. There are tools like sequence that identify and block malicious bot traffic protecting api resources These are usually policy based and configuration based so you can determine how your normal user traffic looks like you can also Distinguish between good bots meaning the bots that you specifically have returned versus the general api crawlers api gateway api gateways Can do four or five important functions. So let's take a look at that. This is your first line of defense. where in you can implement your access restrictions. So you need to have your auth and analogy policies configured in API Gateway. Next is translation. they can do your request translation, wherein they can enhance your request headers based on, some of the origin, It is coming from and other different parameters third is routing They help isolate your front end from your different backends like they can do the necessary routing based on the endpoint and other Configurations fourthly they can do rate limiting and throttling. So this would be the best place to configure your rate limiting and throttling policies to prevent DOS and DDoS attacks. And fifth is security compliance, schema compliance. Sorry. What do I mean by schema compliance is earlier we saw resource exhaustion attacks. And one way to address that was your request and response size restriction. Schema compliance is another strategy to address that. And what do I mean by that is every request is check whether it is adhering to a schema. Like you can define how your API request should look like. And if those requests are not adhering to those schemas, then those requests are rejected right there at the API gateway layer, protecting your back end API resources from getting overwhelmed. SIEM solution. SIEM stands for security information and event management systems. And these are the systems that are designed to gain real time insights into security events. If I were to give some of the examples, it would be Splunk, IBM QRadar or Microsoft Sentinel for Office 365 and other Microsoft offerings. The key fundamental principle of this is in today's day and age APIs are a lot of complex, like it's not simple. If you were to, if you were to look at the APIs, it looks more like a mesh structure. and in, in such a complicated mesh of webs, mesh of APIs, it's not easy, to troubleshoot if you are only focusing on one single component. So what same stands are? The underlying principle is it can take a look at different systems and try to establish correlation between them. So it can take a look at logs between different system. It can take a look at the log forensic results. It can take a look at your real time threads, your user monitoring dashboards, your reporting dashboards, device monitoring dashboards, and other stuff. So the idea is one system in isolation may or may not able to determine all the security vulnerabilities. However, if you take a look at all the different components and try to correlate them, you can uncover a lot of security anomalies, and thereby proactively. proactively address those anomalies. Moving on, API monitoring security practices. First and foremost, you need to monitor metrics. At the very least, you need to have your red metrics. So your red stands for rate, error, duration. These metrics, help to track API performance and availability continuously. Next, security control testing. Regularly validate security headers and access controls to ensure compliance with security policies. The best way to do this would be your API gateway, because that's your first line of defense. Third sample tracing. there are tools like Yeager and AppDynamics that h that imp, that help track, your API requests. and these are configuration based, like you typically have something called a sampling rate. Let's say you. 1, 000 requests per hour, then a sampling rate of 1 percent means you can sample 10 API requests. and what do these sampling help is you can basically trace these APIs, from point to point communication and see what payload is being passed across these APIs. It's like taking an x ray of the system so that you know how your system is working under the hood. And the third is access to tools and this goes back to the DevSecOps, cultural shift. So earlier, as I said, there were silos like development and operations and only the operations team used to have access to monitoring. but it's, It would be a great shift to have that monitoring dashboards access to all the non operations people, because that way you can facilitate proactive security management and uncover security anomalies faster. so far we have seen why we need API security, what do we mean by security mindset and walk through some of the. best practices across all the SDLC life cycles. Now it's time to bring all of this together and conclude. So in today's digital landscape, securing APIs is not just an option. It's a necessity. The security first principle in DevSecOps emphasizes the importance of integrating security at every stage of software development life cycle. By embedding security practices in design, development, testing, release, and operations. Organizations can proactively identify and mitigate vulnerabilities before they reach production. This approach not only enhances the security posture of applications, but also fosters a culture of shared responsibility among development, security, and operation teams. The TLDR version of this is security is a shared continuous responsibility. And the essence of the hour is to shift security left so that we build trust and resilience from ground up. Thank you all if you have made it thus far. I hope you learned a thing or two from this talk which you can employ in your day to day work. Enjoy the rest of the conference.