Screaming in the Cloud - Making Compliance Suck Less with AJ Yawn

Episode Date: June 17, 2021

About AJAJ Yawn is a seasoned cloud security professional that possesses over a decade of senior information security experience with extensive experience managing a wide range of cybersecurity compliance assessments (SOC 2, ISO 27001, HIPAA, etc.) for a variety of SaaS, IaaS, and PaaS providers.AJ advises startups on cloud security and serves on the Board of Directors of the ISC2 Miami chapter as the Education Chair, he is also a Founding Board member of the National Association of Black Compliance and Risk Management professions, regularly speaks on information security podcasts, events, and he contributes blogs and articles to the information security community including publications such as CISOMag, InfosecMag, HackerNoon, and ISC2.Before Bytechek, AJ served as a senior member of national cybersecurity professional services firm SOC-ISO-Healthcare compliance practice. AJ helped grow the practice from a 9 person team to over 100 team members serving clients all over the world. AJ also spent over five years on active duty in the United States Army, earning the rank of Captain.AJ is relentlessly committed to learning and encouraging others around him to improve themselves. He leads by example and has earned several industry-recognized certifications, including the AWS Certified Solutions Architect-Professional, CISSP, AWS Certified Security Specialty, AWS Certified Solutions Architect-Associate, and PMP. AJ is also involved with the AWS training and certification department, volunteering with the AWS Certification Examination Subject Matter Expert program.AJ graduated from Georgetown University with a Master of Science in Technology Management and from Florida State University with a Bachelor of Science in Social Science. While at Florida State, AJ played on the Florida State University Men's basketball team participating in back to back trips to the NCAA tournament playing under Coach Leonard Hamilton.Links:ByteChek: https://www.bytechek.com/Blog post, Everything You Need to Know About SOC 2 Trust Service Criteria CC6.0 (Logical and Physical Access Controls): https://help.bytechek.com/en/articles/4567289-everything-you-need-to-know-about-soc-2-trust-service-criteria-cc6-0-logical-and-physical-access-controlsLinkedIn: https://www.linkedin.com/in/ajyawn/Twitter: https://twitter.com/AjYawn

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me.

I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to. It gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It's an awesome approach. I've used something similar for years. Check them out. But wait, there's more. They also have an enterprise option that you should be very much aware of. Canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network

and impersonates whatever you want to. When it gets NMAP scanned or someone attempts to log into it or access files on it, you get instant alerts. It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached the hard way. Take a look at this. It's one of those few things that I look at and say, wow, that is an amazing idea. I love it. That's canarytokens.org and canary.tools. The first one is free. The second one is enterprising. Take a look. I'm a big fan of this. More from them in the coming weeks. This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery. Lumigo helps make sense of all of the various functions

that wind up tying together to build applications. It offers one-click distributed tracing, so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself? Make one of them go away. To learn more, visit Lumigo.io. Welcome to Screaming in the Cloud. I'm Corey Quinn.

I'm joined this week by AJ Yon, co-founder and CEO of ByteCheck. AJ, thanks for joining me. Thanks for having me on, Corey. Really excited about the conversation. So, what is ByteCheck? It sounds like it's one of those things, byte spelled as in computer term, not teeth, and check without a second C in it because frugality looms everywhere and we save money where we can

by sometimes not buying the extra letter or vowel. So what is ByteCheck? Exactly, you get it. ByteCheck is a cybersecurity compliance software company built with one goal in mind, make compliance suck less. And the way that we do that is by automating the worst part of compliance, which is evidence collection, and taking out a lot of the subjective nature of dealing with an audit by connecting directly where the evidence lives and focusing on security. That sound you hear is Pandora's box creaking open, because back before I started focusing

on AWS bills, I spent a few months doing a deep dive PCI project for workloads going into AWS, because previously I've worked in regulated industries a fair bit. I've been a SOC 2 control owner. I've gone through the PCI process multiple times. I've dabbled with HIPAA as a consultant. And I thought, huh, there might be a business need here. And it turns out, yeah, there really is. The problem for me is that the work made me want to die.

