Monday, February 14, 2022

How low-code development has entered a maturity spurt thanks to new process-oriented capabilities

Closing the gap between the applications and services a company needs -- and the ones they can actually produce -- has long been a missing keystone for attaining digital transformation.

For increasingly software-driven organizations, the speed by which developers produce the needed processes, data flows, and business transactions has been much too slow for much too long. Fast-forward to the pressing new requirements of pervasively digital business in 2022, and it’s abundantly clear that something has to change.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.

Stay with us now as BriefingsDirect explores the latest capabilities and burgeoning strengths of Low-Code software development. To learn how the current maturity of Low-Code development will revolutionize the delivery of essential business applications, please join Matt Calkins, Founder and CEO of Appian in Reston, VA. The interview is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Gardner: Matt, in a nutshell, what is Low Code, and why is this a great time for it to revolutionize digital business?

Calkins: Low Code is a new way to build applications and processes. Instead of using code, drawing your code line by line, you make a picture. You draw a flowchart with lines, boxes, and arrows -- with a start node and an end node -- and that becomes your program.

Calkins

Instead of thinking of a program, it’s now like a series of characters and instructions. At its essence, it’s a drawing. That’s a very human way to program and to envision a process. It’s a very human way -- and it’s empowering to people because it’s intuitive to all of us. It’s also a lot faster. And this is the key advantage of low code. When you do less coding, you move faster.

Now a person can describe a new process by drawing a flowchart -- maybe 10 times as fast, even 20 times as fast, as they could have described the same process using lines of code. When you put that kind of power of speed in the hands of a person, they can develop a lot more software. They can not only develop it, but they can also go back and change it periodically to keep up with the times. It allows far greater flexibility in the way your organization behaves as expressed through software.

Gardner: What is it about the maturity of Low Code now that has more people excited about using it?

Speeding the inevitability of change

Calkins: Low Code is about speed, and speed is helpful because it helps you keep up with change. There’s never been a time that there’s been so much change to keep up with. In the last few years, change has gone from being a nice-to-have to being a must-have.

We've been talking about change and digital transformation for years, but it's never been so imperative as in the last few years. We've now reached a turning point where change is no longer an option.

In the pandemic, every organization had to change to survive, to keep up with the way their customers wanted to do business, the way their employees wanted to work, the locations from which they wanted to work, and to keep up with regulations.

We’ve been talking about change and digital transformation for years, but it’s never been so imperative as in the last few years. We’ve now reached a turning point where change is no longer an option. It’s a necessity. The speed of Low Code allows you to change -- and change is what we’re all about at Appian.

Gardner: So, what can make software development more of a wind in your sail rather than an obstacle to overcome?

Calkins: Software has been too difficult to create -- and to change. Someday we’re going to look back on this period of history and be amazed at how hard we made it on ourselves to program our machines. And how difficult it was to change the behavior of our organizations, because, of course, our behavior is written in software. We’re going to look back and think it’s astonishing that our software was the most immutable thing about our organizations. It’s harder to change than our building, our logo, or our management. Anything could be changed more easily than our software.

That makes no sense to me, because software is ideas, and it should be easy to change them. But the way we’ve created code is so difficult. This structured language with which we instruct machines, it is so complicated, it is so inscrutable. If you didn’t write it, it’s hard to know what the person who did write it was thinking.

It remains very difficult to create and to change our applications. This has got to change. We know we need more software -- and we’re not getting more developers. So, one way or another, we need a faster way to create and change our software.

Low Code is such a way because it makes it intuitive. You’re drawing, you’re dragging and dropping boxes and arrows; it’s very human-like in the way we’re communicating. It’s the last link in a long chain of advancements in the ease by which people instruct their machines. Starting with Ada Lovelace programming the Babbage machine, and all the way up to the present day, we have kept making it easier to program our computers.

Get the Full Guide 

Low Code is just one more step in that direction. It’s not a finished step, we keep trying to make Low Code more intuitive, using more wizards, more drag-and-drop, and minimizing the need for anything that looks like code. We keep working on that, and now we understand the urgency between the global demand for new processes or software and the urgency of change in the pandemic era. We have every reason to be as fast as possible in the way we provide change to our customers.

Gardner: I suppose another difficulty has been the communication of requirements from those who are in the trenches, so to speak, to those who are doing the software development. Is there something about Low Code too that helps understand what the business is doing? Is there a benefit not only in the coding, but also in the communication?

Calkins: Yes, absolutely, there is. If you or I were to look at a Low-Code application, we would understand the main structure of how it works. We would understand the flow because it is a flowchart.

By making it understandable to everybody, even the ones who didn't program it, we've democratized the meaning of a program. We're made it easier to create that program.

By making it understandable to everybody, even the ones who didn’t program it, we’ve democratized the meaning of a program. We’ve made it easier to create that program, but also easier to understand it and therefore, to validate it, to look at it and think that’s not exactly the way I believe it should work. If I’m in the trenches, you may have written it, but I’m looking at it and I know that it’s not right.

