Cyber security: Emphasize Protect or Detect?

February 16, 2019

I am a subscriber to the NIST cyber security framework school of thought. Even though it is officially called the “Framework for Improving Critical Infrastructure Cybersecurity” it isn’t just about securing critical infrastructure, it really is applicable to every organization, industry and geography. Every organization has cyber assets that are critical to the business, and if they don’t – they are building those assets quickly through a digitalization initiative or slowly going out of business.

NIST’s strong point is that it takes an organizational and risk centric view of cyber defense as opposed to an attack centric view. The NIST framework is a set of categories with an implicit flow – starting at Identify. Each category builds on the information and processes from the previous category (there is also a feedback loop that isn’t depicted).

The NIST framework divides into proactive security (identify and protect) and reactive security (detect, respond, recover). I spend a lot of time with cyber security startups and lately I am hearing startups emphasizing the reactive part.

If you dig a little beneath that you find they assume companies have already made a large investment in “protect” and are pretty well defended. Then the next logical step is to bolster their layered defenses to protect themselves against the small number of attacks that do get through. In that context it makes sense – if you already have a strong “protect” stance then it makes sense that next thing on your list should be bolstering your reactive cyber defense capability – and making sure you have the people, processes and tools in place to detect and respond as quickly as possible. That logic holds for the few companies that are really at the forefront of cyber defense

For the other 99% of the world – they need to first focus on identify and protect, as laid out by the NIST cyber security framework. Really it is simple logic – put the tools and processes in place to identify and decide what you need to protect (and how much) and then put the appropriate protection (tools and processes) in place.

The same is true for a cyber platform – it needs to first focus on active security, and build on that to as a basis for reactive security.


5 Indicators Cyber-Security needs a Platform

February 16, 2019

Cyber security is a market ripe for a platform:

  • There is a large underserved market of consumers most companies. Most companies have only rudimentary cybersecurity capabilities and the situation at smaller companies is even worse. As more companies start on their digitization journeys they will become even more vulnerable to cyber-attacks, and their current defenses are woefully inadequate. Cyber insurance in its current state and on its own won’t solve the problem.
  • There are a multitude of producers that can provide partial solutions to serve those consumers, but have difficulty getting their solution to a broad market. There are about 800 startup companies in the cyber space – many are what I would call “features”, i.e. they have neat technology that solve a real, but very specific problem. On top of that there are hundreds of more established companies and service providers. I’ve seen numbers as high as1500 different cyber security vendors in total.
  • There is a large number of “local” producers that end up building or integrating the same pieces in order to get to market. Every cyber solution vendor ends up spending most of their time and effort on “peripheral tasks” (management, deployment, reporting) and integrating with others – SIEMs, SOCs, etc. These peripheral tasks don’t enhance their core technology but are critical for customer success – no matter how good the underlying technology.
  • The intended market for the platform is global. i.e. consumers worldwide have the same problems, and solutions don’t need to be tailored per market. The cyber issue cuts across countries and industries. It is an equal opportunity problem for everyone. Healthcare, Finance, Manufacturing, Government have all seen large attacks and breaches over the last couple years. Some countries are more prone to attack than others – but no one is exempt.
  • A growing number of providers in the market are building their own technical platforms or services, for their own use but not as a two-sided market.Many cyber companies have some version of what they call a platform. One set are the security management solutions, for example Symantec Connect and Checkpoint R80. Another type are security incident response solutions like Hexadite and IBM Resilient. These are not really market platforms like ebay or Android, but rather closed technical platforms. Similarly, many large (financial) institutions have built their own cyber defence stack which is essentially a proprietary technical platform. We are starting to see some cooperation on the part of companies (i.e. the UKs cyber defence alliance) around information sharing. A platform could provide a consistent way to apply this knowledge to a broad set of companies.

The state of the cyber security solution market has created a landscape where many of the cyber security vendors I have met tell the same story – it is increasingly difficult to rise above the noise and get customer attention. Many cyber vendors produce technology that only very savvy companies can even understand. That means they are competing for a small number of large companies with a CISO and dedicated security personnel.

