1
00:00:00,000 --> 00:00:13,520
Specifically, I work in the Information Systems Technology Program, which is a, it's a very applied approach to engineering, and specifically information technology systems.

2
00:00:13,520 --> 00:00:28,180
We're currently at the University of Central Florida developing a undergraduate security program that I'm also, I'm the one that's mainly involved in developing that, and that's actually what my second talk a little bit later is on today.

3
00:00:28,180 --> 00:00:32,470
But this is the more, maybe more interesting, more technical one.

4
00:00:32,760 --> 00:00:40,860
My past research includes the correlation of distributed, distributed network sensors.

5
00:00:40,860 --> 00:00:52,180
If you have a, if you have a large scale network, you have intrusion detection systems, you have firewalls, you have other things that are recording information saying what's going on on the network.

6
00:00:52,180 --> 00:01:04,240
Trying to correlate that information together, to bring it all together and trying to see the big picture of what's going on, rather than getting these little kind of half views of what's really occurring out on the network.

7
00:01:04,240 --> 00:01:12,400
And also I'm working on some projects that involve combined data sharing networks for law enforcement in the state of Florida.

8
00:01:13,860 --> 00:01:18,800
You know, this little blurb ad about the University of Central Florida, it's down in Orlando, Florida.

9
00:01:18,800 --> 00:01:23,540
It's about, we've got about 42,000 students there, about 5,500 of which are in engineering.

10
00:01:23,620 --> 00:01:27,980
We're located about 13 miles east of Orlando, Florida.

11
00:01:29,760 --> 00:01:36,060
As I said, the Information Systems Technology Program, this is a really, it's an applied engineering degree.

12
00:01:36,060 --> 00:01:43,780
It's very hands-on, very real world, very current tools, not so much the traditional theoretical approach to engineering.

13
00:01:45,000 --> 00:01:48,420
A heavy concentration of hands-on learning in the program.

14
00:01:49,440 --> 00:01:56,720
A little bit about the background of what led me to this current idea.

15
00:01:57,620 --> 00:02:03,960
There was a previous research that I worked on, I gave a couple of presentations back at DEF CON 9 and 10.

16
00:02:03,960 --> 00:02:13,680
And this was on using Bayesian multiple hypothesis to try and analyze reports from these distributed intrusion detection systems and other types of network sensors.

17
00:02:13,680 --> 00:02:29,400
With the idea of trying to determine if what you were seeing were correlated events, if this was an initial attack and a follow-up, or if the two events you were seeing in two different places might be two systems communicating who shouldn't be communicating together.

18
00:02:29,400 --> 00:02:35,300
And to try and use multiple sensors to distribute over large distributed networks to try and do this.

19
00:02:35,300 --> 00:02:54,900
The basic idea behind what I was doing with that was taking target tracking methods that came out of radar target tracking systems, trying to track real objects in the sky with various radar systems, and taking that same approach and treating all of our sensors that we have on our network,

20
00:02:54,900 --> 00:03:04,400
whether it's an IDS, a firewall, a router, even a human sat there making observations about what's going on and trying to automate the correlation of that together.

21
00:03:04,400 --> 00:03:17,520
And this wasn't intended to totally throw the human analyst out of the loop, but just to kind of act as a sort of a first level filtering system to throw away a lot of the information that you don't need in order to come to a conclusion about what's going on.

22
00:03:18,240 --> 00:03:31,840
With the idea that we were going to kind of move this more towards a point of view, instead of looking at this one section of the network or this one part of what was going on that's visible to this one sensor, like, you know, you've got your firewall sat at the,

23
00:03:31,840 --> 00:03:33,560
say you've got it sat at the border of your network.

24
00:03:33,560 --> 00:03:35,680
It sees everything that's coming in and out of the border.

25
00:03:35,680 --> 00:03:38,500
But it doesn't see stuff that's entirely internal to the network.

26
00:03:38,580 --> 00:03:45,580
You might have an intrusion detection system sat on one segment of the network that sees what's going on there, but it doesn't see what's going on on another segment of the network.

27
00:03:45,580 --> 00:04:02,900
And to take all these little pictures, pieces of information, and to put them together to get a more complete view of what someone was doing while they were attacking the network, and did this through using radar tracking algorithms, specifically Bayesian multiple hypothesis tracking,

28
00:04:02,900 --> 00:04:15,860
and making an analogy to the world of computer security, where our firewalls, our IDS, our humans looking at what's going on on the network, anything that records information is a sensor.

