The Hitchhiker's Guide to the Software Security Galaxy

The Hitchhiker's Guide to the Software Security Galaxy

Show Video

(upbeat music) - Hi everyone. As Diana mentioned, my name is Jake Marcinko. I'm a senior manager of solution standards at the council, and I'm also the chair of the PCI Software Security Working Group, which is responsible for the PCI software security standards and programs. And today, what I wanna talk about is three specific technologies that are disrupting software development and software security. Now, we'll talk a little bit about some of the benefits of these technologies, as well as the security concerns.

But before we get into that, I wanna talk about video games. So how many folks here, and this is an interactive question. Raise your hand. How many folks here would consider themselves gamers, or like to play video games? A few people. Good.

Let's say 2% of this. I find that hard to believe, because in China alone, half the population have active video game accounts. The China market is $112 billion today. That is half of the global gaming market. And by 2028, the estimate is expected to be 650 billion US dollars. That is incredible.

Oh, go back one slide. So I hate to admit this, but I am myself a gamer, although I don't play games as often as I used to. But I have been around long enough to remember when we didn't have video games. Instead, we had books. And one of my favorite genre of books was a series called the Choose Your Own Adventure series. And the really interesting thing about these types of books is they read like a novel, but then eventually you were presented with a scenario and given several options for how to address the scenario.

And depending upon which option you chose, you would have to reference a different page in the book, and that would tell you what the outcome was. And the really interesting thing about these novels is that you could read these books multiple times over and have a completely different experience, depending upon the selections that you made. Then once personal computers became more accessible in the early to mid-1980s, this concept then evolved into what was called text-based adventure games. So games like "Colossal Cave Adventure," "Zork," "Castle." These are really the predecessors to modern games like "Legend of Zelda," "World of Warcraft," et cetera.

And so I can actually remember playing these games with my brothers. We would play these games for hours after school, much to the disappointment of my parents. So recently, when I came across the source code for one of my favorite text-based adventure games, growing up, "The Hitchhiker's Guide to the Galaxy," it made me wonder, could I do a presentation about software security in the style of an old text-based adventure game? We're about to find out. I've created a little game simulation to help us talk through the three technologies I wanna present on today. And so this is what I envision a text-based adventure game about software development and software security might look like. - [Narrator] "The Hitchhiker's Guide to the Software Security Galaxy."

A science fiction story. Copyright 1984 by Infocom, Incorporated. All rights reserved. Chapter 1: "The Beginning of the End." You wake up.

The room is spinning very gently around your head. Or at least it would be if you could see it, which you can't. It is pitch black.

- [Jake] So in this book, in this game, our main character, Arthur Dent, he wakes up from his sleep. It's obviously pitch black, so he doesn't know what to do. And then the game, you're supposed to put in a command to try and figure out what the right action is. Considering it is pitch dark, we should probably turn on the light.

- [Narrator] You managed to clumsily fumble for the light switch, and miraculously, you find it. Good start to the day. Pity it is going to be one of the worst days of your life. The light is now on. The light reveals your bedroom, which is a mess. It is a small bedroom with a faded carpet and old wallpaper.

There is a desk, a chair, and a window with the curtains drawn. Slung over the chair is a tatty dressing gown. On the desk is a phone.

- [Jake] So obviously, Arthur is still in bed. His room is a mess. This parallels the actual storyline in the book. So we should probably get out of bed.

So we'll enter the command. - [Narrator] You stand up, still a bit woozy from the previous night's libations. As you put on the tattered gown, you notice a couple of analgesic pills in the left pocket. You quickly take them, while praising the small fortunes in life. The brief moment of peace is interrupted abruptly by the skull-shattering ring of the phone on your desk.

You try to ignore it, but the sound is only exacerbating your already blistering hangover. - Okay, so again, Arthur is trying to wake up in the morning. Apparently had a little bit too much to drink last night. The phone is ringing. So I would suggest we answer the phone. - [Narrator] It's your boss Zaphod Beeblebrox.

His voice crackles through the receiver sounding extremely agitated. "We need to have the software features fully integrated and tested prior to tomorrow's release! Can you handle that?" he asks sternly. You muster up as much confidence as you can and respond, "Yes, I can handle it. I'll get started right away." But before you can finish your sentence, your boss hangs up the phone, abruptly ending the call. You put down the receiver, take a deep breath, and think to yourself, "This is going to be an exceptionally long day."

Then, it hits you. The answer to all your problems. The solution is so simple, but you can't help but mutter the words. "Bubble." - All right, this is where we get into our first technology.

So Arthur's boss calls, has an urgent development project that he has to address right away, and he seemingly has an unreasonable timeline to get this done. But then he thinks of a tool called Bubble, which is what we refer to as a no-code or a low-code development tool. So what are these types of tools? Well, low-code and no-code development tools are effectively an application that allows you to develop other applications with a need for very limited software development knowledge. And just as the name suggests, a low-code solution is one that allows you to do software development with some, but it does require a little bit of software development knowledge. Not quite a bit. Versus a no-code solution, where you don't need any software development skills or expertise whatsoever.

And these types of applications are really geared towards non-developers. And there are a number of different benefits for using these tools today. First and foremost, they're very easy to use.

You can design applications basically using a drag-and-drop interface. Development time, much faster. You can create applications in a fraction of the time it takes compared to traditional software development methods. Your costs tend to be lower.

Again, because you're not requiring expensive software development resources to create applications. And quite honestly, maintenance activities become far less complex. And lastly, they can really enhance the customer experience because you don't need to spend a lot of time... You can roll out new features, provide updates, again, in a fraction of the time, which, again, makes your customers happier.

Now, with benefits, naturally there are some downside to this. These types of applications, they are applications, and so they are prone to vulnerabilities. And vulnerabilities in these applications can actually create vulnerabilities in the applications that are developed using these tools. So you really need to first and foremost make sure that your no-code and low-code development tools are properly patched, using the latest libraries, et cetera. Again, because people using these tools might not have very much software development experience, it could actually result in poor coding decisions. So if some software development knowledge is required or some coding is needed to develop an application, but the person doing that might not possess the requisite knowledge, they could potentially introduce vulnerabilities into those applications because they don't know better.

These types of tools can also be quite complex at times, and so they're prone to misconfiguration. If you have folks who are responsible for these applications, and they're not particularly knowledgeable about software design or how these applications should run, they could potentially misconfigure them, and like other situations, introduce vulnerabilities. In addition to poor coding decisions, they could also make poor design decisions, like not using authentication properly, or not leveraging secure channels when transmitting data outside of the application boundary.

And then, lastly, these types of applications, because they're so easy to use, they also make it much more difficult to get visibility and control over the resulting code. You're relying on these applications to write code for you. The trade-off is, is you don't get a lot of influence in how that code is written. So we talked about no-code/low-code tools, we talked about some of the benefits, and we talked about some of the security issues. Let's go back to our gameplay to set us up for our discussion about our second technology.

- [Narrator] Chapter 2: "Shadows in Darkness." Having dealt with the latest crisis created by your boss, you can now continue working on your favorite project, the incredibly popular role-playing game titled "42: Adventures in the Infinite Improbability." After pushing a few updates to the production code, the technical support team has discovered several intermittent issues with the game's operation. There have been reports of random data glitches, missing information, and even a few system crashes in the payment functions for the "Utter Mayhem" game play feature and other expansion offerings. You suspect it may be an API conflict causing the issue, but you aren't quite sure.

- So again, Arthur, our main character, he is responsible for an application that's actually a game. And he's had an issue, or there's been reports of intermittent issues with the game. It being an online game, he thinks it could possibly be an API issue.

So in order to determine whether or not it's an API issue, we should probably first understand what APIs the application has. So let's run an API discovery on this. - [Narrator] Good thinking.

As suspected, it was an undocumented API endpoint that was causing the issues. You successfully remove the offending code, and push the updated code back into production, to the delight of all game players worldwide! - All right, so a common issue with APIs are the proliferation of undocumented or unmaintained APIs. And these are commonly referred to as shadow APIs or zombie APIs. But before we talk about that issue specifically, let's talk about what cloud APIs are in general.

So a cloud API is just an interface that allows applications to communicate with each other over the internet. A common use case in the payments industry is point of sale on the cloud. And we're starting to see a lot more point-of-sale vendors moving some of their backend, and same with merchants, moving some of their backend, in-house, hosted point-of-sale systems into the cloud. And there are many benefits for doing this.

For example, by exposing point-of-sale functionality to the cloud, you're able to interface an array of different applications. So enhanced capabilities are one benefit. It also results in potential improved efficiencies. By exposing your application to more capabilities, theoretically, you can do more things with those capabilities.

Things like inventory management, order fulfillment, these are functions that may not exist in traditional solutions, but because you've exposed it now to cloud APIs, you're exposing potentially far more functionality than what may have existed beforehand. Similarly, it could also help with scalability. If you're able to move some of your workloads from your backend system into the cloud, you can scale those using cloud-based infrastructure in times of need. But again, there are some downsides to this.

