Cyber startups: keys to success

Innovation

What makes a cyber startup successful? From my working with a number of companies, there are four key areas cyber entrepreneurs should consider:

Idea

  • Are you passionate about the idea?
  • How unique is it?
  • Can your intellectual properly be protected?

Credibility

  • Do you have genuine expertise in your domain?
  • What do people in your community think of you?
  • Do you have a strong network and business skills?

Client-focus

  • Do you know your client?
  • Do you understand their issues?
  • Do they trust you to solve them?

Learning

  • Are you focusing on the right things?
  • Are you measuring the right things?
  • Are you incorporating client feedback into the development?

The key here, as you can see, is clients. There is really no way around understanding them, pleasing them and focusing on what they want. This feedback will allow you to pivot where required. Above all, stay focused and avoid premature scaling – don’t do too much too soon.

Advertisement

Books and blogs for cyber startup founders

e4c506fe-hutzero-logo_04t01404t014000000

HutZero, an early-stage entrepreneur bootcamp, kindly prepared a list of books and websites recommended for aspiring cyber startup founders.

Books:
The Lean Startup, Eric Reis
Business Model Generation, Alexander Osterwalder, Yves Pigneur
The Mom Test, Rob Fitzpatrick
Lean Analytics, Alistair Croll, Benjamin Yoskovitz
To Sell Is Human, Daniel H. Pink
Start with Why, Simon Sinek
The Purple Cow, Seth Godin
Lean UX, Jeff Gothelf, Josh Seiden
Made to Stick, Chip Heath, Dan Heath
The Four Steps to the Epiphany, Steve Blank
Do More Faster: Lessons from TechStars, Brad Feld, David Cohen
Fundraising Field Guide, Carlos Espinal

Blogs:
Wired Threat Level
Dark Reading
Krebs On Security
TechCrunch Europe
The Next Web
Tech.eu
Tech City News
Buffer Blog (marketing)
Steve Blank
Fred Wilson’s Blog, A VC
Brad Feld’s Blog (Techstars)
KissMetrics Blog (marketing)
Both Sides of the Table

IoT Security Foundation

IoT

It’s the second year I’m attending the IoT Security Foundation conference and it continues to be a great event.

Strategic and technical tracks run in parallel with vendor showcases and means that there’s something interesting for everyone.

It’s great to see industry practitioners and academics coming together to discuss the ethics of IoT, challenges with design and development and the direction of travel of security.

Some of recorded talks are available on the IoTSF website.

Best practice guidance on vulnerability disclosure, connected consumer products and security compliance framework are available to download.

Security in mergers and acquisitions: integration

M&A 2

This blog is the second part of the discussion of security in mergers and acquisitions (M&A). I suggest to read Part 1 first, as I’m going to build on it and talk about what happens after the deal is finally signed.

Ok, it’s time to put that champagne glass down. I have bad news: closing the deal was the easy part. Now the hard work begins.

The purpose of the integration phase is to create value. More bad news: 83% of the M&A deals did not boost the shareholder value (according to KPMG global research report) and total average returns on M&A are negative (A.T. Kearney research).

All too often the root cause of these failures lies in poor integration.

There are ample opportunities to start losing the value right at the start during the handover between the deal and integration teams.

To alleviate this, I suggest identifying key resources and preparing implementation plans early in the process. Just like having an overall acquisition strategy and plan precedes the negotiation and due diligence phases, having an approach to integration is key to success. Deliverables, due dates, milestones, information flows are all need to be defined in advance. And cyber security plays a big role here.

A newly acquired company is a prime target for cyber criminals due to the magnitude of change it’s going through during the M&A process. Lack of governance, employee turnover, security vulnerabilities and many other factors can contribute to embarrassing security breaches that affect the reputation of the combined entity.

Key cyber security risks to consider:

  • Regulatory compliance liabilities and impact (e.g. GDPR fines)
  • Theft of intellectual property (data leaks, key employees leave with all the secrets, etc.)
  • Reputational damage (unwanted media attention due to data leaks)

