Hey folks, welcome to another episode of the security table. This is an abridged episode because we're going to talk really fast about something and have kind of a shorter episode here. Joined by Izar and Matt and myself, Chris Romeo, we're always around the security table and we're going to jump right in. So I am looking at this NSA and CISA red and blue team share top 10 cybersecurity misconfigurations. Let's pick up with number one and get into it.
So default configurations of software and applications. Do we, are we in favor of these or are we against?
Well, so,
If you don't configure it right, then it's a misconfiguration, then, uh, yeah, I guess it's pretty much on the top ten.
Well, but I mean, this is, if we have, if we talk about a default configuration, this is making an assumption that the default is bad and therefore, but, but you could say the same thing about everything on this list. If this is your default,
Oh, no, no, no, no, wait, wait, they go to default credentials, meaning basically the misconfiguration here is that you are not changing the default passwords, which we know that absolutely nobody ever does, everybody immediately goes and puts a safe, good password instead of the default.
I mean, that's why with default credentials, you don't let people, you don't give them the choice. There is no default credential. You don't have one. You have them set a password when they're configuring the device or whatever. I wasn't going to name any names. It was supposed to be without
I didn't, I just had a thing
yeah, you have a little sneeze
so on this list, there is no default. I mean, unless you're talking about, about credential hygiene or not, there is no default credentials explicitly on this list.
yeah,
But number one is a summary line. It doesn't really need to be its own number, because they have put 11 on this list. If your default configuration is insecure, of course it's going to be number one.
Yeah.
but all of these other things are also,
missing. They're, they're mixing default credentials here with poor credential hygiene at number nine. So it doesn't make sense. Why are these not combined? Why would you have two separate things here?
well, so poor credential hygiene could be two things. misconfiguration of your password policies. Or it could be lack of your runtime behaviors around looking at compromised credentials. So in one case it's a configuration, in the other case it's not a configuration. So it's kind of a misleading item on this list.
Okay.
one, one is what one is having the, the, the fact that you shouldn't be able to keep the default past setup. And the second one is you really should choose a good password and you should store it right.
how about
the thing that, just before we go there, the thing that I have a problem with here is that we start with default configurations, which is a big thing, and then we funnel into credentials and permissions, which is a very, very, a much smaller subset than default configurations.
yeah. Yeah, they talk about service level permissions as well. But look at two. I think we're gonna love two. It's basically the E in STRIDE.
I do, I do, but uh, I don't think it's a misconfiguration. I think it's usually more of a design thing
Ooh, good point. Let's unpack that a little bit. So why, why is this a design problem and not a misconfiguration?
because it, it Putting, putting it, I, I think that lumping it together as a misconfiguration under this title basically means you are, you are using accounts that have way too much, too, way too much privileges than they should. Right. Which is not exactly a problem of a problem of separation.
It's a problem of the way that you design your system and you are giving one, one account the ability of being everything, rather than saying we have this set of accounts that's admin accounts and we have this set of accounts that's user accounts.
I think we have a context problem. We're looking at this through the lens of AppSec and software and ProdSec people. I just took a closer look. This says top 10 cybersecurity misconfigurations. So they're not specifically talking about design, like designing a web app. They're talking about excessive account privileges and elevated service account permissions that would be part of an operating Windows network in an enterprise.
Yeah, so let's talk about that
Aren't those applications?
Well, so think about number one, think about number one in that context then. Leaving the default configuration is the problem, right? by not changing the configuration to a secure state. If it requires elevating security, and I will just, and this is a lightning round here, but, you know, just think about the, the CISA Secure by Design, Secure by Default guidelines that came out recently in updated form. Secure by Default means come secure. And you have to weaken security.
We talk about loosening guides, but most of the time come products and application applications and software are shipped in a default configuration is insecure and leaving it in that insecure configuration state puts it the number one on this list. Number two is likewise. Those things often ship with an administrative account. That administrative account may be the only account that's that's installed by default. And people will use it for operations when they shouldn't.
They should create, they should create an additional account, non privileged, to be used for, for general purpose or something that's view only for, for metrics and reporting purposes or, or whatever. And you should be separation of the, the application should enforce separation of duties and users of those applications should reinforce that.
All right. So let's look at three. I don't get this one. Insufficient
four, actually,
What, you don't get this at all? How do you, how do you, you can't measure what you don't know, right? You can't defend what you don't have
yeah, but isn't everything encrypted in the world we live in now? How is, how can you monitor anything on a network that's not
Oh, no, no, no, no, no, no,
just a bunch of TLS going back
packet inspection,
no, no, no, you can,
TLS offloading.
you can monitor for, for, uh, streams are not predicted in your threat model. So I know that these two things are expected to talk, but if I see A talking to Z, all of a sudden, oh wait, that's not supposed to happen.
Right. But also with TLS offloading and deep packet inspection, I mean, once you're, yes, we're supposed to be in a world of zero trust, right, where systems are going to be on island unto themselves. But traditionally, you know, there's a network boundary where you may terminate TLS at the network boundary and then everything within it can be deep packet inspected and monitored for the traffic. And if you don't do that, then you're potentially leaving yourself at risk.
I mean, can you do that at the speed of an enterprise network though? Can you, I mean, we're talking
if you use mirror traffic,
in a 10 gig connection, you can decrypt all of that TLS traffic
With hardware, with hardware decryption. Yeah, yeah. With hardware decryption. Absolutely.
you can.
Okay. Wow.
But the thing
The world of computing has gotten further.
that, the thing that's sort of bothering me here is that we jumped from configuration of actual stuff and how you use stuff to all of a sudden on three and four we are looking at networks.
And This is designed too. It
And many times it's not the same people who do both things. So who's the public for this thing here?
I guess it's misleading. It's misleading because it's not a configuration. It's, it's,
It is. It is a configuration. Be when, because you could, I mean, whenever, whenever you de, whenever you de you designed, when you go to implement it, it is, you are configuring your network monitoring tools in an insufficient way.
Well, you configure it because it has to be configured to be, to be of use, but it's not a configuration problem of the environment or the system or the whatever. Fair.
We're nit-picking on words at this point.
Yeah, let's, let's keep, but to your earlier point about design, there is a design element to, if you properly design your network monitoring, you don't have insufficient network monitoring. And so
And by the way, and by the way, for four, with software defined networking, this is absolutely a configuration issue,
and four, just for the record, is lack of network segmentation.
right? So having
could be architecture.
it is, it is an architecture and it may
architecture now is configuration.
oh, we could have an episode alone on that one.
I dare you. I dare you to go to an architect and say What you do is configuration. I dare you,
Yeah, you're, you're change management now, friend. That's what you do. It's
Wait, isn't that, isn't that Dev, isn't that DevOps? Isn't that what DevOps and DevSecOps is all about?
What?
And he just said the quiet part loud.
Well, there's another dollar in the swear jar from. from Matt Coles,
at least I didn't say pane of glass.
or ShiftLeft, or any of my other,
Single pane
of the other words that cause pain.
right. So poor patch management. Number five, not a configuration per se, unless it's automatic updates we're talking about.
Oh, I see what you're saying.
oh, oh, speaking of the word jar, so, is this one talking about SBOMs? Is it SBOM time?
Please no. Please stop.
Please
already? Wait, do we have insufficient DAST anywhere?
Oh man, this is... Okay, so poor patch management, lack of regular patching, use of unsupported operating systems. To your point, this isn't a configuration unless it's an automated thing. This is just a point, this isn't the top 10 misconfigurations, it's the top 10 problems
Yeah, true,
It's a la so the, the, the misconfiguration would be a lack of automated patch management. Cause that's something you could change. You could turn it on or turn it off. Alright, good. Six, bypass of system access controls. Wait a minute.
I'm not entirely sure this is a configuration issue. This is a, this is an active attack kind of thing,
yeah, I would say that having system access controls is the configuration or misconfiguration,
look at the first sentence there. That's a threat. The first sentence is a threat. A malicious actor can bypass system access controls by compromising alternate authentication methods in an environment. I
okay, so there's the config, there's the configuration problem, right? If you, if, and it goes back to number one, if you have a default, if the system's default configuration exposes insecure protocols and you leave them open, you're at risk to this threat. Right? Number two, the second sentence here, if a malicious actor can collect hashes. Well, how do they collect hashes? You've left Lanman in your, in your system, right? Or NTLM or whatever.
And that you're saying that's the lack, that's the configuration problem or the
a configuration problem, right? So you've missed configuration. You've left insecure protocols in place.
the whole item is just listing ways of bypassing authentication.
Yeah, but they, they should, they should have taken the, the statements and turned 'em around in, in terms of, as a systems, as a system designer and a system deployer don't leave insecure configurations because they'll allow malicious actors to do X, Y, Z. That's how it probably should have been stated. That's, I think, what they intended to say. But, but what they did was they, they took the attack first and not the, not the cause.
Yeah. So then seven, weaker misconfigured MFA methods.
Oh.
But listen where they start here. Misconfigured smart cards or tokens. Generally government or DoD networks. So not really that applicable to the average enterprise. Like we don't use smart cards anywhere. At least I don't know anyone who uses smart cards.
Uh, some companies, well yeah, okay, maybe primarily in government or DoD, but I, you know, have high security environments that do use this, use smart cards. It's not unheard of, and people use YubiKeys and other FIDO tokens all the time.
I mean, that's not a smart card though, right? A YubiKeys,
It's a token.
they're talking
a token, it's a...
They're talking about CAC cards here from,
They are. CAC and PIV, right,
are talking about tokens as well, so you could think about FIDO and all that
So if you have a, if you have a, a Google Titan, or if you have a, uh, uh, a YubiKeys, right? Those are, those are access tokens. Those are tokens that are in scope here. What's interesting though, is they don't start with not having MFA in the first place. They start with the assumption that you have MFA and it's insecurely configured, not, you don't have MFA.
Well, that
one.
Not having MFA, to our earlier discussion would not be a misconfiguration.
Exactly, yeah,
be a design problem. So they, they kind of followed the
unless it was a configuration option that you could enable MFA that you didn't.
I see.
are assuming that you have it, but it's misconfigured.
That's
All right. Now eight, we go back to network.
No, no, wait, wait, wait, but before we go there, then they jump to lack of phishing resistant MFA.
Which is a configuration problem again.
is the configuration or is design of the MFA, perhaps the MFA solution is not good enough.
That's true if you have one to choose from, but if you have multiples to choose from, and you don't enable, again, the strongest one available,
Oh, oh, no, sorry. On, on upon reading. They seem to be addressing, uh, MFA over SMS because they say that exploitation of Signaling System 7 protocol vulnerabilities and SIM swap techniques is the problem.
right,
So we agree with that. I mean, we agree
if you have the option, if you have an option of using one that
not a misconfiguration,
unless it's an option,
Which a lot of times it is an option. A lot of times it is an option these days between push
But again, wait.
and text based,
If you have a choice between A or B, is that a misconfiguration if you choose the weaker of them? Or is it a bad design choice?
SMS based, or secure by default. So
it's a bad default. It's a bad default, which means it's a design. It's a configuration choice and it's a bad design in that you're giving a poor choice.
Yeah,
It's.
OK, you convinced me.
all right, 8. Insufficient ACLs on network shares and services. So now we're back to the network again.
Yeah, this is a configuration problem that most definitely you've set the wrong ACLs.
we're just we're just we're saying this is a misconfig and we're moving on.
Yep.
All right, 9 says poor credential hygiene.
that's basically bad configuration of human persons because,
Well, this is, this is password. If you're using passwords and you're not using MFA or if you're using MFA with passwords and you have crackable passwords, that means you've set a weak password policy. Right? You haven't used 20 characters with symbols, alphanumeric and spaces.
Wait, wait, wait, we know that those policies are not all that they are hyped up to be, right?
Yeah, I'm, I
But if you enforce a strong password policy...
Mean, what is the new, it's NIST 800-63, right? 800-63 redefines password policies as, as what they should be in a proper
Long, easy to remember, but hard to guess passphrases that don't change frequently.
Not changeable, unless there's been a breach, you don't have to change them.
And here they say that it's, if it's shorter than 15 characters, then it's bad.
And clear text password disclosure. We talked about this earlier with use of insecure protocols that expose credentials on the wire. Right? But what, what's, I guess that's, that's the, that's the choosing of a bad credential that can be easily guessed or reusing credentials and exposing it through insecure configurations. That's ultimately what it's getting to.
But again, is this a configuration thing? I mean, the only configuration that I can think of in here is the size of the password, or the choice of hashing
yeah,
method
there's, there's so much more they could have done. Like even just referencing 800-63 is. The current standard of what I think of as the best practice. Um, I don't, I don't think, I mean, if somebody is in this day and age, if they're allowing short passwords and non complex passwords, then, shame on them...
And then, and then they're, and then they talk about password stealth held in clear text. So this is not a configuration issue, right? This is not
configuration.
That's a design problem. They,
I don't know any system that says would you like to store your passwords in clear text. Oh, okay, I'm going to configure it this way. Yay! Let's hope for the good things.
All right, we got to pick up 10 here. Unrestricted code execution. So there's a, there's a condition at the top though. If unverified programs are allowed to execute on hosts, a threat actor, Oh, it sounds like a threat, can run arbitrary malicious payloads within a network.
Yeah. In my opinion, I don't know how you can say that this is a configuration issue unless you're running EDR,
Well, can you, can you somehow force, like on Windows, can you, is there a configuration setting to only run things that are trusted binaries?
you, you need stuff on top of it.
No, but you can't, you can have Windows fail to run without prompting for UAC. You could, right, or whatever it's called now.
Yeah, they had a what, because it was their safe list. Didn't they build a safe list feature years ago for
If it's not digitally signed, if it's not digitally signed, you can,
and the certificate is good,
can do, you can do group policies to prevent this.
but unless it is a very, and I could be wrong here because I'm not a Windows person, but unless it's a very limited account. You can just click on run it anyway.
Oh yeah, if you're, if you're running as admin, so you're running with elevated privileges, that goes back to the running with elevated privileges discussion,
Enterprise application environment, not everybody has admin, right? And so, and I think that's where they're going. Now, I don't know why you would turn off those protections in a Windows environment. Why would you turn off all of these things about safe listing applications based on signatures of binaries and things like
Because Joe from accounting absolutely needs to be able to run that flash thing that he has from 95. So they have to lower the barriers and give him more
I guess. Not in my world. Not in my network. I won't allow it. So, all right. Well, that was a fun little quick pass through the NSA, CISA, Red and Blue teams share top 10 cybersecurity misconfigurations. I think we kind of had some fun going through there and pointing out some things. Izar's got the
it has to be said, it has to be said that we value the effort. We like that it came out and, uh, we just think that it could be a bit more, I don't know, focused, defined,
Could be tuned up a little bit to truly make it so that it's clear how everything is a misconfiguration.
right. And the mitigations have good stuff. There's a lot to learn in there as well and they have good references. So I think that all in all, 3 out of 5 for the effort.
yeah, yeah. And it's, you know, they're, they're moving, they're moving the industry forward. It may not be perfect. Nobody's ever going to be perfect and that's okay. Cause there is no perfect security. Um, there is only reasonable security and some of this is reasonable and we'll leave it with that. Thanks folks.