I found it depressing. It was dull. It was a whole lot of hurry up and wait. And that didn't align with how I approached the world. So I immediately got the hell out of there. You apparently have a better perspective on, you know, delivering things companies need and don't need to have constant novel entertainment every 30 seconds. So how did you start down this path and what set you on this

road? Yeah, great question. I started in the army as an information security officer, worked in a variety of different capacities. And when I left the military, mainly because I didn't like sleeping outside anymore, I got into cybersecurity compliance consulting. And that's where I got first into compliance and seeing the backwards way that we would do things with old document requests and screenshots. And I enjoyed the process because there was a reason for it. Like you said, you know, there's a business value to this. We're going through these compliance assessments. So I knew they were important, but I hated the way we were doing it.

And while there, I just got exposed to so many companies that had to go through this. And I just thought there was a better way, like typical entrepreneur story, right? You see a problem and you're like, there has to be a better way than grabbing screenshots of the EC2 console and set out to build a product to do that, to just solve that problem that I saw on a regular basis. And I tell people all the time, I was complicit in making compliance suck before. I was in that role and doing the things that I think sucked

and not focused on security. And that's what we're solving here at ByteCheck. So I've dabbled in it and sort of recoiled in horror. You've gone into this to the point where you are not only handling it for customers, but in order to build software that goes in a positive direction, you have to be deeply steeped in this yourself. As you were going down this process, what was your build process like? Were you talking to auditors?

Were you talking to companies who had to deal with auditors? What aspects of the problem did you approach this from? It's really both aspects. And that's where I think it's just a really unique perspective I have because I've talked with a lot of auditors. I was an auditor and worked with auditors hand in hand. And I understood the challenges of being an auditor and the speed that you have to move and you're in the consulting industry.

But I also talked to a lot of customers because those were the people I dealt with on a regular basis, both from a sales perspective and from sitting there with the CTOs trying to figure out how to design a secure solution in AWS. So I took it from the approach of you can't automate compliance, you can't fix the audit problem by only focusing on one side of the table,

which is what currently happens, where one side of the table is the clients and you get to automate evidence collection. But if the auditors can't use that information that you've automated, then it's still a bad process for both people. So I took the approach of thinking about this from both, how do I make this easier for auditors, but also make it easier for the clients that are forced to undergo these audits?

From a lot of perspectives, having compliance achieved, regardless of whether it's PCI, whether it's HIPAA, whether it's SOC 2, etc., etc., etc. The reason that companies go through it is that it's an attestation that they are, for better or worse, doing the right things. In some cases, it's a requirement to operate in a regulated industry. In other cases, it's required to process credit card transactions, which is kind of every industry. And in still others, it's an easy shorthand way of saying that we're not complete rank amateurs at these things. So as a result, we're going to just pass over the results of our most recent SOC 2 audit to our prospective client, and suddenly their security folks can relax and not send over weeks of questionnaires on the security front.

That means that for some folks, this is more or less a box checking exercise rather than an actual good faith effort to improve processes and posture. Correct. And I think that's actually the problem with compliance is it's looked at as a check the box exercise and that's why there's no security value out of it.

That's why you can pick up a SOC 2 report for someone that's hosted on AWS and you don't see any mention of S3 buckets. You can do a control F and you literally don't see anything in a security evaluation about S3 buckets, which is just insane if you know anything about security on AWS.

And I think it's because of what you just described, Corey. They're often asked to do this by a regulator or by a customer or by a vendor. And the result is hurry up and get this report so that we can close this deal or we can get to the next level with this customer or with this investor, whatever it may be. Instead of let's go through this, let's have an auditor come in and look at our environment to improve it, to improve the security, which is where I hope the industry can get to because audits aren't going anywhere. People are going to continue to do them and spend thousands of dollars on them. So there should be some security value out of them, in my opinion.

I love using encrypting data at rest as an example of things that make varying amounts of sense, because sure, on your company laptops, if someone steals an employee's laptop from a coffee shop or from the back of their car one night, yeah, you kind of want the exposure to the company to be limited to replacing the hardware. I mean, even here at the Duckbill Group, where we are not regulated, we've gone through no formal audits,