That’s a higher degree of common knowledge that will help us be on the same page, write better software, and pivot our organizations more quickly to match the needs that only our people in the trenches, as you say, know that we have.

Gardner: You mentioned earlier, Matt, that we’re having a hard time finding developers. Seems like we’re having a hard time finding all sorts of skills and labor, but development seems near the top. If we have a finite set of resources, but we have growing demand for software, how do we reconcile these two realities? 

Calkins: We’re just going to have to get better at creating applications more cheaply and with less time. Because we can’t continue these two curves; they’re diverging, and we need way more software and we’re not getting way more developers.

And for that matter, the cost of a developer we can get is very expensive. So, we need to be more efficient and get more applications per developer, per year. So, if it’s not Low Code, it’s going to have to be something very much like Low Code, a more human, intuitive, and faster way to express our instructions to a machine.

Another way you do this, of course, is to democratize programming to the point where not everybody who does it has to be a “developer,” maybe we could take somebody who’s a power user and bring them in and make them a programmer.

Maybe we could create a programming language, a Low-Code programming language, that is easy enough so a fairly technical person could spend a month and become a productive professional developer in this medium. That’s what we’re going for. We want to democratize access to programming so that more people become developers -- and developers become far more efficient.

Pioneers in democratizing programming

Gardner: What is it about Appian’s legacy that puts you in a position to be helpful in all of this? What is it about what Appian brings to the table that helps make this transformation?

Calkins: We’ve been focused on this for a long time. For about 15 years, we’ve been on this exact issue. How do you create a program by drawing a picture? I encountered that idea nearly 20 years ago, loved the concept, felt it was necessary.

The way the world was going -- more software, not more programmers -- I realized we’re going to need something like that. So, we have been working on it for more than a decade and a half. We were the first Low-Code company to go public in 2017. We’ve been pioneering this space; we’re not the only pioneer, but we’re definitely one of them. 

We’ve put a lot of thought into this, and our entire business is focused on just this: Empowering people to create their processes. And so, we’ve a lot to add. We’re setting the standards. We’re creating the new shape of the market. We’re introducing the new nomenclature.

Low Code wasn’t a big thing when we decided that that was the right term. We went public with “Low Code” as our headline, and a lot of people thought, “Oh, you shouldn’t do that. You should always go public with a very famous well-known market.” But we were first. And now, it’s a much bigger deal.

Gardner: I’ve been curious over the years as to why, as software become more sophisticated – with computer aided design (CAD), engineering, and media and video production, and the design of homes and buildings – that it seems like developers put all their emphasis into automating the business tasks of others. Have they been too busy to automate what they were doing? Do the cobblers’ children have no shoes? Why has the development of software for the development of software lagged?

Calkins: You know, it’s funny. You’re right on this dichotomy. You could think of the advances in software as being of two types. There’s the sheer power inside the software application. And then there’s the connection from the user to the application. And, of course, according to Moore’s Law, the processing power is increasing all the time.

We have so much more power to work with. It’s incredible what these programs can do. But the interface hasn’t advanced as much, has it? The connection between a human and the machine is not advancing, not according to the pace of Moore’s Law.

Sometimes it seems pretty backward. It seems like we ought to be able to do better in facilitating human-to-machine collaboration and instruction. And at Appian, that’s what we’re all about. You can’t just surf the advances in the latest chip technology. You have got to think about what would be more human and what would be more intuitive and empowering. That has to be a critical area of advancement as well. 

Gardner: Well, the need for improvement is very clear. So, Matt, as an industry, where is Low Code going?

Low Code with a purpose

Calkins: Low Code is in the midst of a dramatic change. Like all industries that reach maturity, it has to change at some point from focusing on what it does to focusing on what it’s for. So far, the Low-Code industry is focused on what it does, and you can see that in the name Low Code even. That’s what it does. It gives you an interface to create a program with less code, that’s Low Code.

We need to make it easier to conceive of a new process, design it, deploy it, run it, and change it -- end to end.

What it doesn’t address is what it’s for, and what it’s for has changed. This industry is now about providing the ability to bring change to our customers. Our customers want to create a new behavior, and these days behavior is done in software. You’re going to create a new process.

We therefore need to make it easy for a customer to conceive of that new process, design it, deploy it, run it, and change it -- everything about it, end-to-end. We are going to be a change engine that allows them to create -- and do everything -- with a new process.

That’s the emerging mission for our industry. We can’t afford any longer to be about the technology. We must be about the effect of the technology.

Gardner: Matt, can we unpack this for two different constituencies? One would be the business leader, so they understand what you’re getting at. But also the technologists, the IT people and developers. What does this mean for businesses, and what does this mean for technologists?

Calkins: First, it means that business and technology are going to be using the same product. Instead of having a product for business, a product for technology, and yet another product later on -- we need a unified suite. We need a change engine that gets you from discovering your new process to designing your new process to automating and deploying your new process. The business will be involved in this largely in the discovery phase and the return on investment (ROI) phase.

Get the Full Guide 

