Securosis

Research

New Paper: Defending Data on iOS 7

I have been working on this one quietly for a while. It is a massive update to my previous paper on iOS security. It turns out Apple made a ton of very significant changes in iOS 7. So many that they have upended how we think of the platform. This paper digs into the philosophy behind Apple’s choices, details the security options, and then provides a detailed spectrum of approaches for managing enterprise data on iOS. It is 30 pages but you can focus on the sections that matter to you. I would like to thank WatchDox for licensing the content, which enables us to release it for free. Normally we publish everything as a blog series, but in this case I had an existing 30-page paper to update and it didn’t make sense to (re-)blog all the content. So you might have noticed me slipping in a few posts on iOS 7 recently with the important changes. I can do another revision if anyone finds major problems. And with that, here is the landing page for the report. And here is the direct download link: Defending Data on iOS 7 (PDF) And lastly, the obligatory outline screenshot: Share:

Share:
Read Post

We Need to Thank Target for Being Hacked

Normally we like to blame the victim, but in this case we need to thank them. From the WSJ, the swap to Chip and PIN will happen by October 2015. Here is the key point: Part of the October 2015 deadline in our roadmap is what’s known as the ‘liability shift.’ Whenever card fraud happens, we need to determine who is liable for the costs. When the liability shift happens, what will change is that if there is an incidence of card fraud, whichever party has the lesser technology will bear the liability. So if a merchant is still using the old system, they can still run a transaction with a swipe and a signature. But they will be liable for any fraudulent transactions if the customer has a chip card. And the same goes the other way – if the merchant has a new terminal, but the bank hasn’t issued a chip and PIN card to the customer, the bank would be liable. None of this affects online transactions, though. Share:

Share:
Read Post

Friday Summary: Ink Stained Wretch

I love writing. Except when I hate it. When people ask what I do for a living, I almost never say ‘writer’. I’m an analyst, who occasionally dabbles as a tech journalist, but pumps out more words in typical a year than many professional writers. When the muse is in my corner and the words flow smooth and swift like molten chocolate (sorry, need dessert), the process is incredibly gratifying. I can sometimes pop off a thousand words an hour and walk away deeply satisfied, with perhaps some light editing. That doesn’t really happen a lot since I had kids. More often I plan out a wonderful schedule with plenty of leisure time to settle into the words, build my story (because even tech pieces are stories), and enlighten readers with my content and wit. Then I don’t sleep, I lose a couple days to sick kids or other randomness, and hope beyond hope I can snag a few hours in a coffee shop, pace my caffeine intake perfectly, and maybe, just maybe, finish up before my deadline is so far past that the client forgets my name. Writing on deadline is tough – especially when family, illness, and the ongoing needs of running a business continually conspire to interfere with any plans. It doesn’t help to be a genetic procrastinator of such accomplishment that, in your formal college record, there is a note saying, “don’t cut him any breaks, he manipulates the system too much”. (It’s true – I saw the note in my physical file). Take this Summary. I am writing it in a hotel room in Toronto after a really rough couple weeks defined by illness (my own and one of my kids), right after a rough couple months going back to the holidays. There have been ear infections, stomach bugs, general sniffles, and 9-day fevers. I two stomach bugs 6 weeks, once on the day I needed to fly out to teach a cloud security class. Somehow, through all this, I managed to nail my target deadlines on the Future of Security series, a non-security article for a new publication (for me), and complete a good chunk of my RSA planning. I owe two different conferences four presentations (total), need to launch 2 papers in the next week, and add two more modules to my RSA demo code (overkill, but I would really like to pull it off). But I wouldn’t really have it any other way. Oh sure, I’d like less pressure, but look what I get to do on a daily basis… And running at this pace for so long has turned me into an honest-to-gosh writer, even outside the technology domain. I have written for The Magazine and soon The Loop – not even on security or technology! I was paid to tell stories, and that is deeply satisfying. And while I can’t say everything I write for Securosis excites me equally, some of my recent work has been very rewarding. I never set out to be a writer. And while I have no intention of writing the Great American Novel, I feel pretty lucky to get paid to write words read by thousands. It’s pretty special, and never something I take for granted. Even tonight. Locked in a sparse hotel room with a sniffly nose and an early wakeup call. I do, however, have cookies. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on the Yahoo email issue by the AP. Favorite Securosis Posts Mike Rothman: Security’s Future: Implications for Security Vendors. Lots of security vendors will keep their heads in the sand about the fundamental changes happening and how they will impact security. Don’t say we didn’t warn you… David Mortman: Security’s Future: What it Means (Part 3). Other Securosis Posts Incite 2/5/2014: Super Dud. Firestarter: Inevitable Doom. Security’s Future: Implications for Cloud Providers. Security’s Future: What it Means (Part 3). Security’s Future: Six Trends Changing the Face of Security. Quick Wins with TISM. TISM: The Threat Intelligence + Security Monitoring Process. Favorite Outside Posts Mike Rothman: Russell Brand: my life without drugs. You can’t understand addiction unless you’ve been there. Chilling view into the mind of an addict from Russell Brand. Mike Rothman: Kansas teen uses 3-D printer to make hand for boy. Who says we aren’t living in the future? And to think the kid did such an amazing thing using a 3D printer in a public library. Just amazing! David Mortman: Who owns the data in the Internet of Things? Adrian Lane: Think SQLi is old news? The PR hype machine got tired of talking about it, but the problem never went away. Diana Kelley beat me to the punch on this, and did a great job of explaining what to do about it. Rich: Brian Krebs with more Target details. Bad guys came in via an HVAC contractor. I believe it was a small exhaust port, right below the main port. Research Reports and Presentations Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Top News and Posts Senate grills Target CFO on data breach Verizon Wages War on Netflix. Technically on Amazon AWS, although Netflix is the obvious target. Adobe pushes out-of-band patch for Flash. Target moving to Chip and PIN after attack. I’m in Canada and they look at me like I’m a freaking savage every time I have to swipe my credit card. But hey, we have PCI. No Comment of the Week this time – sorry. Share:

Share:
Read Post

Security’s Future: Implications for Security Vendors

This is the fourth post in a series on the future of information security, which will be the basis for a white paper. You can leave feedback here as a blog comment, or even submit edits directly over at GitHub, where we are running the entire editing process in public. This is the initial draft, and I expect to trim the content by about 20%. The entire outline is available. See the first post, second post, and third post. Implications for Security Vendors and Providers These shifts are likely to dramatically affect existing security products and services. We already see cloud and mobile adoption and innovation outpacing many other security tools and services. They are not yet materially affecting the profits of these companies, but the financial risks of failing to adapt in time are serious. Many vendors have chosen to ‘cloudwash’ existing offerings – they simply convert their product to a virtual appliance or make other minor tweaks, but for technical and operational reasons we do not see this as a viable option over the long term. Tools need to fit the job, and we have shown that cloud and mobile aren’t merely virtual tweaks of existing architectures, but fundamentally alter things at a deep level. The application architectures and operations models we see in leading web properties today are quite different than traditional web application stacks, and likely to become the dominant models over time because they fit the capabilities of cloud and mobile. The security trends we identified also assume shifting priorities and spending. For example hypersegregated cloud networks and greater reliance on automatically configuring servers (required for autoscaling, a fundamental cloud function) reduce the need for traditional patch management and antivirus. When it is trivial to replace a compromised server with a new one within minutes, traffic between servers is highly restricted at a per-server level, and detection and incident response are much improved, then AV, IDS, and patch management may not be essential security controls. Security tools need to be as agile and elastic as the infrastructure, endpoints, and services they protect; and they need to fit the new workflow and operational models emerging to take advantages of these advances – such as DevOps. The implications for security vendors and providers fall into two buckets: Fundamental architectural and operational differences require dramatic changes to many security tools and services to operate in the new environment. Shifting priorities make customers shift security spending, impacting security market opportunities. Preparing for the Future It is impossible to include every possible recommendation for every security tool and service on the market, but some guiding principles can prepare security companies to compete in these markets today, and as they become more dominant in the future: Support consumption and delivery of APIs: Adding the ability to integrate with infrastructure, applications, and services directly using APIs increases security agility, supports Software Defined Security, and embeds security management more directly into platforms and services. For example network security tools should integrate directly with Software Defined Networking and cloud platforms so users can manage network security in one place. Customers complain today that they cannot normalize firewall settings between classical infrastructure and cloud providers, and need to manage each separately. Security tools also need to provide APIs so they can integrate into cloud automation, and to avoid becoming a rate limiter – and later inevitably getting kicked to the curb. Software Development Kits and robust APIs will likely become competitive differentiators because they help integrate directly security into operations, rather than interfering and perturbing workflows that provide strong business benefits. Don’t rely on controlling or accessing all network traffic: A large number of security tools today, from web filtering and DLP to IPS, rely on completely controlling network traffic and adding additional bumps in the wire for analysis and action. The more we move into cloud computing and extensive mobility, the fewer opportunities we have to capture connections and manage security in the network. Everything is simply too distributed, with enterprises routing less and less traffic through core networks. Where possible, integrate directly with platforms and services over APIs, or embed security into host agents designed for highly agile cloud environments. You cannot assume the enterprise will route all traffic from mobile workers through fixed control points, so services need to rely on Mobile Device Management APIs and provide more granular protection at the app and service level. Provide extensive logs and feeds: Security logs and tools shouldn’t be black holes of data: receiving but never providing. The Security Operations Center of the future will rely more on aggregating and correlating data using big data techniques, so they will need access to raw data feeds to be most effective. Expect demand to be more extensive than from existing SIEMs. Assume insanely high rates of change: Today, especially in audit and assessment, we rely on managing relatively static infrastructure. But when cloud applications are designed to rely on servers that run for less than an hour, even daily vulnerability scans are instantly out of date. Products should be as stateless as possible – rely on continually connecting and assessing the environment rather than assuming things change slowly. Companies that support APIs, rely less on network hardware for control, provide extensive data feeds, and assume rapid change, are in much better positions to accomodate expanding use of cloud and mobile devices. It is a serious challenge, as we need to provide protection to a large volume of distributed services and users, without anything like the central control we are used to. We work extensively with security vendors. It is hard to overstate how few we see preparing for these shifts. Share:

Share:
Read Post

Firestarter: Inevitable Doom

Okay, let’s just ignore the first part of this Firestarter where we talk about the Denver Broncos, okay? We recorded it on the Friday before the game and, well, enough said. Then we turned to some recent tech and company ideas we have seen, and why they are doomed to fail. Kind of like you-know-who. Sigh. Share:

Share:
Read Post

Security’s Future: What it Means (Part 3)

This is the third post in a series on the future of information security, which will be the basis for a white paper. You can leave feedback here as a blog comment, or even submit edits directly over at GitHub, where we are running the entire editing process in public. This is the initial draft, and I expect to trim the content by about 20%. The entire outline is available. See the first post and the second post. What it Means The disruptions and trends we have described don’t encompass all advances in the worlds of technology and security, but they represent the ones which will most fundamentally transform the practice of security over the next decade. For example we haven’t directly addressed Software Defined Networks (although aspects show up in our cloud, hypersegregation, and Software Defined Security descriptions), malware ecosystems, or the increasing drive toward pervasive encryption (driven, in no small part, by government spying). Our focus is on the changes most fundamentally alter the practice of security, and the resulting outcomes. The changes come in fits and spurts – distributed unevenly, based on technology adoption rates, economics, and even social factors. But aggregated together, they paint a picture we can use to guide decisions today – for both organizations and professionals. All these changes are currently in process, with plenty of real-world examples. This report focuses on the implications for three groups: security professionals, security vendors and providers, and cloud and infrastructure providers. The people tasked with implementing security, the folks who create the tools and services they use, and the public and private IT departments managing our platforms and services. Let’s start with some high-level principles for understanding how security controls will evolve, then dig into the implications for our three audiences. Security Controls Evolution There is no way to predict exactly how the future will turn out or how security controls will evolve as these trends unfold. But one key question with a few logical follow-ups, can quickly help identify how security controls will likely adapt (or at least need to) in the face of change. How does this enable my security strategy? What does the provider or technology give me? What does it do? What do I need to do? The purpose of this question is to examine how the lines of responsibility and control will shift. For example, when choosing a new cloud provider, what security controls do they provide? Which can you manage? Where are the gaps? What security controls can you put in place to address those gaps? Does moving to this provider give you new security capabilities you otherwise lacked? Or, for a new security tool like active defense: Does this obviate our need for IPS? Does it really improve our ability to detect attackers? What kind of attackers and attacks? How can and will we adjust our response strategy? Here are two interrelated examples: iOS 7 includes mobile device management hooks to restrict data migration on the device to only enterprise-approved accounts and apps, all strongly encrypted and protected by stringent sandboxing. While this could significantly improve data security over standard computers, it also means giving up any possibility of Data Loss Prevention monitoring, and needing to implement a particular flavor of mobile device management. However… Cloud storage and collaboration providers keep track of every version of every file they hold for customers. Some even track all device and user access on a per-file basis. Use one of these with your mobile apps, and you might be able to replace DLP monitoring with in-depth real-time auditing of all file activity at the cloud level – including every device that accesses the files. The combination provides a security and audit capability that is effectively impossible with ‘traditional’ device management and storage, but requires you to change how you implement a series of security controls. Focus on your security strategy. Determine what you can do, what your provider or tool will do, who is responsible, and the technology capabilities and limitations – rather than how to migrate a specific, existing control to the new operating environment. Implications for Security Practitioners Security practitioners in the future will rely on a different core skill set than many professionals possess today. Priorities shift as some risks decline, others increase, and operational practices change. The end result is a fundamental alteration of the day-to-day practice of security. Some of these are due to the disruptions of the cloud and mobility, but much of it is due to the continued advancement of our approaches to security (partially driven by our six trends; also influenced by attackers). We covered cloud computing in depth in our paper What CISOs Need to Know about Cloud Computing. Let’s look at the different skills and priorities we expect to be emphasized by the combination of cloud, mobile, and our six inherent security trends. New Skills As with any transition, old jobs won’t be eliminated immediately, but the best opportunities will go to those with knowledge and expertise best aligned to new needs. These roles are also most likely to command a salary premium until the bulk of the labor market catches up, so even if you don’t think demand for current skills will decline, you still have a vested interest in gaining the new skills. All these roles and skills exist today, but we expect them to move into the core of the security profession. Incident Response is already seeing tremendous growth in demand, as more organizations shift from trying only to keep attackers out (which never works) to more rapidly detection, containment, and remediation of successful attacks. This requires extensive security expertise and cannot be handed off to Operations. Secure Programming includes assisting with adding security functions to other applications, evaluating code for security issues (although most of that will be automated), and programming Software Defined Security functions to orchestrate and automate security across tools. It requires both programming and security domain expertise to be truly effective. Some practitioners will find themselves more on the secure application development side (integrating security into applications),

