In my last post, I outlined the difference between relying on Indicators of Compromise versus Indicators of Attack for digital security. The emphasis here is not that these indicators are new, but that it is imperative to share this early information among all of the different security systems and programs. To be effective against the speed and adaptability of today's attacks, individual security components need to know what is happening across the system and network.

Now, there have been attempts to connect individual security sensors and controls together through proprietary APIs, but this does not scale with the wealth of components that are available. What we need here is an open messaging layer that we can publish and ascribe to a centralized repository that collects all of the info, as well as deep inspection capabilities hanging off the messaging layer that you can reach out to when something new comes along. In the financial industry, to use an outside example, there is a centralized organization, SWIFT, which provides a common infrastructure and messaging protocol for financial transactions among more than 10,000 organizations in 215 countries. SWIFT recently introduced sanctions screening, analogous to deep inspection capability, which checks transactions for compliance with criminal, terrorist, and political sanctions. 

In order to take an uncompromising stand, we needed to better understand how our adversaries work. We setup a “honey net,” a fake target, so that we could watch attacks from beginning to end, learn more about cybercrime tactics, and identify steps we could take to build more effective defenses. Within 12 hours of going live, we had our first Indicator of Attack – network vulnerability scanning of our systems. The IP addresses used to do these scans were not in our library of bad addresses, and they continued to be part of the attack as it evolved. But this information is typically discarded by the firewalls, leaving the other sensors and controls in the dark.

The next event was a brute force password attack on a component that we left intentionally exposed. Using a large botnet, our 20-character password was broken in no time at all. While most systems would be configured to defend against this, by letting it proceed we could reconstruct the user ID and password dictionaries that the attackers were trying.

Once they had a successful login, the attackers setup their own admin account, and even installed language-specific browsers to make their work easier! Here we learned the detailed characteristics of a hacked account. What is interesting to note is that the configuration changes, while anomalous, would not have fallen outside the rules of what most companies allow. Only by looking at the cumulative Indicators of Attack, from several sources, can we confidently declare this system compromised.

There are many other potential Indicators of Attack, many of which will be quickly and easily repelled by your existing defenses: phishing emails, social engineering attempts, repeated failed logins – the list is lengthy. Unfortunately, information on most of these indicators never gets past the initial point of contact. In fact, our attacker tried and failed more than 5,000 times before successfully compromising the system. Trial and error should be a dead giveaway.

Only with a truly connected security system can we develop a sustainable advantage over highly adaptive and evolving cybercriminals. It’s not easy operating in a world where we need to be right all the time and the attacker only needs to be right once. We need to move to a security posture where the criminals do not get thousands of free tries to break in, and if they do find a weakness, they do not get to wander around inside our systems with impunity, carefully evaluating what they want to steal.