we do have controls in place to ensure that all company laptops have disk encryption turned on. It makes sense from that perspective. And in a data center, it was also important because there were a few notable heists where someone either improperly disposed of drives and corporate data wound up on eBay, or someone in one notable instance

drove a truck through the side of a data center wall, pulled a rack into the bed of the truck and took off, which is kind of impressive no matter how you slice it. But in the context of a hyperscale cloud provider like AWS, you're not going to be able to break into their data center, steal a drive, and of course it has to be the right collection of drives and the right machines, and then find out how to wind up reassembling that data later. It's just not a viable attack strategy. Now you can spend days arguing with auditors around something like that, or you can check the box, encrypt at rest, and move on. And very often,

that is the better path. I'm not going to argue with auditors about that. I'm going to bend the knee, check the box, and get back to doing the business thing that I care about. That is a reasonable approach, is it not? It is, but I think that's the fault of the auditor because good security requires context. You can't just apply a standard set of controls to every organization that you're describing where I would much rather the auditor care about, are there any public S3 buckets? What are the security group situation like on that account? How are they managing their users? How are they storing credentials there in the cloud environment as well? Are they using multiple accounts? So many other things to care about other than protecting whether or not someone will be able to pull off the heist of the 21st

century. So I think from a customer perspective, it's the right model. Don't waste time arguing points with your auditors. But on the flip side, find an auditor that has more technical knowledge that can understand context because security requires good context and audits require context. And that's the problem with audits now. We're using one framework or several frameworks to apply to every organization. And I've been with in the consulting space like you, Corey, for a while. I have not seen the same environment in any customers. Every customer is different. Every customer has a different setup. So it doesn't make sense to say every control should apply to every company. And it feels on some level like you wind up getting staff accustomed to treating it as a

box checking exercise. Right. It's dumb that we wind up having to encrypt S3 buckets, but it's for the audit. So just check the box and move on. So people do it. Then they move on to the next item, which is, okay, great. Are there any public S3 buckets? And they treat it with the same, yeah, whatever. It's for the audit box checking approach. No, no, that one's actually serious. You should invest significant effort and time into making sure that it's right. Exactly. Exactly. And that's where the value of a true compliance assessment that is focused on security comes into play because it's no longer about checking the box. It's like, hey, there's a weakness here, a weakness that you probably should have identified. So let's go fix the

weakness. But let's talk about your process to find those weaknesses and then hopefully use some automation to remediate them. Because a lot of the issues in the cloud, you can trace back to why was there not a control in place to prevent this or dissect this. And it's sad that compliance assessments are not the thing that can catch those, that are not the other safeguard in place to identify those. And it's because we are treating the entire thing like a check-the-box exercise and not pulling out those items that really matter and that just focusing on security, which is ultimately what these compliance reports are proving. You know, customers are asking for these reports because they want to know if their data is going to be secure. And that's what the report is supposed to do.

But on the flip side, everyone knows the organization may not be taking it that serious and they may be treating it like a check-the-box exercise. So while I have you here, we'll divert for a minute because I'm legitimately curious about this one. On a scale of legitimate security concern to this is a check-the-box exercise, where do things like rotating passwords every 60 days or rotating IAM credentials every 90 days fall? I think it, again, depends on the organization. I don't think that you need to rotate passwords regularly. Personally, I don't know how strong of a control that is if people are doing that because they're just going to start to make things up that are easy to put the number at the end and increment it by one every time. Great. Good work. Yep. So I think, again, it just

depends on your organization and what the organization is doing. If you're talking about managing IAM access keys and rotating those, are your engineers even using the CLI? Are they using their access keys? Because if they're not, what are you rotating? You're just rotating stale keys that have never been used. Or if you don't even have any IAM users, maybe you're using SSO and they're all using Okta or something else and they're using an IAM role

