Upload
lytuong
View
241
Download
0
Embed Size (px)
Citation preview
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 [email protected] 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 [email protected] to become a sponsor of an API industry guide or
white paper today.
SPONSOR
Email [email protected]
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.