Narrator: Scheduling and constraints. 2 2
In this lesson 3 3
we're going to talk about scheduling and constraints. 4 4
So the first question I have 5 5
for you is how often should you scan? 6 6
Well, this is going to be determined based 7 7
on your internal risk management decisions 8 8
of your organization. 9 9
If you have a larger risk appetite 10 10
you're going to have more time in between scans 11 11
and you might go towards rarely or sometimes. 12 12
If you have a very low risk appetite 13 13
you may do it very often or often. 14 14
This is going to depend on you and your organization. 15 15
Remember, a scan is a point-in-time assessment. 16 16
One organization I worked with did scans every six months. 17 17
Now that seems like an awfully long time 18 18
to me to wait between scans 19 19
and they're assuming a ton of risk because they did that. 20 20
Another organization I worked with did it every month 21 21
yet others do it every week. 22 22
Again, it really depends on you 23 23
and how quickly you want to get those results 24 24
and see what vulnerabilities exist 25 25
so you can start mitigating them. 26 26
Remember, vulnerability scans are really 27 27
up to your organization 28 28
but my personal recommendation is they should be done 29 29
at least weekly. 30 30
Now, this isn't something that comes from your book, 31 31
this is just from my professional experience. 32 32
I think if you don't do it at least weekly 33 33
you are going to be missing a lot 34 34
and there's just way too much stuff that goes 35 35
on in a seven day cycle 36 36
that you should be at least scanning once a week. 37 37
Now, when we start talking about scans, there are lots 38 38
of different things we have to consider when we think 39 39
about when we should schedule them. 40 40
Some of them include things like, 41 41
when we deploy a new or updated system. 42 42
If I'm going to install some new piece of gear onto my network 43 43
I want to make sure it's been scanned 44 44
and I know what vulnerabilities exist. 45 45
And so that's my first time I think 46 46
about when I should scan something. 47 47
Another time I think about it is 48 48
when new vulnerabilities have been identified. 49 49
Now, this can be identified 50 50
in your network or just identified at large. 51 51
For instance, you might be reading the newspaper 52 52
and find out about this new thing called WannaCry. 53 53
If this was 2017, that's when it came out, 54 54
it hit the newspapers and everybody goes 55 55
"Oh my goodness, what is WannaCry?" 56 56
And you could actually find there was a vulnerability 57 57
associated with it and you could scan for that. 58 58
If I see something like that in the news, 59 59
I immediately want to make sure I'm scanning my network 60 60
to see if I'm vulnerable. 61 61
The next thing you want to think about 62 62
is whenever there's a security breach. 63 63
If you've had a security breach in your network 64 64
you want to scan your network 65 65
and make sure you find all your vulnerabilities. 66 66
Just because they got in one way doesn't mean they're 67 67
going to come back in that same way. 68 68
So you can't just patch the one way they got in. 69 69
This isn't a penetration test. 70 70
If they got in, you need to start making sure you lock 71 71
down everything, because generally what we've seen is when 72 72
an attacker gets in one way, 73 73
they come back to re-attack you again and again. 74 74
So if you had a security breach, 75 75
you need to make sure you follow up and do another scan. 76 76
Another reason to do it is when you have regulatory 77 77
or oversight requirements. 78 78
For instance, if you deal with PCIDSS 79 79
with credit card data, you have to do a scan once 80 80
a quarter that's required to be compliant 81 81
with PCIDSS requirements. 82 82
So if you have a regulatory oversight requirement 83 83
you'll do it based on their scan schedule. 84 84
And then the other one you're going to do it for is anytime 85 85
it's regularly scheduled. 86 86
Now, what I mean by that, in my organization 87 87
we do weekly scans. 88 88
So every week we make sure we do a full scan of our servers 89 89
and we make sure that everything is good. 90 90
If you do that, you'll know exactly 91 91
where you are every single week 92 92
and what your vulnerability posture is. 93 93
So why doesn't an organization just scan continuously 94 94
all day every day? 95 95
I should just run my scanners 96 96
over and over and over again to check. 97 97
Well, because vulnerabilities don't show up that way. 98 98
It's not the way things work. 99 99
There are a lot 100 100
of technical constraints here that would preclude you 101 101
from being able to do scans continuously over 102 102
and over and over again. 103 103
One of the big things is your feeds 104 104
are only updated so often. 105 105
Think about like antivirus signatures. 106 106
If you haven't gotten new antivirus signatures 107 107
then you're not going to be able to detect anything new, right? 108 108
That's the same concept here. 109 109
But really the biggest limitation 110 110
is your technical constraints. 111 111
Technical constraints can limit your ability 112 112
to conduct scans more frequently than you'd like. 113 113
When you start scanning your network 114 114
you're going to start causing processor utilization 115 115
and memory utilization. 116 116
For instance, here you can see exactly when the scan started 117 117
and when the scan stopped. 118 118
Notice the processor usage was at like five to 6% 119 119
and then it shot up to almost a hundred percent. 120 120
That's because this computer was 121 121
in the middle of doing a scan. 122 122
Now, this consumes a lot 123 123
of network bandwidth as well as significant processing 124 124
and memory usage on the target and from the scanning system. 125 125
And if you're using agent based scans 126 126
like this particular system was, you're going to see 127 127
on that system how the CPU can spike up during that time. 128 128
So you need to make sure you're timing your scans right 129 129
so they don't have an effect on your end user. 130 130
And you need to make sure 131 131
that you're not overburdening these systems 132 132
by trying to do continuous scans, because if you do that 133 133
your systems can become useless 134 134
because they won't get any work done. 135 135
Another constraint you're to consider is cost. 136 136
Each time you scan that has a cost associated with it. 137 137
Now your corporate policy is going to dictate how 138 138
much risk you're willing to assume. 139 139
And again, this comes down 140 140
to a cost situation because the more scans I do 141 141
the more people hours I have to use to do those scans 142 142
and people to read those scans 143 143
and people to analyze those scans and all of that stuff, 144 144
let alone the processing power and the network bandwidth 145 145
and all the other things that go into that. 146 146
So all of that has additional cost 147 147
and so there's going to be a risk appetite of, 148 148
"Hey if I can do this once a week versus once a day 149 149
is that still good enough?" 150 150
If I do this once an hour 151 151
versus once a day, which one is better? 152 152
And you're going to weigh that based 153 153
on how much it's going to cost you 154 154
and what benefit you're really going to get. 155 155
As I said, I tend to lean on the side of about 156 156
once a week is a good scan frequency, 157 157
but again, you get to choose this in your own organization. 158 158
As you start looking at this 159 159
in your overall threat intelligence, 160 160
you're going to see how much of a threat there is 161 161
against your organization and how often new code 162 162
and exploits are coming out. 163 163
Generally, we see from Microsoft once a week, 164 164
we get patches right? 165 165
We get 'em on patch Tuesday, 166 166
and so if we have 'em coming out on patch Tuesday 167 167
that's a good frequency for us once a week 168 168
to be able to scan, patch, scan and make sure 169 169
that we're getting up to date with the latest patches. 170 170
Now, your scanning frequency and technique will be 171 171
affected also by the data type that's being processed 172 172
by the target. 173 173
Now, what I mean by this is what's being processed 174 174
by the server will help you determine how many times 175 175
you need to scan this thing and how often. 176 176
For example, if you have a server that contains confidential 177 177
or top secret or sensitive information, 178 178
it should be scanned more frequently than a computer 179 179
that's being used by the mail room 180 180
because that's maybe not as important. 181 181
And so you're going to have to make those decisions. 182 182
Conversely, you're going to want to make sure the system 183 183
is scanned using a credentialed scan instead 184 184
of a non-credentialed scan if you're dealing with something 185 185
like secret or top secret or confidential data, right? 186 186
Because this is important stuff 187 187
we want to find all the vulnerabilities. 188 188
Now, again, this becomes tricky though because as I said 189 189
once the scan administrator has to do a credential scan 190 190
that means they need to have administrative credentials 191 191
on that sensitive target, which again 192 192
could lead to an insider threat. 193 193
So all these things are things that have to be balanced 194 194
and you have to weigh that risk. 195 195
This is why CYSA is a much harder exam 196 196
than some of the earlier exams you may have taken 197 197
because there's not a clear cut answer all of the time. 198 198
A lot of these things are risk decisions 199 199
that we have to weigh 200 200
and based on the different circumstances 201 201
we are going to choose different answers. 202 202
It's not always going to be A, sometimes it's going to be B 203 203
or C or D based on the circumstances. 204 204
And so you have to think these things through 205 205
and put on your manager hat 206 206
and your risk management hat as you start thinking 207 207
about these things and what you're going to do. 208 208
Now, one way to mitigate the risk of giving 209 209
out administrator credentials and still being able to 210 210
do a credentialed scan is to use what's called a PAM, 211 211
a privileged access management solution. 212 212
Now, a PAM allows you to mitigate this risk 213 213
of the insider threat. 214 214
Essentially, this is a technology that you can use. 215 215
So the scanning software goes to this server 216 216
the PAM server, 217 217
and it'll actually get 218 218
the privileged credentials from there. 219 219
These are actually one time used credentials. 220 220
So what happens is the PAM server will actually go 221 221
to the target that you're trying to scan. 222 222
It will change the password to some random thing, 223 223
give that random thing over to the scanning server. 224 224
The scanning server will finish its scan. 225 225
Once it's done, it tells the PAM server, "Hey, I'm done." 226 226
And the PAM server goes 227 227
and rechanges that password to something else entirely. 228 228
So you only have the password 229 229
or the administrative credentials for the time of the scan 230 230
and then they're taken away from you again. 231 231
That's how these PAM solutions work, 232 232
these privileged access management solutions. 233 233
So if you are in a big organization 234 234
and you really want to do these credentialed scans 235 235
which I do recommend, then you really do want to 236 236
get yourself a privileged access management solution 237 237
because it'll help you mitigate this insider threat. 238 238
Now, unfortunately, these PAM solutions do cost money 239 239
and sometimes you don't have the budget for it. 240 240
So what can you do 241 241
if you don't have the budget for a PAM solution? 242 242
Well, you can do the next best thing. 243 243
You can create restricted log on hours 244 244
for a specific period of time, that only allows scanning 245 245
during that time using those administrative credentials. 246 246
So we might say we're only going to allow scanning 247 247
from midnight to 2:00 AM. 248 248
So if somebody tries to log on at three in the afternoon 249 249
when the administrator's actually there, 250 250
then we would know that's an insider threat 251 251
and we'd have to think about that, right? 252 252
And look into that and see what's going on. 253 253
This way that privilege account can only be used 254 254
to do the scanning between midnight and 2:00 AM 255 255
which is the time the server will do it 256 256
on its own without the scan administrator there 257 257
so they don't have access to those credentials as well. 258 258
So this is just another mitigation you can use, but again 259 259
the privilege access management solution 260 260
is a much better option, and one I highly recommend.