Many of us in the information security space have a proud legacy of only purchasing best in breed point solutions. In my early days as an information security practitioner, I only wanted to deploy these types of standalone solutions. One of the problems with this approach is that it results in a bloated security portfolio with little integration between security controls. This bloat adds unneeded friction to the infosec team’s operational responsibilities. We talk about adding friction to make the attacker’s job more difficult, what about this self-imposed friction? S&R pros jobs are hard enough. I’m not suggesting that you eliminate best in breed solutions from consideration, I’m suggesting that any “point solution” that functions in isolation and adds unneeded operational friction shouldn’t be considered.
While it has been covered in many other places across the Web (start with Marco Arment, then Ben Brooks), Twitter’s API changes today should worry any social marketers who use tools and technologies that interact with Twitter.
In Twitter’s announcement, they state that they are not going to penalize “Enterprise Clients” and vendors of “Social Analytics” — every quadrant but the top right of their visualization, below. However, Twitter did not clearly delineate lines between what is and is not acceptable. To continue to grow, Twitter needs to encourage a robust and healthy ecosystem, which supports both marketers and users. In order to do that, Twitter must provide much clearer guidance about the long-term stability of its APIs and its support for businesses built on top of their data. If this requires announcements of additional fees for data usage, that will be fine as long as the rules of the road are clearly laid out.
Until Twitter does so, I expect the volume of new enterprise-ready startups centered on Twitter to reduce, and existing vendors will increase their focus on other platforms and communities as CEOs and boards of directors try to reduce their risk and exposure to future changes by Twitter.
I just love the theme of our upcoming Forrester Security Forum (Las Vegas in May, and Paris in June -- check out Laura Koetzle's definitive blog post). Leapfrog Your Global Competition. Rethink Security; Run At The Threat. There's never been a better time to take a deep breath and rethink how security can contribute to business savvy and agility. The "Zero Trust Identity" report I'd telegraphed in my previous post on API access control is now out, and it's consonant with this theme. I found that if enterprises want to be nimble and secure in getting value out of mobile, cloud, and consumerization trends, they're going to have to get over some bad "unextended enterprise" habits, such as tight coupling to authentication functions.
Open Web developers tend to use a variation of the façade pattern for their applications but refine the pattern to focus on standard web formats and protocols and services delivered via the Web — so we refer to it as the open Web façade. Developers draw on three bodies of de jure and de facto standards to implement the open Web façade pattern:
Client standards. Application clients based on a body of emerging standards collectively labeled HTML5.
Service plane standards. A service plane that exposes interfaces using the REST pattern and resource-oriented architecture principles. These services are often called RESTful web services.
Virtual infrastructure standards. A highly virtualized server tier (often a public cloud service) that is easy to deploy initial solutions to but that is also able to scale up or down on demand to meet surges in capacity.
If anything exemplifies the extended enterprise, it's the notion of the "API economy": Unlocking value in your organization's unique data and services by publishing open APIs (application programming interfaces) for access by third parties. As Laura Koetzle notes, business leaders today are prioritizing growth above all -- and fostering a third-party developer ecosystem is becoming a great way to boost revenue. Best Buy, eBay, and USA Today are examples of companies with APIs and external developer communities.
But, but, but...just how secure is an open API? Especially if you, the security professional, can't fully control these external developers' actions? This is where it gets exciting, because security and identity-based access control are enablers of these new business opportunities. After all, an API of this sort is essentially a digital product whose use must be metered.
Many organizations in this position are turning to the OAuth technology to solve a host of security challenges that arise from opening up APIs. I'm excited to be bringing the latest in OAuth business cases, adoption news, and recommendations to my Forrester Security Forum track session on "Securing And Identity-Enabling Monster Mashups." Hope to see you at the Forum November 9-10 in Miami!
(Got a great API security story, or maybe some questions? Don't wait till November; feel free to share in a comment here, or ping me on Twitter using the #FSF11 hashtag.)