Large, cyber savvy companies already have a stack of 20-100 different vendors that they integrate and need to maintain. Adding yet another technology is not something they relish. Just like legacy IT just the cost of maintaining an integrated stack of so many technologies will soon catch up with CISOs and their budgets. Smaller companies are just getting lost in the cost and complexity.

Another issue for companies is IS (information security) vs IT (information technology) because the two are intertwined. From a budgeting perspective IS technology eats at the IT budget, generates additional expense, a need for specialised personnel and is considered by many as a business inhibitor, not enhancer. From a technical perspective, many of the most valuable security capabilities are really IT capabilities (e.g. patch management). To address these issues cyber specific technologies shouldn’t be chasing the “attack du-jour” – but need to take a more holistic defence view of cyber security as part of IT, such as laid out by the NIST cyber security framework.

Creating a $1B Company – Integration Platform, Anchors and Satellites

February 16, 2019

The emergent platform approach dictates some very specific requirements for selecting the components for the first solution and how it is built. The goal of the first solution is to kick start the platform, and create an MAYA (most advanced yet acceptable) offering for the intended market. In other words, the first solution needs to be a combination of an anchor solution familiar to the intended buyer and “bolt-ons” of more advanced satellite capabilities from other startups. The approach is similar to the “strategic acquisition” models of large ISVs, or the bolt-on acquisition models of PE.

Not surprisingly, this approach requires a more seasoned entrepreneurial team that has the experience and knowhow to choose the right anchor solutions, and combine them with appropriate satellite solutions. When done correctly the new startup will have built a basic platform in record time, as well as income and market feedback from the existing solution suite.

Over time the platform the platform expands in three directions –

  • additional equivalent anchors (to capture specific customer preferences)
  • new anchors to address additional market domains
  • additional satellites to address new market niches and innovation

The platform approach empowers customers to tailor their specific solutions by selecting the anchors they need, and the specific satellite enhancements for that anchor.

This is the last post about platforms in general. In upcoming posts I’ll focus on the specific platform we plan to build – a cyber-security platform.

Creating a $1B Company – Emergent Platform Approach is Best

February 16, 2019

The best way to create a platform combines an immediate solution approach with an emergent platform play. It requires a market ripe for a platform (see my earlier post on how to recognize the signs), integrating existing solutions (and yes, even some of the walking dead) using an initial platform built on the fly and then continuing expansion and enhancement of the platform.

In its initial stages a staged platform may not be externally distinguishable from a solution suite. This addresses the platform chicken and egg problem, since from it provides immediate customer value by combining and orchestrating existing solutions into a more complete integrated solution.

In many ways it is similar to what an enterprise IT department does to solve their own real-world end-to-end problems – combine point solutions into an integrated whole. The difference is that by building a platform in parallel the company can provide a coherent, truly integrated solution rather than a patchwork of point solutions. A platform lowers the cost of future integrations and technical debt – making the platform more valuable and faster to respond over the long term. A platform also has access to valuable, aggregated data that can be used to increase its value to customers.

This approach greatly lowers the risk in establishing a platform, by providing much faster revenue generation and market feedback than the “direct to platform” approach. There are more upfront expenses versus the simple solution approach, but nowhere near as much as the pure platform approach. It does make it harder to find investors – since they need to be a savvy mix of PE (private equity) and VC (venture capital) investment.

Creating a $1B Company – The Pure Platform Approach

February 16, 2019

Another option for starting a platform is a pure platform play, in essence “let’s bet the bank that we guessed right approach”. This is an expensive approach since you need to spend to both build the platform and fuel its adoption. There is no initial solution and no foothold to use as a gauge for platform need and adoption, so you spray and pray to create the network effect. That makes it difficult for investors and requires a true visionary entrepreneur “that has seen the future” and can convince investors with deep pockets and patience to buy into their vision of the future.

