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.

Agile security. Part 2: User stories

Clickup

In the previous blog, I wrote about how you as a security specialist can succeed in the world of agile development, where the requirements are less clear, environment more fluid and change is celebrated not resisted.

Adjusting your mindset and embracing the fact that there will be plenty of unknowns is the first step in adopting agile security practices. You can still influence the direction of the product development to make it more resilient, safe and secure by working with the Product Owner and contributing your requirements to the product backlog.

Simply put, product backlog is a list of desired functionality, bug fixes and other requirements needed to deliver a viable product. There are plethora of tools out there to help manage dependencies and prioritisation to make the product owner’s job easier. The image at the top of this post is an example of one of such tools and you can see some example requirements there.

As a security specialist, you can communicate your needs in a form of user stories or help contribute to existing ones, detailing security considerations. For example, ”Customer personal data should be stored securely” or “Secure communication channels should be used when transmitting sensitive information”. Below are a couple more examples from different categories.

When writing security user stories, you should try and elaborate as much as possible on the problem you are trying to solve, what value it will provide if solved and the acceptance criteria. Each story will then have points assigned which signifies how much effort a particular functionality will require. The process of arriving to the final number is quite democratic and usually involves playing planning (sometimes also called Scrum) poker in which every developer will estimate how long each story is going to take with some discussion and eventual consensus. You can do it with an app as on the image below, or the old school way with a deck of cards. 

You don’t have to use the above number pattern, and opt-in instead for the Fibonacci sequence or T-shirt sizes.

It’s important that the security team is involved in sprint planning to contribute to the estimates and help the product owner with prioritisation. Other Scrum meetings, like backlog refinement and daily stand-ups are also worthwhile to attend to be able clarify your requirements (including value, risk, due dates and dependencies) and help remove security related impediments.

A culture of collaboration between teams is essential for the DevSecOps approach to be effective. Treating security as not something to workaround but as a value adding product feature is the mindset product and engineering teams should adopt. However, it’s up to security specialists to recognise the wider context in which they operate and accept the fact that security is just one of the requirements the team needs to consider. If the business can’t generate revenue because crucial features that customers demand are missing, it’s little consolation that security vulnerabilities have been addressed. After all, it’s great to have a secure product, but less so when nobody uses it.

Agile security. Part 1: Embedding security in your product

Board

Outline security requirements at the beginning of the project, review the design to check if the requirements have been incorporated and perform security testing before go-live. If this sounds familiar, it should. Many companies manage their projects using the waterfall method, where predefined ‘gates’ have to be cleared before the initiative can move forward. The decision can be made at certain checkpoints to not proceed further, accepting the sunk costs if benefits now seem unlikely to be realised.

This approach works really well in structured environments with clear objectives and limited uncertainty and I saw great things being delivered using this method in my career. There are many positives from the security point of view too: the security team gets involved as they would normally have to provide their sign-off at certain stage gates, so it’s in the project manager’s interest to engage them early to avoid delays down the line. Additionally, the security team’s output and methodology are often well defined, so there are no surprises from both sides and it’s easier to scale.

If overall requirements are less clear, however, or you are constantly iterating to learn more about your stakeholder’s needs to progressively elaborate on the requirements, to validate and perhaps even pivot from the initial hypothesis, more agile project management methodologies are more suitable.

Embedding security in the agile development is less established and there is more than one way of doing it. 

When discussing security in startups and other companies adopting agile approaches, I see a lot of focus on automating security tests and educating developers on secure software development. Although these initiatives have their merits, it’s not the whole story.

Security professionals need to have the bigger picture in mind and work with product teams to not only prevent vulnerabilities in code, but influence the overall product strategy, striving towards security and privacy by design. 

Adding security features and reviewing and refining existing requirements to make the product more secure is a step in the right direction. To do this effectively, developing a relationship with the development and product teams is paramount. The product owner especially should be your best friend, as you often have to persuade them to include your security requirements and user stories in sprints. Remember, as a security specialist, you are only one of the stakeholders they have to manage and there might be a lot of competing requirements. Besides, there is a limited amount of functionality the development can deliver each sprint, so articulating the value and importance of your suggestions becomes an essential skill.

