Startup Security Essentials: Protect, Compete, and Thrive

Thanks for having me today, Paul. Really excited to be here.

I think the largest difference, Paul, is the pace of innovation. When it comes to startups, I can only think about three words: shipping, shipping, shipping. Ultimately, their objective is to make products that people love to use, and they don't really have much time or bandwidth to do it. We are living in an AI era; it's hyper-competitive now. Customers don't really have much time to look at so many different products in the market, so the attention span is very low. That is really pushing startups to not just build amazing products but also get them out as quickly as possible. Compared to larger enterprises—and I've been fortunate enough to work with some of the largest companies in the world—the focus is not just about innovation; it's also about making the business sustainable. There are many factors that come into play, like if you ship a product that is buggy, it impacts reputation, legal implications, compliance, and so forth. Those important needs often slow down the pace of their innovation cycles. They take a more risk-averse approach, which is right given the scale of the company and the shareholders looking up to them. Those are some of the fundamental differences in how people operate in these two environments. The world is still rapidly changing; I see larger companies also becoming a lot more agile since startups are giving them a challenge in many of these markets, especially in the high-tech space.

I'll cover a topic relevant for this webinar. Cybersecurity is definitely one of the biggest risks to any growing startup. Let me put some color on it. In the last 7 to 10 years, we've seen amazing startups come out of the market, many of which have also IPO'd. But while there are amazing success stories, many companies had massive setbacks because they were not thinking about cybersecurity when building their infrastructure, products, or teams. There were so many lapses in how these products were put out to customers or the world. Those insecure environments allowed hackers to go in and do whatever they want. Based on information on the internet, hundreds of millions of people's personal information got exposed across all jurisdictions, from the US to Asia to Europe. I don't think anybody on this planet who is on the internet has not been impacted by a cyber attack yet. Most people have, myself included. While there are many threats to startups—from staying ahead of the innovation cycle to ensuring they don't run out of money—cybersecurity is definitely becoming one of the top three challenges for any early or growth-stage startup. It's crucial to ensure customer trust doesn't get eroded. When you are a younger company, customers ask, 'Are you going to be around in the next couple of years?' It's all about trust and credibility. If you get breached and customer information gets exposed, that trust erodes very quickly, customer acquisition becomes more expensive, and that has a significant impact on the growth curve. Breaches or lapses in cybersecurity have the potential to invert the growth curve itself. That's my two cents on that topic.

If you look back at the last 48 hours, we are seeing tons of breaches already, especially for younger startups getting compromised or their data inadvertently exposed on the internet, leading to customer information or data loss. That's just 48 hours. Going back, a good population of startups have been breached. One interesting example is a DNA testing technology company with an exciting concept—connecting your ancestors and everything. But we saw that company got breached, leaking the DNA information of all their customers. You might think, 'What can somebody do with that?' With the right information in the right hands, you can learn a lot more about individuals, including health conditions. We see healthcare companies getting breached and health records compromised. Financial information from people transacting through fintech companies can breach and disclose account information. Without going into specifics, there are tens of thousands of examples over the last 10 to 15 years. I don't think it was the fault of any founders or management; when you accelerate the pace of innovation, people overlook aspects of their security controls, and those lapses give opportunity to bad guys to get into networks and take data away. We've seen many examples where a cybersecurity breach actually tripped up the startup—they were not able to raise further money because of the reputation damage. There is a pretty big graveyard of startups that couldn't survive because of a high-profile cyber or data breach.

It all starts with what kind of data startups are producing or consuming. A lot of VCs are concerned about regulatory or compliance-related risks, especially when handling personal data, payment data, or health data. They always ask—and this happened to Cyble when we were raising capital—about how our security controls are designed, how we manage them, how we report on them, and more importantly, who is certifying that those controls are operating effectively. Most mature venture capitalists are aware of the risks of mishandling sensitive customer data, and this becomes one of the points in their checklist when looking at any company from a capital deployment perspective. They want to know not just how the company will scale and get more customers, but how they will secure that customer data effectively. VCs are looking into it closely, and there are compliance requirements enforced not just by the VC but also by customers. Many customers ask, 'Are you ISO 27001 certified or SOC 2 Type II certified?' There are very specific asks. In many cases now, startups are actively going for those compliance requirements and investing in those resources. Ultimately, it benefits the end customer whose data is being handled.

I don't think it's becoming a competitive advantage; it's becoming an essential part of it. When you are dealing with large enterprises or a larger customer base, it is becoming a must-have rather than a nice-to-have. Saying 'I have better security than somebody else' is not really a competitive advantage; it's becoming a hygiene factor, like showering every day. It is an imperative for any company to win trust and acquire customers. You would hardly see any startup these days saying, 'I'm better because I have more security.' Customers say, 'I don't care if you're better; you should have it no matter what. Everybody should have it.' Just like people expect an amazing customer experience, they expect that the entities handling their personal or sensitive information are taking care of it. It's a matter of due care, not a nice-to-have. It's a fundamental expectation from consumers or large enterprises that their data is in safe hands. If startups can't meet those requirements, there is no trust, and customer acquisition costs skyrocket. It becomes a deal breaker.

That's a great question. For any startup, I look at three things on how they put up the right security measures and controls. There are tons of standards—NIST, ISO, SOC 2—but I'm not going to touch on that; that information is already available. I look at the fundamentals: people, process, technology. On the people part: do you have anybody taking responsibility to track or govern the security controls and measures of the organization? It's a straight yes or no. Generally, younger startups don't have a CISO; many don't even have a security manager or analyst. It's mostly the CTO doing security tasks along with their other activities. As you start maturing, one thing I always look for is whether they are investing in the right skill set or people to protect customer or enterprise data. There's no choice there, especially when dealing with sensitive data. The second body is on processes. I'm not talking about typical change management or release cycles; I'm talking about how they monitor security controls and, if things go wrong, what they will do about it. Do they have defined incident response plans? If they see malicious activity or anomalous behavior in a database, do they have a plan? More importantly, if systems do get breached, do they have a plan for communicating with customers and providing full transparency and disclosure? Processes are very important. When things are working fine, nobody cares, but when something happens, all eyes are on you. At Cyble, we were less than 20 people when we brought in our first CISO because we were processing tons of data that could be categorized as sensitive. We were cognizant that we needed to put enough attention on technical controls like SIEM, but also a lot more dedicated focus on creating processes. That starts at the design stage. When your design team is building a new feature, are they considering how to improve security controls? How do you enforce those processes when building the product? Many developers use open-source libraries, and history has taught us that many open-source libraries get rigged or infected with malware. You do a pip install, and months later you realize the package was infected and leaking your AWS secret keys. This has happened to many companies. Processes on how you use third-party libraries—which to trust, which not to—are part of supply chain risk, which is becoming more prominent as hackers try to scale operations by infecting fundamental libraries. The third part is technology. Many early-stage companies can't buy expensive tools themselves, but cloud service providers like AWS, GCP, and Azure offer a suite of security controls that are not very expensive given the cost implication if something goes wrong. Those controls can be bolted into products and infrastructure, giving you more visibility on what's happening in your environment. It's a continuous iteration; as you build security control layers, you have to keep investing. But be careful not to overdo it. Always take a risk-based approach to ensure your control layers are proportionate to the risks coming towards your organization. It shouldn't be an afterthought; it should be one of the most fundamental things you think about when building or converting an idea into implementation.

The open-source community is full of projects, but there are risks involved because they also use many open-source libraries, and we already talked about that risk. In my opinion, there are several tools offered by the cloud platforms themselves, mostly click-and-deploy models for log creation, log analytics, alerting, and notification. The cloud infrastructure has become a lot smarter in the last 15 years. You don't necessarily have to have a list of hundreds or thousands of security tools. There are certain activities important for testing control design effectiveness, but when it comes to deploying tooling, especially for startups, I'd be very careful about going out and buying big expensive tools. There are definitely SMB-focused cybersecurity companies, including Cyble, where we continuously help startups scan the internet for misconfigurations and leaks, and monitor their cloud environment for misconfigurations. There are options to work with SMB-focused companies or utilize security tooling offered straight from the cloud platform. It's not highly mature yet—it's a continuous journey—but it's still better than having nothing. When I look at any potential cyber threat, I look at the cyber kill chain. There are many steps that have to go right for a threat actor to successfully exfiltrate your data or jeopardize your operation. As defenders, we have to be right at only one part of the kill chain to kill the chain. It's an interesting concept followed by the military for a long time, and the cybersecurity industry has adopted it. It's not about putting too many controls in the whole chain; it's about building the right controls that can stop a successful attack. That requires deeper thinking than just putting a tool in the environment.

Absolutely. Tons of security companies and startups are moving in the same direction. For example, with Cyble, many companies try to do penetration testing and vulnerability assessments to test their applications for weaknesses or configuration issues. In the old world, a big team of people would do that. There's a big industry just doing security testing. We've learned that many of these—and penetration testing is still an art, so I don't want to discount that you can fully automate everything; there's a difference between a machine-generated picture and a human-generated one, though in the age of AI we may get closer—but when it comes to foundational security control testing like vulnerability assessments or level one penetration testing, those areas can be fully automated. Cyble offers that capability to our customers. We serve more than 500 large enterprises today, and we offer them the ability to not even schedule a scan. They let us know what the applications are, or we figure it out as part of ASM or attack surface management, and we go and figure it out ourselves without their intervention, doing scans and telling them where to fix, what to fix, and how to fix. Technology has already reached that level. There are certain elements of protection that may require human intelligence, but that gap is closing as AI gets better every day. In the next 3 to 4 years, we'll be in a very different age altogether.

