The Securosis Nexus (and) Beta Test FAQ

We’ve been getting some questions about the beta test, so I decided to put an FAQ together which we will also post within the system. If you have any other questions, please feel free to ask: General What is the Securosis Nexus? The Securosis Nexus is an online environment to help you get your job done better and faster. It provides pragmatic research on security topics that tells you exactly what you need to know, backed with industry-leading expert advice to answer your questions. The Nexus was designed to be fast and easy to use, and to get you the information you need as quickly as possible. Who is it for? The Nexus is for anyone with security responsibilities at their organization. We know that most of the people who work on security don’t have ‘Security’ in their titles, but need to protect their business every bit as much as the Chief Information Security Officer of a Fortune 500 company. The Nexus provides pragmatic research and advice for everyone, even if security is only one of the many hats you wear. What’s “pragmatic research”? Pragmatic research is information you can use. The Nexus doesn’t waste your time on theory and background information (although it is available for the curious). The content tells you exactly what you need to get your job done, and makes it very easy to find. Does that mean it tells me how to configure my products? No. The Nexus provides everything except product-specific information. What’s “expert advice”? Through our Ask an Analyst feature you can submit questions directly to our analysts, each with decades of security experience. We know sometimes reading research isn’t enough and you need direct advice from an experienced professional to get a clear answer on your specific issue. What makes this any different from a wiki, Gartner, or something like LinkedIn? The research is specific to security, and the Nexus presents data in several different ways, making it as quick and easy to locate information as possible. Unlike a wiki, all the content is written by professional research analysts, edited by folks who know how to write and topics are covered completely – not a hodge-podge of whatever people want to contribute. It’s far more structured and pragmatic than big analyst firms like Gartner. And unlike LinkedIn and social media sites, you are guaranteed answers to your questions. The Nexus is not just academic reference data – it is written by people who have built and deployed security products for a living. What else is included? Research and specific answers to your questions is core, but the Nexus includes much more. It offers videos, checklists, podcasts, templates, and other tools to help you get your job done. All the research can be rated and commented on, which helps ensure the content is useful and up to date as well as helping us to improve the content over time based on your feedback. The system tracks your history so you never forget what you read, and enables you to build a custom library of your favorite content. Good questions are anonymized and tied back to the content, to help others with the same problems. And we are just getting going, there will be even more capabilities in the coming months. What are the platform requirements? The Nexus should work with all current browsers, as well as Internet Explorer version 7 and later. Although we don’t have an iOS app yet, we have optimized the site to work well on the iPad. Beta Testing When does the beta start? If you are reading this, it has started. Why can’t I log in yet? We are running the beta in phases and will be adding people on an ongoing basis. We are very conservative, and really want to ensure the system is ready before we let too many people in. We will email you when your name comes up, and we plan to eventually include everyone who signs up for the beta. What can I expect in the beta? This is a real beta test – while the entire system is functional, there will be some bugs. We have set up forum for feedback and will directly answer system questions (but not research questions) there. During the beta, we will be adding research on a daily basis. The beta is opening with the first layer of PCI information, but we have a ton more to add before we open the system to the public (and ask people to pay for it). We will post announcements on the portal page as we add material throughout the beta. Right now, the weakest area is multimedia and tools/templates – such as checklists and PowerPoint samples. We will be adding these along with the rest of the content throughout the beta period. Ask an Analyst is completely open for business, so please do your best to stump us. Is the beta free? Yes. In exchange for your help testing, we provide access to all the content as we build it, plus the Ask an Analyst tool for questions. Will I get a free membership after the beta? No. The Nexus will be competitively priced (think hundreds, not thousands), but beta testers will need to subscribe after we open it up to the public. But until then you get all the free research and advice you can eat. Where should I leave feedback? Please use the beta forum linked on the portal page. That provides direct access to our developers and doesn’t clutter up the comments or the rest of the live system. After the beta, will you delete my account? No – you won’t have access, but your account will stay there if you want to come back. You should also review our privacy policy. Privacy Policy The Securosis Nexus does not sell your information to anyone, ever. We do retain the right to sell or distribute bulk statistics (e.g., what content is most viewed, what topics create the

Read Post

Incite 10/12/2011: Impact and Legacy

As have been overly reported over the past week, Steve Jobs is gone. As Rich so adroitly pointed out, “His death hit me harder than I expected. Because not only do we not have a Steve Jobs in security, we no longer have one at all.” You know, someone who seems to be the master of the universe. Perfection personified. Of course, the reality is never perfection. But what’s perfect is imperfection. Jobs failed. Jobs started over. He took chances and ultimately triumphed. Jobs had the perspective you wished you could have. This is clearly demonstrated by what I believe to be the best speech written in my lifetime (at least so far), Steve Jobs’ Stanford Commencement speech. Why? Because if you pay attention, really pay attention to the words, it’s about the human struggle. Do what you love. Follow your own path. Don’t settle for mediocrity. Live each day to the fullest. Realize we are here for a short time, and act accordingly. It’s not trite. You can and should strive for this. You see impact and legacy works itself out, depending on the actions you take every day. Probably none of us will have an impact like Steve Jobs. Nor should we. You don’t need to be Steve Jobs. Just be you. You don’t have to change the world. Just make it a little better. Be a giver, not a taker. Believe in some kind of karma. Pay it forward. Do the right thing. Lead by example, and hopefully people around you will do the right thing ti. If that happens, we all win, collectively. I’m not going to say don’t change the world. Or don’t try. We need folks who want to change things on a massive scale, and will do the work to make it happen. My point is that it doesn’t have to be you. As Steve Jobs said, “Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma – which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.” Change happens in many forms. We all want to leave the world better than when we got here. That’s what I’m working for. It’s not my place to strive for a legacy or to worry about my impact. All I can do is get up every day and do something positive. Some days will go better than others. And eventually (hopefully many years from now), I’ll be gone. Then it will be up to others to figure out my impact and legacy. Since I don’t know when my time will be up, I had better get back to work. –Mike Photo credits: “Legacy Parkway shield” originally uploaded by CountyLemonade Incite 4 U Take my cards, give me back my wallet: It’s always interesting to see the market value of anything. Not just what you think something is worth. But what someone is actually willing to pay. So thanks to Imperva for mining some bad sites and posting the Current Value of Credit Cards on the Black Market. If you take a look at what’s in my wallet, you’ll see about $15 bucks worth of cards (2 AmEx, a MasterCard, and a bank card). My wallet is worth at least $30, since it’s nice Corinthian leather (said in my best Ricardo Montalban voice). So take my cards, but I’ll fight you for my wallet. – MR Free malware scans: Google announced a Free Safe Browsing Alert for Network Administrators this week, alerting IT when malware is discovered by Google on their machines. The service leverages their malware detection capability announced last year, which discovers malware through a combination of user generated Safe Browsing data and Google’s site indexing crawlers. IT admins can register for alerts when Google discovers malware on the public servers within their control. This free tool will be disruptive to all the security vendors positioning malware detection as a ‘must-have’ feature – so long as it works. Hard to see how folks can continue charging a premium for this ‘differentiating’ service. – AL How about a tour of Alaska? We all know that no matter what you do, bad stuff still happens. As we always say around here, you will be breached at some point. The true test of your security mettle isn’t if you keep the bad guys out, but how you respond when they get in. A lot of that is in the heart of our paper on advanced incident response. One of the main things we talk about in that paper is knowing when, and how, to escalate your incident response process and bring in the next level of experts. While we didn’t explicitly mention it, having your command and control center for air combat drones infected with a virus would be pretty high on the list. It seems the folks on the ground failed to escalate and let the cybersecurity experts get involved. The cybersecurity command learned about it by reading Wired. If a four star general is learning that your control center for those buzzing things sometimes armed with missiles might be a staging depot for the latest warez, it might be time to break out your cold weather gear. -RM Maybe actually do something: OK, time for some snark. I just had to see what pearls of wisdom were in the article 8 ways to become a cloud security expert. Basically it’s a list of conferences and a few blogs. So let me get this straight. Go to RSA or the CSA Congress and you are all of a sudden an expert. C’mon, man! I have a different idea. Why don’t you actually do something in the cloud and protect it. Yeah, maybe build an instance, harden it, configure some security

Read Post

Tokenization Guidance: PCI Supplement Highlights

The PCI DSS Tokenization Guidelines Information Supplement – which I will refer to as “the supplement” for the remainder of this series – is intended to address how tokenization may impact Payment Card Industry (PCI) Data Security Standard (DSS) scope. The supplement is divided into three sections: a discussion of the essential elements of a tokenization system, PCI DSS scoping considerations, and new risk factors to consider when using tokens as a surrogate for credit card numbers. It’s aimed at merchants who process credit card payment data and fall under PCI security requirements. At this stage, if you have not downloaded a copy, I recommend you do so now. It will provide a handy reference for the rest of this post. The bulk of that document covers tokenization systems as a whole: technology, workflow, security, and operations management. The tokenization overview does a good job of introducing what tokenization is, what tokens look like, and the security impact of different token types. The diagrams do an excellent job of illustrating of how token substitution fits within normal payment processing flow, providing a clear picture of how an on-site tokenization system – or a tokenization service – works. The supplement stresses the need for authorization and network segmentation – the two critical security tools needed to secure a token server and reduce compliance scope. The last section of the supplement helps readers understand the risks inherent to using tokens – which are new and distinct from the issues of traditional security controls. Using tokens directly for financial exchange, instead of as simple references to the real financial data in a private token database, carries its own risk – a hacker could use the tokens to conduct transactions, without needing to crack the token database. Should they penetrate the IT systems, even if there is no credit card, if it can be used as a financial instrument, hackers will misuse it. If the token can initiate a transaction, force a repayment, or be used as money, there is risk. This section covers a couple critical risk factors merchants need to consider; although this has little to do with the token service – it is simply an effect of how tokens are used. Those were the highlights of the supplement – now the lowlights. The section on PCI Scoping Considerations is convoluted and ultimately unsatisfying. I wanted bacon but only got half a piece of Sizzlean. Seriously, it was one of those “Where’s the beef?” moments. Okay, I am mixing my meats – if not my metaphors – but I must say that initially I thought the supplement was going to be an excellent document. They did a fantastic job answering the presales questions of tokenization buyers in section 1.3: simplification of merchant validation, verification of deployment, and unique risks to token solutions. But after my second review, I realized the document does offer “scoping considerations”, but does not provide advice, nor a definitive standard for auditing or scope reduction. That’s when I started making phone calls to others who have read the supplement – and they were as perplexed as I was. Who will evaluate the system and what are the testing procedures? How does a merchant evaluate a solution? What if I don’t have an in-house tokenization server – can I still reduce scope? Where is the self-assessment questionnaire? The supplement does not improve user understanding of the critical questions posed in the introduction. As I waded through page after page, I was numbed by the words. It slowly lulled me to sleep with stuff that sounded like information – but wasn’t. Here’s an example: The security and robustness of a particular tokenization system is reliant on many factors including the configuration of the different components, the overall implementation, and the availability and functionality of the security features for each solution. No sh&$! Does that statement – which sums up their tokenization overview – help you in any way? Is this statement be true for every software or hardware system? I think so. Uselessly vague statements like this litter the supplement. Sadly, the first paragraph of the ‘guidance’ – a disclaimer repeated at the foot of each page, quoted from Bob Russo in the PCI press release – reflects the supplement’s true nature: “The intent of this document is to provide supplemental information. Information provided here does not replace or supersede requirements in the PCI Data Security Standard”. Tokenization should replace some security controls and should reduce PCI DSS scope. It’s not about layering. Tokenization replaces one security model for another. Technically there is no need to adjust the PCI DSS specification to account for a tokenization strategy – they can happily co-exist – with one system handling non-sensitive systems and the other handling those which store payment data. But not providing a clear definition of which is which, and what merchants will be held accountable for, demonstrates the problem. It seems clear to me that, based on this supplement, PCI DSS scope will never be reduced. For example, section 2.2 rather emphatically states “If the PAN is retrievable by the merchant, the merchant’s environment will be in scope for PCI DSS.” Section 3.1, “PCI DSS Scope for Tokenization”, starts from the premise that everything is in scope, including the tokenization server, as it should be. But what falls out of scope and how is not made clear in section 3.1.2 “Out-of-scope Considerations”, where one would expect to find such information. Rather than define what is out of scope, it outlines many objectives to be met, seemingly without regard for where the credit card vault resides, or the types of tokens used. Section 3.2, titled “Maximizing PCI DSS Scope Reduction”, states that “If tokens are used to replace PAN in the merchant environment, both the tokens, and the systems they reside on will need to be evaluated to determine whether they require protection and should be in scope of PCI DSS”. From this statement, how can anything then be out of

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.