Monday, September 24, 2012

Example of a Twitter Phishing Attack

Looks like there is a lot of Twitter phishing going around right now. I got a strange DM on Saturday, which contained a URL constructed to look like a Facebook page:

The link itself was to a shorted URL, in this case:

This redirects to a page being served out by However, it frames a page which is being served out by (WHOIS info), a domain registered by someone in Miami. A traceroute shows that the content in the frame is served from a server located in Russia. You can see the framing below, it is quite convincing:

Presumably, if you enter your Twitter username and password here, your own Twitter account is used to send these DMs. Clever, but nasty. 

Friday, September 21, 2012

Speaking at Cloud Security Alliance Congress in Amsterdam next week

Next Tuesday I am giving a presentation on Cloud identity case studies, at the Cloud Security Alliance Congress in Amsterdam. I'll be talking about how OAuth and API Keys apply to Cloud services, with some practical case studies. If any blog readers are in Amsterdam, I'd love to meet up after the talk.

Here is the abstract:

12.40pm Turning your Cloud identity strategy into reality - Case studies In this presentation you will learn via several case studies how companies are today deploying a Cloud identity strategy. We see how this strategy can encompass existing on-premises assets, such as Identity Management platforms. Attendees will learn:
  • How to securely expose your on-premise enterprise applications for Cloud and Mobile APIs 
  • Pragmatic advice of what standards are being used 
  • Considerations for mobile apps
Mark O’Neill, Chief Technology Officer, Vordel 

Tuesday, September 11, 2012

Job Posting: Vordel Solution Architect - Syrinx, Boston MA

Syrinx has an opening for a Vordel Solution Architect here in Boston, MA. The job specs are below:

  • Significant background in security technologies such as single sign on, AD, Kerberos, SSL, SAML a plus - (direct experience with Vordel XML Gateway technologies strongly preferred) 
  • Experience with Java, JavaScripting, WebServices, XSLT, XML.
  • Basic understanding of Networking and Routing concepts; Reverse Proxy, Load Balancing, TCP/IP, DNS.
  • Security Vunerabilities; OWASP Top 10
  • Knowledge of Security Authentication and Authorization; Certificates SSL/PKI ,SAML,OAM,RBAC,ABAC, STS, LDAP/Active Directory.
  • Knowledge of APIs, REST, JSON, OAuth, SOA/Web services, Internet/network security standards and cryptography.
  • Experience with: API business models; leading Web APIs (Facebook, Google, Twitter); RESTful interactions; HATEOAS; HTTP; HTTPs; JSON; WADL; Oauth, API Management.

Axway / Vordel API Gateway - How to set logging content for tools like Splunk

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

The Vordel API Gateway allows you to set the data which gets logged into its various log destinations: log files, database, syslog, etc. Very often, it's useful to log in a particular format for log-crunching tools such as Splunk to process. Here is how to do this:

In the "Settings" section of the API Gateway configuration in Policy Studio, there is an "audit log" tab. In the screenshot below, I'm setting the format of what gets put into the text logs. You can see that I've chosen it to be:


So what does "${timestamp},${id},'${text}'" mean? It means that I'm logging the timestamp, the message ID (which is autogenerated for each message), and the text of each logging filter. I've chosen to separate them with a comma. So the next question is, what goes into ${text} ?

The answer can be seen if you look at any filter in a policy in Policy Studio, and click "Next". This is where you configure what gets logged. What gets logged is what goes into that ${text} value. In the example below, I have a filter which is logging the following upon the "Success" condition:

${} accessed the API

If you're doing authentication in your policy, then the value of ${} is automatically populated by the authenticated client's ID. Note that I am overriding the default logging settings (where only the "Failure" case is logged). I want the info in the "Success" case to go into the log. This is what I want to go into the ${text} part of ${timestamp},${id},'${text}'

The log files for the API Gateway v7 are written out to \groups\group-n\instance-m\logs\audit  , where n and m refer to the group which the API Gateway is in, and the API Gateway itself. 

So now, when I look at the log file being written out, I see this:

# ProductName=apiserver1 7.0.0-2012-07-07 (Windows)
# CurrentDate=Tue, 11 Sep 2012 17:58:16 -0500
# CurrentDateUTC=1347400696
# TZ=Eastern Daylight Time

09.11.2012 22:59:11,884,Id-0599f187504fb42f112c0c5d,'JoeDeveloper accessed the API'
09.11.2012 22:59:11,916,Id-58e1fd41504fb42f06110000,'JaneDeveloper accessed the API'
09.11.2012 22:59:12,070,Id-ab634e7c504fb430152c0c5d,'JoeDeveloper accessed the API'

This is simple for a tool like Splunk to process. 

While we're looking at the logging settings, let's look at the database logging. You can see in the screenshot below that I'm logging to the database:

The same content, ${} accessed the API , gets logged to the database. This can then be found in the Analytics of the API Gateway, in the Audit Trail. In the screenshot below, you can see the view of the Audit Trail, showing the entries. This is the same information as is written into the text log. In fact, if I also choose to write to Syslog (let's say) then the same information is written there too.

Clicking in on any of these entries, I can see the message ID, and the filter which wrote that log text. If many filters in my policy wrote out log data for the same message, then this is where I see the path through the policy, filter by filter.

I can also search the Audit Log here. Let's say I am only interested in the API accesses by "Joe Developer". Here in the screenshot below I construct a search looking for lines which contain "Joe":

So in summary, there is great flexibility in the Vordel API Gateway for both the format (e.g. comma-separated) and content (e.g. insert Client IDs) of logged data.

Monday, September 10, 2012

How to register a REST API with the Vordel API Gateway v7

The API Service Manager is an important part of the Vordel API Gateway. Its job is to make it simple to register an API. Once you've registered your API using the API Service Manager, the API Server acts as a proxy for your API, gathering metrics on how it is used, and applying policy.

Here is a series of short videos and screenshots on how to register a REST API in the Vordel API Gateway.

In this first video below, we see how to start the process of registering a REST API. the first step is simply to paste your REST resource URI into the API Service Manager:


Often you wish to expose your API on a different path than its destination. This is easy to do in the Vordel API Gateway, and the API Gateway performs automatic URL-rewriting for you:


Next, you are walked through a series of steps to apply policies to your API. In the video below, I'm choosing to apply OAuth, and also caching for the response. You can make your own policies using Policy Studio, or simply use the out-of-the-box policies:


Next, you choose what metrics to monitor for your API, as shown below in this screenshot:

Then, the last step is that you deploy. It's easy to deploy to a group of API Gateway, as shown below:


That's all there is to it! Once your API is registered using the API Service Manager, it then comes under the control of the API Gateway, which monitors it and applies policies to it.