OWASPThe Open Web Application Security Project

(OWASP) is a worldwide not-for-profit orga-

nization focused on improving the security

of software, with a mission to make software

security visible, so that individuals and organi-

zations are able to make informed decisions.

API management has done an amazing job in helping

companies, organizations, institutions, and govern-

ment agencies make their digital resources more avail-

able on-line in a secure way. Allowing API providers to

require developers to sign up, obtain keys, and tokens

which need to accompany all API calls.

Vers ion 2017.11 API Security Concerns, Threats, Practices, Services & Tooling

API Management

{“API”:“Security”}

API Security2

API Security

I ndustr y Guide

API Security is the number one concern for companies entering the API game, and the least invested area once they are operating in the space.

API Security 3

When I began doing this research into API security in early 2016 I saw almost no movement forward in the API security conversation.

Security is the number one concern of companies, organizations, institutions, and government agencies considering investing

more resources into their API infrastructure, as well as companies who are ramping up their existing efforts. At the same time

it is also the most deficient area when it comes to investment in API infrastructure by existing API providers. Many groups

are rushing along their API journey, and deploying web, mobile, device, and other applications, but rarely stopping to properly

secure things with each step along the way.

In 2016 I began investing more into the topic of API security. I have been ramping up my research into how APIs were being

secured, and how they weren’t being secured. I’ve been tracking on breaches, vulnerabilities, as well as the companies who

are offering products and services that help API providers secure their APIs, as well as some of the open source tooling that is

available. As I do with my approach to researching everything APIs, along the way I’m keeping notes on the common building

blocks, and other patterns that are contributing to the wider API conversation--in this case it is all about securing our APIs.

From my research into where things are at with API security in 2016, it is clear that one of the reasons things were deficient

in the area of API security was that API management had sucked much of the oxygen out of the conversation. Numerous API

providers I talked with about API security thought it was all about making sure APIs were keyed up, applying OAuth, using

encryption, and rate limiting their APIs. With that, API security was taken care of. Very few were actively scanning, testing, and

looking through web server, DNS and other logs for signs of security threats and incidents. While a major contributing factors

to API security deficiency is that API providers are short on resources, which means API security is often under-invested in by a

company, but beyond this, I think API management has been the biggest reason API security still lags behind in 2017.

Another thing I have noticed in my research, is that many of the APIs being operated were in service of mobile applications,

and many API providers were investing in mobile application security, and considered their APIs behind secure as a result. APIs

in service of mobile applications were living in the shadows, despite being easily reverse engineered using off the shelf proxy

tools. This perception of what API security is has added on a whole other dimension to why investment in this area is so far

behind. Many companies feel like they don’t have public APIs when they are developing them in the service of mobile phones,

despite using HTTP as the transport, and leverage public DNS.

Even with all of the deficiencies in API security, I’m beginning to see forward motion in the API conversation in 2017. I’m

seeing new service providers emerge to help secure web APIs, addressing the specific threats API providers face. I’m seeing

machine learning, behavioral analysis, and other new approaches to analyzing log files, and studying the surface area of our

API infrastructure. There is still much work ahead, but there are signs of renewed conversations on the subject. The biggest

challenge is going to be helping companies, institutions, organizations, and agencies understand that they should be investing

significantly more resources into API security. That is the objective of this API security industry guide, to provide a simple walk

through of the space, and introduce the services, tools, and common building blocks that are in use by successful providers.

WRITTEN BY: KIN LANE

API Security4

Next-Gen Security With ElasticBeam

I have been investing regularly in my API security research

since the beginning of 2016. Each month I spend time

curating stories, learning about new services and tools,

trying to understand what is happening, or in the case of API

security what is not happening. Throughout 2016, I saw very

few conversation going on around API security, and I wasn’t

seeing any innovation in the form of services or tooling

happening either. This worried me. With everything going on

around the 2016 election, and the cyber(in)security that had

emerged across the sector, it was clear were going to need a

significant amount of investment in security, and I just wasn’t

see any sign of it.

That was until the spring of 2017, when I was contacted by

the Elastic Beam team. At first, I have to admit I was turned

off by their talk of artificial intelligence, and machine learning.

I’m pretty skeptical of folks who use these buzzwords and I

am always looking for more evidence of exactly how they are

developing machine learning models, and how they apply this

intelligence across API operations. It was concern that pretty

quickly went away after several conversation with their team,

and spending some time learning how they were tapping into

existing API management systems, as well as other technol-

ogies already in play across the API sector, to get at the log

data they need to develop their behavioral models, evolve

their machine learning algorithms, and establish the artificial

intelligence that they are applying across API operations.

As I learn more about how lacking API security is across API

providers I’m talking with, and how API security conversa-

Augmenting existing API management practices, Elas-ticBeam is using machine learning to push forward the API security space.

WRITTEN BY: KIN LANE

01

Automatical ly detect and block API-based attacks on your data, appl icat ions and control systems.

API Security 5

Using machine learning to help develop the models we need to identify and respond to the next generation of threats.

tions seemed to have halted after API management layers

were put in place. I was left worrying about how we were

going to tackle the scope of this problem. I see Elastic

Beam as part of the solution that will help us keep up with

the volume of data that is flowing through our API infra-

structure.

I’m not saying there is some magic AI or ML that is going

to save us, and Elastic Beam is going to come in and wave

their magic wand. I am saying that we generate a ton of

data across our database, web services, API management,

firewall, DNS, and other logging layers of our operations.

There is no way that we can sift through all of this, and

understand the behavior of the good API consumers, as

well as the ever shifting bad API consumers that plague our

operations. Elastic Beam is using publicly available threat

information, as well as the models developed by delivering

their services to their customers to tackle this problem. This

is how we are going to develop the behavioral models we

need to understand the massive amount of traffic we gen-

erate daily, and machine learning and artificial intelligence is

how we will evolve and apply these models at scale.

Elastic Beam is developing the behavioral models we need

to evolve our insight around what is good and bad behavior,

then working within our existing infrastructure to under-

stand how to enforce security across our API infrastructure.

They are doing this across platforms, understanding how

we need to accomplish where we are already operating.

Additionally, ElasticBeam looking beyond just HTTP and

our web APIs, and keeping an eye on MQTT, and other

protocols being put to work across the API landscape. I’ve

been working to have regular check-ins with the team to

understand where they are going with their road-map, and

opening up conversations about gRPC, GraphQL, Contin-

uous Integration, and delivery. Helping to keep the road

map evolving regarding what they should be focusing on

next, derived from what I am seeing across the landscape.

Making sure the models they are developing fit what is ac-

tually occurring on the ground at companies, organizations,

institutions, and government agencies.

Elastic Beam has become an API Evangelist partner, and

is underwriting my API security research. If you know my

approach to doing research, you know what this means. It

is all about giving me the resources to carve out the time

to understand what is going on. It isn’t about paying me to

showcase Elastic Beam products and services. However,

because they are pushing forward the API security conver-

sation with their products and services, as well as investing

in my work, you will find their name mentioned throughout

my writing.

You are also going to find my work influencing what Elastic

Beam is doing, and helping drive what they are focusing on.

You are going to see me pushing on them to be more clear

about how they are using machine learning and artificial in-

telligence. They have already shown leadership by listening

to my ideas about how to tap in, participate, and lead the

conversation when it comes to threat information sharing,

and open discussion around best practices, and the devel-

opment of ML and behavioral models. Elastic Beam has

taken much of the abuse and hazing I give to startups when

they first approach me, and they have shown resilience in

dealing with me and my work style. All a positive sign, that

we’ll have a long working relationship.

I want to thank the Elastic Beam team for underwriting this

API security research. If you are interested in learning more

about what they are up to, or would like put their services

to work on your platform feel free to reach out directly to

them, or ping me and I’ll hook you up. They are providing an

API Security6

Open Web Application Security Project (OWASP)

The Open Web Application Security Project (OWASP) is a

501(c)(3) worldwide not-for-profit charitable organization

focused on improving the security of software, with a mis-

sion to make software security visible, so that individuals and

organizations are able to make informed decisions. OWASP

is looking to provide impartial, practical information about

application security (AppSec) to individuals, corporations,

universities, government agencies and other organizations

worldwide. Operating as a community of like-minded profes-

sionals, OWASP issues software tools and knowledge-based

documentation on application security.

As the web API space has expanded OWASP has expand-

ed its focus to include the most common threats to APIs.

OWASP has acknowledged the overlap between web

applications, and web APIs, and quickly becoming a valu-

able source for API specific security knowledge, expanding

beyond its web application roots. Providing one of the best

resources to find security related information, and tooling

you can apply throughout your API operations.

OWASP doesn’t endorse commercial services, and is a mem-

ber driven organization, so you will find all the information

they provide to be vendor neutral, and focused on the task

at hand. You will find me regularly anchoring my API security

work in what the OWASP community is doing, as security

should always be a team effort. API security isn’t my primary

focus as API Evangelist, but helping guide you to where you

can find the latest information is what this guide is about.

OWASP is your source for unbiased API security information!

Every technology sector needs an unbiased source of info on best practices, OWASP is this for API security.

WRITTEN BY: KIN LANE

01

OWASP does not endorse or rec-ommend commercia l products or services, a l lowing our community to remain vendor neutral with the col-lect ive wisdom of the best minds in software security worldwide.

OWASP ZAP

API Security 7

API Management

API management has done an amazing job in helping com-

panies, organizations, institutions, and government agen-

cies make their digital resources more available on-line in a

secure way. Allowing API providers to require developers to

sign up, obtain keys, and tokens which need to accompany

all API calls. This, along with encryption by default has gone

a long way towards making data, content, and algorithms

more accessible, while also being secure. However, many

API providers have stopped here, and think their resources

are secure, when in reality there is so much more work to be

done.

Requiring all developers obtain keys to access resources, and

encryption data in transit is an important part of API security,

but it is just one tool in the API security toolbox. Out of API

management you also receive an enhanced set of logging,

analysis, and reporting tools for how developers are putting

API resources to work. When done well, this pushes the API

security conversation forward, allowing API providers to

balance access with security, and be proactive when it comes

to limiting access, or even shutting off access when their

is abuse. The problem is not all API providers are investing

here, let alone going beyond what API management provid-

ers offer.

The awareness brought to the table my API management is

valuable, but there are so many aspects of API operations

at the web server, DNS, and other levels that are often left

out of the API management conversation. I’ll be pushing API

providers to look beyond just the API management layer, and

expanding API security awareness to every other stop along

the API life beyond just management.

Much of the API security conversation begins and ends with API management, something that needs to evolve.

WRITTEN BY: KIN LANE

02

REST is not a standard, i t is a phi-losophy . It is learned from pract i-t ioners in the space.

Encryption, developer authentica-t ion, API keys, rate l imit ing, logging, analysis , and report ing is a great start to API security, but i t should stop there. There is so much more to be done keep things locked down.

API Security8

Web Security Application Security Network Security

Desktop application security led the charge for many years, but was signifi-cantly expanded with the introduction of mobile phones. Security practices are often applied to desktop and mobile phones that put APIs to work, but when security is only viewed from this angle, it creates a dark shadow for many providers who view their APIs as secure, but hackers know better.

We have around 25 years of history on the web, and as usage has grown, and the complexity of websites into full blown web applications, the discipline of API security has developed. While much of what we know about web security can be applied to APIs, there are many things that will fall through the cracks if security is only viewed through this lens.

As computing has grown the local area network has become more important, pushing forward net-work security practices. Now with the Internet these practices have been forced to evolve and think critically about how data, content, and algorithms can be secured not just behind the firewall, but also on the open Internet.