Share:
Read Post

Security’s Future: Six Trends Changing the Face of Security

This is the second post in a series on the future of information security, which will be the basis for a white paper. You can leave feedback here as a blog comment, or even directly submit edits over at GitHub, where we are running the entire editing process in public. This is the initial draft, and I expect to trim the content by about 20%. The entire outline is available. The first post is available. The cloud and mobile computing are upending the foundational technological principles of delivery and consumption, and at the same time we see six key trends within security itself which promise to completely transform its practice over time. These aren’t disruptive innovations so much as disruptive responses and incremental advances that better align us with where the world is heading. When we align these trends with advances in and adoption of cloud and mobile computing, we can picture how security will look over the next seven to ten years. Hypersegregation We have always known the dramatic security benefits of effective compartmentalization, but implementation was typically costly and often negatively impacted other business needs. This is changing on multiple fronts as we gain the ability to heavily segregate, by default, with minimal negative impact. Flat networks and operating systems will not only soon be an artifact of the past, but difficult to even implement. Hypersegregation makes it much more difficult for an attacker to extend their footprint once they gain access to a network or system, and increases the likelihood of detection. Most major cloud computing platforms provide cloud-layer software firewalls, by default, around every running virtual machine. In cloud infrastructure, every single server is firewalled off from every other one by default. The equivalent in a traditional environment would be either a) host-based firewalls on every host, of every system type, with easily and immediately managed policies across all devices, or b) putting a physical firewall in front of every host on the network, which travels with the host if and when it moves. These basic firewalls are managed via APIs, and by default even segregate every server from every other server – even on the same subnet. There is no such thing as a flat network when you deploy onto Infrastructure as a Service, unless you work hard to reproduce the less secure architecture. This segregation has the potential to expand into non-cloud networks thanks to Software Defined Networking, making hypersegregation the default in any new infrastructure. We also see hypersegregation working extremely effectively in operating systems. Apple’s iOS sandboxes every application by default, creating another kind of ‘firewalls’ inside the operating system. This is a major contributor to iOS’s complete lack of widespread malware – going back to the iPhone debut seven years ago. Apple now extends similar protection to desktop and laptop computers by sandboxing all apps in the Mac App Store. Google sandboxes all tabs and plugins in the Chrome web browser. Microsoft sandboxes much of Internet Explorer and supports application level sandboxes. Third-party tools extend sandboxing in operating systems through virtualization technology. Even application architectures themselves are migrating toward further segregating and isolating application functions to improve resiliency and address security. There are practical examples today of task and process level segregation, enforcing security policy on actions by whitelisting. The end result is networks, platforms, and applications that are more resistant to attack, and limit the damage of attackers even when they succeed. This dramatically raises the overall costs of attacks while reducing the necessity to address every vulnerability immediately or face exploitation. Operationalization of Security Security, even today, still performs many rote tasks that don’t actually require security expertise. For cost and operational efficiency reasons, we see organizations beginning to hand off these tasks to Operations to allow security professionals to focus on what they are best at. This is augmented by increasing automation capabilities – not that we can ever eliminate the need for humans. We already see patch and antivirus management being handled by non-security teams. Some organizations now extend this to firewall management and even low-level incident management. Concurrently we see the rise of security automation to handle more rote-level tasks and even some higher-order functions – especially in assessment and configuration management. We expect Security to divest itself of many responsibilities for network security and monitoring, manual assessment, identity and access management, application security, and more. This, in turn, frees up security professionals for tasks that require more security expertise – such as incident response, security architecture, security analytics, and audit/assessment. Security professionals will play a greater role as subject matter experts, as most repetitive security tasks become embedded into day-to-day operations, rather than being a non-operations function. Incident Response One of the benefits of the increasing operationalization of security is freeing up resources for incident response. Attackers continue to improve as technology further embeds itself into our lives and economies. Security professionals have largely recognized and accepted that it is impossible to completely stop attacks, so we need greater focus on detecting and responding to incidents. This is beginning to shift security spending toward IR tools and teams, especially as we adopt the cloud and platforms that reduce our need for certain traditional infrastructure security tools. Leading organizations today are already shifting more and more resources to incident detection and response. To react faster and better, as we say here. Not simply having an incident response plan, or even tools, but conceptually re-prioritizing and re-architecting entire security programs – to focus as much or more on detection and response as on pure defense. We will finally use all those big screens hanging in the SOC to do more than impress prospects and visitors. A focus on incident response, on more rapidly detecting and responding to attacker-driven incidents, will outperform our current security model – which is overly focused on checklists and vulnerabilities – affecting everything from technology decisions to budgeting and staffing. Software Defined Security Today security largely consists of boxes and agents distinct from the infrastructure we protect. They won’t go away, but the cloud and increasingly available APIs

Share:
Read Post

Security’s Future: a Disruptive Collision

This is the first post in a series on the future of information security, which will be the basis for a white paper. You can leave feedback here as a blog comment, or even directly submit edits over at GitHub, where we run the entire editing process in public. This is the initial draft, and I expect to trim the content by about 20%. The entire outline is available. A Disruptive Collision At the best of times, the practice of information security is defined by disruption. We need to respond to business and technology innovations – not only from those we defend, but also from their attackers. Security is never really in control of our own destiny – we are tasked with managing the risks of decisions made by others, in the face of entire industries (and economies) dedicated to discovering new ways of stealing or hurting them and us. We are reactive because those we protect and those who attack are never fully predictable – not because of an inherent failing of security. But the better we predict these disruptions, and the better we prepare our response, the more effective we are. As analysts, we at Securosis focus most of our research on the here and now – on how best to tackle the security challenges faced by CISOs and security professionals when they show up to work in the morning. Occasionally as part of this research we note trends with the potential to dramatically affect the security industry and our profession. We currently see what appears to be the largest combination (collision) of disruptive forces since the initial adoption of the Internet – with implications for security far beyond our first tentative steps onto the global network. Additionally, we have identified six key trends which are currently altering the practice of security. This combination of external and internal change is fundamentally transforming the practice of security. This paper starts with a description of the disruptive forces and the native security trends, but its real objective is to lay out their long-term implications for the practice of security – and how we expect security to evolve for security professionals, security vendors, and cloud and other infrastructure providers. Through the report we will back up our analysis with real-world examples that show this transformation isn’t a vague possibility in a distant future, but is already well under way. But although these changes are inevitable, they are far from evenly distributed. As you will see, this provides plenty of time and incentive for professionals and organizations to prepare. Two Disruptive Innovations Clayton Christensen first coined the term “disruptive technology” in 1995 (he later changed the term to “disruptive innovation”) to describe new business and technology practices that fundamentally alter, and eventually supersede, existing ones. Innovation always causes change, but disruptive innovation mandates change. Innovation creates new opportunities and disrupts old ones. The technology world is experiencing a combination of two disruptive innovations simultaneously colliding and reinforcing each other. Cloud computing alters the consumption and delivery models for technology at both economic and technical levels. Advances in mobile technology are changing our access and consumption models, and reinforcing demand for the cloud – particularly at scale. Cloud Computing Cloud computing is a radically different technology model – it is not simply the latest flavor of outsourcing. It uses a combination of abstraction and automation to achieve previously impossible levels of efficiency and elasticity. This, in turn, creates new business models and alters the economics of technology delivery and consumption. Sometimes this means building your own cloud in your own datacenter; other times it means renting infrastructure, platforms, and applications from public providers over the Internet. Public cloud services eliminate most capital expenses, shifting them to on-demand operational costs instead. Private clouds allow more efficient use of capital, may reduce operational costs, and make technology more responsive to internal needs. Cloud computing fundamentally disrupts traditional infrastructure because it is more responsive, more efficient, and potentially more resilient and cost effective than our old ways of doing things. These are the same drivers that pushed us toward application service providers and virtualization. Public cloud computing is even more disruptive because it enables organizations to consume only what they need without maintaining overhead, while still rapidly responding to changing needs at effectively infinite scale (assuming an adequate checkbook). Every major enterprise we talk with today uses cloud services, and even some of the most sensitive industries, such as financial services, are exploring more extensive use of public cloud computing. We see no technical, economic, or even regulatory issues slowing this shift. Many security professionals focus on the multitenancy risks introduced by cloud, but abstraction and automation are more significant than shared infrastructure or services. Many security controls today rely on knowing and managing the physical resources that underpin our technology services. Abstraction breaks this model by virtualizing resources (including entire applications) into resource pools managed over the network. We give up physical control and shift management functions to standard network interfaces, creating a new management plane. This separation and remote management challenge or destroy traditional security controls. Abstraction is central to virtualization, and we are at least nominally familiar with its issues. But this kind of automation is specific to the cloud, and adds an orchestration layer to efficiently utilize resource pools. It enables extreme agility, such as servers that exist only for hour or minutes – automatically provisioned, configured, and destroyed without human interaction. Application developers can check in a piece of code, which then runs through a dozen automated checks and is pushed into production on a self-configuring platform that scales to meet demand. Security that relies on controlling the rate of change, or that mandates human checks, simply cannot keep up. Virtualization is the core enabling technology of abstraction, and Application Programming Interfaces (APIs) are the core enabler of automation. The elasticity and agility they together provide enable new operational models such as DevOps, which consolidate historically segregated management functions to improve efficiency and responsiveness. Combined with greater reliance on public cloud computing, the Internet itself becomes the interconnected platform for our applications and workloads. Defining DevOps