29
00:04:15,860 --> 00:04:17,480
That's like a radar system.

30
00:04:17,480 --> 00:04:24,760
The actions that the person out there trying to break into the network are doing, that's the target, and that's the trace they leave behind.

31
00:04:25,080 --> 00:04:27,280
They're trying to put these traces together.

32
00:04:27,280 --> 00:04:30,760
And we're working in a situation where we've got to do this in real time.

33
00:04:30,760 --> 00:04:32,280
We've got incomplete data.

34
00:04:32,280 --> 00:04:37,300
We've got inaccurate data, potentially, about what's going on, depending on how your sensors are operating.

35
00:04:39,020 --> 00:04:43,800
Just a little bit more about the system.

36
00:04:46,120 --> 00:04:57,460
How this works, this idea of this multiple hypothesis tracking, is as events occur on the network, as an event is when a sensor recognizes that something's occurring.

37
00:04:57,460 --> 00:05:04,400
When something actually pops up on the sensor, when it gives a report, when you've got an IDS that tells you, hey, I think I see something.

38
00:05:04,400 --> 00:05:09,160
When you've got a firewall that decides it's not going to allow this packet or it sees something unusual.

39
00:05:09,160 --> 00:05:14,220
When you've got your sysadmin on your network saying, hey, you know, something weird's going on here.

40
00:05:14,220 --> 00:05:17,220
As these events arrive, they're analyzed.

41
00:05:17,220 --> 00:05:22,520
And say, for example, we're sat there, and one of our systems sees a port scan happening out there.

42
00:05:23,040 --> 00:05:27,020
We build a hypothesis about what we think's going on.

43
00:05:27,020 --> 00:05:34,260
In this case, if we've got a single scan coming in from the outside world, hey, you know, that's all the information we have.

44
00:05:34,260 --> 00:05:38,240
That's the only hypothesis we can come to, is that that's what's going on.

45
00:05:38,240 --> 00:05:40,300
We're seeing a port scan right now.

46
00:05:40,560 --> 00:05:44,380
Really, I guess, actually, technically, you can make two hypotheses at this point.

47
00:05:44,380 --> 00:05:52,580
You can say, hey, there's a port scan going on, or alternatively, my IDS isn't working properly, and this is a false positive.

48
00:05:53,580 --> 00:05:59,900
Then, as other events occur, say you see a buffer overflow attack against a machine following that.

49
00:06:00,140 --> 00:06:02,400
Well, what could be going on now?

50
00:06:02,400 --> 00:06:07,600
We could make the assumption that the port scan is being followed up by a buffer overflow.

51
00:06:07,600 --> 00:06:12,320
Someone scanned a machine for a vulnerability, then they attacked that particular vulnerability on it.

52
00:06:12,320 --> 00:06:22,640
Or, potentially, these could be two unrelated events, that the port scan could be part of one attack, the buffer overflow could be part of a different attack.

53
00:06:22,660 --> 00:06:24,220
On the system.

54
00:06:26,060 --> 00:06:31,240
And what we were trying to do with this system was trying to automate the process of figuring these out.

55
00:06:31,240 --> 00:06:33,700
Now, this is a simple example.

56
00:06:33,700 --> 00:06:35,560
This is a pretty trivial case.

57
00:06:35,580 --> 00:06:50,440
In this particular case, if the port scan is a scan against, you know, I don't know, against port 80, and the buffer overflow is a buffer overflow against an IIS server, chances are those two things are related.

58
00:06:50,440 --> 00:06:55,520
If they're not, if the port scan doesn't match up with what the buffer overflow was, chances are they're not related.

59
00:06:55,520 --> 00:07:12,960
But, you can extrapolate from this idea into much more complicated systems, and much more complicated series of events, of trying to piece together the pieces and figure out whether or not all of these events and all of these things that we see occurring across the network are related together,

60
00:07:12,960 --> 00:07:25,080
are they not related together, are they likely to be something real, are they likely to be a false positive caused by a imperfect sensor, or imperfect IDS, or firewall, or human in the loop.

61
00:07:26,980 --> 00:07:35,240
Actually, when I was working on this, one of the most interesting sources of data that I had to work with came from the Capture the Flag games here at DEF CON.

62
00:07:35,240 --> 00:07:40,040
Luckily, the SHMOO group captures all of that data that goes on during the Capture the Flag game.

63
00:07:40,040 --> 00:07:49,540
They capture all of that network traffic, and that provided a great playground to work in, to try and see if that information could be correlated together.

