Want Privacy? Have Your Kids Browse for You

The FTC has issued new rules on data collection for minors: Now, the list of what counts as “personal information” has been expanded to include geolocation markers, IP addresses, pictures or audio of the child, and persistent cookies that can track users across sites. The rules also now apply to companies that make plug-ins or advertising networks, which often collect information but aren’t thought of as discrete sites that fall under the rules. I’m pulling my kids from daycare and having them do all my browsing. Then I can sue Google and anyone else who tracks me them. Share:

Read Post

The Battle over Active Defense Continues

One of our favorite friends, Jack Daniels, has a new post on Active Defense: If you make the claim that “active defense” is only a euphemism for “hacking back”, you are either hyping an agenda, or selling a (probably outdated) security model. Or perhaps you’ve just been misled by the previously mentioned shysters. By my count that’s three flavors of wrong, although one may be slightly less bitter. … Let’s start with “active defense”. It is not a new idea, and it doesn’t necessarily mean hacking back. It may encompass counterattacks, but there are a lot of active defenses far short of attack. I refer you back to my post on active defense definitions last summer. I really don’t know where all the confusion is coming from – I meet almost no security professionals who don’t understand the difference. It seems to be more of a press/PR issue. Share:

Read Post

API Gateways: Key Management

For developers one of the most visible API gateway operations is key management. But dear reader this is not your father’s key management – the kind laden with X.509, PKI, and baroque foofaraw that security teams had to beg developers to implement. This is 2013 and the keys are OAuth access keys! And developers are asking us for the keys too, so what should we do? Before we answer that question, for those of you who are not programmers, let’s describe these “access keys” in a little detail. OAuth is a method for authorizing clients (end users and client applications) to use the third party APIs served by the API gateway. It is essentially how developers give access to consumers without consumers needing to share information such as user name and password. OAuth relies upon a trusted identity service to vouch for the client and pass an authorization token to the API, which in turn gives the client access. OAuth enables four parties (a user or consumer, a client application created by a third-party developer, the owner of the APIs, and an identity service provider such as Google or Facebook) to cooperate onto deliver services. As we have discussed, developers are not much keener on the theoretical underpinnings of different identity protocols than the consumers who use their applications. They just want to get their users access to the application so they can move on to more ‘meaningful’ development tasks – like building the client application itself… This shifts the responsibility of identity and authorization onto security teams, which is a new position for them to be in: managing the process instead of cleaning up afterward. Rather than engaging toward the end of a project to conduct a vulnerability assessment, security teams may select identity protocols to be used, establish identity requirements, and guide developers through the process of building them into their applications. This is an unusual collaboration between developers and security – in both degree and kind. The role of the security team as leader for a portion of the development process sets them up as a true design and development partner. Key setup & distribution Setting up keys can be handled in several different ways, but the process is typically initiated through self-service features of the gateway (we told you it’s not your father’s PKI). The developer registers their application and client(s). The steps of the OAuth protocol dance vary by implementation, but the core generally includes: Developer account: A master account for the developer, which could span multiple clients and services Client ID: The key that identifies the consumer and grants access Client secret: How the consumer authenticates Client types: Gateways use these to distinguish between different clients such as iOS and Android Resource: The URLs, redirects and other services the client is requesting access to Once this bootstrap process is complete – whatever variation your API gateway uses – the client application developer should have everything they need. Once the client has their authorization access token they are able to call the APIs and access data with their token. Each subsequent call to the APIs protected by the API gateway includes an OAuth access token. The tokens are passed along with every call from the client app to the API so the API can make access control decisions. This brings up an important part of OAuth’s value proposition: the process of acquiring a token and using a token are kept separate. One implication is that the enterprise security architect must ensure that though these two independent processes – token issuance and token usage – are separate, their policy and governance models are consistent. Users should only be allowed access to the APIs they are authorized for, and not to see other APIs or other users’ data. The access rights requested at token issuance must match runtime behavior. Key verification services Developers may not be that interested in identity protocols but they are all interested in whether their code works. Distributed applications are notoriously difficult to debug, so anything fundamental to operations must be tested. Once access keys are issued and ready for use the API gateway should offer testing tools to ensure there are no surprises at runtime. The API provider should actively help validate the client code to protect their API! There are a number of considerations: Ensure a production-like system is available for testing. Any networked application must deal with a myriad of issues such as ports, routing, and redirects. A token cannot simply be appended to access and refresh requests – each variant of API usage requires its own test cases. Make simple tools available – many APIs include simple cURL scripts to test applications. For example: “curl -H ‘Authorization: your OAuth access token’” The gateway should include several scripts to validate client usage of the API. Provide documentation and guidance for more testing and debug functionality as needed for the client environment. Key lifecycle management OAuth isn’t magic security dust, and using it doesn’t make an application secure. API developers and consumers need to be clear on safe handling of OAuth tokens across their entire lifecycle. Some rules are straightforward, such as always use TLS/SSL. But most are context dependent, such as secure storage for tokens and safe handling of redirects. Two operations that generally require special attention in security policy are refresh and revocation. OAuth access tokens provide shorter-lived access but can create long-lived sessions through with refresh tokens. The refresh token is effectively a protection against an access token being replayed. So each consumer may have two different types of tokens. Security policy makers should align these policies and make use of the separation between shorter-lived access tokens and longer-lived refresh tokens. Policy is not as simple as “one and done”. In addition to refreshing sessions, access revocation requires consideration. Token revocation may seem minor but anyone who has lost their mobile device can say with authority that it is nice to be able to log into and turn off access to your lost mobile phone so its clients no longer

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.