Building Blocks - General Security

There has been a natural progression and order to how API providers are thinking about security so far, based on history.

03

Web, application, and network security provides a pretty big umbrella for many companies, organizations, institutions, and

government agencies to think about security. It addresses all the applications we run on the desktop and our servers, as well

as the web applications that are using HTTP as a transport. It also provides us a way to think about how we secure our data,

content, and algorithms in transport, whether that is behind the firewall, or out on the open Internet. API security isn’t just a

fourth column in this story. API security spans all three of these areas, as increasingly it is APIs that are delivering resources to

these three areas. There is another important dimension as well, in that APIs can be used to help secure, audit, and develop

essential situational awareness across these three areas.

This guide isn’t just covering how to secure your APIs, it also highlights some of the essential building blocks, services, and

tooling for securing the entire scope of your operations, using APIs that are secured. APIs bring in the automation, scalability,

and real time solutions that are needed to secure critical global infrastructure in the Internet age. Doing APIs help you quan-

tify, understand, and evolve your awareness of web, application, and network security, while giving you the agility, flexibility,

and control you need to keep them secure in a changing, and evolving environment.

API security is an important fourth element in our security toolbox, but it is an area of security that touches everything we’ve

learned about security so far. It augments, evolves, and enhances our existing security practices, while also potentially opening

up new problems if we do not think critically about our security practices holistically. However, when done properly, APIs can

balance the need for accessibility with security of our vital data, content, and algorithms in an age where we need to be able to

move our bits and bytes around on the global web, but also in a time where the stakes have never been higher, and the threats

have never been greater to doing business in this way.

API Security

API Security 9

Building Blocks - API Gateway

Identity and Access Message Security General Threat Protection

Gateways are a great way to route all API transactions through a sin-gle channel for evaluating, trans-forming, and security messages across an organization. When all traffic is routed through a gateway, IT security experts feel more con-fident that they have their finger on the pulse of an organization.

A comprehensive gateway stood in front of all web services and APIs is the quickest way to ensure the identity and access management (IAM) is applied across an organi-zation. Making gateways a favored approach for IT leadership when it comes knowing who is accessing resource across an organization.

Gateways bring to the table a wealth of out of the box security solutions. Providing organiza-tions with a single line of defense, across their organizations. Roll-ing out security across all web services and APIs, without much investment in security outside the gateway deployment.

Monitoring Analytics Ease of Use

Comprehensive dashboards, and analysis is standard for API gateways, augmenting all the IAM, logging, monitoring, and message security with the visualizations that are needed to understand what is going on at scale. Deliver-ing organization-wide awareness for IT and business groups to consider. .

With all web service and API traffic flowing through a single gateway it opens up the ability to monitor everything that is go-ing on. This gives the ability for security groups to quickly identify problem traffic, and understand what is going on across an organi-zation, with a single point to step in and secure.

Gateways are widely seen as the easy way to get in front of API security, even if individual teams are falling behind. While they do provide a significant amount of out of the box functionality, this centralization doesn’t come without a cost to operations in the form of surveillance, and a single point of failure.

Gateways have long been the way for the enterprise to se-cure things, but have recently been retrofitted to meet todays

03

In the early days of the API evolution the gateway approach was often seen

as a dinosaur. A heavy-handed, centralized, Enterprise relic that got in the

way of doing APIs right. However, API gateways have evolved, and there are

an emerging breed of micro gateways for delivering similar security features

to smaller microservices, serverless, and even Internet of Things API deploy-

ments across distributed networks, while working under single command and

API Gateways Are Changing With The Times

API Security10

BasicAuth API Keys JWT

Not any formal standard, but something in common practice by API providers, and supported by API management providers. It is the usage of one or two keys what accompany every API call. API keys are really more about identi-fying the application and user over being anything about security, but is perceived as secure by many.

HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn’t require cookies, session identifiers, or login pages; rath-er, HTTP Basic authentication uses standard fields in the HTTP header, removing the need for handshakes.

JSON Web Tokens are an open, in-dustry standard RFC 7519 method for representing claims securely between two parties. JWT allows you to decode, verify and generate JWT. While JWT is a standard it was developed by Auth0, an API driven identity and authentication management company.

Building Blocks - Authentication

OAuth Headers

I am going to include headers in this section because it is one of the most overlooked parts of authentication for API providers. OAuth, JWT, and BasicAuth all use headers for transmitting creden-tials, and APIs providers should be doing the same with all API keys. While easy to do as parameters, they are more secure as headers.

OAuth (Open Authorization) is an open standard for token-based authentication and authorization on the Internet. OAuth, allows an end user’s account information to be used by third-party services, such as Facebook, Twitter, and GitHub, without exposing the user’s password--giving end-users more control over their security.

Authentication is about knowing the right people have access to API resources, and understanding what they are doing with them.

03

Identification

Authentication is often more used as identification than it about security. Knowing who is accessing valuable API resources definitely contributes to security, but should not be mistaken for a complete security solution. However, iden-tification is an important part of the balance of opening up access to resources while also securing

Authentication, and identifying users is the important first step to securing

resources, but access management is a critical second step that ensures API

consumers only have access to what they need. This is where proper API man-

agement comes into play, allowing not just authentication, but fine grained

access management, rate limiting, and other controls that ensure ensures do

not have access to resources that my hurt platform operations.

Access Management

API Security 11

Building Blocks - API Management

Encryption Access Tiers

Rate Limiting

Designated access tiers, and us-age levels for different audience scopes plays an important role in API security. Providing valuable access management distinction for different types of API consum-ers. Limiting what new users can access, and scaling up for more trusted users, and partners.

Security begins and ends with SSL/TLS, and a robust approach to encryption both in storage and in transit. Encryption by default has become the standard operating procedure for API providers, no matter what the sensitivity of the data, content, or algorithms being served up.

Requiring authentication for all API users, and the logging of all API calls made allows API provid-ers to limit the rate of consump-tion for all API users. Putting caps on the number of API calls that can be made for any single API resource, dictating consumption by the second, minute, day, other relevant constraint..

Logging

Analysis Premium

A hallmark of API management are the dashboards, reports, and in-depth analysis that comes with modern solutions. Having an awareness of who is access resources, and what they are doing with them is essential to API security. It isn’t always about locking down, it is about knowing what is happening, and developing

It is standard practice in the API sector for all calls to be logged, similar to website traffic. APIs will often have the same logging capabilities as a website, but API management has introduced an additional layer providing insight into users, applications, and other API centric aspects of doing busi-ness on the web.

Often times API security comes at a premium with platform provid-ers. Lower tiers may not offer very much in the way of security, while enterprise and partner levels of API access come with encryption, auditing, compliance, and other aspects of securing critical data, content, and algorithms for the API consumers that can afford.

As the API sector matured in the years from 2007 to 2013, API management dominated much of the API security conversation.

03

While API management providers have brought a significant amount of secu-

rity to the API space. Balancing access with security, they have also sucked

much of the oxygen out of the API security conversation, leaving many API

providers thinking that everything was secure once they put API management

into place. API management is a good start, but it is just the beginning of truly

securing data, content, and algorithms be served up on the web.

API Management Does Not Equal Security

API Security12

SQL Injection Web Parameter Tampering Malicious Code

An attacked based on the manip-ulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, and other elements for defining an API request.

SQL injection is a code injection technique, used to attack data-base-driven applications, where hackers inject extra information into SQL statement via an entry field for execution resulting in a potential dump the database contents to the attacker.

Various ways of injecting, install-ing, and passing off code that has malicious intent. Once inside or installed the code can be run immediately or potentially at a future date to inflict damage on the computer or open up other doorways.

Building Blocks - Top Concerns

Input Validation Brute Force DDoS

Pushing the boundaries of what a system can handle with too much data, too many requests, or any other way possible. The results of a brute force attack will vary from system and application, but the goal is to just break things, until the API is brought to its knees and can no longer protect itself.

Taking advantage of loose input validations allowing a hacker to find the holes, and gaps in a system. Using existing inputs an attacker will explore what is ac-cepted, rejected, and push what is possible until they find a possible way into an API, and able to break down the systems integrity.

Some of the most commons ways in which API infrastructure is attacked, providing an checklist for any API security strategy.

03

The increasingly common distri-bution denial of service attack, or simply DDoS. Sending requests to an API until all resources are spent, basically taking the API off-line. Not all DDoS are meant to take an API complete off-line, and low level DDoS can be just as effective is rendering APIs useless.

With all the talk about cybersecurity we often forget about the most common threats out there. Many of the breaches that

come across my monitoring of the space are for these most obvious and common threats. It seems like sometimes we get so

obsessed with the obscure that we forget about the multitude of ways in which the most novice of hackers can infiltrate a

system, and walk away with data, and other valuable resources.

I spend a significant amount of time monitoring OWASP, NIST, and other security breach and vulnerability feeds, not because

I’m always learning about the latest in InfoSec, it is because it is a regular reminder that the front-line of API security really are

the most obvious hacks, the ones so easy we overlook them. Seeing familiar brand names and companies go by in my feed for

breaches and vulnerabilities in their operations due to SQL injection, and simple input validation is always a regular reminder

of how easy these thing scan be to overlooked.

API Security 13

Building Blocks - Incident Response

System Lock-down Incident Response Triage

What does incident response look like? Is there a plan? Have there been drills. Is there a response strategy from the last incident that occurred, or possibly studying the incidents that have happened in public.

When a security lapse or breach occurs is there the ability to just lock things down. Shutting down portions of, or entire systems, applications, and the network. Further minimizing the damage that can occur.

What does triage look like for a security incident? What is the plan of attack? How is damage limited, and the scope of the security lapse evaluated, providing the informa-tion needed for a robust, effective response.

Reporting

Establishing a plan for who gets reported to in the time of a security incident. What are the names, numbers, and email address, as well as the priortiza-tion levels. Who gets reported to, and what type of information do they receive as part of the overall

Understanding the ways in which we respond, or do not respond to security incidents, and keeping in tune with how others are handling.

03

Security Operations Cen-ter (SOC)

Computer Security In-cident Response Team

An information security opera-tions center (“ISOC” or “SOC”) is a facility where enterprise informa-tion systems (web sites, applica-tions, databases, data centers and servers, networks, desktops and other endpoints) are monitored, assessed, and defended.

A Computer Security Incident Re-sponse Team (CSIRT) is a service organization that is responsible for receiving, reviewing, and re-sponding to computer security in-cident reports and activity. Ready to go in response to any security incident that may occur.

Computer Emergency Readiness Team (CERET)An internal or external organiza-tion that is responsible for ana-lyzing and reducing cyber threats, vulnerabilities, disseminating cyber threat warning information, and coordinating incident re-sponse activities.

Communications

What is the communication strategy for the security incident response? The reporting should handle internal, while a commu-nications strategy should address the external considerations. In-cluding partners, government, and public regarding what happened.

Forensics

Security forensics is the applica-tion of investigation and analysis techniques to gather and preserve evidence from a security breach for presentation to management, or possible in court of law. En-suring all information has been properly gathered and reported.

Are you ready with your response?

API Security14

Standards Assurance Regulations

What are the assurances artic-ulated by security leadership to management? Are there similar assurances set by vendors, and told to partners. These assurances should reflect service level agree-ments that are already in place.

What are the API security stan-dards guidance in place to help all team members understand best practices. What is expected of all teams, and where can they learn, understand, and reference stan-dards across all conversations.

What are the current regulations governing the industry an API operates within? What are the cur-rents moving regulations forward, or backward? How does current API security governance practices reflect this regulatory climate?