And then, the technologists and the developers are involved in the design, deployment, and automation. It’s going to be one platform, a single product with a single stock keeping unit (SKU) getting you from the beginning to the end on a new process as fast as possible. By bringing all these people together via a common language and common interface, we make it so much easier for businesses to change. And if you don’t think this is necessary, just consider how much difficulty businesses have today with changing fast enough.

They’re always behind the times, always behaving a little too slowly, always reacting to new ideas slower than they should; always, like you said, having their aspirations unmet and their backlog too big. Businesses need to move faster. They need change. And so, we’re providing a change engine to facilitate that most fundamental want in every business I’ve seen.

Gardner: Another trend I’ve noticed over the years, Matt, is that in development, we go through a pendulum swing between centralization and decentralization. On one end there are a lot of different new tools, better testing environments, and yet a lack of integration between them all. That gets too unwieldy, and we swing back to more centralized and integrated platforms.

Is that what’s happening with Low Code as well? Are we swinging in one direction or the other?

Calkins: You’re completely right about that pendulum. I’ve seen the same thing over the last few decades. And lately, the pendulum has swung pretty far toward the power of the largest stack vendors and the big technology vendors. They’ve become exceptionally powerful, pervasive, and irreplaceable in many organizations. 

I believe that the pendulum, when it swings, is going to swing back in the other direction. It’s going back to best-of-breed because best-of-breed tends to have better products. It’s going to be very important for customers to get the speed of change that they want and the agility in the way they execute their plans.

Big tech is going to be a straitjacket to achieving that. So, they’re going to want freedom of choice. They’re going to want to be able to plug into whatever data sources they may have around the enterprise instead of having to move all the data to one location. 

There’s going to be a swing back in that pendulum toward best-of-breed and freedom, and the natural idiosyncrasy that emerges in any large organization. You can’t put that in a straitjacket or a cookie cutter. They’re going to want to express their unique plans and their unique backgrounds.

Low Code is empowering because you can program quickly -- and so you can change quickly. You can adapt to your unique organization and your own data from many different places.

Low Code is an empowerment tool in this way. It’s empowering because you can program quickly -- and so you can change quickly. But it’s also empowering in that you can adapt to the unique organization that you already are. You can adapt to the fact that you have your data in 27 different places. Some of them are in the cloud, and some of them are on-premises. They’re in different formats. Some of them are databases that you haven’t touched in 20 years. 

Your data is scattered, right? That’s a situation that demands freedom, and Low Code is very good at adapting to unique situations like that. So, Low Code is empowering in that it facilitates idiosyncrasy and it also is going to benefit from that swing away from centralization and toward best-of-breed and individual empowerment.

Gardner: When we look for the best-of-breed approach to things like process mining, Low Code, and democratization of skills, are there specific use cases that come to mind where this will be the most valuable the soonest? Is there a low-lying fruit, if you will, to where Low Code platforms will emerge so that the early adopters get the best, empowering results?

Behavioral change in software

Calkins: Every organization of scale needs change, especially in the last few years, because change has become such a norm. Every organization is going to need to make changes.

Imagine a new regulation. Imagine entering a new business. Imagine launching a new product. Imagine having your customers expect something different from you and needing to change your behavior to adapt to that. Imagine your employees saying that they want to work in a new way from a new location, in a new pattern, and on different hours. All of these things require new behaviors. And when you adopt a behavior at scale in an organization, you are always facilitating it with software. So, every change an organization needs to make now is a change that is written or drawn in software.

For example, we recently helped a large financial institution, maybe the most famous financial institution in the world. They were launching a new product, entering a new market. They needed new behaviors and they realized they couldn’t code it fast enough, so they turned to us.

They used our Low-Code platform to program the new behaviors, the new case management that they required to launch this product, and then they were able to launch on time. It was successful. Every time they have to make a new launch or adjustment or behavior around this product, they can come right back to this platform and write some new processes and it’s as easy as drawing.

It’s Low Code, very simple. It’s become a major part of the way they do business. They’ve relied on Low Code to enable their agility -- and every large organization is facing the same situation. They need to be agile. They’re looking for a means to change quickly and Low Code can be that.

Gardner: Matt, are there any misconceptions that you find in the field about Low Code? Perhaps it’s time to better understand the reality. It sounds like from that last example that there are some people who might not be understanding the benefits.

Calkins: The biggest misconception about Low Code is that it isn’t powerful. It’s simple and so, people assume that it’s a toy. But it’s anything but. In fact, it is as powerful as a development language. It’s in use today by the largest organizations in the world to create some of the most important processes that they run, processes that are a matter of law or a matter of satisfying the customer that addresses the core workflows in an organization. Low Code is used for some of the world’s most important processes today, and so, that’s the number one misconception.

The next misconception is that it’s hard to get into. Low Code in fact is exceptionally simple to get into. In fact, you could log on to Appian’s website and learn right there. We have videos, there’s a training course, there’s a free environment that you can use. We’re making it as easy as possible to learn Low Code, make that part of your skill set and make use of it. So, Low Code is actually easy to get into and very powerful, but not everyone realizes it.

Gardner: How do traditional software developers feel about Low Code? How do they react to it?

