Upendra Mardikar is a prolific inventor and cybersecurity and digital identity executive with an “art of possible” mindset who led global teams to secure world-class organizations including American Express, Visa, and PayPal. He is credited with 95+ patents issued and pending. He is the Chief Information Security Officer at Snap Finance, a leading omnichannel digital-first fintech and POS lender, where he leads cybersecurity while building new platforms to enable growth opportunities. This includes securing innovative multi-cloud platforms and products, artificial Intelligence, client-facing technology, and customer and developer experiences.
SPONSORED CONTENT
He is a regular speaker at esteemed conferences for Stanford University, Global Big Data Conference, NFC forums, European Identity Conference, KNOW Identity Conference, Global Retail Conference in Canada, IOT conference, and others. Featured in Genius Journal, he helped pioneer blockchain in Amex and filed patents on blockchain and DLTs. He and his team worked on IoT security and payments and participated in several industry-standard bodies like EMV, Global Platform, PCI-DSS, FIDO, etc.
In this interview, we have John Jeremiah, Marketing Director, Traceable.ai, interviewing Upendra Mardikar on several cybersecurity threats and trends.
Edited excerpts of the interview follow:
John Jeremiah: At Snap Finance you are really on the cutting-edge of connecting consumers to merchants and streamlining financial processes. As a CISO, this has to be really challenging because there’s regulatory requirements, the sensitive nature of transactions and, you have to manage risk. How do you prioritize those risks? What are some of the biggest risks you’re facing in your role?
Upendra Mardikar: If you think about it, these are challenging times, especially with COVID-19, the things happening in the industry right now, and the U.S. government has just put sanctions on Russia. Typically, attackers go after the three most critical industries. The first is critical infrastructure that includes electricity, power plants, nuclear plants, water supplies, etc. The second is the healthcare industry. And then the third, and not necessarily in that order, the financial industry.
In general, financial institutions and financial services have been soft targets for attackers. In terms of prioritizing risks, as we transition our organization to API-first, cloud-first, mobile-first, and AI-first mentality across multiple services, these services using APIs are exposed and vulnerable. So that’s why having secure APIs is one of our highest priorities to make sure that we mitigate risks.
One of the top three biggest risks currently for the industry is ransomware and malware. The second risk is identity takeovers, which we are seeing in the industry, and the third risk is data loss or data leakage. I would have said DDoS if it were 2019 or the early part of 2020 but since late 2020, we are increasingly seeing data leakage as a big threat. Given these three risks, we prioritize our work based on how our services are exposed.
Jeremiah: Now that’s really fascinating how data leakage and the other threats have become bigger threats than DDoS. One of the things I noticed when I looked at your profile is that you’ve come from a strong background in security and incredibly large financial services institutions. So, in your experience at Snap Finance as a CISO, how is it different? How do you compare and contrast the difference from being in a large company to being in a much smaller organization?
Mardikar: Problems are generally amplified in bigger organizations as there are multiple attack surfaces and it’s a larger problem to protect them. Problems are also larger in scale and you have to move the organization at scale.
Smaller organizations have similar problems, except that the velocity of changes is very high. However, it’s potentially easier to get things done, though there are limited resources and three types of constraints in smaller organizations – region constraint, resource constraint, and skill constraint. So, you just have to manage these challenges differently.
In a bigger organization, it’s more about selling and getting collaboration across multiple business units and therefore, a different part of your brain is being activated versus smaller organizations where you still have to juggle with the resources and different constraints.
Jeremiah: You said you’re going to move towards mobile-first, API-first, and cloud-native – you’re really pivoting on how you develop applications. How do you see the next wave of security problems that are going to happen as you move towards these new technologies?
Mardikar: Historically, security has been addressed within closed walls. When you had just four walls of your organization, all you had to do to protect your perimeters was to lock your windows, lock your doors, put up some CCTV cameras, and those were enough to protect your four walls.
Nowadays, protecting within the organization is table stakes, and we have to go beyond the four walls, we have to go and make sure that not only do we protect our organization, we also have to consider the ecosystem of our partners, the supply chain consisting of other third parties. These third parties and multiple stakeholders are going to interact with our systems, and we are going to interact with their systems using APIs. So, when we start interacting with APIs, cloud and SaaS models, the overall system is no longer within four walls or defined boundaries.
Now, the security model needs to address not just North-South traffic, but we need to think beyond that and protect East-West traffic in addition to North-South traffic. And it’s really all in a spaghetti kind of architecture, so it’s not just the egress and ingress traffic we need to pay attention to.
When you’re talking to third parties, vendors, or partners providing value-added services to your organization, we need to secure those transactions as well. Some of them will be real-time, some of them will be batch mode, and some of them will be non-real-time. And so, how do you guarantee delivery with high potency, with high availability architecture, and how do you make sure that these spaghetti-like connections are secure?
Jeremiah: It’s an incredible challenge because the pace of change is so fast. The business expects that technology will iterate really fast, I mean it, not only is technology going fast, but one would argue that the attackers are moving faster too. Now, as a CISO, you have to lead your team and create a way to have your team keep up with all of this change, the pace. How do you lead your team to keep up with both the developers, who are going continuously fast and the attackers, who are equally fast?
Mardikar: There are two principles that we follow.
The first is a “saying yes” principle — we are here to support our business and we always want to say yes to the business. And there is the notion we call the “art of the possible,” and that we always try to support.
Secondly, to keep up with the velocity of changes, we have an automation first mentality – you have to strengthen your foundation by automating every workflow and technology that you are using.
Those are the two primary principles we follow.
We are trying to become a completely engineering-based organization and automate the metrics, the KPIs, and managing security risks.
Practicing “the art of possible,” “automation first,” and “security as an engineering discipline” are the three key factors we follow to keep up with velocity.
Jeremiah: Amazing. I think it really resonates, the idea that security, which has always been perceived in the past, as the “department of no – we can’t do this” moves to a model where you’re automating continuously and embracing the principles of engineering to move at the pace of business. This is really inspiring.
As you talked earlier about APIs and the API risks, how do you see these API risks evolving, and how do you see protecting APIs different from protecting other more traditional security threats?
Mardikar: If you squint a little bit, everything is an API or soon will be. It would be wrong to say that the traditional web 1.0 HTML pages were not APIs. In fact, those were also APIs. POST is an API, and then it evolved to REST, and other kinds of things. Everything is an API, whether you’re talking about native applications, mobile native applications, or whether it’s developer platforms. There are several developer platforms that we have been involved in developing and exposing it or developer first companies. To really think about it, even in the traditional sense, everything was an API.
What is happening now is that these APIs are going more and more towards devices. For example, when you consider SPAs (single page applications), and when you have the entire orchestration move out from your four walls boundary and into the application, that’s where the orchestration is happening.
Now suddenly APIs are becoming stateless and the orchestration is happening outside. With that kind of transition, it’s very difficult for you to know you have an attacker, because they don’t have to use API 1, API 2, API 3 in a very sequential way, now they can call API 3 directly and you cannot expect a sequence.
So, with your partners with ingress and egress traffic that entire thing you have to think beyond just North-South traffic- you have to think about East-West traffic and you have to think about all those tentacles that come out of that – so that is the new paradigm. When you are moving to single-page applications, when you have multiple partners and stakeholders, and when you are talking about ingress and egress APIs – that’s where the paradigm has completely shifted.
Jeremiah: If you think about the culprits that are the cause of some of the vulnerabilities we’re talking about, some of them might be attackers trying to penetrate the systems. But isn’t another reason for the vulnerabilities of some of the technology and processes we’ve adopted? We’ve evolved in such a way that we’re doing continuous development, we’re doing DevOps, and delivering fast.
What do you think we have to do differently, both in educating people and bringing people along? API security is a unique vector. How do you see this as a change and how do we have to change or educate our IT professionals?
Mardikar: Traditionally, auditors will ask – Do you have a good hardware asset inventory? Do you have a good software asset inventory? Are you doing continuous vulnerability assessments? Are your firewalls secure and are your ports closed? These are very typical audit activities that are fair and absolutely necessary. But today, these are necessary but insufficient.
So, the way to think about it is – vulnerabilities, as mentioned in CVEs are primarily directed in the technologies you are using. For example, let’s say you’re using JVMs, or jQuery, or a particular version of firewall, and it has the kind of vulnerabilities reported in CVE’s, you go ahead and patch it. That is one class of vulnerability for which it is extremely critical for us to protect.
But in addition, what is happening is that with API security, there exists some APIs that are not written to get published (Apple uses this distinction which I really like- “published APIs and non-published APIs”), but then other developers using the API in a different context might expose them without knowing they weren’t meant to be published. And when you think about the way we are exposing multiple APIs, intentionally or not, it causes the potential for vulnerability in the whole application.
Now we are suddenly talking about security at the application layer. And when we are doing threat modeling typically what happens is that, especially when you are in scrums and scaled agile type models, we are asking, “I am going to expose this particular API, Is it okay?” And then we do a security review. But the problem with this particular approach is that if you look at one API it might not be so risky, but if you are using and exposing that API in conjunction with another API, it suddenly increases the risk. So, the risk can grow exponentially.
To give you an analogy, if I just state a nine-digit number, it will be somebody’s social security number, but as soon as I say the first name and the last name, along with their social security number, the paradigm changes.
Jeremiah: Thank you. That’s fair. APIs aren’t going away. Developers are going to keep shifting left and we’re going to keep going faster. What do you have to change to keep up? Is there a technology that can help level the playing field to help security teams protect APIs and our applications? Do you see a solution to address this problem?
Mardikar: If you think about it, this problem has been created by technology. API is a technology and it’s created by technology. I don’t see the process as a solution for a technology problem. I see technology as a solution to a technology problem. And for that, when we talk about shift-left, we need to have a proper understanding of the requirements and then apply the threat modeling exercise.
When you expose a particular API to enable a particular product feature, what is the first thing you do? You do the threat modeling. So, it all starts with threat modeling in my mind and automation where technology like Traceable AI is certainly going to help as a next-generation security tool. That can be baked in right from shift left, then go in the middle, and then we go to the right as well, so that there is a closed loop for security.
Jeremiah: So, it’s about automation, understanding threats, detecting them early, and then being able to not only apply that to the developers in the early stages of development, to help them understand those risks but also, as you test and then eventually deploy those applications to understand what’s happening in reality.
Mardikar: Exactly, and then doing a closed loop back into the threat model.
Jeremiah: That’s right! That cycle has to start again because as we’ve talked about earlier, the attackers are only getting faster and more creative.
Mardikar: That’s right. This will be automated – again, going to the art of possible and automation-first mentality.
About the Interviewer
John Jeremiah is an enterprise DevOps evangelist and the Marketing Director at Traceable.ai. He is a multifaceted IT software leader from places such as GitLab, HP, and HPE with over 20 years of IT leadership and software experience including developing and shaping DevOps positioning and go-to-market strategy as well as an application developer, project/program manager, and IT Director. Jeremiah has led software delivery transformation, adopting an agile and mature process framework, and has held a variety of leadership roles with the U.S. Navy, IT consulting, and Fortune 500 IT organizations.
Disclaimer
CISO MAG does not endorse the views of the interviewer and interviewee. Facts, opinions, and language in the interview are personal and CISO MAG does not assume any responsibility or liability for the same.