Share:
Read Post

New Series (and Paper): The Future of Information Security

Update: Here are links to the series as we post it: Post 1 Post 2 Post 3 Post 4 Post 5 Back in 2012 I wrote a post titled Inflection. It was a collection of ideas and trends I have been watching, with the implications for the practice of security. This year I submitted it to the RSA Conference and it was accepted. I will be giving an updated presentation based on that post Tuesday afternoon. I thought that would be the end of it, because this isn’t the sort of research someone is usually interested in licensing and so it stays on the blog. But I was contacted by the folks at Box who were looking for something different that focuses more on where the industry is headed than our usual papers on helping you manage a current security issue. As an analyst I believe the majority of my published research should focus on day-to-day management of security, but it is also important to push the edges a bit and spend time thinking about the bigger picture. I am particularly excited about this paper because it isn’t being licensed by a traditional security vendor. The call from Box came out of left field, and shows that cloud and content providers are seeing security as a competitive differentiator. That isn’t an endorsement – no one can ever pay us to say nice things about them, but I can honestly say we are doing more work this year outside the traditional security market than I have ever seen before. To wet your whistle as I start writing the content, here’s a graphic of the outline. I will also be putting the content up on GitHub as I write and edit it for public feedback and review. I’m finding I like that better than the blog for the people who want to provide feedback, but this feed is better for getting the draft content out to a wide audience. We’ll take feedback on either side. Oh, and I could really use some help with a better title! This one feels a little pretentious to me, but I am struggling for something better and “Inflection” doesn’t translate well to a paper. Thanks, and here’s the outline: Share:

Share:
Read Post

Firestarter: Government Influence

In this week’s Firestarter Rich, Mike, and Adrian (until his computer died) discuss the importance (or lack thereof) of the security industry and community in influencing government. Adrian drops out part-way through due to his frugal laptop choice, but rumor is he whipped out the credit card and payed homage to Apple shortly after the conclusion of this week’s recording. Share:

Share:
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.