Calkins: Well, some of them dive right in and realize that it’s very empowering. Others are very attached to a programming language that they’ve used in the past and preferred to stick with it. I see all kinds of reactions.

Low Code is simple so people assume it's a toy. But it's anything but, it's as powerful as a development language. And it's used for some of the most important processes today.

But to those on the edge of programming, let’s say they’re starting a career. They’re in their 20s, they’re learning their place in the world of development and this Low Code tool comes along. Well, they love it, they love it. Those who are getting going with their careers see this as an unqualified positive -- and they enthusiastically get involved.

It’s true, the wages are very high right now, salaries are high for people who know how to do this. There’s a shortage of Low-Code developers. The people who know how to do this are commanding a lot of money and influence in the market. So, I see Low Code as a great tool for those who are finding their way into the development field.

Gardner: If you’re a chief technology officer (CTO), a chief executive officer (CEO), or on the board, if you’re a chief information officer (CIO), how does Appian help you in your role and your company?

Empowered processes and partners

Calkins: If you’re an executive at a big organization, you have to ask yourself, “Are we changing fast enough?” Almost certainly, the answer is going to be, “No.” Seriously think about that. Don’t measure yourself against what you thought was possible. Measure yourself against what your customers would like.

Are we moving as fast as our customers wish we were moving? Are we introducing new products? Are we changing our behavior? Are we as responsive as, ideally, we could be? There’s almost no business I know of that could say yes to that question.

Get the Full Guide 

If it’s true that you would like to move faster, now is your chance. There’s now such a thing as a Low-Code suite that can take you from discovering a new process, to designing it, and automating it in the same product. You can increase the rate at which you launch a new process by 10x or 20x.

So, an executive can ask these questions and then direct the organization to look into Low Code. Whether you’re on the board, the CEO, the CTO, or the CIO, the direction would be the same. Ask that question and then talk to some Low-Code vendors.

Gardner: How about the ecosystem that’s around you? It seems like over the years, there have been consultancies that have developed within vertical industries and focus on solutions. It seems to me that Low Code would be very important and of interest to them. They’re not interested in selling software; they’re interested in creating solutions in vertical industries. What is your partner ecosystem like?

Calkins: There’s been a lot of enthusiasm. If you have expertise in one vertical industry and you want to bring that expertise to value by instantiating it. Well, there’s no better way to instantiate it than in a Low-Code framework. It’s so easy to deploy and adjust. Every client you have is going to want a variation on your expertise, but the core expertise can be expressed and then modified to fit each circumstance so quickly in Low Code.

Instead of selling your time on an hourly basis, you’re selling your ideas and they’re reproducible. This is a critical pivot where you go from selling the minutes to selling the ideas. This has been very enthusiastically adopted by people who are consultants and who have expertise in one industry or another.

Gardner: Matt, where should we expect the direction of Low Code productivity to go next?

See the process mining big picture

Calkins: Appian recently announced a major new product. We announced our process mining module, which we’ve been working on for a long time. We bought a company, and we’ve been developing it. We finally merged it all into our platform and Low-Code suite.

Process mining is like an x-ray giving you a view into what behaviors happen inside your enterprise. It looks at the usage logs of your applications, weaves them together to create a unified understanding of the sequences and the patterns of behaviors that happen whenever you launch a new use case of any kind.

Process mining is like an x-ray giving you a view into what behaviors happen inside your enterprise. It creates a unified understanding of behaviors.

So, after a customer calls, as an example of a use case, what do you do? If a problem happens in such a process, what sequence of actions do you then best pursue? Based on that process mining look -- that x-ray into your actions -- you can tell whether it’s too slow, you’re being inefficient, you’re spending too much money routing work to the wrong resource or keeping your customers waiting too long. This x-ray can tell you a lot about where you need to build a new process or improve your existing processes.

When you get that diagnostic, you can convert it. You can make a workflow based on what you learned. So, this is the natural starting point for the journey of process optimization. First, we take the x-ray, and we understand what’s inefficient and where we need to make an improvement. Then, we develop the new process. We use a Low-Code workflow interface to drag and drop the right process -- and then we automate it.

You start with discovery, go to design, and then you go to automation -- and it’s on the same product. I think it’s a big step. It’s going to be a great way to measure ROI. It’s going to be a great way to find new places to use Low Code. And it will be well in demand by our partners because they’re going to enjoy deploying their expertise to discover new places where they could be of use.

Gardner: The timing is very auspicious in that processes are now distributed across multiple organizations. As we’ve gone to cloud-native services and using third parties as software as a service (SaaS) services for so much, it’s hard to grasp the whole process. They are not necessarily inside your four walls, and probably never will be again. Is there something about process mining that helps ameliorate this complexity of a distributed business?

Calkins: Yes. Process mining looks at all the usage logs and brings them together. That’s the magic of the technology. So, whereas we used to see only an aspect of the business and one dimension of our behavior at a time, now we see all of it. Just like if you’re going from a 2D view to a 3D view, things start popping out at you. It becomes much clearer about what could be improved and where the inefficiencies lie. It’s a great clarification tool.

