2

We have continuous cybersecurity threat feeds that coming to our SOC on a daily basis from different sources that provide all the new CVEs, new malware variations and more. We just don't know how to handle these alerts in the right way and not only that, we are lost on choosing to what will be the action to follow on those threats. What will be a good process in a bank to follow up on these threats if we can assume that there no major financial restrictions?

Filipon
  • 1,204
  • 10
  • 22

2 Answers2

3

Threat intelligence has a common issue today which is a large volume of data generated & coming to the consuming enterprise IT set up & threat intelligence feed bundle has three different usages.

  • Using threat intelligence data for blocking risks & unwanted connects to your communication to your enterprise setup.
  • Using threat intelligence data to create new rules set in your security generation & threat monitoring solution including SIEM.
  • Using threat intelligence indicates to discover the presence of existing hidden threats within your enterprise.
  • Using threat intelligence data to analyse & visualize the threat landscape as it applies to your company

Each one of these four usages have their own set of actions which needs to be taken. For organization such as banks threat intelligence data can be save the Zero days kind of threats if it is contextualized properly.

Contextualization of threat intelligence data is next stage of threat intelligence consumption which needs new processes, new technology & organization cooperation to work.

Telaprolu Aishwarya
  • 39
  • 2
3

Aha! So you got the cart but forgot the horse!!!! Classic mistake -- your org seems to be in trouble, but you're not alone! Everyone else is like you, so good for asking the question.

The answer, of course, starts with people and processes. You need people with the following knowledge, skills, and abilities to fill in the following tasks for each set of procedures:

  1. All-Source Analyst
  2. Mission Assessment Specialist
  3. Exploitation Analyst
  4. Multi-Disciplined Language Analyst
  5. Target Developer
  6. Target Network Analyst
  7. Threat/Warning Analyst
  8. All Source-Collection Manager
  9. All Source-Collection Requirements Manager
  10. Cyber Intel Planner
  11. Cyber Ops Planner
  12. Cyber Operator

The answer doesn't end there, I guess. Yeah, there are technology solutions to your problem, but they aren't clear-cut. Most orgs (e.g., banks) who implemented something like an All-Source Analysis Procedure that includes a Collection Strategy, Collection Standard Formats, and Processing Requirements as well as Analysis Production -- know that a solid melding of infrastructure, social, individual, and instructional capital is necessary to get the program off the ground.

The technology platform answers I've received to the above follow a certain paradigm. There is no one, easy answer. It's mostly developed through rigor that avoids the ad-hoc nature of IT and R&D. Yet, at the same time, it's just a bunch of random utilities connected in random ways through an integration pipeline. It's a toolchain with no toolbox in a very, very messy garage.

(In no specific order):

Putting it all together looks nothing, but perhaps something like this OSINT with Scrumblr post. Actually, maybe it looks more like this Jumping to OSINT Conclusions with Hunchly post. Or both. Or neither.

The goals and objectives of such as program, are often, in fact, to work backwards from the nightmare scenario and prevent it by implementing some hardening controls in stages, so that the organization doesn't eat the Opportunity cost all at once and can gradually invest (while keeping the wheels on, so to speak). Thus, if you want to see what Good looks like ahead of time, be sure to check out this resource:

Additionally, there are rules of thumb for the 4 major components I described above:

Collection Strategy

Constant monitoring of every possible piece of data to a high degree of detail is not technically-feasible. An intelligence function must shape its collection strategy according to: 1) breadth vs. depth, a balance between detailed but narrow and broad but shallow; 2) Monitoring frequency, long enough to not incur unnecessary expense or undue delay while sufficiently short so that corrections can be made before deterioration.
- Periodic monitoring: Inspecting the environment at a regular frequency which may entail minutes or months or more
- Event-driven monitoring: Inspecting the environment in an ad-hoc method that is driven by specific events occurring, or expected to occur
- Analysis-driven monitoring: Monitoring or inspecting the environment in an ad-hoc manner which is determined by the current state of analysis

Collection Standard Formats