Few people notice security until it’s missing, then the only thing you can notice is the absence of it. We see this time and time again when organisations of various sizes are grappling with data breaches and security incidents. It’s your job to articulate the importance of prioritising security requirements early in the project to mitigate the potential rework and negative impact in the future.

One way of doing this is by refining existing user stories by adding security elements to them, creating dedicated security stories, or just adding security requirements to the product backlog. Although the specifics will depend on your organisation’s way of working, I will discuss some examples in my next blog.

How to respond to a security incident

In this blog I would like to outline a process of responding to a security incident, including a breach of personal data. It is intended to be high-level in nature to allow for adaptation to different types of incidents and specific needs of your organisation.

There are many definitions of a security incident out there. I prefer this one: a security incident is an attempted or successful unauthorised access, use, theft, disclosure, modification or destruction of information, or interference with or misuse of information processing infrastructure, applications and data. A personal data breach is one of the types of a security incident which occurs when personal information is subject to loss or unauthorised access, use, disclosure, copying or modification.

More

Time for something new

IMG-6141

After six years with KPMG’s Cyber Security practice I decided it was time to take on a new challenge. It was a great pleasure helping clients from various industry sectors solve their security issues and I certainly learned a lot and met many fantastic people.

A digital venture incubation firm has partnered with a world leader in visas and identity management to found a new London-based venture that is creating a frictionless travel experience. 

I joined this tech startup as the Head of Information Security and couldn’t pass on this opportunity to be one of the early members of the leadership team. 

I’ll be driving the security and compliance agenda, adjusting to the needs of the dynamic and growing business. I can’t wait to put the skills I learned in consulting into practice and contribute to this company.

I’ll have an opportunity to help create a trusted, seamless, user centred visa application process for consumers and businesses alike, through automation and a cutting edge technology. And that’s exciting!

Developing an information security strategy

I wrote previously on how to assess your threat landscape and what your priorities should be when you start developing a security programme in a new company.

In this blog, I would like to dig deeper and talk about how you actually develop a security strategy with some illustrative examples. You can then use these to further refine your security architecture.

As always, we would start with a Why. Why is security important for your business? Well, you will need to help your stakeholders understand that security can help build customer trust and become a brand differentiator.

And how can this be achieved? To keep this simple, let’s zoom in on three priorities:

  • Support the business. Embed security into the business by ensuring alignment to business strategy
  • Risk-based approach. Pragmatic and prioritised security controls, advice, guidance and information security expertise for the business
  • Focus. Centre on protecting the most important assets and understanding the threats

The aim could be to arrive to a state where security underpins all products and services to offer customers a frictionless experience.

Talking to your business stakeholders will help you understand your company’s wider goals and strategy. Let’s imagine for a second that these conversations revealed that your organisation, like many others, ultimately want to grow their revenue. They also identified that the way they are going to grow their revenue is through increasing sales, building customer trust, improving products and services and scaling operations to better meet customers’ needs.

Vulnerable product, misconfigured infrastructure, insecure operations, inadequate compliance regime and inability to withstand incidents all prevent the business from achieving its objectives.

Strategy

You can now prioritise your security activities to align with these objectives, for example by grouping them into product, infrastructure and people security, as well as wider compliance and resilience objectives.

Timeline

Remember, the above is just an indicative timeline. The reality will very much depend on your organisation’s priorities, maturity and resource availability.

The first 100 days as a CISO

Lifecycle

What should you do in your 100 days in a new company? In short, you should find a way to support the business and present it in a way that is understood and accepted. Communicate broadly and often to ensure constant alignment. Measure your progress in a meaningful way to demonstrate the value to the business.

Roadmap

  • Get buy in

Validate top assets, threats and risks. Obtain leadership support on next steps.

  • Baseline where you are

Understand business requirements, technological and regulatory landscape. Perform interviews and review existing product and documentation.

  • Work out what needs to be done

Recommend security improvements to address risks and align with business strategic priorities.

  • Make it happen