Gardner: It sounds like that’s something we could dive deeper into at some point and it’s very interesting. Any other ways that people can learn more if they’re intrigued about Low Code? What do you advise them in terms of making this move from a lesson into an engagement? 

Calkins: We’re so eager to make it easy to learn Low Code. We’re building our community as fast as we can. We have free resources, free environments to use, a great program to get you involved, a forum where you can post your work and learn from other people’s work. Just go to Appian.com or lowcode.com and avail yourself of all these resources. It’s a booming industry.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Appian.

Wednesday, January 12, 2022

When it comes to API security, expect the whole world to be testing your mettle, says Twitter CISO

Just as cloud computing initially seeped into organizations under the cloak of shadow IT, application programming interface (API) adoption has often followed an organic, inexact, and unaudited path. 

IT leaders know they’re benefiting from APIs -- internal, via third parties, and often outwardly exposed -- they just don’t know where they are, how much they support key services, and how they’re being used … or abused.

As a result, developers and business architects alike don’t know how organically adopted technologies like APIs are adversely impacting their businesses -- until something like the Log4j and Log4shell vulnerabilities have run amok.

Stay with us now as we explore how API-intensive and API-experienced businesses are bringing maturity to their APIs’ protections through greater observability, tracing, and usage analysis.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.

To learn how Twitter, a poster child for business-critical API use, makes the most of APIs by better knowing and managing them across their full lifecycles, we’re joined by several guests to discuss the latest in API maturity: Please welcome Rinki Sethi, Vice President and Chief Information Security Officer (CISO) at Twitter, and  Alissa Knight, recovering hacker and partner at Knight Ink. The discussion is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Gardner: Security researchers at Akamai in their latest state of the internet report detail how cyber criminals have noticed APIs and are turning them into an attack vector. This in itself isn’t a surprise, but the degree to which people are not prepared for such vulnerabilities as the Log4j issue is.

Rinki, how do CISOs such as you at Twitter get the most out of APIs while limiting the risk?

Sethi
Sethi: Securing APIs is a multi-layered approach. My philosophy is that APIs are meant to be exposed. We expose APIs to enable developers to do amazing things on our platform.

So, you need a multi-pronged approach to security. There are basic tools that help you prevent risk around APIs, whether it’s volumetric attacks or the basic vulnerabilities and supporting the infrastructure. But really, each API introduces its own risk, and there is a multi-layered approach in how you go and secure that.

Gardner: Rinki, what’s your history as a CISO? And please tell us about your tenure at Twitter.

Sethi: I’ve been in the cybersecurity industry for almost two decades now. I’ve been around the block at some really great brands in the Bay Area, from working at eBay to Palo Alto Networks to IBM.

I took my first CISO role almost three years ago at a start-up company called Rubrik, a unicorn, and helped them after a security breach and to scale up their security program. That was my first role as CISO. Before that, I held various roles leading product security, security operations, and governance, risk, and compliance (GRC).

While at Rubrik, during early COVID, we had to scale back and focus on how to thrive as a business. At that time, Twitter reached out. I joined Twitter after the security breach and before the U.S. election to help build out a scalable security program. And so, here we are. I’m a little over a year into this role.

Gardner: The good news about APIs is they’re widely exposed and can be used productively. The bad news is they’re greatly exposed. Knowing that and living with that, what keeps you up at night? What’s a lingering concern when it comes to the use of APIs?

Decrease API vulnerability ASAP 

Sethi: The explosion of APIs in use in just the last few years has been at an exponential rate. Our traditional security products don’t protect us against business logic flaws -- and that’s what keeps me up at night.

How to Protect Against 

Business logic flaws can result in security or privacy violations for the consumer. And other than unit testing -- and really looking at your APIs and testing them out for those business logic flaws -- there’s not great innovation yet. There are [API security] companies starting up, and there are going to be a lot of good things that come out, but we’re still early. That’s what keeps me up at night. You still have to go back to the manual way of looking at APIs.

Those kinds of vulnerabilities are the biggest challenge we have in front of us. And thankfully we have people like Alissa who come after us and find those issues.

Gardner: Alissa, you wrote an e-book recently, The Price of Hubris: The Perils of Overestimating the Security of Your APIs. Other than the business logic flaws that Rinki described, what are the biggest risks in the nearly unmitigated use of APIs these days?

Knight: There’s a library of papers I’ve done on these issues. I feel like every morning, Rinki wakes up and lies in her room and says, “Oh, my God, another paper from Alissa!” So, yes, there’s a real struggle around API security.

Knight
What was interesting and what I loved about the Hubris paper was it allowed me for the first time to take all my vulnerability research across industries -- automotive, healthcare, financial services, fintech, and crypto currency exchanges – and put them into a single paper. It’s a compendium of all my API exploits that shows this is a ubiquitous problem across many industries.

It’s not just a Twitter problem or a whatever-bank problem. It’s an everyone problem. Much to Rinki’s point, APIs have pretty much become the plumbing system for everything in our world today. They affect life and safety. That’s what attracts me as a vulnerability researcher. It’s like George Clooney’s movie, The Peacemaker, where the lead character didn’t care about the terrorist who wants 1,000 nuclear weapons. He cared about the terrorist who just wants one.

