How to secure a tech startup

scrum_boardIf you work for or (even better) co-founded a tech startup, you are already busy. Hopefully not too busy to completely ignore security, but definitely busy enough to implement one of the industrial security frameworks, like the NIST Cybersecurity Framework (CSF). Although the CSF and other standards are useful, implementing them in a small company might be resource intensive.

I previously wrote about security for startups. In this blog, I would like to share some ideas for activities you might consider (in no particular order) instead of implementing a security standard straight away. The individual elements and priorities will, of course, vary depending on your business type and needs and this list is not exhaustive.

Product security

Information security underpins all products and services to offer customers an innovative and frictionless experience.

  • Improve product security, robustness and stability through secure software development process
  • Automate security tests and prevent secrets in code
  • Upgrade vulnerable dependencies
  • Secure the delivery pipeline

Cloud infrastructure security

To deliver resilient and secure service to build customer trust.

  • Harden cloud infrastructure configuration
  • Improve identity and access management practices
  • Develop logging and monitoring capability
  • Reduce attack surface and costs by decommissioning unused resources in the cloud
  • Secure communications and encrypt sensitive data at rest and in transit

Operations security

To prevent regulatory fines, potential litigation and loss of customer trust due to accidental mishandling, external system compromise or insider threat leading to exposure of customer personal data.

  • Enable device (phone and laptop) encryption and automatic software updates
  • Make a password manager available to your staff (and enforce a password policy)
  • Improve email security (including anti-phishing protections)
  • Implement mobile device management to enforce security policies
  • Invest in malware prevention capability
  • Segregate access and restrict permissions to critical assets
  • Conduct security awareness and training

Cyber resilience

To prepare for, respond to and recover from cyber attacks while delivering a consistent level of service to customers.

  • Identify and focus on protecting most important assets
  • Develop (and test) an incident response plan
  • Collect and analyse logs for fraud and attacks
  • Develop anomaly detection capability
  • Regular backups of critical data
  • Disaster recovery and business continuity planning

Compliance and data protection

To demonstrate to business partners, regulators, suppliers and customers the commitment to security and privacy and act as a brand differentiator. To prevent revenue loss and reputational damage due to fines and unwanted media attention as a result of GDPR non compliance.

  • Ensure lawfulness, fairness, transparency, data minimisation, security, accountability, purpose and storage limitation when processing personal data
  • Optimise subject access request process
  • Maintain data inventory and mapping
  • Conduct privacy impact assessments on new projects
  • Data classification and retention
  • Vendor risk management
  • Improve governance and risk management practices

Image by Lennon Shimokawa.


Privacy and data protection considerations

If people entrust your company with their personal data, it is your responsibility to protect it. GDPR provides a good framework even if it doesn’t apply in your geography.

Below is a list of things you can do in no particular order which I use as a cheat sheet when I start up a data protection programme in a company.

Inventory

Make an inventory of all personal data you hold. Know (and document) what and how you collect, why you collect it, who you share it with and where and how long it is being stored.

Honour the rights of individuals

Develop comprehensive processes to support data subject access requests (right to be informed through consent and notice, right to access and data portability, right to erasure, etc.).

Privacy and security by design

Make privacy, compliance and data protection considerations during product development with regular review and testing. Minimise and don’t store beyond necessary.

Technical security measures

Implement technical controls to protect customer data, for example access control, encryption, logging and monitoring.

Processes for breach response

Establish an end-to-end incident identification and response process to handle security and privacy incidents as part of the broader security strategy.

Awareness and training

Provide data protection and privacy training for staff. Extra points for regular bespoke education and awareness sessions addressing topical issues.

Data Protection Officer

Appoint a data protection officer and get legal support. Perform data identification and classification. Make conducting privacy impact assessments on new projects a habit. Involve relevant stakeholders.

Legal framework

Get on top of data protection addendums to agreements, vendor management, client consent management and cross-border transfer agreements.


Vulnerability scanning gone bad

4197732260_60306abecf_z

Security teams often have good intentions when they want to improve the security posture of a company by introducing new tools.

In one organisation, for example, they might want to mitigate the risk of exploiting application vulnerabilities and decide to deploy a code-scanning tool. This would make sure that applications are tested for exploits before they are released. Great idea but the uptake on the use of this tool was surprisingly low and created a lot of friction.