Preparing people, establishing good practice and implementing the right technologies and processes.

Timeline.jpeg

Startup security

14188692143_8ed6740a1d_z

In the past year I had a pleasure working with a number of startups on improving their security posture. I would like to share some common pain points here and what to do about them.

Advising startups on security is not easy, as it tends to be a ‘wicked’ problem for a cash-strapped company – we often don’t want to spend money on security but can’t afford not to because of the potential devastating impact of security breaches. Business models of some of them depend on customer trust and the entire value of a company can be wiped out in a single incident.

On a plus side, security can actually increase the value of a startup through elevating trust and amplifying the brand message, which in turn leads to happier customers. It can also increase company valuation through demonstrating a mature attitude towards security and governance, which is especially useful in fundraising and acquisition scenarios.

Security is there to support the business, so start with understanding the product who uses it.  Creating personas is quite a useful tool when trying to understand your customers. The same approach can be applied to security. Think through the threat model – who’s after the company and why? At what stage of a customer journey are we likely to get exposed?

Are we trying to protect our intellectual property from competitors or sensitive customer data from organised crime? Develop a prioritised plan and risk management approach to fit the answers. You can’t secure everything – focus on what’s truly important.

A risk based approach is key. Remember that the company is still relatively small and you need to be realistic what threats we are trying to protect against. Blindly picking your favourite NIST Cybersecurity Framework and applying all the controls might prove counterproductive.

Yes, the challenges are different compared to securing a large enterprise, but there some upsides too. In a startup, more often than not, you’re in a privileged position to build in security and privacy by design and deal with much less technical debt. You can embed yourself in the product development and engineering from day one. This will save time and effort trying to retrofit security later – the unfortunate reality of many large corporations.

Be wary, however, of imposing too much security on the business. At the end of the day, the company is here to innovate, albeit securely. Your aim should be to educate the people in the company about security risks and help them make the right decisions. Communicate often, showing that security is not only important to keep the company afloat but that it can also be an enabler. Changing behaviours around security will create a positive security culture and protect the business value.

How do you apply this in practice? Let’s say we established that we need to guard the company’s reputation, customer data and intellectual property all the while avoiding data breaches and regulatory fines. What should we focus on when it comes to countermeasures?

I recommend an approach that combines process and technology and focuses on three main areas: your product, your people and your platform.

  1. Product

Think of your product and your website as a front of your physical store. Thant’s what customers see and interact with. It generates sales, so protecting it is often your top priority. Make sure your developers are aware of OWASP vulnerabilities and secure coding practices. Do it from the start, hire a DevOps security expert if you must. Pentest your product regularly. Perform code reviews, use automated code analysis tools. Make sure you thought through DDoS attack prevention. Look into Web Application Firewalls and encryption. API security is the name of the game here. Monitor your APIs for abuse and unusual activity. Harden them, think though authentication.

  1. People

I talked about building security culture above, but in a startup you go beyond raising awareness of security risks. You develop processes around reporting incidents, documenting your assets, defining standard builds and encryption mechanisms for endpoints, thinking through 2FA and password managers, locking down admin accounts, securing colleagues’ laptops and phones through mobile device management solutions and generally do anything else that will help people do their job better and more securely.

  1. Platform

Some years ago I would’ve talked about network perimeter, firewalls and DMZs here. Today it’s all about the cloud. Know your shared responsibility model. Check out good practices of your cloud service provider. Main areas to consider here are: data governance, logging and monitoring, identity and access management, disaster recovery and business continuity. Separate your development and production environments. Resist the temptation to use sensitive (including customer) data in your test systems, minimise it as much as possible. Architect it well from the beginning and it will save you precious time and money down the road.

Every section above deserves its own blog and I have deliberately kept it high-level. The intention here is to provide a framework for you to think through the challenges most startups I encountered face today.

If the majority of your experience comes from the corporate environment, there are certainly skills you can leverage in the startup world too but be mindful of variances. The risks these companies face are different which leads to the need for a different response. Startups are known to be flexible, nimble and agile, so you should be too.

Image by Ryan Brooks.