Okay, cool. We're recording now and yeah, we're going to have a talk today on understanding the CNCF security landscape. Hi, my name is not Mike Coleman. I'll be delivering on behalf of Mike as he's not feeling well today. My name is Nigel Douglas, but all the content put together today was by Mike Coleman. So I certainly suggest reaching out if you have any questions. So just about Mike himself. Yeah, he's my colleague. We work in the same team developed for advocacy here at Cystic, and we're working directly on the Project Falco. And Mike has a lot of experience in this cloud security landscape, worked on different projects within the space. And you can certainly catch him at that tag Mike G Coleman. It's pretty much the same username on everything. So for the agenda today, we're going to look at what makes cloud native different. I think for some people are still moving into that. Cloud native space and just need a rundown on what cloud native means exactly. Once we understand what cloud native is, we want to look at the existing landscape, the CNCF who are pretty much the overseers of everything cloud native. And what I mean by that is all these open source projects that kind of get brought into the cloud native computing foundation. They certainly do the oversight for that. So nearly all the projects we're going to talk about today are under the oversight of the CNCF. And as such, they have a landscape view of all the projects that are under that underside. So for that, we'll then talk about what CNAP means. So again, for a lot of people's CNAP is a new terminology. When we think about these industry analysts, the likes of Gartner, they define these acronyms, CWPP, CIEM, CSPM, CNAP. They don't do it deliberately to confuse us. They do it actually to consolidate technologies. So what I mean by that is, you know, we could all as software vendors have different definitions of what you need as an end user or consumer to solve industry problems. But since they're the analysts, they've gathered all this data. They collectively say, look, a CNAP is the better choice because it covers the wide range of issues. It addresses those issues, but it does it in a consolidated forms, which should be more affordable since you're buying a single platform. So what we're going to talk about today is is it possible to gather those open source technologies that are under the oversight of CNCF and consolidate into something that resembles a CNAP capability or platform. Now as a disclaimer, you know, for this talk, we're not exactly saying we're going to provide a supported CNAP platform. We're just covering whether the technologies can address the problems or pain points that were defined within that CNAP platform. Now, the technologies themselves are going to fall into different pockets. That makes sense. When we talk about these analysts, where, especially as Kubernetes, the project evolves as cloud-name technologies evolve. Originally, you'd have something like CWPP evolves and we see CDR, then we're seeing CNAP. So by definition, some technologies may fall into CWPP and CDR or they might be Kim, but also possibly CSPM. We'll talk about all that in a while. So it's just important not to hold us directly accountable for where projects may fall into more than one category.  A lot of the CNAP platforms, SISTIC included, are going to use an amalgamation of these different technologies. So in SISTIC's case, we will have technologies like OPA, for policy enforcement, we have Falco for real-time detection. We have even, I'm not sure how we achieve it, but we certainly have network policy generation. So I don't know if we're interacting with the CNI anyway in Kubernetes, the network interface to achieve that. So let's get started. So what is cloud-native? Now, cloud-native, it doesn't mean just the cloud platform, it's beyond the cloud platform. So we're talking more as the applications, so basically non-monolithic applications. So I'll go back again. What is a monolithic application? Monoliths are generally speaking, they're the old way of developing applications. So you had this rather large application, it resided on a physical server or virtual machine. And it was clunky.  You know, it was just the way it used to be, we used to develop applications. Now applications are a bit more resilient. The idea is what we call cloud-native, they're designed to work well in the cloud. So they're all containerized. So compartmentalized into those different sections where you have your front end, you have your back end, and they all can be updated seamlessly. These quick updates, it's fantastic system cloud-native. And how are cloud-native applications achievable? Well, we talk around technology such as Docker for the containers, we talk about Kubernetes for orchestrating those containers. All of this is cloud-native. So what we're talking about cloud-native, essentially we're not talking about just the cloud platform, we're talking about everything in the delivery of these applications. So basically non-monolith, non-on-prem, the new way of thinking about container delivery, whether that be serverless or Kubernetes orchestration, this is all cloud-native, it's all designed to deliver in the cloud. So this is a, you know, these modern tools, these techniques to achieve that, and all the following are cloud-native. So we're not going to talk about perimeter-based firewalls. We're going to talk about network interfaces and now policy as alternative technologies. And the idea is this all fast, and we can deliver the applications quicker without impacting, you know, service delivery. So customers see, like, essentially 100% of time at all times. So with that, yeah, even the perimeter, you know, I just alluded to it there a second ago. But in the past, when you had a monolithic application, you had a firewall, and that firewall was blocking or allowing specific IP addresses. So it was all fine when an application was static, you know, you would say, look, I have an application with a fixed IP, block these IPs to that fixed IP. But with containers, since they're ephemeral, they don't last very long. You know, my pod lasts five minutes and it dies and is recreated, the orchestrator does all of that.  And that's all part of that whole resilience thing of, you know, quick delivery, everything updates quickly. So when it comes to detecting intrusions, we can't rely on just archaic systems of monitoring based on IP, monitoring based on application name. So these kind of things, this state is going to change regularly, so it's more less stateless. Now, another thing to point out here is everything around the perimeter has changed. When we have a cloud-native application, most likely it's being delivered through the cloud, you know, so the cloud provider themselves, they're the ones managing those external connections. This is different to when it was all running in your own enterprise service. We're also talking about exposure, it's much larger when we're talking about cloud-native. So by default with Kubernetes workloads, you know, they're on a flat network. So it means all pods, there's no restrictions by default, they can all freely talk to each other. And if we're using a load balancer, well, we can expose that to the public internet. And that's a scary thought, you know, we don't want to overly expose resources, workloads to the public internet where they can be subject to a threat. So we need to be able to control the access to services, to workloads, to network connections. All of this needs to be achieved both at the cloud layer and also at the workload layer. And that's what we're talking about with cloud-native application protection platforms, both the cloud services, but also the underlying workloads that we're going to secure. And how do you detect unusual activity? Since cloud-native workloads are so different to a traditional technology, our monitoring tools are the tools we need to achieve this zero trust architecture if you want. And how is that going to be different? So I'll cover all that in a second. So this is the general anatomy of a cloud-native application. You have your VM, which is no real different to a VM that you would see in an on-prem environment, except we're talking about an instance that's running in the cloud. Containers, the workloads that we're seeing are going to run on that instance. So Kubernetes at its core is still going to have virtual machines, what we call a control plane, and you have worker nodes. Those are still VM instances. So containers run on those VMs. There is the alternative approach of serverless. So we're just talking about deploying our workloads through a cloud serverless approach. But in either case, whether we go down running them on a VM or serverless without a server, you're still going to have the same controls that you need to have enforcement. So you're going to have identity and access management. The cloud provider, as you see at the bottom, whether it be AWS, Microsoft Azure, Google Cloud, IBM Cloud, there's a whole bunch of different cloud providers that will do this. They should have all these services out of the box. So they'll have an equivalent of an IAM service for defining what users can and cannot do. They'll have their own virtual firewall technology like VPC controls on what connections are allowed in an avid environment. They'll have object storage. They'll be able to find, you know, where you're going to store secrets that are going to be accessed for database or other resources. There's going to be logging, you know, real-time logging. And when we're talking about monitoring the health in a cloud provider or working at the workload level, we're going to have to plug into these different services. We're going to need to access those logs from the cloud provider, the audit logs. And then we're talking about network security. If there is a load balancer configured at this cloud layer, we're going to need to access that audit log service. And we're going to need to be able to access those security groups to make sure if there's a change to a security group, if we need to enforce something in a security group, you know, that we have access to those APIs. So cloud native applications at their core are running on cloud infrastructure. Moving on to next slide. This is what I was talking about briefly a second ago is the cloud native landscape. If you go to, if you were to Google CNCF landscape or project landscape, you would see this, it's much bigger than what you're seeing here. It's all the projects that are, you know, in the CNCF. And these projects, you know, some of them are sponsor projects, you have the ones that are incubating, they're going through the internal process or a gradual process of making sure that they're essentially audited, they're checked that they comply with a bunch of stringing controls to make sure that they are the best of the best. As you can see, some projects like OPA and Falco as of last week are now graduate projects, you know, which means that they've gone through all this rigorous process that met all the conditions to say they are now able to go outside of the oversight of the CNCF that they are, you know, meet all the best standards. So when I look at that top left corner and I still look at Falco, OPA, Caioverno, we'll talk about these technologies later in the session, but it's also, you know, it adds to the credibility that we're not just picking a niche technology that no one's heard of. And then you might have one minor use case for, but rather we're picking the technologies that are widely adopted, you know, they meet stringing controls and are most likely going to be integrated into a CNAP technology. Now this is as of the third of, sorry, the second of March 2024. This table is going to update on a, you know, a regular basis. So again, check out the landscape if you want to see an up to date view. So with that, what is CNAP? And I mentioned it briefly a while ago, a CNAP is a cloud native application protection platform. It's a bit of a mouthful. There's a lot of words there. But what it means is it's integrating the capabilities of existing acronyms defined by industry analysts, such as CSPM, which is the cloud security posture management. CIEM, which is this cloud infrastructure or cloud identity and event management, cloud workload protection platforms, CWPP and CDR, which is the cloud detection response. Now that will cover anything from identity and access management, network security, anything on the workload platform infrastructure, the data, the secrets that you're managing. So down to the logs. Again, we need to look at everything within the platform and CNAP does a job of tying in all these loose ends. So you don't have to buy a CSPM, you don't have to buy a CDR technology. You should now be able to, as an organization, vet out a CNAP, understand the capabilities of the CNAP, and then say, okay, credibly, we could consume or build that technology. So those building blocks are. So CSPM is the first thing to cover that, since it's posture, we're looking at the health of the environment. For most people, that's vulnerability management to look at, you know, do we have a lot of vulnerabilities in the environment and how do we scan those, and we'll use technology such as like Trivy or Clare to check for, you know, are there vulnerabilities in the environment. But posture management also includes just general misconfigurations. So as much as a vulnerability, we're identifying something that's insecure, general misconfiguration, it could be overprivileges. You know, if we're talking about, you know, when we configure our, when we're creating our cluster, let's say, using our infrastructure as code, we're deploying your environment. So we may do certain insecure misconfigurations, which leaves our, you know, the environment open to attack, and that will fall under CSPM. But there's different parts of CSPM, or KSPM, which is Kubernetes specific posture management to make include things like threat detection compliance. And I ask, why is the threat detection under posture? But if we think about regulatory compliance frameworks, if we look at the likes of PCI, HIPAA, you know, for them, they define water insecure controls, even OASP G10, for Kubernetes, they'll define water insecure controls. So if you have a threat detection tool, or even any kind of introspection or monitoring tool, and it can tell you an insecure configuration was done here, and you're able to detect that in real time, that that certainly plays into KSPM. While I'm not advocating and saying you have to use, you know, real time detection tool specifically for CSPM, they do have a use case under there. For Kim, that's identity and event management. So that's more easy to understand. That's specifically identities. So an identity could be at the cloud layer. So we're talking about IAM, identity and access management. So usually the cloud providers provide their own services for defining the identities and permissions for those identities, those users in the cloud, what they can and can't access. But even when we're talking about the workload level, you know, there's tools like role based access control, RBAC, it's been in Linux for long before, cloud native. And that defines, you know, again, what fraud actions you can perform. So create, read, update, delete. And again, this is all Kim. For CWPP, we're talking about workload protection. Now this is where there's a gray yard for a lot of people. Did CDR play CWPP? Certainly not, but there are overlaps between the two that are more hard to define than in the other buckets. So CWPP is workload protection. And there's the last piece platform. It's a bit of a strange one, but it's more like CWP. So when we're talking about here, workload protection is just making sure workloads aren't doing something insecure. Now this ties back to things like vulnerability management. Certainly we want to thwart threats if they are malicious. So certainly want to maybe mitigate the risk. So that would tie into CWPP. But for a lot of people, this will be, you know, monitoring the container, monitoring Kubernetes. If, if something malicious is done or an insecure behavior, let's say terminal shell container and try to download a malicious package, everything CWPP. But what when we're talking about it's workload specific. So it's CWPP. So for workloads, we're focused on the containers, the pods. If we're talking about serverless, again, it's the application you're delivering. So let's focus on security specific to the workload. So if it's a workload with a high risk vulnerability, we want to mitigate that CWPP. If it's a container, whether serverless or running in Kubernetes, and we want to again detect and prevent that threat, it's CWPP. So it's host container detection response, whereas CDR is in some cases, let's say an extension of CWPP, because we're still monitoring container and Kubernetes runtime activity. We are doing the host threat detection response. But we also are extending it to cloud detection response. So, you know, in the cloud provider, a user might do something malicious. They might be trying to access secrets, delete resources, doing things they shouldn't be able to do. So are we able to detect it? Well, unlike workload protection, which is fundamentally using things like system calls in Linux, or you're connecting to the Kubernetes audit logs to see what is happening at the Kubernetes audit there. Containers, all that's done through system calls. CDR, you're going to need to plug into the cloud audit logs. So things like cloud trail, whether it be Google audit logs, I don't know what the name of it is, Google platform logs. Azure probably have their own Azure platform logs. So whether you can plug into those audit logs of the cloud provider, that will help us to detect and respond to threats in the cloud. So that's the main differences. CDR is sort of an extension of everything cloud. Some people used to call it CNDR, cloud native detection response. So it's everything from cloud native and the workload. But again, CWPP before CDR existed was focused purely at the workload layer. So yeah, let's start off with CSPM. So yeah, as I said a while ago, CSPM is cloud security posture management. As you can see in the graph, it's going to cover everything around the data, the management, even the network. So anything posture, anything that's kind of drifting from the original controls. This includes flight charts, navigation material, anything, you know, so if you have secrets, you have, you've configured network control, sorry, around your security groups. If someone's making changes to those different records, we want to be able to verify if there's a change to a static configuration. And then that's essentially keeping the posture. So you'll see in PCI or SOP2, there'll be a bunch of controls saying users who aren't at certain clearance level shouldn't be able to make changes to certain things. And if they do, well, you certainly need to have a technology in place or system in place to either prevent them from doing it or minimum detect that there's a, you know, a compliance check that someone's doing something they shouldn't be able to do. And that's the posture management part. So yeah, this was the piece of data. So there was three different breaches. There was the Flexbroker and Booker, Pegasus Air Lines and Sivicom, and they're all related to misconfigured S3 buckets. So in this case, like personally identifiable data, whether it be like photos, signatures, electronic flight bag, software source code, plain text passwords, secret keys, all that can be accessed through these S3 buckets. So, you know, the use case is pretty strong for a CSPM technology is to be able to control and prevent how people access resources in the cloud. Because by default, there's, you know, first limited controls that are enforced to stop people from accessing resource that they shouldn't. So an attacker could, as they've proven in these breaches, access resource that they really shouldn't be able to do. So that's the use case for CSPM is to prevent access to sensitive controls or from deleting controls or modifying controls, let's say, network policy, security group enforcement, that would allow you to therefore access sensitive credentials more easily. The next thing is KSPM. Now KSPM is, as you can see by the box, it's specific to Kubernetes. So we're not talking about the cloud layer anymore. We're talking about just Kubernetes. With that, we could put technologies like Kyverno by OPA. They could be in either KSPM or CSPM. And the reason for that is they both carry that whole deploy time enforcement. Whereas, you know, OPA gatekeeper would be purely Kubernetes enforcement. So there's technologies like I could recommend gatekeeper for Kubernetes control about what you shouldn't be able to do. But Kyverno would certainly be able to be at CSPM or KSPM use case. As I say, there's overlap between both. And in some people's definition I've seen up, they may not talk about KSPM because that might be integrated into the broader CSPM logic. But what are the options that I should have, you know, probably open up the slide when I was mentioning that a second ago. The technologies like Kubebench, I think they do certainly qualify under posture management. And the reason for that is they show, I think it's with the CIS benchmark, they'll show what are best practices for Kubernetes specifically. It'll say, you know, on a checklist, are you green or red?  And then if you say false, great, you know, it's disabled. If it are accepted, yeah, if it's set to true, no, it's an X. So it goes for a checklist of all the insecure configurations, you generate your report based on CIS with center for information security or something like that. So it's a pretty highly recognized standardized procedure. And you can go back and start reconfiguring, you know, your controls to make sure you get a green list of, you know, I've done all my best practices. And technology is a great cross-laner also great, you know, they use infrastructure as code or IAC to create specific control planes for all sorts of workload controls. But at the runtime level, as I mentioned, technologies like Kyverno, they're Kubernetes specific, you know, so they do all this, you know, enforcement controls, but they also do certain kind of cloud controls. OPA is a cloud native policy engine, I believe it ties into the cloud layer, whereas I said gatekeeper is, yeah, it's a policy enforcement at the workload level. And then Falco, while it's not, it doesn't do the enforcement controls to say, you know, what you can and can't do, you know, let it instead what it'll do is it'll monitor all insecure activity. So in this case, you know, by plugging into the cloud audit logs, Kubernetes audit logs, monitoring system calls, if we detect that a user has tried making contact with them, you know, secrets or making changes trying to delete resources, even if they're successful or not, it doesn't matter, being able to monitor activity, we're able to go back and, you know, actually audit that activity and it's brilliant for reporting. So we can say, look, these users tried doing this and we took this enforcement action based upon that. But lack of monitoring at all, if you're just relying purely on enforcement, but you have no monitoring, well, it's very hard to show reports say, look, this is, we can monitor that activity. So I think all the technologies played a part, technologies like Qbench certainly are important for reporting on, do you have insecure configurations in place? Falco is certainly important for monitoring all activity, anomalous or not, to see what is going on. And certainly then for the important enforcement engines are that that, you know, they are the last protocol, they're going to make sure that someone can't make those changes that they shouldn't be able to do. So that's all, that's all CSPN. The next part is Kim, identity and event management. Again, this is everything that's human or not human. So you can have identities in the cloud for like robot accounts, there are a lot of those. But for users in the cloud as well, so you say, John has access to AWS, what can he do in AWS? Well, you're going to want to force I am controls identity and access management. And that says I have access to 50 out of 5000 services. And in those I have read only access something like that. Now, Kim shouldn't really be limited to to the cloud layer because again, if we are talking. Yeah, it's very hard for us to list specific technologies. The reason for this is, you know, if we're talking about I am, you know, your cloud provider doesn't bring a job of writing that. So, you know, what I would just say is, use the existing technologies and place provided by your cloud provider. It's going to be different slightly for each provider, but point is they give you technologies use those where appropriate. So I wouldn't be recommending open source technologies here. What I would say is, like Ksock is another software vendor they recently released a policy generator for our back. So this more in the Kubernetes, you know, Linux host layer to say the crowd actions on workloads. So what user can cannot do or, you know, yeah, service accounts kind of can't do and declare inside Kubernetes. So there's different things that define identity and event management, pretty much everything around access and entitlements. So what I would say is if you can enforce your trust and logic into your environment where possible brilliant. What you'll notice more and more seen at platforms like cystic, for instance, they'll do Kim policy generation. So they'll say, we monitor users what their activities in the cloud. And if they're not accessing these services over 24 period or for week or whatever, then they'll say using kind of a simple logic. They'll say, you know, these services are never accessed by these users, or these users services are rarely ever touched by user. Maybe they only ever needed to read what was going in there, but they never actually wrote any changes. So they'll recommend appropriate policy that won't break anything, but it will ensure that they don't have overly. Permissive access. And that way, even if that real human account was compromised, there's a limited blast radius for the attacker. There's limited things they can do in the cloud, as far as damage control. So apologies. It's like cough. So as far as Kim goes when we're talking about recommending OSS technologies, technologies like key cloak are great for single sign on. You know, when, even when we talk about Falco, you know, I say your octa identity, if you're configuring identity and access management in an identity provider set to the cloud provider, you know, Falco can monitor the activity on the ID ID, yeah, IDP provider. And that way, you know, if there is anomalous activity, someone is trying to make changes to to octa to get access to the cloud provider. Well, you can also monitor that in Falco. So although I didn't list it there, that's a genuine use case. But the same logic would apply to something like Prometheus Low Key Grafana. If you can aggregate real time events from other technologies, including octa or other IDP providers, or in the cloud provider itself, you can get those cloud trail logs in. You know, you have a pretty good job of monitoring what users are not doing as far as permissions go and be able to then take appropriate action. Technologies like Terraform, Open Tofu, Pulumi, they're all perfect for defining consistent templates of what users should be able to do. So you can create like, for instance, complex infrastructures code templates to say, here's our infrastructure of this what's going to be spun up. These users will be lax with it. They will only be able to do these actions within the environment and do it all as a defined template from day one. We're all then thinking about security as an after sight of everything you're doing in front of DevOps practices. So kind of this whole DevOps, DevSecOps methodology of tying security into the DevOps workflow. So yeah, here's just more statistics regarding Kim. I don't know if there's where these, I think these are taken from our statistics research report, you know, 90% of ground permissions are not used. Time back to what I was saying there a second ago, if they're not used, if an attacker comes in, and they make changes, are we monitoring any of this? And if we're not monitoring it, then it's really in our best interest to limit what the users kind of can't do. We should also monitor what they're doing, but either way, we should limit the blast radius. So an attacker can't go into a service that we're not monitoring and start abusing it for crypto mining or whatever operation they want to do or, you know, reconnaissance. 58% of identities are not human rules.   How many permissions do we give to non human identities? And if it's a lot and they're compromised, are you monitoring it? Because I might be able to notice that my password has been changed as a user her logs in with a password. But, you know, we don't tend to believe stale credentials on these non human identities and it's a serious concern. And of those 98% of permissions have not been used for at least 90 days. So we're looking at stale accounts. Worst case scenario, and it's a terrible thing to talk about, but like, if there was a layoff in your company, 100 people were moved.  And what stops a user who has left that company still accessing the cloud provider. So this is all Kim, you know, it's about if credentials are getting old, do we force the user to, you know, reset them? If a user has been removed from a company, do we have a plan on action to remove those old credentials? There's a bunch of ways of looking at it, but please do factor in on human roles, because it's a massive security gap. So this CWPP, this is the vulnerability management threat detection and hardening side of it. And again, it can be anything from containers, VM serverless. Now, this is pretty self explanatory, I guess, what we're trying to say is make sure your workloads are secure. To detect vulnerabilities, what is our plan of action for removing those? Again, as I mentioned earlier, technologies like trivy, great for detecting vulnerabilities. To technologies like Falco are great for threat detection. Tets are gone as well.  But you know that might tie more into CDR. So we'll come back to that in a while. So with this, you know, again, this is probably coming from not the most recent report, but probably 2023. But yeah, 87% of containers just have higher critical vulnerabilities that are not patched. This is just a reality. Unfortunately, is that there's a huge amount of vulnerabilities running in existing workloads, create surface area for attackers to abuse. For that, when we look at those operating systems, because every container has its own operating system, we'll notice that most of them are going to be using Red Hat Enterprise Linux. I personally use Ubuntu a lot, but you know, reality is only 16% here at Alpine. And why is Alpine such an important thing? Well, when we look at, you know, Alpine images, they're like 5.7 megabytes is on screen. Whereas like those larger images, you know, the alternate ones are like 228 megabytes, so it takes a certain load on your environment. There's bloat. The reason why some people might use it or for two reasons, maybe the first reason is because you have all your dependencies in place. That's great for your application if it needs those. But then sometimes it really is just I deployed this base image before, and I'm just going to keep doing that over and over again. There's very little thought gone into base images. And that's scary when we talked about the previous slide of the number of vulnerabilities associated with those more bloaty base images. So yeah, base image OS selection can reduce bloat by 97.5%. And that's probably the biggest factor I would provide when we're talking about CWPP is to be really serious about what images you're choosing to use. Because if we can reduce the vulnerabilities and reduce the exposure, we certainly then are handling the majority of the issue on CWPP. And then hypothetically, if say that same, you know, lightweight image, which has less vulnerabilities does get abused. Well, we still have our threat detection response actions in place to take action, but we are reducing the attack surface. And if you look at from those images that were analyzed so cystic, yeah, two years ago we would have done this report or a year ago and they would report and done a report for over 1,800 malicious images identified within containers. 608 of those were crypto mining. And that seems pretty obvious in hindsight because you think about what Kubernetes, what cloud native means fundamentally. We talked about the idea of resiliency, scalability, you know, short lifespan. These are all great for, for something like crypto mining, because we can say, look, you can, you know, you probably have no resource constraints in place by default. Workloads, you know, we can scale up more and more as we need them. So, you know, they're by default in a good way for abusing resources. And due to their short lifespan, it's very hard to do instant response and forensics. If you don't have native technologies in place of the CNAP to monitor, you know, was a crypto miner use what actually happened at the time when they were abusing our container for mining operations. And if they're, if it's in base images, then they can do it over many different pods and just keep coming back as long as they're pointing to the same mining pool, they can get rewards. So as I say, Kubernetes, the fact that it's about delivering applications at scale, it seems like an obvious target for such an operation as mining, make, you know, crypto mineral currency off a fairly simple operation. So as I say, you know, how do we avoid this? You can use tools like SNIC to scan the application dependencies and development earlier on in your pipeline to make sure you're not introducing these insecure dependencies into your environment. So if you have technologies such as Harbor, they provide artifact registry signing and scanning. So again, it's just making sure that nothing has changed. So once it's signed, we know that's the, the approved, the standard one that we wanted. And there's been no kind of drift from the intentional design tools like six store, and they do specifically the supply chain scanning, and that also includes the signing verification technology. So if we want to reduce our vulnerabilities, if we don't have a reason for using images that have, you know, a large list of vulnerabilities, then we can use to container such as Wolfie or Alpine Linux, which are what we call distrust. Now, what, what does that really mean when we're talking about like distrust so Alpine Linux, it's, it's a Linux distribution that was designed to be small, simple and secure. It's a little busy box, open RC. Basically, instead of using things like G lib C or GNU core utilities and system D and all of that that's usually in the other container images. This makes Alpine one of basically, you know, the only container images that doesn't use that core utilities that we see with GNU. And it's just, it's a different approach. It's less dependencies, less load is brought in with Alpine Linux and that's a great one to maybe choose as your base image going forward. If you don't have a reason for using rel or Ubuntu or something else. So CDR was that all about. So this is the detection response. We talked in at the workload level, and also knows the response part CDP P was never really, you know, mad about talking about response capabilities for the detection. You know, it was more about making sure we detect and know what workloads are doing. But there was never a specific defined need to, you know, mitigate not mitigate but to kill a pod or kill a process when identified as an issue. So that there was just funny in this terminology. So CDR says detection response, similar to what you expect with EDR, XDR, any of these detection response technologies. So it's like that for the cloud. Now as mentioned, by now, people have a fairly good idea of what CDR or sorry cloud native is and how it's different. So now we're talking about cloud native detection response. We can detect malicious activity on IDM, your IM or in your security groups, or even just changes to buckets or anything in the cloud provider as well as at the workload CDR is focused on that. So, you know, can we detect it. Yes, we'll, with so technology like Falco we can monitor cloud trail audit logs or any other audit log from the providers, and then say, okay, with an automation action like Falco sidekick, we can then, you know, mitigate the risk in real time or close to real time using again serverless approaches if you want to go down that route. But technologies such as Tetra gone, they can do something like signal action at the workload level to, you know, kill a process that we identify in the container which is really useful. And all of this ties into CDR but CDR so much more than just workload, it extends to the cloud provider as well. Now here we're looking at companies that take about 207 days to identify and 70 days to contain the breach. This is more and more we're hearing about this is the, the average total cost of a data breach. It's continuously going up. But again, it's that the time spent to detect respond by monitoring all the anomalous activity at the cloud layer, we're certainly reducing our time to to respond from weeks, not even days, but rather like get it done in, you know, within an hour or less, you want to talk about minutes. Because again, the costs are crazy we're talking here measuring in USD millions. And as a 2022 going on to 2023. They've easily comfortably exceeded the four million per cost per breach. And this number can only go up I'd say, especially as adoption of cloud continues to rise. So briefly, I just mentioned technologies like Falco, a tetragon. The reason I didn't add more technologies to the CDR part is it really is that detection response. You know, it's more aligned with traditional EDR, but for the, you know, use case or problem points of cloud native and the cloud provider. So our tetragon does a great job of looking at runtime observability enforcement for containers kubernetes Falco does the same, but then also provides comprehensive monitoring across octa get up across the cloud providers as well. So key takeaways of today's session cloud native applications have a large tax surface. I'm sorry to say it, but it's just true, you know, we talked about flat networks design so no networking enforcement by default. No resource limits in regards to abuse done by mining activity. There's no are back controls really in place for what, you know, create, read, update, delete actions. And at the cloud layer, you know, there's not a whole lot of difference either in the cloud provider you're also expected to enforce those controls yourself. You should adopt these technologies gradually. This is a journey when it comes to moving from monolith cloud native. You know, Microsoft's architecture, you know, it's something that we need to really look into how it's going to affect your business, how it's going to benefit your business. There is an increased need for least privilege and zero trust what you should get from this session is from the data we talked about research reports. Most organizations just aren't enforcing those kind of controls, and it's hard right we've got sporadic technologies, they're not well linked together. And that does a good job of tying the loose ends to give a comprehensive view of controls. And this also is a single solution that should, you know, be implemented and managed by different teams whether it be DevOps security in a collaborative manner. So again, this will address business issues such as addressing that large attack surface, but it is a collaborative approach. And that's why we're proposing CNAP, but we hopefully have given you an idea of the different technologies that will come together to make that CNAP. So with that, I hope today's session was useful. And we're looking forward to seeing you again soon. Bye for now.