For me, I don’t care about the hacker who wants to deface websites or steal my data. I care about the hacker who wants to go after my APIs -- because that could mean taking remote control of the car that my family is in or hacking healthcare APIs and stealing my patient records. If your debit card was compromised, Wells Fargo can send you a new one. They can’t send you a new patient history.

APIs are the foundational plumbing for everything in our lives today. So, rightfully so, they are attracting a lot of attention -- by both black hats and white hats.

Gardner: Why are APIs such a different beast when it comes to these damaging security risks?

Knight: Humans tend to gravitate toward what we know. With APIs, they speak HTTP. So, the security engineers immediately say, “Oh, well, it speaks the HTTP protocol so let’s secure it like a web server.”

APIs are the foundational plumbing for everything in our lives today. So, rightfully so, they are attracting a lot of attention -- by both black hats and white hats.

And you can’t do that because when you do that, and Rinki addressed this, you’re securing it with legacy security, with web application firewalls (WAFs). These use rules-based languages, which is why we have gotten rid of the old Snort signature base, if you remember that, if you’re old enough to remember Snort.

Those days of intrusion detection system signatures, and updating for antivirus and every new variant of the Code Red worm that came out, is why we’ve moved on to using machine learning (ML). We’ve evolved in these other security areas, and we need to evolve in API security, too.

As I said, we tend to gravitate toward the things we know and secure APIs like a web server because, we think, it’s using the same protocol as a web server. But it’s so much more. The types of attacks that hackers are using -- that I use -- are the most prevalent, as Rinki said, logic-based attacks.

I’m logged in as Alissa, but I’m requesting Rinki’s patient records. A WAF isn’t going to understand that. A WAF is going to look for things like SQL injection or cross-site scripting, for patterns in the payloads. It’s not going to know the difference between who Rinki is and who I am. There’s no context in WAF security -- and that’s what we need. We need to focus more on context in security.

Gardner: Rinki, looking for just patterns, using older generations of tools, doesn’t cut it. Is there something intrinsic about APIs whereby we need to deploy more than brute labor and manual interceding into what’s going on?

Humans need to evolve API culture

Sethi: Yes, there are a lot of things to do from an automation perspective. Things like input/output content validation, looking at patterns and schema, and developing rules around that, as well as making sure you have threat detection tooling. There’s a lot you can do, but a lot of times you’re also dealing with partner APIs and how your APIs interface with them. A good human check still needs to happen.

Now, there are new products coming out to help with these scenarios. But, again, it’s very early. There are a lot of false positives with them. There’s a lot of tooling that will help you capture some 80 percent, but you still need a human take a look and see if things are working.

What’s more, you have the issue of shadow APIs, or APIs that are old and that you forgot about because you no longer use them. Those can create security risks as well. So, it goes beyond just the tooling. There are other components needed for a full-blown API security program.

Gardner: It seems to me there needs to be a cultural adaptation to understand the API threat. Do organizations need to think or behave differently when it comes to the lifecycle of APIs?

Knight: Yes. The interesting thing -- because I’m so bored and I’m always trying to find something to do -- I’m also the CISO for a bank. And one of the things I ran into was what you mentioned with culture, and a culture shift needed within DevOps.

Get the Free Tool to 

I ran into developers spawning, developing, and deploying new APIs -- and then determining the cloud environment they should use to secure that. That’s a DevOps concern and an IT concern. And because they’re looking at it through a DevOps lens, I needed to educate them from a culture perspective. “Yes, you have the capability with your administrative access to deploy new APIs, but it is not your decision on how to secure them.”

Instead, we need to move toward a mindset of a DevSecOps culture where, yes, you want to get the APIs up and running quickly, but security needs to be a part of that once it’s deployed into development -- not production -- but development. Then my team can go in there and hack it, penetration test it, and secure it properly -- before it’s deployed into production. 

What’s still happening is these DevOps teams are saying, “Look, look, we need to go, we need to rush, we need to deploy.” And they’re in there with administrative access to the cloud services provider. They have privileges to pick Microsoft Azure or Amazon clouds and just launch an API gateway with security features, and yet not understand that it’s the wrong tool for the job.

If all you have is a hammer, everything looks like a nail. So, it requires a culture change. It is certainly that. Historically, there’s always been an adversarial relationship between security and developers. And it’s part of my job -- taking off my hacker hat and putting on my executive hat as the CISO – to change that mindset. It’s not an us versus them equation. We’re all on the same team. It’s just that security needs to be woven into the software development lifecycle. It needs to shift left and shield right.

Gardner: Rinki, any thoughts about making the culture of security more amenable to developers?

Sethi: I couldn’t agree more with what Alissa said. It’s where I found my passion early in my security journey. I’m a developer by trade, and I’m able to relate to developers. You can’t just sit there and train them on security, do one-day training, and expect things to change.

I'm a developer by trade, and I'm able to relate to developers. You have to make their lives easier to some degree, so they don't worry and the tooling is training them in the process. You have to show them the impact of a security breach or bugs.

