The virtual world stage is ever evolving, and unfortunately, the physical conflicts of yesterday are quickly becoming the digital conflicts of today. States, groups, and individuals are poised to wage digital warfare for a variety of political, economic, and social reasons. And, as with any conflict, civilian data — and civilian architecture — are prone to be not only the casualties of war, but the unwitting weapons too.

Today, we’re going to discuss the primary actors of World War API, their motives, and how API security should adapt to meet their threats. We’ll also discuss security from the perspective of the API developer as a response to the external threats, and how threats should be managed internally.

Understanding the Conflict: A Brief Recap

As we previously discussed in Cyberattacks on the International Scale, the world is rapidly changing, and as part of this change, much of the conflict that once took physical form, such as industrial espionage and lone-wolf terror attacks, is moving into the digital realm.

The largest fights haven’t been fought yet — and even so, we can see the ripples of what is to come today. The massive Sony pictures attack that cost the company 35 million dollars was attributed by the FBI to North Korea. On the other side of the aisle, hacktivist group Anonymous famously leaked 2,434,899 emails from 680 Syrian domains, including the private domain of Syrian President Bashar Assad.

These are significant examples, but don’t think this is a recent phenomenon. In 1999, during the Kosovo Conflict, the United States bombed an embassy in Belgrade for providing communication services to the enemy. In response, Chinese hackers cyber-bombed US and NATO services, plastering “We won’t stop until the war is over!” on websites and defense portals. In 2007, Estonia claimed attacks from Russian hackers “overwhelmed the Baltic nation’s computer networks, crashing e-mail for its parliament, taking down emergency phone lines and freezing online services of government offices, banks, universities and hospitals”.

Cyber warfare isn’t just an emerging threat — it’s a historic and current one. The fact is that understanding the actors in the conflicts to come is the first step to preventing the havoc they’ll wreak.

The Lone-Wolf Attacker

Possibly the most common attack that API developers will face is that of the individual attacker. This commonality can be attributed to the fact that an individual attacker is harder to detect than a group attack, and thus is the most likely “first strike” move a group will make. These attacks are primarily concerned with economic and disruptive damages, and typically target specific resources.

Luckily, though these attacks are likely to be the most common, they are also the easiest to deal with. Small attacks typically call for solutions that are easy to implement. Individual attackers will use techniques like code injection and spoofing, so preparing an API for these sorts of issues is prime.

API developers should keep in mind that dealing with these sorts of attackers entails making the API a non-attractive target — individual attacks are largely ones of opportunity, and thus, removing these opportunities will go a long way towards securing the API.

Developers should audit thoroughly, and audit often. While auditing internally is effective, there are also a lot of third party solutions. All-in-one security solutions like Akana API Security tie in development and auditing to a front-end web gateway. Other solutions, like Axway, unify multiple services into a suite of solutions.

The most damaging aspect of an individual attack, however, is not the reduction of functionality, but the exposure of resources. Individual attackers rarely attack for the purposes of disrupting global services, and instead attack for specific economic and social actions.

The result is that internal resources need to have more specific and powerful methods of protection. Internal encryption, U2F FIDO, and CAC cards, and even biometric security for local resources and development-only functionality can negate any damage from an individual attack, even if the attacker manages to broach external security solutions.

DDOS Group Attacks

While group attacks are significantly less common that individual ones, they are arguably the most dangerous. Every individual is essentially a force multiplier, drastically increasing both the complexity of the attack and the potential damage the attack can deliver.

The most common type of attack of this variety is the Distributed Denial of Service, or DDOS. DDOS attacks attempt to overwhelm the memory and capacity of the API itself, flooding it with concurrent connections each sending or requesting gigantic amounts of information.

While much of this traffic can be redirected, the sheer amount of data being handled is a significant issue. Rate limiting is a good solution, but can only go so far.

One of the best ways to handle group attacks is to tie user accounts to behavior. API Keys are not an adequate form of security in and of themselves, but when properly managed and distributed, they can provide a layer of security and help track behavior. When this behavioral tracking is paired with rate limiting solutions, bad behavior can be automatically detected and cut off.

Additionally, API developers should understand that the amount of control given to an API consumer directly relates to the potential damage they can do. An API’s users are its lifeblood — but a single cell can infect the entire bloodline if it’s allowed too much freedom. Restrict the power the consumer has, and you restrict the potential damage from a rogue actor.