This approach isn’t for the faint of heart – when it works the results are spectacular – Uber, AirBnB, eBay. On the other hand, when it fails it is a bloodbath, e.g. Betterplace that turned $850M into $450K. These are “big” bet companies – they either create the platform and become enormous, or fail miserably and are never heard from again.

Not surprisingly both entrepreneurs and VCs are wary of starting a company as a pure play platforms, both much prefer a solution company.

But there is another option available that lowers the risk, making a platform startup more palatable. It requires a more seasoned entrepreneurial team and savvy investors. More on that in the next post…

Creating a $1B Company – The Accidental Platform

February 16, 2019

Creating a platform is the embodiment of the chicken and egg problem. If there are no consumers – producers have no one to sell to. If there are no producers, consumers have nothing to buy.

Starting a platform is not always intuitive and always hard, so most (especially technology oriented) entrepreneurs opt for building a point solution – not a platform. They follow common wisdom and focus on building a specific solution to a specific customer problem. If they use the term platform, they mean platform in the technology sense.

The upside of this approach is that it is investor friendly and the path to initial revenue is clear – create a solution people want and will pay for. The underlying hope is that the solution’s market will generate enough revenue to make an “interesting” company. The problem is that in many cases, after initial success in the market, the company needs to expand the scope of its solution to become either a suite of solutions or a platform.

This is the stage when many initially successful startups (wunderkinder) fail. The original solution was not designed as a platform (both from business and technology perspectives) and a lot of painful change and new investment is needed to enable the metamorphosis from solution to platform.

Building a platform also requires a very different mindset from solution marketing and selling – making it feel like starting from scratch. So instead many startups opt for expanding into a solution suite, not a platform. It looks promising but tends to be a dead end. If they are lucky they are acquired by a larger company looking to expand, if not they become walking dead – too much revenue to quit, too little to really expand.

But there is another option…

Creating a $1B Company – 5 Indicators a Market is Ripe for a Platform

February 16, 2019

What is a Platform?

The word “platform” even though it is used quite often, is a chameleon word – meaning different things in different contexts and to different people. A good starting point for a common definition is to understand that all platforms have a common basic structure. Platform owners control access, provide governance and infrastructure, own the IP of the platform. Providers are a platform’s interface with users, sometimes one entity is both the owner and provider. Producers create offerings and adopt the platform to enhance go-to-market, but a platform may not be the only route to market. Consumers adopt a platform because it makes it easy for them to find, gain access and solve problems they have. You can read more about platforms here.

An economic view of platforms is they enable two sided markets of direct interactions between producers and consumers. A successful platform, is a “golden goose” creating self-feeding network effect (e.g. ebay, Facebook, iOS).

Technologists view platforms a bit differently. For them, any technology that provides external programmable access (e.g. APIs) is a platform. Actually, APIs are platform enablers, but do not turn a solution into a platform.

Sometimes technology companies call their technology a “platform” even though they don’t really intend them as two sided markets. They do this because most folks intuitively understand the economic value in owning a platform and the customer value of using APIs to open a solution to tailoring. Everybody wants to be a platform – so every startup worth their salt provides an API and claims to be a platform. What many don’t understand is that creating a platform is not just providing technology enablers to your own solution but actually figuring out how to enable some sort of two sided market of consumers and producers.

What Platform to Build?

Once in a “steady state” platforms are regarded “golden geese”, but the $1,000,000,000 question is how do you find the right market early on – either as an entrepreneur that would like to build a platform or as an early stage investor that would like to fund one?

Here are 5 indicators for a market ready for a platform:

1.  There is a large underserved market of consumers.

2.  There are a multitude of producers that can provide partial solutions to serve those consumers, but have difficulty getting their solution to a broad market.

3.  There is a large number of “local” producers that end up building or integrating the same pieces in order to get to market.

4.  The intended market for the platform is global. i.e. consumers worldwide have the same problems, and solutions don’t need to be tailored per market.

5.  There is a growing number of providers in the market are building their own technical platforms or services, for their own use but not as a two sided market.

