 I've already turned that one on now you're fine yeah that would be great please I'm going to see how it's going to be. It's alright, you can come and say hi. Oh, okay. Carlton, how are you people type people? Uh, there's a BDI, I'm going to say hi. BDI? Alright, BDI, nice, nice. Yeah, BDI, it's a market. Actually, you know, I think it'd be great that we introduced everyone. Okay, yep. Yeah, we can do that. Actually, watch them over here Carlton, and look at the camera. And so, today, in fact, Dr. Miller, why don't you come in as well? And then you can speak and introduce everyone, sure. Found it, like, come on, come in. No, I am suggesting come in. So actually, yeah, can you see anyone? Yeah. Go ahead and introduce yourself and tell them we're at and what we're doing and what's going on today. Alright, hi everyone, welcome. I'm Dr. Miller, I'm the director of the Cyber Bites Academy. We are here at the ACL's grand opening, the American Cyber League. Welcome. Yes, and obviously, you guys know me, Eric Coff, your host of the O'Connor Giants podcast. And today actually is a special day. We had something else planned, but we pivoted. At the entrepreneurs, we are the small business innovators that we are. And what's even more incredible is that earlier today when I was setting up, I got a chance to actually meet Carlton and I said to him, I said, I promise you, we're going to probably use your company and talk to you about some kind of way. And now today, we actually decided we're just going to do a live podcast interview with him where we feature his company because as I was discovering and him setting up his slide presentation behind us, he's actually an 8A small business. He's a veteran on small business. And he recently became certified on a GSA IT 70 schedule. So a lot of good stuff to talk about. Stuff that we talk about on our show day in and day out. And so we definitely, I thought it'd be a great opportunity to give you an opportunity to meet their company, listen to the company, learn a little bit about what they do. And he can explain more because again, you know, I'm not a techie guy. So take it away, sir. Absolutely. So thanks for the introduction. I want to thank y'all for attending a lot of podcasts as well as those that we have here present with us today. As a state, my name is Carlton Harris. I'm the Chief Technology Officer for Intend Enterprise Solutions. We currently specialize in advanced technologies in products and services where we actually was birthed out of the cybersecurity arena. Whenever you look at myself, the CEO, the CIO, everyone that took part in the company, we very much have a very strong cyber background where we did everything from your network security all the way up to being a federal CISO. Currently, we just changed our, we just started doing some research and development on 5G, AI, and different things of that nature as well as business transformation services. And one of the things that we mentioned before everyone got here and foreheaded this audience in the room as it's now growing. You know, we were talking about you were having the doors shut in on your business and people kept telling you no. Can you tell us a little bit about that story? Yeah, absolutely. So as an entrepreneur, we're really starting off in the Gulf kind of space getting out there, knocking on doors, trying to find business. We commonly hear no. Being subject matter experts, one of the things that we always have gone forth and do is knock on the door, hey, I'm an expert in SOC services or I'm an expert in cloud IT migration. But we're constantly hearing no only if you were SDVOSB, no only if you was on this contract, no only if you was in this place right here. So one of the things that we started picking up as we started shifting from SMEs to entrepreneurs in the Gulf kind of space is how do we eliminate no. So we went out, we got our A&A, got SDVOSB certified and we just find as many ways to alleviate no. Another strong way that we alleviate no is through partnerships with other small businesses. Because as the introduction I did earlier for myself and as well as my co-founders, for example, we're all men. So one of the notes that we hear is, no, we're looking for a woman on a small business. Well, we have a partner for that. We have someone that we're able to team with. We always, we're very strong with hey, regardless if our services are alike or what it is that we're doing, how do we team together in order to knock on those doors and alleviate no and get some business towards a small business or anything. Now, another thing that we mentioned was that you're a technical person. And you said you had to actually start learning the business side and what it's like to learn the business. And you spent several years trying to do that. Yes, yes. And so we were incorporating in 2012, but always like I say founded in 2016, where that's where we really decided to put our head down and really go out. One of the hardest things that we had to get through is that it's now always the technical solution that a enterprise is looking for, our technical solution that's going to get you in the door. Because the people who's trying to solve the problems are not really technical people. They're usually not on the technical side. So you have to, hey, this is how it affects your mission. This is how it affects your business operations. And this is how we're going to support that. So it has been like the initial onset was a initial struggle of figuring that out. Like if I went into an organization and like, hey, I need an incident response, for example, I would come in and I'm putting up this giant, like, hey, here's the ultimate best way to do it. But then I'm shooting $10 million over their budget or something like that. And now they're not taking those small agile steps to really become insecure because I came in with this subject matter expert mindset, this type of business mindset. Nice. And then what brings us here today? So one of the things that brought us here today is actually the Cyberbikes Foundation. They're a grand opening of the American Cyber League. We met with the Cyberbikes Foundation a few months ago and really started some good conversations with them and telling them on roadmap where we're going, how we're bringing in those effects capabilities. And we've very much seen a lot of synergy between how we're able to work with them in order to take a service to the warfire, to mission in order to solve complex problems. They have a great facility here where upstairs on the second floor, there's actually starting a software factory where they're doing DevSecOps processes trying to answer to some of those problems. We've been known across on the federal civilian side to answer some of those complex problems. So we thought that it would be awesome if we had came in today in order to actually present how we answer those problems in the DevSecOps process with some secure containerization. And today I got with me one of our engineers, Mike Stacey, who's going to be presenting actually on secure containerization and how you secure the environment. So as I turn it over to Mike, one of the things I'm just going to touch on real quick is one of the things that we try to do within our DevSecOps processes is shift more to the left with those processes, bringing security operations and your developers together as you all know about DevSecOps. That's implementing a cohesive environment where cybersecurity isn't trying to be a blocker. We're really here to enable operations and ensure that those applications that you're putting off in front of you're out into the public that they're secured to a way that your mission won't stop. So with that, I'm going to give it to Mike. Perfect. All right. Thanks Carlton. Appreciate it. All right, so what I'm going to pick up real quick is we're going to do kind of a high-level talk-through of the DevSecOps pipeline. This might be something you guys are already familiar with. It might be something that you're not. So I'm going to kind of talk through each step at that high level and then we're going to talk about the containers play a role in this. And I'm going to take it one step further and kind of start to expose a lot of the security gaps that come with implementing something like this into your environment. And the best part is we're going to talk about how to fix those security gaps so that you can absolutely use a container environment. So theoretically you may have already made the decision to go ahead and start containerizing your applications, right? There's a lot of really strong reasons to do that. One of them is rapid deployment, patching and scalability. DevSecOps works seamlessly into this DevOps pipeline flow and allows you to spin up versions of your applications with near on-demand availability. You get portability across your operating systems and your hardware platforms. There's a shared kernel involved, so you're not limited necessarily to the version of the OS that you're running or the hardware specs that you're trying to deploy to. Same thing that supports an agile DevOps environment. We're not really worried so much about releases that are happening in these like four month cycles or whatever. We're looking at turning out newest and latest versions of something maybe every couple weeks or even days even. Sometimes even shorter time spans. It's cost effective, right? We're minimizing our resources. We're minimizing our overhead by not being so reliant on independent and isolated virtual machines to host specific applications. Instead we have a sort of a family of applications sitting on specifically managed nodes that lower our resources overall. And one of the biggest benefits of this is how it fits into this DevOps pipeline. So I'll kind of talk through it briefly and show you what the lifecycle of an application might look like. I've added some tools up here that you may or may not be familiar with. A lot of these are kind of the biggest like industry standard players. So they might kind of help connecting your mind like, oh yeah, this stage right here in the build process. I know what that is because I use this tool in our environment. So we've got our planning stage. The talking and the specific weighing out of what your approach is going to be done. A lot of documentation and whatnot. Inside of code is where you're compiling your actual custom applications. Moving over into build, you have your utilizing jacons. Your pipeline is starting to take over. You're compiling everything with a base image and whatnot. You're finally testing things for performance over here. You're releasing things to the artifactory. You're adding dependencies. You're deploying it to production and the end user or the customer is able to reach your application and then you're monitoring over here in the end. So you've got stuff out here that's good to go but you want to make sure that everything is above board operating as it's supposed to be. So you're realizing various tools to check on this. And even though it appears linearly here, the reality is this is actually the infinity loop that you're seeing back here because you're not sort of dropping back into the story depending on how you need it. It's a continuous cycle. So as soon as you hit operate, at some point in your timeline, you're going to be right back here pushing things down the way. And you might think, I don't have something that looks like this just yet. This is a lot more steps than what we're doing right now to get our applications out there. But the spirit of DevOps right now is that most of this becomes automated. And in a sense, the more you automate this, it kind of becomes like a conveyor belt. So once you notice something right here in operate, you're monitoring your environment. I see a change that I need to make. You're planning out what this change looks like. You're dropping it, and then it's just chugging through the conveyor belt. And all you're doing is you're continuously spitting out the latest and greatest version of whatever it is you're trying to produce. So DevOps pipeline isn't necessarily trying to make your cycle harder by adding steps to it. On the contrary, it's really trying to make things easier by automating as much of that as possible, but in a very specific and directed way. And containers, they only do, they only enhance that, right? Once you kind of implement containers in here, you kind of allow the DevOps pipeline to be fully realized. And I'm going to show you why on this next slide. So I'll talk about the container environment just briefly. Again, if you're familiar with it, that's awesome. I'm going to just talk through the different components, though. Let's see. Starting with your Paz IaaS. Is this your platform as a service or your infrastructure as a service? Essentially, we can replace this with maybe it's like your Google Cloud provider, your Azure, AWS, whatever this is. This is going to be the platform that you're building on right here. Your orchestrator is something like Kubernetes, right? Your master node. Anytime you see node, you can kind of substitute in your mind VM just for simplicity. Node can be a variety of things. It can be your host. You can kind of use these terms interchangeably, depending on the setup. But just for the sake of understanding the diagram, we'll call the nodes and think about this on VMs. Your orchestrator is Kubernetes, right? It's managing all of your infrastructure that your containers are sitting on top of. And then on there, you have nodes that spin up accordingly. So all right, let's think about this. We've got an application right here. Maybe it's a web app. Maybe it's got a database that it connects to. And maybe there's some other tool in here that's monitoring it, who knows, right? This node is fun up because it's like, all right, I only need this many compute resources. The orchestrator knows this. All right, let's deploy these containers out here. This host itself, this node is also a VM. It's got the compute resources inside of your cloud provider. It's got the host OS, whatever OS you choose to build your application on top of. It's got the runtime, which is actually the engine that manages all of your containers and pulls from your registry. And then it has your containers. These are the things that were built right back here on this step. So everything that you did here to make sure that your application is great and available for its end users and its customers is sitting right here in these blue containers. And then the orchestrator's coming up and it's spinning up node two because it says, hey, all right, well, this is great. Our application is running really, really good because we started utilizing the DevOps pipeline to its full potential. So let's spin up another node because traffic is coming in like crazy. Everybody's using our app. This is awesome. Business is moving. We got node number two. All right, node number three is now up because the same thing. And node number four is now up because we have new applications that we're going to introduce to the environment. We've got our registry off to the side over here. This is where we're doing our image pools into our containers. The registry could exist inside of your boundary, whether it's on-prem or in the cloud or whatever, but they can also exist as SaaS offerings that you utilize. And then your persistent storage, which might exist inside of your cloud provider as well, that containers might need to access from time to time. And so that's the container environment at a glance. Now that you know what the new pieces are, it might look kind of familiar. Some parts of it might look familiar to what you're already using in a regular virtualized setup. But some of it shouldn't stand out. Some of it should look a little bit different. And anytime you introduce something new into your environment, there's certainly security questions that arise, right? So let's take it piece by piece. Let's look at the container image first. Okay. Our container image has a number of issues. Let's just kind of address these top ones first. Container image is a static archive file. So once you've pushed that container out, right, think back to the pipeline. We hit that monitoring stage. The application is ready. It's out here, and it's inside of production. The idea behind the container is it's supposed to be immutable, which means it's unchanging. You've decided, hey, this is the best version of this thing. Here we go. It's ready. We're not messing with it, right? And if you are going to mess with it, we're going right back to the pipeline and run it through that cycle. Of course, there's a question around that. If it's unchanging, and it's just sitting out here and it's aging, theoretically, it will accrue security vulnerabilities after time. I mean, we're already doing vulnerability standing in our environment right now. And you know how, if resources age for a while, especially when you have fun past, they're going to have critical security updates that are missing. So that's what happens, right? Your container, no matter how long the life cycle is, at some point it is prone to accrue in some kind of vulnerability. And again, you're not. So here's the good one, right? So no in-the-field patching. So due to the immutable state, you're not showing into your container you're not making any changes like that. That's going to disrupt the idea behind having a container in that static frame. So potentially you could have, like, all right, great. These applications are going great and we'll need to update the source code because there's no bugs. But your base OS is now accruing all kinds of potential issues. So the vulnerabilities aren't still happening, right? Embedded secrets. You might do something. You might be developing your container just out of ease and put, like, all right, we'll put the username and password in there in an open deal. We'll put, like, a key in there just because it's easy and stuff. But your images are going to be one of, like, the most sought-after resources in your environment, especially when someone's working to do something malicious inside of this environment. So embedded secrets are unfortunately more common than you'd like to think and it's kind of an often overlooked piece because anyone who's actually able to obtain your container image really can probably parse through the framework there and grab the secrets. If they're willing to get to this level, that shouldn't be an issue. Hidden malware is also, like, actually a pretty tangible concern. You're pulling your base image from your container from, you know, who knows where. Hopefully trusted repositories, hopefully trusted sources. But that's not always the case, right? Maybe there's somebody out there on GitHub who's toting the best version of the specific OS and you grab it because it fits a specific need. But, you know, you don't necessarily know what's in there and it could be preloaded with all kinds of hidden malware. Especially if, in regards to, a targeted attack, consider somebody who's actually, like, maybe got a decent high profile mission objective and they actually have adversaries who are really willing to invest the time and the resources to say, hey, I know kind of what their goals are and I know, like, how they're utilizing their similar resources so I can actually craft an image based on something they need and almost socially engineer them to get them to deploy this thing. That kind of stuff is definitely not a non-essential software. That's another one, you know? You have your custom application but it's built on something that already exists. Maybe some type of organic sandwich. And so, non-essential software, of course, has already contained that because your application probably isn't going to be depending on every single piece of a component of the actual image itself. Now, these leftover components are just another potential attack avenue for somebody who's actually able to do that. And then, let's see. So let's start by talking about some of the solutions here. I realize I'm not able to get to every single one but let's start talking about how you can avoid these issues. Integrate security early. So this is probably one of the biggest ones. This points right back to our DevOps pipeline. Integrating security as early as pipeline as possible is definitely going to be the best move. We're talking about saying, hey, critical vulnerabilities aside of my production ready apps. Well, shifting this left all the way down here as early as possible helps to identify these things along before they ever actually want to get in production. You don't really want to be focusing all of your scanning remediation tactics out here. That's just going to slow down your availability. So moving left as far as possible, scanning frequently and scanning early is going to be best, right? Scanning your rocker while you're building it, scanning the image itself, scanning it after it's been compiled is definitely going to be your best move there. Establishing quality checks inside of the DevOps pipeline, right? So this is just talking about automating that process as much as you want to automate the DevOps pipeline and really make it that conveyor belt of churning out great application containers. You can establish thresholds along the way that says, hey, all right, we're dropping this image. It's ready to go. It's moving down the pipeline, ready to go. Oh, hold on a second. We just hit a threshold. This hasn't passed the index amount of checks, whatever it is, whatever you set the policy as, to prevent those insecure containers of actually going out to those. And then let's see, a continuous monitoring of an aging image, right? So ultimately the image is going to hit production, right? But you're not necessarily maybe using that same version of the OS anymore. You still want to securely monitor that one with constant scanning even though you can't catch everything. You'll catch everything as you're building it out, but it will still age when it's in production. So making sure that, even though you're starting it early, making sure you're still maintaining it as you reach the actual deployment phase. Avoid remote shelling into your containers for sure. This just obstructs the usability of the container. Validate your images, right? If you're pulling images from untrusted sources, I would avoid that in general, but you can scan the images once you get them and then use checks. Make sure the images that are deploying into your environment actually are validated with some sort of hash or check. And then secret managers, right? We talked about avoiding using passwords, hash stuff inside of your container image. There's a variety of ways you can do this. Typically your cloud provider will offer some sort of a secret manager for you. As well as Kubernetes, the orchestrator itself has a secret manager that you can leverage to pull those secrets securely instead of having them embedded. And then conduct malware scans, right? This is another one that's sort of a given, but the problem itself is often overlooked. Providing just another depth of scanning, not just on vulnerabilities, but actually signature based malware scans. Let me ask you a question. What's a secret manager? I know everyone else knows that. I don't know a secret manager. Yeah, so it's kind of exactly what it sounds like. It's like, it's literally just like a predefined area that's going to handle all of the secrets that otherwise would be stored in here and then just dipping them out on like a need-to basis. So instead of saying, hey, our secrets are embedded in the container, which is something that's going to, where the application is that can be accessed. This sits way back on our infrastructure stack and it only called upon as needed with permissions by the containers. And that could sit way down here in the cloud, that could be managed by the orchestrator itself. But, that's helpful. No. Y'all got it? Y'all got it? I think they got it. It's quite clear. It's quite clear. It's a serious screenshot there. I had to learn about the hood. Alright, let's talk about the registry for a second. So the registry is kind of a, it's another one that, again, it depends on where it sits in your boundary, right? This could be inside of your cloud environment. This could not be. This could be something that you're using that's a size offering, right? But, regardless of how it's being utilized, this is kind of a honeypot. This is something that has very, like, business critical resources in it. Not only because of whatever is compiled inside of the image that's ready to go, but also because of where it sits in your pipeline of that automated process. So somebody who really gets the wheel of your registry could theoretically wreak a lot of havoc if they're willing to drop something out into your pipeline that you absolutely do not want out there. And so, that would result in insecure connections, right? If, say, this sits out here somewhere in Sassland and you've got your cloud platform right here, if this is an insecure connection, it is vulnerable of whatever the just exposed network traffic concerns that you would have, regardless of whether it was a containerized environment or not. Those kind of things still exist in this area. But now we're just introducing a new variable to the equation, because we're calling on a registry as well. Stale images is another kind of weird concern, right? Okay, so you're the dev team. You're constantly turning out new versions of this image, which is great. That's what you're supposed to be doing. Although, unfortunately, you're collecting a nice little pool of old images. So, all right, think about the dev box pipeline. You notice something over here. You're like, hey, this is an issue because we noticed a big missing critical security update. Let's come back here. Let's either download a new version of the OS or we'll manually push the update and we'll rebuild and we'll shove it out the door and it's good to go. That being said, inside of your registry is still sending that old one. And it's sending even older than that. It's willing to do more security updates and more security updates, because you're not changing the single container. You're constantly deploying something there. So, in here you have a nice little pool of images just absolutely riddled with missing security patches that are just begging to be pushed down the pipeline now in the requirement. And then insufficient authorization and authentication, right? So, this revolves around account control. Not giving somebody unnecessary scoping when it comes to their role, what they can access. Again, it being such kind of a highly sensitive aspect of this whole environment, we want to make sure that those things are scoped accordingly. And then a lack of auditing for reuse tags. It can be we're talking about ease of use again. It's pretty common practice to see somebody just constantly tag something that's the latest and shove it out there. If you've got the latest, we're good. Push it out. That's not going to be great in the long run, especially when you're trying to trouble see things that are going on right now in our production environment. If everything is latest, then really nothing is. It's going to make auditing a headache down the road, for sure. All right, so how can we fix some of these problems? The simplest one can clip this channel, right? Any connections for dev tools, orchestrators, and container runtimes and clip that connection between your registry to that environment. There's really no reason not to. Automate the disposal of stale images. We said we had this little pool of this collection of bad images out of here. These are toxic and we don't want them. You can add a time trigger to them. Say, all right, these have been sitting on environment for two months. There's no way we keep a container alive in that version for two months. Just get rid of it. Just start developing it. You can apply policies that enforce unique version pools. All right, we're only pulling stuff into this environment based on the policy that defines that it has to look this way. It has to have this kind of a tag. This kind of unique, discreet identifier for it to come into the environment. Otherwise, it's not getting played at a point in the field. You can federate your IDP to utilize robust security controls. Think about the identity provider you're using right now. Maybe it's the one hosted by a cloud service provider. Maybe it's like a third party one. Maybe it's your on-prem AD. Whatever it is, you're probably treating it with quite a deal of granular security, right? You're implementing all kinds of stuff. Maybe it's like MFA, SSO, password enforcement and all that stuff. We'll federate your IDP to your registry, right? Just carry those controls through. Use those same accounts. That way you can still scope the access and have the strong control around it. And then really audit all of your read-write logs, especially your write logs to the registry for sure, but also your read logs. Push these to your SIN. Set up monitoring metrics around it. Keep a pretty close pulse on the activity that's going on in the registry. Alright. Let's chat about the orchestrator for a second. Let's see. Alright, so the orchestrator knows right here we talked about that earlier. This is essentially, this is the master node, the VM, the one that controls all the other ones. It's got a lot of responsibility for this architecture. You can see in the anatomy of containers it sits really well. And so exposing this or letting this get exploited really does kind of give you a lot of availability to go upward and take control of those resources. So unfound admin access, right? This just goes right back in the separation of duties and scoping appropriately. You definitely don't want to give people unnecessary access. Unnecessary access for a user is just kind of like a bait for somebody to come in and say, okay, great. Now that I have this, let me see how far I can go with this role. Oh, I can go everywhere. Okay, great. I'm messing with every single node now. You want to avoid mixed sensitivity workloads, right? You might again, you might just be deploying stuff out there because this is great. This is simple and convenient, but you know, let's go back to the first example actually. Think about the DevOps pipeline where I was showing you you might have like a front-end and a database and a monitoring tool. Okay, so let's say this front-end is your web application, right? This is where everybody is setting your customers, your users. This container is the back-end database, but it's got highly sensitive information in it that is being inputted by the customers. Well, you want to keep those things segmented, right? Like, theoretically, this orchestrator and the runtime itself is doing a pretty good job of allowing these containers to operate independently and to just be naturally segmented, but you can provide another level of segmentation to kind of help yourself sleep at night by separating them into different virtual networks. All these levels of segmentation help to sort of avoid the lateral movement that could come from somebody who is able to exploit them with your containers. The node itself, right? This orchestrator node again, we talked about just how sensitive it was and what kind of power you can wield if you take this thing over. So, hardening this master node is a really kind of a crucial way of making sure that everything above it does not become overexposed. And then making sure that exceptional access control is applied to the cluster admins. This goes hand in hand with your unbound admin access. But let's talk about a few ways real quick briefly to kind of address these security issues. Having a strong access model, these privilege and separated duties, we already talked about that for all of your users who are admins who are accessing this orchestrator. Have that layered authentication, MFA and SSL. But kind of like we were talking about with the registry, right? Implement these layered identity controls in order to prevent just like weak credentials from being able to expose something so it's very important. We talked about it, right? Separate your applications into their respective ENX by sensitivity. A little bit, this will come into planning. All right, what I like to do is I appreciate that. I wouldn't want to talk about the customers and the kind of people that are going to be using this and why they would need it. I think that would be very helpful for the audience here. What kind of companies need this service and why do they need it because that's kind of what we like to talk about. That's fair to everybody. Does that make sense? So basically you don't want to be a decision maker. I'm sorry. What's the picture? Oh, it's being recorded. So the type of company that would want to implement this would be organizations that want to modernize their on-plan to the cloud or let's say you were on the cloud you were running VMs, for example and you want to move to a more orchestrated type of environment using container-based such as Kubernetes such as OpenShift these are the type of customers that would want to use to be able to use this type of technology, right? This type of controls to protect your environment. So right now one of the clients is FEMA. FEMA is basically the national flood insurance program is currently using technology like these to be able to so for one let me back up a little bit. We were able to help them move from a 25-year-old mainframe where flood insurance were in issued 45 to 60 days to now flood insurance again issued in real time. So if you're living in a flood zone you don't actually get flood insurance from State Farm, USAA or any other organizations you get your flood insurance actually come from FEMA. FEMA is the one that provides flood insurance and if you live by a lake or flood zones, right? So with these guys we were able to help them implement OpenShift OpenShift 3 we're about to move to OpenShift 4 where we are using the containers that's embedded within OpenShift it's a immutable CIS OS it's a immutable OS that engineers are giving up to move to as we speak. So part of that is basically having for it to be immutable there's a certain configuration as Mike was talking about that must be implemented as you cannot have agents installed into the image so you have to have technology that can work agent-less into the industry so that you can get the necessary controls implemented as well as get the telemetry that you're looking for as an analyst to be able to see what's going on within the environment who's attacking you who's abusing their power as far as access control, who where traffic is coming from and so on and so forth. So the technology basically controls that need to be implemented it can be anybody that's using container-based OpenShift Kubernetes should definitely take a look whenever you go to Amazon for example you can build DPCs you definitely should look into these controls and make sure that these controls that you are implementing them and you are protecting your containers. So for example your containers have certain security features from the get go and using OpenShift or Kubernetes for example you can create configurations where you can walk in an environment where you can spin up your entire environment within a week. So if you want to get a virus your virus is basically staying there for a week instead of 60 days or 6 months before a malware is attacking or somebody who attacks you is attacking. So some of the configuration that is talking about is basically setting up your environment to be able to withstand the type of attack that would come from it on a container-based because these systems also have their own risk that comes with it, right? So you also have to look at understand the container platform and the type of controls that you need to that you need to put in it and what you need to remove that would not once you stand it up everybody won't have access to it so you have to restrict this access on the get go and you have to implement the controls to make sure that it's immune. Can I ask you a question? Does the government actually know they need this? So our government folks do know that they need this. Okay. So it sounds like to me you say it says have some controls already but then you've got to restrict access and some other things. Yes. So when they're writing stuff up you said they know they need this to go about achieving it. That's where it comes in, right? That's where it comes in, right? So within the group that we work with, the National Foundation program that we worked in FEMA for example I have to say that I have not worked with a... I have been in the federal government and I have been in the military I have never worked with a group of people that has done it, like they have. All of this is not possible without the client pushing this. They have to be that governance there. This is the first time that I worked with a group and the government to include, self included, who was a prior gov that has that mentality, hey, let's do the right thing for the environment. They do have the budget as well. So that helps. This is one of the this is the first time I see a government agency or government program dedicated to the security of the platform. And as well as outputting, not in the bleeding edge but outputting close to the bleeding edge as possible they're not waiting for things to 10 years later to implement it. If it's available it will help them to move to it and go and apply it. What other types of agencies need these services? Any agencies. All of them. All of the agencies need this. This is not just a single agency. This is all agency if you go on the cloud or if you have your own private cloud on site all agencies need to be able to implement these controls under OpenShift, under VMs under Kubernetes or cloud environment. They need to implement this. I see you said AWS is on there. On spring you had AWS? I talked about it. So it doesn't we're not AWS partners. It's not just a caveat. So it could be Azure, it could be or it could be SoftLayer regardless of what the cloud provider is. The technology set is similar. How you do networking may be a little bit different but the technology set is similar. If your engineers are good at it then you should be able to implement these controls. On outside you guys mentioned similarity. Can you explain that a little bit about that? That's connected. So similarity is a SaaS platform that allow us to provide a single pane of glass view to our clients. So it is our 24-7 Security Operations Center capability that we have built to be able to support our clients. That's similarity. So within Singularity we have SAM, we have machine learning, we have traffic analyzers, we have all type of endpoint protection, EDR within that platform to be able to support our clients regardless of where they are. We protect them online and offline. So regardless of where you are with your capabilities or with your environment we can protect that. So within Singularity as well we have the DevSecout that's also going through the federal process. So we've been going through the federal process for the last four months. We should be fully federal validated within the next 30 days hopefully. So the federal process is basically it's a security process that you go through to show the government that you are implementing all the necessary controls according to GSA and FedRAM that will help to protect government data. So that's what the federal process is and we're taking our Singularity platform which is 24x7 SAR analysis of a platform as well as the DevSecout we're probably the only one with all four capabilities in the DevSecout for security. We have the IAS interactive security tests. We have the DAS, the dynamic security tests such as Web Inspect we have the RAS Realtime security capability to protect your applications and we have SAS which is a source code analysis. We are the only one who has that and only one can be federal in the next 30 days so if you are going to do DevApps we have the full platform readily available we use infrastructure as code we can deploy it to any organization regardless of your code base if it's Java, if it's Python, if it's C++ we can deploy it within that environment and helps you have full visibility from this first time the engineer type the first line of code to production we can provide you the full visibility as to what you're supposed to do Can I ask you something? How did you get into this? Wow I'm sorry I had basic questions like this is over my head I got into this when I was in their army so I went in their army as a logistician and I went to since there was logistical school around me the next one I was in Fort Bragg they said if I were there born I didn't have to leave Fort Bragg so I was there born for the time in the military the nearest school was in Georgia Tech and I was going to be able to travel that far to be able to so I was fairly decent in math so I went to computer science and that's where basically where it starts developed the cyber security skills my first class in cyber security from a computer science program I said this is it this is it I did not want to be a developer any longer I definitely want to play in the cyber security side and from there I was able to basically go through all those security security categories there is from the firewall engineer, input engineer network security engineer to chief information security officer which is my last work in the federal government for the federal election commission I was a CISO there for four years anybody have questions if the agency has already how long has it taken if the agency has already had and they come to you how long will it take to start and finish and get them back to where they were so the question is if the agency has already hacked how long will it take to go from start and finish and get them back to where they were correct yeah it's kind of a loaded question because it depends on a whole lot of things it totally depends on the it's definitely a valid question but it depends on the type of attack the scope of it what would be the effect of the resources and all those kinds of things so far as the timeline goes there would be quite a bit of discovery that would have to go on initially in order to determine all the variables that are applied to the county's attack as well as that's including the remediation process as well there's one thing to identify the attack here's the vector, here's how they got in here's the resources they hit but if you want to talk about getting you know next here's your state now so to add a little bit to what Mike said like he said it all depends on the type of incident right so for us we have all the sensors and we have all the analysts as a 24-7 security operation center to be able to respond to it very quickly once it is detected so we have network sensors we have server sensors we have all types of sensors it has the type of capability so for us to comment if they did not know that they had it it is likely we'll probably be able to detect it within maybe an hour or two after installation after we bring them online to our platform and because we can monitor the traffic we can see where things are going we can provide a map we can see what the network base is we can see where the client base is we can see where if the traffic is coming from overseas if the traffic is coming from California we can see all that information so we can use that information to be able to deduce where exactly the attack is coming from if it's an attack and third hunter level 2, level 3 engineers analysts would be able to do a deep dive on the third hunting to be able to detect and analyze certain events to be able to detect if it's an actual incident or if it's just an event and if it's an actual incident of course we'll be implementing the incident response process and the recovery plane as well to be able to recover that asset or assets to their normal operating environment so if it's in the cloud and you're using OpenShift Kubernetes it could be a quick turnaround then it takes a little bit longer time because it's talking about physical assets that you have to change a little bit to add to that as well so the other half of that it depends on the government customers how they identify their FIPS 199 information right is it high, is it moderate, is it low what is the RTO or the recovery times for your critical assets what are my critical assets so we will work with the customer to identify those things to ensure that we're recovering those critical assets that are most important to the mission and working its way down to the non-critical assets and data and talk and I would say sometimes basically we want you to monitor that environment they probably not want you to eradicate eradicate the problem immediately they want to monitor to see what's going on in the network how they move what asset they're trying to get into they probably want to track it and some client will just say please get rid of it as quickly as possible so we'll follow that process and as Fred stated the most important assets will be taken care of first and then put on the line if you know my report just elaborate on your point and then I think your question was also specifically if something's already been compromised and then they reach out how long would it take to come in kind of implying that maybe they don't have security and prescription in place so that's definitely like a possible of course that happens all the time but the best answer to that solution is having something already in place because making that phone call to say hey come in here instead of a security sector to determine something that's already happened is feasible and obviously mitigate that before it ever occurs because it's really not a matter of if it happens it's really when it happens so if you want to avoid that when you play for the F you go ahead and set something up and then with our Singularity platform basically regardless of where you are anywhere if you're in country, if you're in Texas if you're in France basically our platform is built on the cloud to be able to support the climate and there's also cybersecurity policy and executive orders that they take federal governments have to implement these security solutions what it is that you implement and that you budget for is what's important but the solution is going to be the overall best to manage it I've got a question from someone here watching what is your plan of scale what is the capability to take the company data centers, cloud, Google etc. the actual physical assets like the CIA what is the plan what is the capability to take a company IT coming to the highest level of security aka data centers and cloud, Google etc to take somebody to the highest level of security it takes basically knowing what the scope of the work is everything that we do is what is the scope I can take you to the highest security that you can implement based on your budget right so and it's just happened we have a platform basically that was built to be budget friendly that's basically why, because I deal with a lot we deal a lot with smaller agencies that have not as much budget as a DOD type of environment so we have a platform to be able to take them from A to Z with a limited budget so for us basically we'll take understand what the requirement is what some of the payments are that they see within their environment what is it that they're not meeting what the requirement it could be compliance or it could be internal requirement and policies that they're not meeting what is that and then we come in and we can help them build the policy and the procedures behind it to make sure that they because security is not just the tools that you implement right it's the training of the people and as well the configuration of your devices your assets and as well as the policies that you implement and the procedures that you implement for your people to follow so security is not just the tools sets and basically we have the people on the back end the Q1, Q2, Q3 personnel to be able to provide from the first level of triage to the forensic analysis readily available to support but it's everybody comes together but the policies have to be in place so that everybody know what the policies are our team know what the policies are we automate a lot of them a lot of as much policies as we can to be to make sure that when we operate we always operate in the audit ready mode so the more we automate the more we don't have to worry about IG comes in and says oh all of a sudden everybody is running with their head cut off IG is here, IG is here, IG is here right so we operate with that frame of mind basically to always be audit ready so whenever somebody comes to audit we always have the reports the dashboards and so on so forth are created for management as well as for the auditors we can just say okay here's the access, auditor access go look at what you need to look at let us know if you have any questions we can take one more question I think that one is ready I think I put in but you answered a lot that I was looking towards the monitor and the training aspect which kind of spoke about that that you were going to copy that that will help out the business with that but since you're talking on another level this is a lot about government and you made a comment about people being one of the few who was easier to work with where others do have a big constraint although they also have a big need at the same time are we doing anything to one maybe get some awareness down to those who don't have the same budget approved I suppose they won't have the budget but you know how sometimes it just don't happen in that timeframe and how are you doing it across the different services so it's all going to be on the G-Wide we have systems ready to talk to each other so we'll go with that thank you for that so we work with any organization so our goal is basically to help organization implement their appropriate security capabilities along with the personnel to be able to protect the assets so regardless of what the budget is we work with them we understand that every program has the funding to be able to implement the top match security capabilities. And that's where we build Singularity. It's basically to be able to provide that to programs that have smaller budget and also program that doesn't clearly know what they're looking for, right? Because a lot of the programs, regardless if they may have an ISO on the government side, this is not a criticism, but the ISO may not be trained. It's just assigned as their role. So they're not trained as an ISO, so they're not security engineers, but they have that role. So we work with them to basically teach them. We have an account manager who is a technical expert that works with them to make sure that we first identify the assets and be able to protect each one of these assets cost-effectively. Our product is extremely cost-effective. What did you want to see? Go for it. Yeah, I thought that if we had any, it's like a curriculum for, it's like companies to mitigate, like, it's the human accident, basically, like the human vulnerabilities that we have. I think we're talking about the human training, the human training as far as security awareness. So we provide, for some of our clients, we go in and provide live human training for CBT type of training, computer-based trainings. We have partners that we work with that for the convenience of our clients. So a lot of our partners, we work with them for the convenience of our clients. So the training aspect that you're talking about where our folks, the companies folks or our clients folks can go to training. We work with some of these people for the convenience of our client. We provide it to our clients at no cost. Let's say we work with, I don't want to announce what I didn't get. I did not get the permission for that. So if I work with a client and the client says, hey, I need somebody to come and provide us cybersecurity awareness training. We have people that either they keep failing the training, they keep clicking on something that's supposed to click on, they keep going places that they're not supposed to go to. Can you come in and provide security awareness training? So regardless if it's part of the contract, we will go and provide that training. We will go and work with them and provide that training. That's something that, it's not that we pride ourselves, but because it's also helpful, right? Because the less things they click on, the less places that they go into that would bring issues to their environment, the better it is for us. So even if it's not part of our work, we make sure that we work with them and we provide that training. So as far as CBT training, most agencies does have that training in place already. But if they need that to be augmented by somebody coming to speak with their users, we provide that service. We also provide, part of our service that we provide is a phishing exercise to be able to identify the witness and the human part, to identify the people that's going to click and go everywhere that a length takes them, for example, to be able to provide them immediate training. And that's why we work out partners for this type of phishing type of exercise. And most of the time this comes at no cost. Alright, thank you. Alright, best way to reach you guys. The best way to reach us is by going to our website, www.eecomputing.com. Or you can reach our toll-free number, which is 833-720-7770. You can send us an email from the website, you can reach out from the website, and we will be able to get you within 24 hours. Alright, and the type of companies and organizations you like working with? The type of organization that we like working with, as a company that provides cybersecurity services, we like to work with any company that will welcome us into their family. So we really create a great partnership with each one of our clients. We really, really do believe in working with them directly and create that partnership that's back and forth. So for each one of our clients, we meet with them on a weekly basis, at least weekly, to basically show them the vulnerabilities that we're able to detect to 72 hours scanning and other third analysis capabilities that we have to detect vulnerabilities in their environments. And as well as to be able to show them opportunities for improvement. So we usually, at least on a weekly basis, we'll have at least an hour with them to basically work them through what we see, what's going on in their environment. The weaknesses as far as the human is concerned, to be able to show them the security posture in general. How do you like the lawyer that bills for the hour? Say it again? Do you like the lawyer? You know, when they call you, you get a bill for that call. I want to check it out, you have a good invoice. Do you like that guy? No, no, we're not those folks. That's a good question. Not at all, not at all. We did not charge our clients for calling us. I mean, when we meet in partnership with our clients, we truly mean that. If your client called us, again, if they called us five hours, we would not charge them additional hours for calling us, trying to work on the issues. You hired us to do that anyway. So why would we charge you for more of that? So we don't charge our clients. Everyone I just came in. This is so touching. This is the man. Tell these wonderful people. Welcome. I'm Dr. Miller. Again, I'm the director of the Cyber Bites Academy. So we do training here with A plus. Help people get certification A plus, net plus, security plus. Also working on SAT as well. So we want to also get the youth in here as well. I'm just delighted that we're able to host an event like this and bring people in. So give everybody a hand again, Carl. We thank all of you for the event. Pleasure meeting all of you. Thank you. What's the next step? So, I mean, out of this in terms of what we're doing. So I know my people. Do I have to take the next one over there? Yeah, we can. How long is it? What's next? I mean, I don't know. So, I mean, my question for you is, how do I get it? When I am here, I can sit in the corner. You sit in the corner. Or work it out in the distance. I was just ready. Yeah. You've got a still paper. Yeah, because otherwise, then I'd have to sit in the corner. I would say just leave it here. I won't do it in here. Because the problem with these computers, when I sit in the corner, whatever you have it on. Yeah. I'll give you the information. All right. So the first class. That's so funny. All right. Five minutes. Five minutes. Five minutes. Five minutes. Five minutes. Five minutes. Five minutes. Yes, sir. Yes, sir. We areса. Well, I appreciate it. The sir. Um, exactly. I hope you got an attitude and make sure you're doing what you're doing and that it ends up in your pocket and your family pocket. That is important. Absolutely. You don't like this right? Yes sir. So that's why we don't use social media. I use social media. We're on the same page. Alright. That's fine. This is my brother. You think you're not social media? I got social media. I got social media. I got social media. I got social media. I don't need social media. We're not connected or in a hot field. I know that for you. I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm