Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
352 Military Communications and Information Technology... has mechanism that allows the Decision Module to efficiently execute multiple queries over the data streams in order to perform event correlation. The result of a correlation process is an intermediate event that is further processed by CLIPS rule engine [12]. CLIPS uses ontology that describes broad range of network security aspects (we use ‘’FCDS ontology’’ developed in our project). CLIPS engine identifies whenever some attacks or malicious network events have been discovered. The information describing the network incident and reconfiguration procedures (Common Decision Rule – CDR) are sent to Translator. Moreover, detailed information in human readable format are generated and visualized to network administrators via DM GUI. Figure 3. UML diagram of DM Data received from network sensors is arranged in streams. Each stream is built of multiple tuples (events). Each tuple, depending on sensor type, may have different schema. Borealis allows to process streams in order to correlate information coming from different sources and to detect network incidents more efficiently. The query that is executed over the multiple streams consists of operators. There are different kinds of operators provided by the Borealis engine that allow for aggregation, filtering and joining data coming from different streams. According to Figure 2. only intermediate events are matched with the knowledge stored in the ontology. The intermediate events are obtained via the Borealis query that is executed over the streams of a network events. Their names, types and schemas are maintained in the ontology. Each intermediate event received by CLIPS rule engine is considered as attack symptom and as such is matched with knowledge in the ontology in order infer the most probable attack [13]. The example of symptom matching is graphically presented in Figure 4. When the symptoms are received by CLIPS rule engine the most probable attacks are inferred. However one symptom could match several attacks, therefore CLIPS is responsible for computing the probability score and alerting about these attacks, for which the calculated score exceeds the detection threshold.
Chapter 4: Information Assurance & Cyber Defence 353 Figure 4. Matching sensor events (symptoms) with knowledge in ontology [13] If the attack is detected it may have accompanying (described in ontology) general decision rule that will minimize consequences. There are several pre-defined general reactions such as blocking, traffic redirection (e.g. to a trap or back to the attacker), administrator notification or service disabling. The ontology defines different security policies (what reactions are recommended/allowed in the particular domain) for different domains, therefore CLIPS additionally matches this knowledge with appropriate general reaction rule to avoid policy violation. Each Decision Module can react to network events and attacks by sending information (CDR) to the Translator element and then to RE. The output information from DMs is the CDR describing attack symptoms (information about network events) and particular reaction rule to be applied by reaction elements. Translator has the knowledge about its subnet capabilities and can access the necessary reaction elements (e.g. firewalls, filters or IDS). Reaction elements can be reconfigured by Translator in order to apply commands sent by the Decision Module. All Decision Modules within the federation can also interact with each other and exchange security information. Particularly information about network incidents, like attack in one domain, may be sent to different Decisions Modules in order to block the attacker before the consequent attack takes place on another domain. Communication between domains and Decision Modules is based on P2P (Peerto-Peer) in order to increase communication resiliency and enable data replication. Moreover, P2P approach allows the proposed system to overcome IP addressing issues and minimize the configuration cost. The proposed approach allows the system to have redundant communication channels between Decision Modules. Particularly, when a physical connection is under attack or is congested, the communication packets still have an opportunity to reach the destination DM using a different path. The used communication channels are encrypted using the SSL algorithm. This allows to protect the communication against the packet sniffing (by third
- Page 302 and 303: 302 Military Communications and Inf
- Page 305 and 306: Commanding Multi-Robot Systems with
- Page 307 and 308: Chapter 3: Information Technology f
- Page 309 and 310: Chapter 3: Information Technology f
- Page 311 and 312: Chapter 3: Information Technology f
- Page 313 and 314: Chapter 3: Information Technology f
- Page 315 and 316: Chapter 3: Information Technology f
- Page 317 and 318: Application of CID Server in Decisi
- Page 319 and 320: Chapter 3: Information Technology f
- Page 321 and 322: Chapter 3: Information Technology f
- Page 323 and 324: Chapter 3: Information Technology f
- Page 325 and 326: Chapter 3: Information Technology f
- Page 327 and 328: Chapter 3: Information Technology f
- Page 329 and 330: Chapter 3: Information Technology f
- Page 331 and 332: Managing Lessons Learnt from Daily
- Page 333 and 334: Chapter 3: Information Technology f
- Page 335 and 336: Chapter 3: Information Technology f
- Page 337 and 338: Chapter 3: Information Technology f
- Page 339 and 340: Chapter 3: Information Technology f
- Page 341 and 342: Chapter 3: Information Technology f
- Page 343: Chapter 3: Information Technology f
- Page 347 and 348: Federated Cyber Defence System - Ap
- Page 349 and 350: Chapter 4: Information Assurance &
- Page 351: Chapter 4: Information Assurance &
- Page 355 and 356: Chapter 4: Information Assurance &
- Page 357: Chapter 4: Information Assurance &
- Page 360 and 361: 360 Military Communications and Inf
- Page 362 and 363: 362 Military Communications and Inf
- Page 364 and 365: 364 Military Communications and Inf
- Page 366 and 367: 366 Military Communications and Inf
- Page 368 and 369: 368 Military Communications and Inf
- Page 370 and 371: 370 Military Communications and Inf
- Page 372 and 373: 372 Military Communications and Inf
- Page 374 and 375: 374 Military Communications and Inf
- Page 377 and 378: Development of High Assurance Guard
- Page 379 and 380: Chapter 4: Information Assurance &
- Page 381 and 382: Chapter 4: Information Assurance &
- Page 383 and 384: Chapter 4: Information Assurance &
- Page 385 and 386: Chapter 4: Information Assurance &
- Page 387 and 388: Chapter 4: Information Assurance &
- Page 389 and 390: Chapter 4: Information Assurance &
- Page 391 and 392: Chapter 4: Information Assurance &
- Page 393 and 394: Chapter 4: Information Assurance &
- Page 395 and 396: Network Traffic Characteristics for
- Page 397 and 398: Chapter 4: Information Assurance &
- Page 399 and 400: Chapter 4: Information Assurance &
- Page 401 and 402: Chapter 4: Information Assurance &
352 <strong>Military</strong> <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong>...<br />
has mechanism that allows the Decision Module to efficiently execute multiple<br />
queries over the data streams in order to perform event correlation. The result<br />
of a correlation process is an intermediate event that is further processed by<br />
CLIPS rule engine [12]. CLIPS uses ontology that describes broad range of network<br />
security aspects (we use ‘’FCDS ontology’’ developed in our project). CLIPS<br />
engine identifies whenever some attacks or malicious network events have been<br />
discovered. The information describing the network incident <strong>and</strong> reconfiguration<br />
procedures (Common Decision Rule – CDR) are sent to Translator. Moreover,<br />
detailed information in human readable format are generated <strong>and</strong> visualized to<br />
network administrators via DM GUI.<br />
Figure 3. UML diagram of DM<br />
Data received from network sensors is arranged in streams. Each stream is built<br />
of multiple tuples (events). Each tuple, depending on sensor type, may have different<br />
schema. Borealis allows to process streams in order to correlate information<br />
coming from different sources <strong>and</strong> to detect network incidents more efficiently.<br />
The query that is executed over the multiple streams consists of operators. There<br />
are different kinds of operators provided by the Borealis engine that allow for aggregation,<br />
filtering <strong>and</strong> joining data coming from different streams.<br />
According to Figure 2. only intermediate events are matched with the knowledge<br />
stored in the ontology. The intermediate events are obtained via the Borealis<br />
query that is executed over the streams of a network events. Their names, types<br />
<strong>and</strong> schemas are maintained in the ontology. Each intermediate event received by<br />
CLIPS rule engine is considered as attack symptom <strong>and</strong> as such is matched with<br />
knowledge in the ontology in order infer the most probable attack [13].<br />
The example of symptom matching is graphically presented in Figure 4.<br />
When the symptoms are received by CLIPS rule engine the most probable attacks<br />
are inferred. However one symptom could match several attacks, therefore CLIPS<br />
is responsible for computing the probability score <strong>and</strong> alerting about these attacks,<br />
for which the calculated score exceeds the detection threshold.