to come in there. So it's just, again, it's context. And I think the problem is a lot of folks don't understand AWS or they don't understand the cloud. When I say folks, I mean auditors. They don't understand that. So they're just going to ask for everything. Did you rotate your passwords? Did you do this? Did you do that? And it may not even make sense for you based off of your environment. But again, is it worth the fight with the auditor or do you just give them whatever they want? And so you can go about your way whether or not it's a legit security concern. Yeah. At some point, it's not worth fighting with auditors.

But if you find yourself wanting to fight the auditor all the time, at some level, you start to really resent the auditor that you have. To put that slightly more succinctly, how do you deal with non-technical auditors who don't understand your environment, what they're looking at, without strangling them? Great question. I think it goes back to before you hire your auditor. Oftentimes in the sales process, there's questions around who's come from a big four on your staff, or what control frameworks do you all specialize in, or how long will this take, how much will it cost? But there's very rarely any questions of who on your staff knows AWS? And it's similar to going to the doctor. You wouldn't go to an eye doctor to get foot surgery. So you shouldn't go to an auditor who has never seen AWS that doesn't know what EC2

is to evaluate your AWS environment. So I think organizations have to start asking the right questions during the sales process. And it's not about price or time or anything like that when you're assessing who you're going to work with from an auditing firm. It's are they qualified to actually evaluate the threats facing your organization so that you don't get asked the stupid question. If you're hosting on AWS, you shouldn't be getting asked where are your firewall configurations. They should understand what security groups are and how they work. So there's just a level of knowledge that should be expected from the organization side. And I would say, if you're working with the current auditor that you're having those issues with, continue to ask the hard questions. Auditors that are not technical,

I have a blog post on our website and it says, this is the section your auditors are the most scared of. And it's the logical access section of your SOC 2 report. And auditors that are not technical run away from that section. So just keep asking the hard questions and they'll either have to get the knowledge or they'll realize they're not qualified to do the assessment and the marriage will split up kind of naturally from there. But I think it goes back to the initial process of getting your auditor. Don't worry about cost or time. Worry about their technical skills and if they're qualified to assess your environment. And in 2021, that's a very different story

than it was the first few times I encountered auditors discovering the new era. At a startup, the auditor shows up. Great, how do we get access to your Active Directory? Yeah, we don't have one of those. Okay, how do we get on the internet here? Oh, here's the wireless password. Wait, there's not a separate guest network? That's right. Well, now I have privileged access because I'm on your network. It's like, technically that's true,

because if you weren't on this network, you wouldn't be able to print to that printer over there in the corner. But that's the only thing that it lets you do. Everything else is identity-based, not IP address allow listing. So instead, it's purely just convenience to get to the internet. You're about as privileged on this network as you would be at a Starbucks half a world away. And they look at you like you're an idiot. And that should have been the early warning sign that this was not going to be a typical audit conversation. Now, though, in 2021, it feels like it's time to find a new auditor. Exactly.

Yeah. Especially because organizations, unfortunately, last year, security budgets were some of the things that were first cut when budgets were cut due to the global pandemic. So I'm sure that'll have no lasting repercussions. Right. That's always a great decision. So compliance, that means compliance budgets have been significantly slashed because that's the first thing that gets cut is spending money on compliance activities. So the cheaper option oftentimes is going to mean even less technical resources, which is why I just I don't think manual audits, human audits make sense to go through a process, hire an auditor who's selling you on all this technical expertise, and then the staff that's shown up and assigned to your project has never seen inside to get cybersecurity technical experts from these human auditors. And then somebody shows up without that experience or expertise. So you have to start to rely on tools, rely on technologies. And that can be native technologies in the cloud or third party tools. But I don't think you can actually do a great audit by myself in the cloud because auditing is time-based. You build by the hour, and it doesn't make sense for me to do all of those manual things that tools and technologies out there exist to do for us.

So you started a software company aimed at this problem, not an auditing firm and not a consulting company. How are you solving this via the magic of writing code? It's, you know, just connecting directly where the evidence lives. So for AWS, I actually tried to do this in a non-software way prior when I was just a typical auditor. And I was just asking our clients to provision us cross-account access to go in their environment with some security permissions to get evidence directly. And that didn't pass the sniff test at my consulting firm, even though some of the clients were open to it. But we built software to go out to the tools where the evidence directly lives and continuously