MISP Galaxy provides standard formats for continuous, end-of day, and/or end-of week reporting on Collection work products. Typically, these are referred to as Standard Technical Report Using Modules (STRUMs), or end-of day formatted reports that detail all intelligence collected from sources. In the past, STIX was proposed as the standard for sharing purposes, but STIX 2 recently emerged and is available in MISP Galaxy and the ATTACK-Python-Client. VERIS, another larger standard, is also available in MISP Galaxy. Let the tool do its job, but otherwise I have no specific guidance around which standard(s) your org selects.

Processing Requirements

Both SIEMs and TIPs (Threat Intelligence Platforms) play vital roles in this phase of the cycle, perhaps also the most-important and time-consuming phase (although ideally the heavy lifting is automated). SIEMs can aid in correlation of many variables and parameters, but cannot correlate everything alone, especially not all data types that are relevant to intel analysts. The rigid framework of the data that can be populated into SIEMs limits these types of data that can be used for automated analysis. TIPs helps fill those gaps when it comes to machine readable threat intelligence (MRTI) data ingestion and handling. Because TIPs aggregates multiple types of sources of intelligence, they tend to be more flexible in their data structures than SIEMs. This allows the analysts to ingest threat intelligence in different forms, often structured and unstructured. Despite the less-structured nature of the data that is inputted into the platform, TIPs can produce results in a structured manner that can then be delivered to SIEMs or other platforms to provide context and actionable results.

Automation in the Processing Cycle
Valuable data processing functions include: parsing, filtering, correlating, deduplicating, and aggregating. Processing that can't be handled by point solutions can instead be worked through a data-science pipeline such as Splunk SPL, Splunk MLTK, Python Pandas, or Apache Drill.

Analysis Production

During the analysis phase, raw data is transmuted into information in the form of trends, patterns, sequences, clusters, and so on. This is attained via a sequence of primitive inferences such as selection, cataloging, abstraction, specification, assessment, matching, instantiation, correlation, and transformation. If the information generated during the analysis phase provides sufficient understanding for avoiding or deterring a threat (or alleviating any harmful event), then it can be termed as intelligence.

The analysis comprises of facts, findings, and forecasts that define the element of study and allow the assessment and anticipation of events and outcomes. The analysis must be timely, objective, and mostly-importantly accurate. To generate intelligence objectively, the analysts apply 4 types of reasoning -- deduction, induction, abduction, and the scientific method. The analysis stage also requires well-trained and specialized skills that allow analysts to give meaning to the processed data and to prioritize it against known requirements.

Up to this point in the intelligence cycle work, the discussion has revolved around raw data. Even third-party threat intelligence ingested into platforms is just data at this point. The production phase of the intelligence cycle is where the raw data becomes actual threat intelligence, not just machine readable threat intelligence (MRTI). Production is the process of turning the raw collected data (which may or may not include MRTI) into finished intelligence (FINTEL).

Production can take many forms, each with a specific purpose and audience in mind. Traditionally, the production phase involved the creation of reports that could be delivered to customers as part of the dissemination and feedback phase. Report production is still an important part of the intelligence cycle and a critical function of the threat intelligence team.

The whole point of this intelligence cycle work is to go from the requirements phase through processing, production, and dissemination in a cohesive manner.

Analysis Requirements
FFIEC has a requirement that cyber intelligence orgs [use] multiple sources of intelligence, correlated log analysis, alerts, internal traffic flows, and geopolitical events to predict potential future attacks and attack trends.

Other regulations around cyber threat intelligence are emerging on their scope and specificity.

atdre
  • 18,885
  • 6
  • 58
  • 107
  • 1
    https://www.enisa.europa.eu/publications/exploring-the-opportunities-and-limitations-of-current-threat-intelligence-platforms/at_download/fullReport – atdre Jan 29 '19 at 13:10
  • 1
    https://www.enisa.europa.eu/publications/enisa-threat-landscape-report-2018/at_download/fullReport – atdre Jan 29 '19 at 13:57
  • https://github.com/sfakiana/SANS-CTI-Summit-2021 – atdre Apr 06 '21 at 19:15