You're good Ethan. Good, we've got so many things up for this meeting. Here we go. Rochester Stockbridge Unified Board Meeting, Special Meeting, Prior to Full Board Meeting, Monday, January 25th, 2021 at 6 p.m. via Google Meet. Agenda, we have called to order. Excellent. Adjustments to the agenda. I don't think we have any. Use the hand raised, by the way, or, you know, if you need to. I'm a little sad Carl's not here because he's the one who negotiated this agreement. So I was hoping he would, I've got some notes, but so we will talk about negotiations and we have nothing else. I would entertain a motion to enter executive session to discuss negotiations. I'll make a motion to enter executive session to discuss negotiations. Second. We've got two seconds. Jenny and Justine. Excellent. Let's go. Oh, Lindy, I realize we never did that thing so I could see all the people. Yeah, well, there's no other people but us. And Carl's an executive session waiting. Oh, he's there. Okay. Okay, so should we go over to that? In various permutations of this, there have been ways that we've met first as an SU and then we've discussed it as an SU and then we've tabled the SU vote while we went into the breakout meetings and all the towns voted and then we came back and voted as the SU. And other times we've done it with a motion where it's contingent on SU approval. And I was wondering if we got any guidance from Jamie or Dina or how we're supposed to do it. This go round. Let me send. He said to send him an email. Let me see if he's on. Do you want me to text him real quick, Ethan? What's that? Do you want me to text him? Yes. Oh, yeah. If you want to. I was going to do that. It does look like our agenda and I assume that our agenda was put together thoughtfully is that we go into executive session, then we return and then we take action to approve support staff, master agreement. And then after adjourn, we go to a full board meeting at 6.30. So it does rather than bouncing back and forth. It seems that we are to do this prior to the full board meeting. Right. And if you look at the agenda for the full board meeting, it doesn't have us going back and forth. So I think you're right, Carl. I think the contingent is the way to do this contingent on full SU board approval. Okay. Because yeah, the whole idea is that we have to ratify this as individual boards as well as the SU board. But we need to keep it a unified contract. And so what the parliamentary hoops we're trying to jump jump through are trying to avoid, you know, us approving it and then tumbridge saying no. And then we having to figure out how we're going to, you know, deal with deal with a bifurcated contract. But so I would move that we approve the support staff master agreement for 2021 contingent upon SU board approval. Second. All right. We have a second. Any discussion? I think we pretty well covered this. Let me call do a roll call vote just to make sure we get everybody. Megan. Hi. Great. Justine. Hi. Jenny. Hi. There you are. There you are. Great. Thank you. Hi. Amy. Hi. Ethan. Hi. Carl. Hi. Excellent. You're unanimous. Thank you, Carl, for doing this. Please give us plenty of warning when you decide you're going to be done with us. Because we this is a big thing. And I definitely know I don't want to do it. I'm happy to be on the executive board and be the chairman, but I do not want to be on negotiations. So others, I have to say, Justine, legal mind, negotiations, that I would nudge, nudge, nudge. So anyway, Carl, just let us know. If you're happy to keep doing this, we're happy to have you do it. But if you ever want to step down, give us some warning. So it's not a sudden transition. Hope you're muted. You're muted, Carl. There we go. Let's stop toggling the camera and start toggling the mic. Yeah, actually, my thinking would be that as we do reopen the support staff negotiations that someone joined me, just to kind of be part of it and see how it goes. It's pretty, I mean, it's pretty straightforward. There's a lot of the, when we've worked with an attorney, the attorney obviously steps us through a lot of things. There's a decent amount of institutional knowledge on the board, but I think it'd be good for someone to be there just to see it and to start knowing how it goes rather than just being dropped in cold.  What's that, Amy? Start training underneath Carl, basically. So it's a really good idea. Yep. Okay. Good. I think we have taken care of it. Let us have an entertain a motion to adjourn our wagon wheel. Rochester's our said wagon wheel meeting. And those of us who are returned to the SU full board meeting. I make a motion to adjourn. Second. Carl, seconded. All in favor signify by saying aye.