The focus of cyber security post-deal is on protecting the value from internal and external threats, enabling secure integration, achieving long-term security and minimising cultural impact.

This can be attained in the following ways:

  • Supporting the project team deployment (security education, secured laptops, secure remote connection, encryption, etc.)
  • Identifying and prioritising key assets, systems, people and processes
  • Assessing the security of these assets (a carefully scoped pentest might be a good idea)
  • Ensuring confidentiality, integrity and availability of these assets (backups, antivirus, firewalls, patches, etc.)
  • Establishing and controlling access
  • Supporting the rationalisation of normalisation of processes
  • Developing an approach to cyber risk management (including third-party risk)
  • Rolling out security training
  • Supporting secure migration of applications and data
  • Supporting with incident management
  • Supporting with achieving compliance with relevant laws and regulations
  • Setting up a security monitoring capability of the merged entity
  • Establishing governance
  • Developing integrated security strategy and roadmap

Different cultures, attitudes to security and varying control frameworks are among many challenges to consider. Controls are typically relaxed to allow for the integration to go faster. This is where you need to be on a look out for increased threat levels.

To address these effectively, it’s a good idea to split your efforts in two stages: interim and long-term integration.

From the cyber security perspective, during the interim phase, the aim is to assess cyber maturity across the acquired entity rather than come up with a permanent solution.

High-risk areas should be addressed first by establishing interim controls. Long-term integration efforts should be initiated in parallel, starting with development of a security strategy, governance and roadmap.

Proportionality and risk-based approach is key here when integrating the acquired company into your governance structure and control framework. Focus on what matters most and prioritise security controls to protect the value and avoid backlash.

Don’t forget that people would need to still be able to carry out their duties with minimal disruption, but it’s a good idea to establish who needs access to what and why.

Some things can be outside of your control, like losing key employees after deal completion due to inadequate incentive structure. While it might not be your job to design the right retention mechanisms, it’s your responsibility to protect intellectual property, as mentioned above.

Above all, cyber security efforts during the integration process should be joined up with other functions and stakeholder groups. Work closely with the Legal team to minimise potential impact of compliance-related risks, engage Procurement for third-party risk management and align with the executive team to establish the right security culture.

Security in mergers and acquisitions: conducting due diligence

M&A 1

Recently I’ve had an opportunity to support a number of high-profile mergers and acquisitions (M&A) from the cyber security perspective. Although, due to the confidentiality of these projects I won’t be able to share any details, I would like to talk about some learnings and common approaches that might be useful.

The focus of this blog will be on the due diligence process and the role of security in it. It’s written from the buyer’s perspective, but insight into this thought process can be useful if you’re selling too.

Acquiring firms usually seek to fill the gaps in their capabilities (e.g. new technologies) in line with their strategy or to find overlaps allowing for cost reductions through greater consolidation.

Due diligence during M&A is rarely simple, quick or 100% accurate. It aims to reduce risk for both parties involved in the transaction and identify value creation opportunities. Although it might feel brief due to the business pressures, no amount of time will allow you to detect all the threats and identify every risk facing the business.

The main questions you would like to have clarity on from the security perspective are: “What security measures does the company have in place?” and “Are these the right measures?”

Sometimes, it feels like an art rather than a science.  But there are ways to reduce the uncertainty surrounding this process.

Jason Weinstein, former Deputy Assistant Attorney General, U.S. Department of Justice, once said: “When you buy a company, you’re buying their data, and you could be buying their data-security problems.”

Security teams, however, are not always welcome during M&A activities. Why? For one thing, it takes time and costs money to involve them. They may also scare or annoy employees of the target company and can be perceived as slowing things down or, worse still, hampering the deal.

So even when security gets involved, it’s usually quite late in the process with a few days left before the deal needs to be finalised.

To make matters worse, access to the target company is often restricted and the best you can get is a (partially) filled questionnaire. Your security-related questions form a part a broader pre-deal survey, so it’s a good idea to put some thinking what you should ask and why.

