Subscribe
Copied to clipboard
Share
Share
Copied to clipboard
Embed
Copied to clipboard
The Business of Open Source
Trailer
Bonus
Episode 19
Season 1
Securing the Cloud with Josh Stella
The conversation covers:
- Josh’s role as CTO of Fugue, a leading cloud security and compliance provider for engineers.
- The difference between cloud security and data center security — and why old school approaches to security don’t work in the cloud.
- How engineers and security specialists can best communicate with business leaders about how to approach security, and how Fugue can help.
- Who should be the person in charge of setting up Fugue, running reports, and communicating results across an oragnization.
- The people who tend to lose their job when a cloud security breach occurs.
- Why cloud security requires organizational change, and how companies are adapting to prevent issues.
- The importance of upskilling employees and making sure they have the appropriate knowledge to solve cloud challenges.
- Why the cloud has the possibility to be more secure than a data center. Josh also talks about cloud perception, and why some are still viewing the cloud as scarier than the data center.
- What Joshn considers to be the most effective hacking strategies for cybercriminals.
- The relationship between security and compliance, and how organizations should approach that relationship.
- Why there is no such thing as a perfect security posture.
Links
- Fugue: https://www.fugue.co/
- Customer write-up on G2: https://www.g2.com/products/fugue/reviews/fugue-review-4269523
- Twitter: https://twitter.com/joshstella
- LinkedIn: https://www.linkedin.com/in/josh-stella-949a9711/
- Fugue Blog: https://www.fugue.co/blog
- Fugue Masterclass: https://resources.fugue.co/cloud-security-masterclass-registration
- Fugue Office Hours: https://resources.fugue.co/cloud-infrastructure-security-office-hours
Transcript
Emily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.
Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with Josh Stella. Josh, thanks so much for joining us.
Josh: Well, Emily, thanks so much for having me.
Emily: Of course. I always like to start the same. Can you just introduce yourself and your company, and tell me a little bit about what the company does, and then also what you do?
Josh: Sure. So, Fugue does cloud security for public cloud providers like AWS, and Azure, and Google. Prior to founding Fugue, I worked at AWS as a principal solutions architect primarily focused on national security; Department of Defense, and similar things. My background is I'm a programmer and I'm a software architect, and I've kind of lived between national security kinds of work and high tech in startups. And so what Fugue does is we’ll tell you all about the security posture of your cloud environments, and teach you where you have weaknesses that hackers can exploit; we help you close those, and then we can actually keep things from having those misconfigurations going forward. So, that's a little bit about us. If you're a developer, you can use our forever free developer version, and we work with a lot of enterprises folks like SAP, and big organizations, too.
Emily: So, were you involved with setting up the super-secret CIA cloud that AWS was involved in?
Josh: I was not personally. A very close colleague of mine was actually working very closely on that, but no, I was not directly involved in that.
Emily: Okay, you probably couldn't talk about it, even if you were so. [laughs].
Josh: No comment.
Emily: Anyway, I always like to ask also, what do you actually do? Like, you get up in the morning, presumably, you don't go to an office anymore, but—
Josh: Oh, true. True, yeah. Whether going to an office or not, my days are… so I started out founding the company with my co-founder, Andrew Wright. And for a while, I was the CEO when we were in the kind of R&D phase, but then I always intended to hire a really great CEO, which we did a couple of years ago, Phillip Merrick, and I became the CTO. And there are different kinds of CTO.
My main functions are, like, I get up in the morning, I go read the news about any breaches in Cloud that have happened, and then I try to recreate them whenever possible, if there's enough information, because the attack vectors on Cloud are completely different than in the data center, and are inobvious to folks. So, when you read about a breach, and you see that they use the identity and access management service almost like a network, to get to S3, that's really interesting and it's really important so that Fugue can protect our customers. So, I spent a fair amount of time doing that. I do work every day with the product team. Occasionally, I will weigh in fairly strongly on an engineering topic, but a lot of times our engineers are just very, very good and we've hired experts and all their areas so I work with them, but it's usually just to give advice and some guidance.
And I do a fair amount of writing, and I do a fair amount of teaching classes online: we have a masterclass series on Cloud security that has been very well received. And then the research I do into how cloud exploits are actually being done by recreating those in my own environments, I use those both in the classes and of course, Fugue as our product can then have protections built-in against them. So, I’d say that's a lot of what I do.
Emily: I wanted to ask a little bit more about this difference between cloud security and data center security. Can you go into that a little bit more? And then also, what do people miss in that difference?
Josh: Okay, so I'm going to start at the prosaic and kind of go to the sublime a little bit, but the most simple way to think about the difference is in the data center days, you really had a network perimeter. So, you've got a big pile of servers, they're racked and there are switches that that connect them together, and then there's this layer of security at the, kind of, perimeters of the network where the data center network connects to, whether it's the corporate network, or another data center, or the internet. And that kind of perimeter defense slash defense in-depth idea meant when you were talking about data center security, the primary things you were thinking about were, “What's happening on my network?” And, “Are the servers—or the physical devices that are actually running compute stuff—are they secure?” Well, it turns out in the Cloud, almost none of that matters that much, and the reason is—so I think Gartner recently said, like, over 90 percent of cloud exploits are due to misconfigured cloud services.
So, that the data center, you had, like, piles of baryonic matter. You had actual servers in racks, you would replace them every three years, maybe five years on a recap cycle. And so it was moving slowly, and to get to those things, you had to kind of penetrate those layers of network perimeter and defense in depth. Well, on the Cloud if you stand up an S3 bucket, for example—and the press loves to pick on S3 breaches because well, a lot of people store data in S3, but very often these breaches are much more complex than just a misconfigured S3 bucket—but Gartner said the vast majority—and this is what we see, and what I saw at AWS—of hacker success in Cloud is looking for misconfigured cloud services, and then exploiting those. So, wherein the old days you might have been really concerned: “Do I have a bunch of packets coming in from an IP address that's known to have botnet activity on it?”
And if so, I'll try to shut off that flow of packets, and, “Are my server operating systems patched?” And things like that. You definitely still want to keep your patch levels up, but a more typical cloud exploit would be something like finding API keys in an insecure place so that the attacker can modify your cloud infrastructure, and goes in and steals the backup of a database, or installs crypto mining software inside your infrastructure. So, it's a really big topic, but you really have to think about it very differently. You have to think about it as a software engineer more than as a security engineer. You have to think about it less as, “I'm protecting things,” and more as, “I'm configuring them properly. I'm making the Cloud safe by configuring it properly.” This is why we teach masterclasses. There's a very long list of ways to get those things wrong.
Emily: Do you think in general, people are aware of these differences, and this idea that you have to think about security differently? Like, how much is that percolating through to people who are not in—they're not living and breathing this cloud computing space?
Josh: It has not dawned on as many people as I wish it had. [laughs]. There are still a lot of folks who think using old school approaches to security will work on Cloud. And there are a number of problems with that. One is that the skills needed to do this stuff properly on Cloud are more like software engineering, engineering skills, and less analyst skills.
So, when you can configure all of your compute resources via APIs, which is how the Cloud works, you're going to automate—I can build a global network while I'm talking to you by typing in the background. You could not do that in the data center. So, I don't see enough people being aware, not fully. And the worst thing that I see—well, and it's particularly bad if you don't understand what the threat is and what the attack surfaces are because, guess what, the attackers are all automated and very clever, and they will get you—but the next bad thing I see is when people try to force the Cloud to act like a data center in order to use the old ideas about how to do security. And that removes all the advantages of the Cloud, and it also never works.
Emily: That's interesting. Obviously, this podcast is about the business of cloud and cloud-native, and security is sort of ultimately a business problem.
Josh: Yep.
Emily: How do people talk about security when they're talking, not just inside the engineering department, but also with business leaders, and how can engineers—or security specialists—how can they communicate, “This is the way we need to approach security. This is why. This is what we need to do and why?” How do people make sure there's not some stuff that gets lost in translation?
Josh: What I recommend is that—and this is why we—it's one of the reasons why we built Fugue, is we give people tools for doing this—what I would recommend is kind of base camp one on climbing the Cloud security mountain is just understanding your current security posture; understanding whether what you have built in the Cloud is safe. And I can pretty much guarantee to every listener that, you know, we had a new customer write a nice write-up on Fugue in G2 saying, “Fugue is going to hurt your feelings the first time you run it.” We're going to tell you about a whole bunch of stuff that should scare you, and we're going to present that visually, and that's something you can take to a boss. You can say, “Hey, I used this free tool and it says we have, like, 90 things configured in ways that hackers exploit. We should go fix those, and by the way, we should keep keeping track of this.” And so I think presenting the information, rather than it being vague, quantifying it and having evidence, in my experience—in general in life around business decisions—is much better than having an opinion or winning an argument. So, get some data, show it to your boss, and go start fixing stuff. [laughs].
Emily: So, my next question is who should do this? I mean, I think there's often a question related to security, and particularly you were just saying part of the issue with cloud security is that there's a little bit of a shift of responsibility, but who should be the one that's setting up Fugue, and running these reports, and talking to their boss about this problem?
Josh: Yeah. So, it varies because organizations are struggling with where these things should live. What I believe is the concern with security, as you pointed out, is fundamentally a business concern. It's: “are my systems doing what is intended for whom it is intended, and only that?” So, that has to begin with the folks that are building the systems.
So, very often at Fugue, what we'll see with the more sophisticated customers we have, the DevOps team will want this stuff baked in really early in the software development lifecycle, and they might even be doing that kind of independently of the security team, but the security team usually also has a role as does the compliance team. So, what we believe is that this should be implemented throughout the entire software development lifecycle from when people are writing their infrastructure’s code or building infrastructure in the development environments, all the way through to monitoring and production, and doing audit reports for SOC 2 compliance or whatever. Generally, with Fugue—depending on the organization—we will either find folks who really care about what we do in the DevOps team, or in the security team. And the way we like to talk about it is any engineer who is concerned with security—whatever their title and role—can benefit from understanding cloud security and being more effective at it.
Emily: When there is a cloud security breach, who loses their job?
Josh: Uh, well, quite a few CSOs. If it's the kind that hits the Wall Street Journal, usually the CSO is not going to be around. And if you can agree with what I'm saying, which is that building stuff correctly and not misconfiguring cloud is the most critical thing to get right for cloud security CSOs don’t generally have authority over how people build software. And I think this is a disconnect that really needs to be addressed in every organization. If you get breached, you might say, “Well, that's the chief information security officer’s job to keep those from getting breached.”
In the old days, that meant the security organization adding in those layers of perimeter defenses and trying to capture things. Well, now it means, you know, Global 2000 or Fortune 500, there are thousands of developers, any one of whom might be building a new network right now, or a whole new application and all of its attendant infrastructure. So, I think we're going through a period where that shift in technology has created a shift in responsibilities, or maybe a shift in the ability to do the right things and where that needs to happen, but the old ways of thinking about how information technology was built and secured aren’t helping. So, the CSO gets fired, but it's usually not their fault is my opinion. [laughs].
Emily: What would you think—I mean, everything I talked about with moving to Cloud and moving to cloud-native, there's all these technical changes, but there's also all these organizational changes. How does cloud security require organizational change? And how successful do you see companies being at adapting not just tech, but also organizations?
Josh: Well, I mean I think that is the important part. The tech is there: we built Fugue, there's other tools out there, there's other things you can use, there is great technology for this. The struggle is with the organization and how to implement it, and how to operationalize it, and build it into workflows. So, I think that as far as how well people are doing with it: it's highly variable, and it's even highly variable within organizations. So, you might find a sort of pocket of people who are very clued in to how you should be thinking about this and dealing with it in the same company where another group is still thinking, our firewalls and our intrusion detection systems are good enough, or are more important than they are.
So, it really comes down to whether you are thinking in a cloud-native way. And I think that the Cloud is not a pile of remote data centers. It is a global distributed computer that you can program and configure. And that's really what we're talking about when you build an air-quotes, “network,” Amazon aren't running around and plugging wires into switches. That's just a configuration. It's just a configuration of that big distributed computer, and so we have to think about this from a software engineering perspective.
Now, the good news is there, that—well as it relates to the organization, a lot of security organizations don't have a lot of developers in them, and so this looks confusing and scary. And that always creates challenges. If people are intimidated by something or it's out of their comfort zone, that actually creates organizational friction. But I'm here to tell you, the Cloud is potentially—if done well—Cloud is the most secure way to do computing ever invented by humans, and for a really simple reason: you can control it all through APIs. Now, that means I can build a global network in five minutes and you might not notice, but it also means I can write programs that are constantly aware of everything and know how to get things right. So, it is a big organizational challenge, a lot of folks that are trying to, kind of, adapt their traditional data center teams may not be aware that you probably have people on your teams that are really trying their level best but don't have the most appropriate skills for the problem that is now required to be solved.
Emily: Skilling up is always a big challenge, as is reorganizing and reconceptualizing how you work and how you work together.
Josh: Oh, yeah. Yeah, absolutely. And a lot of the—it gets really complex because organizational structure has a whole lot more inertia than technology, and for lots of reasons: somebody has been here for 15 years and wants to get promoted, or hasn't been promoted and has a whole team and a budget, and who's going to pay for this, and who's going to chip into this, and which managers need to change their ideas about what they own and are responsible for? And I'm not trying to be pejorative here. That's all real stuff.
The Cloud has effectively turned security on it’s head. It used to be the infrastructure and security teams would go build secure environments, and then application developers would deploy into those environments. And now all of a sudden, application developers run a script or a program, and it builds the “infrastructure”—air quotes, again. We're really configuring a big, existent thing—but all of a sudden, in five minutes, you have what it would have been weeks and months of procurement, and discussion, and controls on what was being built. So, when you have a change that radical, you probably can expect—you should expect—that a lot of people are going to be challenged by that and probably won't tell you that they are because people don't like to admit when they don't understand something.
So, skilling people up is really, really important. What we try to do in the masterclass series is give people new ways to think about these topics. I can't teach you everything I know about cloud security in a series of classes that are only an hour every other week or something, which is about what we do, but I can tell you how to take apart the problems and really think about them. And guess what? Even if you don't already know how to do that, you can learn it, and it's interesting, and it's fun.
Emily: I wanted to go back to something else that you said about Cloud having the possibility to be more secure than a data center. How do you think that figures—if at all—into organizations’ decision to move into the Cloud? I mean, how aware are they that this actually could be more secure?
Josh: Highly variable. Some understand that. Most don’t. Most are still viewing Cloud as, kind of, scarier than the data center because their mindset hasn't shifted. So, for example, with Fugue, you can tell Fugue, “Tell me everywhere I have a dangerous misconfiguration.” And we will show that to you on an automatically generated map, like a Google map of your infrastructure. We'll show you physically, visually where that is.
Well, how would you do that, even that simple thing from a Cloud—Fugue perspective, in the data center? You would have to typically do what's called a data call, and get a bunch of human beings to answer questions and plug data into spreadsheets, and when I worked in national security, we would get these data calls, and you'd be given, like, a week. Well, Fugue can do that every five minutes, in about five minutes. So, even out of the gate, the fact that you can use computer software to interrogate the other computer software means you can automate it, and you can be much more thorough. Humans, also, are terrible at keeping lists of details. Computers are great at it, so we can use them for that.
But then as you extend further—and we have this diagram of climbing a mountain of cloud security—so the very first base camp, sort of, at the foot of the mountain is just understanding what you have and what's wrong. But as you go up, you want to start doing some other things: you want the system to automatically tell you any time something changes, and any time something changes in a dangerous way. And then with Fugue, we've, kind of, taken this to its logical conclusion—and we're unique in this regard. This is actually what we started with when we first founded the company, and why we did so much R&D—you can tell Fugue, if anything is misconfigured, automatically heal it back to a known good configuration. Fully self-healing infrastructure is something that was totally elusive for decades in the data center because there weren't consistent APIs over these things. So, not a lot of people are ready to think that way, but that's where this is all going.
Emily: So, is this kind of like how people are more afraid to fly in an airplane because they're not in control, but they have no problem getting into their car, even though you're, like, dramatically more likely to die in a car accident.
Josh: That is an awesome analogy and I'm going to steal it. Yeah, it really is a lot like that. I think that in the history of automated systems in computer security, a lot of claims were made that couldn't be backed up with tech because we did not have these very consistent APIs that the Clouds have. If you were trying to do automated security in a data center, you probably got burned. So, in a way—and I don't want to strain your analogy too much, but I might a little bit—early flight was not so safe. Until you really get into the ’60s and ’70s, you should probably have been nervous getting on an airplane in 1937 or 1945, but by the time we really had figured it out, it became tremendously safer—as you point out—than driving a car.
And I think that folks are just starting to realize it. But you have to trust the system, you have to trust the automation, and that takes time and building trust. But I'm here to tell you, this can now be done in a way that will work highly effectively and it is the future. The bad guys are all automated, okay? The hackers are running scripts, and programs and botnets constantly to find anything you have facing the internet that has any exploit they know how to use. So, they just get up in the morning and have a cup of coffee and look through a log of all of your and everyone else's stuff that you got something wrong on, and they point another program that and exploit it. Well, if you're not using automation and they are, you're doomed.
Emily: Yeah, I wanted to ask, so if you went over to The Dark Side and decided to be a hacker, what would you do? What do you think are the most effective hacks? You don't have to go in detail, of course, but I'm just curious what you've learned.
Josh: Sure. I mean, there's a lot of ways to do this stuff. I mentioned two of the most common ways are finding—so if everything is driven by APIs, if you can get a hold of the API keys—essentially the login information, the ability to access APIs—if you can get a hold of those, then whoever's stuff is using those APIs you can now get to. And so you see a lot of that, folks using bad engineering practices and putting keys in source code, and it's showing up in GitHub, and people searching GitHub for keys. Or doing things like having unencrypted backup snapshots of file systems sitting out there and in those file system backups there being keys. That's something bad guys do a lot.
You should be using things like IAM, and key rotation, and putting everything in KMS, and doing best practices there, and never ever, ever having API keys stored in source code or on a disk or anywhere that the bad guy might find, it even later. I mean, there was a breach last year of actually a cloud security company—not us—where that's exactly what the bad guys did. They found—I won't name names—but they found some keys, and then they managed to get into the company's cloud environment—and this is really a cool hack. Instead of—the keys they found gave them access to the production database, but they didn't go into it. Why didn't they go into it? Because they're probably monitoring the production database. But those same keys allowed the bad guys to stand up another database cluster with a backup of the production database. Like that is such a cloud-native hack, you would never have hackers—well, I can't say never, but it would be extraordinarily difficult to imagine hackers breaking into a data center and then standing up a new compute cluster to steal data from so that it wouldn't be monitored because that would be obvious.
But in Cloud, that's probably happening all day, every day where people are building stuff, and that's why something like Fugue becomes important. So, there's lots of ways you can go about it, and honestly, one of the most fun parts of my job is reading about those things and seeing how hackers are going about it because I'm telling you, they are more clever and more cloud-native than most of the people that are trying to prevent them coming in, and I'm often just very impressed and, kind of, I'm not happy anyone's data got stolen, but I can appreciate a good hack and there's some really clever ones out there. IAM relationships is another big one to look at. People still think of IAM—identity and access management stuff—as being identity. And it is, but now it's the identity of compute resources, and it forms a network that sidesteps the TCP/IP-based network, and so if you can surf that network, nobody's probably monitoring it and you can get a lot of places. So, I can't answer more succinctly than that, but those are a couple of ways.
Emily: Before we go, I wanted to ask you about the relationship between security and compliance. So, even if security is clearly a business problem, compliance is, like, even more into that business-y category. Can you just talk a little bit about the relationship between security and compliance and how organizations need to think about that relationship?
Josh: Well, it's a good question. So, historically—at least in the environments that I worked in—compliance and audit were, sort of, at the end of the development process as a sort of gating function. In the national security world, you need to get what's called an ATO, an authority to operate, and an ATO requires going through a NIST certification and accreditation against the 800-53 compliance family standard, and that's a big manual process with a human team, and Excel spreadsheets, and big documents and so on. And it makes sense. You do want to try to prevent bad stuff from happening.
Well, in Cloud—and then security was kind of different in that security were the folks who were doing things like monitoring firewall configurations and doing packet capturing at those perimeters that don't exist anymore, and doing intrusion detection, and making sure people's laptops didn't have unapproved applications on them. So, these worlds were a little separated. In Cloud, they're actually much more closely related, and they should be. And the beauty of that is, when you look at these compliance standards, like NIST 800-53, like SOC 2, like PCI, or GDPR, or HIPAA, or any of them—we cover a whole bunch of them—they're going to give you a whole lot of good advice from a security perspective. So, you can now, using automation and tools like Fugue, rather than having this dreaded audit come, or CNA process at the end of your development cycle that's going to add weeks to—of friction before you can deploy as you fix errors, you can just constantly be using those compliance standards to check your work in an automated way.
So, you build a little, you find out that, “Well, am I breaking any NIST rules?” You know, NIST is going to tell you—well that NIST implemented correctly, like in Fugue, Fugue’s going to tell you, “NIST says you have to have all your data be encrypted at rest everywhere,” And we're going to look across hundreds of cloud resource types and tell you if anywhere, you have data that's not being encrypted at rest. So, it really changes the game on Cloud because now compliance through automation, so it's not this manual audit at the end anymore, you can now have it completely automated and baked into the software development lifecycle instead of doing a week-long audit at the end. In five minutes, you get that feedback, and you can keep doing it iteratively. Compliance can actually become a massive help to getting things secure all the way through the lifecycle.
And in fact, I would point folks to a good friend of ours, was the guest star of a class about a week ago, and he's an expert on bringing cloud environments into compliance. And he taught a whole class on that, I'd recommend that. The final thing I'll say, though, is all those CIS benchmark, and NIST, and all those, there's lots of good stuff in there, but what we've learned from recreating these cloud hacks, is that the hackers are ahead of the compliance standards and the security teams. And so in Fugue, we bake in what we call Fugue Best Practices, and really what that is, is a collection of stuff that will tell you if you're vulnerable to the kind of hack that you read about in the news recently. And you're not necessarily going to get that—you won't get a complete picture of that with things like NIST, and CIS, and so on. However, they're awesome; they're going to tell you a lot. I hope that answered the question. I hope I answered the correct question there. [laughs].
Emily: Oh, absolutely. Well, first of all, it sounds like you can be completely compliant and still get hacked, but I think everybody knows that, you know, there's no such thing as a perfect security posture.
Josh: That is very true. The security posture is going to be helped by looking at compliance standards. There are other things we know are dangerous that are not in the compliance standards, and that's why we put those—and by the way, those things are actually in the totally free forever version of Fugue; you can go see if you're vulnerable to this because the compliance bodies are, kind of, slower-moving, and we can be faster. But then there's another third category, which is hackers doing stuff that no one predicted they would do.
And guess what? They're good at that. There's a reason why hacking used to mean a clever program, and now the means breaking into your stuff because they do it through cleverness, through deep technical expertise. So, you're not going to be able to predict what they're going to do, and that's their job. And therefore you have to employ other tactics than just compliance.
You have to employ things like drift detection: noticing if anything changed in the environment’s configuration. And again in Cloud, 90 percent of what you should care about is configuration of Cloud. Not logs, not packets going over networks. Those are leaky abstractions on Cloud. They don’t capture—there is no real perimeter, so you really have to be thinking about configuration.
And you want to use compliance standards, you want to use predictive rules, but then you also need to keep track of what's going on. So, for example, if I saw a compute instance change its IAM role association, I would immediately—if I got a notification that that happened, I would be immediately looking into that because that has the potential to be a devastating attack, and probably the biggest breach anyone has ever heard of, that's how it happened. So, we now predict that in Fugue Best Practices, but you really need to get things right from a security and compliance perspective, but then keep in mind that the hackers are going to do things that you're not predicting, and that's why we do drift detection and self-healing in Fugue because you just can't think of every bad thing they might do to you.
Emily: I think also part of what you're saying is just don't think of compliances as exclusively this hurdle that you have to jump through, but also think of it as almost like a tool that you can use, a set of best practices that you can use throughout the process.
Josh: Oh yeah, absolutely. I mean, that's the beautiful thing about what's happening now with Cloud. It’s stuff that used to be this onerous data call, and you have to fill out forms. You can just use—so, okay. I'm a programmer. I'm not a security engineer as a background, I'm a very security-focused programmer and software architect.
When I'm writing a program, I have tools that tell me where I'm being dumb. That’s, like, 80 percent of the job is your tools telling you where you've made errors, and then the other 20 percent is you catching the errors the tools weren't smart enough to find. So, for example, just to use a, kind of, goofy, trivial example, if I were to try to multiply your name times a date, if I have a decent programming compiler, or interpreter, or debugger, it's going to tell me, “You probably don't want to multiply a name by a date. You're probably not going to get a result that is sensible.” So, it's going to tell me where I've made a mistake.
With Fugue and similar technologies, that can now be done for security and compliance. And we use the compliance families to provide that guidance. So, in the same way that a programmer in the past would see, “I’ve made a cast error on types,” or something, now with using Fugue, Fugue will tell you, “Hey, you made a security error on that firewall rule.” With Cloud, and APIs, and automation tools like Fugue, security and compliance become highway builders, not tollbooth operators. They contribute to velocity rather than taking it away, and I think that's really exciting.
Emily: I just have a couple, sort of, last questions for you. The first one is what tool could you not live without, or I should say, do your job without?
Josh: Well, to be honest with you. The most important tool I use, other than things like web browsers that are just par for the course, is just having a great text editor. [laughs]. And programmers out there will understand why I'm saying that. And I got to say, I was an Emacs guy for, like, 20 some years, but VS Code is really, really good. I love what Microsoft's doing these days with the programming tools, and so I'll choose VS Code. I love it.
Emily: And then how can listeners connect with you, follow you, read more?
Josh: Oh, cool, yeah. So, on Twitter, I'm @joshstella. They can email me, I'm Josh, J-O-S-H@Fugue, F-U-G-U-E.co. I'm on LinkedIn. And if you ping me on any of those—I mean, the main thing I would suggest is keeping track of our blog, and the masterclass series, and we also do office hours. I mean, we take education really, really seriously at Fugue and trying to educate folks about what we have learned. And so hopefully people will find those things valuable. A lot of folks have.
Emily: Well, thank you so much, Josh, for joining us.
Josh: Well, yeah. Again, thanks for having me. I enjoyed the conversation, Emily.
Emily: Thanks for listening. I hope you’ve learned just a little bit more about The Business of Cloud Native. If you’d like to connect with me or learn more about my positioning services, look me up on LinkedIn: I’m Emily Omier—that’s O-M-I-E-R—or visit my website which is emilyomier.com. Thank you, and until next time.
Announcer: This has been a HumblePod production. Stay humble.