for more content, study advice and exam questions. Enroll in statistics by MJ, link in the description below. Hi everyone, it's MJ and welcome back to the course on statistics. Now this is the ninth chapter and I know we've really looked at exploratory data analysis, general probability, random variables, probability distributions, joint probability distributions, generating functions, compound distributions and even the central limit theorem. So this might be chapter nine, but in a weird and wonderful way, I'm almost of the opinion that this should have been chapter one. This is the very start of statistics and I'm gonna explain why in this video because if we had to look at statistics and when you ask ourselves, what is the aim of the subject? What is the point? What is the purpose? Why do we do it? We would see that stats is focused with one very simple task and that is to take data and turn that data into information, okay? That is all statistics is about. How it does that, we can actually break it into two components. The one component is calculating of things known as statistics and that's where the subject gets its name and the other part is with something known as inference. Now inference is something we're gonna deal with later on in the course. So I'm gonna be spending the rest of the video talking about statistics but you need these things in order to do inferences which you need in order to do information. So to explain the big picture, I'm going to be giving an example, okay? And the example is as follows. Let's say you have a university with a whole bunch of students and you need to ask yourself as let's say you're head of the student representation board or something like that, so you need to ask should we have a big party, okay? This is the decision we need to know but in order to come up with this decision we need information. We wanna know do people actually wanna have a party? What type of party do they want? When should the party be? But to get this information we don't have the time or the resources to ask everyone. So what do we do in this situation? We need the information but it's going to be quite expensive to obtain all of this information. Fortunately, and this is where statistics comes in, what we can do is we can ask a few students. So instead of trying to ask everyone we can just ask a few of them. And let's say we ask five of them and we see that four say yes and one says no. So we get this very interesting results that 80% said yes. And what we can then do is say well maybe what does that, or what information can that tell us about everyone? And then we now have our information so we can know what our decision needs to be and we can now have an event that is going to affect the university students. So that is the story. What I wanna do now is just explain to you what all the jargon is. Remember we've been doing all of these other weird and wonderful things, they're very high level concepts and I found a lot of students struggle with the jargon. So what we're gonna be doing now is just labeling each of these things in this party so that we understand what it is. All the university students can be thought of as the population. So we have our population over here. We then do something known as a survey, okay? And once we've asked a few students, this will be our sample. Okay, so we have our population is everyone but the five people are the sample. Now this is where it gets interesting, okay? Before we ask the student whether they wanna go to the party or not whether they think the party's a good idea. So before we ask him the question, the student can either be yes or no. And because it can be either one of these things, it's known as a random variable. Think of the student almost as a coin before you toss it. Once the student has answered and they've partaken in the sample, so after the student answers or after we flip the coin, what we have is an observation. And this would be in the situation, I mean, if we have to use our notation, we use the capital X to denote the random variable and we will use the lowercase X to denote observation. In this case, the observation can either be yes or the observation can be no. Then what we can do, and this is where stats becomes very mathematical, is we need to do calculations in order to determine our statistics. And 80% yes, as you all know, that is a statistic. But what exactly is a statistic? If we had to define this in a more technical terms, we can say that a statistic is a function of our random sample. So if we donate our random sample by X underscore, then a statistic is anything of a function of this random sample. What we're using here is a very famous statistic known as X bar. And the rest of the next video is gonna be dedicated to this X bar. Because we know that X bar is equal to a sum of the observations divided by the total number of observations, which in our case was equal to one plus one plus zero plus one plus one, where one denotes a yes to the party and we asked five people, four said it, and if you do the math, we get 0.8. And I mean, there it looks like the math is quite easy, but as you guys know from all the earlier videos, the mathematics does get a little bit more complicated than that. And that's why, like I say, this should be the first video. This should be chapter one, because when you start delving into the maths, it does get intimidating. People are like, oh, stats isn't for me, but once you see the bigger picture, you'll start understanding why this is so cool. Where things do get a little bit confusing is that yes, the students are random variables, but the statistic itself, X bar, is also a random variable. And because it is a random variable, we're gonna see that it has its own probability distribution. And that was actually the whole point of that central limit theorem was discussing what the distribution is of the statistic. Now this statistic is a very special one, as it is also an estimator. And it is an estimator for the population's mean, which we donate by that symbol called mu. Now the reason why we're interested in estimators, and this is something that we will discuss in later courses, is because then we can start asking questions like what is the probability that more than 50% of the university students actually want to come to the party? The problem with this is we need to know what the variance is of the sample, and like I said, we'll get to that a little bit later. But this does into something known as hypothesis testing. And once we have hypothesis testing, we can use that to create information. And once we have that information, we can then make our decision on whether to have a party or not. There's no point throwing a massive party and people don't actually want to go to it. So you can actually save a lot of money and make the right decision when you understand statistics. So what we're gonna be doing for the rest of the videos in this chapter is just looking at some of the mathematical properties of X bar and also something known as S, which is going to be our random samples variance. But we'll discuss that in separate videos. What I wanted to do is just give you a little bit of an overview to show you where we're going with all of this maths.  But once you understand the big picture, you can see, okay, this is what we're doing, this is why we're doing it, and hopefully it will make a lot more sense. So I'll see you guys in the next video where we will be discussing more about the sample mean. See you then, cheers. For more content, study advice, and exam questions, enroll in Statistics by MJ, link in the description below.