When planning out API security governance think about the tone you want

to set across an organization. Is it more carrot, or is it about the stick? When

do you focus on carrots, and when do you bring out the stick? The success of

API governance across all stops along the life-cycle, not just security, often

depends on the tone that gets set by leadership. Also, how it is executed at

the ground level amongst teams, and in practice.

Building Blocks - Governance

Audit Risk Compliance

What does the risk landscape look like? There should be considerable thinking about what the trade-offs are when publishing any single API. Doing business via APIs is all about balancing access to resourc-es, and securing them. Has the risk involved been properly discussed and documented.

What does the regular audit prac-tices look like for API security? How are all APIs audited as part of their regular operations. What does the process look like? API security auditing is what stands between existing operations and the security incident that will make or break an organization.

Working to set some of the healthy practices and other rules around what API security should look like across an organization.

03

Are API operations in compliance? What does compliance look like? How do the rest of the building blocks involved in API security governance contribute and lead to compliance? Is compliance one time thing, or is it something that is an ongoing journey the whole team is involved in.

Carrot Or A Stick

API Security 15

Building Blocks - Network

Local ISP Cloud

Our connection to the web is obviously a critical aspect of doing business today. Think about when it goes down, and what this does to our productivity. This relation-ship should be evaluated as part of our API security strategy. Studying the practices of our providers, and what opportunities there are to help understand and defend the threats we face on the Internet, but also acknowledging the chang-ing ISP landscape in 2017.

The local area network is often perceived as the safest aspect of our network. However, with the introduction of the web into so many aspects of our lives, we should be scrutinizing our lo-cal networks for any traffic that doesn’t belong. Some API provid-ers have begun to view the local network in a similar way to the public network, helping to not begin to operate in denial about the threats we face.

A significant portion of our API traffic will originate and termi-nate in the cloud. This network shouldn’t just exist behind the curtain of the cloud. We need to have a coherent map of our cloud network, and how this is monitor-ing, logged, analyzed, and secured along with every other layer of the network. Cloud providers are giv-ing us more tools to quantify, and secure our networks--we should be putting them to work.

For many companies, the network is a black box out of reach, when in reality network security is essential to API security.

03

As with most aspects of the API conversation, network security has several dimensions. Your network should be secured, to

ensure the security, reliability, and performance of your APIs. However, with evolution in networking technology, most layers

of your network now have APIs, allowing for programmatic control of the network level like we’ve never had before.

Software Defined Networking (SDN) allows us to monitor, log, analyze, and secure the network our APIs defend on using

APIs. This gives us an unprecedented agility when it comes making sense of our network in real-time, and responding to them

immediately. This will have a profound effect on how we secure all aspects of our applications and APIs that are using these

networks. Baking SDN into all aspects of how we secure our worlds, making our systems more resilient and evolutionary in

response to live security events.

Moving on from the positive aspects of SDN, this evolution in how we operate on-line will open up another attack vector

within our infrastructure. If we do not have solid API security practices, we are just opening up another door for attackers to

walk through. APIs have spread to almost every aspect of doing business on-line, as well as our private lives, and SDN rep-

resents one of the most interesting aspects of operating APIs in 2017, giving us a new approach to defining, routing, con-

trolling, and securing our valuable resources in real-time on our local, ISP, and cloud networks.

Software Defined Networking (SDN)

API Security16

Configuration Changes Errors

The ability to make DNS changes via an API across API operations is an essential part of securing any APIs in an on-line landscape. Modern DNS providers have APIs, and these are the DNS providers you should be using to manage your APIs. Making changes in real-time, reflecting the control introduce by SDN at the network is essential for the DNS front-line.

Configuration of DNS is always a sensitive area of any on-line operation, but it is an area that can open up security holes pretty quickly. Anytime DNS changes are made the focus is usually for a pretty precise reason, when an operator should also take the time to consider the bigger picture, and how any configuration can be used to weaken or infiltrate APIs.

The error log for the DNS provides a wealth of information about security holes, probing, and can be used for predicting attacks. This layer is often forgotten about by API providers, and not proper-ly logged, and communicate by DNS providers. The DNS error log should be included alongside all other logging, and analysis layers used across API operations.

DNS has always been the front door for accessing web and API resources,

but in recent years it has become just as much about security as it is about

addressing on the web. As mentioned earlier, the logging and DDoS protec-

tion available at this layer makes it an essential part of a wider API security

strategy. When you introduce API management of the DNS layer, you turn it

into a serious security perimeter for API operations.

Building Blocks - DNS

DNS has become the front-line of API security, being the place where we defend against DDoS, and analyze for coming threats.

03

DNS Is More Than Addressing, It is Security

Domain Verification New Domains

Verifying domains is one step, but the introduction of new domains should also be part of the veri-fication process. How long has a domain been in operation, and who is operating it. As well as looking at the overlap between many domains in use.

The domains in use for an API are done, but all the domains used as part of API operations for external link, webhooks, and other aspects of delivering data and content might not be so well known. Domain verification is always a good idea as part of API security operations.

DDoS

Denial of Service attack was discussed earlier, but it has made DNS the front-line for securing against this attack. There is only so much you can do with existing infrastructure during a DDoS at-tack, and DNS will be your decid-ing factor in surviving one.

API Security 17

Rules Filters White Lists

Some traffic might be allowed, but should also be tightly filtered, lim-iting what gets through, and what doesn’t. This will overlap with rule, but should be clearer than just black and white rules.

A clearly defined set of firewall rules supporting API operations provides a sensible front line for security, but also surpasses all other traffic, allowing other un-necessary requests.

Considering API traffic at the IP address level. There should be a known list of device, server, network, and client IP addresses. Depending on the tightness of network, this list will vary in size.

APIs have emerged often outside of existing web efforts, and are seen as

separate implementations from website and web application teams. This sep-

aration can be seen in web security practices. API security should build upon

existing web security practices, however there are many nuances, and details

that are uniquely API. Build on existing web application firewall work, but

make sure API security teams are present and part of the overall planning.

Building Blocks - Firewall

Black Lists User Access Policies Device Access Policies

Looking to the user level. There should be policies in place for allowing, limiting, and restricting what specific users have access to when it comes to API operations.

Contrasting the white lists, the ability to add to, audit, and remove IP addresses from black-lists should be done in real time, providing tight security at the

The firewall has been a staple of web security, and since APIs are just the next step in the web, the WAF is still a relevant tool.

03

Going beyond users. There should be device level access policies, further allowing, limiting, and restricting what different types of devices have access to via APIs.

Building On Existing Web Firewall Efforts

App Access Policies

Adding the 3rd dimension, there should be policies for allowing, limiting, and restricting what applications have access to at the firewall level.

Logging Consistency

Include firewall logs in the wider analysis and auditing of any API security strategy. Like the DNS layer, the firewall will be full of intelligence that can be used.

Ensure consistency across fire-walls, by having a common defi-nition of rules, lists, and policies, and leveraging import and export features provided by the WAF.

API Security18

Building Blocks - Security Automation

Scanner Leak Detection Fuzzing

Data leaks will often be caught by scanning the API surface area, but this can also be identified through logging, network analysis, and other techniques. Making sure the only messages that get through are properly formed, and acces-sible through sanctioned channels.

Scanning the surface area of an API looking for holes, vulnerabil-ities, and other potential security incidents are a common part of the API security toolbox. Further augmenting existing security ef-forts with technological approach-es to securing the front-line.

Fuzz testing is a quality assurance technique used to discover coding errors and security loopholes in software, operating systems or networks. It involves inputting massive amounts of random data, called fuzz, to the test subject in an attempt to make it crash.

Obfuscation Smoke Screen Chaos Automation

Going beyond just obfuscation and actually sending out misin-formation, bad links, data, and other things to known hackers, and targets. Usage of honey pots, virtualization, and other solutions to keep hackers busy, and away from active infrastructure, keeping APIs alive and usable.

Introducing efforts to obfus-cate the surface area of the API landscape, making it difficult to reverse engineer the landscape. Helping ensure that code, SDKs, and other elements to not always give away the true nature of the API surface, making it difficult to attack successfully.

Following the lead of Netflix, and deploy software thats only mission is to disrupt and attack internal systems. Testing the resilience of API infrastructure, and push-ing the boundaries of what it can handle. Focusing on production environments, not just sandboxes, ensuring resilient systems.

There are a number of ways to automate API security, providing a much needed boost to teams who are defending the front-line.

03

Chaos Monkey is a service which identifies groups of systems and randomly

terminates one of the systems in a group. The service operates at a controlled

time (does not run on weekends and holidays) and interval (only operates

during business hours). In most cases we have designed our applications to

continue working when a peer goes off-line, but in those special cases we

want to make sure there are people around to resolve and learn from any

Chaos Monkey

API Security 19

SaaS IaaS Workstations

At a lower level from SaaS, develop-ment and IT groups will often lever-age Infrastructure as a Service (IaaS) providers like Amazon, Google, and Azure to get their work done. This work will often also occur out of view of sanctioned IT, and development efforts, opening up security holes.

Software as a Service (SaaS) is a ubiquitous tool in companies, organi-zations, institutions, and government agencies. Much of this activity is not sanctioned by IT. Even when applica-tions are blocked, may employees will still find a way to access the tools they need to get their job done.

People increasingly are bringing their own laptops into work with them, so that they can have access to the tools and services they are needing. Company workstations might be locked down, but shadow workstations will be introducing a number of security concerns.

Building Blocks - Shadow IT

Mobile Devices

More devices are being connected to the Internet, or possibly posses their own networks. Most cameras, print-ers, and even speakers, or kitchen devices can create their own local area network, as well as sniff out and con-nect to any available wireless service, opening up additional concerns.

Alongside personal laptops, everyone has their own mobile device these days. The applications, and net-work traffic are a potential threat to operations. Even mobile devices that aren’t connected to the local net-work, utilizing 3G & 4G networks can potentially introduce risk into existing environments.

With the introduction of social networks, the cloud, and mo-bile devices, a shadow IT has emerged within organizations.

03

You might ask what Shadow IT has to do with securing APIs. If you think

about it, the APIs you should be worried about aren’t always the APIs you are

operating. SaaS, IaaS, devices and other applications all are using APIs. Many

of them have APIs baked into them. This guide is about introducing you to the

API security landscape, which involves securing internal APIs, using APIs to in-

crease security, as well as awareness of ALL APIs in use as part of operations.

Shadow IT Isn’t About Securing APIs!

Proxies, VPN, and TOR

The average user is getting pretty sav-vy to the wide range of technologies available today for obfuscating, hid-ing, and acting as man in the middle with APIs using proxies. There are an increasing number of concerns when it comes to API usage that occurs in the shadows.

API Security20

Building Blocks - Proactive

Monitoring Testing Performance

Augmenting monitoring, API testing can be used to detect malicious attacks on API infra-structure, identifying misuse of resources. Comprehensive API test coverage across ALL APIs makes it much harder to sneak anything through, keeping APIs doing exactly what they were intended

API monitoring can be the ear-ly warning system for security problems across the landscape. Monitoring that APIs are up and running is just the start, but also monitoring for other common vital signs can help catch security incidents before they become too much worse.

Performance can be a sign of po-tential security concerns. Sluggish APIs aren’t always about security incidents, but they can be an early warning sign for one, and will definitely be a hallmark of DDoS attacks, which are increasingly low level, and not intended to entirely take down API infrastructure.

API security isn’t just being on the defense, and proactive, offen-sive strategy can help keep your finger on the pulse of your APIs.

03

API providers who are actively monitoring, testing, quantifying and measuring performance on a real time basis are the ones

