Securing GSuite: a guide for startups

GSuite

GSuite is an excellent choice for any startup, especially early in the process of establishing your business. Its flexible cost structure allows you to pay per user while benefiting from range of services, including email (with a custom domain name), calendar, document collaboration and storage, videoconferencing and much more.

GSuite, being a Software-as-a-Service (SaaS), relieves you from the underlying infrastructure management in line with the shared responsibility model. This can be especially powerful for smaller companies trying out an idea, as it doesn’t require intensive capital expenditure to set up a datacentre or staff to maintain it. Startups, however, are still responsible for the data, permissions and overall configuration of GSuite if they want to keep their information secure.

Thankfully, Google made available a short checklist for small businesses, describing the necessary steps to safeguard company data. Similar guidance is available for larger (100+ users) organisations.

Settings 2

The plan you select will determine how many security features are available to you. Depending on the criticality of your data and the amount of control you require, it can be a good idea to upgrade to the Enterprise plan.

Hint: if you ask customer support to put you in touch with a sales representative and request a discount, it might just be given to you. Provided you are willing to commit to the subscription for a couple of years.

DashboardSecurity professionals will feel at home with the advanced features available after the upgrade. It includes encryption, data leakage prevention (DLP), granular access control and much more. Managing it is also going to become easier, as various reports and healthcheck dashboards are now at your fingertips.

Settings

Regardless of the plan you use, it won’t hurt to enable multi-factor authentication on all accounts, as it dramatically reduces the risk of account takeover. It might also be a good idea to backup your critical business data somewhere off GSuite for extra resiliency.


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.


The Complexity of Risk Management – free audiobook chapter

My publisher kindly made one of the chapters of my audiobook available for free. In it, I discuss the role of uncertainty in making decisions and managing risk.


How to inventory your AWS assets

Resource

Securing your cloud infrastructure starts with establishing visibility of your assets. I’ll be using Amazon Web Services (AWS) as an example here but principles discussed in this blog can be applied to any IaaS provider.

Speaking about securing your AWS environment specifically, a good place to start is the AWS Security Maturity Roadmap by Scott Piper. He suggests identifying all AWS accounts in your organisation as a first step in your cloud security programme. 

Following Scott’s guidance, it’s a good idea to check in with your DevOps team and/or Finance to establish what accounts are being used in your company. Capture this information in a spreadsheet, documenting account name, ID, description and an owner at a minimum. You can expand on this in the future to track compliance with baseline requirements (e.g. enabling CloudTrail logs).

Once we have a comprehensive view of the accounts used in the organisation, we need to find out what resources these accounts use and how they are configured. We can get metadata about the accounts using CloudMapper’s collect command. CloudMapper is a great open source tool and can do much more than that. It deserves a separate blog, but for now just check out setup instructions on its GitHub page and Scott’s detailed instructions on using the collect command.

The CloudMapper report will reveal the resources you use in all the regions (the image at the top of this blog is from the demo data). This can be useful in scenarios where employees in your company might test out new services and forget to switch them off or nobody knows what these services are used for to begin with. In either case, the company ends up paying for these, so it makes economic sense to investigate, and disabling them will also reduce the attack surface.

In addition to that, the report includes a section on security findings and will alert of potential misconfigurations on the account. It also provides recommendations on how to address them. Below is an example report based on the demo data. 

Findings

As we are just establishing the view of our assets in AWS at this stage, we are not going to discuss remediation activities in this blog. We will, however, use this report to understand how much work is ahead of us and prioritise accordingly.

Of course, it is always a good idea to tackle high criticality issues like publicly exposed S3 buckets with sensitive information but don’t get discouraged by a potentially large number of security findings. Instead, focus on strategic improvements that will prevent these issues from happening in the future.

To lay the foundation for a security improvements programme at this point, I suggest adding all the identified accounts to an AWS Organisation if you haven’t already. This will simplify account management and billing and allow you to apply organisation-wide service control policies.


Cyber security in divestments

3197813348_6786c9aae5_z

A company may divest its assets for a number of reasons: political, social or purely financial in order to free up resources to focus on core business. Regulators may also demand a divestment to prevent one company holding a monopoly. When such a decision is made, the security function can support the business by managing risks during this process. These risks not only include the obvious legal and regulatory compliance ones, but also risks related to business disruption and leaks of intellectual property or other sensitive information. Security teams can also help the business identify value adding opportunities through, for instance, saving costs on software licenses.

The scale of divestments vary and depend on the nature of the organisation: they can range from a single subsidiary to a whole division. Information usually accompanies physical assets, which opens up potential challenges with data governance when these assets change hands. The magnitude of such risks differ depending on specific conditions of the deal, for example:

  • Number of assets is scope
  • Criticality of assets
  • Location of assets and applicable jurisdictions

In my experience, divestments are almost always associated with aggressive timelines for completion usually in the form of legally binding agreements. Therefore, as a security professional, the last thing you want to do is to slow down the process and prevent the business from meeting these timelines.

You need to balance this, however, with the risk exposure. It helps when the security team gets involved early to support the process from the start. All too often, however, the business can be asking for security sign-off after the finalisation of the deal. This can be disappointing, particularly when a number of data transfer requirements have already been violated.

So if you’re one of the lucky ones, and the business is asking for your advice on divesting securely, what should you tell them? What areas do you consider? Here are some examples to get you started:

  • Information asset inventories and data maps. These might include data, software and infrastructure assets. You can’t help securely transfer something you don’t know exists. Start with establishing visibility and interdependencies.
  • Access control. Who has access to what? Do they need that access? Will they need that access in the future? Segregation of duties and least privilege principles are not just abstract philosophical concepts – they have real applications when it comes to divestments.
  • Consider legal and regulatory requirements when it comes to data asset transfer, retention and disposal. Involve your legal team, but don’t forget about technical controls, like encryption and secure data wipes.
  • Availability of skilled resource and mature IT function on the ‘buy’ side. Remember, whoever is buying the assets must have their infrastructure ready to support the acquisition and integration of new assets. Despite being perceived as a ‘buyer’s problem’, risks like that can negatively impact the overall project and should be considered.

All in all, the divestment process can be challenging but the early integration of security professionals ensures the appropriate oversight is given to all relevant areas for a smooth transfer to the buyer.

Image by Jason Kuffer.


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