I mentioned the use of shadow APIs. So a shadow API is effectively an API that was never intended to be inserted into an application. It's basically a backdoor. The other type of API I mentioned were zombie APIs, which were APIs that were originally supported, but are no longer being maintained.

And both of these types of APIs are problematic because they are exposing functionality that should not be exposed to the internet, and potentially introducing or exposing vulnerabilities to the internet that could potentially be compromised. So some of the ways to mitigate that would be to do API discovery, API inventory. Another issue with APIs in the cloud is that you are now exposing far more application functionality to the internet than before.

So with the exposure of more functionality, you are now increasing the attack profile of the application. So some of the mitigations that you could implement to help with this scenario are doing things like having secure coding practices, using multifactor authentication, doing input validation. You know, other types of controls that can help minimize these vulnerabilities. In addition to, like I said, doing API discovery, so you can find these APIs and decommission them. So we talked about cloud APIs.

We talked about no-code/low-code solutions. We'll go to the gameplay one more time to set us up for our third and final technology. - [Narrator] Chapter 3: "The Rise of AutoGuard." After participating in numerous security assessments with your assessor, Trillian, the two of you decide to put your coding skills to more productive use. You work together to develop a new software product, called AutoGuard, that will revolutionize the security assessment industry.

A key feature of AutoGuard is its ability to analyze vast amounts of source data, cross-reference regulatory requirements, flag potential issues, and generate reports, all in a matter of seconds, tasks that would otherwise take an assessor days to complete manually. Despite acknowledging your software engineering masterpiece, Trillian conveys her concern about the reliability of such extensive automation. Can the results be trusted? - All right, in this scenario, Arthur is being presented with the situation to leverage artificial intelligence to help with a future software assessment. Now, the use of AI in software development is an incredibly vast topic, and I'm not going to touch about all the benefits that leveraging AI can bring into software development in general. I'm going to specifically focus on the use of AI and software security assessments. We're getting a lot of questions at PCI about, can we leverage automation and AI in security assessments? But before I get into that, let's talk about some of the benefits of leveraging AI for these use cases.

So first and foremost, cost savings. If we are leveraging AI, we can do things like automated evidence collection and analysis. That is probably where assessors spend the majority of their time, in terms of an assessment. So cost savings.

Could also result in increased productivity. Now that the assessor isn't spending all of their time trying to find evidence, they're able to do more things like do deeper analysis, find problem areas, and investigate those further. And then another benefit is actually greater scalability.

The use of AI can enable an assessment to be done against not just one framework, like PCI standards, but it can do assessments against multiple frameworks at the same time. And this really helps organizations that are subject to multiple regulatory frameworks. It also helps with things like GRC management.

Again, you're not having to do so much manual evidence collection. Multiple assessments can be coordinated. And you're not having to eat up all of your software developer time trying to track down these assessments.

You can let them do their job and let AI handle the evidence collection. Now, despite these benefits, and PCI recognizes these benefits, we have to put some guardrails on their use. We do want to encourage the use of AI and automation, but only in certain circumstances, for the time being. Things like evidence collection. Absolutely.

Automated security testing, automated security controls. These are all things that AI can help with, without any potential controversy. However, one area where we do not permit the use of AI yet is for decision making functions.

AI can support decision making, but at the end of the day, a human needs to interpret that information and make the decisions. Don't rely on AI to do that on your behalf. For example, things like pass/fail determinations, compensating control analysis. These are things that you can use AI to assist you with, but don't rely on them. And PCI is working on guidance on the use of AI and assessments, and we expect that to be published in Q1 of next year. We are also looking at how we can change some of our internal manual processes.

Things like reporting, attestations, and listing updates, and to make improvements on those to better support AI in the future. So again, these are all things we're considering, but we're not in a position yet to support that yet. We are looking at that. So again, in summary, there's three things I want to point out.

We do want to encourage the use of these technologies. We understand the benefits, and there are many benefits. But again, we also recognize that there are challenges.

So the key takeaways from this are: understand the risks of using these technologies, know their limitations, and stay up to date on security issues and best practices for how to leverage these technologies. And with that, thank you for your time today. (upbeat music)

2025-01-27 14:38

Show Video

Other news

CS50 Tech Talk with OpenAI - ChatGPT for Writers 2025-02-22 18:14
Dishonored Lore: Inventions and Technology 2025-02-22 11:42
Removing and replacing parts | HP EliteBook X Flip G1i 14-inch Notebook Next Gen AI PC 2025-02-21 12:02