The catch phrase “intelligence-driven security” has never sat particularly well with me. Those who have read my pieces or have heard me speak may find this statement a bit surprising. The regular reader knows that I believe strongly in intelligence as a component of a successful and mature security program. Among its many virtues, intelligence improves detection, informs decision-making, and accelerates response. How can I make this statement? I’ll elaborate.
Although intelligence is a critical component of a mature security program, it should not drive security. Why? At a high level, intelligence is about understanding the threat landscape, attacker techniques, and attack methodologies. This is extremely important to a successful security program, but it is only half of the picture. What’s missing? How can we apply that knowledge to the operational problems and strategic and tactical challenges that we face at each of our respective organizations?
Completing the second half of the picture, not surprisingly, involves understanding those operational problems and strategic and tactical challenges. Where does this understanding come from? It comes from an understanding of the risks we are looking to mitigate. Remember, boiled to its essence, security is about managing, reducing, mitigating, and accepting risk, rather than eliminating it. Intelligence can and must inform this process, but it shouldn’t drive it. It’s just not the right tool for the job.
• Create human language goals and priorities: Before diving into any technology or creating any alert logic, it is helpful to write down, in human language sentences, what you would like to accomplish. This is similar to the programming practice of writing pseudo-code before writing any actual code. This accomplishes two important things. First, it helps the organization to organize its goals and priorities, which are derived from the risks the organization seeks to mitigate and can subsequently be used to frame and execute a work plan. Second, it serves to document those goals and priorities. Documentation (at all levels) is seldom fun, but it is an extremely important activity for a number of reasons.
• Identify appropriate data sources: Once goals and priorities are identified, the appropriate data sources can be identified to meet those goals and priorities. The relevant data sources can include network traffic data, various types of logs (network, end-point, and malware), intelligence feeds, threat reports, and other sources. It is important to consider all data sources relevant to a particular goal or priority and to explicitly identify and document the relevant sources alongside it.
• Identify appropriate technologies: Different technologies suit different needs. For example, for certain goals and priorities, a SIEM or data warehouse may be the appropriate tool. For others, a network or endpoint forensics platform might be the right fit. Or, for yet others, something different entirely may fit the bill.
• Throw out the default rule set: This may sound radical, but for each technology, throw out the default or standard rule set. Why? Because it wasn’t written specifically for your organization. Are there specific signature sets, rules, logic, alerts, etc. that meet the needs of your organization? Absolutely, and those should be retained selectively. It’s important to remember, though, that many elements of the system’s default set won’t meet the needs of your organization. Keeping them in there will create noise and false-positives that won’t help you accomplish your goals and priorities.
• Write spear alerting: Alerts are a powerful force in security operations and should be leveraged accordingly. Write alerting designed to identify suspicious, malicious, or anomalous activity as defined by your goals and priorities. Don’t bother writing any alerts that don’t fit your goals and priorities. Why? Because that will just produce additional noise and false positives that you’ve already decided you aren’t interested in.
• Streamline the workflow: Regardless of how and where alerts are generated, they should all flow to one unified work queue. Priority should be used to assist the team in identifying what to work on first, second, etc. Highest priority goes to the highest fidelity, most reliable alerts covering the most critical assets. Lowest priority goes to the lowest fidelity, least reliable alerts covering the least critical assets. The most important takeaway here is that one work queue allows your team to focus and provides them jumping off points into analysis, forensics, and investigation. More than one work queue leads to complication and confusion.
• Practice Continuous Security Monitoring (CSM): Once you set up alerting and a work queue, use it. Every alert should be reviewed by the team and investigated appropriately to build context around it and understand what occurred. Some alerts will require more investigation, while others will require less investigation. There is really no point in setting up alerts that you never intend to look at. That’s really the point of CSM — reviewing each alert and performing analysis, forensics, and investigation as required.
• Follow a mature process: Process is the glue that binds people and technology together. If you have great people and great technology, a great process is also required. Process helps the team focus on what tasks are value-added and converge to a conclusion. After all, analysis and forensics are not done for analysis’ and forensics’ sake, but rather, to reach a conclusion.
• Leverage automation where appropriate: Once a mature process is in place, study the application of that process operationally. If time-consuming, manual labor exists for certain aspects of the process, consider automation. If time can be saved in one place, it means that more time can be spent elsewhere. This leads to greater overall visibility across the organization.
• Maintain a communal presence: We can learn a lot from our peers. Maintaining a presence in the broader security operations community ensures that an organization is in the loop regarding current events, topics, discussions, and issues. All of these factors play a role in ensuring that the security operations program changes with the times, and that information is shared in a timely and relevant manner. Just remember — this relationship involves both giving and receiving.
• Continuously improve: Never believe that the work has been completed. Technologies, methodologies, and the threat landscape change continuously and quickly. It is important to continually seek feedback and improve. The steps described here are iterative and should continually be stepped through in a cyclical fashion.
The points above, while not exhaustive, provide a high-level overview of what makes up some of the most mature, successful, risk-driven security programs. While intelligence plays a critical role in informing security, it is clearly not the right tool to drive security. A risk-driven approach to security provides a much more comprehensive and scientific approach that allows organizations to keep pace with today’s sophisticated threat landscape.