It has to be about making their lives easier to some degree, so they don’t need to worry about things, and the tooling is training them in the process. And then a shared sense of responsibility has to be there. And that's not going to come because security just says it’s important. You have got to show them the impact of a security breach or of bugs being written in their code -- and what that can then end with. 

And that happens by showing them how you hack an application or hack an API and what happens when you’re not developing these things in a secure manner. And so, bringing that kind of data when it’s relevant to them, those are some bits you can use to change the culture and drive a cohesive culture with security in the development team. They can start to become champions of security as well.

Knight: I agree, and I’ll add one more thought to that. I don’t think developers want to write insecure code. And I’m not a developer, so I couldn’t speak directly to that. But I’m sure nobody wants to do a bad job or wants to be the reason you end up on the nightly news for a security breach.

I think developers generally want to be better and do better, and not do things like hard-code usernames and passwords in a mobile app. But at the end of the day, the onus is on the organization to speak to developers, and said, “Hey, look. We have the annual security awareness training that all companies need to take about phishing and stuff like that,” but then no one sends them to secure code training.

How is that not happening? If an organization is writing code, the organization should be sending its developers to a separate secure code training. And that needs to happen in addition to the annual security awareness training.

Gardner: And Rinki, do you feel that the risk and the compliance folks should be more concerned about APIs or is this going to fall on the shoulders of the CISO?

Banking on secure APIs

Sethi: A lot of times, risk and compliance falls under the CISO and I think Alissa said they don’t get into it. The regulators are not necessarily going to get into the minutia and the details of each and every API, but they may mandate that you need some kind of security program around that.

As we all know, that’s only one aspect of security. But I think it’s starting to come up in discussions -- especially in the banking world. They’re leading the way as to what others should expect around this. What I’m hearing from vendors that are supporting API security is that it’s easier to go to a bank and drive these programs because they already have a culture of security. With other companies, it’s starting to come now. It’s a little bit more chaotic around how to bring these teams involved with APIs together so that they can build good security.

Knight: If you think about it, 20 years ago, back when both Rinki and I got into security, it was a different story. The motives for hackers were website defacement and getting your name on all those defacements. That was the point of hacking.

Now, it’s all about monetizing the data you can steal. You don’t go digging for gold in just any random hole. You try and find a gold mine, right? Data is the same. Data is worth more than … Bitcoin. Maybe more than oil. You go to a gold mine to find gold, right? That means you go to APIs to find data. Hackers know that if they are going to steal and ransom a company, and double dip, and then lock and leak -- so leak the data and encrypt it -- you go where the gold is, and that’s the APIs.

I think there’s going to be an exodus where hackers start shifting their focus to APIs. Knowing that more hackers are moving in this direction, I need to learn JSON, I need to know what the hell that is and not be scared off by it anymore, because that’s where the data is. I need to understand how to hack APIs. 

Just because someone’s a hacker doesn’t mean they know how to hack APIs. I know a lot of hackers that freak out when they see JSON. So, it’s a certain type of hacker. Hackers need to take their craft -- either a white hat or black hat -- and develop that craft to focus on how to hack APIs.

The winds are changing and it’s going toward APIs because Twitter isn’t a monolithic application just like Amazon.com isn’t. It’s not one big app running on one big web server. It’s a bunch of distributed containers, microservices, and APIs. And hackers are going to learn how to hack those APIs because that’s where the data is.

Gardner: What do organizations then need to do to find out whether they’re behind that 8-ball? Is this still a case where people don’t know how vulnerable they are?

Identification, please

Sethi: Yes, I think identification is essential. If you’re kicking this off, at least make the case for a top priority to identify what your API environment looks like. What do you have that’s currently being used? What older versions that are not used but are still around and may be creating risks? Are there shadow APIs?

Finding out what the environment looks like is the first step. Then go through those APIs to see how they work. What do they do for you? What are the high-risk ones that you want to take a look at and say, “We need a program around this.” Identification is the first step, and then building a program around that.

Learn More 

You may also want to identify what teams you need on board because as you’re identifying what’s already existing, if there’s things you need to do to change around to how developers are working with APIs, that’s another step you want to look at. So, it’s about building a cohesive program around building a culture. How do you identify what’s out there? How do you change how work is being done so that it’s more secure?

Knight: As a CISO, I’m quick to buy the coolest new things, the shiny new toys. My recommendation is that we as security leaders and decision-makers need to take a step back and go back to the old, fine art of defining our requirements first. 

Creating a functional requirements document on what it is we need from that API threat management solution before we go out there shopping, right? Know what we need versus buying something and looking at a vendor and saying, “Oh you’ve got that. Yeah, that could be good. I could use that. Oh, you’ve got that feature? Oh, I could use that.”

You can't protect what you don't know you have. Do your tools have the capability to catalog APIs and find out what the attack surface really is? What kind of data are those APIs serving? I sure as hell want to know which APIs are serving PII or PCI data.

