Security Misconfiguration

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

1 hour 6 minutes
Video Transcription
Hey, everyone is Canada Hill Master Instructor, a cyber. In this video, we're gonna talk about Web defense.
So when we talk about security, Miss Configuration, we're talking about obviously insecure configurations, right? So I mentioned that with the Amazon s three buckets as an example that we see a lot of breaches occurring with. We're talking about there where a lot of the cloud instances when you set them up, they're kind of opened by default. So you have to know what you're doing
from from a setup standpoint
to make sure you're securing things properly. Also, Miss configured http headers allow Attackers to do things like get her post request and do nefarious things with those on. Then you know, we could do this against essentially any level of the applications stack again. This this can occur on any level of the stack.
So prevalent as I mentioned, it's one of the most common things in the cloud is probably the most prevalent place you see it act. And then there's a couple examples there the deep root analytics breach on, then also the Dow Jones breach Again. Those were related to Miss Configured Cloud instances.
So how do we check for that? You know, of course, checking for improper permission. So, as an example, if I'm setting up the woods, pick on Amazon stuff from in here if I'm setting up my stuff inside Amazon So I'm trying to set up different buckets. I want to make sure that I'm not using my route user account or my admin account.
So I want to just go ahead and set up other security counts in place is part of that. I am stuff,
and that way I can then use those accounts is kind of the managing stuff for different buckets that I'm setting up. So I want to segment out my security essentially there to make sure that no one's able to get rude access on things
using default credentials. So I don't want to mention the route account. Also don't want to use, like the default user name and password on anything.
We also don't wanna have our air handling be too verbose, So we don't want the attacker to get all sorts of information When they try to do something and they get an air message back. We don't want them to get a bunch of information that's very helpful to them to then go attack our stuff.
If we're using antiquated software's older software out there as well as if we disabled security features for some big notes reason we definitely don't want to be doing that type of stuff. So if you see that stuff out there, that might be, ah, indicator that we're vulnerable to security. Miss Configurations and an attacker can get our information.
So the impact again data loss, you know, financial loss from the aspect of we can't, you know, get access to our data or we have a breach. And then people go ahead and sue us because of that breach, or we get finds from losing the individuals. Data
prevention. Dockery. What can we do? Right? So heartening systems. And when we talk about that in the cloud, we're talking about making things Sure things are secure. We're also segmenting out our security accounts for access to these different systems. So we also want to remove unnecessary features,
patching, making sure we're patching properly and keeping things updated
as I already mentioned segmentation, and then we want to verify that whoever is trying to access this stuff is actually whomever they say they are right, so using things like multi factor or two factor authentication. Also going through validation checks every so often, so as an example, Fireman attacker and I get some
good credentials and I go ahead and sign in.
We want to make sure that at a certain point you challenge me again and make sure that it's actually a legitimate user that, you know, we maybe could send ah pin code or something to their phone to make sure that they're legit user and not an attacker.
So just a quick post assessment question here. Which of the following is a way to prevent against security, Miss Configurations?
All right, so we talked about this already, right? We talked about that. The answer here would actually be Answer. See segmenting our application architecture. So obviously a is wrong because we don't want to install a necessary features. And B is wrong because we don't want to use that antiquated antiquated it or that older software or dated as I'm using the verb each year
and then D is wrong because we don't want to use default credentials
as we already talked about before.
Up Next