A number of subject matter experts in the deal team are all scrambling for limited available time and priority is sometimes given to understanding financials, legal aspects or broader IT strategy, rather than security specifically. Cyber risks, however, should form a core part of the process.

To alleviate some of the challenges outlined above, it helps if the value of the security involvement is clearly articulated (yes, it’s your job to do that). In short, it brings additional expertise to the table, protects the negotiating position and informs senior executives about potential risks, providing recommendations on mitigating them.

To save time, I’ve developed a high-level assessment template that covers all the possible areas of interest from the cyber security perspective and helps identify key assets, systems, processes and employees, but I would never send it as is. You need to do your homework and learn as much about the company and its culture as you can using the information in the public domain.

There are paid-for services out there but Google often does the job, as many OSINT experts would argue. Assuming, of course, you know how to use it! Open source intelligence and research skills at this stage are more useful than ever. Checking the dark web to see if target’s confidential information is being sold by cybercriminals can be useful too.

After the initial research, you can now tailor the questionnaire to verify your initial thoughts. Don’t be shy to ask for evidence if you want to see their policies or latest pentest reports: there are usually secure data rooms set up to share these kinds of documents.

The aim here is to understand the target company risk profile and make the deal team aware of the potential risks and opportunities. You can go one step further and quantify the risk, as this would help inform the value of the deal, potentially reducing the asking price to account for remediation activities during the post-deal phases. Despite the number of unknowns (believe me, it’s normal) it is also a good practice to provide recommendations.

It’s helpful to group your recommendations into three broad categories:

  1.  Risks that should be addressed before the deal can be signed (red flags)
  2.  Items that should be included in the contract (conditions on signing the deal)
  3. Post-deal activities as part of a 30-60-90 day plan that helps prioritise risks mitigation actions

Ask the target to disclose any known security flaws, issues and incidents. It’s probably also a good idea to reserve some funds for the remediation activities post deal. It shouldn’t be all negative; identify value creating opportunities too, if you can.

If you’re a seller, you can increase your marketability by assessing your own assets, discovering your own vulnerabilities and addressing these. Establishing processes to demonstrate compliance is a bonus. But don’t just focus on the current state, think about how your assets are going to stay so post-deal.

Congratulations! You successfully supported the business in making the right decision about this company. But the role of cyber security doesn’t end here. If the board decides to go ahead and the agreement is reached, we are moving into the post-deal stage.

Now, we need to ensure a smooth and secure integration.

Early Stage Cybersecurity Accelerator Programme

HutZero

A few weeks ago I learnt that my application to attend the HutZero cyber entrepreneur bootcamp had been successful.  I am excited to start the programme next week and will keep you posted!

Whether you are just finishing your studies on cyber security, or have worked in the corporate world for a number of years, HutZero supports individuals at the very start of their entrepreneurial journey.

DevOps and Operational Technology: a security perspective

3391525700_187606bd23_z

I have worked in the Operational Technology (OT) environment for years, predominantly in major Oil and Gas companies. And yes, we all know that this space can move quite slowly! Companies traditionally employ a waterfall model while managing projects with rigid stage gates, extensive planning and design phases followed by lengthy implementation or development.

It’s historically been difficult to adopt more agile approaches in such an environment for various reasons. For example, I’ve developed architecture blueprints with a view to refresh industrial control assets for a gas and electricity distribution network provider in the UK on a timeline of 7 years. It felt very much like a construction project to me.  Which is quite different from the software development culture that typically is all about experimenting and failing fast. I’m not sure about you, but I would not like our power grid to fail fast in the name of agility. The difference in culture is justified: we need to prioritise safety and rigour when it comes to industrial control systems, as the impact of a potential mistake can cost more than a few days’ worth of development effort – it can be human life.

The stakes are not as high when we talk about software development.  I’ve spent the past several months in one of the biggest dot-coms in Europe and it was interesting to compare and contrast their agile approach to the more traditional OT space I’ve spent most of my career in. These two worlds can’t be more different.

