Instructor: Remediation issues. 2 2
In this lesson, we're going to talk about some of the issues 3 3
you may face when you try to remediate a vulnerability. 4 4
Now, there are numerous issues that can arise 5 5
during attempts to remediate a vulnerability, 6 6
and some of these you can control, 7 7
and some of them you can't. 8 8
For instance, you need to ask yourself, 9 9
is the risk high enough to spend time and money 10 10
on this particular issue? 11 11
Again, I've mentioned this before, 12 12
if it's a $10,000 problem, 13 13
you're not going to spend a million dollars to fix it. 14 14
And so it's going to be hard for you 15 15
to get the budgetary approval to fix that issue, 16 16
so that way, you wouldn't be able to remediate that issue. 17 17
Instead, you'd have to accept it. 18 18
You may ask yourself, 19 19
can I use a compensating control instead? 20 20
Well, possibly, depending on what that thing is. 21 21
For instance, if you have a web server 22 22
that's vulnerable on port 80, 23 23
you can't just shut down port 80 24 24
because you had stopped the function of the web server. 25 25
And so in that case, 26 26
a compensating control couldn't be used. 27 27
But there may be some other control you can put in place. 28 28
And so these are the things 29 29
you have to think about as you go forward. 30 30
Now, what are some of the main places that we have issues? 31 31
Well, we have issues with legacy systems 32 32
and proprietary systems. 33 33
We have issues with organizational governance. 34 34
We have issues with business process interruption, 35 35
degrading functionality, and MOU and SLAs. 36 36
In this lesson, we're going to talk about all of these topics. 37 37
Now, the first one is legacy systems. 38 38
What is a legacy system? 39 39
Well, I like to think about a legacy system 40 40
as something old. 41 41
It's a computer system that's no longer supported 42 42
by its vendor, and so no longer can be provided 43 43
with security updates and patches. 44 44
For instance, if you work in a manufacturing plant, 45 45
there might be some system that is critical 46 46
to your operations, but it is 20 or 30 years old, 47 47
and the person who made that is no longer in business. 48 48
Well, you're not going to get any more security updates 49 49
or patches for that thing, 50 50
but it still works and it still runs, 51 51
and it might cost you millions of dollars to replace it. 52 52
So what do you do? 53 53
Well, you don't patch it. 54 54
Instead, you start finding compensating controls 55 55
like isolating it onto its own network and things like that 56 56
to make sure that that system can keep running 57 57
and keep the business operating. 58 58
So when we're dealing with legacy systems, 59 59
we're dealing with these old systems 60 60
that are no longer supported. 61 61
On the other hand, we have another category systems 62 62
that are often not supported well, 63 63
and these are proprietary systems. 64 64
Proprietary systems are systems that are owned 65 65
by its developer or vendor where a lack of vendor support 66 66
could be an inhibitor to your remediation. 67 67
Now, what do I mean by this? 68 68
Well, I have a couple of proprietary systems in my business. 69 69
This particular software 70 70
that we have had coded by a developer. 71 71
Now, we don't actually have the coder on staff. 72 72
It's a third party company, 73 73
and so if we need to have updates and security done, 74 74
we have to contract them again to get them to support it, 75 75
because we pay them and they fix the system. 76 76
Now, that's one simple example of a proprietary system, 77 77
but there's actually larger ones too. 78 78
For example, if you look at the U.S. Department of Defense, 79 79
they've got lots of proprietary systems. 80 80
Not anyone can just go out 81 81
and buy an F16 or an Abrams tank. 82 82
These all have different systems that were built 83 83
specifically for that purpose. 84 84
And so they can't go to Microsoft and say, 85 85
"Hey, give me a patch for an Abrams tank." 86 86
Instead, they have to go back to that original vendor. 87 87
And depending on the contract they have 88 88
in place with that vendor, 89 89
they might get monthly updates or every six month updates 90 90
or every year updates or as required updates. 91 91
And so that can actually inhibit your remediation, 92 92
because if you're on a six-month cycle, 93 93
and you identify a vulnerability today, 94 94
it might take six months 95 95
for them to code you a patch and then send it to you. 96 96
So these are issues you have to think about 97 97
when you're dealing with proprietary systems. 98 98
Another hindrance for you is organizational governance. 99 99
Organizational governance is the system 100 100
by which an organization makes and implements decisions 101 101
in pursuit of its objectives. 102 102
Now, why would this be a hindrance? 103 103
Well, because a lot of organizations don't value security. 104 104
Now, if you work for a cybersecurity company, 105 105
they probably care about security, 106 106
but if you work for something like a hospital, 107 107
they care about security, 108 108
but that's not their top priority. 109 109
Their top priority is making sure 110 110
that patients get the healthcare they need. 111 111
And so these organizations tend to be run by doctors 112 112
and hospital administrators, not security professionals. 113 113
And so organizational governance may put you at bay 114 114
and say you can't patch those systems right now, 115 115
because what if you had to patch all the X-ray machines 116 116
in a hospital and it's going to take them down for two days? 117 117
They're not going to allow you to do that. 118 118
They're going to say, 119 119
we're just going to keep operating 'em, right? 120 120
And they would have to find out some alternate way 121 121
to be able to get those things patched, 122 122
because they can't take 'em all down at once. 123 123
And so this is the idea of organizational governance. 124 124
Sometimes, that organizational inertia, 125 125
that governance that tells you how you're going to do things 126 126
can really handcuff you as a cybersecurity professional. 127 127
So keep that in mind. 128 128
This brings us to another similar concept 129 129
known as business process interruption. 130 130
Now, business process interruption is any period of time 131 131
when an organization's way of doing business operations 132 132
is interrupted, and this can be caused by an outside force, 133 133
but it can also be caused by our own security personnel. 134 134
I mentioned previously, if you're going to install a patch 135 135
to a server and you have to reboot that server, 136 136
it might take 10 or 15 or 20 minutes 137 137
for that server to come back online. 138 138
During that 10 or 15 or 20 minutes, 139 139
that server isn't doing its job. 140 140
You have now interrupted the business process. 141 141
And so you would have to figure out 142 142
when is the best time to do this? 143 143
You may find out at two in the afternoon, 144 144
this thing needs to be patched right now. 145 145
But your business doesn't close till 11 at night. 146 146
What are you going to do? 147 147
Most likely, you're going to try to put 148 148
some kind of compensation in place, 149 149
additional monitoring in place, 150 150
and wait until the business is closed 151 151
and then do the update overnight. 152 152
This is why a lot of security people end up working 153 153
overnight shifts because we're working 154 154
while the other people in the business are actually sleeping 155 155
because what we do could affect their business. 156 156
Now, this becomes harder 157 157
when you start dealing with 24/7 operations. 158 158
Amazon.com never sleeps. 159 159
Diontraining.com never sleeps. 160 160
It's available 24 hours a day. 161 161
So we had to build our systems in place 162 162
so that we can work through these problems, 163 163
and we can still do our security patching and updating 164 164
without interrupting our business processes. 165 165
Another thing you have to worry about 166 166
is degrading functionality. 167 167
Now, degrading functionality is a period of time 168 168
when the organization systems are not performing 169 169
at peak functionality, and this could lead 170 170
to business process interruption. 171 171
For instance, let's say I have two web servers 172 172
that are forward-facing to the internet, 173 173
and then they're behind a load balancer. 174 174
Can I take one down and patch it 175 175
while the other one carries a load? 176 176
Yes, I can, but I'm now going to be in a degraded condition, 177 177
because I only have half of my capacity 178 178
while the one is offline being repaired. 179 179
Then when I bring it online, 180 180
I can bring the other one offline and do the same thing. 181 181
That's one way that we do our patching of our systems 182 182
is that way, we can take one offline, 183 183
patch it and bring it back on. 184 184
By doing that, because we have the redundancy built in, 185 185
we can minimize our business process interruption. 186 186
But if that one server that was online went offline 187 187
because of an availability attack at that time, 188 188
we would then be completely down. 189 189
So we are operating in degraded functionality. 190 190
We are only one of two servers up 191 191
instead of two of two servers up, 192 192
so we lost our redundancy there. 193 193
That's the idea of degrading functionality. 194 194
The next concept we have to talk about 195 195
is memorandums of understandings or MOUs. 196 196
An MOU usually is a preliminary 197 197
or exploratory agreement to express an intent 198 198
to work together that is not legally binding 199 199
and does not involve the exchange of money. 200 200
Essentially, I like to call these handshake deals. 201 201
They're not contractually binding, 202 202
but I've used a lot of MOU in my day. 203 203
For instance, early in my career, 204 204
I was based out of one building, 205 205
and I worked with another competitor 206 206
who happened to be based out of a different building. 207 207
And we had an MOU 208 208
that if there was some kind of a major outage, 209 209
and my facility was down on power and their facility wasn't, 210 210
we could actually come over to their facility and work. 211 211
And the same thing that if their facility was down 212 212
and ours was up, they would come over to us and work. 213 213
And so we had this friendly competitiveness between us 214 214
where we actually helped each other, 215 215
'cause we weren't direct competitors, 216 216
but we were in the same general business space. 217 217
And so we had a lot of the same equipment, 218 218
a lot of the same phone lines, 219 219
a lot of the same computer systems, 220 220
and so that worked out well. 221 221
But there was really nothing to hold either of us to it. 222 222
If it was really bad day and their power went out 223 223
and my guys were all busy, I would say, 224 224
"Sorry, I've got no room for you." 225 225
There's nothing you can do about it. 226 226
There was no contract, right? 227 227
And so that's the idea of an MOU. 228 228
It's just kind of a gentleman's agreement, if you will, 229 229
or a handshake deal. 230 230
Now, on the other side of things, 231 231
we have a service level agreement, 232 232
and this is really where you want to get to 233 233
when you're starting to deal 234 234
with third party contractors and vendors. 235 235
This is a contractual agreement 236 236
that sets out the detailed terms 237 237
under which an ongoing service will be provided. 238 238
So if I'm going to buy a proprietary system from somebody, 239 239
I shouldn't have an MOU that tells me 240 240
how they're going to support me. 241 241
I should have an SLA. 242 242
That SLA should give us terms 243 243
for what kind of patch support they're going to give us 244 244
and what kind of forensic support 245 245
and instant response support and things like that. 246 246
Anything can be contractually binding inside of this SLA. 247 247
For instance, I have an SLA 248 248
with my underlying service provider for our website. 249 249
They have a 99.99% uptime. 250 250
Now, if they don't maintain that 99.99% uptime, 251 251
that means they're actually going to have to refund us money, 252 252
because they're not meeting their portion of the SLA. 253 253
That's the idea of an SLA. 254 254
There are terms and there are consequences 255 255
if that agreement is broken because it is a contract.