64
00:07:49,540 --> 00:07:53,340
And this little graph I got up here, I mean, this is kind of just pulled right out of context.

65
00:07:53,340 --> 00:08:00,440
These are some slides I grabbed just to give a bit of background about the previous research in this.

66
00:08:01,760 --> 00:08:23,880
Basically, what this was showing is, as you let the number of hypotheses that you consider increase, in that previous example I said, excuse me, I said that we had the two hypotheses either these two events are unrelated, or these two events are part of a chain of a single attack.

67
00:08:24,180 --> 00:08:35,560
Well, we let those, we say these are our two hypotheses, and then we look at the evidence that's going on, and we evaluate them, and we find out which hypothesis we think is currently the best one we have available.

68
00:08:35,920 --> 00:08:39,040
Then, we wait for more information to come in.

69
00:08:39,040 --> 00:08:43,440
We'll have a certain confidence level, and how confident do we believe in this hypothesis?

70
00:08:44,060 --> 00:08:53,120
As more information comes in, we'll build more hypotheses, and we re-evaluate the likelihood of our existing hypotheses.

71
00:08:53,180 --> 00:09:04,420
Eventually, at least in theory, this will eventually converge to a point where one hypothesis is clearly the winning hypothesis.

72
00:09:04,420 --> 00:09:15,860
Now, the problem with, I said that's in theory, the problem with that is, you have to consider every possible hypothesis in order to do that, and the number of hypotheses grows at a super exponential rate.

73
00:09:15,880 --> 00:09:18,680
So, it's practically impossible to do that.

74
00:09:18,680 --> 00:09:23,840
There's a lot of work on the pruning of them, deciding which ones you want to keep, which ones you want to throw away.

75
00:09:23,980 --> 00:09:39,980
And what this graph is just showing here was, along the bottom is a number of hypotheses that were allowed to remain in the system, going from, well, at the bottom one, all the way up to a thousand, and the accuracy of how well it correlated the different attacks together.

76
00:09:40,020 --> 00:09:53,320
And it never quite got up to 100%, but it got up into about 93, 94% accuracy on the capture-the-flag data, being able to piece together what were related attacks.

77
00:09:53,320 --> 00:10:13,160
And now, of course, this was actually correlated against the baseline was done by hand, taking me, I and a few others that helped me, took the data over the capture-the-flag game over about a, I think it was about an eight-hour period, and by hand figured out what was related information,

78
00:10:13,160 --> 00:10:18,840
what were related attacks, and then built a system that could do, to automate that process.

79
00:10:18,840 --> 00:10:21,280
So this thing, it worked.

80
00:10:21,280 --> 00:10:23,880
This was a, it was a pretty decent idea.

81
00:10:23,880 --> 00:10:24,720
It worked.

82
00:10:24,720 --> 00:10:28,400
It didn't necessarily work as well as we had hoped initially.

83
00:10:29,760 --> 00:10:36,940
If you've got everything on a same network, or related network, where you're likely to see lots of related events, it works well.

84
00:10:36,940 --> 00:10:46,400
If you've got this distributed over large networks, where you're likely to see many more unrelated events than related events, it goes, the accuracy goes down a bit.

85
00:10:46,400 --> 00:10:50,300
Or at least the amount of work you have to do to get good accuracy goes way up.

86
00:10:50,300 --> 00:10:51,420
It's more accurate.

87
00:10:51,420 --> 00:10:53,080
It's more accurate to say.

88
00:10:54,340 --> 00:10:57,200
So that's what it had done in the past.

89
00:10:57,480 --> 00:11:07,060
And this got me thinking about, so this was a system that had developed to try and detect related information on a network.

90
00:11:07,140 --> 00:11:10,440
And then, of course, you know, once you can do that, you always think about the next step.

91
00:11:10,440 --> 00:11:15,340
And once the next step, once you can detect something, you figure out how to hide it even better.

92
00:11:15,660 --> 00:11:16,060
Right?

93
00:11:16,060 --> 00:11:19,480
You know, it's always kind of that one-upmanship game that we're playing.

94
00:11:19,480 --> 00:11:24,000
So it got me thinking, how do we defeat a system that works like that?

95
00:11:24,000 --> 00:11:40,880
How could you avoid detection on a network that was well-observed, well-monitored, and where the information was well-correlated, where you couldn't rely on the guy sat over on this part of the network not knowing what the guy sat over on this other part of the network was doing,

96
00:11:40,880 --> 00:11:43,340
or seeing, or knew about what was going on?

97
00:11:43,340 --> 00:11:49,360
If you assume that there was complete coverage of the network, how could you hide what was going on on there?

98
00:11:49,360 --> 00:11:59,280
And I'm not necessarily, I'm not talking about so much the detection of a specific attack, like someone does a buffer overflow against a web server.

99
00:11:59,280 --> 00:12:04,460
They do, you know, whatever other type of initial attack to gain access to the system.

100
00:12:04,460 --> 00:12:06,280
But assuming they're already on there.

101
00:12:06,280 --> 00:12:10,700
They've got onto the system, and they want to be communicating back and forth.

102
00:12:10,700 --> 00:12:14,480
They've got their remote machine they're sat at.

103
00:12:14,480 --> 00:12:16,480
They've got access to a machine on the network.

104
00:12:16,480 --> 00:12:20,200
They want to communicate back and forth, but they don't want to be detected while doing it.

105
00:12:20,200 --> 00:12:25,860
How could you go about that and avoid detection on a well-monitored network?

106
00:12:27,900 --> 00:12:32,780
So you have to look at this from the point of view of where do we have the choices about what we do?

107
00:12:33,020 --> 00:12:37,160
When you're talking about the initial attack, you don't have a whole lot of choices.

108
00:12:37,160 --> 00:12:44,700
If you've got a, you know, I guess, I mean, I guess, unless you get lucky and you see a system out there that's got a ton of vulnerabilities on it, then you've got some choices about what to do.

109
00:12:44,700 --> 00:12:49,160
But assume that you have limited choices of how a system is broken into.

110
00:12:49,160 --> 00:12:51,740
There's limited ways into the system to begin with.

111
00:12:51,740 --> 00:12:53,460
You don't have many choices there.

112
00:12:53,820 --> 00:13:02,840
So any tool that's written to initially gain access to a system usually has a fairly limited lifespan.

113
00:13:02,980 --> 00:13:09,280
At least it's limited lifespan in the range of people who actually care about security.

114
00:13:09,280 --> 00:13:14,520
You always find some bozo out there who never updates anything, never puts any security on their system.

115
00:13:14,520 --> 00:13:15,840
You can always get into them.

116
00:13:15,840 --> 00:13:21,800
But talking about the people who are serious about it, you have a limited lifespan with any sort of tool for initially getting in there.

117
00:13:22,760 --> 00:13:29,840
However, once you have access to a machine and all you're worried about doing is communicating with that machine, you've got a lot of choices.

118
00:13:29,840 --> 00:13:32,680
You know, we're not stuck with one type of communication protocol.

119
00:13:32,680 --> 00:13:37,120
We're not stuck with any traditional communication protocol that's out there whatsoever.

120
00:13:38,740 --> 00:13:45,180
The trick to this is figuring out which ones work and which ones won't be seen.

121
00:13:49,080 --> 00:13:50,960
So here's the question.

122
00:13:50,960 --> 00:13:54,700
How do you communicate on a network without letting anyone know you're doing it?

123
00:13:55,160 --> 00:13:56,680
First things first.

124
00:13:57,860 --> 00:14:00,180
How do they detect what's going on?

125
00:14:00,180 --> 00:14:03,260
How does someone see what you're doing on a network?

126
00:14:03,260 --> 00:14:04,280
You've got IDS.

127
00:14:04,280 --> 00:14:05,040
You've got firewalls.

128
00:14:05,040 --> 00:14:06,260
You've got observers.

129
00:14:09,300 --> 00:14:10,680
What's going on on the network?

130
00:14:12,320 --> 00:14:23,720
In general, I pick the IDS and I say software or human because whatever's looking at your network, whether it's automated or whether it's a person, they're trying to determine if someone's intruding on your network.

131
00:14:24,200 --> 00:14:25,760
You get two basic forms of this.

132
00:14:25,760 --> 00:14:27,300
And this applies...

133
00:14:28,020 --> 00:14:32,780
I think the IDS system, in at least one sense, is the most general case.

134
00:14:32,780 --> 00:14:39,800
And you can kind of find derivative cases that cover the same concept for firewalls and routers and everything else out there.

135
00:14:39,800 --> 00:14:42,200
There's basically two forms of detection out there.

136
00:14:42,300 --> 00:14:44,160
Anomaly and signature detection.

137
00:14:44,360 --> 00:14:47,980
Signature detection works on known attacks, known events.

138
00:14:48,000 --> 00:14:54,780
You know, if you know exactly what you're looking for, you know when you see this packet go by, it's something bad, you want to throw up an alert about it.

139
00:14:54,780 --> 00:14:56,920
Hey, that's great, you can catch it every time.

140
00:14:56,920 --> 00:14:58,400
It'll never get by.

141
00:14:58,400 --> 00:15:00,320
You know, you've got that one nailed.

142
00:15:00,860 --> 00:15:10,360
The only way to avoid that type of detection is to use either an unknown method or something perhaps that changes constantly, and never use the same method twice.

143
00:15:11,840 --> 00:15:15,640
The anomaly detection, it doesn't detect misuse of the system.

144
00:15:15,640 --> 00:15:17,140
It doesn't detect something malicious.

145
00:15:17,140 --> 00:15:19,160
It just detects something unusual.

146
00:15:19,560 --> 00:15:29,920
So it's not necessarily really great at trying to pick up something bad happening on your network, but it'll pick up something unusual.

147
00:15:30,320 --> 00:15:36,340
And it's really, if the signature detection doesn't work, that's the only chance you have left, is looking for something unusual.

148
00:15:36,340 --> 00:15:39,780
If you don't know what to look for, look for things that stand out.

149
00:15:41,480 --> 00:15:44,840
So we can't really avoid the signature detection.

150
00:15:44,840 --> 00:15:51,480
If you've got a way of communicating, or a way of doing anything on the network, and someone can write a signature to detect that, that's it.

151
00:15:51,480 --> 00:15:53,380
You can't do anything with it.

152
00:15:53,380 --> 00:15:54,800
It's got a limited lifespan.

153
00:15:54,900 --> 00:15:56,800
Eventually it's going to be seen.

154
00:15:58,580 --> 00:16:13,860
So the only alternative is to use something that you can't write a signature for, something that changes constantly, quote-unquote random, or at least appears random to anything that's observing the network.

155
00:16:14,200 --> 00:16:18,260
And we have to be able to do this without looking unusual.

156
00:16:18,260 --> 00:16:19,040
And that's the key.

157
00:16:19,040 --> 00:16:31,200
Not only do we have to do something, it's kind of a catch-22 in a way, because we've got to do something that's very unusual, you know, this kind of random changing communication protocol, but we've got to do it without looking unusual.

158
00:16:31,200 --> 00:16:33,900
You can't stand out on there.

159
00:16:33,900 --> 00:16:38,320
So the first stage of this is to detect the baseline of the network.

160
00:16:38,340 --> 00:16:43,020
What does the traffic on the network look like to begin with?

161
00:16:43,020 --> 00:16:45,720
What is occurring on the network?

162
00:16:45,720 --> 00:16:48,340
What happens out there all the time?

163
00:16:48,340 --> 00:16:50,000
And this can be done passively.

164
00:16:50,000 --> 00:17:06,040
You can sit back and discover what type of traffic is allowed on the network, what does normal traffic look like, and kind of build yourself a map of both what is going on on the network, what the structure of the network is, and what's allowed in and out of this network.

165
00:17:07,480 --> 00:17:09,260
This is not a new concept.

166
00:17:09,480 --> 00:17:11,500
It's just this general idea of doing this.

167
00:17:11,500 --> 00:17:12,560
This is done all the time.

168
00:17:12,560 --> 00:17:19,320
This is how many tools and other fun little things are written and developed.

169
00:17:19,340 --> 00:17:27,440
But the key thing is that this is what, generally, this is what people do this process.

170
00:17:27,500 --> 00:17:31,620
Someone looks at a network or you think about what's going on on the network.

171
00:17:31,980 --> 00:17:34,500
You know, a good example of this is a reverse WWW shell.

172
00:17:34,500 --> 00:17:35,940
That's an old tool.

173
00:17:36,040 --> 00:17:40,380
The idea of this was that you've got a computer inside the network.

174
00:17:41,160 --> 00:17:44,140
You're not allowed to make connections from the outside to it.

175
00:17:44,140 --> 00:17:48,100
You know, the firewall is going to drop any inbound connections to it.

176
00:17:48,100 --> 00:17:56,780
So you put a piece of software on that computer inside the network that at certain intervals, perhaps at random intervals, it looks like it's going out to a web browser.

177
00:17:56,780 --> 00:17:58,420
It goes and makes a web request.

178
00:17:58,420 --> 00:18:07,280
Except that what that web request is doing is coming to your computer on the outside, getting the next command that you've told it to do.

179
00:18:07,280 --> 00:18:17,440
It carries it back as the HTTP response to the target computer, to the one that you got access to, and then it carries out that particular command.

180
00:18:17,440 --> 00:18:21,640
It's masqueraded looking like the computer on the inside is just surfing the web.

181
00:18:22,180 --> 00:18:25,460
That's a great way of hiding it, unless someone knows to look for it.

182
00:18:25,460 --> 00:18:30,800
Once someone knows to look for it, if you stick with it too long, they're going to look for it, they're going to see it, it's going to stand out.

183
00:18:31,520 --> 00:18:38,280
Similarly, carrying data commands and ICMP echo response packets, same sort of idea.

184
00:18:38,400 --> 00:18:51,460
What I'm trying to do with this project is to automate this process and make it run on the fly and have it adapt itself to whatever network it's currently working on.

185
00:18:51,460 --> 00:18:58,680
Look at what's going on on the network, decide what to do on the network, decide what will work there, and then carry it out.

186
00:19:02,900 --> 00:19:07,980
Some aspects of network traffic are going to have a low entropy, meaning a very low randomness.

187
00:19:07,980 --> 00:19:12,780
They're going to be very kind of, the same thing is always going to happen.

188
00:19:13,520 --> 00:19:16,500
Certain communication protocols are only going to go to certain computers.

189
00:19:16,580 --> 00:19:19,100
DNS requests are only going to go to your DNS servers.

190
00:19:19,100 --> 00:19:21,560
They're not going to be jumping around to every computer on your network.

191
00:19:22,180 --> 00:19:25,000
Incoming web requests are probably only going to come to your web server.

192
00:19:25,000 --> 00:19:26,960
They're not going to come to every computer on your network.

193
00:19:27,300 --> 00:19:28,660
Other things are going to look like this.

194
00:19:28,680 --> 00:19:30,320
They're going to be much more random.

195
00:19:30,320 --> 00:19:34,940
Maybe outgoing web requests, you know, people, different people circling the web.

196
00:19:35,280 --> 00:19:37,820
Outgoing FTP, all sorts of things.

197
00:19:37,820 --> 00:19:39,620
Other things are going to be very random.

198
00:19:39,620 --> 00:19:42,100
There's going to be a lot more entropy in that.

199
00:19:42,580 --> 00:19:46,700
And entropy is the key to hiding information.

200
00:19:47,040 --> 00:19:54,020
The more entropy you have on the system, the more information you can hide in that.

201
00:19:54,020 --> 00:20:03,380
This is like if you look at, if you look at a system like a steganography, for example, you know, you're trying to hide information in something else.

202
00:20:03,380 --> 00:20:10,240
If you've got a bitmap, a bitmap has lots and lots of redundant information in it versus a JPEG image.

203
00:20:10,240 --> 00:20:12,920
A JPEG has taken a lot of that redundant information out.

204
00:20:12,920 --> 00:20:15,040
That's why a JPEG is smaller than a bitmap.

205
00:20:15,120 --> 00:20:18,620
You can hide a lot more information in a bitmap than you can in a JPEG.

206
00:20:18,620 --> 00:20:21,560
Higher entropy, you can hide more information inside it.

207
00:20:21,620 --> 00:20:32,360
So if we find what has the highest entropy on that network, what communication channels have the highest degree of randomness, we can then pick what we want to work in.

208
00:20:32,360 --> 00:20:36,280
And we've got all sorts of, all sorts of things that we can work with here.

209
00:20:36,280 --> 00:20:45,120
We can work with the timing of the packets, we can work with packets, sending out packets that have bad checksums, malformed checksums, all sorts of different things that we can play with.

210
00:20:45,120 --> 00:20:51,400
We don't have to use a SSH or Telnet or some other standard type of communication format.

211
00:20:51,400 --> 00:20:59,340
We can send crafted packets where the information is carried in all sorts of different little pieces of information inside that packet.

212
00:20:59,340 --> 00:21:04,720
The key is, we just have to make sure it doesn't look unusual when that packet goes out.

213
00:21:05,120 --> 00:21:10,080
So the overall concept here is we detect what the network baseline condition is.

214
00:21:10,080 --> 00:21:14,280
On the specific network that we're looking at, what does normal look like?

215
00:21:14,280 --> 00:21:16,140
What doesn't look unusual?

216
00:21:16,240 --> 00:21:20,240
And then select from that the potential communication channels.

