Trainer: Communicating risk. 2 2
Now, one of your jobs as a cybersecurity analyst 3 3
is to make sure you can explain risk 4 4
in plain and simple language. 5 5
Now, what do I mean by that? 6 6
Well, let's take the example of a denial of service attack. 7 7
Let's pretend you went into a meeting, 8 8
and there was a room with a bunch of executives in it, 9 9
and they look and you say, 10 10
"Hey, I heard you're a new cybersecurity analyst. 11 11
"Tell me, I heard there's a big threat out there 12 12
"of denial of service attacks. 13 13
"What exactly is that and how are we affected?" 14 14
Well, if you started saying the answer something like this, 15 15
"Well, a denial of service attack is a type of cyber attack, 16 16
"which is used to overwhelm a computer, a service, 17 17
"or a resource by providing extraneous information requests 18 18
"in a limited duration of time." 19 19
"Now, for example, during a SYN flood, 20 20
"there's this three-way handshake 21 21
"that's compromised by an attacker 22 22
"after initiating the handshake by sending a SYN request. 23 23
"but they never return the ACK request, 24 24
"and this doesn't allow 25 25
"a completed requested connection to occur." 26 26
Is that really simple? 27 27
Well, not really. 28 28
Instead, if you're talking to a bunch of executives, 29 29
you need to change it into something more simple, 30 30
something like this. 31 31
"A denial of service attack 32 32
"is a result of malicious activity 33 33
"against our public website. 34 34
"The site could become overloaded, 35 35
"it could prevent customers from accessing their accounts, 36 36
"and this could result in a loss of sales 37 37
"for up to two hours where we're dealing with it 38 38
"and a potential loss of revenue of up to $25,000 39 39
"based on our average daily sales volume." 40 40
Which one do you think is going to get you 41 41
more money and more budget for your cybersecurity 42 42
to be able to prevent a DoS attack? 43 43
Probably the second one, right? 44 44
Because the executives can understand that. 45 45
You put it in terms they understand. 46 46
It's this technical thing that you have now dumbed down, 47 47
for lack of a better term, 48 48
into simple things that affect them. 49 49
"It's when your site becomes overloaded. 50 50
"This prevents your customers from accessing their account. 51 51
"They can't give you money, 52 52
"and we're going to lose money, boss. 53 53
"Therefore, you need to give me money, 54 54
"so that we can go ahead 55 55
"and prevent these DoSes from occurring." 56 56
This is one of the main roles that you have 57 57
is to communicate risk in simple language, 58 58
so that your bosses and their executives 59 59
can understand what they're funding 60 60
because this communication is key. 61 61
When you communicate, 62 62
you need to think about 63 63
who the receiver of that communication is. 64 64
If you're talking to another technician, 65 65
the first answer was probably fine, 66 66
but if you're talking to executives and managers, 67 67
the second answer is much, much better. 68 68
Now, another way that we communicate 69 69
is using something known as a risk register. 70 70
A risk register is a document 71 71
that highlights the results of risk assessments 72 72
in easily comprehensible format. 73 73
Inside of this risk register, 74 74
you're going to document things like 75 75
the impact and likelihood ratings, 76 76
those high, medium and lows we talked about, 77 77
the date you identified the risk, 78 78
the description of the risk, 79 79
the countermeasures and controls, 80 80
who is the risk owner, 81 81
and how are they going to decide, 82 82
if we're going to accept, mitigate, 83 83
transfer, or avoid the risk. 84 84
And then we also need to think about the status. 85 85
Which of those are we doing and what is the plan of action? 86 86
If it's a mitigation, what controls are we putting in place? 87 87
All of these are things you're going to document 88 88
inside that risk register. 89 89
And the risk register really is a document 90 90
for management and executives to look over 91 91
and understand what their risk posture is 92 92
across the organization. 93 93
Now, this risk register needs to be shared 94 94
between the different stakeholders, 95 95
so they can understand what risks are associated 96 96
with the different workflows that they manage. 97 97
Like I said, 98 98
this is made for the managers and the executives. 99 99
It's not something you're going to create 100 100
and keep inside your own work group. 101 101
You need to make sure this is widely understood 102 102
where your risks are, 103 103
so they understand what risks they're taking on. 104 104
Any risk that's being accepted, 105 105
they need to understand what that is 106 106
'cause this is important for them. 107 107
Now, another thing we want to document 108 108
and communicate is our compensating controls. 109 109
Now, what is a compensating control? 110 110
Well, this is a type of security control 111 111
that acts as a substitute for a principal control. 112 112
Now, a principal control is just a primary control. 113 113
When dealing with a compensating control, 114 114
they're going to provide you 115 115
with the same or better level of protection, 116 116
but they're going to use a different methodology or technology. 117 117
For example, if your risk management framework states 118 118
that you have to install antivirus 119 119
on all of your workstations, 120 120
but for some reason, you can't install it on one of those, 121 121
you might choose to install an anti-malware solution instead 122 122
because anti-malware also includes antivirus. 123 123
And this would then be compensating control 124 124
because it meets or exceeds 125 125
the requirement having antivirus, 126 126
although you're using a different technology, 127 127
anti-malware in this particular situation. 128 128
Another good example of this might be, 129 129
if you wanted to have long strong passwords 130 130
for all of your systems, 131 131
that is what your requirement is going to say. 132 132
Everyone must have a 16 character long, strong password. 133 133
Well, that's great, except some devices, like SCADA and ICS, 134 134
might only support an eight character password, 135 135
so you can't get a long strong password on that system. 136 136
But maybe you're able to set up two-factor authentication 137 137
using a smart card and pin, and if you can, 138 138
that would be a compensating control 139 139
because a compensating control here 140 140
would be having two-factor or multi-factor authentication. 141 141
That is stronger than just using a password, 142 142
but we're using a different technology, 143 143
but we're still getting what we need out of the system. 144 144
Now, the third thing we need to consider is exceptions. 145 145
When we talk about exceptions, 146 146
we need to think about exception management. 147 147
When you're dealing with all your policies and procedures, 148 148
they're going to say you need to do certain things, 149 149
and sometimes, you simply can't. 150 150
These are going to be listed as an exception. 151 151
Exception management is a formal process 152 152
that's used to document each case 153 153
where a function or asset is non-compliant 154 154
with the written policy and procedural controls. 155 155
For example, you might have business processes 156 156
and assets that are affected. 157 157
You want to document that. 158 158
If I have this exception, 159 159
where this thing can't use a long strong password, 160 160
what is being affected by that? 161 161
Then I might think about what personnel are involved. 162 162
Because I don't have a long strong password, 163 163
we're going to end up changing it every 30 days 164 164
instead of every 60 days, because that way, 165 165
it gives us at least a little bit of a compensation. 166 166
We might think about the reason for the exception. 167 167
We have to have an exception for this system, 168 168
because it's an old ICS SCADA system, 169 169
and it can't support a long, strong password, 170 170
and it can't support two-factor authentication, 171 171
so we have to have an exception for it. 172 172
Somebody might ask, 173 173
"Why can't you just take the system offline?" 174 174
Well, this particular ICS SCADA system 175 175
might be running our entire manufacturing floor, 176 176
and if we take it offline, 177 177
we lose $1,000,000 a day in productivity, 178 178
so we're going to live with the fact 179 179
that it only has an eight character password. 180 180
These are the kind of things 181 181
you have to think about in the real world. 182 182
We're then going to look at a risk assessment. 183 183
We're going to look at that system and say, 184 184
"How bad is it by not having this one control? 185 185
"Do I have enough other controls that might mitigate it?" 186 186
Maybe I took that ICS SCADA system, 187 187
and I put it on its own VLAN, 188 188
and it's only accessible from the local network, 189 189
not from the internet, 190 190
and I put additional compensations in place. 191 191
And when I do a risk assessment for it, 192 192
I find out that this brings me down 193 193
to a lower level of risk, 194 194
and I'm willing to grant an exception. 195 195
I might think about compensating controls 196 196
that are being utilized. 197 197
Again, because I couldn't access the long strong password, 198 198
I put it on its own isolated network, 199 199
so nobody else can access that system directly. 200 200
Next, we have the duration of the exception. 201 201
How long are we going to exist in this accepted state? 202 202
In the case of this ICS SCADA system, 203 203
maybe we decide that we're going to give them 12 months, 204 204
because in that 12 months, we're going to have enough money, 205 205
and we have an upgrade coming 206 206
and that system's going to get replaced 207 207
with this newer system that has better security. 208 208
That's the idea here with the duration. 209 209
We don't want to let this run on indefinitely, 210 210
but it has to be a reasonable amount of time, 211 211
so they can get the money and get the system replaced. 212 212
And finally, what steps are needed to achieve compliance? 213 213
In the case of my fictitious ICS SCADA example, 214 214
we might need to upgrade from version two to version three, 215 215
and that costs us $1,000,000 for the new system, 216 216
and it takes six months to install. 217 217
So here's all the things, 218 218
we need to have budgeting in place, 219 219
we need to have approval in place. 220 220
We need to start ordering these things, 221 221
and there's this amount of lead time, 222 222
and we can start going through all of those things. 223 223
All of these are things you have to consider 224 224
as you're thinking about your exception management. 225 225
Now, the final thing to think about, 226 226
when you're talking about exception management, 227 227
is that if you have a certain policy or procedure 228 228
that's generating a lot of exception requests, 229 229
you need to step back and start thinking about, 230 230
do you need to redesign or reconsider that policy? 231 231
Sometimes somebody has a great idea 232 232
for a policy or procedure, they say, 233 233
"This is going to save us time, this is going to save us money, 234 234
"this is going to make us more secure," whatever it is. 235 235
But when you start putting it into practice, 236 236
you find out that your systems can't support it. 237 237
You don't have the capability, you don't have the knowledge, 238 238
you don't have the money or the resources, whatever it is, 239 239
and so people start putting in exception requests. 240 240
If you get one or two requests, that's probably okay, 241 241
we can work with those. 242 242
If you're getting hundreds or thousands 243 243
of requests across your organization, 244 244
this probably means it's a bad or stupid policy. 245 245
So go back and look at it, and if possible, 246 246
you might want to redesign that.