assess the environment. So that's AWS, that's GitHub, that's Jira, that's all of the different tools where you normally collect this evidence. And instead of having to prove to auditors in a very manual fashion by grabbing screenshots, you just simply connect using APIs to get the evidence directly from the source, which is more technically accurate. The way that auditing has been done in the past is using sampling methodologies and all these other outdated things. But that doesn't really assess if all of your data stores are configured in the right way.

If you're actually backing up your data, it's me randomly picking one and saying, yes, you're good to go. So we connect directly where the evidence lives and hopefully get to a point where when you get a SOC 2 report, you know that a tool checked it. So you know that the tool went out and looked at every single data store, or they went out and looked at every single EC2 instance or security group or whatever it may be. And it wasn't dependent on how the auditor felt that day. This episode is sponsored in part by Chaos Search. As basically everyone knows, trying to do log analytics at scale with an elk stack is expensive, unstable, time-sucking,

demeaning, and just basically all around horrible. So why are you still doing it, or even thinking about it, when there's Chaos Search? Chaos Search is a fully managed, scalable log analysis service that lets you add new workloads in minutes and easily retain weeks, months, or years of data. With Chaos Search, you store, connect, and analyze, and you're done. The data lives and stays within your S3 buckets, which means no managing servers, no data movement, and you can save up to 80% versus running an ELK stack the old-fashioned way. It's why companies like Equifax, HubSpot, Klarna, AlertLogic, and many more have all turned to Chaos Search. So if you're tired of

your ELK stack falling over before it suffers, or of having your log analytics data retention squeezed by the cost, then try Chaos Search today and tell them I sent you. To learn more, visit chaossearch.io. That sounds like it is almost too good to be true. And at first, my immediate response is, this is amazing, followed immediately by that transitioning into anger that, this is amazing, followed immediately by that transitioning into anger that, why isn't this a native thing that everyone offers? I mean, to that end, AWS announced Audit Manager recently, which I haven't had the opportunity to dive into in any deep sense yet, because it's still brand new, and they decided to release it alongside

15,000 other things. But does that start getting a little bit closer to something companies need? Or is it a typical day one first release of an Amazon service where, well, at least we know the direction you're heading in. We'll check back in two years. Exactly. It's the day one Amazon service release where,

okay, AWS is getting into the audit space. That's good to know. But right now at its core, that AWS service, it's just not usable for audits for several reasons. One, auditors cannot read the outputs of the information from Audit Manager. And it goes back to the earlier point where you can't automate compliance, you can't fix compliance if the auditors can't use the information. Because then they're going to go back to asking dumb questions and dumb evidence requests if they don't understand the information coming out of it. And it's just because of the output right now is a dump of JSON, essentially, in a Word document for some strange reason. Okay, that is the perfect example right there of two worlds colliding. It's like, well,

we're going to put JSON out of it because that's the language developers speak. What do auditors prefer? I don't know, Microsoft Word? Okay, sounds good. Even Microsoft Excel is a better answer than that. And that is just, okay, that is just Looney Tunes awful. Yep. Yeah, exactly. And that's one problem. The other problem is audit manager requires a compliance manager. If we think about that tool, you know, developer is not going to use audit manager. It's going to be somebody responsible for compliance. It requires them to go manually select every service that their company's using. A compliance manager, one, doesn't even know what the services are. They have no clue what some of these services are. Two, how are they going to know if you're using

Lambda randomly somewhere or a systems manager randomly somewhere or Elastic Beanstalks in one account or one region, config here, config. They have to just go through and manually. And I'm like, well, that doesn't make any sense because AWS knows what services you're using. Why not just already have those selected and you pull those in scope? So the chances of something being excluded are extremely high because it's a really manual process for users to decide what are they actually assessing. And then lastly, the frameworks need a lot of work. Auditing is complex because there's standards and regulations and all of that.

And there's just a gap between what AWS has listed as a service that addresses a particular control that there was a few times where I looked at Audit Manager and I had no clue what they were mapping to and why they were mapping. So it's a typical day one service. It has some gaps, but I like the direction it's going. I like the idea that an organization can go into their AWS console, hit to a dashboard and say, am I meeting SOC 2 or am

I meeting PCI? I feel like this is a long time coming. I think you probably could have done it with Security Hub with less automation. You have to do some manual uploads there, but long answer to say has a long way to go there, Corey. I heard a couple of horror stories of, oh my God, it's charging me $300 a day and I can't turn it off when it first launched. I assume that's been fixed by now because the screaming has stopped. I have to assume it was, but it was gnarly

and surprising people with bills and surprising people with things labeled audit is never a great plan. Right, yeah. The pricing was a little ridiculous as well, and I didn't really understand the pricing model, but that's typical of a new AWS service. I never really understand. That's why I'm glad that you exist, because I'm always confused at first about why things cost so much, but then if you give it some time, it starts to make a little bit more sense. Exactly. The first time you see a new pricing dimension, it's novel and exciting and more than a little scary and you dive into it,

but then it's just pattern recognition. It's, oh, it's one of these things again. Great. It's why it lends itself to a consulting story. So you were in the army for a while. And as you mentioned, you got tired of sleeping on the ground, so you went into corporate life, and you were at a national cybersecurity professional

services firm for a while. What was it that finally made you, I guess, snap, for lack of a better term? And I'm going to start my own thing, because in my case, it was, well, okay, I get fired an awful lot. Maybe I should try hanging out my own shingle because I really don't have another great option. I don't get the sense, given your resume and pedigree, that that was your situation. Not quite. I surprisingly don't do well with authority.

So a little bit. I like to challenge things and question the norm often, which got me in trouble in the military, definitely got me in trouble in corporate life. But for me, it was, I wanted to change. I wanted to innovate. I saw, I just kept seeing that there was a problem with what we were doing and how we were doing it. And I didn't feel like I had the ability to innovate. Innovating in a professional services firm is updating a Google sheet or adding a new Google form and sending that off to a client. That's not really the innovation that I was looking to do.

And I realized that if I wanted to create something that was going to solve this problem, I could go join one of the many startups out there that are out there trying to solve this problem, or I could just try to go do it myself and leverage my experience. And two worlds collided as far as timing and opportunity where I financially was in a position to take a chance like this. And I had the knowledge that I finally think I needed to feel comfortable going out on my own and just made the decision. I'm a pretty decisive person. And I decided that I was going to do it and just went with it. And despite it, you know, going about this during the global pandemic, which presented its own challenges last year, getting this off the ground. But it was really, you know, I collected a bunch of knowledge. I realized maybe two and a half

years ago, actually, that I wanted to start my own business in this space. But I didn't know what I wanted to do just yet. I knew I wanted to do software. I didn't know how I wanted to do it. I didn't know how I was going to make it work. But I just decided to take my time and learn as much as I can. And once I felt like I acquired enough knowledge and there was really nothing else I could gain from not doing this on my own, and I knew I wasn't going to go join a startup to join them on this journey, it was a no-brainer just to pull the trigger. It seems to have worked out for you. I'm starting to see you folks crop up from time to time. Things seem to be going well. How big are you now? Yeah, we're doing well. We have a team of

seven of us now, which is crazy to think about because I remember when it was just me and my co-founder staring at each other on Zoom every day and wondering if there would ever be anybody else on these calls and talking to us. But it's going really well. We have early customers that are happy and that's all that I can ask for. And they're not just happy silently. They're being really public about being happy about the platform and about the process and just working with people that get it. And we're building a lot of momentum. I'm having a lot of fun on LinkedIn and doing a lot of marketing efforts there as well. So it's been going well.

It's been actually going better than expected, surprisingly, which I don't know. I'm a pretty optimistic entrepreneur and I thought things would go well, but it's much better than expected, which means I'm sleeping a lot less than I expected as well. Yeah, at some point when you find yourself on the startup train, it's one of those, oh yeah, that's right. My health is in the gutter. My relationships are starting to implode around me.