Hello, I'm Winston Hansma, and we're going to talk a little today about helping people understand how, when their trainer tells them to use their feet, what that means. There's a lot of terms and cutting that make sense to us as trainers, but don't necessarily make a whole lot of sense to people that aren't involved in cutting. We use our feet for multiple things. We use it to keep a horse up to a cow going across the pen. If we've got a horse that's coming up into a cow a little bit more than it should, then we're going to use our cow side leg to help ride it off. If the horse is falling off too much around the herd, we're going to use our herd side leg to make that horse stay up to that cow. I don't tend to use this one as much as maybe some trainers do now, but some trainers, now the question is, is how to use those legs. Personally, I like to use my cow side leg, which will be the leg that's closest to the cow that we're working. I like to use my leg on the front cinch area, so right in here. To me, for me and my program, what that does, right rein, my right leg on the front cinch area. I'm using my left leg back a little bit to hold that hip in place.


From Miami Beach, Florida, it's theCUBE, covering Acronis Global Cyber Summit 2019. Brought to you by Acronis. Cover and welcome back to this theCUBE coverage here Miami Beach at the Fontainebleau Hotel for Acronis' Global Cyber Summit 2019. John, for two days of coverage we're on day two, learning a lot about the global security, cybersecurity and protection, marketplace and solutions. Our next guest is Alex Miraschenko, also known as Alex Miro. Great to have you on. Great chatting with you prior to coming on camera. Thanks for coming on. My pleasure, thank you. So Vice President of Cyber Infrastructure at Acronis, essentially looking at your platform, that's essentially the hyper-converged stack underneath the platform software you're enabling, kind of the critical infrastructure for the platform. Yeah, that's one way to describe it. It is infrastructure, we provide the complete stack all the way, whatever you run on top of the standard commodity hardware, including the virtualization layer, capability to run the standard container workloads and essentially optimized for the cyber platform. You know, your interesting background, we were talking before we came on camera about your background, certainly you've seen waves of innovation, you've been a high performance storage enterprise, infrastructure, engineer and developer and executive. Lots changed in the past couple years and certainly the past decade, you run the VSAN wave, you saw that storage wave, now we're in a cloud wave, now we're on premise with hybrid. So hybrid's certainly now a big part of the operating model. So the operating system is not just storage anymore, it's a system view. What's your personal opinion on where storage is now? I've heard software-defined data center from VMware for years. We've been joked about software-defined storage, software-defined compute. I mean everything software-defined, but software is the game, scales a game, high performance is a requirement. What's change in storage right now? Well and like everything and nothing at the same time. As I said, like remember going back to like 30 years ago, I was like, oh gosh, you know, if the storage is exploding, you know, soon we're going to have like two gigabytes.   Or like imagine when people start recording music or you know, like they've seen this MP3 thing coming up. It's the same game, different year. But it's just like, it's like this exponential curve. It's like the shape of the curve stays the same. And to be honest, like part of me like never believes that I was like, oh come on, how much bigger can it get? And now everybody's like, oh, we got IUT line. We've got like those cameras streaming things, 24 seven in every possible thing you can think of. And of course, we're going to store everything. I'm not sure I know what to do with it, but. So from that point of view, the demand keeps growing and you need to have technologies to handle that appropriately. And again, it's just not a matter of kind of throwing the bits somewhere and forgetting about them. It's just keeping them in the predefined order and actually being able to process that. And Acronis isn't a business of a cyber protection. Some people say, oh, you guys just like a backup company. I mean, yeah, that's the fundamental part of that. But as you pointed out again in our pregame chat as it is, the traditional data protection guys be that backup, you know, you can think about as there is like a raid as a way to protect your data. They are all about defending against like a physical disruption as you call it, right? My disk died, you know, it's like my data center died and like my power went out. So what do I do? I was the data. But it does not protect you what I call a logical destruction. I mean, back in the like the classic example. Logical disruption. What is that? Disruption. Okay, yeah, logical disruption. You didn't say destruction. Disruption, it's the same thing. I mean, ransomware is pretty much destructive. I mean, it's hostage at that point, but. Logical meaning non-physical, not like an event like a hurricane or outage or something like that. I mean, you removed the right file and you didn't notice that.  I mean, you know, what are you going to do, right? Nothing got disrupted or destroyed, but your file's gone. That's. Logical disruptions or disruptions, that's happening. Certainly security points that out. But the security is the big thing, that's what the people didn't think about it. But definitely not like me, but like 20 years ago, is like the, so what happens if you see some guy hacked or like people, you know, like ransomware, right?  Encrypted, deleted, whatever they want to do there.  And. So you're saying people have a really strong backup and recovery, but they're recovering malware that they stored. Exactly. Yeah, so it's like, so that seems like an obvious problem, but like nobody, but Acronis actually provides an integrated solutions to build with that. I mean, they're different.  But then anybody who tried to like really deal with the restore in a critical situation knows that even without the malware concerns, it's stressful, shall we say. Yeah. And it's not always predictable. And it's always predictable. And it's post-Ace too, you're doing it after the fact. Right, right. But if the malware is involved, it's, you know, it becomes an extremely expensive and sometimes, you know, impossible operation. Acronix takes care of that because, you know, we can actually monitor your backups.  It's an post-hoc, you know, we're obviously proactive also to kind of real-time scanning for viruses. So it's a multi-level cyber protection, which is fairly, you know, I think it's unique in industry. Well, I think it's interesting how you guys have brought data protection concepts and paradigm and practice, by the way, into cyber, which is much more holistic view. Right. And I think that's like an operating system kind of thinking. And thinking it holistically is about systems. And systems has consequences. Something goes wrong over here. It's affecting it over the place. Get a race off of it. And, you know, we have a very strong system background for TNA, as they sometimes like to say that. And in fact, they first virtualize or a virtualization solution. And containers, for that matter, were built by the Cronus engineering team more than 15 years ago, way before it, like anybody in the Linux world knew how to store container and what they hope for the main. So that's like our storage layer, software-defined storage. It's fully blown, HCI product, completely our own understanding how to build that. That gives us a unique advantage among the security companies. You know, I got to ask you a question. I'm a, I'm a, I'm fascinated. I'm a student of history and also a student of competitive advantage when it comes to technology platforms. And the one thing I always say and see with entrepreneurs, whether they're young or old, is that there's two types of entrepreneurs. There's a systems thinker and a coder, right? And I think with platforms, you can't shortcut a platform because there's trajectory benefits of economies of scale for putting the work in. You can't just put a platform out there overnight. You got to have a, you got to build it and it takes time. So there's some people trying to accelerate platforms, some have done the work, you guys have done it for a long time. What's your view on that whole, well I'm going to throw a platform out there. What are some of the things that, that get exposed when I try to, you know, push a platform too fast? Well, the platform assumes that you have an ecosystem, people actually using it and building stuff on top of that. I mean, like every, you talked about the coders, right? So every programmer, a software developer, or most of them at least, they dream of two things.   I went through that phase, mostly in the operating system, a long time ago. And it's, you know, it's a process. I mean, whatever you build has to actually serve the purpose. If you, like there are lots of platforms in all areas of technology and people's like, oh, we're going to create a set of APIs and anybody can plug in it to us. It's like, unless you solve a real problem and really simplify life for people, they're not going to do that. I mean, right, they're not going to do, like use a platform for the sake of using the platform. Our cyber platform is different because we're essentially exposed, our APIs to our technology that's out there and people have been using. I mean, I don't know if you saw the keynote yesterday, there was the demo of the way how to write.  When people can add, you know, their own policies to cyber protect workflow, which could be specific to what they do, you know? They not rise, things like that. That plan, the platform makes sense because it's already out there and that's respond to customer demands, like, you know, look, we love what you guys do, but we have this specific set of requirements. And if it's general enough, we incorporate it into the product, but there is also a lot of things which could be specific to a vertical or even to a specific company. We just want to enable them to do this stuff. Well, that's what platforms are, they're enabling. They have to enable some capabilities that provides value to that use case. And that could be custom, domain specific. But I'm sorry, that could be domain specific. So a platform has to enable capabilities for someone to do something. Yes, but again, the key point to the platform is it has to kind of solve a real problem, not be there for the sake of elegance or solution or API or things of that nature. Final question for you, Alex. So I'm a CIO or CISO, or I'm out there with decision-making. I'm like, man, you know what? I got to rethink my enterprise architecture. I got to think about, I got IoT coming. I got industrial IoT and just an regular IoT. I want to have a comprehensive platform. Why Cronus? What's the pitch? And how do you, and what's different than the traditional sands and storage and other solutions out there? What's that pitch to that enterprise decision-maker or Cronus? You kind of like, to say as you say, I mean, you have a tremendous growth in your data flows. The number of data sources are exploding. It's actually going back to your previous question. I think that's what one of the differences is that it's not just a volume of data, it's the breadth of the data sources you're getting there. So you got to have to manage that CISO somehow or it's sort of an example. I don't know what the right analysis is like. Who wrote the analogy for that? So you're going to be like, how are you guys going to manage that? You have to protect it. At least you have to know what your exposure is or what the thing's there. And just throwing out a bunch of, you know, like standard network technologies, point products is not going to solve it. I mean, yes, you can hire lots of people. You can build your own thing. You would be effectively reinventing the lots of wheels in the process while we already have that solution for you. I like the platform idea because it makes data more addressable horizontally scalable. It's not just a siloed product out there. You can actually work and enable with data. Data's moving around. You got to be acted on. You need software to do that. Yes, exactly, exactly. So that's another thing. It's not, it keeps like a structured data versus unstructured data. There's discussions been going on for many years. You know, the reality is you will always have both types and you will always have the need to process them in both ways. And that's a good idea. I have one more final question since I just popped in my head. It's a final, final question. What's in the infrastructure platform that you're involved in that people should know about that they might not know about that's important to investigate? What is our killer feature? Is there a killer thing in there that is like notable that they should know about? What's under the hood on the infrastructure side for Cronus? Well, a lot of things. What's your favorite feature? We've been talking about that. What's your favorite feature? What's the one thing? Gosh, you know, it's like, I have lots of babies. I love them all. I mean, that's a really hard kill. You can't take sides. It's not a side. I mean, like I say, like, okay, I've been writing storage all my most of my career. I like storage, but it doesn't mean it's more important or less important than other things, you know, unless you have a comprehensive compute layer on top of that, the storage is just, then it becomes a storage vendor, niche vendor, right? So that's not who we are. I'm really fascinated by actually the integration with the cyber feature and the security because that's, on one hand, it's not something that I've been doing in my previous career for most of the time, but I do have a lot of kind of understanding of the workflow issues and integration points and that excites me something that's one of the reasons I'm here at Cronus. Integrated platforms is I think the key thing. Thanks for coming on, Alex. Thanks for sharing your insight. Appreciate it first thing in the morning here and well, afternoon now. Thanks. Thanks for coming on. You know, man, that's like everybody's so busy. It's a Cronus inaugural global cyber summit 2019 about cyber protection, not data protection, cyber protection, they both work hand in hand. This is theCUBE coverage here in Miami Beach. I'm John Furrier, we'll be back with more after this short break.


JavaScript developers would never make over $55,000 a year. Again, JavaScript developers would never make over $55,000 a year. Let me explain. Before a lot of you guys attacked me and tried to go into the comments and start writing about menu wrong. I got these job postings about JavaScript developers and they make all this money and let me put things in perspective for you guys. There's a ton of people who will apply. JavaScript developers who will apply for those jobs and have no chance of getting them because they're not qualified. They're not worth $55,000 a year, which is very low for any kind of developer position. But let's just focus on JavaScript today, guys, and I'm gonna give you guys some reasons why. So first of all, guys, let's tell you a little bit of a JavaScript story. First of all, the golden ever of JavaScript was a couple of years ago, maybe five to 10 years ago, when web development was really kind of taken off during the framework area, where we didn't have Ankyler and all that stuff and people starting to realize, hey, this browser can really kind of start to build programs out of back in the old ASP.NET days where you start to have the versions of the services come up and Flash and Java and all that stuff start to really come on the scene. During that time, web development was in its early stages and we really needed some really good JavaScript developers. Well, once those frameworks came to really start to take the web development up a few notches. Well, fast forward 10 years from now where we all, we got all these different frameworks, all this good stuff that's on the front end of a website that we can really kind of tailor made things to customize them and really put them in a position to win. But the problem is though, we have JavaScript developers out here who still got that old mindset that you're gonna really do a lot of heavy lifting with JavaScript without necessarily considering the database, considering the back end. Just really focusing on the front end design had huge experience and you might as well put on a hat to say I am a designer, not a web developer. So guys, you need to realize that and really put yourself in a position to win. That being said guys, I have a seven step guide below that's really gonna help you guys take things to the next level and really put you in a position to win. So this seven step guide helped JavaScript developers really take that next step, separate you from everybody in the interview process and help you get that first JavaScript job that's gonna make 60, 70, 80, even six figures if you position yourself in the right way. So, lab seven step guide below and it also give you access to our free community too guys. So go ahead and sign up while that guide is actually free. That being said guys, let's jump into this. Yeah, a lot of JavaScript developers can make a ton of money guys. Software development, web development in general. Great space, great opportunity for anybody who's committed to actually get started. The problem is a lot of you guys coming in with this old mindset of I'm just gonna focus on one thing, one thing only and that's what I do well. And if you work for a big organization, a Microsoft or a big software company who have ton of developers where you can niche down that much, great. But for the average developers in these small and mid-sized companies or freelancer you have to think of the problem as a whole and have a solution to be able to sell to that client, to sell to your hiring manager, to sell to the end user that you can do the job. Even during the interview process guys if you're not communicating how you solve these problems with JavaScript you're not gonna win guys. Upwork is real. You can get some quality JavaScript developers to little to no money. You guys think you're gonna come in with those same level skills and somebody gonna pay you 75, $80,000, six figures a year for something that can go to Upwork and get $10,000 in hours. Really solid JavaScript developers. And we haven't even got to start talking about the advanced platforms. I was working on a project the other day and I was looking at Google Analytics as far as the tracking capability and integrating it with the CRM and being able to put everything under one dashboard so that the client can see everything and one fails, whoop. Man, that stuff had gotten advanced to the point where you can really lay down some good JavaScript code without necessarily knowing a ton about JavaScript. And that's the core issue guys. A lot of you guys just focus on the code and it's getting easier and easier. Machine learning, AI, all this stuff is building these platforms, these frameworks that's gonna automatically put you out of work as fast as you can get your degree or a certification or coding bootcamp. So guys, it's so important that you guys get the right mindset when you're coming in as a JavaScript developer so that you don't fall into that trap of I'm just gonna write code and everything else is gonna fall in line. Yeah, that was true 10 years ago when demand for developers were through the roof and there was no supply. But the demand is still there but the employers, the hiring managers they have options now guys. They can go to Upwork, they can do freelance, they can hire somebody in so they're not gonna make the mistake of hiring a JavaScript developer who just not gonna do the job and they definitely not gonna overpay them because that's gonna put them in a position so that their company can be at risk. So that being said guys, let's talk about the JavaScript mindset. Number two, you need to really focus on trying to be more of a full stack developer. Yes, I want you to have that specialty in JavaScript or front end web development. I want you to still have that and promote yourself. But as you guys already know, if you work for any company for an extended amount of time, if you work for any freelance gig, once you're done with those first three or four projects that first three or four months or six months of any project, the projects start to wean off really fast. So you need to be able to provide more solutions, more projects, more ways you can provide them with more value very quickly. Or you're gonna be out of work because they're gonna eventually find out, hey, I'm paying you for nothing. Hey, I don't need you anymore. I can go, I can do this without you. Or I just call you when I need you. Which if you write code the right way, your code is sustainable, it's scalable so they won't need you. That's why you need to thank yourself as more of a problem-solving full stack developer because you're always gonna have work even with that one client. That's why I always recommend you guys to niche down in a certain industry with a certain technology stack because you're gonna find out pretty quickly as a company advance, say, grow, you write down, you lay down code, you're gonna put yourself in a position to scale how those bigger projects and they'll be willing to pay you more money as the problems or the projects get bigger. So it's very important that you guys do this and you're gonna always have a job. This is the kind of stuff I tell you guys about where AI, it's hard for AI to come in in unstructured situations and identify problems and really put them in a position to communicate with the end user so that they can get buy-in guys. Don't get me wrong, I'm pretty sure AI would be at this point maybe not in my lifetime but somewhere else, but AI is in a position where if there's some structured data, if you have a specific problem, structured data, tables, all that stuff is way better than humans. But when you get an unstructured situation, you gotta identify problems to solve, you gotta interact with end users, you got multiple components involved, is not a one, two, three, four, five step that you can repetitively do, that's where you have to stand out as a JavaScript developer. Identify these problems, really put yourself in a position to present these as a project for yourself to solve and how it's gonna help that company make more money, get their ROI and make them look good for their bosses. So this is what you're gonna have to do to really kind of take yourself from just making $40,000 as a JavaScript developer to a hundred, even more thousands of dollars a year guys just by changing the way you look at your problem solving ability. Not necessarily learn how to do more code. Yes, that's a part of it, but that's not the end goal, as you guys may think. The coding boot camps, they don't pay you or the employer, they don't pay you to code guys, they pay you to solve problems. That's what you got to start thinking about. I know you got a problem, you're tired of me talking about problem solving, but this is the way you get jobs. This is the way I'm able to be the successful that I am without necessarily being one of the best as far as code writers of code guys. So web development is the future. If you guys don't know this already, you're probably watching this video on a browser, you see, and you see platforms like Microsoft, Google, all these guys are moving some of their core production or core software packages to the web. All the new frameworks really putting us in a position that we can really leverage that web browser to do more stuff. So get ahead of the curve, be prepared to provide these type of solutions to your clients and really put you in a position to win. So I guess you guys have a few other questions for me and what I'm gonna do, I'm gonna start a conversation guys. If you agree or if you disagree with me, go ahead and links, let's have a conversation in the comment section below and you guys tell me what your experience being as a JavaScript developer. Have you made over $60,000 a year as a JavaScript developer? I hope you have. If so, tell me your story. If you can't get over that $50,000 a year, huh? Let me know in the comment section. We wanna help you guys take things to the next level. But like I was saying in an earlier video guys, if you are struggling to get above that $50,000 market, you need some help, I can help you with that. The first step you need to do is sign up for my seven step guide so we can start really putting things out and letting you out of plan so that you can put yourself in a position to win.  Like, subscribe to the content. If you have additional questions, comment below. I'll see you guys in the next video. Peace.