I arrived to a surprising conclusion though: they are both slow when it comes to security. But  for different reasons.

Agile, and Scrum in particular, is great on paper but it’s quite challenging when it comes to security.

Agile works well when small teams are focused on developing products but I found it quite hard to introduce security culture in such an environment. Security often is just not a priority for them.

Teams mostly focus on what they perceive as a business priority. It is a standard practice there to define OKRs – Objectives and Key Results. The teams are then measured on how well they achieved those. So say if they’ve met 70% of their OKRs, they had a good quarter. Guess what – security always ends up in the other bottom 30% and security-related backlog items get de-prioritised.

DevOps works well for product improvement, but it can be quite bad for security. For instance, when a new API or a new security process is introduced, it has to touch a lot of teams which can be a stakeholder management nightmare in such an environment. A security product has to be shoe horned across multiple DevOps teams, where every team has its own set of OKRs, resulting in natural resistance to collaborate.

In a way, both OT and DevOps move slowly when it comes to security. But what do you do about it?

The answer might lie in setting the tone from the top and making sure that everyone is responsible for security, which I’ve discussed in a series of articles on security culture on this blog and in my book The Psychology of Information Security.

How about running your security team like a DevOps team? When it comes to Agile, minimising the friction for developers is the name of the game: incorporate your security checks in the deployment process, do some automated vulnerability scans, implement continuous control monitoring, describe your security controls in the way developers understand (e.g. user stories) and so on.

Most importantly, gather and analyse data to improve. Where is security failing? Where is it clashing with the business process? What does the business actually need here? Is security helping or impeding? Answering these questions is the first step to understanding where security can add value to the business regardless of the environment: Agile or OT.

Image by Kurt Kurasaki.

Developing Global Cyber Services

UNADJUSTEDNONRAW_thumb_3078

Over the past year I’ve worked as a core part of the KPMG’s Global Cyber Strategic Growth Initiative as the lead for service development activities, with a focus on working with member firms to deploy capabilities in order to ensure consistent delivery and quality across key growth areas.

I was responsible for the roll-out of cyber security services that included developing sales and delivery accelerators, accreditation requirements, learning pathways, vendor ecosystem and quality and risk management principles across EMEA, APAC and Americas.

To achieve this, I created a service development framework and worked with numerous stakeholders across the firm’s network: global deployment, service development leads, acquisition leads, risk management and key member firm cyber representatives and regional leads.

I also developed a method for the in-country adoption of deployed capabilities and supported both global and in-country risk team members in the evaluation of risk when taking services for client use.

I ensured the sustainability of deployed capabilities through the implementation and use of delivery frameworks and tools, and assigned ownership for the upkeep of deployed capabilities. I worked with member firms to promote the adoption of prioritised services; developed adoption timelines and targets for deployed service.

One of the existing aspects of the role was alliance, acquisition and investment integration support where I collaborated with the relevant stakeholders to deploy and embed offerings obtained through alliances to member firms while monitoring progress against agreed budgets, milestones, deliverables and benefits for capabilities being deployed.

By the end of the programme, I deployed Cyber Maturity Assessment, Identity and Access Management, Industrial Internet of Things Cyber Security, Privacy and Cyber Incident Response services to 19 countries around the world.

This resulted in achieving significant revenue and market share growth for cyber security services of my firm globally. KPMG International was also named a leader in information security consulting services in 2016 and 2017 according to Forrester Research.

cq5dam.web.512.99999

Security function review

When determining the level of maturity of a security function, I focus on the following areas and try to answer these questions:

Business alignment

  • Is security strategy aligned with business strategy (including vision and mission)?
  • Is it documented and communicated?
  • Is it supported by the leadership?
  • Is there a guiding policy in place to achieve set objectives?

Governance

  • Have accountable individuals been identified?
  • Have risk management practices been established?
  • Have audit and assurance practices been established?

Operating model

  • Have performance measurement practices been established (including KPI definition)?
  • Have global and regional interfaces been defined?
  • Has team structure and funding been agreed?