217
00:21:20,240 --> 00:21:24,920
Determine which ones have highly random information on the network.

218
00:21:24,940 --> 00:21:26,340
Prune it down.

219
00:21:27,300 --> 00:21:29,160
Initially, we can select from anything.

220
00:21:29,160 --> 00:21:31,720
We can craft a packet that does anything we want.

221
00:21:31,780 --> 00:21:39,940
We're going to look at what happens on the network, figure out what's allowed, limit it to that, and then limit it to what has a lot of entropy within that.

222
00:21:40,020 --> 00:21:43,700
And then we have to somehow communicate this method to the receiver on the outside.

223
00:21:43,700 --> 00:21:48,320
We have to get the information of what communication scheme we're going to use.

224
00:21:48,320 --> 00:21:55,140
We have to get that to the receiver outside and then maintain a, you know, I put almost undetectable presence on the network.

225
00:21:55,140 --> 00:21:57,240
You never should think you're undetectable.

226
00:21:57,240 --> 00:21:59,460
You should never think anything's absolute because it never is.

227
00:21:59,460 --> 00:22:01,340
That's how you always get yourself into trouble.

228
00:22:01,600 --> 00:22:05,900
But we can monitor and update the network conditions to stay hidden.

229
00:22:05,900 --> 00:22:09,760
If the network conditions change, we can change the scheme we're using to communicate.

230
00:22:11,580 --> 00:22:16,680
On the network, if we just sit there and listen, what can we learn by listening on the network?

231
00:22:16,680 --> 00:22:24,860
There's all sorts of things that we can find out by just sitting there and listening, not doing anything active, not doing anything to be discovered.

232
00:22:24,860 --> 00:22:30,180
We can figure out what types of packets are allowed inside the network, what types of packets are allowed outside the network.

233
00:22:30,180 --> 00:22:32,360
We can figure out the architecture of the network.

234
00:22:32,380 --> 00:22:33,260
Where are the switches?

235
00:22:33,260 --> 00:22:34,360
Where are the routers?

236
00:22:34,360 --> 00:22:36,720
Where are other machines on this network?

237
00:22:36,920 --> 00:22:39,920
And then look at what types of packets are flying around.

238
00:22:39,920 --> 00:22:43,260
What types of packets does the machine that I'm on send and receive?

239
00:22:43,260 --> 00:22:46,280
What types of packets do other machines out there send and receive?

240
00:22:46,280 --> 00:23:02,900
And from this, get an idea of what is allowed to move around this network, what is moving around this network, and what we can inject into the data flowing around without being, without sticking out like a sore thumb and being immediately identified.

241
00:23:04,120 --> 00:23:09,640
So if we narrow down these choices, we start with the ability to send any type of packet, you know, send it to any port whatsoever.

242
00:23:10,220 --> 00:23:14,520
We start paring it down based on what's available, figure out what has the highest entropy.

243
00:23:15,240 --> 00:23:21,480
Look at this, look at the type of packets based on the protocol the ports are using.

244
00:23:22,180 --> 00:23:26,480
And look at the entropy based on how often do these packets fly?

245
00:23:26,480 --> 00:23:29,800
How different is the data in these packets whenever they go by?

246
00:23:29,800 --> 00:23:32,600
What different machines do these types of packets go to?

247
00:23:32,600 --> 00:23:36,940
And then pick a channel that we know we can get from point A to point B.

248
00:23:36,940 --> 00:23:46,840
We can get from inside the network we've got access to the machine on, out of that network over to the place where we want to get the information to, or back and forth, vice versa, either way.

249
00:23:46,840 --> 00:23:52,420
We can figure out what can get into one, out of one network, into another, and then back the other way.

250
00:23:52,420 --> 00:23:55,200
It doesn't necessarily have to be a symmetric communication channel.

251
00:23:55,300 --> 00:24:02,560
The packets that you send out, the packets that you send going out one way, don't have to look a heck of a lot like the packets coming back in the other way.

252
00:24:02,560 --> 00:24:18,980
As long as they're getting to the right segment on the network, as long as they're getting down to the right branch off of your switch so that it can be picked up by a, by a network card in promiscuous mode, as long as you can get down that far and you know what to look for,

253
00:24:18,980 --> 00:24:24,300
each guy on each end knows what to look for, you don't have to have it even be a symmetric communication channel between them.

254
00:24:24,300 --> 00:24:28,360
You can have essentially two different channels going back and forth.