Any market with the above dynamics can be fertile ground for the right platform, i.e. the next $1,000,000,000 startup.

Scrum and the Theory of Constraints – Part 2

January 20, 2015

So what if you have user stories that are dependent on external resources? The answer act a little differently during sprint planning by subordinating specific user stories to resource availability:

  1. Check and see if there are user stories that have been marked with constraints. If so they take precedence over regular user stories. For each of them check if their constraints still hold and can be fulfilled – if so choose the story. If the constraints no longer hold, put them into the normal backlog and continue as usual.
  2. For every selected unmarked user story choose and analyse them as usual – if there are no external dependencies, continue. Otherwise mark the user story as one that has constraints. These stories require a bit deeper analysis to see if they can be split into 2 stories – one that requires the dependency, and another that doesn’t. Add the user story without the dependency to the current sprint, and mark the story with constraints to be handled later.
  3. For all the stories that have dependencies, the scrum master must work with management to schedule and assign the story to a specific future sprint (that of course is dependent on the availability of the resource).

Scrum and the Theory of Constraints – part 1

January 13, 2015

One of the tenants of scrum is that the group has all the people and resources they need to complete their stories within the designated timebox. You won’t start a scrum unless you have available all the people and resources needed to complete it. In the Theory of Constraints this is called the “complete kit“.

In the real world (especially in large organizations) many times the resources needed are constrained – people get snatched to other tasks, skills are not always available when needed or planned, machines aren’t available or are broken etc. Which means that the “complete kit”assumption of scrum doesn’t hold.

Standard scrum methodology doesn’t address this issue at all, which is one the reasons it is difficult to apply agile to organisations that have teams that support multiple productsservices with conflicting needs.

The way to handle this at scrum zero (and keep it updated as part of the backlog refinement for every sprint)

1. The team must define the “complete kit” for each user story selected from the backlog (e.g. availability of environments, business experts).

2. It is the responsibility of the scrum master is to subordinate user stories assignment to available resources, and plan ahead to assign user stories to future sprints to account for anticipated resource availability.

This is a critical responsibility since if not handled correctly the project will be “starved“. In part 2 we will describe how the scrum master can do this.

Test Driven Development (TDD) vs. Business Value

December 10, 2014

Test Driven Development (TDD) is broken (or at least is implemented very badly by most organizations) see our previous post for a great explanation about why it doesn’t work. What TDD needs to become is business oriented testing that can be used as the “definition of done” as described in scrum.

Our approach is similar to the approach taken in the Sprint Planning Meeting where the Product Owner and the team negotiate which stories a team will tackle during that sprint. The difference is that we believe that rather than just doing an estimation of effort – the first task is to use business value as the main vector in estimating what should be achieved during a sprint. Together the product owners and developers create a chart for each proposed user story.  In that chart the product owner uses the y-axis to indicate the business value and the developers use the x-axis to indicate the associated effort. Then stories are classified into one of four categories as shown in the figure below – Oyster, Pearl, Quick Win and White Elephant.

ease value matrix

The idea is find the mix of stories that maximize business value subject the timeresource constraints. The methodology is to first focus on Pearls and trash the White Elephants  – don’t do them just because they are there. Oysters are usually too difficult to complete in a single sprint and should be subdivided into user stories that can be implemented in a single sprint – i.e. Pearls, Quick Wins or White Elephants. Finally use whatever timeresources you have left for Quick Wins – do as many as possible.

An example is the failed Apple Navigator project. Apple tried to incorporate a cool new story – navigation enhanced by real-time 3D imagery. This story turned out to be the oyster that ruined the project. What Apple should have done is decompose the oyster into its components: navigation and imagery. From a business perspective navigation is a pearl, while imagery is a white elephant.

Once the stories are selected – developers should work on implementation and testers should start working on the business acceptance tests – the tests that define the required business results from the sprint. These should be generated from the sprint’s user stories.

These business acceptance tests are the ones that matter and should live as long as the user story (as regression tests). They are independent of implementation – and therefor also independent of refactoring or other changes to the system.