who you do not hear about in the news. These are the API providers who are regularly exercising their API monitoring and

testing procedures, and live on a healthy security diet. These providers have their fingers on the pulse of what requests are

being made to their APIs, and have confidence that the API responses are delivering acceptable payloads, to authorized con-

sumers.

API monitoring and testing provides have emerged out of the awareness introduced by API management providers. The first

wave of API management providers were all about defining access to our resources, and being aware of who is access them,

and what they are doing from a provider level. The current wave of API monitoring and testing providers are doing the same,

but from an API consumer perspective. The proactive API providers are doing both. Managing their APIs using modern ap-

proaches, but also pro-actively monitoring and testing their APIs from a consumer perspective.

This aspect of API security demonstrates the balance that is API security. The goal is to make our valuable data, content, and

algorithms accessible over the Internet in a secure way. The key is to make them accessible, which goes against many secu-

rity practices. This is something that takes a significant amount of monitoring and awareness of what is going on. If you have

a defensive API security strategy you are just responding to incidents, if you are actively monitoring, testing, and evaluating

performance, you are taking the offense. Something that when executed will keep the API landscape much more secure.

Exercise And A Healthy Diet Over Treating The Illness

API Security 21

Virtualization Containers Serverless

Containerization has continue the vir-tualization trend, providing even more modularized approaches to deploying API infrastructure. Allowing APIs to be deploying for individual use cases, either permanent or temporary. All continuing a trend of contributing to security through isolation.

Cloud computing has introduced many new ways of deploying infra-structure, and with it’s API roots, it has been leveraged for deploying and managing APIs in a very isolated way. Contributing to API security by kind of keeping everything separated and running in its own space.

Serverless, and distilling down of APIs to a single function, op-erating within an isolated, and compartmentalized serverless environment is further limiting the damage that can occur at the security level. Even if one API is hacked, the damage is limited.

Building Blocks - Isolation

Honey Pot Sand-boxing

Sandbox environments are a good way to deploy APIs that haven’t been hardened for production, or even allow applications to put an API to use during development and testing stag-es. Virtualization plays a role here, but more importantly it is about defining a separate secure space.

Adding to obfuscation and smoke-screen techniques describe in pre-vious sections, separate honey pots are increasingly being set up using virtualization technologies. Operating with one goal, to attract hackers, and identifying them, and establishing a fingerprint that can be defended against in other areas of operations.

Breaking API apart and delivering in smaller pieces is an in-creasingly common way to define the API security landscape.

03

Localhost

One way to secure APIs for any amount of time is to install them locally on the computer where the web, desktop, or possibly device based applications are consuming them. Limiting the network all together, or limiting it to being centered around single workstation.

Just because you isolate an API, or application does not mean secure is taken

care of. When virtualization is involved there are additional levels of security

concern introduced that might just be out of sight of the average developer.

We are seeing a new wave of security threats emerge because of contain-

erizations, with a growing number of services ad tooling emerge that helps

developers, and IT operators understand the benefits and risk of containers.

Isolation Is Not Complete Security

API Security22

Building Blocks - Orchestration

Continuous Integration Continuous Deployment Audit Test Coverage

Along with continuous integra-tion, similar approach are being used to deploy code that drives APIs, and applications. Further expanding the landscape, and opening up a new realm of secu-rity concerns to think about when locking things down.

Continuous Integration (CI) practices have emerged on the landscape and are becoming a popular way to operate on an API landscape. It also opens up a new surface area for security concerns that need to be addresses, other-wise it loses its impact.

I talked about testing earlier, but how we do automate this test coverage? API security should be looking at how to automate the assurance that testing is being applied consistently across the ENTIRE API landscape, and doing its job.

The technology landscape is getting busier, and more real time, introducing a number of new security concerns along the way.

03

With each wave of technology introduced into our work-flows we are also

opening up new security holes in our technology, but also our practices.

With the latest wave of continuous integration (CI) and continuous deploy-

ment (CD) we are moving fast, while also breaking things. With each evolu-

tion in our API integration and deployment practices we should be thinking

deeply about the trade offs we make, and consider security at every turn.

CI/CD Security Considerations Emerge

Code Review Code Scanning Dependency Evaluation

Beyond reviewing code for quali-ty, the scanning of all third party libraries, downloads, and anything involved with API operations is being used to ensure this vector is not introducing new headaches. Think of virus scanners, but at an infrastructure scale, evaluating ev-erything across the landscape.

Ensuring all code that is deployed, whether continuously, or manu-ally is reviewed as part of the API security strategy. This includes server side as well as client side code. This is often a manual process, but is increasingly being automated through a variety of tools and services.

With each API deployed, and each system decoupled, we are poten-tially introducing new dependen-cies, and new security concerns. We like to think API infrastructure is decentralized, but increasingly code libraries, and other APIs are just increasing the number of de-pendency security concerns.

API Security 23

Scraping Bot Discovery Bot Visibility

Not all API consumers are human. It can be difficult to identify which sign-ups are meant to establish another account for use as part of bot activity. Discovering bots on any API platform will be a growing concern for plat-forms looking to secure their APIs. Being able to tell the humans from the clients that are automated.

Scraping is a common way to get at data and content on the web, and many scrapers have figured out that APIs are a great source of retrieving quality resources. Not all API requests are created equal, and not all API consumers have positive intentions. Scraping is a big concern across the security world.

Bots come in many shapes and sizes, and from many different networks. Discovery of bots on your own platform is one thing, but being able to gain visibility in what other application, and network level traffic are bots will be an increasing aspect of securing the API landscape.

Building Blocks - Client Automation

Bot Defense Bot Registry

Not all client automation is bad. Sometimes platforms want to be able to enable client automation for good purposes. This reality requires pro-viding a bot registry, where the good bot owners can register their bots, and be upfront with their automated intentions. Bringing bots out of the shadows and reduce security threat.

Once you identify the bots on your own platform, and the bot threats from other platforms. What do you do about it? Having a coherent, well planned, and evolving strategy for defending against bots is essential to an API security strategy. Bot defenses will separate the stable and reliable API platforms from those who can’t control this automated world.

Automation is everywhere. Security isn’t the only thing being automated, threats are also being automated along the way.

03

Bot Observability

Along with a registry. Bot activity should be observable, not just by the platform, but quantifiable to govern-ment, and the public. Observability involves not just sharing the number of accounts, and platform activity, but also actively communicating around what healthy bot activity looks like and honest about bad behavior too.

Take a look at Twitter and Facebook these days, and the challenges they are

facing from the automation of accounts, messaging, and other aspects of

their API platforms. Now take a look at Slack, who has a firm control over

automation that is occurring via their API platforms. Now decide which type

of platform you will be operating, and how you will approach the threats

coming from external API automation.

The Emerging Threats From External Automation

API Security24

Building Blocks - Next Generation

Machine Learning Artificial Intelligence Cognitive

The models being developed by machine learning are being in-creasingly applied without human interactions, leveraging artificial intelligence to make the deci-sion at runtime regarding what is a threat. These uses of AI are emerging as one possible way we will be able to handle the number and scope of the threats we face when securing API infrastructure.

Machine learning is being used to analyze logs, inspect traffic, and identify threat patterns that are emerging across the landscape. Changing how we study security, and develop models to apply in active API security efforts. These models are defining a new gener-ation of API security tooling that goes well beyond just what we know as API management.

Cognitive solutions are being developed as part of the larger AI security landscape to evolve our knowledge of the security land-scape, and develop an ever evolv-ing understanding of how to re-sponse, or not respond to threats. Augmenting the human side of the API security discussion with more awareness that can be modeled, and then applied by AI.

There is a wave of new services and tooling targeting the expand-ing cybersecurity landscape, exploring new ways to secure APIs.

03

When considering next generation approaches to API security technology al-

ways talk to your vendors about the observability, and how tech like machine

learning and artificial intelligence are quantified. I’m seeing some interesting

approaches to how ML and AI are being applied to the security landscape, but

I am also seeing a great deal of smoke and mirrors being deployed to further

obfuscate the API landscape, and make things more confusing.

Observable Next Generation API Security Technology

Predictive Behavioral

Applying mathematical mod-eling for accurate attack detec-tion which then applies what is learned to save security analysts time as no security rules need to be written or updated. Adapting automatically to fast changing environments, and the expanding cybersecurity landscape--chang-ing how we respond.

Building the predictive efforts of the human side of the API security conversation, ML models are being developed to predict the security landscape and front-line based upon what we’ve learned along the way. There is hopes that more data will bring more insight regarding what is next for securing our APIs, and the infrastructure they drive.

Visualization

Seeing security isn’t easy, and I’m finding more efforts to help us visualization our API infrastruc-ture, as well as being able to see how security is being applied, or not applied. With added approach-es to helping us visualize threats as they are identified in real time, giving us a visualization of the API security landscape.

API Security 25

Observability Agility Evolution

API providers who have their act together possess a type of agility that goes beyond what they can do with their APIs, but how they can respond to new threats, and changes in how technology is wielded against them.

API observability is present on secure platforms, where security practices are evident across operations, and reg-ularly communicated about. Leaving nothing about API security in the shadows.

You see a constant state of evo-lution at API providers who have their security practices well honed. They are regularly studying existing approaches, and thinking out ahead regarding whats next.

Building Blocks - Operations

Knowledge Resilience

When API security practices are in place and regularly exercised you see a type of resilience in API operations. Incidents are isolated, minimized, and easily recovered from. Problems are identified early, and organizations are not negatively impacted.

API providers who have their secu-rity act together regular show their knowledge of the topic on the blog, and at conferences. When you have the knowledge you tend to be confi-dent enough to share it publicly and with others.

When you study API platforms enough you see the signs of healthy operations, and those who have security act together.

03

Predictive

Along with solid API security practic-es, new technological approaches are being applied to help make it easier to understand what might happen next. Taking whats been learned along the way, and developing models for being ready for what is next.

Self Learning Self Healing

When you combine automation of threat identification and scanning for vulnerabilities with trends in continuous deployment you begin to see the potential for self healing API infrastructure that can fix whatever is wrong before there is ever a breach.

With the growing number of API secu-rity service providers, as well as shared data regarding threats and breaches, we are beginning to see more models that can identify new threat patterns, and learn ways of securing a platform as it consumes new information.

Confidence

Secure API providers are more confi-dent. They know there stuff, and are sure of their security practices. They have the data telling them that things are tight. It is something that spreads across organizations, and stabilizing API operations in new ways.

Like with API management, the technology of API security isn’t always the

solution. It is the awareness these technologies can introduce when applied

right that becomes the most effective aspect of API security. There is no silver

bullet when it comes to API security, and the companies who have the most

secure API platforms out there are able to apply each of these building blocks

to their API operations, resulting in the hardened platform we all envision.

Awareness Is The Name of The Game

API Security26

Building Blocks - Information

Logging Gathering Discovery

Log files are the beginning, but information should be gathered from users, applications, and any-where else that might be relevant to feeding the API security deci-sion making process.

Logging of all the layers of oper-ations plays a significant role in feeding the API security machine. No log file should go unexamined, and cross-referenced with whatev-er decisions that are being made.

How is information stored, and indexed for discovery. Some of this may involve machine learning, but some of it will always be human, requiring rich indexes and tooling for help them find what they need.

Establishing the flow of information into API security operations, providing a wealth of data for strengthening across teams.

03

Query Analysis Scenarios

How is information analyzed? What analysis tooling and services are put in the service of securing the API landscape? There are a wealth of tools for making sense of logs, and other data sources.

Is there a query layer across API security operations and threat in-formation? Discovery by humans should go behind a single search, and be able to be automated, and made programmatic if possible.

Is there information regarding existing known threat scenari-os? Have existing incidents been documented, and made part of information stores, with external incidents added to the mix.

Aggregators Bounties

Is information gathered from bug bounties conducted as part of platform operations, as well as ex-tracted from other public bounty programs, learning from the wider security sector.

Have external information aggre-gators been evaluated for value in API security operations? There are a number of emerging sources for access aggregated threat informa-tion.

As you are gathering information think about the degree at which you are just

becoming about surveillance, and not about the thing you set out to achieve

with your API operations. There is a notion of collection too much information

in an effort to understand everything that is going on. There will be a tipping

point where you are gathering too much information, and losing your former

self, and when there is a breach you will just be giving away more information.

Pros and Cons of Platform Surveillance

API Security 27

Hunting Advisories Intelligence

API Blueprint is a documentation-ori-ented API description language that makes semantic assumptions over just having plain Markdown. API Blueprint is perfect for designing your Web API and its comprehensive documentation but also for quick prototyping and collaboration.

Threat hunting has become a thing. There are services emerging that will help you hunt for threats, within your own infrastructure, or identify and track down the threats that have been targeting your platform. Sometimes an offensive strategy is a useful part of a well rounded API security strategy.

Purchase intelligence from orga-nizations. Develop it as part of your own information gathering, then enriching with other sources. Through collaboration, sharing, or just paying for services that can help round off the API security efforts.

Building Blocks - Threats

Definitions Schema

Learn about, and use common threat information sharing schema so that when information is pulled from external sources, and shared with 3rd parties you are speaking in a known schema. Increasing the chances the data will be of value, and reduce the workload required to on-board and put threat information to use.

Being clear about what the threats are and having precise definitions of the top threats facing an API platform. Building on experiences, information gathered, as well as the definitions available to us from the InfoSec com-munity. Sharing definitions regularly to help the team understand the threats they face.

Knowing the threats. Staying informed. Developing the intel-ligence and awareness needed to stay ahead of the threats.

03

Models

Develop threat models that can be used across API security operations, and evolved by both humans and ma-chines. Study the models being shared by other InfoSec players, and stay in tune with what government agencies are using at NIST, and other relevant groups. Stay in tune with what is go-ing on and keep models fresh.

The web is under constant threat right now. Every company, organization, in-

stitution, and government agency operating on-line is facing threats. Many of

the same threats. There is a wealth of approaches to identifying, quantifying,

and defining threats that are out there before they come to you. Many leading

providers are pro-actively developing models, and reusing existing schema to

make sure their operations are well informed about existing API threats.

Not Waiting For Threats To Come To You

API Security28

Building Blocks - Scope

Cloud Multi-Cloud On-Premise

In todays environment we are doing business in not just a single cloud, and we can easily find our API infrastructure spanning multi-ple cloud environments, further expanding the threat landscape.

We are operating more APIs in the cloud, and consuming more APIs that operate in the cloud. Making it an important part of how we consider the security of our opera-tions, as we publish more services.

Not forgetting our on-premise en-vironments, where we are publish-ing APIs for internal consumption. Just because they are internal, doesn’t exempt them from API security scrutiny.

Working to define the scope of the API security landscape, as we continue to do business in more places on-line, around the globe.

03

Social Media SaaS

I talked about SaaS earlier as part of the shadow IT discussion, but now I”d like to bring up again regarding the sanctioned services we are using, and identifying the threats introduced by their APis.

As I said earlier this API security guide isn’t just about the APIs we are providing, but about the entire threat landscape of APIs we are consuming, bringing social media APIs front and center.

Mobile

Many companies feel if they secure their mobile applications, the job is done. In denial about the threats introduced when mobile applications are reverse engi-neered, and APIs mapped out.

Internet of Things

We are increasingly connecting devices to the web, and APIs are how this is being done. Cameras, printers, and other devices should be included as part of this discus-sion.

Voice

Voice enablement is quickly be-coming ubiquitous in our homes, businesses, automobiles, and pub-lic places. These are all API driven, and pose a new realm of security threats we should be considering.

The shiny new technology is always interesting, but if we begin investing

in the latest tech before we get a handle on security for the technology we

already have in place, we are just expanding the scope of our problems unnec-

essarily. Take the time to develop and prove your API security strategies in the

areas you are already operating in. Harden them, test them, and then when

ready, begin to think about what is next for your APIs.

Get a Handle on Security Before Increasing The Scope

API Security 29

Risk Scoring Likelihood

Applying a score to risk models, and being able to give each API a score re-garding what its potential risk will be. Scoring is about security groups trying to provide a simple way to distill down what has been learned and communi-cate that across teams.

Being able to model what the risk is for operating APIs, and defining them in the targeted landscape. Taking data and experience gathered along the way and developing models for pre-dicting the challenges that lay ahead for delivering API resources.

Identifying the risk is one aspect of this, but being able to under-stand the likelihood of security incidents can help determine how resources are applied as part of API security efforts, making the most of what you have.

Building Blocks - Scaffolding

Impact Trust

The establish of a framework of trust. Identifying which groups, compa-nies, organizations, institutions, and government agencies are trustworthy as part of the API security landscape. Setting the done for how we partner and do business in this environment.

Some security providers are working to quantify the impact of security threats based upon previoius inci-dents, but also through models they have developed. Providing a way of quantifying what will happen if in-vestments in API security aren’t made.

Establishing the scaffolding to hang API security strategies, discussions, and modeling on, providing a solid framework.

03

Blockchain

Some service providers are looking to the blockchain to help establish trust, and provide a distributed ledger to guide API security practices, allowing automation to respond to incidents in real time, and identify who should be using APIs and who shouldn’t.

Where do you go to plan, evolve, and evaluate your existing API security

strategy? Are you able to understand the risk, and confidently understand the

likelihood of potential security incidents? What does trust look like on your

platform? Do you trust your 3rd party developers? Is there a trusted group of

partners you can work with? Aside from the technology, how do you quantify

the politics of you your API security operates.

Where Does Your API Security Planning Exist?

Does your API security strategy have a framework to operate in?

API Security30

Building Blocks - Communications

Sharing Collaboration Teams

Collaboration across internal groups, as well as potentially with partners, and 3rd party actors is a growing part of securing the API front-line. APIs are about opening up resources to external actors, which then makes them part of the security conversation--make sure you collaborate with them.

The sharing of security practic-es, and threat information is an increasingly common way to take on security across an entire land-scape, and industry. While it may seem like it might make things worse at first, it actually reduces the amount resources needed to get the job done.

I talked a variety of common teams across the API security landscape. Teams are essential through the API security life-cy-cle, and every other type business or technical team should have a API security training, and pres-ence introduced whether they are providing APIs ore not.

Communication around API security operations, internally, and externally, is an essential part of any healthy API operations.

03

Contributions Security Page

A publicly available security page is a hallmark of healthy API platforms. There are numerous examples of security pages from API providers to learn from. This type of communication shows confidence, and demonstrates that there is a security plan in place, and assures partners, and other API consumers about security.

When it comes to communicating around API security, entertain contributions from other groups, teams, and from external groups. Also make contributions to other security efforts, events, and orga-nizations. Don’t make API security a silo-ed effort, and participate and communicate openly across your industry.

Blogging

Blogging regularly about security keeps the communication chan-nels open. It keeps the API secu-rity muscles strong, and working through all the elements of the API security strategy out in the open. Regularly assuring API con-sumers, and partners that things are good, and sending potential signs to bad actors as well.

I encounter a number of IT, developer, and business folks that feel a critical as-

pect of any API security strategy is being secretive about your strategy. Every

single time I hear this I know that this is being said to cover up incompetence,

and a lack of planning. There is no reason you should be quiet about your API

security. If your plan is as tight as you say it is, you should be willing to have

that tested, and being open, and public about it is a great place to start.

The Best API Security Strategies Are Shared Publicly

API Security 31

Trainings Boot Camps Workshops

Development of boot camps that provide multi-day events that im-merse developers, and business users regarding API security practices, and make sure they have what is needed to actively participate in efforts.

Establishing regular training programs for all participants in API efforts, both internally and externally. Providing in person, and on-line training materials that can be used to help people get up to speed on API security.

Providing workshops that can be conducted for partners, and at conferences or other public events, helping strengthen API security practices amongst key players in the API ecosystem.

Building Blocks - Education

Courses White Papers

Develop and publish white papers for internal, partner, and public consump-tion. Providing insight behind API security efforts, and educating any participants regarding the evolving API security landscape.

The crafting of courses for use across trainings, boot camps, and workshops, but can also be published via on-line technical training platforms. Provid-ing API security resources that will benefit API operations, or even within an entire industry.

Acknowledging the challenges ahead of us when it comes to making sure everyone is up to speed with API security efforts.

03

Guides

The authoring of guides like this one, that provide a single publication where people can educate themselves about this fast moving space, and un-derstand the common building blocks, services, and tooling in use.

Certification

Establish certification programs to help measure and certify that indi-viduals have been exposed to specific API security knowledge and practices, and are competent when it comes to applying in their API work.

API security isn’t just for your IT or development teams. Everybody within an

organization should be educated about the common threats to the platform.

As stated before in this guide, API security isn’t just about the APIs you own

and operate. Business users need to be made aware of the APis behind the

SaaS and mobile applications they depend on, as well as be trained on helping

make sure internal APIs are secure -- API security is a team sport.

Educate EVERYBODY About API Security

API Security32

Your silence will not keep you safe in the unsecured cyber landscape. I am process-

ing hundreds of breaches that occur each week, and tuning into numerous feeds

for information about existing threat models. All of this information is available to

you to use as training materials, to develop models for automating API security op-

erations. Information is a two-way street. You should be consuming this informa-

tion, but you should also be preparing, publishing, and sharing threat information

obtained from across your own API operations.

There might be bots, scrapers, and compromised devices, servers, and worksta-

tions probing your API operations right now, but without knowledge about IP ad-

dresses, domains, geographic locations, and other fingerprints about what they are

up to, you may never know. If you don’t have confirmation from other providers

regarding the API traffic that is a threat, you might just see it as business as usual.

You might not see attacks before they happen. Why would you want to cripple

your API operations like this?

The threat information sharing space is rapidly growing with top platforms like

Facebook and other sharing data about the types of attack, their signature, and

severity of attacks. Networks of threat information providers are being developed,

and service providers and tooling is emerging to service the space. Facebook even

has publish the ThreatExchange API to help facilitate, automate, and grow this

knowledge--something you can integrate directly into your existing API security

operations and tooling.

If each company, organization, institution, and government agency does this on

their own, the work will be repeated, and the bad actors will win. This shouldn’t

be about how little you know, or how little planning you’ve done around your API

security strategy. This should be about opening up and learning about what other

providers are doing, and eventually you will be operating at a level that you can be-

gin sharing your own information. Some threat sharing platforms offer more perks,

advantages, and access when you begin contributing, over just being a consumer.

Threat sharing in real-time is how API providers of all shapes and sizes will stay

two steps ahead of the bad actors. The more robust the security information shar-

ing becomes for the API sector, the more robust the defenses will be, which will be

something the entire space will benefit from--do your part.

Learn about threats.

Share threat information.

Everyone is more secure.

Information Sharing Is Essential

Knowledge will play a role in helping ensure

your team can deal with any new threat.

AttackType

IndicatorType

PrecisionType

PrivacyType

ReviewStatusType

SeverityType

SignatureType

ShareLevelType

StatusType

ThreatType

04

API Security 33

There is some added security available for APIs that operate internally behind

a firewall. However, the question of API security isn’t just about individual APIs

being secure, or not secure. It is also about having the skills necessary to develop

secure APIs in a consistent manner, and why would you allow your development

team to be sloppy in one area, but then require them to be able to deliver security

100% of the time when they do things that are publicly available.

No matter what you call your web APIs, you should be looking at them all through

an external lens. This will help ensure more consistency across your internal,

partner, mobile, as well as the intentionally public APIs. I regularly have conver-

sations with teams who are developing internal APIs, but then are asked to open

them up to the public, and don’t know where to begin when it comes to securing

them. Similarly, I regularly encounter APIs deployed to support publicly available

mobile applications, and the APIs are considered to be private, even though they

use HTTP and public DNS. These are just a few examples of API security miscon-

ceptions because the lines between internal and external aren’t clear in an Internet

age.

The solution for these challenges is to treat all APIs like they are public, no matter

where they end up living. Have a single strategy for developing, managing, and

auditing all APIs, and you’ll know that your APIs meet a high standard, and your

teams will be able to deliver that consistently. When crafting web APIs you should

be considering who has access to them, not whether they are public or private.

When you approach in this manner, and look at everything as being potentially

publicly available you will have significantly less to worry about when it comes to

security.

The added benefit of this type of approach is when you are ready to expand access

for APIs that are only being consumed by internal groups to external partners, or

even 3rd party developers, there will be significantly less work to be done. You

won’t have to come up with additional practices, or put APIs through a different

process, you are just securing things as usual.

The web has become ubiquitous in our business environments. It is essential out

on the open web and behind the firewall. To properly secure our digital resources,

we should be treating all API access as public, and we will be better of for it.

If you treat all your APIs like

they are public you won’t

need any additional work or

processes when you decide

to widen who as access.

Treating All APIs Like They Are Public

It’s easy to get complacent with API security

for internal APIs assuming they are safe.

05

HTTP

DNS

Web

SSL

API Security34

Arxan Technologies Carbon Black Fallible

Carbon Black, Inc. Is a security company that develops endpoint security software that detects malicious behavior and prevents malicious files from attacking an organization

Arxan Technologies is an Amer-ican technology company spe-cializing in Application Attack Prevention and Self-Protection solution for IoT, Mobile, and other applications.

Fallible helps secure their systems by continuously monitor setup including external APIs, apps for bugs and server logs for intrusion detection and perform security assessments on code changes.

URL: http://apis.how/carbonblackURL: http://apis.how/arxan URL: http://apis.how/fallible

Not every company has the resource on staff to deliver API security on-site.

I’m showcasing a different set of providers with each publication of this guide

that can help companies think through all aspects of their API security, as well

as other areas as well. If you don’t know where to begin with your API security

efforts you should be contacting one of the professionals listed above and see

if you can leverage their existing talent to get you started.

Service Providers - General Security

Service providers who are providing general security services in the space. Not a complete list, but a look at a few leading.

06

Acquire The Resources You Need

CrowdStrike Zenedge

ZENEDGE provides organizations an enterprise-class, managed white-glove cybersecurity service to help secure their web sites, web applications, and networks against vulnerabilities and Distributed De-nial of Service (DDoS) attacks.

CrowdStrike’s Falcon platform stops breaches by detecting all attacks types, even malware-free intrusions, providing five-sec-ond visibility across all current and past endpoint activity while reducing cost and complexity for customers.

URL: http://apis.how/zenedgeURL: http://apis.how/crowdstrike URL: http://apis.how/42crunch

42Crunch

42Crunch is the only enterprise grade, full-fledged API Security platform, addressing the devel-opment, testing and deployment security requirements of an API infrastructure.

API Security 35

Amazon API Gateway Mashery API Gateway CA API Gateway

The Mashery gateway provides a wide range of policies for fine-grained control over how, when, and from where your user commu-nity can access your APIs, inside and outside of a company.

Amazon API Gateway is a fully managed service that makes it easy for developers to create, pub-lish, maintain, monitor, and secure APIs at any scale. Integrating with existing AWS infrastructure.

Building CA SOA application gate-way technology for exposing, and securing back-end applications, network systems or infrastructure via APIs for mobile, cloud and REST composition features.

URL: http://apis.how/masheryapigatewayURL: http://apis.how/awsapigateway URL: http://apis.how/caapigateway

Five years ago, API gateways were only found in the enterprise, and were

dinosaurs from the service oriented architecture (SOA) age. In 2017, you

can still get an industrial grade version of a gateway, but there are a number

of smaller gateways like Tyk and Kong that can be deployed anywhere, in

the cloud, on-premise, or on-device. You also see the cloud giants getting

involved, as with their AWS API Gateway providing what you need in the

Service Providers - API Gateway

These are just a handful of API gateway providers reflecting the old school, as well as the new school breed of them.

06

API Gateway Wherever You Need It

Tyk Kong

Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware). Kong runs in front of any RESTful API and is extended through Plug-ins, which provide extra function-ality and services beyond the core platform.

Tyk is an open source API Gateway that is fast, scalable and modern. Out of the box, Tyk offers an API management platform with an API gateway, API analytics, developer portal and dashboard that can be installed anywhere you need to manage APIs.

URL: http://apis.how/kongURL: http://apis.how/tyk URL: http://apis.how/rogueapigateway

RogueWave API Gateway

The RogueWave API Gateway solution streamlines management, deployment, development and operation of APIs, enhancing se-curity and regulatory compliance through authentication, autho-rization and audit capabilities as part of API management.

API Security36

Amazon IAM Dome9 Duo

Dome9 delivers comprehensive security and compliance across public cloud infrastructure envi-ronments, helping visualize secu-rity posture, identify and mitigate risks and threats,.

AWS Identity and Access Manage-ment (IAM) enables you to secure-ly control access to AWS services and resources for users, creating and managing AWS users and groups, and permissions..

Duo Security’s innovative and easy-to-use technology can be quickly deployed to protect us-ers, data, and applications from breaches, credential theft and account takeover

URL: http://apis.how/dome9URL: http://apis.how/awsiam URL: http://apis.how/duo

There are many areas of your API operations you should be building from

scratch, but authentication is not one of them. That is the quickest way to get

things wrong, and open up unnecessary holes in your operations. There are

numerous service providers out there that will help you tackle your identi-

ty and authentication management needs. Later on in this guide we’ll also

showcase a handful of the open source solutions for delivering authentication

Service Providers - Authentication

Looking at the service providers delivering the layer of secure for understanding who is accessing our API resources

06

Do Not Reinvent The Authentication Wheel

Forum Systems Okta

Okta provides secure identity management and single sign-on to any application, whether in the cloud, on-premises or on a mobile device for your employees, part-ners and customers who are using the platform.

Forum Systems provides Ser-vice-Oriented Architecture (SOA) and Mobile Computing Security, trust management, threat protec-tion and information assurance solutions for Governments and Enterprises.

URL: http://apis.how/oktaURL: http://apis.how/forumsys URL: http://apis.how/yubico

Yubico

Yubico delivers simple, secure login, preventing unauthorized access to computers, servers, and Internet accounts with multiple authentication and encryption protocols on all devices and plat-forms, to user accounts.

API Security 37

Amazon API Gateway Azure API Management Google Apigee

Allows you to secure your APIs using a key, token, and IP filtering. Enforce flexible and fine-grained quotas and rate limits, modify the shape and behavior of your APIs using policies.

Amazon API Gateway is a fully managed service that makes it easy for developers to create, pub-lish, maintain, monitor, and secure APIs at any scale. Integrating with existing AWS infrastructure.

Apigee is a API management plat-form that enables API providers to design, secure, deploy, monitor, and scale APIs, sitting in-line with runtime API traffic and enforces a set of out-of-the-box API policies.

URL: http://apis.how/azureapimanURL: http://apis.how/awsapigateway URL: http://apis.how/apigeeapiman

Take time to get to know the leading API management service providers.

While API management is just one aspect of your API security toolbox, there

are numerous valuable features brought to the table by these companies. It

may seem easy to build many of these features, but these provider have been

working on this for a decade, and you need to be focusing resources on doing

what you do best, not building yet another API management solution.

Service Providers - API Management

These are some of the players who have been leading the API management conversation setting tone for API security.

06

Numerous Out Of The Box API Management Fea-

3scale WSO2

WSO2 is the lean enterprise middleware company. It delivers the only complete open source enterprise SOA middleware stack purpose-built as an integrated platform to support today’s het-erogeneous enterprise environ-ments internally and in the cloud.

3scale makes it easy to open, secure, distribute, control and monetize APIs. Powerful, secure and Web scalable, 3scale is the API Management Platform built with performance, customer control and excellent time-to-value in mind.

URL: http://apis.how/wso2URL: http://apis.how/3scale URL: http://apis.how/restlet

Restlet is providing the fastest and easiest API-First Platform as a Service that developers and non-developers working on API projects can use. It includes a comprehensive, well-integrated set of capabilities to design, docu-ment, test and host APIs.

Restlet

API Security38

Farsight Security Red Canary Risk IQRed Canary Security Operations Center analysts triage and inves-tigate every potential threat to identify the true threats and elim-inate the burden of false positives, and alert your team and provide detailed and actionable context.

Farsight Security provides the world’s largest real-time action-able threat intelligence on how the Internet is changing. Lever-aging proprietary technology purpose-built to manage volumes of data and real-time analysis.

RiskIQ provides organizations the visibility and intelligence they need to secure their Enter-prise Digital Footprint and map their Adversaries’ infrastructure, allowing to defend against threats targeting its websites, mobile

URL: http://apis.how/redcanaryURL: http://apis.how/farsight URL: http://apis.how/riskiq

API security is not just about preventing incidents. Ideally, you won’t ever

have to deal with a major breach, but you should have an active, well honed

incident response plan, and team in place. There are several service providers

on the API security landscape who will assist you in your response, either with

the right technology, or also possibly by providing human resources that can

come on-site in person, or virtually and assist with the response.

Service Providers - Incident Response

Learning about the service providers who are focusing on re-sponding to security incidents and helping companies.

06

Do Not Underestimate What It Will Take To Re-

Shape Security The Hive Project

A scalable open source and free Security Incident Response Plat-form, tightly integrated with MISP (Malware Information Sharing Platform), designed to make life easier for SOCs, CSIRTs, CERTs and security practitioner dealing with security incidents.

Shape is designed for rapid and large scale deployment to protect the highest traffic web and mobile applications from sophisticated cyberattack and consistently de-livers results for fraud loss reduc-tion and attack deflection from cybercriminals.

URL: http://apis.how/thehiveURL: http://apis.how/shapesec URL: http://apis.how/ciscoumbrella

Cisco Umbrella

Umbrella’s API enables you to integrate with your existing solu-tions to amplify protection. Auto-matically enrich the data in your SIEM, threat intelligence platform, or incident work-flow to speed up investigation and response by security analysts.

API Security 39

Cisco StackPath FiremonSmart. StackPath is the only web services platform built on security, with a fortified, machine learning core that aggregates, analyzes and syndicates real-time threat data both to and from each of our secure services.

Cisco’s network security combines multiple layers of defenses at the edge and the network, implement-ing policies and controls. Autho-rized users gain access to network resources, but malicious actors are blocked.

FireMon Security Manager ad-dresses the inherent complexity and changing requirements of today’s enterprise networks by providing continuous visibility into network security devices and policies across the enterprise.

URL: http://apis.how/stackpathURL: http://apis.how/cisco URL: http://apis.how/firemon