Balance is key. And I think that that is something that we don't talk about enough in this world. There are periodically horrible tweets about how you should wind up focusing on your company. It should be the all-consuming thing that drives you at all hours of the day. And you check, and oh, who made that observation on Twitter? Oh, it's a VC. And then you investigate the VC, and huh, you should only have one serious bet. It should be your

all-consuming passion, says someone who's invested in a wide variety of different companies all at the same time in the hopes that one of them succeeds. Huh. Almost like this person isn't taking the advice they're giving themselves and is incentivized to give that advice to others. Huh. How about that? And I know that's a cynical take, but it continues to annoy me when I see it. Where do you stand on the balance side of the equation? Yeah, I think balance is key.

I work a lot, but I rest a lot too. And I spend, I really hold my mornings as my kind of sacred place. And I spend my mornings meditating, doing yoga, working out, and really just giving back to myself. And I encourage my team to do the same. And we don't just encourage it from just like, hey, you guys should do this. But I talk to my team a lot about not taking ourselves too seriously. It's our number one core value. It's why our slogan is make compliance suck less, because it's really my military background. We're not being shot at. We're sleeping at home

every night. And while compliance and cybersecurity, it's really important and we're protecting really important things. It's not that serious to go all in and to not have balance and not to take time off, not to relax. I mean, a part of what we do at BiteCheck is we have a 10% rule, which means 10% of the week, I encourage my team to spend it on themselves, whether that's doing meditation, going to take a nap. And these are work hours, you know, go out, play golf. I spent my 10% this morning playing golf during work hours. And I encourage all my team every single week, spend four hours dedicated to yourself because there's important and it's not your job. And that's the thing. We hire a lot of veterans here because of my veteran background. And I tell all the vets that come here, when you're in the military, your job, your rank and your day-to-day work is your identity. It's who you are. You're a Marine

or you're a soldier, you're a sailor, you're an airman. If that's a bad choice that you made, sorry for all my Air Force guys. Well, there's another the spaceman story as well, I'm told, but I don't know if they call them spacemen or not. But remember, there's a new branch to consider. And we can't forget the Coast Guard either. If they don't call themselves spaceman, that is their name from now on. We just made it today. Like if I ever meet somebody in the Space Force, they're calling them the spaceman. That is amazing. But I tell our interns that we bring from the military, like you have to strip that away. You have to become an individual because bite check is not your identity and it won't be your identity. And bite check's not my identity. It's something that I'm

doing and I'm optimistic that it's going to work out and I really hope that it does. But if it doesn't, I'm going to be all right. My team's going to be all right and we're going to all continue to go on. And we just try to live that out every day because there's so many more important things going on in this world other than cybersecurity compliance. So we really shouldn't take ourselves too seriously. And that advice of just grinding it out and that should be your only focus, that's only a recipe for disaster, in my opinion. AJ, thank you so much for taking the time to speak with me. If people want to hear more about what you have to say, where can they find you?

They can find me on LinkedIn. That's my one spot that I'm currently on. I am going to pop on Twitter here pretty soon. I don't know when, but probably in the next few weeks or so. I've been encouraged by a lot of folks to join the tech community on Twitter, so I'll be there soon. But right now, they can find me on LinkedIn. I give four hours back a week to mentoring, so if you hear this and you want to reach out, you want to chat with me, send me a message and I will send you a link to find time on my calendar to meet. I spend four hours every Friday mentoring. So I'm open to chat and help anyone. And when you see me on LinkedIn, you'll see me talking about diversity in cybersecurity, because I think the really the only way you can solve the cybersecurity skills shortage is by hiring more diverse individuals.

So come find me there, you know, engage with me, talk to me. I'm a very open person and I like to meet new people and that's where you can find me. Excellent. And we'll of course throw a link to your LinkedIn profile in the show notes. Thank you so much for taking the time to speak with me. It's really appreciated. Yeah, definitely.

Thank you, Corey. This is kind of like a dream come true to be on this podcast that I've listened to a lot and talk about something that I'm passionate about. So thanks for the opportunity. AJ Aon, CEO and co-founder of ByteCheck. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment that's embedded inside of a Word document.

If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble