The world is changing. What was once fought on battlefields with physical weapons is quickly transitioning online, with groups of individuals and even entire nations utilizing the internet to disrupt their enemies.

Just as with any conflict, there will be civilian casualties — whether it be civilian infrastructure or users weaponized as Distributed Denial of Service drones, the consequences of the coming virtual conflicts will be bad.

Thankfully, developers can do a lot to prevent the impact of such infiltration. As we’ve covered before, API developers not only have the tools to implement security, but have an ethical and often legal responsibility to ensure their services are used for the intended purpose.

In this first of two pieces, we will examine the threat of cyberattacks on the international scale. In the follow up, we’ll look at who exactly are launching these attacks, along with some general methods API developers can implement to negate the damage caused if defenses are broken.

Real-World Examples

In November of 2014, the United States Government named North Korea as a state actor in the hacking of Sony Pictures. The attack, which leaked personal information about employees, employee dependents, and corporate earnings and figures, was quoted by C-SPAN as having resulted in the release of “47,000 unique Social Security numbers from SPE computer network”. The attack cost Sony an estimated $35 million dollars.

In February 2012, hacktivist group Anonymous leaked approximately 2,434,899 emails from 680 Syrian domains, including that of Syrian President Bashar Assad. The attack damaged Assad’s international standings, and called into question his handling of the ongoing Syrian civil war.

Threats like these prompted U.S. President Obama to issue an Executive Order on April 1, 2015 against cyber-attacks. What do all these events have in common? They represent a rising trend: Cyber warfare represents the future state of international conflicts. While the days of small scale terrorism and border skirmishes are far from over, more and more conflict is moving into the digital space.

Why Attackers Target APIs

Unfortunately, APIs are a hot commodity to exploit. While we discuss the nature of the attackers and their goals in the companion to this piece, it helps our current discussion to understand what makes APIs so attractive to hackers:

• APIs are virtual buffets for hackers. Thousands upon thousands of users, all sharing private information, use APIs in their daily eCommerce, communications, and entertainment. This makes an API a potential wealth of data for attackers to use for fraud, theft, and even blackmail.
• APIs are necessarily forward facing. Because public APIs are designed to be consumed by third party developers, they have no choice but to be forward facing. Thus, they are exposed by force. Unlike private servers, which must be physically hacked into or accessed via non-private servers, public servers and services are more exposed at all times.
• API Developers often use common resources (e.g., dependencies, third party APIs, and open source code). While this is good for development, it means that all developers who use a specific resource might all be exposed to that resource’s bug, widening the net of impact. This was the case with the infamous Heartbleed bug.

Because of these basic facts, API developers should expect more and more attacks by state and non-state actors as politically oriented crimes shift from physical to digital. This also means that API developers should also expect that, even if they aren’t directly related to the cause, they may be “weaponized” or caught in the crossfire.

The Three Defenses

The unfortunate reality of this shift from physical struggle to digital struggle, however, is that civilian infrastructure is becoming a growing target. While government and corporate business infrastructure are prime targets, threats to web services are growing as they are often less protected and thus more attractive for hackers.

API developers accordingly have an ethical, and sometimes legal, responsibility to prevent the misuse and abuse of their APIs and services. Establishing and maintaining CIA — Confidentiality, Integrity, and Availability — should be the most principle activity an API developer engages in. Luckily, developers can fend off a great deal of these attacks and secure their CIA by adhering to a three-tiered fundamental approach.

1: Preventing Damage

First and foremost, API developers should do everything they can do to prevent damage from ever occurring in the first place. This is easier said than done, of course, but there are a few significant approaches developers can take to stop attackers in their tracks.

Hackers function like a disease. When a disease invades a body, it often utilizes insects such as ticks and mosquitoes as a route to the host. These routes typically are of opportunity and random chance rather than anything specifically planned out (because, let’s face it, malaria isn’t sitting at a big green table plotting our destruction a la Dr. Strangelove). These modes of transmission are called vectors.

Hackers are much the same, and typically use unpatched vulnerabilities and requests as “vectors” to a system. API developers need to patch these vectors, and ensure attackers can’t use them as direct routes to the internal systems.

Find cues using rate monitoring