After closer examination, it turns out that this was primarily due to challenges with communication with the development teams that would need to use the tool. The impacted teams weren’t sufficiently trained on the use of it and there wasn’t enough support from the management to adopt it.

Development teams have tight timelines and budgets to work to in order to meet the business objectives. Anything that could disrupt these aspects is viewed with caution.

As a result, applications that should have had their code scanned either hadn’t, or had to be scanned at a much later stage of the development cycle. It was not incorporated in the DevOps pipeline– the scans were run as part of a manual check before release in production. Not only the risk of having applications with flaws in them remain largely unchanged, the whole process of delivering working software was prolonged.

These new applications were being delivered to facilitate revenue growth or streamline exiting processes to reduce cost and complexity. The impact on the business was that the new functionality they were expecting took longer to materialise, resulting in users’ frustration.

What can you do to prevent such situations from happening? Here are a few recommendations:

  1. Communicate frequently and at the right level. Communication must start at the top of an organisation and work its way down, so that priorities and expectations can be aligned. A person may need to hear the same message multiple times before they take action.
  2. Articulate the benefits. Security and risk teams need to ensure they position any new processes or tools in a way that highlights the benefits to each stakeholder group.
  3. Provide clear steps. In order to ensure the change is successful, security professionals should clearly outline the steps for how to start realising these benefits.

Communicating and providing support on new security policies, tools and practices to impacted teams is absolutely critical. This is especially important in large organisations with many stakeholder groups spread across multiple geographies. Always keep the people in mind when introducing a change, even if it’s the one for the better.

Image by Hugo Chinaglia


Innovating in the age of GDPR

Expo

Customers are becoming increasingly aware of their rights when it comes to data privacy and they expect companies to safeguard the data they entrust to them. With the introduction of GDPR, a lot of companies had to think about privacy for the first time.

I’ve been invited to share my views on innovating in the age of GDPR as part of the Cloud and Cyber Security Expo in London.

When I was preparing for this panel I was trying to understand why this was even a topic to begin with. Why should innovation stop? If your business model is threatened by the GDPR then you are clearly doing something wrong. This means that your business model was relying on exploitation of consumers which is not good.

But when I thought about it a bit more, I realised that there are costs to demonstrating compliance to the regulator that a company would also have to account for. It’s arguably easier achieved by bigger companies with established compliance teams rather than smaller upstarts, serving as a barrier to entry. Geography also plays a role here. What if a tech firm starts in the US or India, for example, where the regulatory regime is more relaxed when it comes to protecting customer data and then expands to Europe when it can afford it? At least at a first glance, companies starting up in Europe are at a disadvantage as they face potential regulatory scrutiny from day one.

How big of a problem is this? I’ve been reading about people complaining that you need fancy lawyers who understand technology to address this challenge. I would argue, however, that fancy lawyers are only required when you are doing shady stuff with customer data. Smaller companies that are just starting up have another advantage on their side: they are new. This means they don’t have go and retrospectively purge legacy systems of data they have been collecting over the years potentially breaking the business logic in the interdependent systems. Instead, they start with a clean slate and have an opportunity to build privacy in their product and core business processes (privacy by design).

Risk may increase while the company grows and collects more data, but I find that this risk-based approach is often missing. Implementation of your privacy programme will depend on your risk profile and appetite. Level of risk will vary depending on type and amount of data you collect. For example, a bank can receive thousands of subject access requests per month, while a small B2B company can receive one a year. Implementation of privacy programmes will therefore be vastly different. The bank might look into technology-enabled automation, while a small company might look into outsourcing subject request processes. It is important to note, however, that risk can’t be fully outsourced as the company still ultimately owns it at the end of the day

The market is moving towards technology-enabled privacy processes: automating privacy impact assessments, responding to customer requests, managing and responding to incidents, etc.

I also see the focus shifting from regulatory-driven privacy compliance to a broader data strategy. Companies are increasingly interested in understanding how they can use data as an asset rather than a liability. They are looking for ways to effectively manage marketing consents and opt out and giving power and control back to the customer, for example by creating preference centres.

Privacy is more about the philosophy of handling personal data rather than specific technology tricks. This mindset in itself can lead to innovation rather than stifling it. How can you solve a customers’ problem by collecting the minimum amount of personal data? Can it be anonymised? Think of personal data like toxic waste – sure it can be handled, but with extreme care.


Cyber Security: Law and Guidance

IMG-2260