255
00:24:30,320 --> 00:24:36,700
One of the big challenges with this system is starting the conversation.

256
00:24:36,860 --> 00:24:48,500
If you've got a piece of software running on the inside of this network, and it's going to start communicating with you on the outside, and you don't know what particular communication scheme it's going to be using, there's some difficulties in getting,

257
00:24:48,500 --> 00:24:57,020
in getting that first packet out of there, that first piece of information to the outside, without having it be something that can easily be written as a signature.

258
00:24:57,020 --> 00:25:05,020
Because it's hard to, it's hard to change things or inject randomness into the first bit of communication.

259
00:25:05,020 --> 00:25:20,500
There's some, there's some ways that we can limit how signature vulnerable that first bit of communication is, but that's one of, that is, that's one of the points that needs, that presents some challenge and needs some work on in this.

260
00:25:21,680 --> 00:25:29,800
Having the communication software itself remain undetected on the remote machine, not talking about what the software is doing, but actually having the software itself avoid detection.

261
00:25:29,800 --> 00:25:33,380
Of course, that's another challenge, but that's a completely different story.

262
00:25:34,200 --> 00:25:44,680
That's, whether it's something that's using a polymorphic code that is, that changes from one installation to another, or even changes itself constantly.

263
00:25:44,680 --> 00:25:49,320
There are ways around that, but it is a different, but it is another challenge in there.

264
00:25:49,320 --> 00:25:55,160
The third one that's actually, I think, a fairly interesting one, is the problem on a low entropy network.

265
00:25:55,160 --> 00:25:58,760
What do you do when there's not a whole lot of randomness going on on the network?

266
00:25:59,200 --> 00:26:03,320
You know, if there's not a lot of randomness in the packets, how do we stay hidden in it?

267
00:26:03,320 --> 00:26:19,300
We have to ensure that every packet that we send out doesn't significantly affect the statistical baseline of the network, so that an anomaly detection system sat on the network will not recognize this as something unusual.

268
00:26:19,320 --> 00:26:20,880
It will not stand out.

269
00:26:20,880 --> 00:26:29,400
It won't push the statistical analysis of the network beyond the limits, beyond the thresholds that we currently have, and it will avoid becoming an anomaly.

270
00:26:29,400 --> 00:26:46,440
This is actually the area right now that I'm doing, that I'm concentrating on, trying to figure out the best methods for communicating and picking channels and picking well-hidden channels on a low entropy network.

271
00:26:46,440 --> 00:26:52,240
So, just as a summary in the system, you know, what's real, what's not real.

272
00:26:52,480 --> 00:27:10,200
So far, the allowed protocols discovery, the network architecture discovery, the statistical profiling of the network, those are working prototypes, those modules, those parts of the system are working prototypes.

273
00:27:10,200 --> 00:27:21,020
Next stages that we're moving towards are the selection of the communication scheme, implementation of the communication, and the adaptation to changing network conditions.

274
00:27:21,400 --> 00:27:31,540
I hope that by this time next year, this will actually be a working package that I can give maybe a bit better presentation and demonstration of what it's actually doing.

275
00:27:31,540 --> 00:27:33,340
But this is the current idea.

276
00:27:33,460 --> 00:27:40,860
Anybody that has any interest in this or any ideas or feedback or wants to tell me why I'm crazy for thinking this, feel free.

277
00:27:40,860 --> 00:27:42,700
There's my contact information.

278
00:27:43,440 --> 00:27:47,460
And that's it for about a 25-minute presentation.

279
00:27:54,470 --> 00:27:55,910
There's one question.

280
00:28:05,550 --> 00:28:07,810
That is a great question.

281
00:28:08,230 --> 00:28:11,050
I'll take that just, I'll try and answer one more real quick.

282
00:28:11,050 --> 00:28:21,110
He asked, is there any concept of trying to actually change the baseline of the network so that you can do something that used to look unusual, make it not look unusual anymore?

283
00:28:21,130 --> 00:28:24,890
That is, it's not one of the first level items on there.

284
00:28:24,890 --> 00:28:27,270
That's a pretty advanced way of working it.

285
00:28:27,270 --> 00:28:38,030
But actually changing, injecting stuff in slow enough that the system, the anomaly detection system adapts to it and thinks that's normal, that is one of the long-term ideas on there.

286
00:28:38,030 --> 00:28:41,490
That's a great idea to put into this.

287
00:29:19,870 --> 00:29:21,050
Thank you.