We shouldn’t be forgetting about securing the network we depend on for our

APIs. Network security is a different aspect of security, but it is increasingly

overlapping with the world of APIs because of software defined networking

(SDN), which allows networks to be configured in real-time using APIs. This

overlap will continue to bring these to aspects of the security world together,

making network security critical to APIs, and vice versa.

Service Providers - Network

Looking at the providers who are focused on securing things at the network level which our APIs operate on.

06

Security And Software Defined Networking (SDN)

Gigamon Juniper

High performance, scalable, and intelligent network securi-ty solutions for enterprises and service providers, with advanced, integrated threat intelligence, delivered on the industry’s most scalable and resilient platform.

We provide pervasive visibility into physical, virtual, and cloud environments so you can see the data in motion across your en-tire network, making it easier to manage, secure and understand all their network data, and enhance network performance.

URL: http://apis.how/juniperURL: http://apis.how/gigamon URL: http://apis.how/openswitch

OpenSwitch

The OpenSwitch platform is an open source, Linux-based network operating system (NOS) for dis-aggregated switches built around OCP-compliant hardware, utiliz-ing an open network installation environment (ONIE) boot loader.

API Security40

Akamai Cloudflare Farsight SecurityCloudflare is a web performance and security company that pro-vides on-line services to protect and accelerate websites. Cloud-Flare security protects websites from a range of on-line threats including spam, SQL injection, and

Enterprise Threat Protector (ETP) enables security teams to pro-ac-tively identify, block, and mitigate targeted threats such as malware, ransomware, phishing, and data ex-filtration that exploit the Do-main Name System (DNS).

Farsight Security DNS data solutions protect cyber assets with rapid threat detection and response to rapidly identify and react to incursions of your In-ternet presence using real-time contextual information.

URL: http://apis.how/cloudflareURL: http://apis.how/akamai URL: http://apis.how/farsight

I’ve been managing DNS professionally since 1997, and CloudFlare was the

first major shift in the DNS landscape I’ve seen since I first started. Part of

it was because of the changing tone of doing business on the web, but also

being able to manage DNS using web APIs. CloudFlare showed me how

important DNS will be to doing business on the web using APIs, and also how

important APIs will be to allow us to properly defend this front-line.

Service Providers - DNS

Looking at the front-line of the API space, and learning more about the service providers who deliver DNS.

06

CloudFlare Changed How I View DNS

DNS Simple Google Cloud

Google Cloud DNS is a scalable, reliable and managed authorita-tive Domain Name System (DNS) service running on the same infrastructure as Google providing a cost-effective way to make your applications and services available to your users.

DNSimple provides the tools your need to manage your domains, offering both a carefully crafted web interface for managing your domains and DNS records, as well as an HTTP API with various code libraries and tools for program-matic control of DNS..

URL: http://apis.how/googlednsURL: http://apis.how/dnssimple URL: http://apis.how/azuredns

Azure

The Microsoft Azure DNS Re-source Provider REST API allows you to create and modify DNS zones and records hosted within Azure. Zones and records are man-aged as Azure Resources, for use across the rest of the Microsoft Azure stack of cloud services.

API Security 41

Amazon WAF StackPath FiremonStackPath is a web services plat-form for security, speed and scale. Unifying security solutions by le-veraging collaborative intelligence that makes each service smarter and more secure with every threat detected..

AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect ap-plication availability, compromise security, or consume excessive resources.

FireMon Security Manager ad-dresses the inherent complexity and changing requirements of today’s enterprise networks by providing continuous visibility into network security devices and policies across the enterprise.

URL: http://apis.how/stackpathURL: http://apis.how/awswaf URL: http://apis.how/firemon

Like every aspect of the API life-cycle, your web firewall should be configu-

rable, and -managed using an API. The firewall for your APIs will need to be

like your APIs, agile, flexible, and evolvable. You should be able to open up,

restrict, and prioritize a variety of traffic for different purposes. While much of

what you are doing will be via port 80, the IP configuration, filtering, rules, and

logging will all need to be a shifting landscape that you need full control over.

Service Providers - Firewall

Looking at provider who still provide firewall services for websites, but is something that can be applied to web APIs.

06

The API Driven Firewall Defending Your APIs

Barracuda F5 Networks

F5 Firewalls stand up in front of a legacy app to mitigate vulnerabil-ities like cross-site scripting, SQL injection attacks, and sensitive data, securing code and meeting compliance standards such as PCI-DSS, across web, mobile, and API applications.

Barracuda firewalls analyzes net-work traffic , leveraging advanced fingerprints to identify applica-tions and content traffic, based on the fingerprints, a flexible set of actions, including allowing, block-ing, resetting, and redirecting connection attempts and traffic.

URL: http://apis.how/f5wafURL: http://apis.how/barracuda URL: http://apis.how/ciscofirewall

Cisco

Cisco Firepower NGFW applianc-es combine our proven network firewall with the industry’s most effective next-gen IPS and ad-vanced malware protection. All so you can get more visibility, be more flexible, save more, and protect better.

API Security42

Google Security Scanner Qualys ArachniDynamic deep scanning covers all apps on your perimeter, in your internal environment and under active development, and even APIs that support your mobile devices. With programmatic scanning of SOAP and REST API services.

