When network spying is applied to counter terrorism, data flow sorting is crucial.

When network spying is applied to counter terrorism, data flow sorting is crucial.

The original intention and foundation of all intelligence warfare means lies in strengthening national defense. This article discusses the progress made by incorporating computer network spying (CNE) data into the Counter-Terrorism (Counter Terrorism, or CT) pilot project.

Action Outline
The CT program mainly involves two areas. First, obtain and warn Anti-terrorism-related active signal intelligence (SIGINT. Second, in order to support in-depth analysis and development of CNE data, the design of the existing anti-terrorism data model is expanded. At present, the CT program can support the establishment of new nodes on the Internet by the TAO Department in terms of some spying methodologies. In addition, with the joint efforts of internal and external partners, this work has paved the way for continued expansion of the CT plan's CNE data model.
Detailed conclusions and suggestions are provided at the end of the article. The three key points supporting the entire article are highlighted here:
Provides priority for CT data acquisition.
The Digital Network Intelligence (DNI)/CNE Analysis and Development Team is further built.
Vision of the CT plan CNE data usage strategy.
TAO data stream acquisition
The first step to process CNE data is to identify and obtain data streams, so that information can be routed to the CT team. This work is challenging as described in the following section.
Status quo
The CT team is receiving a CNE data stream (FOXACID log file ). This task is marked as the top-level priority by CT customer GHOSTWolf, and the data stream is also selected as the first CNE data stream capturing object. After the CT team mapped the FOXACID data stream to the entire NSA network, a data stream was created based on the Protocol Exploitation since middle February 2008.
Because the expansion of the CNE data model has not yet been implemented, the only way to process FOXACID logs is to adjust the information and adapt it to the existing CT model. The primary reason for this approach is the inherent flexibility of the existing model. It is not difficult to define a new "Event Type" in the CT uptake system and call up all selectors from each FOXACID event to pollute the event. Another advantage of the current model design is that it is relatively easy to define a new selector type for the implant ID and integrate it into the system, so that the implant ID is added to the observation list as the target selector. CT users can then check for any events related to the defined implant group. Therefore, if CT plans to obtain data streams containing embedded callback information, it will become easy to add it to the existing data model, so that analysts can track the implantation deployed through FOXACID.
As one of the progresses in this project, the CT system is applying a set of alarm techniques to FOXACID spying. These technologies include geographic location critical point settings in Geo, and alerting through Agent Logic (Internet Relay Chat and email) and iSpace control panel.
The following conclusions are drawn from the development of FOXACID uptake code: at present, the CT data model can support more CNE data than expected. Given that the system has introduced a new CNE stream, it may be feasible to simply add these streams to the current data stream before extension is performed.
TAO data stream to obtain long and short-term targets
The recent goal of introducing the CNE data stream into the CT program is to identify other CNE data streams established by FOXACID data. According to the requirements of GHOSTWolf, the next step is to obtain the embedded callback data stream. This process allows analysts to track when tasks are implanted and when they need to communicate with the monitoring site. The problem is implanted into VALIDATOR, Olympus, UNITEDRAKE, and STRAITBIZZARE.
After the data flow is established, the next step is to get the data collected from the implant, including any files and the results of the implant plug-in. CT analysts can have a more comprehensive understanding of the target-related CNE activities based on each new data stream. However, these data types are not suitable for existing data models. Therefore, it is very important to propose model extension.
In addition, there are some CNE datasets that are not created by TAO but will be helpful to CT analysts. GOLLUM (an implant from a partner) is a type of data set that helps to feed into CT, as indicated by GHOSTWolf. RADIUS logs (ISP dialing customer records) are also an excellent source of information, creating a natural link between the called Number Recognition (DNR) and DNI dataset.
Challenges/Prospects
Further obtaining CNE data from TAO will face large-scale challenges. First of all, considering the complexity of the TAO data stream, it is quite costly to locate only the owner of the final data. Each member of the CT team in the TAO department is good at dealing with data streams. Although it is necessary to master this capability, there is no new data flow creation, mainly because CT is not within the scope of the TAO generation process. The extra transparency requirements on TAO data streams can effectively alleviate this problem.
Another factor that benefits other systems in TAO data usage is the universal labeling and classification of CNE data. In the example of FOXACID, the file does not have a native classification mark. Before the data is sent to external customers such as CT, TAO must remove the data of the segmentation target and the Foreign Intelligence Surveillance Act (FISA. CT has been PL3 certified, so it is vital to have a complete FOXACID intake target. Unfortunately, the lack of unique tags and classifications for each document brings about other problems, which complicate the supervision, classification, and policies around CNE data. In addition, further exploration with TAO also shows that this problem is also suitable for other data streams. Adding the TAO data feed classification tag can help all users of TAO data maintain proper security operation procedures.
Engineers in the TAO department have been dedicated to creating a Resource Description Framework (RDF) database system that can carry all information and is open to external users. With the continuous development of this capability, CT itself as the user of this data will also benefit a lot. The system will solve many problems, including the labeling and classification problems solved in the previous section.
In short, to push more TAO data streams to analysts in an effective and real-time manner, these problems need to be solved. CT should also be synchronized with TAO in the development and deployment of the RDF database. Finally, CT needs to perform data model extension and transfer any TAO data currently ingested to the new model.