I’m proud to be one of the contributors to the newly published  Cyber Security: Law and Guidance book.

Although the primary focus of this book is on the cyber security laws and data protection, no discussion is complete without mentioning who all these measures aim to protect: the people.

I draw on my research and practical experience to present a case for the new approach to cyber security and data protection placing people in its core.

Check it out!


NIS Directive: are you ready?

UNADJUSTEDNONRAW_thumb_3de4

Governments across Europe recognised that with increased interconnectiveness a cyber incident can affect multiple entities spanning across a number of countries. Moreover, impact and frequency of cyber attacks is at all-time high with recent examples including:

  • 2017 WannaCry ransomware attack
  • 2016 attacks on US water utilities
  • 2015 attack on Ukraine’s electricity network

In order to manage cyber risk, the European Union introduced the Network and Information Systems (NIS) Directive which requires all Member States to protect their critical national infrastructure by implementing cyber security legislation.

Each Member State is required to set their own rules on financial penalties and must take the necessary measures to ensure that they are implemented. For example, in the UK fines, can be up to £17 million.

And yes, in case you are wondering, the UK government has confirmed that the Directive will apply irrespective of Brexit (the NIS Regulations come into effect before the UK leaves the EU).

Who does the NIS Directive apply to?

The law applies to:

  • Operators of Essential Services that are established in the EU
  • Digital Service Providers that offer services to persons within the EU

The sectors affected by the NIS Directive are:

  • Water
  • Health (hospitals, private clinics)
  • Energy (gas, oil, electricity)
  • Transport (rail, road, maritime, air)
  • Digital infrastructure and service providers (e.g. DNS service providers)
  • Financial Services (only in certain Member States e.g. Germany)

NIS Directive objectives

In the UK the NIS Regulations will be implemented in the form of outcome-focused principles rather than prescriptive rules.

National Cyber Security Centre (NCSC) is the UK single point of contact for the legislation. They published top level objectives with underlying security principles.

Objective A – Managing security risk

  • A1. Governance
  • A2. Risk management
  • A3. Asset management
  • A4. Supply chain

Objective B – Protecting against cyber attack

  • B1. Service protection policies and processes
  • B2. Identity and access control
  • B3. Data security
  • B4. System security
  • B5. Resilient networks and systems
  • B6. Staff awareness

Objective C – Detecting cyber security events

  • C1. Security monitoring
  • C2. Proactive security event discovery

Objective D – Minimising the impact of cyber security incidents

  • D1. Response and recovery planning
  • D2. Lessons learned

Table view of principles and related guidance is also available on the NCSC website.

Cyber Assessment Framework

The implementation of the NIS Directive can only be successful if Competent Authorities  can adequately assess the cyber security of organisations is scope. To assist with this, NCSC developed the Cyber Assessment Framework (CAF).

The Framework is based on the 14 outcomes-based principles of the NIS Regulations outlined above. Adherence to each principle is determined based on how well associated outcomes are met. See below for an example:

NIS

Each outcome is assessed based upon Indicators of Good Practice (IGPs), which are statements that can either be true or false for a particular organisation.

Whats’s next?

If your organisation is in the scope of the NIS Directive, it is useful to conduct an initial self-assessment using the CAF described above as an starting point of reference. Remember, formal self-assessment will be required by your Competent Authority, so it is better not to delay this crucial step.

Establishing an early dialogue with the Competent Authority is essential as this will not only help you establish the scope of the assessment (critical assets), but also allow you to receive additional guidance from them.

Initial self-assessment will most probably highlight some gaps. It is important to outline a plan to address these gaps and share it with your Competent Authority. Make sure you keep incident response in mind at all times. The process has to be well-defined to allow you report NIS-specific incidents to your Competent Authority within 72 hours.

Remediate the findings in the agreed time frames and monitor on-going compliance and potential changes in requirements, maintaining the dialogue with the Competent Authority.


Using SABSA for application security

Aligning OWASP Application Security Verification Standard and SABSA Architecture framework.

OWASP Application Security Verification Standard (Standard) is used at one of my clients to help develop and maintain secure applications. It has been used it as blueprint create a secure coding checklist specific to the organisation and applications used.

Below is an excerpt from the Standard related to the authentication verification requirements:

OWASP

The Standard provides guidance on specific security requirements corresponding to the Physical layer of the SABSA architecture.

SABSA views

Read the rest of this entry »