Cloud Security Scanner is a web security scanner for common vulnerabilities in Google App Engine applications, for auto-matically scanning and detecting cross-site-scripting (XSS), Flash injection, mixed content (HTTP in

Automatic, dead accurate and easy-to-use web application secu-rity scanner to automatically find security flaws in your websites, web applications and web services.

URL: http://apis.how/qualsysURL: http://apis.how/googlescanner URL: http://apis.how/arachni

We can’t do all of this alone. There are an evolving number of security service

providers who have been shifting their servies to focus on the needs of API

infrastructure. There are plenty of things you can do on your own, but there

are very few API operations I know of that have enough resources on staff to

do API security properly. Spend some time looking at how these API security

services can help augment and automate what you are already doing.

Service Providers - Security Automation

Taking a look at a handful of the providers who offer auto-mation services and tooling that makes API security easier.

06

Help Defining Security For Our API Infrastructure

NetSparker Rapid7

Rapid7’s Penetration Testing Services team will simulate a re-al-world attack on your networks, applications, devices, and/or people to demonstrate the secu-rity level of your key systems and infrastructure and show you what it will take to strengthen it.

Netsparker finds and reports web application vulnerabilities such as SQL Injection and Cross-site Scripting (XSS) on all types of web applications, regardless of the platform and technology they are built with, providing fool-proof auditing of websites and APIs.

URL: http://apis.how/rapid7penetURL: http://apis.how/netsparker URL: http://apis.how/acunetixscanner

Acunetix

Acunetix can crawl any website and web application, even modern Single Page Application (SPAs), JavaScript and RESTful APIs. Acu-netix DeepScan crawls even the most advanced web applications by replicating user actions and executing JavaScript.

API Security 43

Tinfoil Security Vaddy Peach API Security

Vaddy automatically runs as part of your existing CI process, run-ning after every code change, and alerts you when a commit con-tains vulnerabilities to discover vulnerabilities, and deal with them before they get baked in your code.

Tinfoil is a simple, developer friendly service that lets you scan your website for vulnerabilities and fix them quickly and easi-ly. We’re a team of experts with extensive backgrounds in security across many organizations.

Integrating Peach API Security into your existing Continuous In-tegration (CI) system ensures that your product development teams receive immediate feedback on the security of your latest release, across all existing work-flows.

URL: http://apis.how/vaddyURL: http://apis.how/tinfoil URL: http://apis.how/peach

With continuous integration (CI) and continuous deployment (CD), and all the

other containerized deployment and orchestration going on, security service

providers are beginning to shift their focus to help address this ever changing

landscape. This is a new area of my API security that I’m tracking on, but it

makes sense to begin paying attention to how companies are securing their

continuous integration with APis, as well as the deployment of code behind.

Service Providers - Orchestration

API integration and deployment is getting more automated, and orchestrated--some security providers are keeping up.

06

Continuous Security

Neuvector Continuum Security

BDD-Security is a security test-ing framework that uses natural language in a Given, When, Then Gherkin syntax to describe se-curity requirements as features, running as part of the build/test/deploy process.

NeuVector delivers an application and network intelligent container security solution that automat-ically adapts to protect running containers and their hosts. Don’t let security concerns slow down your CI/CD processes.

URL: http://apis.how/continuumURL: http://apis.how/neuvector URL: http://apis.how/cyberark

Aqua

The Aqua Container Security Platform provides develop-ment-to-production life-cycle controls for securing contain-erized applications that run on-premises or in the cloud, on Windows or Linux, supporting multiple orchestration environ-

API Security44

Akamai Shape Security Distil NetworksShape security targets aggregators used scraping bots to discover and publicize non-compliant ticket-ing options. These unauthorized bookings disrupted the airline’s ability to manage revenue and reduced the airline’s operational

Akamai bot Manager provides a framework to help you better manage interactions with on-line entities, then identify, categorize, and take the appropriate action on different types of bots, based on their business and IT impacts.

Distil Networks identifies and police malicious website traffic, blocking 99.9% of bad bots with-out impacting legitimate users. Giving you visibility and control over human, good bot and bad bot website and API traffic.

URL: http://apis.how/shapesecURL: http://apis.how/akamaibot URL: http://apis.how/distilnetworks

Bots come in many shapes and sizes. A lot of focus has been spent on Twitter

bots in recent months, but the landscape for automation is expanding as fast

as the API sector. Cameras, printers, and many Internet connected devices

are increasingly being conscripted into bot armies, the being unleashed on

companies, organizations, institutions, and government agencies for a variety

of purposes, and API security providers are responding with new solutions.

Service Providers - Client Automation

Looking at some of the service providers who are helping de-fend the landscape against bots, scraping, and automation.

06

Help Defending Your Platform In A Bot Landscape

ShieldSquare Infisecure

InfiSecure blocks frauds before they hurt your business. Defend-ing against scrapers, hackers and spammers with advanced bot detection technology and plug & play real-time automated pro-tection, for web, mobile, and API applications.

ShieldSquare automates bot pro-tection on your website or mobile app without impacting genuine users and the performance, by pro-actively building signa-tures for each unique visitor to a website, mobile applications, and across API consumers.

URL: http://apis.how/infisecureURL: http://apis.how/shieldsquare URL: http://apis.how/permieterx

PermiterX

PerimeterX Bot Defender Mo-bile prevents automated attacks against mobile apps including account takeover attacks, account abuse, fraud and exploitation of mobile , web, and device API vul-nerabilities and common exploits used by hackers.

API Security 45

ElasticBeam DarkTrace Jask

Darktrace is capable of detecting a range of in-progress threats, breaches and vulnerabilities — from IoT hacks and criminal cam-paigns, through to insider threats or latent vulnerabilities.

Over the last 3 years Elastic Beam has assembled the best AI tech-nology, team and IP assets to address the growing need for more sophisticated defenses against API-based cyberattacks using Arti-ficial Intelligence and behavioral

JASK injects a modern sensing and investigation layer into your security operations by accelerat-ing discovery, analysis, and triage, helping security operations teams to focus on increasingly smarter, ever evolving threats.

URL: http://apis.how/darktraceURL: http://apis.how/elasticbeam URL: http://apis.how/jask

I do not see how we are going to be scaling our API infrastructure without the

help of machine learning (ML), and executed as part of some sort of evolving,

security focused artificial intelligence (AI). There is just too much data to

look through, and we are going to need the help of ML to help us develop the

models we will need to identify malicious traffic, and better understand what

is good behavior, or bad behavior on our API platforms.

Service Providers - Next Generation

These are the security providers who are pushing forward the API security space, using next generation technology.

06

Delivering API Security At Scale

Guardicore Sift Science

The Sift Science Trust Platform of-fers a full suite of fraud and abuse prevention products designed to attack every vector of on-line fraud for industries and businesses across the world.

GuardiCore is specially designed for today’s software-defined and virtualized data centers and clouds, providing active breach detection, threat deception, process-level visibility, seman-tics-based analysis, and a real time response to incidents.

URL: http://apis.how/siftscienceURL: http://apis.how/guardicore URL: http://apis.how/ibmcognitive

IBM

The IBM® Cognitive SOC is a new platform embeds Watson for Cyber Security’s ability to understand, reason and learn about security topics and threats by tapping into and making sense of structured and unstructured knowledge.

API Security46

API Umbrella APIMan KongThe apiman project is a stand-alone API Management system that can be either run as a sepa-rate system or embedded within existing frameworks and plat-forms.

API Umbrella is an open source API management platform for ex-posing web service APIs. The basic goal of API Umbrella is to make life easier for both API creators and API consumers.

Kong is a scalable, open source API Layer. Kong was original-ly built at Mashape to secure, manage and extend over 15,000 Microservices for its API Market-place, which generates billions of requests per month.

URL: http://apis.how/gitapimanURL: http://apis.how/gitapiumbrella URL: http://apis.how/gitkong

When I started doing API Evangelist in 2010 we did not have an open source

API management solution. After a couple years of lobbying on API service pro-

viders, and writing numerous stories on the subject, WSO2 launched their API

Manager, and after about five years we now have a wealth of open source API

management solutions to choose from of all shapes and sizes, demonstrating

how mature the layer of the API life-cycle has become.

Tooling - API Management

Some open source API management tooling I am keeping an eye on out there, allowing for the securing of API resources.

07

We Have Come A Long Ways With API Management

Tyk IBM API Microgateway

The Microgateway is an develop-er-focused, extensible gateway framework written in Node.js for enforcing access to Microservices & APIs.

Tyk is a lightweight, open source API Gateway and Management Platform enables you to control who accesses your API, when they access it and how they access it, recording analytics on how your users are interacting with your API.

URL: http://apis.how/gitmicrogatewayURL: http://apis.how/gittyk URL: http://apis.how/gitwso2apiman

WSO2 API Manager

WSO2 API Management is an Open Source API Management tool that allows APIs/Services to be Secured, Monitored and Rate Controlled. This tool allows API Developers to design, publish, ver-sion and manage API life-cycles.

API Security 47

league/oauth2-server Go OAuth2 Server OAuth2orizeThis service implements OAuth 2.0 specification. Excerpts from the specification are included in this README file to describe different grant types. Please read the full spec for more detailed information.

A standards compliant implemen-tation of an OAuth 2.0 authoriza-tion server written in PHP, allow-ing you to protect your API with access tokens, or allow clients to request new access tokens and refresh them.

OAuth2orize is an authorization server toolkit for Node.js, pro-viding Passport authentication strategies and application-specific route handlers, can be used to assemble a server that implements the OAuth 2.0 protocol.

URL: http://apis.how/gitknoopoauth2URL: http://apis.how/gitphpleagueo- URL: http://apis.how/githansonoauth2

While OAuth 2.0 isn’t perfect, it is the best we have currently for securing our

APIs in a way that allows API providers to dictate levels of control, developers

to execute securely, while also giving end-users a voice in what is going on.

Facebook, Twitter, Github, and all the major API platforms support OAuth

2.0 for their platforms. If you are providing API access to user’s data on your

platform, learn more about what OAuth 2.0 can do for your operations.

Tooling - Authentication

A handful of the open source authentication tools available out there, showing what is possible for securing your APIs.

07

Embracing OAuth 2.0 With All Its Complexities

IdentityServer3 express-jwt

Middleware that validates Json-WebTokens and sets req.user.This module lets you authenticate HTTP requests using JWT tokens in your Node.js applications. JWTs are typically used to protect API endpoints, and are often issued using OpenID Connect.

IdentityServer is a .NET/Kata-na-based framework and hostable component that allows imple-menting single sign-on and access control for modern web applica-tions and APIs using protocols like OpenID Connect and OAuth2.

URL: http://apis.how/gitauth0expressjwtURL: http://apis.how/gitidentityserv URL: http://apis.how/gitauth0angularjwt

angular2-jwt

The IBM® Cognitive SOC is a new platform embeds Watson for Cyber Security’s ability to understand, reason and learn about security topics and threats by tapping into and making sense of structured and unstructured knowledge.

API Security48

API Security Checklist Fuzzapi CortexThe apiman project is a stand-alone API Management system that can be either run as a sepa-rate system or embedded within existing frameworks and plat-forms.

Cortex tries to solve a common problem frequently encountered by SOCs, CSIRTs and security researchers in the course of threat intelligence, digital forensics and incident response: how to analyze observables they have collected, at scale.

Kong is a scalable, open source API Layer. Kong was original-ly built at Mashape to secure, manage and extend over 15,000 Microservices for its API Market-place, which generates billions of requests per month.

URL: http://apis.how/gitfuzzapiURL: http://apis.how/gitapiseccheck URL: http://apis.how/gitcortex

I am only about two years into my research into API security, and I’ve spent a

great deal of time looking at what the leading service providers are up to. I’m

just about six months into looking at what open source solutions are available

out there, so my tooling section is a little short. However, I think this is also

due to some of the deficiency when it comes to investment in the space, and

is something that will take a few years to mature.

Tooling - Other

A random of other assortment interesting API security tool-ing I’ve been tracking on, that I think are relevant today.

07

Just Getting Started With Open Source API Security

ThreatExchange Connec-tor

TheHive

TheHive is a scalable 3-in-1 open source and free Security Incident Response Platform designed to make life easier for SOCs, CSIRTs, CERTs and any information se-curity practitioner dealing with security incidents.

Tyk is a lightweight, open source API Gateway and Management Platform enables you to control who accesses your API, when they access it and how they access it, recording analytics on how your users are interacting with your API.

URL: http://apis.how/gitthehiveURL: http://apis.how/gitcbthreatex URL: http://apis.how/threathunter

Threat Intelligence Hunter

An intelligence tool that helps you in searching for IOCs across multi-ple openly available security feeds and some well known APIs. The idea behind the tool is to facilitate searching and storing of frequent-ly added IOCs.

API Security 49

OWASP Zap Zap Admin Zap Core HelpAn administration application to support OWASP Zap execution.

The OWASP Zed Attack Proxy (ZAP) is a security tools to help you automatically find security vulnerabilities in your web appli-cations while you are developing and testing your applications.

A set of help files for the OWASP Zap core.

URL: http://apis.how/gitzapadminURL: http://apis.how/gitzaproxy URL: http://apis.how/gitzaphelp

Tooling - OWASP Zap

OWASP Zap is a tool that should be in yours, and the de-velopers you work with toolbox for helping secure your

07

Zap Extension Zap API (Python)

An API for OWASP Zap written in Python.

Exentsions for the OWASP Zap execution.

URL: http://apis.how/gitzapapipythURL: http://apis.how/gitzapext URL: http://apis.how/gitzapapijava

Zap API (Java)

An API for OWASP Zap written in Java.

Zap API (Go) Zap API (PHP)

An API for OWASP Zap written in PHP.

An API for OWASP Zap written in Go.

URL: http://apis.how/gitzapapiphpURL: http://apis.how/gitzapapigo URL: http://apis.how/gitzapapinode

Zap API (Node.js)

An API for OWASP Zap written in Noe.js.

OWASP Zap has been built to detect vulnerabilities in web applications, but

many of the things it is looking for will apply easily to APIs. Since OWASP

has been investing more in identifying API specific threats, I’m sure Zap will

continue to deliver for APIs. Another thing to look at is the number of APIs

being developed on top of OWASP, which will allow for the automation of API

scanning using APIs, again bringing APIs full cycle when it comes to security.

OWASP Making The API Shift

API Security50

This publication is targeting API providers at startups, companies, organizations,

institutions, and government agencies, providing a snapshot of the API sector

specifically dedicated to API security. While the primary target of the publication

is API providers, there are also regular updates about best practices, new tooling,

standards, and other aspects of the sector that concern API service providers,

and companies looking to reach API providers in the space.

This entire industry guide has been funded by Elastic Beam, who is delivering

much of what I’ve been talking about here. Thank you Elastic Beam for making

this happen:

If you would like to find out about upcoming publishing opportunities, and

supporting any of my research, you can email info@apievangelist.com to learn

more. My guide are usually updated quarterly with a regular rotation of feature

articles, and shorts, as well as including new specifications, services, tooling, and

other relevant elements from across the API sector--new opportunities emerge

on a regular basis. You will also see white papers like this one released in tandem,

providing more guidance and opinion on where the space is going.

The primary objective of this publication is to reach and educate API providers,

while also including API service providers in this regular storytelling. The API

Evangelist website provides access to the raw research on API security, but this

guide is meant to provide an executive summary that any business or technical

user can pick up to get up to speed on the subject.

Email info@apievangelist.com to become a sponsor of an API industry guide or

white paper today.

SPONSOR

Email info@apievangelist.com

to receive more information

about sponsoring.

Become Sponsor

API Evangelist sponsors make

it so I can dedicate my time

to researching the API space,

as well as provide these

guides to what is going on -- I

couldn’t do it without them.

Striking A Balance

“Thank You!”

About The SponsorThose Who Make This Publication Possible - Thanks!

API Security 51

I have been researching the API sector for the last seven years. API Evangelist

is the real time result of this research, providing analysis, links to news, patents,

companies, and the APIs that are making an impact on the space. Since 2012 I

have worked to publish white papers, guides, and other more long form content

derived from my research -- this is the latest attempt to provide access to my API

security research in a more polished and portable format.

As I monitor the space I keep an eye on what companies, organizations, institu-

tions, agencies, and individuals are up to, aggregating best practices, services,

tooling, specifications, and the other building blocks that make this API thing

work. While there is a wealth of raw research available publicly on my site, my

readers have continued to request a more refined, polished, distilled down ver-

sion of my research, resulting in the delivery of my API industry guides.

I am a one person operation, writing, designing, and editing of these guides. Once

I’m done with each one I publish on the website, and via Github, where my loyal

readers help me find any mistakes and improve the content. If you find anything

you think is a mistake, or missing information, feel free to let me know. I depend

on my readers, and community to help me deliver a quality guide that keeps up

with the fast changing world of APIs.

Along the way, I am also experimenting with new ways of generating revenue and

paying the bills. I have a number of companies asking to sponsor my site, but alas

I only have four logo slots available. These polished versions of my guides give

me a new way to extend sponsorship opportunities to my partners, and compa-

nies doing interesting things in the space. The money helps me dedicate my time

to keeping tabs on what is going on and generating as high-quality content as

possible.

Thank you for tuning in, and please let me know how I can make this publication

better -- thanks for your support.

-- Kin Lane

About the PublicationBrought To You By Kin Lane, the API Evangelist

ABOUT

Twitter: @kinlane

Github: @kinlane

kinlane.com

Kin Lane

twitter: @apievangelist

github: @apievangelist

apievangelist.com

API Evangelist

a

{ “API” : ”Evangel ist ” }

{“API”:”Security”}API Security Concerns, Threats, Practices, Services & Tooling

Providing a snapshot of the world of API security, and evaluating where we stand, the API service providers delivering solutions in the space, and some of the tooling, and common building blocks in play.