Data is a precious and vehemently defended resource within financial organizations. In most instances, financial data must be verified for accuracy and the results are well documented, retained and accessible for reference at any time.
Additionally, scenarios that result in high profitability or large financial gains are expertly analyzed and used as models for future transactions in the hopes of replicating or improving results.
This process makes sense - verify, analyze, extract, retain, reuse to achieve future success. Companies then invest heavily in protecting this financial data. So it is unusual that the same rules don’t apply to the handling of security data within financial institutions?
Most often, data collected from various security devices is fed into a SIEM, analyzed as individual alerts, and mitigated based on static rules. The results are then stored in a Word document or IT ticketing system, and the security analyst moves on to the next threat. The insights gained from the mitigation process are either lost or documented in disparate systems like email or chat tools. Why aren’t financial organizations treating their security data with the same thoughtfulness as the rest of their data?
There’s a comparable amount of security data as there is financial data flowing through a financial organization. There also tends to be more financial analysts on staff than security analysts. So financial institutions are in the tough position of having to manage an overwhelming amount of data with limited personnel. Therefore, security analysts are left in a never-ending cycle of alert, mitigate, repeat from scratch. They don’t have the resources or time to spend learning from past data.
However, retaining and reusing historical data can turn this never-ending cycle into a more strategic approach that’s more in line with the process for handling financial data, and better protects that financial data from being compromised.
Historical data informs alerts and incidents with organization-specific details. This provides the context needed to understand not only the level of a threat, but the specific evolution of a threat as it directly relates to the organization. Historical context also facilitates dynamic prioritization to eliminate false positives and escalate previously benign threats, so analysts can be more confident that they are focusing on the right threats at the right time.
For example, historical data plays a big role in informing fraud detection. It identifies patterns of misuse over time from internal and external parties. Specifically, tracking and analyzing the history of logins, account activity and transaction history helps uncover breaches like account impersonations and insider trading.
Without historical data captured from multiple devices, each action is viewed in a silo or identified based on behavioral algorithms that rely on one source. Isn’t it time to handle security data with more purpose?