By both limiting the rate and power of these calls, group attacks can be largely negated. Group attacks should be treated like a flood — when dealing with a flood, the solution is not to stop the water in its tracks, but to gradually reduce its impact. Dikes, walls, and drain channels are used to divert the flood and cut it into manageable channels. In the same way, API developers can divert attacks, offloading traffic from one API server to another, redirecting malicious attacks, and taking steps to limit the creation of the flood in the first place.

The best way to pre-empt this sort of attacker is to design the API and its front-facing functionality in such a way as to decrease the amount of possible concurrent connections. Utilizing API Gateways as a limiting architecture can help decrease the amount of automated connections by requesting authentication when users make a call.

Download our free eBook on API Security for guidance on how to defend your API

Motivations for an Attack: Economic vs. Impact

While the reasons for these digital attacks are as wide-ranging as they are prolific, they can be broadly categorized into two camps — economic and impact.

Economic attacks are those attacks which target resources for their economic impact, either against the company or in the benefit of the attacker. Accordingly, these sorts of attacks typically aim for the use of resources, not the taking down of resources. During the course of auditing, these resources should be identified and isolated.

Providers can identify resources with large economic impacts by analyzing web traffic for the most commonly accessed resources — the most common paths taken by actual consumers will be the biggest targets for hackers looking to disrupt core functionality. Additionally, areas with weak security, or certain calls that interact directly with the backend are going to be the prime targets for the effective hacker.

Conversely, impact attacks pursue a different strategy. Impact attacks focus on taking resources offline and preventing the proper usage of the software. API developers should implement solutions that focus more on limiting the rate of requests and tying these requests to long-term behavioral analysis to identify vulnerability scanning and potential attackers.

In the real world, an API provider is likely to face both types of attacks at some point. Planning for both, and implementing solutions that solve cross-over issues (such as front-facing server vulnerabilities and poor encryption support) can bolster an API against unknown issues by making the API an unattractive target.

The Psychology of Cyber Terrorism

It’s very easy to fall into the trap of making bogeymen out of hackers and cyberterrorists. The media routinely portrays hackers as a hooded dark figure in a basement somewhere, cracking their fingers and maniacally typing, when in reality, this all too common caricature does very little to help define motive. These are real people. And as people, they have a wide range of reasonings, fears, and tolerances. Understanding all three will help better deal with these threats.

First and foremost, understanding the reasoning behind attacks is chiefly important. Cyber attacks always occur for a reason, and understanding what value an API or resource target provides to a potential attacker can go a long way to informing what resources need to have bolstered defenses.

Let’s look at an example. An API developer is auditing their security, and knows that their resources have been previously targeted, though the attack was so broad that the actual target could not be ascertained. The API handles encrypted data streams from financial institutions, largely functioning as a point-of-sale authorization vendor.

The target in this example is clear — financial gain and disruption of services. But what is the psychology? When auditing, it is found that the data was not blocked or terminated, but instead rerouted post-decryption. This would argue that the psychology is financial gain, and not disruption — after all, if the goal were disruption, we would expect to see services stopped or blocked, and not just intercepted.

This, joined with the fact that all transactions, and not just transactions originating from specific sources, suggests the action is not politically oriented. Therefore, as a security approach, all resources dealing with post-decryption data storage must be bolstered, with no particular attention paid towards specific sources.

Final Thoughts: Understand the Motivation Behind Cyber Terrorism

Our dialogue is not about hypothetical threats, but a conversation about a real-world conflict that is increasing in both scope and intensity. In 2014 alone, half of all US adults reported being hacked.

As this conflict grows, API providers will find themselves more and more in the crossfire. Thankfully, by understanding both the enemy and the nature of the conflict, the effects of this conflict on the API space and the Internet of Things can be negated, or at least reduced. Gleaning the motivation behind cyber terrorism can help providers improve security in their APIs by knowing what resources to protect, and what paths are most likely to be exploited.

Taking action now will save API developers a headache of monumental proportions in the future. We hope you’ve enjoyed this series, but know that this is only a small part of the current and omnipresent threat to the tech industry. If you enjoyed this series, please follow us for more as we track security in the API space, industry trends, and the emerging dominance of languages and media.