Most startups are going in one direction to get a SOC 2 certification because many large enterprises ask, 'How are you securing my data or platform?' There are Type I and Type II nuances. I had a conversation three days ago with a young startup. They said, 'We're about to land this large enterprise customer.' I congratulated them, and they said the customer wants to know how they are securing data. I said that's a logical question. They asked what to do about it. I said, 'Let's agree on what standard you want to implement across your organization. You can pick ISO 27001 or SOC 2; it's your choice.' They decided to go with SOC 2 control design and are planning towards testing those controls. They also wanted to do a penetration test on their website. Many startups think penetration testing is a job you can do in two hours; that's not the case. Security is not a checklist. I always educate them that we need to spend adequate time testing security design within products or infrastructure. It can take a couple of weeks, depending on the complexity of the application. They get questions like: How often do you get penetration tests? Are you compliant with industry regulations? How are you managing backups? If you get a ransomware attack, can you get your systems online? Do you have a change management process that accounts for security? What is your secure software development lifecycle process? There are tons of questions. I remember about four years ago, one of our large customers in the US gave us a technical sign-off, but then forwarded our onboarding to their third-party risk management team. Many large enterprises have a dedicated function whose job is to look at the startup and understand if they are good to work with or too risky. They have a long list of questionnaires—40 to 50 questions—covering everything from how often you do vulnerability assessments to how you ensure your AI models are not diverging sensitive or private data. The list is long. I tell every startup: if you really want to work with a large enterprise, you have to start very early in building up your cybersecurity program. Large enterprises understand you don't have sufficient capital to do everything they'd like to see. It's about making investments based on risks, being transparent about what you have in place, and sharing what you'll be doing over the next 6 to 12 months to improve your security layers. Large enterprises like to see that startups are thinking of security as a foundational part of building the company or product, not as an extra add-on to win contracts. That approach won't take you far; you'll eventually get breached and those customers will churn out.

Full disclaimer: I'm not a lawyer or a privacy guru, but based on my professional experience, whenever you are working with any enterprise or consumer data—PHI, PII, financial information, or any sensitive data that may have a linkage to national security—there are tons of obligations. If you look at the contracts large enterprises make you sign, there are obligations, liabilities, and indemnities. Founders generally say, 'Yeah, whatever, I'll sign everything and put my life at stake,' but trust me, when shit hits the fan, it becomes a nightmare. What does that nightmare look like? For example, when you collect and store personally identifiable information of your customers, many states in the US, including California, have strict regulations or penalties if you can't protect that PII. Those penalties can be very expensive and can break down the entire company. It has in many cases. Look at GDPR; it goes a whole level deeper. The classification of PII itself is interesting. For larger breaches, they can take up to a certain percentage of your revenue. Coming back to the question: when building your products, be truthful about what information you're collecting, processing, and storing. Data governance is a very important piece that many people think is boring, but it's the most sensitive part—it's all about the data. There are different regulations and requirements depending on what layer you are on. Even if you process data but don't store it, that still has obligations. I'm not saying go hire an expensive lawyer; you can consult with a privacy consultant. There are good consultants out there who are not super expensive. They can look at the entire data lifecycle and give you the right level of advice on what regulations you fall into or what security requirements you have to fulfill. If you're a healthcare startup dealing with health information, there's HIPAA compliance. You should consult with an expert, maybe a lawyer if required, to understand the undertaking you have with that collection, access, or storage of data. More importantly, there's the thing about disclosure to customers: they have the right to know what information of theirs you are storing or processing. It's a long list when it comes to the entire data governance piece. We could do a separate webinar for that, Paul, but there's a lot of undertaking, especially when collecting, processing, or storing data of customers, enterprises, or consumers.

It's already the case. If you look at many startups today, when they go to pitch their solution to large enterprises, cybersecurity is a requirement, an imperative. If you're not doing it, the likelihood of landing large enterprise customers is very low. Period. If you want to have those amazing logos and nice, cool-looking contracts, security is a requirement. If you don't do it, it's not going to happen. And if you're not closing big deals, what's the likelihood you'll take your company to the next level? Maybe SMBs would be interested, and there's a big market, but even SMBs are becoming more sensitive to cybersecurity because of legal regulations and requirements. If you want to win customers, cybersecurity is becoming one of the requirements to work with them and grow.

Cybersecurity is not hard. You'll see tons of gurus giving all different types of advice. In my opinion, whenever you are building your platform, it's always good to think from a threat actor's perspective: what different ways can I get into your environment and take the data? An engineer has a good understanding of ways they can compromise a system. This is especially advised for companies that don't have a CISO or dedicated security person. For very young companies that don't have the budget for dedicated security people, they have to put on the hat of a bad guy and think about how they can hack into their own computers. This self-assessment exercise helps you understand the problems and put some controls, maybe out-of-the-box from the cloud environment, to mitigate some risks. As you mature, it's probably a good idea to bring in an experienced security person to design and execute the entire security program. That becomes an important piece of the puzzle. As you scale up, the complexity of managing data and creating different avenues to collect or process information may warrant further investments in your control design layers. It's an evolving journey. Treat cybersecurity, as you rightly said, as a growth driver instead of a roadblock. It will be very hard for companies to scale if they can't prove they take cybersecurity seriously.

No, thanks for having me, Paul. It was amazing. Thanks everyone.