Geographic and behavioral rate limiting is perhaps the most powerful approach to preventing damage. Rate limiting systems function in a variety of ways, but the most common is a behavioral approach. By establishing a baseline of reasonable behavior, e.g. the average number of calls to a given resource from a given geographic area over a set period of time, these systems can analyze traffic that does not fit the baseline, and reject or limit these connections.

By allowing your system to choke traffic that is malicious or otherwise questionable, you can intelligently restrict the access of attackers while keeping the experience of the userbase dynamic and effective.

Decrease number of routes

Another method to prevent damage is to secure the API “stronghold”. Essentially, the less gates or pathways you have, the more secure a system is going to be. What this functionally means for API developers is that points of entry to the API should be restricted and monitored. Reduce the number of outward facing calls and services that support those calls. When such a reduction is not possible, try to combine calls with similar functions, or even put these calls behind a gateway or common call with variable functionality.

Containerization for isolation

One of the best methods API developers can use is something called “containerization”. Services like Docker combine services, APIs, and resources into a single “container”, isolating functionality in nodes. By doing this, multiple vectors are combined into a singular vector, and the damage that can be done to the service is entirely contained to that specific container, preventing additional damage to exterior services.

Holistic platform security

All of these solutions are great for specific applications, but what about general holistic security? Enter access management and identity control. These two solutions use credentials issued from a central server in order to identify and grant access to a particular service. These credentials can be limited in nature, with a specific scope and timeframe applied to limit usage.

In Authentication, a user provides their credentials in order to identify themselves. Part and parcel, Authorization controls the systems that user is able to access and how they use these systems. Implementing an effective control system at this level can limit invalid operations amongst users, and help track user behavior over time.

Next comes concepts for wider identity management. With Federation, a single user account or credential is used across multiple services. While this is great for user experience, it necessarily decreases security by giving a relatively “one size fits all” key for the user. Delegation, on the other hand, is far more limiting — in effect, it allows a user to function within the rights of another user profile, thereby limiting their actions even below that of a full user.

Implementing the right access management and identity control solution will depend largely on how much power you want your users to have — but nailing the sweet spot means drastically increased security.

2: Pre-Empting Damage

Developers should pre-empt damage to their services by thinking like an attacker. Why, exactly, is an API a target for hackers? What makes an API’s resources attractive? What can be done to negate this?

One major issue in API development is the trend of coding “just enough”. When developers code just for functionality, rather than for long-term security and ecosystem cohesion, they create a situation where they have a powerful and extensible service that doesn’t consider the platform it relies upon.

This creates a lot of additional vectors. For instance, without understanding the weakness and strengths of the underlying platform, things like SQL injection become a daunting reality. Injecting code into a service negates almost every security feature an API can adopt, as the internals are thus completely and irreparably exposed.

Luckily, much of the process of pre-empting data concerns the culture and processes of the API developer, and can thus easily be implemented:

• Adopting a proper internal culture of security can prevent a lot of internal attacks using phished passwords obtained via social engineering.
• Segregating versioning and development can help stop the constant threat of day zero exploits and versioning hacks.
• Know where your vulnerabilities lie, and take on the role of a white hat hacker to test these risks.
• Even proper a GitHub documentation approach segregated between developer and user functionality can go a long way towards obfuscating, and thus protecting, a large portion of your functionality.

3: Recovering from Damage

Unfortunately, not all damage can be prevented or pre-empted. Damage is going to occur, and developers need to have a plan in place to deal with this. A lot of this recovery can be done at the base level. Implementing redundant server clusters and offsite backups can create a database restoration point, ensuring any data lost is from a relatively small time period.

Creating and implementing an IT Disaster Recovery Plan that takes hacking and espionage into account can create an avenue by which a company can heal after drastic damages. In a roundabout way, adhering to legal and ethical concerns for IT providers can also help, as keeping adequate records, securing these records, and maintaining these records makes total loss a non-issue.

Last Thoughts

The threat of international cyber warfare is no hypothetical discussion — it is occurring as we speak. State and non-state entities are utilizing the webspace to dole out terrorism and direct acts of war, and this will only increase. API developers have a responsibility to understand and combat the hacking that has come of these conflicts, and to protect their users from exposure.

If API providers cannot arm their platforms, the industry will die. Developers integrate APIs not out of necessity, but out of trust. If that trust is broken, then World War API will be won — but not by API developers, but by the enemy.