Understand what your requirements are. Then, most importantly, you can’t protect what you don’t know you have. So, does your tool have the capability to catalog APIs and find out what your attack surface really is versus what you think it is? What kind of data are those APIs serving? Maybe we don’t need to start by focusing on protecting every single API, but I sure as hell want to know which APIs use or serve personally identifiable information (PII), or payment card industry (PCI) data, and all of those that are serving regulated data.

So where do I need to focus my attention out of the 6,000 APIs I may have? What are the ones I need to care about the most because I know I can’t protect my entire operating area -- but maybe I can focus on the ones I need to care about the most. And then the other stuff will come in there.

The number one vulnerability, if you look at the Hubris whitepaper, that’s systemic across all APIs is authorization vulnerabilities. Developers are authenticating a request but not authorizing them. Yes, the API threat management solution should be able to detect that and prevent it, but what about going back to the developers and saying, “Fix this.”

Let’s not just put all the onus and responsibility on the security control. Let’s go to the developers and say, “Here, our API threat management solution is blocking this stuff because it’s exploitable. You need to write better code, and this is how.” And so, yeah, I think it’s an all-hands-on-deck, it’s an-everyone issue.

Gardner: Because the use of APIs has exploded, because we have the API economy, it seems to me that this ability to know your API posture is the gift that keeps giving. Not only can you start to mitigate your security and risk, but you’re going to get a better sense of how you’re operating digitally and how your digital services can improve.

Rinki, even though better security is the low-lying fruit from gaining a better understanding of your APIs, can you also then do many other very important and beneficial things?

CISOs need strong relationships

Sethi: Absolutely. If you think about security upfront in any aspect, not just APIs, but any aspect of a product, you’re going to think about innovative ways to solve for the consumer around security and privacy features. That gives you a competitive advantage.

You see this time and time again when products are released. If they have issues from security or privacy, they may have been able to threat model that in advance and say, “Hey, you might want to think about these things as an outcome of the consumer experience. They may feel like this is violating their security or privacy. These are things that they may have in mind and expect from the product.”

And, so, the earlier you have security and privacy involved, the better you’re going to deliver the best outcomes for the consumer.

Knight: Yes, and Dana, I consider it fundamental to our role as a CISO to be a human LinkedIn. You should form a partnership and relationship with your chief technology officer (CTO), and have that partnership with infrastructure and operations, too.

APIs are like this weird middle ground between the CISO’s office and the CTO’s office because it’s infrastructure, operations, and security. And that’s probably not too different from other assets in the environment. APIs need a shared responsibility model. One of the first things I learned from being a CISO was, “Wow, I’m in the business of relationships. I’m in the business of forming a relationship with my chief fraud officer, my CTO, and the human resources officer.

All of these things are relationship-building in order to weave security into the culture of the enterprise, and, I think, in 2021 we all know that by now.

Gardner: APIs have become the glue, the currency, and a common thread across digital services. What I just heard was that the CISO is the common denominator and thread among the different silos and cultures that will ultimately be able to impact how well you do and how well you protect your APIs. Are CISOs ready, Rinki?

Sethi: I wouldn’t say that they aren’t. Any CISO today is exposed to this. The proof is around, look at how many vendors are out there solving for API security now, right? There’s hundreds and they’re all doing well.

There's so much innovation happening. All CISOs are talking about this, thinking abut this, and it's a challenge. CISOs are the common denominator in how we bring these different teams together to prioritize these weaknesses.

It’s because CISOs have defined that there’s a problem that we need to go and solve it. It’s a multilayered issue, and that’s why there’s so much innovation happening right now. And we’re not just solving for typical issues in your infrastructure, but also how you look at content validation? How are you looking at those business logic flaws? How are you looking at monitoring? Even how are you looking at identifying APIs?

You don’t know what you don’t know, but how do you start finding out what’s in your environment? There’s so much innovation happening. All CISOs are talking about this, thinking about this, and it’s a challenge. I do think CISOs are the common denominator in how we bring these different teams together to prioritize this.

Knight: I think you hit the nail on the head, Dana. CISOs are the connective tissue in an organization. We even have a seat on the boards of directors. We have a seat at the big kids’ table now, along with the CEO, and the heads of the different departments in the company.

And I don’t think the API security solutions were all created equal. I just recently had the pleasure of being invited by Gartner to present to all their analysts on the state of the API security market. And all these API security vendors have a different approach to API security, and none of them are wrong. They’re all great approaches. Some are passive, some are in-line, some import the swagger file and compare the back-end API to your Open API specification. Some are proxies.

How to Protect Against 

There are all these different approaches because the attack surface for APIs is so big and there are so many things you need to think about. So, there are many ways to do it. But I don’t think they are created equal. There’s a lot of vendors out there. There’s lot of options, which is why you need to first figure out what you require.

What is the back-end language? What are you programming in? Does your solution shim into the application? If so, you need to make sure the API security solution supports that language, that sort of thing. All these things you need to think about as a security decision-maker. We as CISOs sometimes go out there and look at product options and take the features of the product as our requirements. We need to first look at our requirements -- and then go shopping.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Traceable AI.

You may also be interested in: